Subject: RE: [mpls] TR: working group last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Sat, 24 Jun 2006 01:09:52 +0200

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:[email-masked]] 
> Envoyé : vendredi 23 juin 2006 17:23
> À : [email-masked]
> Cc : Lou Berger; LE ROUX Jean-Louis RD-CORE-LAN; 
> [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 23 Jun 2006 17:16:51 -0700 (PDT)

Hi Lou, JL and all,

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

<snipped>

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

The editors will include this in the next rev and consider this LC comment
addressed..

Thanks JL for identifiying the issue and Lou for fixing the text.

rahul