Subject: [mpls] Identifier Semantics [Re: working group last call on draft-ietf-mpls-rsvp-te-p2mp-05.txt]

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 22 Jun 2006 11:18:22 -0700 (PDT)

Hi Folks,

Yakov brought up the issue of P2MP ID, Tunnel ID, Extended Tunnel ID
semantics as part of the last call and a discussion followed on this list.

In order to resolve this discussion I had proposed some text. I have
received some comments on this offline and want to move this discussion to
a broader audience.

Please comment on the text changes below, if you have objections or
suggestions. Else this will be incorporated in the next version of the
spec.

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

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

---

From: Lou Berger <[email-masked]>
Date: Thu, 22 Jun 2006 15:10:18 -0400

All,

Here's one (but not the only) comment that was made off list.  Also 
there were already several comments made on these points on the list.

My comment still applies, and please consider this as an "objection" 
to the proposed text:

At 01:20 PM 6/22/2006, Lou Berger wrote:
>[...]
>At 05:23 PM 6/20/2006, Rahul Aggarwal wrote:
>>Hi All,
>>
>>Attached is draft-ietf-mpls-rsvp-te-p2mp-06.txt that incorporates changes
>>to address Last call comments.
>>
>>Please let me know if you have any comments on *only the changes made to
>>address LC comments* i.e. diff of v05 and v06 by this Friday.
>>
>>A brief summary of changes:
>>
>>1. Editorial changes requested by Benjamin Niven - see MPLS mailing list.
>>2. Several editorial and non editorial changes requestd by Adrian Farrel -
>>see MPLS mailing list for Adrian's comments and my response. There may be
>>one or two open items here. Once Adrian looks at my response these should
>>be resolved quickly.
>>3. Several editorial and non-editorial changes requestd by JL - see MPLS
>>mailing list for JL's comments and my response.
>>4. Clarification of tunnel ID and extended Tunnel ID semantics as
>>requested by Yakov Rekhter and follow on comments by Zafar Ali and George
>>Swallow.
>

The objection:

>I don't have any issues with the changes mentioned by Zafer and 
>George, but I didn't see closure on the issue debated by Adrian and 
>Yakov.  Specifically on the issue of if extended tunnel ID had to 
>equal the node ID of the sender.  I did see a position state, that I 
>too agree with, i.e., that  it should be permitted and may be 
>required in some environments (e.g., FRR) but may not be required in 
>all environments so should be left as before.  Also, as I read the 
>mails most were in favor of leaving tunnel ID as is, i.e., not 
>requiring it to be set to zero.  This doesn't match what was done in 
>this past rev.

In summary, my position is:
1) That the extended tunnel ID remain as defined in the previous 
version, i.e., retain the semantics from rfc3209/rfc3473.  I think 
adding a restriction for environments where FRR is used is 
acceptable.  (This spec covers GMPLS and non-packet environments too!)
2) That Tunnel ID remain as defined in previous version, i.e., retain 
the semantics from rfc3209/rfc3473.

The specifics of the text below is dependent on consensus on these points.

Lou

---

From: [email-masked]
Date: Fri, 23 Jun 2006 13:43:47 +0200

lou, all, see in-line

Lou Berger <[email-masked]>
22/06/2006 21:10
 
        To:     Rahul Aggarwal <[email-masked]>
        cc:     [email-masked], [email-masked], 
[email-masked], ccamp <[email-masked]>
        Subject:        Re: [mpls] Identifier Semantics [Re: working group 
last call       on draft-ietf-mpls-rsvp-te-p2mp-05.txt]

>The specifics of the text below is dependent on consensus on these 
points.

[dp] if there is no Tunnel ID (or a single fixed value for the Tunnel ID), 
there is no possibility to instantiate multiple trunks per destination 
(set of destinations)

now there is a more fundamental issue: what is the purpose of the initial 
comment, i think it is first to clarify  processing of Tunnel ID and 
Extended Tunnel ID but i don't think i have seen any specific issue in 
keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473

i am deeply concerned about having moving definition departing from base 
RSVP-TE on objects that are fundamental for the stability of the protocol

thanks,
- dimitri.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 26 Jun 2006 06:49:34 -0700

Dimitri,

[clipped...]

> > keeping usage of the Tunnel ID & Extended Tunnel ID per RFC 3209/3473

The purpose of the initial comment is to clarify the definition
of P2MP ID.

The current spec said the following (Section 19.1.1):

 P2MP ID

      Tunnel.

What is the uniqueness scope of this 32 bit identifier ? Is it the
root node scope, or a global scope ?

At the minimum the spec should spell out support for the root node 
uniqueness scope.

If some folks want the spec to support global scope, then it has
to be an option (in which case the root node scope will be another
option), *and* the spec has to spell out the procedures for assigining
such globally unique P2MP IDs (in the absence of such procedures
the spec should just have the root node uniqueness scope).

Yakov.