Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Jun 2006 07:43:21 -0700

Lou,

[since the answer to the question you posed below may benefit
other folks, I added mpls and ccamp mailing list to the cc:]

> Rahul,
>          Okay, so I'm just a bit slow.  Can you explain why the 
> semantics of P2MP-TE needs to be different than P2P-TE?
> 
> Yakov,
> 
> Perhaps you should answer this?
>
> Lou

To answer your question observe that in P2P-TE the Session object
carries IPv4 tunnel end point address, while in P2MP-TE the Session
object carried P2MP-ID.

Here are some of the reason(s) semantics of IPv4 tunnel end point
address needs to be different than P2MP-ID:

1. IPv4 tunnel end point address is a unicast address. P2MP-ID
is not. 

2. IPv4 tunnel end point address is suitable for hierarchical routing
(e.g., CIDR). P2MP-ID is not.

3. There are well-established procedures for assigining (globally)
unique unicast IP addresses. There are no such procedures for
assigining (globally) unique P2MP IDs.

Yakov.

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

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2006 11:03:03 -0400

Yakov,
         Thank you for the concise response to a question that has 
been outstanding for some time.  Now there are two specific aspects 
to the proposed response (Rahul's) to the issues you raise below:

1) Tunnel ID
[From rahul's mail]
  > 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."
  >

I don't see how this change, setting the ID to zero, relates to the 
issue you raise.  Can  justify why this change is required?

2) Extended Tunnel ID
[again from rahul's mail]

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

So the original text, allowed for global uniqueness and included a 
"well-established procedures for assigning (globally) unique" P2MP IDs.

It seems to me that the -05 text covered the issue you raised.  So 
now we come to the heart of the matter:  Why is a change in the -05 
definition of the IDs needed?

It seems to me that at most the text needs to replace a "may" with a 
"MUST", as in "Ingress nodes that wish to narrow the scope of a 
SESSION to the ingress-PID pair MUST place their..."

Lou

>other folks, I added mpls and ccamp mailing list to the cc:]

a bit unusual to redirect private mail, but whatever...

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Jun 2006 09:28:19 -0700

Lou,

> issue you raise.  Can  justify why this change is required?

This is orthogonal to the issue of P2MP ID uniqueness scope. 
  
> "well-established procedures for assigning (globally) unique" P2MP IDs.

Could you please point me to the text that spells out procedures
for assigning P2MP IDs that are globally unique *on their own* (not
in a combination with the Extended Tunnel ID).

> SESSION to the ingress-PID pair MUST place their..."

That is necessary, but not sufficient. Here are the changes that
need to be made:

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.

The last sentence above has to be deleted.

2. Section 19.1.1 replace:

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

with the following:

 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
      whose IP address is carried in the Extended Tunnel ID.

3. Section 19.1.1 replace

  Extended Tunnel ID

with the following:
 
  Extended Tunnel ID
 
       A 32-bit identifier used in the SESSION object that remains
       constant over the life of the P2MP tunnel.  Ingress nodes
       that use the locally scoped  P2MP ID MUST place their IPv4
       address here; a combination of this address and P2MP ID
       provides a globally unique identifier for the P2MP tunnel.
  
4. Make similar changes in 19.1.2

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2006 14:21:40 -0400

Yakov,
         See below.

>This is orthogonal to the issue of P2MP ID uniqueness scope.

okay, that's not how it's been presented.  What *is* the reason for 
this change?

>in a combination with the Extended Tunnel ID).

Ahh, good point, I was referring to the uniqueness of the tuple <P2MP 
ID, Tunnel ID, Extended Tunnel ID>. I must admit, I made the 
assumption that this is what you cared about for uniqueness.  Is this 
not the case?  If not, why is uniqueness of the tuple insufficient?

>The last sentence above has to be deleted.

why, what's incorrect about it?

>       whose IP address is carried in the Extended Tunnel ID.

Why not, just "Identifier that is unique within the scope of the Ingress LSR."?

How about:
>        that wish to a globally unique identifier for the P2MP tunnel
>MUST place their tunnel sender address here.

>4. Make similar changes in 19.1.2

yes.

Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Jun 2006 12:26:02 -0700

Lou,

> assumption that this is what you cared about for uniqueness.  

That is precisely what I care about. 

> Is this 

Uniqueness of the tuple is sufficient.
  
> why, what's incorrect about it?

To begin with, the last sentence states that the P2MP ID, *by itself*
"provides an identifier for the set of destinations of a given P2MP
TE Tunnel". However, since a given P2MP ID, *by itself*, may not
be unique, how could it unambiguously identify the set of destinations
of such tunnel ?

> Why not, just "Identifier that is unique within the scope of the 

That would be fine with me.
  
>          MUST place their tunnel sender address here.

The above will be ok if we'll add the following to spell out
what constitutes this (globally unique) identifier.

      A combination of this address and P2MP ID
      provides a globally unique identifier for the P2MP tunnel.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Jun 2006 13:37:01 -0700

Lou,

[clipped...]

> You are 100% correct, how about fixing it by saying:
> "The P2MP ID together with Tunnel ID, Extended Tunnel ID provide an 
> identifier for the set of destinations of the P2MP TE Tunnel."

Given that P2MP ID is unique within the scope of the root, why a
tuple <Extended Tunnel ID, P2MP ID> is not sufficient to identify
the set of destinations of a P2MP tunnel ? After all, you agreed
further down that such a tuple identifies a P2MP tunnel.

> > > >       P2MP Identifier that is unique within the scope of the Ingress
> > > >       LSR whose IP address is carried in the Extended Tunnel ID.
> > >
> great.
> Agreed!

Good, so we are in agreement that a combination of root node address
and P2MP ID forms a (globally unique) identifier for the P2MP tunnel.

> Much thanks,
> Lou
> 
> PS I assume there is no need to change the definition of Tunnel ID, correct?

Correct.

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2006 16:51:32 -0400

Yakov,

>further down that such a tuple identifies a P2MP tunnel.

Because this would preclude the use of tunnel ID to further partition 
the session space (as is done today for P2P-TE.)  The tuple I 
mentioned included all three.

Much thanks,
Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2006 16:08:21 -0400

Yakov,
         See below, I think we're almost there.

great.

Agreed!

Much thanks,
Lou

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 27 Jun 2006 14:59:21 -0700

Lou,

[clipped...]

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

You, yourself agreed that "A combination of this address and P2MP
ID provides a globally unique identifier for the P2MP tunnel."

Since the set of destinations of a P2MP tunnel is just a part of
the tunnel, identifying the tunnel should be sufficient in order
to identify the set of destinations.

Since a tuple <Extended Tunnel ID, P2MP ID> is sufficient to identify
the tunnel, the same tuple is sufficient to identify the set of
destinations of the tunnel. Therefore, the Tunnel ID is not
needed to identify the set of destinations of the tunnel.

Yakov.

P.S. I would also caution against trying to draw too much analogy
with the P2P tunnels. As I explained to you in one of my previous
e-mails, the semantics of some of the fields carried in the Session
object in P2MP tunnels is quite different from the semantics of
their counterparts in P2P tunnels.

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Jun 2006 22:01:37 -0400

Yakov,
         See below.

>ID provides a globally unique identifier for the P2MP tunnel."

Well actually my point was: "... the uniqueness of the tuple <P2MP 
ID, Tunnel ID, Extended Tunnel ID>. "

>to identify the set of destinations.

right, and all three fields are needed.

>needed to identify the set of destinations of the tunnel.

we disagree.

>their counterparts in P2P tunnels.

Sure, but you've not stated any reason or need to change the 
semantics wrt tunnel ID...

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 28 Jun 2006 14:07:31 +0100

Just FWIW

   P2MP-ID (P2ID):
      A unique identifier of a P2MP TE LSP, which is constant for the
      whole LSP regardless of the number of branches and/or leaves.

Extracted from RFC4461.
We do not have to use that description in the protocol fields, but if we 
choose not to, I suggest that we change the name of the field to avoid 
confusion.

Historically, the reason for the text "The P2MP ID provides an identifier 
for the set of destinations of the P2MP TE Tunnel." is that some folk hoped 
to use something akin to a group address in this space. Thus the tunnel 
would be identified by tunnel ID, extended tunnel ID and group destination 
address. Multiple tunnels to the same destination group address would have 
different tunnel IDs (if from the same sender) and could have different 
extended tunnel IDs (if the senders made that choice).

Adrian

----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 28, 2006 3:01 AM
Subject: [mpls] Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]

> Well actually my point was: "... the uniqueness of the tuple <P2MP ID, 
> Tunnel ID, Extended Tunnel ID>. "
>
> Sure, but you've not stated any reason or need to change the semantics wrt 
> tunnel ID...
>
> Lou
>

---

From: George Swallow <[email-masked]>
Date: Wed, 28 Jun 2006 15:11:24 -0400

> needed to identify the set of destinations of the tunnel.

I really don't understand this drive to change semantics that have been
stable since we began working on this draft, and that are consistent
with 3209 this late in the game.  I am TOTALLY opposed to it.

...George

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

---

From: George Swallow <[email-masked]>
Date: Wed, 28 Jun 2006 16:07:09 -0400

>       provides a globally unique identifier for the P2MP tunnel.

I want this to be the full tuple:

<P2MP ID, Tunnel ID, Extended Tunnel ID>

Further we should only be calling this a globally unique identifier of a
tunnel since the set of endpoint can change over the lifetime of the
tunnel.

...George

---

From: Lou Berger <[email-masked]>
Date: Wed, 28 Jun 2006 18:10:03 -0400

George,
         Glad to see I'm not the only one who holds this opinion!

Lou