The MPLS WG Archive

["LE ROUX Jean-Louis RD-CORE-LAN" <jeanlouis.leroux@orange-ft.com>]

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?

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

> 
> 
> > > 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)?

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

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