The MPLS WG Archive

["Adrian Farrel" <adrian@olddog.co.uk>]

Yakov,

>> > 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.

>> 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.

Well, we already have the 2^16 limit for P2P tunnels. Are people running up 
against this limit?
This can easily be seen as a separate set of 2^16 tunnels because a 
different object is used to encode the information, but this is a point that 
should definitely be clarified in the I-D: what is the relationship between 
the Tunnel IDs in P2P and P2MP Sessions?

You're right that an implementation that sets P2MP ID = Tunnel ID cannot 
also set P2MP ID = multicast IP address.
Whether this discussion is even meaningful depends on whether the scope of 
the P2MP ID uniqueness is global (can't use Tunnel ID) or ingress (can use 
Tunnel ID, or multicast address, or timestamp, or anything).

>> > 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 ?

You cannot do Session-based resource sharing across multiple sources.
If you recall, RFC3209 says:
   To uniquely
   identify a TE tunnel, we use the combination of the destination IP
   address (an address of the node which is the egress of the tunnel), a
   Tunnel ID, and the tunnel ingress node's IP address, which is placed
   in the Extended Tunnel ID field.
which supports what you say, but also:
      Extended Tunnel ID
         A 32-bit identifier used in the SESSION that remains constant
         over the life of the tunnel.  Normally set to all zeros.
         Ingress nodes that wish to narrow the scope of a SESSION to the
         ingress-egress pair may place their IPv4 address here as a
         globally unique identifier.

Is there any *practical* impact? Well, *if* the two fields are always going 
to carry the same information, clearly the second field is redundant. If the 
field is redundant, it can be used for other purposes if and when they are 
found. If that is the case, don't force it to be set to an irrelevant value 
in this I-D.

Cheers,
Adrian 



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls