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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/