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

["Igor Bryskin" <ibryskin@movaz.com>]

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" <yakov@juniper.net>
To: "Lou Berger" <lberger@labn.net>
Cc: "Rahul Aggarwal" <rahul@juniper.net>; <p2mp@labn.net>; <mpls@ietf.org>;
<ccamp@ops.ietf.org>
Sent: Wednesday, July 05, 2006 3:18 PM
Subject: Re: draft-ietf-mpls-rsvp-te-p2mp-06.txt [P2MP ID]


> Lou,
>
> > 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?
>
> 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.
>