draft-ietf-teas-rsvp-ingress-protection-11.txt   draft-ietf-teas-rsvp-ingress-protection-12.txt 
Internet Engineering Task Force H. Chen, Ed. Internet Engineering Task Force H. Chen, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Experimental R. Torvi, Ed. Intended status: Experimental R. Torvi, Ed.
Expires: April 18, 2018 Juniper Networks Expires: June 19, 2018 Juniper Networks
October 15, 2017 December 16, 2017
Extensions to RSVP-TE for LSP Ingress FRR Protection Extensions to RSVP-TE for LSP Ingress FRR Protection
draft-ietf-teas-rsvp-ingress-protection-11.txt draft-ietf-teas-rsvp-ingress-protection-12.txt
Abstract Abstract
This document describes extensions to Resource Reservation Protocol - This document describes extensions to Resource Reservation Protocol -
Traffic Engineering (RSVP-TE) for locally protecting the ingress node Traffic Engineering (RSVP-TE) for locally protecting the ingress node
of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic
Engineered (TE) Label Switched Path (LSP). Engineered (TE) Label Switched Path (LSP).
Status of this Memo Status of this Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2018. This Internet-Draft will expire on June 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
4.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 9 4.1.2. Subobject: Backup Ingress IPv6 Address . . . . . . . . 9
4.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 9 4.1.3. Subobject: Ingress IPv4 Address . . . . . . . . . . . 9
4.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 9 4.1.4. Subobject: Ingress IPv6 Address . . . . . . . . . . . 9
4.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 10 4.1.5. Subobject: Traffic Descriptor . . . . . . . . . . . . 10
4.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 11 4.1.6. Subobject: Label-Routes . . . . . . . . . . . . . . . 11
5. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 11 5. Behavior of Ingress Protection . . . . . . . . . . . . . . . . 11
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 11 5.1.1. Relay-Message Method . . . . . . . . . . . . . . . . . 11
5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12 5.1.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 12
5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13 5.2. Ingress Behavior . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 13 5.2.1. Relay-Message Method . . . . . . . . . . . . . . . . . 14
5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14 5.2.2. Proxy-Ingress Method . . . . . . . . . . . . . . . . . 14
5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 15 5.3. Backup Ingress Behavior . . . . . . . . . . . . . . . . . 16
5.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 16 5.3.1. Backup Ingress Behavior in Off-path Case . . . . . . . 16
5.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 18 5.3.2. Backup Ingress Behavior in On-path Case . . . . . . . 18
5.3.3. Failure Detection and Refresh PATH Messages . . . . . 19 5.3.3. Failure Detection and Refresh PATH Messages . . . . . 19
5.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 19 5.4. Revertive Behavior . . . . . . . . . . . . . . . . . . . . 19
5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 19 5.4.1. Revert to Primary Ingress . . . . . . . . . . . . . . 20
5.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 20 5.4.2. Global Repair by Backup Ingress . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21 8. Co-authors and Contributors . . . . . . . . . . . . . . . . . 21
9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
For a MPLS TE LSP, protecting the failures of its transit nodes using For a MPLS TE LSP, protecting the failures of its transit nodes using
fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875 fast-reroute (FRR) is covered in RFC 4090 for P2P LSP and RFC 4875
for P2MP LSP. However, protecting the failure of its ingress node for P2MP LSP. However, protecting the failure of its ingress node
using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS using FRR is not covered in either RFC 4090 or RFC 4875. The MPLS
Transport Profile (MPLS-TP) Linear Protection described in RFC 6378 Transport Profile (MPLS-TP) Linear Protection described in RFC 6378
skipping to change at page 4, line 47 skipping to change at page 4, line 47
[Ib]&&& [L3] [Ib]&&& [L3]
Figure 1: Ingress Local Protection Figure 1: Ingress Local Protection
In normal operations, source S sends the traffic to primary ingress In normal operations, source S sends the traffic to primary ingress
Ia. Ia imports the traffic into the primary LSP. Ia. Ia imports the traffic into the primary LSP.
When source S detects the failure of Ia, it switches the traffic to When source S detects the failure of Ia, it switches the traffic to
backup ingress Ib, which imports the traffic from S into the backup backup ingress Ib, which imports the traffic from S into the backup
LSP to Ia's next hops R2 and R4, where the traffic is merged into the LSP to Ia's next hops R2 and R4, where the traffic is merged into the
primary LSP, and then sent to egresses L1, L2 and L3. Source S primary LSP, and then sent to egresses L1, L2 and L3.
detects the failure of Ia and switches the traffic within 10s of ms.
Note that the backup ingress is one logical hop away from the Note that the backup ingress is one logical hop away from the
ingress. A logical hop is a direct link or a tunnel such as a GRE ingress. A logical hop is a direct link or a tunnel such as a GRE
tunnel, over which RSVP-TE messages may be exchanged. tunnel, over which RSVP-TE messages may be exchanged.
2. Ingress Failure Detection 2. Ingress Failure Detection
Exactly how to detect the failure of the ingress is out of scope. Exactly how to detect the failure of the ingress is out of scope.
However, it is necessary to discuss different modes for detecting the However, it is necessary to discuss different modes for detecting the
failure because they determine what is the required behavior for the failure because they determine what is the required behavior for the
skipping to change at page 5, line 26 skipping to change at page 5, line 25
source is responsible for fast detecting the failure of the primary source is responsible for fast detecting the failure of the primary
ingress of an LSP. The backup ingress is ready to import the traffic ingress of an LSP. The backup ingress is ready to import the traffic
from the source into the backup LSP(s) after the backup LSP(s) is up. from the source into the backup LSP(s) after the backup LSP(s) is up.
In normal operations, the source sends the traffic to the primary In normal operations, the source sends the traffic to the primary
ingress. When the source detects the failure of the primary ingress, ingress. When the source detects the failure of the primary ingress,
it switches the traffic to the backup ingress, which delivers the it switches the traffic to the backup ingress, which delivers the
traffic to the next hops of the primary ingress through the backup traffic to the next hops of the primary ingress through the backup
LSP(s), where the traffic is merged into the primary LSP. LSP(s), where the traffic is merged into the primary LSP.
For a P2P LSP, after the primary ingress fails, the backup ingress For an LSP, after the primary ingress fails, the backup ingress MUST
MUST use a method to reliably detect the failure of the primary use a method to reliably detect the failure of the primary ingress
ingress before the PATH message for the LSP expires at the next hop before the PATH message for the LSP expires at the next hop of the
of the primary ingress. After reliably detecting the failure, the primary ingress. After reliably detecting the failure, the backup
backup ingress sends/refreshes the PATH message to the next hop ingress sends/refreshes the PATH message to the next hop through the
through the backup LSP as needed. backup LSP as needed. The method may detect the failure of the
primary ingress slowly such as in seconds.
After the primary ingress fails, it will not be reachable after After the primary ingress fails, it will not be reachable after
routing convergence. Thus checking whether the primary ingress routing convergence. Thus checking whether the primary ingress
(address) is reachable is a possible method. (address) is reachable is a possible method.
2.2. Backup and Source Detect Failure 2.2. Backup and Source Detect Failure
Backup and Source Detect Failure or Backup-Source-Detect for short Backup and Source Detect Failure or Backup-Source-Detect for short
means that both the backup ingress and the source are concurrently means that both the backup ingress and the source are concurrently
responsible for fast detecting the failure of the primary ingress. responsible for fast detecting the failure of the primary ingress.
skipping to change at page 6, line 21 skipping to change at page 6, line 20
Before the primary ingress fails, the backup ingress is responsible Before the primary ingress fails, the backup ingress is responsible
for creating the necessary backup LSPs. These LSPs might be multiple for creating the necessary backup LSPs. These LSPs might be multiple
bypass P2P LSPs that avoid the ingress. Alternately, the backup bypass P2P LSPs that avoid the ingress. Alternately, the backup
ingress could choose to use a single backup P2MP LSP as a bypass or ingress could choose to use a single backup P2MP LSP as a bypass or
detour to protect the primary ingress of a primary P2MP LSP. detour to protect the primary ingress of a primary P2MP LSP.
The backup ingress may be off-path or on-path of an LSP. If a backup The backup ingress may be off-path or on-path of an LSP. If a backup
ingress is not any node of the LSP, we call it is off-path. If a ingress is not any node of the LSP, we call it is off-path. If a
backup ingress is a next-hop of the primary ingress of the LSP, we backup ingress is a next-hop of the primary ingress of the LSP, we
call it is on-path. If it is on-path, the primary forwarding state call it is on-path. When a backup ingress for protecting the primary
associated with the primary LSP SHOULD be clearly separated from the ingress is configured or computed, the backup ingress MUST not be on
backup LSP(s) state. the LSP except for it is the next hop of the primary ingress. If it
is on-path, the primary forwarding state associated with the primary
LSP SHOULD be clearly separated from the backup LSP(s) state.
3.1. Forwarding State for Backup LSP 3.1. Forwarding State for Backup LSP
A forwarding entry for a backup LSP is created on the backup ingress A forwarding entry for a backup LSP is created on the backup ingress
after the LSP is set up. Depending on the failure-detection mode after the LSP is set up. Depending on the failure-detection mode
(e.g., source-detect), it may be used to forward received traffic or (e.g., source-detect), it may be used to forward received traffic or
simply be inactive (e.g., backup-source-detect) until required. In simply be inactive (e.g., backup-source-detect) until required. In
either case, when the primary ingress fails, this entry is used to either case, when the primary ingress fails, this entry is used to
import the traffic into the backup LSP to the next hops of the import the traffic into the backup LSP to the next hops of the
primary ingress, where the traffic is merged into the primary LSP. primary ingress, where the traffic is merged into the primary LSP.
skipping to change at page 12, line 15 skipping to change at page 12, line 15
provides sufficient information for the backup ingress to create the provides sufficient information for the backup ingress to create the
appropriate forwarding state and backup LSP(s). appropriate forwarding state and backup LSP(s).
The ingress also sends the backup ingress all the other PATH messages The ingress also sends the backup ingress all the other PATH messages
for the LSP with an empty INGRESS_PROTECTION object. An for the LSP with an empty INGRESS_PROTECTION object. An
INGRESS_PROTECTION object without any Traffic-Descriptor sub-object INGRESS_PROTECTION object without any Traffic-Descriptor sub-object
is called an empty INGRESS_PROTECTION object. Thus, the backup is called an empty INGRESS_PROTECTION object. Thus, the backup
ingress has access to all the PATH messages needed for modification ingress has access to all the PATH messages needed for modification
to refresh control-plane state after a failure. to refresh control-plane state after a failure.
The empty INGRESS_PROTECTION object is for efficient process of
ingress protection for a P2MP LSP. For a P2MP LSP, its primary
ingress may have more than one PATH messages, each of which is sent
to a next hop along a branch of the P2MP LSP. The PATH message along
a branch will be selected and sent to the backup ingress with an
INGRESS_PROTECTION object containing the Traffic-Descriptor sub-
object; all the PATH messages along the other branches will be sent
to the backup ingress containing an INGRESS_PROTECTION object without
any Traffic-Descriptor sub-object (empty INGRESS_PROTECTION object).
For a P2MP LSP, the backup ingress only needs one Traffic-Descriptor.
The advantages of this method include: 1) the primary LSP is The advantages of this method include: 1) the primary LSP is
independent of the backup ingress; 2) simple; 3) less configuration; independent of the backup ingress; 2) simple; 3) less configuration;
and 4) less control traffic. and 4) less control traffic.
5.1.2. Proxy-Ingress Method 5.1.2. Proxy-Ingress Method
Conceptually, a proxy ingress is created that starts the RSVP Conceptually, a proxy ingress is created that starts the RSVP
signaling. The explicit path of the LSP goes from the proxy ingress signaling. The explicit path of the LSP goes from the proxy ingress
to the backup ingress and then to the real ingress. The behavior and to the backup ingress and then to the real ingress. The behavior and
signaling for the proxy ingress is done by the real ingress; the use signaling for the proxy ingress is done by the real ingress; the use
of a proxy ingress address avoids problems with loop detection. of a proxy ingress address avoids problems with loop detection. Note
that the proxy ingress MUST reside within the same router as the real
ingress.
[ traffic source ] *** Primary LSP [ traffic source ] *** Primary LSP
$ $ --- Backup LSP $ $ --- Backup LSP
$ $ $$ Link $ $ $$ Link
$ $ $ $
[ proxy ingress ] [ backup ] [ proxy ingress ] [ backup ]
[ & ingress ] | [ & ingress ] |
* | * |
*****[ MP ]----| *****[ MP ]----|
skipping to change at page 14, line 17 skipping to change at page 14, line 29
2. If the backup ingress is off-path (the backup ingress is not the 2. If the backup ingress is off-path (the backup ingress is not the
next hop of the primary ingress for P0), then send it a PATH next hop of the primary ingress for P0), then send it a PATH
message P0' with the content from P0 and an INGRESS_PROTECTION message P0' with the content from P0 and an INGRESS_PROTECTION
object; else (the backup ingress is a next hop, i.e., on-path object; else (the backup ingress is a next hop, i.e., on-path
case) add an INGRESS_PROTECTION object into the existing PATH case) add an INGRESS_PROTECTION object into the existing PATH
message to the backup ingress (i.e., the next hop). The object message to the backup ingress (i.e., the next hop). The object
contains the Traffic-Descriptor sub-object, the Backup Ingress contains the Traffic-Descriptor sub-object, the Backup Ingress
Address sub-object and the Label-Routes sub-object. The options Address sub-object and the Label-Routes sub-object. The options
is set to indicate whether a Backup P2MP LSP is desired. The is set to indicate whether a Backup P2MP LSP is desired. The
Label-Routes sub-object contains the next-hops of the primary Label-Routes sub-object contains the next-hops of the primary
ingress and their labels. ingress and their labels. Note that for on-path case, there is
an existing PATH message to the backup ingress (i.e., the next
hop), and we just add an INGRESS_PROTECTION object into the
existing PATH message to be sent to the backup ingress. We do
not send a separate PATH message to the backup ingress for this
existing PATH message.
3. For each Pi of the other PATH messages for the LSP, send the 3. For each Pi of the other PATH messages for the LSP, send the
backup ingress a PATH message Pi' with the content copied from Pi backup ingress a PATH message Pi' with the content copied from Pi
and an empty INGRESS_PROTECTION object. and an empty INGRESS_PROTECTION object.
For every PATH message Pj' (i.e., P0'/Pi') to be sent to the backup For every PATH message Pj' (i.e., P0'/Pi') to be sent to the backup
ingress, it has the same SESSION as Pj (i.e., P0/Pi). If the backup ingress, it has the same SESSION as Pj (i.e., P0/Pi). If the backup
ingress is off-path, the primary ingress updates Pj' according to the ingress is off-path, the primary ingress updates Pj' according to the
backup ingress as its next hop before sending it. It adds the backup backup ingress as its next hop before sending it. It adds the backup
ingress to the beginning of the ERO, and sets RSVP_HOP based on the ingress to the beginning of the ERO, and sets RSVP_HOP based on the
skipping to change at page 16, line 4 skipping to change at page 16, line 21
5.3. Backup Ingress Behavior 5.3. Backup Ingress Behavior
An LER determines that the ingress local protection is requested for An LER determines that the ingress local protection is requested for
an LSP if the INGRESS_PROTECTION object is included in the PATH an LSP if the INGRESS_PROTECTION object is included in the PATH
message it receives for the LSP. The LER can further determine that message it receives for the LSP. The LER can further determine that
it is the backup ingress if one of its addresses is in the Backup it is the backup ingress if one of its addresses is in the Backup
Ingress Address sub-object of the INGRESS_PROTECTION object. The LER Ingress Address sub-object of the INGRESS_PROTECTION object. The LER
as the backup ingress will assume full responsibility of the ingress as the backup ingress will assume full responsibility of the ingress
after the primary ingress fails. In addition, the LER determines after the primary ingress fails. In addition, the LER determines
that it is off-path if it is not any node of the LSP. that it is off-path if it is not any node of the LSP. The LER
determines whether it uses Relay-Message Method or Proxy-Ingress
Method according to configurations.
5.3.1. Backup Ingress Behavior in Off-path Case 5.3.1. Backup Ingress Behavior in Off-path Case
The backup ingress considers itself as a PLR and the primary ingress The backup ingress considers itself as a PLR and the primary ingress
as its next hop and provides a local protection for the primary as its next hop and provides a local protection for the primary
ingress. It behaves very similarly to a PLR providing fast-reroute ingress. It behaves very similarly to a PLR providing fast-reroute
where the primary ingress is considered as the failure-point to where the primary ingress is considered as the failure-point to
protect. Where not otherwise specified, the behavior given in protect. Where not otherwise specified, the behavior given in
[RFC4090] for a PLR applies. [RFC4090] for a PLR applies.
 End of changes. 15 change blocks. 
24 lines changed or deleted 46 lines changed or added

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