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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 26 May 2006 15:59:41 +0200

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 : [email-masked]
> > [mailto:[email-masked]] De la part de Loa 
> Andersson Envoyé : 
> > samedi 13 mai 2006 12:48 À : [email-masked] Cc : ccamp; 
> George Swallow; 
> > [email-masked]; 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:  [email-masked]
> >                                            [email-masked]
> > 
> > 

_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Wed, 31 May 2006 10:44:38 -0400

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yakov Rekhter
> Sent: Wednesday, May 24, 2006 11:35 AM
> To: Loa Andersson
> Cc: [email-masked]; ccamp; George Swallow (swallow); Adrian 
> Farrel; Deborah Brungard; Ross Callon; Bill Fenner
> Subject: Re: working group last call on 
> Loa and George,
> Few observations and suggestions...
> 
> (a) <Ingress LSR IP address, P2MP ID> tuple is both necessary 
> and sufficient to unambiguously identify a P2MP Tunnel.
> 

Yakov, et al

I would ask to add extended tunnel ID as part of this, unless we force
is to be equal to the Ingress LSR IP address (at least in P2MP draft),
as suggested by George. 

> (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both 
> necessary and sufficient to identify a P2MP LSP.

Following the above comment, a FEC for P2MP is identified by <Ingress
LSR IP address, P2MP ID, LSP ID, extended tunnel ID>. 

Thanks

Regards... Zafar 

> 
> Therefore I would suggest that draft-ietf-mpls-rsvp-te-p2mp-05.txt
> should say the following:
> 
> 1. A P2MP tunnel is identified by a tuple <root node IP address,
> index>, where the index value is unique within the scope of the IP
> address of the root node.  The P2MP tunnel identifier <root 
> node IP address, index> is unique within the same scope as 
> the root node IP address.
> 
> 2. Both the Extended Tunnel ID and the Tunnel Sender Address 
> fields carry the root node IP address (both fields carry the 
> same value).
> The index is carried in the P2MP ID.
> 
> 3. Tunnel ID field should be set to all zeros, and be ignored 
> on receipt.
> 
> 4. A P2MP LSP is identified by a combination of tunnel 
> identifier (<root node IP address, index>), and LSP ID.
> 
> With this in mind sections 4.1, 4.2, 19.1 and 19.2 should be 
> modified to clarify the following:
> 
> (a) SESSION identifier;
> (b) semantics of Extended Tunnel ID; semantics of the P2MP ID;
> (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.
> 
> Yakov.
>

---

From: "Zafar Ali \(zali\)" <[email-masked]>
Date: Wed, 31 May 2006 10:44:33 -0400

> Sent: Sunday, May 28, 2006 12:47 PM
> To: Adrian Farrel
> Cc: Loa Andersson; [email-masked]; ccamp; George Swallow 
> (swallow); Deborah Brungard; Ross Callon; Bill Fenner
> Adrian,
> > >> > (a) <Ingress LSR IP address, P2MP ID> tuple is both 
> necessary and 
> > >> > sufficient to unambiguously identify a P2MP Tunnel.
> > >> >
> > >> Clearly these two statements depend on the definition of 
> "P2MP ID" 
> > >> as you pointed out below.
> > >>
> > >> As the I-D says...
> > >>    The P2MP ID provides an identifier for the set of 
> destinations of the
> > >>    P2MP TE Tunnel.
> > >
> > > Does this identifier have a globally unique scope, or 
> only the scope 
> > > of the root ? If the former, then what are the procedures for 
> > > assigning such identifiers ?
> > 
> > Good questions.
> > 
> > Presumably, if we want to retain the concept of Session (which 
> > appeared to be the case in discussion amongst the authors) then the 
> > P2MP ID has to have global scope.
> > 
> > Not sure whether the procedures for assigning the 
> identifiers has to 
> > be in scope of this document. The procedure for assigning 
> IP addresses 
> > to P2P tunnel destinations does not appear to be in scope 
> for RFC3209.
> > 
> > It is worth looking at RFC4461 for more information on the P2MP ID. 
> > This gives us:
> >       A unique identifier of a P2MP TE LSP, which is 
> constant for the
> >       whole LSP regardless of the number of branches and/or leaves.
> > which is not as hepful as it could have been :-(
> > 
> > I think you are right to try to flush this sort of thing out now 
> > rather than let us get into the ambiguity mess that we got 
> to with RFC3209.
> 
> There is a difference between IP addresses used for P2P 
> tunnel destinations, and identifiers used for P2MP ID. The 
> former are unicast addresses (each address identifies a 
> *single* node/interface).
> The latter are *group* addresses (each address identifies a 
> *group* of nodes). There are well-established procedures for 
> assigining unicast IP addresses, but not for group addresses.
> 
> If some folks would like to retain the ability of the P2MP ID 
> to have global scope, then at the minimum the spec (a) should 
> have this as *an option*, with P2MP ID having the scope of 
> the root node being another option documented in the spec, 
> and (b) spell out the procedures for assigining such globally 
> unique P2MP IDs.

Yakov, Adrian, et al

I think global scoping will be a bad idea. Furthermore, we cannot force
it to come from multicast IP address space. So Ingress node scoping is
quite obvious and IMHO suffices. 

I also don't see an issue in sharing 2^16 space for both P2MP and P2P
tunnels. Does anyone see an issue here? I think having said that P2MP ID
has Ingress node scope, an implementation MAY choose to make P2MP ID =
tunnel ID, or has flexibility otherwise. 

My $0.02. 

Thanks

Regards... Zafar