The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title		: Extended RSVP-TE for Multicast LSP Tunnels
> 	Author(s)	: S. Yasukawa et al.
> 	Filename	: draft-yasukawa-mpls-rsvp-multicast-00.txt
> 	Pages		: 39
> 	Date		: 26-Jun-02

Since Seisho Yasukawa has explicitly asked for comments.....

In my opinion, this draft is not necessary.  It is based on the 
incorrect assumption that RSVP-TE, as it is currently defined, does not 
have supprort for multicast.

Classical RSVP was designed around multicast, and RSVP-TE introduces 
nothing to change this, even though it does not explicitly describe a 
multicast implementation.

For a multicast LSP, one has only to specify a multicast group address 
in the SESSION object (the tunnel endpoint address), and do not include 
an EXPLICIT_ROUTE object.  Normal Path processing should propagate the 
Path message to all next-hops in the multicast group, according to the 
multicast table that already exists.

When Resv messages return, the FLOWSPEC values are merged according to 
the rules for classical RSVP (RFC 2205 and related documents).  Incoming 
LABEL objects are installed on the next-hop interfaces.  One label is 
generated to send upstream - using the merged FLOWSPEC object.

I am aware that RSVP-TE's definition of EXPLICIT_ROUTE and RECORD_ROUTE 
does not accommodate multicast.  If there is some need to specify an 
explicit multicast tree that differs from the multicast routing table, 
then this might be required.

Personally, I think attempting to traffic-engineer a multicast tree 
beyond what existing multicast routing protocols already do is 
pointless.  Any automatic process for generating these trees will 
duplicate all of the work that routing protocols already do.  Any manual 
process will be unmanageable, since receivers may be continuously 
joining and leaving the multicast group.

Given the infeasability of a manually-configured multicast LSP, we're 
back to automatic configuration.  RSVP, as it currently stands, is 
sufficient in this situation.  It reads the existing multicast routing 
table to determine the next-hops for a multicast group, and monitors the 
routing table to add and remove next-hops as needed.  Rules for merging 
FLOWSPEC objects are already in place.  Rules for merging labels are 
self-evident.

While it is true that current RSVP-TE implementations do not have 
support for multicast LSPs, there is nothing in RFC 3209 that prohibits 
the use of RSVP-TE for multicast situations.  Note that the only part of 
RSVP-TE that is not multicast-friendly is the EXPLICIT_ROUTE object - 
ant this object is optional in Path messages anyway.

-- David