The MPLS WG Archive

[Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>]

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

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
>
>
>
>
>----- Original Message -----
>From: <Internet-Drafts@ietf.org>
>To: <i-d-announce@ietf.org>
>Cc: <mpls@ietf.org>
>Sent: Wednesday, November 17, 2004 5:13 AM
>Subject: [mpls] I-D ACTION:draft-ietf-mpls-rsvp-te-p2mp-00.txt
>
>
> > 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
> > i-d-announce-request@ietf.org 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:
> > mailserv@ietf.org.
> > 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
> > mpls@lists.ietf.org
> > https://www1.ietf.org/mailman/listinfo/mpls
> >
>
>_______________________________________________
>mpls mailing list
>mpls@lists.ietf.org
>https://www1.ietf.org/mailman/listinfo/mpls



_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls