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: Fri, 23 Jun 2006 09:20:57 +0200

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. 

IMO full RRO inclusion is the price to pay if you want to fix remerge in a simple manner in the control plane.

Regards,

JL

> -----Message d'origine-----
> De : Lou Berger [mailto:[email-masked]] 
> Envoyé : vendredi 23 juin 2006 05:51
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]; [email-masked]; Drake, John E
> Objet : RE: [mpls] TR: working group last call 
> ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> 
> JL,
> 
> So what happens when no RRO is used (which isn't currently 
> required) or portions of the RRO are removed?
> 
> Lou
> 
> At 02:03 AM 6/22/2006, LE ROUX Jean-Louis RD-CORE-LAN wrote:
> 
> >Hi Rahul, all
> >
> >Actually, after thinking a bit more, it seems to me that a simpler 
> >remerge procedure based on RRO analysis could be useful.
> >If the RRO is carried in Path messages, the node where the remerge 
> >occurs could easily identify the node that created the 
> remerge, simply 
> >by analyzing the two RROs.
> >When a node detect a remerge it sends a PAthErr with a new object 
> >(Remerge-Spec object) that identifies the remerge origin. 
> This PathErr 
> >carries the set of sub-LSPs received in the Path message that caused 
> >the remerge.
> >On receipt of such PAthErr, a node that see its own address in the 
> >Remerge-spec object moves the set of sub-LSPs...
> >
> >It seems that this procedure would require simpler processing...
> >It requires the use of RRO, but this is the price to pay.
> >
> >Would that make sense?
> >
> >Best Regards,
> >
> >JL
> >
> >
> > > -----Message d'origine-----
> > > De : Drake, John E [mailto:[email-masked]] 
> Envoyé : mardi 
> > > 20 juin 2006 23:59 À : [email-masked]; LE ROUX Jean-Louis 
> > > RD-CORE-LAN Cc : [email-masked] Objet : RE: [mpls] TR: 
> working group 
> > > last call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
> > >
> > > Rahul,
> > >
> > > Snipped, comments inline.
> > >
> > > Thanks,
> > >
> > > John
> > > > > > 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. Actually there will always be an 
> > > > > > intersection, because the PathErr includes the set 
> of sub-lsp 
> > > > > > objects in the received Path... 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?
> > > > > >
> > > >
> > > > I believe this was clarified by John Drake offline and no 
> > > > revisions
> > > were
> > > > needed ?
> > > 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"
> > >
> > > As you can see from the last paragraph, we do need to 
> create a new 
> > > object/type.
> > >
> >
> >_______________________________________________
> >mpls mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/mpls
> 
> 

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

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Jun 2006 07:28:52 -0400

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

Lou

---

From: [email-masked]
Date: Fri, 23 Jun 2006 14:11:03 +0200

hi j-l, lou, all,

RFC 4461 mentions

"The requirements presented in this document apply equally to packet-
   switched networks under the control of MPLS protocols and to packet-
   switched, TDM, lambda, and port-switching networks managed by
   Generalized MPLS (GMPLS) protocols.  Protocol solutions developed to
   meet the requirements set out in this document MUST attempt to be
   equally applicable to MPLS and GMPLS."

without favoring one technique over the other - this specific requirement 
output of the MPLS WG shall be verified otherwise we should probably stop 
writing requirement documents 

it is therefore, fundamental to keep protocol mechanisms aligned for both 
MPLS and GMPLS (specialization should only be considered when there is no 
viable & scalable alternative)

thanks,
- dimitri.

"LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
23/06/2006 09:20
 
        To:     "Lou Berger" <[email-masked]>
        cc:     [email-masked], "Drake, John E" <[email-masked]>
        Subject:        RE: [mpls] TR: working group last call 
ondraft-ietf-mpls-rsvp-te-p2mp-05.txt

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. 

IMO full RRO inclusion is the price to pay if you want to fix remerge in a 
simple manner in the control plane.

Regards,

JL

---

From: Rahul Aggarwal <[email-masked]>
Date: Fri, 23 Jun 2006 06:34:28 -0700 (PDT)

Hi Lou,

See below:

On Fri, 23 Jun 2006, Lou Berger wrote:

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

<Last Call Comment from JL>

>  normally included in a PathErr message, as well as one or more
SUB-
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
>    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
> intersection, because the PathErr includes the set of sub-lsp
> objects in the received Path... 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.

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

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

As you can see from the last paragraph, we do need to create a new
object/type.

<End of John Drake's comment on the above>

> De we really want/need to be making

See above for the assertion.

rahul

---

From: Lou Berger <[email-masked]>
Date: Fri, 23 Jun 2006 11:23:22 -0400

sigh.  See below.

>below outlining the issue:

see below for a description of how it *does* work.

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

>IMO for this procedure to work

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

>message. I think this is reasonable solution.

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

I think that a new type isn't needed and what is defined (and further 
clarified above) is sufficient.

>See above for the assertion.

see above.

Lou