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 ?

> And this means that there is not a one-to-one relationship between P2MP ID 
> and P2MP Tunnel even within the scope of a single ingress.
> 
> Although this was debated (the ingress could uniquely assign one ID per 
> tunnel) we recognized:
> 
> i. The Tunnel ID field already performs this function
> ii. It may be desirable to identify common sets of destinations
> 
> The best example of ii. that was discussed would allow you to place a 
> multicast IP address in the P2MP ID field. This is not mandatory (and some 
> people think it is a bad idea :-), but the specification was designed to 
> allow it.
> 
> If an implementation chose to set P2MP ID = Tunnel ID, I guess that would be 
> very fine with everyone.

For one thing, this would limit the number of tunnels that could be
originated by a particular root node to 2^16. 

It would also rule out the ability to place a multicast IP address in
the P2MP ID field.

> > 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.
> 
> I don't believe we should force the Extended Tunnel ID like this when an 
> existing RFC defines another use albeit in the P2P context.

What are exactly the (practical) problems with carrying the root
node IP address both in the Extended Tunnel ID and in the Tunnel
Sender Address fields ?

Yakov.