[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt
Hi 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.
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.
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.
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.
Cheers,
Adrian