< draft-ali-ccamp-rsvp-te-include-route-05.txt   draft-ali-ccamp-rsvp-te-include-route-06.txt >
CCAMP Working Group Zafar Ali CCAMP Working Group Zafar Ali
Internet Draft George Swallow Internet Draft George Swallow
Intended status: Standard Track Clarence Filsfils Intended status: Standard Track Clarence Filsfils
Expires: April 20, 2014 Matt Hartley Expires: August 13, 2014 Matt Hartley
Ori Gerstel Ori Gerstel
Cisco Systems Cisco Systems
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
Ruediger Kunze Ruediger Kunze
Deutsche Telekom AG Deutsche Telekom AG
October 21, 2013 February 14, 2014
Include Routes - Extension to Include Routes - Extension to
Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
draft-ali-ccamp-rsvp-te-include-route-05.txt draft-ali-ccamp-rsvp-te-include-route-06.txt
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 working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
This Internet-Draft will expire on April 20, 2014. This Internet-Draft will expire on August 13, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
Conventions used in this document Conventions used in this document
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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119 this document are to be interpreted as described in RFC 2119
[RFC2119]. [RFC2119].
Table of Contents Table of Contents
Copyright Notice.....................................................1 Copyright Notice.................................................1
1. Introduction......................................................2 1. Introduction..................................................2
2. RSVP-TE signaling extensions......................................3 2. RSVP-TE signaling extensions..................................4
2.1. IPv4 Point-to-Point Path ERO subobject....................4 2.1. IPv4 Point-to-Point Path ERO subobject................4
2.2. IPv6 Point-to-Point Path ERO subobject....................5 2.2. IPv6 Point-to-Point Path ERO subobject................5
2.3. Processing rules for Path ERO subobjects..................7 2.3. Processing rules for Path ERO subobjects..............7
3. Security Considerations...........................................8 3. Security Considerations.......................................8
4. IANA Considerations...............................................8 4. IANA Considerations...........................................8
4.1. New ERO subobject types...................................8 4.1. New ERO subobject types...............................8
4.2. New RSVP error sub-codes..................................9 4.2. New RSVP error sub-codes..............................9
5. Acknowledgments...................................................9 5. Acknowledgments...............................................9
6. References........................................................9 6. References...................................................10
6.1. Normative References......................................9 6.1. Normative References.................................10
6.2. Informative References...................................10 6.2. Informative References...............................10
1. Introduction 1. Introduction
There are scenarios that require two or more Label Switched There are scenarios that require two or more Label Switched
Paths (LSPs) to follow same route in the network. E.g., many Paths (LSPs) to follow same route in the network. E.g., many
deployments require member LSPs of a bundle/ aggregated link (or deployments require member LSPs of a bundle/ aggregated link (or
Forwarding Adjacency (FA))) follow the same route. Possible Forwarding Adjacency (FA))) follow the same route. Possible
reasons for two or more LSPs to follow the same end-to-end or reasons for two or more LSPs to follow the same end-to-end or
partial route include, but are not limited to: partial route include, but are not limited to:
skipping to change at page 3, line 25 skipping to change at page 3, line 25
noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain noted in [OSPF-TE-METRIC] and [ISIS-TE-METRIC], in certain
networks, such as financial information networks, network networks, such as financial information networks, network
performance (e.g. latency and latency variation) is becoming performance (e.g. latency and latency variation) is becoming
critical and hence having bundles with component links (FAs) critical and hence having bundles with component links (FAs)
with homogeneous latency and latency variation is important. with homogeneous latency and latency variation is important.
The RSVP-TE specification [RFC3209] and GMPLS extensions to The RSVP-TE specification [RFC3209] and GMPLS extensions to
RSVP-TE [RFC3473] allow abstract nodes and resources to be RSVP-TE [RFC3473] allow abstract nodes and resources to be
explicitly included in a path setup, e.g., using IPv4 prefix ERO explicitly included in a path setup, e.g., using IPv4 prefix ERO
subobject [RFC3209], IPv6 prefix ERO subobject [RFC3209] and subobject [RFC3209], IPv6 prefix ERO subobject [RFC3209] and
Unnumbered Interface ID ERO subobject [RFC3477], etc. However, Unnumbered Interface ID ERO subobject [RFC3477], etc. When a
such inclusion may not be possible in the following scenarios: source node has full topological knowledge and is permitted to
signal an Explicit Route Object, these methods can be used to
satisfy the inclusion requirements mentioned above. However,
there are scenarios when path computations are performed by
remote nodes, thus there is a need for relevant inclusion
requirements to be communicated to those nodes. These include
(but are not limited to):
. Inclusion of an LSP path which, while known at the source . LSPs with loose hops in the Explicit Route Object (ERO), e.g.
node of the to-be-signaled LSP, where the required detail of inter-domain LSPs;
the route is incomplete or unavailable, e.g. due to
confidentiality of the path attributes. Such cases are likely . Generalized Multi-Protocol Label Switching (GMPLS) User-
to arise in Inter-domain and GMPLS overlay networks. Network Interface (UNI) where path computation may be
performed by the (server layer) core node [RFC4208].
These use-cases require the relevant path-inclusion information These use-cases require the relevant path-inclusion information
to be communicated to the route expanding nodes. This document to be communicated to the route expanding nodes. This document
defines the necessary information, encodings, and procedures. defines the necessary extensions to RSVP-TE protocol.
This document assumes that node expanding the route is normally a This document assumes that node expanding the route is normally a
hop of the included LSP. However, there is a race condition in hop of the included LSP. Therefore, the node calculating or
which included LSP is yet to be signaled. This draft addresses expanding the route of the signaled LSP has the knowledge of the
this race condition, as detailed in Section 2.2. inclusion route.
However, there is a race condition in which included LSP is yet
to be signaled. This draft addresses this race condition, as
detailed in Section 2.2.
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
2. RSVP-TE signaling extensions 2. RSVP-TE signaling extensions
New IPv4 and IPv6 Point-to-Point (P2P) Path ERO subobject types New IPv4 and IPv6 Point-to-Point (P2P) Path ERO subobject types
are defined in this document. These ERO subobjects are used to are defined in this document. These ERO subobjects are used to
communicate path inclusion requirements to the ERO expanding communicate path inclusion requirements to the ERO expanding
node(s). For this purpose, the subobjects carry RSVP-TE node(s). For this purpose, the subobjects carry RSVP-TE
Forwarding Equivalence Class (FEC) of the reference LSP who's Forwarding Equivalence Class (FEC) of the reference LSP who's
Path is be used to expand the loose hop of the LSP being Path is be used to expand the loose hop of the LSP being
signaled. signaled.
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
2.1. IPv4 Point-to-Point Path ERO subobject 2.1. IPv4 Point-to-Point Path ERO subobject
The IPv4 Point-to-Point Path ERO subobject is defined as The IPv4 Point-to-Point Path ERO subobject is defined as
follows: follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |M| Reserved | |L| Type | Length |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 4, line 42 skipping to change at page 5, line 5
hop in the explicit route. hop in the explicit route.
This document only defines the use of the subobject in This document only defines the use of the subobject in
loose hopes in the ERO, i.e., L bit MUST of set to 1. loose hopes in the ERO, i.e., L bit MUST of set to 1.
Type Type
IPv4 Point-to-Point Path ERO subobject IPv4 Point-to-Point Path ERO subobject
(to be assigned by IANA; suggested value: 38). (to be assigned by IANA; suggested value: 38).
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
Length Length
The length contains the total length of the subobject in The length contains the total length of the subobject in
bytes, including the type and length fields. The length is bytes, including the type and length fields. The length is
always 24. always 24.
M bit: When "mandatory inclusion" bit is set, the route of the M bit: When "mandatory inclusion" bit is set, the route of the
LSP being signaled MUST follow the path specified by the Path LSP being signaled MUST follow the path specified by the Path
ERO subobject. When mandatory inclusion is not set, the route ERO subobject. When mandatory inclusion is not set, the route
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
of the LSP being signaled SHOULD follow the path specified by of the LSP being signaled SHOULD follow the path specified by
the Path ERO subobject. the Path ERO subobject.
The remaining fields are used to specify RSVP-TE FEC of the The remaining fields are used to specify RSVP-TE FEC of the
reference LSP who's Path is be used to expand the route of the reference LSP who's Path is be used to expand the route of the
LSP being signaled. Specifically, LSP being signaled. Specifically,
Tunnel ID Tunnel ID
Tunnel ID of the reference LSP who's Path is be used to Tunnel ID of the reference LSP who's Path is be used to
skipping to change at page 5, line 40 skipping to change at page 6, line 5
LSP ID LSP ID
LSP ID of the reference LSP who's Path is be used to LSP ID of the reference LSP who's Path is be used to
expand the route of the LSP being signaled. expand the route of the LSP being signaled.
2.2. IPv6 Point-to-Point Path ERO subobject 2.2. IPv6 Point-to-Point Path ERO subobject
The IPv6 Point-to-Point Path ERO subobject is defined as The IPv6 Point-to-Point Path ERO subobject is defined as
follows: follows:
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length |M| Reserved | |L| Type | Length |M| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address | | IPv6 tunnel end point address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 tunnel end point address (cont.) | | IPv6 tunnel end point address (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Must Be Zero | Tunnel ID | | Must Be Zero | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID | | Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) | | Extended Tunnel ID (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID (cont.) | | Extended Tunnel ID (cont.) |
skipping to change at page 6, line 43 skipping to change at page 7, line 4
set if the subobject represents a loose hop in the ERO. set if the subobject represents a loose hop in the ERO.
If the bit is not set, the subobject represents a strict If the bit is not set, the subobject represents a strict
hop in the explicit route. hop in the explicit route.
This document only defines the use of the subobject in This document only defines the use of the subobject in
loose hopes in the ERO, i.e., L bit MUST of set to 1. loose hopes in the ERO, i.e., L bit MUST of set to 1.
Type Type
IPv6 Point-to-Point Path ERO subobject IPv6 Point-to-Point Path ERO subobject
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
(to be assigned by IANA; suggested value: 39). (to be assigned by IANA; suggested value: 39).
Length Length
The length contains the total length of the subobject in The length contains the total length of the subobject in
bytes, including the type and length fields. The length is bytes, including the type and length fields. The length is
always 48. always 48.
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
M bit: The M bit usage is as defined for the M bit of IPv4 M bit: The M bit usage is as defined for the M bit of IPv4
Point-to-Point Path ERO subobject. Point-to-Point Path ERO subobject.
The remaining fields are used to specific RSVP-TE FEC of the The remaining fields are used to specific RSVP-TE FEC of the
reference LSP who's Path is be used to expand the route of the reference LSP who's Path is be used to expand the route of the
LSP being signaled, as detailed in Section 2.1. LSP being signaled, as detailed in Section 2.1.
2.3. Processing rules for Path ERO subobjects 2.3. Processing rules for Path ERO subobjects
The basic processing rules of an ERO are not altered. Please The basic processing rules of an ERO are not altered. Please
skipping to change at page 7, line 44 skipping to change at page 8, line 4
- If the path taken by the LSP referenced in the Path ERO - If the path taken by the LSP referenced in the Path ERO
subobject is known to the processing node and the path subobject is known to the processing node and the path
contains the loose abstract node in the ERO hop, the contains the loose abstract node in the ERO hop, the
processing node MUST ensure that loose hop expansion to the processing node MUST ensure that loose hop expansion to the
next abstract node follows the referenced path. next abstract node follows the referenced path.
- If the path taken by the LSP referenced in the Path ERO - If the path taken by the LSP referenced in the Path ERO
subobject does not contain the loose abstract node in the ERO subobject does not contain the loose abstract node in the ERO
hop, the processing node MUST sent a PathErr message with the hop, the processing node MUST sent a PathErr message with the
error code "Routing Problem" (24) and the new error value error code "Routing Problem" (24) and the new error value
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
"unknown or inconsistent LSP suboject" (value to be assigned "unknown or inconsistent LSP suboject" (value to be assigned
by IANA) for the signaled LSP. by IANA) for the signaled LSP.
- If the path referenced in the LSP subobject is unknown to the - If the path referenced in the LSP subobject is unknown to the
processing node, the processing node SHOULD ignore the Path processing node, the processing node SHOULD ignore the Path
ERO subobject and SHOULD proceed with the signaling request. ERO subobject and SHOULD proceed with the signaling request.
After sending the Resv for the signaled LSP, the processing After sending the Resv for the signaled LSP, the processing
node SHOULD return a PathErr with the error code "Notify node SHOULD return a PathErr with the error code "Notify
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
Error" (25) and error sub-code "TBD" (value to be assigned by Error" (25) and error sub-code "TBD" (value to be assigned by
IANA, suggested value: TBD) for the signaled LSP. IANA, suggested value: TBD) for the signaled LSP.
If the M bit is not set, the processing node follows the If the M bit is not set, the processing node follows the
following procedure: following procedure:
- If the path taken by the LSP referenced in the Path ERO - If the path taken by the LSP referenced in the Path ERO
subobject is known to the processing node and the path subobject is known to the processing node and the path
contains the loose abstract node in the ERO hop, the contains the loose abstract node in the ERO hop, the
processing node SHOULD ensure that loose hop expansion to the processing node SHOULD ensure that loose hop expansion to the
skipping to change at page 8, line 46 skipping to change at page 9, line 5
4. IANA Considerations 4. IANA Considerations
4.1. New ERO subobject types 4.1. New ERO subobject types
This document adds the following new subobject of the existing This document adds the following new subobject of the existing
entry for ERO (20, EXPLICIT_ROUTE): entry for ERO (20, EXPLICIT_ROUTE):
Value Description Value Description
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
----- ------------ ----- ------------
TBA IPv4 Point-to-Point Path ERO TBA IPv4 Point-to-Point Path ERO
subobject subobject
TBA IPv6 Point-to-Point Path ERO TBA IPv6 Point-to-Point Path ERO
subobject subobject
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
These subobject may be present in the Explicit Route Object, but These subobject may be present in the Explicit Route Object, but
not in the Route Record Object. not in the Route Record Object.
4.2. New RSVP error sub-codes 4.2. New RSVP error sub-codes
IANA registry: RSVP PARAMETERS IANA registry: RSVP PARAMETERS
Subsection: Error Codes and Globally-Defined Error Value Sub- Subsection: Error Codes and Globally-Defined Error Value Sub-
Codes Codes
For Error Code "Routing Problem" (24) (see [RFC3209]) the For Error Code "Routing Problem" (24) (see [RFC3209]) the
skipping to change at page 9, line 37 skipping to change at page 10, line 5
Sub-code Value Sub-code Value
-------- ----- -------- -----
Unknown or inconsistent LSP suboject To be assigned by IANA. Unknown or inconsistent LSP suboject To be assigned by IANA.
5. Acknowledgments 5. Acknowledgments
Authors would like to thank Gabriele Maria Galimberti, Luyuan Authors would like to thank Gabriele Maria Galimberti, Luyuan
Fang and Walid Wakim for their review comments. Fang and Walid Wakim for their review comments.
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
6. References 6. References
6.1. Normative References 6.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.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for V., and G. Swallow, "RSVP-TE: Extensions to RSVP for
LSP Tunnels", RFC 3209, December 2001. LSP Tunnels", RFC 3209, December 2001.
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
[RFC3473] Berger, L., "Generalized Multi-Protocol Label [RFC3473] Berger, L., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, January 2003. RFC 3473, January 2003.
6.2. Informative References 6.2. Informative References
[RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter,
"Generalized Multiprotocol Label Switching (GMPLS) "Generalized Multiprotocol Label Switching (GMPLS)
User-Network Interface (UNI): Resource ReserVation User-Network Interface (UNI): Resource ReserVation
skipping to change at page 10, line 37 skipping to change at page 11, line 4
Engineering (RSVP-TE)", RFC 3477, January 2003. Engineering (RSVP-TE)", RFC 3477, January 2003.
[RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation
Protocol (RSVP) -- Version 1 Message Processing Protocol (RSVP) -- Version 1 Message Processing
Rules", RFC 2209, September 1997. Rules", RFC 2209, September 1997.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Authors' Addresses Authors' Addresses
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
Zafar Ali Zafar Ali
Cisco Systems, Inc. Cisco Systems, Inc.
Email: zali@cisco.com Email: zali@cisco.com
George Swallow George Swallow
Cisco Systems, Inc. Cisco Systems, Inc.
swallow@cisco.com swallow@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
cfilsfil@cisco.com cfilsfil@cisco.com
Internet-Draft draft-ali-ccamp-rsvp-te-include-route-05.txt
Matt Hartley Matt Hartley
Cisco Systems Cisco Systems
Email: mhartley@cisco.com Email: mhartley@cisco.com
Ori Gerstel Ori Gerstel
Cisco Systems Cisco Systems
ogerstel@cisco.com ogerstel@cisco.com
Kenji Kumaki Kenji Kumaki
KDDI Corporation KDDI Corporation
 End of changes. 24 change blocks. 
48 lines changed or deleted 57 lines changed or added

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