--- 1/draft-ietf-mpls-p2mp-te-bypass-01.txt 2008-02-27 21:12:25.000000000 +0100 +++ 2/draft-ietf-mpls-p2mp-te-bypass-02.txt 2008-02-27 21:12:25.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group J.L. Le Roux (Ed.) Internet Draft France Telecom Category: Standard Track -Expires: January 2008 R. Aggarwal +Expires: August 2008 R. Aggarwal Juniper Networks J.P. Vasseur Cisco Systems, Inc. M. Vigoureux Alcatel-Lucent P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels - draft-ietf-mpls-p2mp-te-bypass-01.txt + draft-ietf-mpls-p2mp-te-bypass-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -213,21 +213,21 @@ LSPs of a given backup P2MP LSP, tunneled within the same P2MP Bypass Tunnel. This backup label will indicate to the Merge Points that packets received with that label should be switched along the protected P2MP LSP. For that purpose upstream label assignment procedures defined in [MPLS-UPSTREAM] and RSVP-TE extensions for upstream label assignment defined in [RSVP-UP] MUST be used. To signal a backup P2MP LSP, the same backup label, is distributed by the PLR to all MPs belonging to a same P2MP Bypass Tunnel, in the context of this P2MP Bypass Tunnel. - This requires the backup P2MP LSP to be signaled prior to the failure. + This requires the backup P2MP LSP to be signaled prior to the failure At the MP, backup S2L sub-LSPs (i.e., S2L sub-LSPs of the Backup P2MP LSP) are merged with protected S2L sub-LSPs. A MP (i.e., the bypass tunnel leaf LSRs), maintains a context specific Incoming Label Map (ILM) for the P2MP Bypass Tunnel. This can be implemented by maintaining a different context specific ILM for each LSR that is the root of a P2MP Bypass Tunnel (per-neighbor), or by maintaining a different context specific ILM for each P2MP Bypass Tunnel (per- tunnel). The context of an inner label (i.e., a backup label) is determined by the underlying P2MP Bypass Tunnel on which it is @@ -292,21 +292,21 @@ {LSR1.LSRn} may be a superset of {MP1.MPq}, that is some leaf LSRs of a given P2MP Bypass Tunnel, noted {LSRx.LSRy}, may not belong to {MP1.MPq}. The PLR will not distribute the backup label for the backup P2MP LSP to these LSRs {LSRx.LSRy}. However due to the nature of the P2MP Bypass Tunnel, during failure, packets with the backup label will also be delivered onto the P2MP Bypass Tunnel to {LSRx.LSRy}. {LSRx.LSRy} MUST discard these packets based on the absence of an entry for this label in the context specific ILM referred to that P2MP Bypass Tunnel. This requires that - {LSRx.LSRy} create a context specific ILM (per-tunnel or per-neighbor) + {LSRx.LSRy} create a context specific ILM, per-tunnel or per-neighbor for that P2MP Bypass Tunnel label. PHP MUST be deactivated on the P2MP Bypass Tunnel, in order to allow MPs to determine the context for the backup labels assigned by the PLR. Hence the P2MP Bypass Tunnel will be signaled with the "non PHP behavior desired" bit set in the Attribute Flags TLV as specified in [NO-PHP]. Note that P2MP Bypass Tunnels may be signaled in advance, prior to the establishment of any protected P2MP LSP, either automatically or @@ -402,21 +402,21 @@ object, or both. A MP MUST maintain one context specific ILM table per PLR or per P2MP Bypass Tunnel for which it is a leaf LSR. A MP MUST install the upstream assigned label received in a backup LSP's Path message (i.e., the backup label), within an ILM either specific to the underlying P2MP Bypass Tunnel or specific to the PLR, which is the ingress node of the underlying P2MP Bypass Tunnel. The underlying P2MP bypass tunnel is identified by its session object, - carried within the IF_ID_RSVP_HOP object of the backup LSP’s Path + carried within the IF_ID_RSVP_HOP object of the backup LSP's Path message. An upstream assigned label for a backup P2MP LSP MUST be mapped to the outgoing interface(s) and label(s) of the corresponding protected P2MP LSP. As specified in [RSVP-UP], the Resv message sent by a MP to the PLR, does not carry any Label Object. The processing of backup S2L sub-LSP SEROs/SRROs MUST follow backup tunnel ERO/RRO processing described in [RFC4090]. @@ -513,22 +513,22 @@ Bit Number: 8 (suggested value) Meaning: P2MP Partial Protection Desired Used in Attributes Flags on Path: Yes Used in Attributes Flags on Resv: No Used in Attributes Flags on RRO: Yes Referenced Section of this Doc: 7 11. Acknowledgments We would like to thank Kireeti Kompella, Venu Hemige, Laurent - Ciavaglia, Yannick Bréhon, and Mohamad Chaitou, for the useful - comments and discussions. + Ciavaglia, and Yannick Brehon, for the useful comments and + discussions. 12. References 12.1. Normative references [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3031] E. Rosen, A. Viswanathan, R. Callon, "MPLS Architecture", RFC 3031. @@ -554,22 +554,22 @@ RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress. [RFC4420] Farrel, A., Ed., et al."Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4420, February 2006. 12.2. Informational references [NO-PHP] Ali, Swallow, Aggarwal, "Non PHP Behavior and out-of-band - mapping for RSVP-TE LSPs", draft-ali-mpls-rsvp-te-no-php-oob-mapping, - work in progress + mapping for RSVP-TE LSPs", draft-ietf-mpls-rsvp-te-no-php-oob- + mapping, work in progress 13. Authors' Addresses: Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE Email: jeanlouis.leroux@orange-ftgroup.com @@ -622,13 +622,13 @@ This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The IETF Trust (2007). This document is subject to the + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.