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

[[e-mail]]

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

Lizhong
 

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

> Hi  Lizhong,
> 
> [e-mail]: 
> 
> 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.
[Lizhong] I just try to work out a real network case for the problem you 
described.



> 

> 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." 
> 
> 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.
> 

> 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.
> 
> (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 ?
[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.


> 
> -Thomas
> 
> 
> 
> 

> > 
> > Message: 2
> > Date: Thu, 25 Nov 2010 14:14:40 +0100
> > From: Thomas Morin <[e-mail]>
> > Subject: Re: [mpls] wglc on draft-ietf-mpls-ldp-p2mp-11
> > To: [e-mail]
> > Message-ID: <[e-mail]>
> > 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
> > > [e-mail] 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.