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 call ondraft-ietf-mpls-rsvp-te-p2mp-05.txt
Hi Rahul, Your proposed text for the processing of Notify Request and Resv Conf objects covers my points. Thanks, JL > -----Message d'origine----- > De : Rahul Aggarwal [mailto:rahul@juniper.net] > Envoyé : jeudi 22 juin 2006 15:35 > À : LE ROUX Jean-Louis RD-CORE-LAN > Cc : mpls@ietf.org > Objet : RE: [mpls] TR: working group last call on > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > Hi JL, > > Please see below: > > On Thu, 22 Jun 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > Hi Rahul, > > > > Please see inline, > > > > > > > -----Message d'origine----- > > > De : Rahul Aggarwal [mailto:rahul@juniper.net] Envoyé : mardi 20 > > > juin 2006 22:47 À : LE ROUX Jean-Louis RD-CORE-LAN Cc : > > > mpls@ietf.org Objet : Re: [mpls] TR: working group last call on > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > Hi JL, > > > > > > Sorry for the delay. Please see below: > > > > > > On Fri, 26 May 2006, LE ROUX Jean-Louis RD-CORE-LAN wrote: > > > > > > > Hi all, > > > > > > > > I transfer the below comments on this list, as it should be > > > discussed > > > > as part of last call comments. > > > > > > > > Regards, > > > > > > > > JL > > > > > > > > > -----Message d'origine----- > > > > > De : LE ROUX Jean-Louis RD-CORE-LAN Envoyé : jeudi 25 > mai 2006 > > > > > 14:19 > > > > > À: > > > > > Objet : RE: working group last call on > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > Hi Rahul, Dimitri, Seisho > > > > > > > > > > Thanks for the great edit job, > > > > > > > > > > Find below a set of comments on this revision 05 > > > > > > > > > > Four technical points: > > > > > > > > > > 1: Section 8.1.2 Downstream notification > > > > > > > > > > The text in 8.1.2 is a bit unclear > > > > > > > > > > "A transit LSR sets the Sub-Group Originator ID in > the FILTER_SPEC > > > > > object(s) of a Resv message to the value, that was > > > received in the > > > > > corresponding Path message. If the incoming Resv > > > message carries a > > > > > Notify Request object then, the LSR MUST set the > Notify node > > > > > address > > > > > in the Notify Request object to the value, that was > > > received in the > > > > > corresponding Path message", > > > > > > > > > > > > > > > > Which value? The sub-group originator? the notify address? > > > > > > This should be the Router ID of the transit LSR if the > transit LSR > > > is merging more than one Resv with a Notify Request object. > > > > Ok, but it also applies when the LSR changes the sub-group > originator > >id to its own address doesn't it? > > > > Yes, you are right. > > > > > > > > > This is unclear. The processing needs to be clarified. > > > > > We could update as follows: > > > > > > > > > > "If the incoming Resv message carries a Notify Request > > > object then, > > > > > -If the sub-group originator ID is its own > > > address, the LSR MUST > > > > > set the Notify node address in the Notify Request object > > > to its own > > > > > address, in the Resv message that it sends upstream. > > > > > -If the sub group originator ID is not its own > > > address, the LSR > > > > > MUST propagate the Notify Request object unchanged, > in the Resv > > > > > message that it sends upstream." > > > > > > > > > > > Shouldn't the transit LSR always set its own address in > the Notify > > > Request if it is merging multiple Resvs with Notify > Request objects > > > into a single Resv ? The current text is not clear on this either. > > > > A transit LSR should actually put its own address in the Notify > > Request not only when it is merging multiple Resv, but also when it > > changes the sub-group orignator id to its own address (even > if there > > is no Resv merging) > > > > > > > > How about: > > > > > > "A transit LSR sets the Sub-Group Originator ID in the > FILTER_SPEC > > > object(s) of a Resv message to the value, that was > received in the > > > corresponding Path message. If the incoming Resv message > carries a > > > Notify Request object then: > > > > > > - If there is at least another incoming Resv message > that carries a > > > Notify Request object and the LSR merges these Resv > messages into a > > > single Resv message that is sent upstream, the LSR MUST set the > > > Notify node address in the Notify Request object to its Router ID. > > > > > > - Else the LSR MUST propagate the Notify Request object > unchanged, > > > in the Resv message that it sends upstream." > > > > See above comment > > > > How about adding a bullet between these two bullets: > > "- Else if the LSR sets the Sub-Group Originator ID in the > outgoing Path message, that corresponds to the received Resv > message, to its own address, the LSR MUST set the Notify node > address in the Notify Request object to its Router ID." > > > > > > > > > > > > > > 2: Section 8.2 ResvConf > > > > > > > > > > Similar comment > > > > > > > > > > "A transit LSR sets the Sub-Group Originator ID in > the FILTER_SPEC > > > > > object(s) of a Resv message to the value, that was > > > received in the > > > > > corresponding Path message. If any of the incoming > > > Resv messages > > > > > corresponding to a single Path message carry a > > > RESV_CONFIRM object > > > > > then the LSR MUST include a RESV_CONFIRM object in the > > > > > corresponding > > > > > Resv message that it sends upstream and MUST set > the receiver > > > > > address > > > > > in the RESV_CONFIRM object to the value that was > > > received in the > > > > > corresponding Resv message." > > > > > > > > > > Change to > > > > > > > > > > " > > > > > A transit LSR sets the Sub-Group Originator ID in the > > > FILTER_SPEC > > > > > object(s) of a Resv message to the value, that was > > > received in the > > > > > corresponding Path message. If any of the incoming > > > Resv messages > > > > > corresponding to a single Path message carry a > > > RESV_CONFIRM object > > > > > then the LSR MUST include a RESV_CONFIRM object in the > > > > > corresponding > > > > > Resv message that it sends upstream. If the sub-group > > > originator > > > > > ID is its own address then > > > > > it MUST set the receiver address in the > RESV_CONFIRM object > > > > > to this addresse, else it MUST > > > > > propagate the object unchanged" > > > > > > > > > > > Shouldn't the transit LSR always set its own address in the > > > RESV_CONFIRM if it is merging multiple Resvs with RESV_CONFIRM > > > objects into a single Resv ? The current text is not > clear on this > > > either. > > > > Same comment. Yes but IMO it should also do it when it changes the > > sub-group originator id (even with no Resv merge)? > > > > That is correct. > > > > > > > How about: > > > > > > "A transit LSR sets the Sub-Group Originator ID in the FILTER_SPEC > > > object(s) of a Resv message to the value that was received in the > > > corresponding Path message. If an incoming Resv message > > > corresponding to a single Path message carries a > RESV_CONFIRM object > > > then the LSR MUST include a RESV_CONFIRM object in the > corresponding > > > Resv message that it sends upstream and: > > > > > > - If there is at least another incoming Resv message > that carries a > > > RESV_CONFIRM object and the LSR merges these Resv messages into a > > > single Resv message that is sent upstream, the LSR MUST set the > > > receiver address in the RESV_CONFIRM object to its Router ID. > > > > > > - Else the LSR MUST propagate the RESV_CONFIRM object > unchanged, in > > > the Resv message that it sends upstream." > > > > > > > This also applies when the LSR changes the sub-group originator id > > without any Resv merge > > > > How about adding a bullet in between these two bullets: > > "- If the LSR sets the Sub-Group Originator ID in the > outgoing Path message, that corresponds to the received Resv > message, to its own address, the LSR MUST set the receiver > address in the RESV_CONFIRM object to its Router ID." > > thanks, > rahul > > > > > > > > > > > > > > 3: Section 14.2 Sub-group based reoptimization > > > > > > > > > > The new path may intersect the old path, this is a case > > > of rerouting > > > > > and this is not covered by remerge procedures as described in > > > > > section 18. Hence Transient Data duplication may occur during > > > > > the time between the Resv is received and the PathTear is > > > sent. To avoid > > > > > data duplication the branch node must not start > > > transmitting on the > > > > > new path before the old path has been torn down, but this > > > will lead > > > > > to transient packet loss. > > > > > This should be clearly mentionned here IMO. > > > > > Actually the only way to avoid both transient duplication and > > > > > transient packet loss is to rely on the global mb4b > > > procedure with a > > > > > new LSP id... > > > > > > > > > > > How about adding the following to this section: > > > > > > "Sub-Group based re-optimization may result in transient data > > > duplication as the new Path messages for a set of S2L > sub-LSPs may > > > transit one or more nodes with the old Path state for the > same set > > > of S2L sub-LSPs. " > > > > The proposed text addresses my point and is fine with me > > > > > > > > > > > > > 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 ? > > > > I will provide more comments in a following email. > > > > Best Regards, > > > > JL > > > > > > > > > > > > > > > Also find below some minor edits: > > > > > > > > > > Section 6.1 > > > > > > > > > > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP > > > > > SECONDARY_EXPLICIT_ROUTE> ] > > > > > Change to: > > > > > <S2L sub-LSP descriptor> ::= <S2L_SUB_LSP&>; [ <P2MP > > > > > SECONDARY_RECORD_ROUTE> ] > > > > > > > > > > > Ok. > > > > > > > > Section 7.1 > > > > > <S2L sub-LSP list> change to <S2L sub-LSP descriptor list> > > > > > > > > > > > Ok. > > > > > > > > Section 8.1.2 > > > > > > > > > > "If this LSR subsequently receives a corresponding > > > Notify message > > > > > from > > > > > an upstream LSR than it MUST: > > > > > - send a Notify message downstream toward the Notify > > > > > node address that the LSR received in the Resv message. > > > > > - process the sub-group fields of the FILTER_SPEC > object in the > > > > > received Notify message, and modify their values in > > > the Notify > > > > > message that is forwarded to match the sub-group > field values > > > > > in the original Path message sent downstream by > this LSR." > > > > > > > > > > Invert these two bullets > > > > > > > > > > > Ok. > > > > > > > > Section 8.2 > > > > > > > > > > "If this LSR subsequently receives a corresponding > > > ResvConf message > > > > > from an upstream LSR then it MUST: > > > > > - send a ResvConf message downstream toward the > > > receiver address > > > > > that > > > > > the LSR received in the RESV_CONFIRM object in the > > > Resv message. > > > > > - process the sub-group fields of the FILTER_SPEC > object in the > > > > > received ResvConf message, and modify their > values in the > > > > > ResvConf > > > > > message that is forwarded to match the sub-group > field values > > > > > in the original Path message sent downstream by > this LSR." > > > > > > > > > > Invert these two bullets > > > > > > > > > > > Ok. > > > > > > > > Section 11.2 last sentence > > > > > > > > > > "Note the receiver of a ResvErr message is able to > > > identify the > > > > > errored outgoing Path [Change to: Resv] > > > > > message, and outgoing interface, based on the > Sub-Group fields > > > > > received in the ResvErr message. > > > > > > > > > > Ok. > > > > > > > > > > > > Section 13 > > > > > > > > > > "A sender on a LAN uses a different label for sending > > > traffic to each > > > > > node on the LAN that belongs to the P2MP LSP" > > > > > > > > > > This is not always the case, I would rather say > > > > > > > > > > "Downstream nodes for a given P2MP LSP on a LAN are likely to > > > > > allocate a different label, in which case the sender has > > > to perform > > > > > replication"... > > > > > > > > > > > Actually the procedures in this document imply that a sender on a > > > LAN must do replication if there is more than one downstream > > > receiver. Upstream labels are required to avoid this. > > > > > > However I do realize that the first sentence is not entirely > > > accurate. How > > > about: > > > > > > "If there are multiple downstream LSRs on a LAN on a P2MP LSP, a > > > sender LSR on the LAN has to perform replication. A > separate copy of > > > the data is unicast to each of the downstream LSRs" > > > > > > > > > > > Section 16 > > > > > > > > > > "Stitching and nesting > > > > > considerations and procedures are described further in > > > [INT-REG]." > > > > > > > > > > Change to "Stitching and nesting > > > > > considerations and procedures are described further in > > > > > [LSP-STITCH] and [RFC4206]." > > > > > > > > > > Section 17 > > > > > > > > > > Infact => In fact > > > > > > > > > > > Ok. > > > > > > > > Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object => P2MP > > > > > LSP_IPv6 FILTER_SPEC object > > > > > > > > > > > Ok. > > > > > > > > Also some references need to be updated... > > > > > > > > > > > Will do that. > > > > > > Thanks for the detailed comments. > > > > > > rahul > > > > > > > > Best Regards, > > > > > > > > > > JL > > > > > > > > > > > -----Message d'origine----- > > > > > > De : owner-ccamp@ops.ietf.org > > > > > > [mailto:owner-ccamp@ops.ietf.org] De la part de Loa > > > > > Andersson Envoyé : > > > > > > samedi 13 mai 2006 12:48 À : mpls@ietf.org Cc : ccamp; > > > > > George Swallow; > > > > > > zzx-adrian@olddog.co.uk; Deborah Brungard; Ross > Callon; Bill > > > > > > Fenner Objet : working group last call on > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > > > Working Group, > > > > > > > > > > > > this initiates a two week working group last call on > > > > > > draft-ietf-mpls-rsvp-te-p2mp-05.txt > > > > > > > > > > > > please send comments to the MPLS working group > mailling list > > > > > > and/or working co-chairs. > > > > > > > > > > > > The last call ends eob May 28th. > > > > > > > > > > > > The ccamp mailing list copied as this is a work that has an > > > > > > overlap between the working groups. > > > > > > > > > > > > Loa and George > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Loa Andersson > > > > > > > > > > > > Principal Networking Architect > > > > > > Acreo AB phone: +46 8 632 77 14 > > > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64 > > > > > > Kista, Sweden email: > > > loa.andersson@acreo.se > > > > > > loa@pi.se > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 |
|