The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Jan> msg00146



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

draft-yasukawa-mpls-rsvp-p2mp-00.txt

  • From: Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>
  • Date: Wed, 29 Jan 2003 19:35:57 +0900
  • Cc: mpls@UU.NET, "LARREUR-HEMON Elodie FTRD/DAC/LAN" <elodie.larreur@rd.francetelecom.com>, swallow@cisco.com

Hello George,

I understand your concern about our P2MP draft.
Let me explain our intention and understanding again.

When we propose this draft, we are not intending to develop a new
multicast protocol over conventional RSVP-TE framework.

I think, defining multicast protocol requires
a mechanism which calculates multicast tree in itself.
But our proposed draft doesn't have such a mechanism in itself.

In our design, TERO (Tree Explicit Object) is introduced and
P2MP LSP is established using TERO.
This TERO represents P2MP LSP topology but it is provided by
external mechanism (e.g. NW management system).

In this way, our protocol doesn't define multicast tree calculation
mechanism in protocol itself as multicast protocol do.

And we evaluate that this extension is consistent with TE
extension to RSVP (RSVP-TE) and in the scope of RSVP-TE
extension.

So we think this is acceptable and in the scope of the
MPLS wg.

And we want to discuss this extension at MPLS wg
because we think this wg is most appropriate place
when considering situation discussed over the thread
on IANA Considerations for RSVP.

But I totally agreed with you in the point that introducing Join/Leave
mechanism might enhance the function exceeding the scope of
MPLS wg.

We want to know what modification is required to our draft
in order to fit in the scope.
We will modify our specification if necessary because we want
this technology.

And we want to know how should we process this work in this wg.

It is very helpful for us if you or anybody in this list give us some
suggestion to these issues.

Thanks,

Seisho


>I very much agree. This draft is not simply an extension to RSVP for
>multicast tunnels.  It actually defines a new multicast protocol.
>
>As such it is:
>
>    a) a mis-use of RSVP (note the thread on IANA Considerations for
>       RSVP)
>
>    b) not completely in the scope of the MPLS wg.
>
>While the MPLS wg can look for ways to support multicast, it is not
>now (or ever likely to be) in the charter of the workgroup to define a
>new multicast protocol.
>
>RSVP should simply be used to build the tree.  All of the join/leave
>activity belongs in a multicast protocol.
>
>...George
>
>==================================================================
>George Swallow       Cisco Systems                  (978) 497-8143
>                      250 Apollo Drive
>                      Chelmsford, Ma 01824