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

From: Loa Andersson <[email-masked]>
Date: Sat, 13 May 2006 12:48:18 +0200

Working Group,

this initiates a two week working group last call on
draft-ietf-mpls-rsvp-te-p2mp-05.txt

please send comments to the MPLS working group mailling
list and/or working co-chairs.

The last call ends eob May 28th.

The ccamp mailing list copied as this is a work that has
an overlap between the working groups.

Loa and George

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                           [email-masked]

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 24 May 2006 08:34:52 -0700

Loa and George,

> an overlap between the working groups.

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.

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.

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.

Yakov.

---

From: Rahul Aggarwal <[email-masked]>
Date: Wed, 24 May 2006 09:34:26 -0700 (PDT)

Hi Yakov,

Thanks for the comments. Please see below:

> necessary and sufficient to identify a P2MP LSP.

Agreed.

> IP address, index> is unique within the same scope as the root node

Ok.

> The index is carried in the P2MP ID.

Ok.

> 3. Tunnel ID field should be set to all zeros, and be ignored on

Ok.

> (<root node IP address, index>), and LSP ID.

Ok.

> (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.

How about the following rephrasing:

1.

Section 4.1:

" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
   identified by a P2MP SESSION object. This object contains the
   identifier of the P2MP Session which includes the P2MP ID, a tunnel
   ID and an extended tunnel ID.

   The fields of a P2MP SESSION object are identical to those of the
   SESSION object defined in [RFC3209] except that the Tunnel Endpoint
   Address field is replaced by the P2MP Identifier (P2MP ID) field.

   The P2MP ID provides an identifier for the set of destinations of the
   P2MP TE Tunnel."

to

" A P2MP TE Tunnel comprises one or more P2MP LSPs. A P2MP TE Tunnel is
identified by a P2MP SESSION object. This object contains the
identifier of the P2MP Session which includes a tuple
<Ingress LSR IP address, P2MP Identifier>, where the P2MP Identifier (P2MP
ID) is unique within the scope of the IP address of the ingress LSR. The
Ingress LSR IP address is encoded in the Extended Tunnel ID. Th P2MP
Tunnel identifier, carried in the P2MP SESSION object, is unique within
the same scope as the ingress LSR IP address.

The fields of the P2MP SESSION object are identical to those of the
SESSION object defined in [RFC3209] except that the Tunnel Endpoint
Address field is replaced by the P2MP ID field."

2.

Section 4.2.

"   A P2MP LSP is identified by the combination of the P2MP ID, Tunnel
   ID, and Extended Tunnel ID that are part of the P2MP SESSION object,
   and the tunnel sender address and LSP ID fields of the P2MP
   SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
   defined in section 20.2."

to

"   A P2MP LSP is identified by the combination of the P2MP ID,
Extended Tunnel ID that are part of the P2MP SESSION object,
and the tunnel sender address and LSP ID fields of the P2MP
SENDER_TEMPLATE object. The new P2MP SENDER_TEMPLATE object is
defined in section 20.2."

3.

19.1.1

"P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP ID and identifies the set of destinations of the P2MP
      Tunnel."

to

"P2MP ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It encodes the
      P2MP Identifier that is unique within the scope of the Ingress LSR
      IP address carried in the Extended Tunnel ID.

4.
19.1.1

"Tunnel ID

      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel."

to

"Tunnel ID

      A 16-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. It SHOULD be set to 0
      by the ingress LSR and be ignored on receipt."

5.

"Extended Tunnel ID

 A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel.  Normally set to
      all zeros. Ingress nodes that wish to narrow the scope of a
      SESSION to the ingress-PID pair may place their IPv4 address
      here as a globally unique identifier [RFC3209]."

to

"Extended Tunnel ID

      A 32-bit identifier used in the SESSION object that remains
      constant over the life of the P2MP tunnel. This identifier
      MUST be set to the ingress LSR's IPv4 address."

6.

19.1.2

"This is same as the P2MP IPv4 LSP SESSION Object with the difference
   that the extended tunnel ID may be set to a 16 byte identifier
   [RFC3209]."

to

"This is same as the P2MP IPv4 LSP SESSION Object with the difference
   that the extended tunnel ID MUST be set to a 16 byte identifier that is
the ingress LSR's IPv6 address."

7.

19.2.1

" IPv4 tunnel sender address
            See [RFC3209]"

to"

"IPv4 tunnel sender address. This address MUST be the same as the address
in the Extended Tunnel ID field of the SESSION object."

8.

19.2.2

"IPv6 tunnel sender address
           See [RFC3209]"

to

"IPv6 tunnel sender address. This address MUST be the same as the address
in the Extended Tunnel ID field of the SESSION object."

Thanks,
rahul

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 May 2006 18:47:19 +0100

Hi Yakov,

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

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

> (c) semantics of the Tunnel ID IP address in the SENDER_TEMPLATE.

Cheers,
Adrian

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 24 May 2006 14:28:11 -0700

Adrian,

>    The P2MP ID provides an identifier for the set of destinations of the

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 ?

> If an implementation chose to set P2MP ID = Tunnel ID, I guess that would be 

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.

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 May 2006 12:08:50 +0100

Yakov,

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

> It would also rule out the ability to place a multicast IP address in

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

> node IP address both in the Extended Tunnel ID and in the Tunnel

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

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 28 May 2006 09:46:49 -0700

Adrian,

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

---

From: Loa Andersson <[email-masked]>
Date: Mon, 29 May 2006 23:22:44 +0200

All,

this closes the working group Last Call on
draft-ietf-mpls-rsvp-te-p2mp-05.txt

Could the authors/editors please summarize the comments and
document how they will be addressed.

Loa and George

-- 
Loa Andersson

---

From: Rahul Aggarwal <[email-masked]>
Date: Tue, 30 May 2006 08:47:58 -0700 (PDT)

Hi Loa,

> document how they will be addressed.

We will plan to do this by end of the week.

Thanks,
Editors

> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mpls
>

---

From: George Swallow <[email-masked]>
Date: Tue, 30 May 2006 15:40:49 -0400

> node IP address both in the Extended Tunnel ID and in the Tunnel

If you wish to use bypass FRR, you will do exactly this.  The Extended
Tunnel ID is meant to provide a means of making the Session globally
unique.  An intermediate node that wishes to merge back into an existing
tunnel over a bypass tunnel uses it's own IP address in the sender field
and the existant Session Object.  If the session object were not unique
then this would be very hit or miss!

Personally I would like to see the text with ^^^^ removed from the
draft.  It was carried over from 3209 which was written prior to the FRR
draft.

>          over the life of the tunnel.  Normally set to all zeros.
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^

If we ever get around to pushing 3209 to Draft Standard I'll take it out
of there as well.

...George

========================================================================
George Swallow             Cisco Systems                  (978) 936-1398
                           1414 Massachusetts Avenue
                           Boxborough, MA 01719