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

From: "Drake, John E" <[email-masked]>
Date: Tue, 20 Jun 2006 14:59:03 -0700

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 22 Jun 2006 08:03:58 +0200

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

 LSP Path state.  A minimum of three SUB-LSP objects is
> > > >    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
> > > >    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-
> > > > 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.
> 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.
>

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Thu, 22 Jun 2006 16:02:39 +0200

Hi Rahul,

>Would you like to propose the modified text ? 

I can provide some text by the end of the day.

Regards,

JL

> De : Rahul Aggarwal [mailto:[email-masked]] 
> Envoyé : jeudi 22 juin 2006 15:53
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [email-masked]; Drake, John E
> Hi JL,
> On Thu, 22 Jun 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.
> > 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.
> I think this is reasonable. If it is desriable to fix remerge 
> in the control plane this is a reasonable tradeoff. Else the 
> spec has the option to fix remerge in the data plane.
> 
> > Would that make sense?
> >
> 
> Would you like to propose the modified text ?
> 
> Thanks,
> rahul
> 
> > Best Regards,
> >
> > JL
> >
> >
> 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,
> > >
> > > 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.
> > >
> > > creating a different object/type for the set of sub-LSPs in the 
> > > received Path message. I think this is reasonable solution.
> > >
> > > Thanks,
> > >
> > > John"
> > >

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 23 Jun 2006 14:29:15 +0200

Hi Lou,

> 
> "fixing in the data plane" doesn't work for all technologies 
> covered in the spec, e.g., GMPLS optical.

Couldn't you fix it in the optical case, simply by not activating the cross connection that causes the re-merge?

> If it were broken, then certain a 
> change would be needed, but I haven't heard anyone make such 
> an assertion.

It seems to me that the current procedure requires a lot of processing. All LSRs on the path from the re-merge originator to the re-merge node will have to compare all sub-LSPs in the PathErr with all sub-LSPs in the corresponding P2MP Path State Block, and this may require a lot of processing. The other approach only require looking at the re-merge originator address...

However, note that this is not a blocking issue for me if we let the current procedure as is.

Regards,

JL

> De : Lou Berger [mailto:[email-masked]] 
> Envoyé : vendredi 23 juin 2006 13:29
> Cc : Lou Berger; [email-masked]; [email-masked]; Drake, John E
> 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
> 
> >Regards,
> >
> >JL
> >
> > > 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 
> > > 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.
> > > >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.