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

["Zafar Ali \(zali\)" <zali@cisco.com>]

> -----Original Message-----
> From: owner-ccamp@ops.ietf.org 
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Yakov Rekhter
> Sent: Sunday, May 28, 2006 12:47 PM
> To: Adrian Farrel
> Cc: Loa Andersson; mpls@ietf.org; ccamp; George Swallow 
> (swallow); Deborah Brungard; Ross Callon; Bill Fenner
> Subject: Re: working group last call on 
> draft-ietf-mpls-rsvp-te-p2mp-05.txt 
> 
> Adrian,
> 
> > >> > Few observations and suggestions...
> > >> >
> > >> > (a) <Ingress LSR IP address, P2MP ID> tuple is both 
> necessary and 
> > >> > sufficient to unambiguously identify a P2MP Tunnel.
> > >> >
> > >> > (b) Further <Ingress LSR IP address, P2MP ID, LSP ID> is both 
> > >> > necessary and sufficient to identify a P2MP LSP.
> > >>
> > >> 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  

> 
> Yakov.
>