draft-ietf-teas-p2mp-loose-path-reopt-07.txt   draft-ietf-teas-p2mp-loose-path-reopt-08.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: April 27, 2017 Cisco Systems, Inc. Expires: June 11, 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
October 24, 2016 December 8, 2016
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-07 draft-ietf-teas-p2mp-loose-path-reopt-08
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.
Mechanisms that facilitate path re-optimization of loosely routed This document discusses the application of the existing mechanisms
Point-to-Point (P2P) TE LSPs include a method for the ingress node to for path re-optimization of loosely routed Point-to-Point (P2P) TE
trigger a new path re-evaluation request and a method for the mid- LSPs to the P2MP-TE LSPs, identifies issues in doing so and defines
point node to notify availability of a preferred path. This document procedures to address them. When re-optimizing a large number of S2L
discusses the application of these mechanisms to the re-optimization
of loosely routed P2MP-TE LSPs, identifies issues in doing so and
proposes procedures to address them.
This document defines Resource Reservation Protocol (RSVP) signaling
extensions to allow the ingress node of a loosely routed P2MP-TE LSP
to request the re-evaluation of the LSP tree downstream of the node,
and a mid-point node to notify to the ingress node that a preferable
tree for the P2MP-TE LSP exists. For re-optimizing a group of S2L
sub-LSPs in a tree using the Sub-Group-Based Re-optimization method, sub-LSPs in a tree using the Sub-Group-Based Re-optimization method,
an S2L sub-LSP descriptor list can be used to signal one or more S2L the S2L sub-LSP descriptor list may need to be semantically
sub-LSPs in an RSVP message. This RSVP message may need to be fragmented. This document defines the notion of a fragment
semantically fragmented when large number of S2L sub-LSPs are added identifier to help recipient nodes unambiguously reconstruct the
to the descriptor list. This document introduces the notion of a fragmented S2L sub-LSP descriptor list.
fragment identifier to help recipient nodes unambiguously reconstruct
the fragmented S2L sub-LSP descriptor list.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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/.
skipping to change at page 3, line 10 skipping to change at page 3, line 10
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
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . 6
3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . 7 Re-optimization . . . . . . . . . . . . . . . . . . . . . 7
4. Signaling Procedure For Loosely Routed P2MP-TE LSP 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 Re-optimization . . . . . . . . . . . . . . . . . . . . . 8
4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8 4. Signaling Extensions For Loosely Routed P2MP-TE LSP
Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 9
4.2. Sub-Group-Based Re-optimization Using Fragment 4.2. Sub-Group-Based Re-optimization Using Fragment
Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . 11 5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 12
6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . 13 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 14
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 4, line 27 skipping to change at page 4, line 27
node along the path to the egress node at the time of its signaling node along the path to the egress node at the time of its signaling
by the ingress node. Such an S2L sub-LSP is signaled with no by the ingress node. Such an S2L sub-LSP is signaled with no
Explicit Route Object (ERO) [RFC3209], or with an ERO that contains Explicit Route Object (ERO) [RFC3209], or with an ERO that contains
at least one loose next-hop, or with an ERO that contains an abstract at least one loose next-hop, or with an ERO that contains an abstract
node which identifies more than one node. This is often the case node which identifies more than one node. This is often the case
with inter-domain P2MP-TE LSPs where Path Computation Element (PCE) with inter-domain P2MP-TE LSPs where Path Computation Element (PCE)
is not used [RFC5440]. is not used [RFC5440].
As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE
LSP tree by re-signaling all its S2L sub-LSP(s) using the LSP tree by re-signaling all its S2L sub-LSP(s) using the
Make-Before-Break (MBB) method or may re-optimize individual or a set Make-Before-Break (MBB) method or may re-optimize individual S2L sub-
of S2L sub-LSP(s) i.e. individual or a set of destination(s) using LSP or a set of S2L sub-LSPs i.e. individual destination or a set of
the Sub-Group-Based re-optimization method. destinations, both using the Sub-Group-Based Re-optimization method.
[RFC4736] defines RSVP signaling mechanisms for re-optimizing loosely [RFC4736] defines RSVP signaling procedure for re-optimizing the
routed Point-to-Point (P2P) TE LSP(s). This document discusses the path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). Those
mechanisms include a method for the ingress node to trigger a new
path re-evaluation request and a method for the mid-point node to
notify availability of a preferred path. This document discusses the
application of those mechanisms to the re-optimization of loosely application of those mechanisms to the re-optimization of loosely
routed P2MP-TE LSPs, identifies issues in doing so and proposes routed P2MP-TE LSPs, identifies issues in doing so and defines
procedures to address them. procedures to address them.
For re-optimizing a group of S2L sub-LSPs in a tree using the Sub-
Group-Based Re-optimization method, an S2L sub-LSP descriptor list
can be used to signal one or more S2L sub-LSPs in an RSVP message.
This RSVP message may need to be semantically fragmented when large
number of S2L sub-LSPs are added to the descriptor list. This
document defines the notion of a fragment identifier to help
recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP
descriptor list.
2. Conventions Used in This Document 2. Conventions Used in This Document
2.1. Key Word Definitions 2.1. Key Word Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.2. Abbreviations 2.2. Abbreviations
ABR: Area Border Router. ABR: Area Border Router.
AS: Autonomous System. AS: Autonomous System.
skipping to change at page 7, line 39 skipping to change at page 7, line 50
In order to address above mentioned issues and to align In order to address above mentioned issues and to align
re-optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a re-optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a
need for a mechanism to trigger re-optimization of the LSP tree by need for a mechanism to trigger re-optimization of the LSP tree by
re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this
requirement, this document defines RSVP-TE signaling extensions for requirement, this document defines RSVP-TE signaling extensions for
the ingress node to trigger the re-evaluation of the P2MP LSP tree on the ingress node to trigger the re-evaluation of the P2MP LSP tree on
every hop that has a next-hop defined as a loose or abstract hop for every hop that has a next-hop defined as a loose or abstract hop for
one or more S2L sub-LSP path, and a mid-point LSR to signal to the one or more S2L sub-LSP path, and a mid-point LSR to signal to the
ingress node that a preferable LSP tree exists (compared to the ingress node that a preferable LSP tree exists (compared to the
current path) or that the whole P2MP-TE LSP must be re-optimized current path) or that the whole P2MP-TE LSP must be re-optimized
(because of maintenance required on the TE LSP path). (because of maintenance required on the TE LSP path) (see Section
4.1).
3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization
Applying the procedures discussed in RFC4736 in conjunction with the Applying the procedures discussed in RFC4736 in conjunction with the
Sub-Group-Based Re-Optimization procedures ([RFC4875], Section 14.2), Sub-Group-Based Re-Optimization procedures ([RFC4875], Section 14.2),
an ingress node MAY trigger path re-evaluation requests for a set of an ingress node MAY trigger path re-evaluation requests for a set of
S2L sub-LSPs in a single Path message using S2L sub-LSP descriptor S2L sub-LSPs in a single Path message using S2L sub-LSP descriptor
list. Similarly, a mid-point LSR may send a PathErr with the Notify list. Similarly, a mid-point LSR may send a PathErr with the Notify
error code 25 and sub-code 6 containing a list of S2L sub-LSPs error code 25 and sub-code 6 containing a list of S2L sub-LSPs
transiting through the LSR using an S2L sub-LSP descriptor list to transiting through the LSR using an S2L sub-LSP descriptor list to
skipping to change at page 8, line 34 skipping to change at page 8, line 47
sub-sets of S2L sub-LSPs in each (due to either the combined Path sub-sets of S2L sub-LSPs in each (due to either the combined Path
message getting fragmented or the combined PathErr message getting message getting fragmented or the combined PathErr message getting
fragmented) and would require additional logic to determine how to fragmented) and would require additional logic to determine how to
re-optimize the LSP tree (for example, waiting for some time to re-optimize the LSP tree (for example, waiting for some time to
aggregate all possible PathErr messages before taking an action). aggregate all possible PathErr messages before taking an action).
When fragmented, RSVP messages may arrive out of order, and the When fragmented, RSVP messages may arrive out of order, and the
receiver has no way of knowing the beginning and end of the S2L receiver has no way of knowing the beginning and end of the S2L
sub-LSP list. sub-LSP list.
In order to address the above mentioned issues caused by RSVP message In order to address the above mentioned issues caused by RSVP message
semantic fragmentation, this document proposes the use of fragment semantic fragmentation, this document defines new fragment identifier
identifier for the S2L sub-LSP descriptor list when combining large object for the S2L sub-LSP descriptor list when combining large
number of S2L sub-LSPs in an RSVP message. number of S2L sub-LSPs in an RSVP message (see Section 4.2).
4. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-optimization 4. Signaling Extensions For Loosely Routed P2MP-TE LSP Re-optimization
4.1. Tree-Based Re-optimization 4.1. Tree-Based Re-optimization
To evaluate a P2MP-TE LSP tree on mid-point LSRs that expand loose To evaluate a P2MP-TE LSP tree on mid-point LSRs that expand loose
next-hop(s), an ingress node MAY send a Path message with "P2MP-TE next-hop(s), an ingress node MAY send a Path message with "P2MP-TE
Tree Re-evaluation Request (value TBA1)" defined in this document. Tree Re-evaluation Request (value TBA1)" defined in this document.
The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP
tree transiting a mid-point LSR to trigger the re-evaluation request. tree transiting a mid-point LSR to trigger the re-evaluation request.
The ingress node MAY send a re-evaluation request to each border LSR The ingress node MAY send a re-evaluation request to each border LSR
on the path of the LSP tree. on the path of the LSP tree.
A mid-point LSR that expands loose next-hop(s) for one or more S2L A mid-point LSR that expands loose next-hop(s) for one or more S2L
sub-LSP path(s) SHOULD do the following upon receiving a Path message sub-LSP path(s) does the following upon receiving a Path message with
with the "P2MP-TE Tree Re-evaluation Request" flag set: the "P2MP-TE Tree Re-evaluation Request" flag set:
o The mid-point LSR SHOULD check for a preferable P2MP-TE LSP tree o The mid-point LSR MUST check for a preferable P2MP-TE LSP tree by
by re-evaluating all S2L sub-LSP(s) that are expanded paths of the re-evaluating all S2L sub-LSP(s) that are expanded paths of the
loose next-hops of the P2MP-TE LSP. loose next-hops of the P2MP-TE LSP.
o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MAY o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MUST
send an RSVP PathErr with the Notify error code 25 defined in send an RSVP PathErr with the Notify error code 25 defined in
[RFC3209] and sub-code "Preferable P2MP-TE Tree Exists (value [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists (value
TBA2)" defined in this document to the ingress node. The mid- TBA2)" defined in this document to the ingress node. The mid-
point LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re- point LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re-
evaluation Request" flag in the subsequent RSVP Path messages sent evaluation Request" flag in the subsequent RSVP Path messages sent
downstream for the re-evaluated P2MP-TE LSP. downstream for the re-evaluated P2MP-TE LSP.
o If no preferable tree for P2MP-TE LSP can be found, the o If no preferable tree for P2MP-TE LSP can be found, the mid-point
recommended mode is that the mid-point LSR that expands loose LSR that expands loose next-hop(s) for one or more S2L sub-LSP
next-hop(s) for one or more S2L sub-LSP path(s) SHOULD propagate path(s) MUST propagate the request downstream by setting the
the request downstream by setting the "P2MP-TE Tree Re-evaluation "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES
Request" flag in the LSP_ATTRIBUTES Object of the RSVP Path Object of the RSVP Path message.
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 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 MAY LSP tree and upon receiving this PathErr, the ingress node MUST
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 14, line 44 skipping to change at page 15, line 6
8. Security Considerations 8. Security Considerations
This document defines RSVP-TE signaling extensions to allow an This document defines RSVP-TE signaling extensions to allow an
ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP
tree downstream of a node, and for a mid-point LSR to notify the tree downstream of a node, and for a mid-point LSR to notify the
ingress node of the existence of a preferable tree by sending a ingress node of the existence of a preferable tree by sending a
PathErr. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP PathErr. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP
spanning multiple domains, it may be desirable for a mid-point LSR to spanning multiple domains, it may be desirable for a mid-point LSR to
modify the RSVP PathErr message defined in this document to preserve modify the RSVP PathErr message defined in this document to preserve
confidentiality across domains. Furthermore, an ingress node may confidentiality across domains.
decide to ignore this PathErr message coming from a mid-point LSR
residing in another domain. Similarly, a mid-point LSR may decide to
ignore the P2MP-TE tree re-evaluation request originating from
another ingress domain.
This document also defines fragment identifier for the S2L sub-LSP This document also defines fragment identifier for the S2L sub-LSP
descriptor when combining large number of S2L sub-LSPs in an RSVP descriptor when combining large number of S2L sub-LSPs in an RSVP
message and the message needs to be semantically fragmented. The message and the message needs to be semantically fragmented. The
introduction of the fragment identifier, by itself, introduces no introduction of the fragment identifier, by itself, introduces no
additional information to signaling. For a general discussions on additional information to signaling. For a general discussion on
MPLS and GMPLS related security issues, see the MPLS/GMPLS security MPLS and GMPLS related security issues, see the MPLS/GMPLS security
framework [RFC5920]. framework [RFC5920].
9. References 9. References
9.1. Normative References 9.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.
skipping to change at page 17, line 8 skipping to change at page 17, line 8
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
[RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol
(RSVP) Message Formats for Label Switched Path (LSP) (RSVP) Message Formats for Label Switched Path (LSP)
Attributes Objects", RFC 6510, February 2012. Attributes Objects", RFC 6510, February 2012.
Acknowledgments Acknowledgments
The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis
Villamizar, Dimitri Papadimitriou, Nobo Akiya and Vishnu Pavan Beeram Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram
for reviewing this document and providing many useful comments and and Joel M. Halpern for reviewing this document and providing many
suggestions. The authors would also like to thank Ling Zeng with useful comments and suggestions. The authors would also like to
Cisco Systems for implementing mechanisms defined in this document. thank Ling Zeng with Cisco Systems for implementing mechanisms
A special thanks to Adrian Farrel for his thorough review of this defined in this document. A special thanks to Adrian Farrel for his
document. thorough review of this document.
Author's Addresses Author's Addresses
Tarek Saad (editor) Tarek Saad (editor)
Cisco Systems Cisco Systems
EMail: tsaad@cisco.com EMail: tsaad@cisco.com
Rakesh Gandhi (editor) Rakesh Gandhi (editor)
Cisco Systems Cisco Systems
 End of changes. 27 change blocks. 
68 lines changed or deleted 64 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/