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

From: Richard Li <[email-masked]>
Date: Wed, 17 Jul 2013 15:38:41 +0000

Hi All!

We have updated our receiver-driven RSVP-TE draft. Your comments will be highly appreciated.

Regards,

Richard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, July 01, 2013 6:17 AM
To: Telus Communications; Christian Jacquenet; Eduard Metz; Boris Zhang; Quintin zhao; Richard Li
Subject: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt

A new version of I-D, draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt
has been successfully submitted by Renwei Li and posted to the IETF repository.

Filename:	 draft-lzj-mpls-receiver-driven-multicast-rsvp-te
Revision:	 03
Title:		 Receiver-Driven Multicast Traffic-Engineered Label-Switched Paths
Creation date:	 2013-07-01
Group:		 Individual Submission
Number of pages: 24
URL:             http://www.ietf.org/internet-drafts/draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt
Status:          http://datatracker.ietf.org/doc/draft-lzj-mpls-receiver-driven-multicast-rsvp-te
Htmlized:        http://tools.ietf.org/html/draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03
Diff:            http://www.ietf.org/rfcdiff?url2=draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03

Abstract:
   This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the setup of Receiver-Driven
   Traffic-Engineered point-to-multipoint (P2MP) and multipoint-to-
   multipoint (MP2MP)Label Switched Paths (LSPs) in Multi-Protocol Label
   Switching (MPLS) and Generalized MPLS (GMPLS)networks.

The IETF Secretariat

---

From: John E Drake <[email-masked]>
Date: Thu, 18 Jul 2013 11:49:38 +0000

Richard,

If one wanted to support leaf-initiated join, why wouldn't one simply have the leaf send a notification (e.g., Notify) to the root requesting it to extend the p2mp tree to the leaf using the existing P2MP procedures?  The authors of RFC4875 expected an application level notification to produce exactly this behavior.

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Li
> Sent: Wednesday, July 17, 2013 8:39 AM
> To: [email-masked]
> Subject: [mpls] FW: New Version Notification for draft-lzj-mpls-
> receiver-driven-multicast-rsvp-te-03.txt
> 
> Hi All!
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Richard Li <[email-masked]>
Date: Fri, 19 Jul 2013 00:24:51 +0000

Hi John,

Technically you certainly can do it that way. But if you do so, you would either need a new protocol or change an existing protocol for the purpose of notification. 

On the other hand, in IP/PIM it is well and widely accepted that multicast distribution trees are built up from the leaf to root. 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.

In addition, the receiver-driven RSVP-TE also has additional benefits with respect to MP2MP. Otherwise one need a full-meshed P2MP trees to implement MP2MP.

Regards,

Richard

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 18, 2013 7:50 PM
To: Richard Li; [email-masked]
Subject: RE: [mpls] FW: New Version Notification for draft-lzj-mpls-receiver-driven-multicast-rsvp-te-03.txt

Richard,

Yours Irrespectively,

John

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Richard Li
> A new version of I-D, 
> draft-lzj-mpls-receiver-driven-multicast-rsvp-te-
> 03.txt

---

From: John E Drake <[email-masked]>
Date: Fri, 19 Jul 2013 13:12:27 +0000

Yours Irrespectively,

John

> From: Richard Li [mailto:[email-masked]]
> Sent: Thursday, July 18, 2013 5:25 PM
> To: John E Drake; [email-masked]
> Technically you certainly can do it that way. But if you do so, you
> would either need a new protocol or change an existing protocol for the
> purpose of notification.

JD:  Okay, so we agree that your draft is unnecessary.  Further, Notify is not a new protocol whereas you are actually proposing two new protocols.  Viz, the one documented in your draft, which is the complete antithesis of standard RSVP-TE, and the undocumented one, which is how the receivers learn about the P2MP session in the first place.

> 
> On the other hand, in IP/PIM it is well and widely accepted that
> multicast distribution trees are built up from the leaf to root. 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.

JD:  As you agreed, the notification message would provide this synthesis. 

> 
> In addition, the receiver-driven RSVP-TE also has additional benefits
> with respect to MP2MP. Otherwise one need a full-meshed P2MP trees to
> implement MP2MP.

JD:  From my reading of the draft, MP2MP support appears to be an assertion.

> If one wanted to support leaf-initiated join, why wouldn't one simply
> have the leaf send a notification (e.g., Notify) to the root requesting
> it to extend the p2mp tree to the leaf using the existing P2MP
> procedures?  The authors of RFC4875 expected an application level
> notification to produce exactly this behavior.
> 
> Yours Irrespectively,
> 
> John
> 
> >    This document describes extensions to Resource Reservation
> Protocol
> > -

---

From: Eric Rosen <[email-masked]>
Date: Fri, 19 Jul 2013 15:02:12 -0400

> 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?