draft-ietf-teas-p2mp-loose-path-reopt-08.txt   draft-ietf-teas-p2mp-loose-path-reopt-09.txt 
TEAS Working Group T. Saad, Ed. TEAS Working Group T. Saad, Ed.
Internet-Draft R. Gandhi, Ed. Internet-Draft R. Gandhi, Ed.
Intended status: Standards Track Z. Ali Intended status: Standards Track Z. Ali
Expires: June 11, 2017 Cisco Systems, Inc. Expires: August 6, 2017 Cisco Systems, Inc.
R. Venator R. Venator
Defense Information Systems Agency Defense Information Systems Agency
Y. Kamite Y. Kamite
NTT Communications Corporation NTT Communications Corporation
December 8, 2016 February 2, 2017
RSVP Extensions For Re-optimization of Loosely Routed RSVP Extensions For Re-optimization of Loosely Routed
Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)
draft-ietf-teas-p2mp-loose-path-reopt-08 draft-ietf-teas-p2mp-loose-path-reopt-09
Abstract Abstract
Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered
(TE) Label Switched Path (LSP) may be triggered based on the need to (TE) Label Switched Path (LSP) may be triggered based on the need to
re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of
S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or
the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method.
This document discusses the application of the existing mechanisms This document discusses the application of the existing mechanisms
for path re-optimization of loosely routed Point-to-Point (P2P) TE for path re-optimization of loosely routed Point-to-Point (P2P) TE
skipping to change at page 2, line 9 skipping to change at page 2, line 9
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."
Copyright Notice Copyright Notice
Copyright (c) 2016 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 6 3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 6
3.2. Existing Mechanism For Tree-Based P2MP-TE LSP 3.2. Existing Mechanism For Tree-Based P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . 7 Re-optimization . . . . . . . . . . . . . . . . . . . . . 6
3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . 8 Re-optimization . . . . . . . . . . . . . . . . . . . . . 7
4. Signaling Extensions For Loosely Routed P2MP-TE LSP 4. Signaling Extensions For Loosely Routed P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 9 Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 9 4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8
4.2. Sub-Group-Based Re-optimization Using Fragment 4.2. Sub-Group-Based Re-optimization Using Fragment
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 10 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Message and Object Definitions . . . . . . . . . . . . . . . . 11 5. Message and Object Definitions . . . . . . . . . . . . . . . . 11
5.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11 5.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11
5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 11 5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 11
5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 12 5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 13 7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 13
7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 14 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 13
7.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 14 7.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
skipping to change at page 5, line 18 skipping to change at page 5, line 18
2.2. Abbreviations 2.2. Abbreviations
ABR: Area Border Router. ABR: Area Border Router.
AS: Autonomous System. AS: Autonomous System.
ERO: Explicit Route Object. ERO: Explicit Route Object.
LSR: Label Switching Router. LSR: Label Switching Router.
S2L sub-LSP: Source-to-leaf sub Label Switched Path.
TE LSP: Traffic Engineering Label Switched Path. TE LSP: Traffic Engineering Label Switched Path.
TE LSP ingress: Head-end/source node of the TE LSP. TE LSP ingress: Head-end/source node of the TE LSP.
TE LSP egress: Tail-end/destination node of the TE LSP. TE LSP egress: Tail-end/destination node of the TE LSP.
2.3. Terminology 2.3. Terminology
Domain: Routing or administrative domain such as an IGP area and an
autonomous system.
Interior Gateway Protocol Area (IGP Area): OSPF area or IS-IS level.
Inter-area TE LSP: A TE LSP whose path transits across at least two
different IGP areas.
Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least
two different Autonomous Systems (ASes) or sub-ASes (BGP
confederations).
S2L sub-LSP: Source-to-leaf sub Label Switched Path.
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
[RFC4875] and [RFC4736]. [RFC4736] and [RFC4875].
3. Overview 3. Overview
[RFC4736] defines RSVP signaling extensions for re-optimizing loosely [RFC4736] defines RSVP signaling extensions for re-optimizing loosely
routed P2P TE LSPs as follows: routed P2P TE LSPs as follows:
o A mid-point LSR that expands loose next-hop(s) sends a solicited o A mid-point LSR that expands loose next-hop(s) sends a solicited
or unsolicited PathErr with the Notify error code 25 (as defined or unsolicited PathErr with the Notify error code 25 (as defined
in [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" in [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists"
to the ingress node. to the ingress node.
skipping to change at page 9, line 45 skipping to change at page 9, line 33
path(s) MUST propagate the request downstream by setting the path(s) MUST propagate the request downstream by setting the
"P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES
Object of the RSVP Path message. Object of the RSVP Path message.
A mid-point LSR MAY send an unsolicited PathErr with the Notify error A mid-point LSR MAY send an unsolicited PathErr with the Notify error
code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress
node to notify of a preferred P2MP-TE LSP tree when it determines it node to notify of a preferred P2MP-TE LSP tree when it determines it
exists. In this case, the mid-point LSR that expands loose next- exists. In this case, the mid-point LSR that expands loose next-
hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L
sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to
the ingress node. the ingress node. The mid-point LSR SHOULD consider how frequently
it chooses to send such a PathErr - considering both that a PathErr
may be lost on its transit to the ingress node and that the ingress
node may choose not to re-optimize the LSP when such a PathErr is
received.
The sending of an RSVP PathErr with the Notify error code and The sending of an RSVP PathErr with the Notify error code and
"Preferable P2MP-TE Tree Exists" sub-code to the ingress node "Preferable P2MP-TE Tree Exists" sub-code to the ingress node
notifies the ingress node of the existence of a preferable P2MP-TE notifies the ingress node of the existence of a preferable P2MP-TE
LSP tree and upon receiving this PathErr, the ingress node MUST LSP tree and upon receiving this PathErr, the ingress node SHOULD
trigger re-optimization of the LSP using the MBB method with a trigger re-optimization of the LSP using the MBB method with a
different LSP-ID. different LSP-ID.
4.2. Sub-Group-Based Re-optimization Using Fragment Identifier 4.2. Sub-Group-Based Re-optimization Using Fragment Identifier
It might be preferable, as per [RFC4875], to re-optimize the entire It might be preferable, as per [RFC4875], to re-optimize the entire
P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1,
"Make-before-Break") or to re-optimize individual or group of S2L "Make-before-Break") or to re-optimize individual or group of S2L
sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2
"Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same
skipping to change at page 13, line 43 skipping to change at page 13, line 35
http://www.iana.org/assignments/rsvp-te-parameters). From the http://www.iana.org/assignments/rsvp-te-parameters). From the
registries in this name space "Attribute Flags", allocation of new registries in this name space "Attribute Flags", allocation of new
flag is requested (Section 5.1). flag is requested (Section 5.1).
The following new flag is defined for the Attributes Flags TLV in the The following new flag is defined for the Attributes Flags TLV in the
LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned
by IANA. by IANA.
o P2MP-TE Tree Re-evaluation Request Flag: o P2MP-TE Tree Re-evaluation Request Flag:
+--------+---------------+---------+---------+---------+------------+ +--------+---------------+---------+---------+---------+-----------+
| Bit No | Attribute | Carried | Carried | Carried | Reference | | Bit No | Attribute | Carried | Carried | Carried | Reference |
| | Flag Name | in Path | in Resv | in RRO | | | | Flag Name | in Path | in Resv | in RRO | |
+--------+---------------+---------+---------+---------+------------+ | | | | | or ERO | |
| TBA1 by| P2MP-TE Tree | Yes | No | No | This | +--------+---------------+---------+---------+---------+-----------+
| IANA | Re-evaluation | | | | document | | TBA1 by| P2MP-TE Tree | Yes | No | No | This |
+--------+---------------+---------+---------+---------+------------+ | IANA | Re-evaluation | | | | document |
+--------+---------------+---------+---------+---------+-----------+
7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code
IANA maintains a name space for RSVP protocol parameters "Resource IANA maintains a name space for RSVP protocol parameters "Resource
Reservation Protocol (RSVP) Parameters" (see Reservation Protocol (RSVP) Parameters" (see
http://www.iana.org/assignments/rsvp-parameters). From the http://www.iana.org/assignments/rsvp-parameters). From the
sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes
and Globally-Defined Error Value Sub-Codes", allocation of a new and Globally-Defined Error Value Sub-Codes", allocation of a new
error code is requested (Section 5.2). error code is requested (Section 5.2).
 End of changes. 16 change blocks. 
36 lines changed or deleted 29 lines changed or added

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