The MPLS WG Archive

["LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ft.com>]

Hi Lou,

Your proposed update to the remerge text covers my initial LC comment. 
This requires quite a lot of processing compared to the RRO-based approach I suggested, but it works in all situations (no RRO or partial RRO). Hence it must be kept...

Also please see inline, 

> -----Message d'origine-----
> De : Lou Berger [mailto:lberger@labn.net] 
> Envoyé : vendredi 23 juin 2006 17:23
> À : zzx-rahul@juniper.net
> Cc : Lou Berger; LE ROUX Jean-Louis RD-CORE-LAN; 
> mpls@ietf.org; Drake, John E
> Objet : RE: [mpls] TR: working group last call 
> ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> sigh.  See below.
> 
> At 09:34 AM 6/23/2006, Rahul Aggarwal wrote:
> 
> 
> >Hi Lou,
> >
> >See below:
> >
> >On Fri, 23 Jun 2006, Lou Berger wrote:
> >
> > > JL,
> > >
> > > See below.
> > >
> > > At 03:20 AM 6/23/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> > >
> > > >Hi Lou,
> > > >
> > > >When RRO is not used this procedure does not apply and remerge 
> > > >should be fixed in the data plane on the remerge node.
> > >
> > > "fixing in the data plane" doesn't work for all 
> technologies covered 
> > > in the spec, e.g., GMPLS optical.
> > >
> > > (You're making me think about my favorite HL Mencken quote...)
> > >
> > > >IMO full RRO inclusion is the price to pay if you want to fix 
> > > >remerge in a simple manner in the control plane.
> > >
> > > Yes, but there is already a defined, documented, and agreed to 
> > > mechanism that will work for all the cases.
> >
> >It doesn't appear that the mechanism for fixing remerge in 
> the control 
> >plane works as defined and hence this discussion. See the email 
> >snippets below outlining the issue:
> 
> see below for a description of how it *does* work.
> 
> ><Last Call Comment from JL>
> >
> > > 4: Section 18.1.1 Remerge Procedure
> >
> > >The text says
> > >    "The PathErr message MUST include all of the objects
> > >  normally included in a PathErr message, as well as one or more
> >SUB-
> > >    LSP objects from the set of sub-LSPs associated with the
> >matching
> > >    P2MP LSP Path state.  A minimum of three SUB-LSP objects is
> > >    RECOMMENDED. This will allow the node that caused the re-merge
> >to
> > >    identify the outgoing Path state associated with the valid 
> > > portion of
> > >    the P2MP LSP. The set of SUB-LSP objects in the received Path 
> > > message
> > >    MUST also be included"
> > >
> > > And then:
> > >
> > >    "A node that receives a PathErr message that contains 
> the Error 
> > > Value
> > >    "Routing Problem/P2MP Remerge Detected" MUST determine if it is
> >the
> > >>    node that created the re-merge case.  This is done by checking
> > >    whether there is any intersection between the set of SUB-LSP 
> > > objects
> > >    associated with the matching P2MP LSP Path state and 
> the set of 
> > > SUB-
> > >    LSP objects in the received PathErr message.  If there is, then
> >the
> > >>    node created the re-merge case."
> > >
> > > There is an issue here.
> 
>  I agree the text could be clearer.  But I think this is the 
> sole issue.
> 
> >  Actually there will always be an
> > > intersection, because the PathErr includes the set of sub-lsp 
> > > objects in the received Path...
> 
> The text should have stated "... matching P2MP LSP Path state 
> and the set of other-branch SUB-LSP objects in the 
> (added-----^^^^^^^^^^^^, and vvvvvvvvvvvvvvvvvvvvvvv) 
> received PathErr message.  Other-branch SUB-LSP objects are 
> those SUB-LSP objects included, by the node detecting the 
> re-merge case, in the PathErr message that were taken from 
> the matching P2MP LSP Path state.  Such SUB-LSP objects are 
> identifiable as they will not be include in the Path message 
> associated with the received PathErr message.  See Section 
> 11.1 for more details on how such an association is identified."

OK this text is definitely clearer, and easy to understand.


> 
> >IMO for this procedure to work
> > > the PathErr MUST only include sub-LSP objects associated with the 
> > > matching P2MP LSP state on the rermerge LSR and must not 
> include the 
> > > set of SUB-LSP objects in the received Path message.
> >
> > > By the way why are three objects recommended?
> > >
> > >
> 
> 
> Both sets of SUB-LSP objects are required.  Here's why:
> 1) SUB-LSP objects from the Path message (your point): this 
> is required to cover the case of other branches between the 
> node that detected a re-merge and the node that caused the 
> re-merge.  

OK, I see.

> Just moving all the  SUB-LSP objects at the 
> offending branch node is at best unneeded disruption to such 
> (sub) branch destinations and at worst will result in a new 
> re-merge situation.  In the latter case, the result could be 
> permanent instability and oscillation between multiple 
> re-merge points.

OK

> 2) "Other-branch" SUB-LSP objects: These are required to 
> cover the case where a branch node has more than two (or n) 
> outgoing path messages.  Consider the case where there are 3 
> outgoing path messages and one of which results in a 
> (partial) re-merge downstream.  To correct the problem, this 
> branch node needs to identify which of the other 2 (or n-1) 
> outgoing path messages is triggering the re-merge.  
> "Other-branch" SUB-LSP objects provide this identification.  
> Also, as they are already being included, these objects are 
> also used to identify the branch node that caused the re-merge.

OK

> 
> 
> 
> ><End LC comment from JL>
> >
> ><Response to the above by Rahul>
> >
> > > I believe this was clarified by John Drake offline and no 
> revisions 
> > > were needed ?
> >
> ><End of the response to the above by Rahul>
> >
> ><John Drake's Comment on the above>
> >
> >Rahul,
> >
> >Here's the e-mail I sent to JL:
> >
> >"JL,
> >
> >The text was originally stated as you stated.  The issue is that the 
> >set of sub-LSPs associated with the interface on the node 
> that caused 
> >the re-merge condition may have more members than the set of 
> sub-LSPs 
> >in the received Path message, and you only want to move the 
> ones that 
> >were in the received Path message.
> >
> >Adrian was the one who initially pointed this and he 
> proposed creating 
> >a different object/type for the set of sub-LSPs in the received Path 
> >message. I think this is reasonable solution.
> >
> >Thanks,
> >
> >John"
> 
> While a different type is a possible solution, I think John 
> is forgetting a detailed discussion that he and I had in 
> which we decided that we could use another object (or c-type) 
> but decided that such identification wasn't really needed for 
> proper processing so we decided not to add the complexity of 
> a new type.
> 
> >As you can see from the last paragraph, we do need to create a new 
> >object/type.
> >
> 
> I think that a new type isn't needed and what is defined (and 
> further clarified above) is sufficient.

A new type would allow easier identification of "other-branch" sub-LSP objects, it would require less processing, but I agree that this works as is.

Regards

JL

> 
> ><End of John Drake's comment on the above>
> >
> > > De we really want/need to be making
> > > such a significant change at this late date (post WG last 
> call!).  
> > > If it were broken, then certain a change would be needed, but I 
> > > haven't heard anyone make such an
> > assertion.
> > >
> >
> >See above for the assertion.
> 
> see above.
> 
> Lou
> 
> 
> >rahul
> 
> 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls