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

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 
> draft-ietf-mpls-rsvp-te-p2mp-05.txt 
> 
> Loa and George,
> 
> > 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
> 
> 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