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

[Yakov Rekhter <yakov@juniper.net>]

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.