The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] TR: working group last callondraft-ietf-mpls-rsvp-te-p2mp-05.txt
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 > -----Message d'origine----- > De : Lou Berger [mailto:lberger@labn.net] > Envoyé : vendredi 23 juin 2006 13:29 > À : LE ROUX Jean-Louis RD-CORE-LAN > Cc : Lou Berger; zzx-rahul@juniper.net; mpls@ietf.org; Drake, John E > Objet : RE: [mpls] TR: working group last call > ondraft-ietf-mpls-rsvp-te-p2mp-05.txt > > 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 > > > > > -----Message d'origine----- > > > De : Lou Berger [mailto:lberger@labn.net] Envoyé : > vendredi 23 juin > > > 2006 05:51 À : LE ROUX Jean-Louis RD-CORE-LAN Cc : > > > zzx-rahul@juniper.net; mpls@ietf.org; 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:John.E.Drake2@boeing.com] > > > Envoyé : mardi > > > > > 20 juin 2006 23:59 À : zzx-rahul@juniper.net; LE ROUX > Jean-Louis > > > > > RD-CORE-LAN Cc : mpls@ietf.org 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 > > > >mpls@lists.ietf.org > > > >https://www1.ietf.org/mailman/listinfo/mpls > > > > > > > > _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls |
|