The MPLS WG Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] [mpls] Comments on draft-leroux-mpls-p2mp-te-bypass-00.txt
Hi,
First of all, my full support to the ID, this is for sure a needed
solution in several cases.
Here are my comments/suggestions:
1) To be discussed next week (live will be easier): it might be
useful in some cases to tradeoff the rerouting times for the P2MP
backup efficiency, provided that the failure detection times stays
bounded of course and on the order of a few ms. Note that in
situations where P2MP backup may be useful, it may make sense to have
the PLR not immediately upstream to the protected element. We can use
an distributed bidding mechanism to determine the PLR based on the
P2MP backup cost and the distance between the PLR and the protected
element.
2) In the introduction, don't you want to indicate that the use of
bypass P2MP tunnels may lead to more states compared to the P2P case
because of the requirement to fully intersect the protected primary ?
3) Trade-off between a set of P2P, one P2MP bypass tunnels and a set
of P2MP bypass tunnels. There are cases where it might be preferable
to use a set of P2P because of the number of states if the PLR has to
protect a large number of primary P2MP tunnels and the PLR cannot
find a good overlapping bypass P2MP. An alternative is also to use a
"few" P2MP bypass tunnels in that case: the PLR would have to do some
replication but still much less than with P2P bypass tunnels.
3) It would be useful to indicate that a P2MP TE LSP may be protected
by some PLRs using P2P and by other PLRs using P2MP bypass tunnel
along the protected P2MP primary path (thus comment 5)).
5) It might be useful to define:
* a flag in the LSP-ATTRIBUTE to indicate at each PLR whether the
primary P2MP TE LSP is protected by a set of P2P bypass tunnels or
one P2MP bypass tunnel
* a flag in the LSP-ATTRIBUTE to report "Partial" protection of the
primary P2MP TE LSP, by partial I'm referring to the ability to only
find a P2MP backup that does not fully intersect the primary TE LSP.
Or is partial protection simply not supported?
Comment in line (Search for JP>)
Network Working Group J.L. Le Roux
Internet Draft France Telecom
Category: Standard Track
Expires: February 2007 R. Aggarwal
Juniper
Networks
August
2006
P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels
draft-leroux-mpls-p2mp-te-bypass-00.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
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document defines procedures for fast reroute protection of
point-to-multipoint (P2MP) MPLS-TE LSPs, with point-to-multipoint
bypass tunnels. During branch node failure the traffic on a
protected
P2MP TE-LSP is tunneled within a P2MP bypass tunnel towards the set
of Merge Points. To avoid data duplication, the backup label is
assigned by the PLR following the RSVP-TE upstream label assignment
procedure.
Le Roux, Aggarwal Fast Reroute with P2MP Bypass Tunnels [Page 1]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this
document are to be interpreted as described in RFC-2119.
Table of Contents
1.
Terminology.................................................2
2.
Introduction................................................3
3. Solution
overview...........................................3
4. PLR
procedures..............................................4
4.1. Before
failure..............................................4
4.2. During
failure..............................................5
5. MP
Procedures...............................................5
6. Backward
compatibility......................................6
7. Security
Considerations.....................................6
8.
References..................................................6
8.1. Normative
references........................................6
9. Authors'
Addresses:.........................................7
10. Intellectual Property
Statement.............................7
1. Terminology
This document uses terminologies defined in [RFC3031], [RFC3209],
[RFC4090] and [RFC4461]. It defines the following new terms:
P2MP Bypass tunnel: Point-to-Multipoint Bypass Tunnel. A P2MP TE-
LSP that is used to protect a set of P2MP TE-LSPs traversing a
common node. The Ingress LSR of a P2MP bypass tunnel is the PLR
and the leaf LSRs are a set of LSRs, on the protected P2MP LSP,
downstream of the protected node.
P2MP Facility Backup: A local repair method in which a P2MP bypass
tunnel is used to protect one or more P2MP TE-LSPs that
traverse the PLR (P2MP Bypass Ingress), the resource being
protected, and the set of Merge Points (P2MP Bypass leaves)
downstream to the protected resource.
Backup P2MP LSP: The LSP that is used to backup up one of the
many protected P2MP LSPs in P2MP Facility Backup.
Backup S2L sub-LSP: A S2L sub-LSP of a backup P2MP LSP.
.
Le Roux, Aggarwal [Page 2]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
JP> It might be useful to define the notion of overlapping P2MP
Bypass tunnel
where's all the leaf LSRs of the bypass tunnel intersect the
protected primary
P2MP tunnel.
2. Introduction
[RFC4090] defines fast reroute extensions to RSVP-TE for local
protection of P2P MPLS TE LSPs. Two techniques are defined: the one-
to-one backup method, which creates a detour LSP for each protected
LSP at each PLR, and the facility backup method, which creates a
bypass tunnel that can be used to protect a set of LSPs by taking
advantage of MPLS label stacking.
[RSVP-P2MP] defines extensions to RSVP-TE for setting up P2MP TE-
LSPs. It specifies extensions to one-to-one and facility backup Fast
Reroute procedures defined in [RFC4090] so as to support fast
reroute
protection of P2MP LSPs.
The facility backup solution defined in [RSVP-P2MP] only relies on
P2P bypass tunnels for link and node protection. This faces the
following limitation: The protection of a P2MP LSP against node
failures requires, when the protected node is a Branch LSR, a set of
P2P Next Next Hop (NNHOP) Bypass tunnels towards all LSRs downstream
to the protected node. During failure the PLR has to replicate
traffic on each P2P NNHOP bypass tunnel, and this may lead to
significant inefficient bandwidth usage.
To overcome this limitation it is highly desired to define
extensions
to the fast reroute facility backup solution, so as to support P2MP
Bypass tunnels.
JP> See my previous comments regarding the trade-off between number
of states and
backup tunnel efficiency.
This draft specifies extensions to the Fast Reroute procedures
defined in [RFC4090] and [RSVP-P2MP] to support P2MP TE-LSP node
protection with P2MP bypass tunnels.
Procedures defined in [RFC4090] and [RSVP-P2MP] MUST be followed
unless specified below.
3. Solution overview
The P2MP Facility Backup method defined in this document relies on
the use of P2MP bypass tunnels. A P2MP bypass tunnel can be used to
protect a set of P2MP TE-LSPs by taking advantage of MPLS label
stacking.
A P2MP Bypass tunnel is used to protect a P2MP TE-LSP against branch
LSR failures. The bypass tunnel head-end is the PLR, and the bypass
tunnel leaf LSRs are the set of MPs, that is the set of LSRs
downstream to the protected branch node, on the protected P2MP TE-
LSP.
The P2MP bypass tunnel protects the set of S2L sub-LSPs that transit
the protected node.
When P2MP facility backup method is used, during failure the PLR
MUST
send data for each protected P2MP LSP into the P2MP bypass tunnel.
Label stacking is used: The inner label is the backup label for the
backup P2MP LSP, that will be used on the MP to forward traffic to
Le Roux, Aggarwal [Page 3]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
the corresponding protected P2MP LSP, and the outer label is the
P2MP
bypass tunnel label.
To avoid data replication on the PLR, the same backup label MUST be
used for all S2L sub-LSPs towards all MPs of a given backup P2MP
LSP.
This backup label will indicate to the MPs 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 the set of MPs, in
the context of the P2MP bypass tunnel. This requires the backup P2MP
LSP to be signalled prior to the failure.
JP> Which is required anyway to guarantee fast rerouting and always
the case for Protection recovery
(by contrast with recovery)
On the MP, backup S2L sub-LSPs (i.e. S2L sub-LSPs of the backup P2MP
LSP) are merged with protected S2L sub-LSPs. The MPs, (i.e. the
bypass tunnel leaf LSRs), maintain a context specific ILM
JP> Spell ?
for the
P2MP Bypass tunnel. The context of an inner label (i.e a backup
label)
is determined by the underlying P2MP bypass tunnel on which it is
received. This requires deactivating PHP on the P2MP bypass
tunnel. A
label, in a given Bypass tunnel specific ILM, is mapped to the
outgoing interfaces and labels of the corresponding protected P2MP
LSP.
4. PLR procedures
4.1. Before failure
To protect a P2MP LSP against a branch node failure, a PLR MUST
JP> The MUST is what I propose to change (see comments above)
depending on the path
quality for the P2MP bypass, number of states, ... compared to using
P2P bypass.
select a P2MP bypass tunnel with a set of leaf LSRs with the
following properties:
- These leaf LSRs are transit or egress LSRs on the protected
P2MP LSP. We will denote this subset as {LSR1.LSRn}.
- {LSR1.LSRn} are downstream of the protected node on the
Protected P2MP LSP.
- In the event of failure of the protected node, traffic
received on the protected P2MP LSP by the PLR, can be
delivered to all the leaves of the protected P2MP LSP
downstream to the failed node, if it is tunnelled to
{LSR1.LSRn} over the P2MP bypass.
JP> This is where we could discuss using one or more P2MP bypass (if
non overlapping)
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.
The backup label (i.e. the inner label) used for every backup S2L
sub-LSPs, (i.e. the inner label within the P2MP bypass tunnel), of a
given backup P2MP LSP MUST be the same, so as to avoid traffic
replication on the PLR. This label MUST be assigned by the PLR using
upstream label assignment procedures.
Le Roux, Aggarwal [Page 4]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
Backup P2MP LSPs MUST be signaled prior to the failure.
To signal the backup P2MP LSP, the PLR MUST send one or more Path
messages to each MP. The Path messages to signal a backup P2MP LSP
are sent to the MPs using directed signaling; they are addressed to
the MPs, without Router Alert option.
The PLR MUST use the sender template specific method to identify a
Path message for a backup P2MP LSPs. Hence the PLR will set the
source address in the sender template to a local PLR address.
A Path message to a given MP comprises one or more backup S2L sub-
LSPs that transit through this MP.
The backup label MUST be assigned by the PLR, in the context of the
underlying P2MP Bypass tunnel, following upstream label assignment
and P2MP RSVP-TE context identification procedures defined in [RSVP-
UP]. Hence, a Path message sent to a MP for a backup P2MP LSP MUST
include an Upstream Assigned Label object carrying the value of the
backup label. It MUST also include an RSVP-TE P2MP LSP TLV within an
IF_ID RSVP TLV, that carries the session object of the underlying
P2MP Bypass tunnel. This allows MPs to identify the label space of
the backup label assigned by the PLR. The same backup label MUST be
sent to all MPs of a protected P2MP LSP.
Note that the PLR MUST continue to refresh Path messages for the
protected P2MP LSP along the nominal route.
The processing of backup S2L sub-LSP SEROs/SRROs MUST follow
backup LSP ERO/RRO processing described in [RFC4090].
4.2. During failure
When the PLR detects a link or/and node failure condition, it has to
reroute a protected P2MP LSP onto the P2MP bypass tunnel using as
inner label the backup label assigned for this P2MP LSP.
The PLR MUST continue to send Path messages for the backup P2MP LSP.
JP> Need to discuss the replication of Path messages by the branch
node along the backup P2P LSP
The RRO/ERO flags MUST be updated as per defined in [RFC4090]
5. MP Procedures
A MP receives one or more Path messages for the protected P2MP LSP
and one or more Path messages for the backup P2MP LSP.
Note that, as specified in [RFC4090], the reception of a backup
LSP's
Path message does not indicate that a failure has occurred or that
the incoming protected LSP will no longer be used.
A S2L sub-LSP is received
JP> "Received" confusing terminology
within a Path message for the protected
P2MP LSP and within a Path message for the backup P2MP LSP. These
two
Path messages are distinguished thanks to the sender-template
specific method. As specified in [RFC4090], each of these Path
messages will have a different SENDER_TEMPLATE. The protected LSP
can be recognized because it will include the FAST_REROUTE object or
Le Roux, Aggarwal [Page 5]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
have the "local protection desired" flag set in the
SESSION_ATTRIBUTE
object, or both.
A MP MUST install the upstream assigned label received in a backup
LSP Path message, within an ILM specific to the underlying bypass
tunnel, which is identified by its session object, carried within
the
IF_ID RSVP_HOP object of the backup Path message. An upstream
assigned label for a backup P2MP LSP MUST be mapped to the outgoing
interfaces and labels 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].
6. Backward compatibility
Procedures with MPs that do not support upstream label assignment
are
to be defined (combination of P2P and P2MP bypass LSPs).
7. Security Considerations
No new security issues are raised in this document.
8. References
8.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.
[RFC3209] D. Awduche et al., "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209.
[RFC4461] S. Yasukawa et al., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)",
RFC4461.
[RFC4090] Pan, Swallow, Atlas, et al., "Fast Reroute Extensions to
RSVP-TE for LSP Tunnels", RFC4090.
[RSVP-P2MP] Aggarwal, Papadimitriou, Yasukawa, "Extensions to
RSVP-TE
for Point to Multipoint TE LSPs", draft-ietf-mpls-p2mp-rsvp-te, work
in progress.
[MPLS-UPSTREAM] Aggarwal, Rekhter, Rosen, "MPLS Upstream Label
Assignment and Context Specific Label Space", draft-ietf-mpls-
upstream-label, work in progress.
Le Roux, Aggarwal [Page 6]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
[RSVP-UP] Aggarwal, Le Roux, " MPLS Upstream Label Assignment for
RSVP-TE", draft-ietf-mpls-rsvp-upstream, work in progress.
9. Authors' Addresses:
Jean-Louis Le Roux
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex
FRANCE
Email: jeanlouis.leroux@francetelecom.com
Rahul Aggarwal
Juniper Networks
1194 North Mathilda Ave.
Sunnyvale, CA 94089
Email: rahul@juniper.net
10. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be
claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights.
Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the
use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR
repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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 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
Le Roux, Aggarwal [Page 7]
Internet Draft draft-leroux-mpls-p2mp-te-bypass-00.txt August 2006
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Le Roux, Aggarwal [Page 8]
_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls
|
|