The MPLS WG Archive

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

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 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."
> 
> 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"
> 
> 
> 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...
> 
> 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?
> 
> 
> 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> ]
> 
> Section 7.1
> <S2L sub-LSP list> change to <S2L sub-LSP descriptor list>
> 
> 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
> 
> 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
> 
> 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.
> 
> 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"...
> 
> 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
> 
> Section 19.4.2 P2MP LSP_IPv4 FILTER_SPEC Object => P2MP 
> LSP_IPv6 FILTER_SPEC object
> 
> Also some references need to be updated...
> 
> 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