draft-ietf-teas-rsvp-te-domain-subobjects-01.txt   draft-ietf-teas-rsvp-te-domain-subobjects-02.txt 
TEAS Working Group D. Dhody TEAS Working Group D. Dhody
Internet-Draft U. Palle Internet-Draft U. Palle
Intended status: Experimental V. Kondreddy Intended status: Experimental V. Kondreddy
Expires: November 1, 2015 Huawei Technologies Expires: January 20, 2016 Huawei Technologies
R. Casellas R. Casellas
CTTC CTTC
April 30, 2015 July 19, 2015
Domain Subobjects for Resource ReserVation Protocol - Traffic Domain Subobjects for Resource ReserVation Protocol - Traffic
Engineering (RSVP-TE) Engineering (RSVP-TE)
draft-ietf-teas-rsvp-te-domain-subobjects-01 draft-ietf-teas-rsvp-te-domain-subobjects-02
Abstract Abstract
The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
specification and the Generalized Multiprotocol Label Switching specification and the Generalized Multiprotocol Label Switching
(GMPLS) extensions to RSVP-TE allow abstract nodes and resources to (GMPLS) extensions to RSVP-TE allow abstract nodes and resources to
be explicitly included in a path setup. Further Exclude Routes be explicitly included in a path setup. Further Exclude Routes
extensions to RSVP-TE allow abstract nodes and resources to be extensions to RSVP-TE allow abstract nodes and resources to be
explicitly excluded in a path setup. explicitly excluded in a path setup.
This document specifies new subobjects to include or exclude domains This document specifies new subobjects to include or exclude 4-Byte
during path setup where domain is a collection of network elements Autonomous System (AS) and Interior Gateway Protocol (IGP) area
within a common sphere of address management or path computational during path setup.
responsibility (such as an Interior Gateway Protocol (IGP) area or an
Autonomous System (AS)). Note that the use of AS as an abstract node
representing domain is already defined in existing RSVP-TE
specefications, albeit with a 2-Byte AS number.
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/.
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 November 1, 2015. This Internet-Draft will expire on January 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . 5 3. Subobjects for Domains . . . . . . . . . . . . . . . . . . . 5
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Explicit Route Object (ERO)'s Subobjects . . . . . . . . 5 3.2. Explicit Route Object (ERO)'s Subobjects . . . . . . . . 5
3.2.1. Autonomous system . . . . . . . . . . . . . . . . . . 6 3.2.1. Autonomous system . . . . . . . . . . . . . . . . . . 6
3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 6
3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 8 3.2.3. Mode of Operation . . . . . . . . . . . . . . . . . . 8
3.3. Exclude Route Object (XRO)'s Subobjects . . . . . . . . . 8 3.3. Exclude Route Object (XRO)'s Subobjects . . . . . . . . . 8
3.3.1. Autonomous system . . . . . . . . . . . . . . . . . . 8 3.3.1. Autonomous system . . . . . . . . . . . . . . . . . . 8
3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. IGP Area . . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 9 3.3.3. Mode of Operation . . . . . . . . . . . . . . . . . . 9
3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . 9 3.4. Explicit Exclusion Route Subobject . . . . . . . . . . . 9
4. Interaction with Path Computation Element (PCE) . . . . . . . 10 4. Interaction with Path Computation Element (PCE) . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 10 5.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 13 A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 13
A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 14 A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 14
A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14
A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 14 A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP- The RSVP-TE specification [RFC3209] and the GMPLS extensions to RSVP-
TE [RFC3473] allow abstract nodes and resources to be explicitly TE [RFC3473] allow abstract nodes and resources to be explicitly
included in a path setup using the Explicit Route Object (ERO). included in a path setup using the Explicit Route Object (ERO).
Further Exclude Routes extensions [RFC4874] allow abstract nodes or Further Exclude Routes extensions [RFC4874] allow abstract nodes or
resources to be excluded from the whole path using the Exclude Route resources to be excluded from the whole path using the Exclude Route
object (XRO). To exclude certain abstract nodes or resources between object (XRO). To exclude certain abstract nodes or resources between
skipping to change at page 4, line 12 skipping to change at page 4, line 9
by legacy implementations. If one of the subobjects is received in a by legacy implementations. If one of the subobjects is received in a
RSVP-TE object that does not understand it, it will behave as RSVP-TE object that does not understand it, it will behave as
described in [RFC3209] and [RFC4874]. Therefore, it is assumed that described in [RFC3209] and [RFC4874]. Therefore, it is assumed that
this experiment will be conducted only when all nodes processing the this experiment will be conducted only when all nodes processing the
new subobject form part of the experiment. new subobject form part of the experiment.
When the result of implementation and deployment are available, this When the result of implementation and deployment are available, this
document will be updated and refined, and then be moved from document will be updated and refined, and then be moved from
Experimental to Standard Track. Experimental to Standard Track.
It should be noted that there are other ways such as use of boundary
node to identify the domain (instead of domain identifier), the
mechanism defined in this document is just another tool in the
toolkit for the operator.
1.2. Requirements Language 1.2. Requirements Language
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. Terminology 2. Terminology
The following terminology is used in this document. The following terminology is used in this document.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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 | Reserved | |L| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS-ID (4 bytes) | | AS-ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: The L bit is an attribute of the subobject as defined in L: The L bit is an attribute of the subobject as defined in
[RFC3209]. [RFC3209], i.e., set if the subobject represents a loose hop in
the explicit route. If the bit is not set, the subobject
represents a strict hop in the explicit route.
Type: (TBD1 by IANA) indicating a 4-Byte AS Number. Type: (TBD1 by IANA) indicating a 4-Byte AS Number.
Length: 8 (Total length of the subobject in bytes). Length: 8 (Total length of the subobject in bytes).
Reserved: Zero at transmission, ignored at receipt. Reserved: Zero at transmission, ignored at receipt.
AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in AS-ID: The 4-Byte AS Number. Note that if 2-Byte AS numbers are in
use, the low order bits (16 through 31) MUST be used and the high use, the low order bits (16 through 31) MUST be used and the high
order bits (0 through 15) MUST be set to zero. order bits (0 through 15) MUST be set to zero. For the purpose of
this experiment, it is advised to use 4-Byte AS number subobject
as default.
3.2.2. IGP Area 3.2.2. IGP Area
Since the length and format of Area-id is different for OSPF and Since the length and format of Area-id is different for OSPF and
ISIS, the following two subobjects are defined: ISIS, the following two subobjects are defined:
For OSPF, the area-id is a 32 bit number. The subobject is encoded For OSPF, the area-id is a 32 bit number. The subobject is encoded
as follows: as follows:
0 1 2 3 0 1 2 3
skipping to change at page 8, line 8 skipping to change at page 8, line 8
Identifier in octets; Valid values are from 2 to 11 inclusive). Identifier in octets; Valid values are from 2 to 11 inclusive).
Reserved: Zero at transmission, ignored at receipt. Reserved: Zero at transmission, ignored at receipt.
IS-IS Area Id: The variable-length IS-IS area identifier. Padded IS-IS Area Id: The variable-length IS-IS area identifier. Padded
with trailing zeroes to a four-byte boundary. with trailing zeroes to a four-byte boundary.
3.2.3. Mode of Operation 3.2.3. Mode of Operation
The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area
could also be used in the ERO to specify an abstract node (a group of could be used in the ERO to specify an abstract node (a group of
nodes whose internal topology is opaque to the ingress node of the nodes whose internal topology is opaque to the ingress node of the
LSP). LSP).
All the rules of processing (for example Next Hop Selection, L bit All the rules of processing (for example Next Hop Selection, L bit
processing, unrecognized subobjects etc) are as per the [RFC3209]. processing, unrecognized subobjects etc) are as per the [RFC3209].
Note that if a node is called upon to process subobject defined in Note that if a node is called upon to process subobject defined in
this document, and it does not recognize, it will behave as described this document, and it does not recognize, it will behave as described
in [RFC3209] when an unrecognized ERO subobject is encountered. This in [RFC3209] when an unrecognized ERO subobject is encountered. This
means that this node will return a PathErr with error code "Routing means that this node will return a PathErr with error code "Routing
Error" and error value "Bad EXPLICIT_ROUTE object" with the Error" and error value "Bad EXPLICIT_ROUTE object" with the
skipping to change at page 8, line 47 skipping to change at page 8, line 47
TBD3 ISIS Area id TBD3 ISIS Area id
3.3.1. Autonomous system 3.3.1. Autonomous system
[RFC3209] and [RFC4874] already define a 2-Byte AS number. [RFC3209] and [RFC4874] already define a 2-Byte AS number.
To support 4-Byte AS numbers as per [RFC6793], a subobject is with To support 4-Byte AS numbers as per [RFC6793], a subobject is with
the same format as defined in Section 3.2.1 with following the same format as defined in Section 3.2.1 with following
difference: difference:
The meaning of the L bit (similar to [RFC4874]). The meaning of the L bit is as per [RFC4874], where.
0: indicates that the abstract node (AS) specified MUST be excluded. 0: indicates that the abstract node specified MUST be excluded.
1: indicates that the abstract node (AS) specified SHOULD be avoided. 1: indicates that the abstract node specified SHOULD be avoided.
3.3.2. IGP Area 3.3.2. IGP Area
Since the length and format of Area-id is different for OSPF and Since the length and format of Area-id is different for OSPF and
ISIS, the following two subobjects are defined: ISIS, the following two subobjects are defined:
For OSPF, the area-id is a 32 bit number. Subobjects for OSPF and For OSPF, the area-id is a 32 bit number. Subobjects for OSPF and
IS-IS are of the same format as defined in Section 3.2.2 with IS-IS are of the same format as defined in Section 3.2.2 with
following difference: following difference:
The meaning of the L bit (similar to [RFC4874]). The meaning of the L bit is as per [RFC4874].
0: indicates that the abstract node (OSPF or IS-IS Area) specified
MUST be excluded.
1: indicates that the abstract node (OSPF or IS-IS Area) specified
SHOULD be avoided.
3.3.3. Mode of Operation 3.3.3. Mode of Operation
The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area The new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) Area
could also be used in the XRO to specify exclusion of an abstract could also be used in the XRO to specify exclusion of an abstract
node (a group of nodes whose internal topology is opaque to the node (a group of nodes whose internal topology is opaque to the
ingress node of the LSP). ingress node of the LSP).
All the rules of processing are as per the [RFC4874]. All the rules of processing are as per the [RFC4874].
skipping to change at page 10, line 29 skipping to change at page 10, line 24
parameters.xhtml. Within this registry IANA maintains two sub- parameters.xhtml. Within this registry IANA maintains two sub-
registries: registries:
o "EXPLICIT_ROUTE subobjects": http://www.iana.org/assignments/rsvp- o "EXPLICIT_ROUTE subobjects": http://www.iana.org/assignments/rsvp-
parameters/rsvp-parameters.xhtml#rsvp-parameters-25 parameters/rsvp-parameters.xhtml#rsvp-parameters-25
o "EXCLUDE_ROUTE subobjects": http://www.iana.org/assignments/rsvp- o "EXCLUDE_ROUTE subobjects": http://www.iana.org/assignments/rsvp-
parameters/rsvp-parameters.xhtml#rsvp-parameters-95 parameters/rsvp-parameters.xhtml#rsvp-parameters-95
Upon approval of this document, IANA is requested to make identical Upon approval of this document, IANA is requested to make identical
additions to these registries as follows: additions to these registries as follows, in sync with [PCE-DOMAIN]:
Subobject Type Reference Subobject Type Reference
TBD1 4-Byte AS number [This I.D.] TBD1 4-Byte AS number [This I.D.]
TBD2 OSPF Area ID [This I.D.] TBD2 OSPF Area ID [This I.D.]
TBD3 IS-IS Area ID [This I.D.] TBD3 IS-IS Area ID [This I.D.]
6. Security Considerations 6. Security Considerations
Security considerations for MPLS-TE and GMPLS signaling are covered Security considerations for MPLS-TE and GMPLS signaling are covered
in [RFC3209] and [RFC3473]. This document does not introduce any new in [RFC3209] and [RFC3473]. This document does not introduce any new
skipping to change at page 11, line 16 skipping to change at page 11, line 10
We would like to thank Adrian Farrel, Lou Berger, George Swallow, We would like to thank Adrian Farrel, Lou Berger, George Swallow,
Chirag Shah, Reeja Paul, Sandeep Boina and Avantika for their useful Chirag Shah, Reeja Paul, Sandeep Boina and Avantika for their useful
comments and suggestions. comments and suggestions.
8. References 8. References
8.1. Normative References 8.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,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation Protocol-
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, January 2003. (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<http://www.rfc-editor.org/info/rfc3477>.
[RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes -
Extension to Resource ReserVation Protocol-Traffic Extension to Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE)", RFC 4874, April 2007. Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
April 2007, <http://www.rfc-editor.org/info/rfc4874>.
[ISO10589] [ISO10589]
ISO, "Intermediate system to Intermediate system routing ISO, "Intermediate system to Intermediate system routing
information exchange protocol for use in conjunction with information exchange protocol for use in conjunction with
the Protocol for providing the Connectionless-mode Network the Protocol for providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, 1992. Service (ISO 8473)", ISO/IEC 10589:2002, 1992.
[PCE-DOMAIN]
Dhody, D., Palle, U., and R. Casellas, "Standard
Representation Of Domain Sequence. (draft-ietf-pce-pcep-
domain-sequence)", April 2015.
8.2. Informative References 8.2. Informative References
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for
Inter-Domain Multiprotocol Label Switching Traffic Inter-Domain Multiprotocol Label Switching Traffic
Engineering", RFC 4726, November 2006. Engineering", RFC 4726, DOI 10.17487/RFC4726, November
2006, <http://www.rfc-editor.org/info/rfc4726>.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Path Computation Method for Establishing Inter-Domain Per-Domain Path Computation Method for Establishing Inter-
Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC Domain Traffic Engineering (TE) Label Switched Paths
5152, February 2008. (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<http://www.rfc-editor.org/info/rfc5152>.
[RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
(PCE) Communication Protocol (PCEP)", RFC 5440, March Element (PCE) Communication Protocol (PCEP)", RFC 5440,
2009. DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[RFC5553] Farrel, A., Bradford, R., and JP. Vasseur, "Resource [RFC5553] Farrel, A., Ed., Bradford, R., and JP. Vasseur, "Resource
Reservation Protocol (RSVP) Extensions for Path Key Reservation Protocol (RSVP) Extensions for Path Key
Support", RFC 5553, May 2009. Support", RFC 5553, DOI 10.17487/RFC5553, May 2009,
<http://www.rfc-editor.org/info/rfc5553>.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
Extensions for Multi-Layer and Multi-Region Networks (MLN/ Extensions for Multi-Layer and Multi-Region Networks (MLN/
MRN)", RFC 6001, October 2010. MRN)", RFC 6001, DOI 10.17487/RFC6001, October 2010,
<http://www.rfc-editor.org/info/rfc6001>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, December Autonomous System (AS) Number Space", RFC 6793,
2012. DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>.
[PCE-DOMAIN]
Dhody, D., Palle, U., and R. Casellas, "Standard
Representation Of Domain Sequence. (draft-ietf-pce-pcep-
domain-sequence)", April 2015.
Appendix A. Examples Appendix A. Examples
These examples are for illustration purposes only, to show how the These examples are for illustration purposes only, to show how the
new subobjects could be encoded. They are not meant to be an new subobjects could be encoded. They are not meant to be an
exhaustive list of all possible usecases and combinations. exhaustive list of all possible usecases and combinations.
A.1. Inter-Area LSP Path Setup A.1. Inter-Area LSP Path Setup
In an inter-area LSP path setup where the ingress and the egress In an inter-area LSP path setup where the ingress and the egress
skipping to change at page 14, line 5 skipping to change at page 13, line 50
E2 Area E E2 Area E
* All IGP Area in one AS (AS 100) * All IGP Area in one AS (AS 100)
Figure 1: Domain Corresponding to IGP Area Figure 1: Domain Corresponding to IGP Area
As per Figure 1, the signaling at Ingress could be - As per Figure 1, the signaling at Ingress could be -
ERO:(A1, ABF1, Area B, Area C, Egress) ERO:(A1, ABF1, Area B, Area C, Egress)
It should be noted that there are other ways to achieve the desired
signaling, the area subobject provides another tool in the toolkit
and can have operational benefits when -
o Use of PCEP like domain-sequence [PCE-DOMAIN] configurations in
explicit path such that area subobjects can be used to signal the
loose path.
o Alignment of subobjects and registries between PCEP and RSVP-TE,
thus allowing easier interworking between path computation and
signaling i.e. to and fro of subobjects between signalling and
path computation (if need be).
A.2. Inter-AS LSP Path Setup A.2. Inter-AS LSP Path Setup
A.2.1. Example 1 A.2.1. Example 1
In an inter-AS LSP path setup where the ingress and the egress belong In an inter-AS LSP path setup where the ingress and the egress belong
to different AS, the domain subobjects (AS) could be used in an ERO. to different AS, the domain subobjects (AS) could be used in an ERO.
AS A AS E AS C AS A AS E AS C
<-------------> <----------> <-------------> <-------------> <----------> <------------->
 End of changes. 34 change blocks. 
58 lines changed or deleted 85 lines changed or added

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