Subject: Re: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11

From: [email-masked]
Date: Wed, 15 Dec 2010 17:29:27 +0800

Hi Thomas,
If there is no loop before MBB, and the loop is not caused by the event 
which triggers the MBB, then I can not find a network case of which there 
is a loop of multi-hop during MBB. Could you kindly give a network 
example?

What's more, I have a comment to section 5:
"mLDP is able to prevent this inconsistency by never allowing an upstream 
LDP neighbor to be added as a downstream LDP neighbor into the LFT for the 
same FEC."

Please see the following figure:
    --R
   /  |
 10   5
 /    |
A     N2--
 \    |   \
  5   5    \
   \  |     5
    --Z      \
      |       \
      |        \
    Leaf1     Leaf2

For the above network, the mLDP tree will be R->N2->Z->Leaf1, N2->Leaf2. 
When the link between R and N2 is down, or changed to cost 50 (for 
example), then N2 should do MBB, and choose Z as new upstream. Assume Z 
has got the topology change event, and Z will also do MBB and find new 
upstream node A. When Z receive the ACK notification, it will install new 
<X, Y, L> and remove the old. What's more, Z will add N2 which is a former 
upstream node, as a downstream node. Then it is conflict with the 
description in section 5. Then this restriction should not be applied for 
the MBB procedure.

Thanks
Lizhong

> ------------------------------
> 
> Message: 2
> Date: Thu, 25 Nov 2010 14:14:40 +0100
> From: Thomas Morin <[email-masked]>
> Subject: Re: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
> 
> Hi Loa, working group,
> 
> I did a review of the draft a few months ago, and most of the issues I 
> had are now fixed.
> 
> There is still one issue pending that I think remains to be solved, 
> related to how the specs handle the effects of transients unicast 
> routing loops for P2MP LSPs (MP2MP already had satisfying text in this 
> respect). Some discussion has already been done on the list (last email: 

> http://www.ietf.org/mail-archive/web/mpls/current/msg05041.html ), and 
> off the list, but without a conclusion yet.
> 
> A part from that, I think the document is overall in a pretty good 
shape.
> 
> -Thomas
> 
> 
> Loa Andersson a ?crit :
> > Working Group,
> >
> >
> > this is to start a 2 week+ working group last call on
> > draft-ietf-mpls-ldp-p2mp-11.
> >
> > Please review the document and send comments to the
> > [email-masked] mailing lsit.
> >
> > The working group last call ends November 26 - 2010.
> >
> > /Loa
> >
> 
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Thomas Morin <[email-masked]>
Date: Fri, 17 Dec 2010 17:25:21 +0100

Hi  Lizhong,

[email-masked]:
>
> If there is no loop before MBB, and the loop is not caused by the 
> event which triggers the MBB, then I can not find a network case of 
> which there is a loop of multi-hop during MBB. Could you kindly give a 
> network example?

I'm not sure why you ask me the question...

I've for now only considered the cases where not more than one failure, 
metric or topology change occur in a short time window (cases where two 
or more such events occur nearly simultaneously compared to the 
convergence time are off scope).   Given this I'm just looking at what 
happens after, and what is due to, *one* event, and thus don't think 
I've claimed anything on the existence of cases of multihop loop during 
MB4B that would not be due to the same event that triggered MB4B.

What I've insisting on clarifying is the case of one event causing a 
multihop loop, in which the MB4B resulting from this event will fail to 
give the expected result.

> "mLDP is able to prevent this inconsistency by never allowing an 
> upstream LDP neighbor to be added as a downstream LDP neighbor into 
> the LFT for the same FEC."

I think that the text that you quote from section 5 that says "never 
allowing an upstream LDP neighbor to be added as a downstream LDP 
neighbor" is a shortcut to refer to section 2.4.1.4 §2 that implies that 
a router will wait for the inconsistency to resolve before installing 
dataplane states (the inconsistency being a router receiving a label map 
from its own upstream router), but does *not* say that the control plane 
messages should be ignored.

Note well that if the choice has been made to purely ignore Label maps 
in such inconsistency cases, then basic rerouting cases (with or without 
MBB) would break.

> For the above network, the mLDP tree will be R->N2->Z->Leaf1, 
> N2->Leaf2. When the link between R and N2 is down, or changed to cost 
> 50 (for example), then N2 should do MBB, and choose Z as new upstream.

(side note: if R-N2 goes down, N2 doesn't need to do any MB4B; a more 
illustrative case is R-N2 metric increasing and making Z a better 
upstream for N2 for the considered FEC)

> Assume Z has got the topology change event, and Z will also do MBB and 
> find new upstream node A. When Z receive the ACK notification, it will 
> install new <X, Y, L> and remove the old. What's more, Z will add N2 
> which is a former upstream node, as a downstream node. Then it is 
> conflict with the description in section 5. Then this restriction 
> should not be applied for the MBB procedure.

Let's keep in mind the following:
- the "restriction" is better described as a delay, as indicated above
- last revision has new text at end of section 9.4.4, that I had 
suggested for being consistent with 2.4.1.4 §2, and that says that 
sending the MBB notification is delayed until the inconsistency is resolved.

Based on this, let's look at your example.
We have two possible cases:

- Z updates its upstream before N2 does:
   * (Z's upstream was N2, is now A)
   * Z sends Label map to A, ... receives a MBB notification at some point
   * later on, N2 send Label map to Z, which hapilly processes  it ((no 
inconsistency causing a delay to update the dataplane), and Z sends the 
MB4B notification to N2 at once (or as soon as it receives it)

- N2 updates its upstream before Z does:
   * (N2 upstream was R, and is now Z)
   * when N2 sends its Label map to Z, Z processes it, but notices the 
inconsistency (N2 is Z's upstream) and thus (a) does not yet forward LSP 
traffic to N2 (2.4.1.4§2), and (b) does not yet send an MB4B 
notification (9.4.4)
   * then, a bit later, Z updates its upstream state (was N2, becomes 
A), which result in (a) Z building the tree toward A, (b) Z setting up 
dataplace to forward LSP traffic to N2 (as per last sentence of 2.4.3) 
and (b) sends the MBB notification (as per 9.4.4)

Was my attempt at a clarification useful ?

One possible improvement to the document would be to have the sentence 
of section 5 you quoted point at 2.4.1.4 to avoid any misunderstanding 
of what "never allowing ..." means.

-Thomas

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Sun, 19 Dec 2010 12:01:44 +0800

Hi Thomas,
Thanks for the explanation. See comments in line.

Lizhong

Thomas Morin <[email-masked]> wrote on 2010-12-18 
00:25:21:

> which there is a loop of multi-hop during MBB. Could you kindly give
> a network example? 
> 
> I've for now only considered the cases where not more than one 
> failure, metric or topology change occur in a short time window 
> (cases where two or more such events occur nearly simultaneously 
> compared to the convergence time are off scope).   Given this I'm 
> just looking at what happens after, and what is due to, *one* event,
> and thus don't think I've claimed anything on the existence of cases
> of multihop loop during MB4B that would not be due to the same event
> that triggered MB4B.
> 
> multihop loop, in which the MB4B resulting from this event will fail
> to give the expected result.
[Lizhong] I just try to work out a real network case for the problem you 
described.

> allowing an upstream LDP neighbor to be added as a downstream LDP 
neighbor
> " is a shortcut to refer to section 2.4.1.4 §2 that implies that a 
> router will wait for the inconsistency to resolve before installing 
> dataplane states (the inconsistency being a router receiving a label
> map from its own upstream router), but does *not* say that the 
> control plane messages should be ignored.
> 
> Note well that if the choice has been made to purely ignore Label 
> maps in such inconsistency cases, then basic rerouting cases (with 
> or without MBB) would break.
> 

> N2->Leaf2. When the link between R and N2 is down, or changed to 
> cost 50 (for example), then N2 should do MBB, and choose Z as new 
upstream.
> 
> (side note: if R-N2 goes down, N2 doesn't need to do any MB4B; a 
> more illustrative case is R-N2 metric increasing and making Z a 
> better upstream for N2 for the considered FEC)

> Assume Z has got the topology change event, and Z will also do MBB 
> and find new upstream node A. When Z receive the ACK notification, 
> it will install new <X, Y, L> and remove the old. What's more, Z 
> will add N2 which is a former upstream node, as a downstream node. 
> Then it is conflict with the description in section 5. Then this 
> restriction should not be applied for the MBB procedure. 
> 
>   * later on, N2 send Label map to Z, which hapilly processes  it 
> ((no inconsistency causing a delay to update the dataplane), and Z 
> sends the MB4B notification to N2 at once (or as soon as it receives it)
> 
>   * when N2 sends its Label map to Z, Z processes it, but notices 
> the inconsistency (N2 is Z's upstream) and thus (a) does not yet 
> forward LSP traffic to N2 (2.4.1.4§2), and (b) does not yet send an 
> MB4B notification (9.4.4)
> A), which result in (a) Z building the tree toward A, (b) Z setting 
> up dataplace to forward LSP traffic to N2 (as per last sentence of 
> 2.4.3) and (b) sends the MBB notification (as per 9.4.4)
> 
[Lizhong] the procedure is clear, thanks.

> 
> One possible improvement to the document would be to have the 
> sentence of section 5 you quoted point at 2.4.1.4 to avoid any 
> misunderstanding of what "never allowing ..." means.
[Lizhong] actually I suggest to explicitly say the control plane will 
allow an upstream LDP neighbor to be added as a downstream LDP neighbor, 
as you described above. Then it is more clear.

shape.