draft-ietf-teas-rsvp-te-domain-subobjects-03.txt   draft-ietf-teas-rsvp-te-domain-subobjects-04.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: March 24, 2016 Huawei Technologies Expires: May 22, 2016 Huawei Technologies
R. Casellas R. Casellas
CTTC CTTC
September 21, 2015 November 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-03 draft-ietf-teas-rsvp-te-domain-subobjects-04
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.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 March 24, 2016. This Internet-Draft will expire on May 22, 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
skipping to change at page 2, line 25 skipping to change at page 2, line 25
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . . 7
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) . . . . . . . 9 4. Interaction with Path Computation Element (PCE) . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 14
A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 13 A.1. Inter-Area LSP Path Setup . . . . . . . . . . . . . . . . 14
A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 14 A.2. Inter-AS LSP Path Setup . . . . . . . . . . . . . . . . . 15
A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 14 A.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 15
A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 15 A.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 3, line 41 skipping to change at page 3, line 41
(PCEP) extensions for the domain sequence [PCE-DOMAIN]. (PCEP) extensions for the domain sequence [PCE-DOMAIN].
1.1. Scope 1.1. Scope
The procedures described in this document are experimental. The The procedures described in this document are experimental. The
experiment is intended to enable research for the usage of Domain experiment is intended to enable research for the usage of Domain
subobjects for inter-domain path setup. For this purpose this subobjects for inter-domain path setup. For this purpose this
document specify new domain subobjects as well as how they document specify new domain subobjects as well as how they
incorporate with existing subobjects. incorporate with existing subobjects.
The experiment will end two years after the RFC is published. At
that point, the RFC authors will attempt to determine how widely this
has been implemented and deployed.
This document does not change the procedures for handling subobjects This document does not change the procedures for handling subobjects
in RSVP-TE. in RSVP-TE.
The new subobjects introduced by this document will not be understood The new subobjects introduced by this document will not be understood
by legacy implementations. If one of the subobjects is received in a by legacy implementations. If a legacy implementation receives one
RSVP-TE object that does not understand it, it will behave as of the subobjects that it does not understand in an RSVP-TE object,
described in [RFC3209] and [RFC4874]. Therefore, it is assumed that the legacy implementation will behave as described in [RFC3209] and
this experiment will be conducted only when all nodes processing the [RFC4874]. Therefore, it is assumed that this experiment will be
new subobject form part of the experiment. conducted only when all nodes processing the 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 It should be noted that there are other ways such as use of boundary
node to identify the domain (instead of domain identifier), the node to identify the domain (instead of domain identifier), the
mechanism defined in this document is just another tool in the mechanism defined in this document is just another tool in the
toolkit for the operator. toolkit for the operator.
skipping to change at page 9, line 31 skipping to change at page 9, line 41
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].
Note that if a node is called upon to process a subobject defined in Note that if a node is called upon to process a 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 [RFC4874] when an unrecognized XRO subobject is encountered, i.e. in [RFC4874] when an unrecognized XRO subobject is encountered, i.e.
to ignore it. In this case the desired exclusion will not be carried to ignore it. In this case the desired exclusion will not be carried
out. out.
IGP Area subobjects in the XRO are local to the current AS. In case
of multi-AS path computation to exclude an IGP area in a different
AS, IGP Area subobject should be part of Explicit Exclusion Route
Subobject (EXRS) in the ERO to specify the AS in which the IGP area
is to be excluded. Further policy may be applied to prune/ignore
Area subobjects in XRO at AS boundary.
3.4. Explicit Exclusion Route Subobject 3.4. Explicit Exclusion Route Subobject
As per [RFC4874], the Explicit Exclusion Route is used to specify As per [RFC4874], the Explicit Exclusion Route is used to specify
exclusion of certain abstract nodes between a specific pair of nodes exclusion of certain abstract nodes between a specific pair of nodes
or resources in the explicit route. EXRS is an ERO subobject that or resources in the explicit route. EXRS is an ERO subobject that
contains one or more subobjects of its own, called EXRS subobjects. contains one or more subobjects of its own, called EXRS subobjects.
The EXRS subobject could carry any of the subobjects defined for XRO, The EXRS subobject could carry any of the subobjects defined for XRO,
thus the new subobjects to support 4-Byte AS and IGP (OSPF / ISIS) thus the new subobjects to support 4-Byte AS and IGP (OSPF / ISIS)
Area can also be used in the EXRS. The meanings of the fields of the Area can also be used in the EXRS. The meanings of the fields of the
skipping to change at page 10, line 4 skipping to change at page 10, line 21
an EXRS, except that scope of the exclusion is limited to the single an EXRS, except that scope of the exclusion is limited to the single
hop between the previous and subsequent elements in the ERO. hop between the previous and subsequent elements in the ERO.
All the rules of processing are as per the [RFC4874]. All the rules of processing are as per the [RFC4874].
4. Interaction with Path Computation Element (PCE) 4. Interaction with Path Computation Element (PCE)
The domain subobjects to be used in Path Computation Element Protocol The domain subobjects to be used in Path Computation Element Protocol
(PCEP) are referred to in [PCE-DOMAIN]. Note that the new domain (PCEP) are referred to in [PCE-DOMAIN]. Note that the new domain
subobjects follow the principle that subobjects used in PCEP subobjects follow the principle that subobjects used in PCEP
[RFC5440] are identical to the subobjects used in RSVP-TE and thus [RFC5440] are identical to the subobjects used in RSVP-TE and thus
are interchangeable between PCEP and RSVP-TE. are interchangeable between PCEP and RSVP-TE.
5. IANA Considerations 5. IANA Considerations
5.1. New Subobjects 5.1. New Subobjects
IANA maintains the "Resource Reservation Protocol (RSVP) Parameters" IANA maintains the "Resource Reservation Protocol (RSVP) Parameters"
at http://www.iana.org/assignments/rsvp-parameters/rsvp- at <http://www.iana.org/assignments/rsvp-parameters>. Within this
parameters.xhtml. Within this registry IANA maintains two sub- 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/
parameters/rsvp-parameters.xhtml#rsvp-parameters-25 rsvp-parameters#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-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, in sync with [PCE-DOMAIN]: 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.][PCE-DOMAIN]
TBD2 OSPF Area ID [This I.D.] TBD2 OSPF Area ID [This I.D.][PCE-DOMAIN]
TBD3 IS-IS Area ID [This I.D.] TBD3 IS-IS Area ID [This I.D.][PCE-DOMAIN]
Further upon approval of this document, IANA is requested to add a
reference to this document to the new PCEP numbers that are
registered by [PCE-DOMAIN].
6. Security Considerations 6. Security Considerations
Security considerations for MPLS-TE and GMPLS signaling are covered Security considerations for RSVP-TE and GMPLS signaling RSVP-TE
in [RFC3209] and [RFC3473]. This document does not introduce any new extensions are covered in [RFC3209] and [RFC3473]. This document
messages or any substantive new processing, and so those security does not introduce any new messages or any substantive new
considerations continue to apply. Further, general considerations processing, and so those security considerations continue to apply.
for securing RSVP-TE in MPLS-TE and GMPLS networks can be found in Further, general considerations for securing RSVP-TE in MPLS-TE and
[RFC5920]. GMPLS networks can be found in [RFC5920]. The section 8 of [RFC5920]
describes the inter-provider security considerations, which continue
to apply.
The route exclusion security consideration are covered in [RFC4874] The route exclusion security consideration are covered in [RFC4874]
and continue to apply. and continue to apply.
7. Acknowledgments 7. Acknowledgments
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.
Thanks to Vishnu Pavan Beeram for shepherding this document.
Thanks to Brian Carpenter for Gen-ART Review.
Thanks to Liang Xia (Frank) for SecDir Review.
Thanks to Spencer Dawkins and Barry Leiba for comments during the
IESG Review.
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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <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.,
skipping to change at page 11, line 42 skipping to change at page 12, line 22
Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874,
April 2007, <http://www.rfc-editor.org/info/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] [PCE-DOMAIN]
Dhody, D., Palle, U., and R. Casellas, "Standard Dhody, D., Palle, U., and R. Casellas, "Domain Subobjects
Representation Of Domain Sequence. (draft-ietf-pce-pcep- for Path Computation Element (PCE) Communication Protocol
domain-sequence)", September 2015. (PCEP). (draft-ietf-pce-pcep-domain-sequence)", November
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, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <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
 End of changes. 19 change blocks. 
40 lines changed or deleted 66 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/