Subject: Re: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt

From: Quintin Zhao <[email-masked]>
Date: Mon, 22 Jul 2013 20:10:29 -0400

Hi Eric,

This is the requirement draft that documents the requirements and user cases
for receiver driven multicast RSVP-TE:
http://datatracker.ietf.org/doc/draft-jacquenet-mpls-rd-p2mp-te-requirements
/

Here let me elaborate a little more on the purpose of the receiver driven
multicase rsvp te.

mLDP has the advantage of a receiver-driven tree setup protocol, where it
scales independently of the number of receivers joining the tree, but it
doesn't provide both the traffic engineering and bandwidth guarantees.

RSVP-TE P2MP has the advantage of both traffic engineering and bandwidth
guarantees, but it is not flexible when the number of receivers joining the
tree increases.

Instead of deploying both the mLDP and RSVP-TE P2MP in the network to have
the scalability for some applications, the traffic engineering and the
bandwidth guarantees for some applications, it would be good for users to
have one protocol deployed, with said protocol having both the advantages of
mLDP and RSVP-TE P2MP. This is what receiver driven multicast rsvp is trying
to solve.

Regards,
Quintin

----------------------------------------------------------------------

Message: 1
Date: Fri, 19 Jul 2013 15:02:12 -0400
From: Eric Rosen <[email-masked]>
To: Richard Li <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [mpls] FW: New Version Notification for
	draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt
Message-ID: <16359.1374260532@erosen-linux>

> But in MPLS, the multicast distribution tree (LSP) are built in a 
> totally different ordering. I am always struggling with why MPLS 
> should be doing it in a different way from PIM. If would be nice if 
> MPLS could unify with PIM with respect to MDT build-ups.

Please see RFC 6388 (mLDP), which explains how to do receiver-driven tree
setup for MPLS.

The advantage of receiver-driven tree setup protocols is that they scale
independently of the number of receivers that join the tree.  That's because
each node on the tree knows only about the nodes that are one hop away.
This is the design center of PIM-SM -- the number of receivers joining the
tree can increase without bound.

The advantage of a head-end-driven tree setup protocol (like RSVP-TE P2MP)
is that the head-end knows all the nodes on the tree, and thus can set up a
more optimal tree.  You probably wouldn't do this in an environment where
the number of receivers can increase without bound.

In that light, a receiver-driven version of RSVP-TE just doesn't seem to
make much sense.  What problem does it actually solve?