Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt

From: [email-masked]
Date: Tue, 16 Nov 2004 16:13:33 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF.

	Title		: Extensions to RSVP-TE for Point to Multipoint TE LSPs
	Author(s)	: R. Aggarwal, et al.
	Filename	: draft-ietf-mpls-rsvp-te-p2mp-00.txt
	Pages		: 45
	Date		: 2004-11-16
	
This document describes extensions to Resource Reservation Protocol -
   Traffic Engineering (RSVP-TE) for the setup of point-to-multipoint
   (P2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching
   (MPLS) and Generalized MPLS (GMPLS) networks.  The solution relies on
   RSVP-TE without requiring a multicast routing protocol in the Service
   Provider core. Protocol elements and procedures for this solution are
   described. There can be various applications for P2MP TE LSPs such as
   IP multicast. Specification of how such applications will use a P2MP
   TE LSP is outside the scope of this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-rsvp-te-p2mp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-rsvp-te-p2mp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: lidefeng <[email-masked]>
Date: Thu, 18 Nov 2004 14:42:42 +0800

In section 3.4 of draft-ietf-mpls-rsvp-te-p2mp-00.txt, it says that "All LSRs need to  process the ERO corresponding to the first P2P sub-LSP. A LSR needs  to process a P2P sub-LSP descriptor for a subsequent P2P sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of a SERO propagates the   corresponding P2P sub-LSP downstream."

Does  it mean that an LSR received the Path message with one ERO and several SEROs, if all the SEROs don't include this particular LSR, this particular need't process all these SEROs? For example,  In the case of the p2mp tree of figure 1 in draft-ietf-mpls-rsvp-te-p2mp-00.txt, LSR H encode the P2P sub-LSP explicit  routes in the Path message sent to LSR I:
      P2P sub-LSP-Q:   ERO = {I, M, Q}, P2P_SUB_LSP Object-Q,
      P2P sub-LSP-R:   SERO = {Q, R}, P2P_SUB_LSP Object-R,

then, LSR I need only process "P2P sub-LSP-Q:   ERO = {I, M, Q}, P2P_SUB_LSP Object-Q,", needn't process "P2P sub-LSP-R:   SERO = {Q, R}, P2P_SUB_LSP Object-R,"? if it is right, what is the justification to carry the SERO?

And what does "The branch LSR that is the first hop of a SERO propagates the   corresponding P2P sub-LSP downstream." mean? it means that LSR Q propagates the  corresponding P2P sub-LSP downstream when LSR I receives the Path message sented by LSR H? and it is clear that at this time LSR Q doesn't receive the Path message yet, how can it propogate the P2P sub-LSP downstream? Or this sentence means something else? 

Regards

Defeng Li

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, November 17, 2004 5:13 AM
Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt

> implementation to automatically retrieve the ASCII version of the

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

---

From: Seisho Yasukawa <[email-masked]>
Date: Thu, 18 Nov 2004 17:17:09 +0900

Hi,

Thank you for your comments.
Please find my comments and answers belows.

At 14:42 04/11/18 +0800, lidefeng wrote:
>In section 3.4 of draft-ietf-mpls-rsvp-te-p2mp-00.txt, it says that "All 
>LSRs need to  process the ERO corresponding to the first P2P sub-LSP. A 
>LSR needs  to process a P2P sub-LSP descriptor for a subsequent P2P 
>sub-LSP only if the first hop in the corresponding SERO is a local address 
>of that LSR. The branch LSR that is the first hop of a SERO propagates the 
>corresponding P2P sub-LSP downstream."
>
>Does  it mean that an LSR received the Path message with one ERO and 
>several SEROs, if all the SEROs don't include this particular LSR, this 
>particular need't process all these SEROs?

No.
Please see below marked **.
We describe detail SEROs operation in section 6.2.

"
6.2. Multiple P2P Sub-LSPs in one Path message

[snip]

    All LSRs need to process, when it is present, the ERO corresponding
    to the first P2P sub-LSP. If one or more SEROs are present an ERO
    must be present.  The first P2P sub-LSP is propagated in a Path
    message by each LSR along the explicit route specified by the ERO.

    A LSR needs to process a P2P sub-LSP descriptor for a subsequent P2P
    sub-LSP only if the first hop in the corresponding SERO is a local
    address of that LSR.

***
    If this is not the case the P2P sub-LSP
    descriptor is included in the Path message sent to LSR that is the
    next hop to reach the first hop in the SERO. This next hop is
    determined by using the ERO or other SEROs that encode the path to
    the SERO's first hop.

    If this is the case and the LSR is also the
    egress the P2P sub-LSP descriptor is not propagated downstream. If
    this is the case and the LSR is not the egress the P2P sub-LSP
    descriptor is included in a Path message sent to the next-hop
    determined from the SERO. Hence a branch LSR only propagates the
    relevant P2P sub-LSP descriptors on each downstream link. A P2P
    sub-LSP descriptor that is propagated on a downstream link only contains
    those P2P sub-LSPs that are routed using that link. This processing
    may result in a subsequent P2P sub-LSP in an incoming Path message to
    become the first P2P sub-LSP in an outgoing Path message.
"

>For example,  In the case of the p2mp tree of figure 1 in 
>draft-ietf-mpls-rsvp-te-p2mp-00.txt, LSR H encode the P2P sub-LSP explicit 
>routes in the Path message sent to LSR I:
>then, LSR I need only process "P2P sub-LSP-Q:   ERO = {I, M, Q}, 
>P2P_SUB_LSP Object-Q,", needn't process "P2P sub-LSP-R:   SERO = {Q, R}, 
>P2P_SUB_LSP Object-R,"? if it is right, what is the justification to carry 
>the SERO?

Please see above.

>And what does "The branch LSR that is the first hop of a SERO propagates 
>the   corresponding P2P sub-LSP downstream." mean?

This is also described in above section.
Actually a branch LSR is branch point(s) of the P2MP LSP.
So it always guarantees existence of SERO(s) in our scheme.

Therefore, in our scheme, branch node must
1) convert SERO(s) to ERO(s)
2) divide received SEROs into multiple SEROs which correspond
to multiple downstream portion of sub P2MP LSPs.

Note there are several schemes to divide SEROs information easily
and we are now discussing these schemes.

Hope above explanation would help your understanding.

Regards,
Seisho

>it means that LSR Q propagates the  corresponding P2P sub-LSP downstream 
>when LSR I receives the Path message sented by LSR H? and it is clear that 
>at this time LSR Q doesn't receive the Path message yet, how can it 
>propogate the P2P sub-LSP downstream? Or this sentence means something else?
>
>Regards
>
>Defeng Li
>
>
>
>