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

From: Lou Berger <[email-masked]>
Date: Wed, 05 Jul 2006 11:09:44 -0400

At 10:39 AM 7/5/2006, Yakov Rekhter wrote:
>Could you please provide *technical* reason(s) that would explain why
>a combination of P2MP ID and Extended Tunnel ID is not sufficient ?
>
>Yakov.

Yakov,
         Simply, because that's the way MPLS and GMPLS is specified 
today and works in running code.

If you want to change something from the way it works today, i.e, in 
RFC3209 and 3473 (and really 2205), IMO it's incumbent on you to 
justify why what's there needs to be changed.  The case has been made 
for why the session object must use a P2MP ID rather than a 
destination IP address.  The case has not been made for changing the 
definition or semantics of Tunnel ID.

Can provide the justification of why we need to deviate from current 
specs on definition of Tunnel ID?

Lou

---

From: George Swallow <[email-masked]>
Date: Wed, 05 Jul 2006 12:08:40 -0400

> specs on definition of Tunnel ID?

Absolutely.  We didn't start with a blank piece of paper.  We're
building on existing things.  So the onus for argument, should you
choose to pursue it, is in your court.

...George

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

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 05 Jul 2006 07:39:44 -0700

Lou,

> >[clipped...]
> >
> > > > > > > >    The P2MP ID provides an identifier for the set of
> > > > > > > >    destinations of the P2MP TE Tunnel.
> > > > > > > >
> > > > > > > >The last sentence above has to be deleted.
> > > > > > >
> > > > > > > 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 ?
> > > > >
> > > > > 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.
> > >
> > > 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.
> >
> >You, yourself agreed that "A combination of this address and P2MP
> >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>. "
>
> >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.
> 
> right, and all three fields are needed.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 05 Jul 2006 12:18:13 -0700

Lou,

> specs on definition of Tunnel ID?

Are you saying that the only reason we have to use Tunnel ID as
part of a p2mp tunnel identifier is because Tunnel ID is used as
part of a p2p tunnel identifier ?

Yakov.

---

From: Lou Berger <[email-masked]>
Date: Thu, 06 Jul 2006 10:57:04 -0400

Yakov,

>part of a p2p tunnel identifier ?

I didn't say that.  What I said is the same thing that George said: 
That the onus is on you to state why we should deviate from current 
spec and practice.

If you care to, can you articulate any reason to justify this 
change?  If not, we should leave the definition unchanged and move on.

Lou

---

From: "Igor Bryskin" <[email-masked]>
Date: Thu, 6 Jul 2006 17:11:21 -0400

Yakov,

Let's discuss some practical issues.

Suppose, I (as a operator or a management application) decided to change a
root of an existing P2MP tunnel (perhaps, because it has crashed) while
maintaining the same set of receivers. Rather than re-signaling entire
tunnel, I'd rather issue a P2MP Path message from a new root that will
modify the head of the tunnel- the rest of the tunnel will see this
operation as a MBB procedure with no modifications in the data plane. Note
that this would be possible with the P2MP tunnel identification suggested by
the draft and won't be possible with your scheme.

Furthermore, a P2MP tunnel could be built of multiple P2MP LSPs originated
not necessarily on the tunnel root. Once we discussed with Kireeti a
hierarchical P2MP tunnel. Suppose a tunnel needs to support 10000 leaves.
The root of the tunnel can originate a P2MP LSP to 100 (intermediate)
leaves, each of which could originate a P2MP LSP of it's own to 100  leaves.
It should be a very scalable approach because the root does not need to know
about all 10000 leaves (neither a leaf needs to know about the identity of
the tunnel root). In order to make this work we need to identify the tunnel
independently from the root.

So, I vote to keep the tunnel identification as it is described in the
draft.

Igor

----- Original Message ----- 
From: "Yakov Rekhter" <[email-masked]>
To: "Lou Berger" <[email-masked]>
Cc: "Rahul Aggarwal" <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, July 05, 2006 3:18 PM
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]