The MPLS WG Archive

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



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

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

  • From: George Swallow <swallow@cisco.com>
  • Date: Tue, 28 Jan 2003 10:56:31 -0500
  • cc: "Seisho Yasukawa" <yasukawa.seisho@lab.ntt.co.jp>, mpls@UU.NET, "LARREUR-HEMON Elodie FTRD/DAC/LAN" <elodie.larreur@rd.francetelecom.com>, swallow@cisco.com

> Hi Seisho and all
> 
> We read your draft with much interest, and consider this is a good
> approach for multicast MPLS-TE tunnels.
> 
> We have several comments regarding leaf initiated Joining/pruning
> procedures, and the interaction with access multicast protocols like
> IGMP :
> 
> Why does the Join/ leave messages contain the attributes of the P2MP
> tunnel (Session, and Sender objects) ? 
> This requires a mechanism for the Join leaf node to dynamicaly learn
> these attributes.
> 
> To our mind, it could be more relevant to include (S,G) or (*, G),or
> ({S}, {G}) in Join /Leave messages, rather than tunnel parameters. Then
> the sender would have knowledge of (S, G) localization, and could
> optimise P2MP utilisation (FEC) based on this information.
> 
> In this scenario, the sender would have to maintain a table indicating
> the registered (S, G) attached to each leaf node.
> When a potential leaf node receives an IGMPv3 report message for a new
> (S, G), it checks if it already receives this (S, G), if no it sends a
> Join message to the sender node, including the (S, G). Then the sender
> can either graft an existing P2MP tunnel, or create a new tunnel to
> reach this leaf node, depending on local optimization criteria.

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