draft-ietf-pce-pcep-domain-sequence-06.txt		draft-ietf-pce-pcep-domain-sequence-07.txt
	PCE Working Group D. Dhody		PCE Working Group D. Dhody
	Internet-Draft U. Palle		Internet-Draft U. Palle
	Intended status: Experimental Huawei Technologies		Intended status: Experimental Huawei Technologies
	Expires: April 25, 2015 R. Casellas		Expires: July 3, 2015 R. Casellas
	CTTC		CTTC
	October 22, 2014		December 30, 2014
	Standard Representation Of Domain-Sequence		Standard Representation of Domain-Sequence
	draft-ietf-pce-pcep-domain-sequence-06		draft-ietf-pce-pcep-domain-sequence-07
	Abstract		Abstract
	The ability to compute shortest constrained Traffic Engineering Label		The ability to compute shortest constrained Traffic Engineering Label
	Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and		Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
	Generalized MPLS (GMPLS) networks across multiple domains has been		Generalized MPLS (GMPLS) networks across multiple domains has been
	identified as a key requirement. In this context, a domain is a		identified as a key requirement. In this context, a domain is a
	collection of network elements within a common sphere of address		collection of network elements within a common sphere of address
	management or path computational responsibility such as an Interior		management or path computational responsibility such as an Interior
	Gateway Protocol (IGP) area or an Autonomous Systems (AS). This		Gateway Protocol (IGP) area or an Autonomous System (AS). This
	document specifies a standard representation and encoding of a		document specifies a standard representation and encoding of a
	Domain-Sequence, which is defined as an ordered sequence of domains		Domain-Sequence, which is defined as an ordered sequence of domains
	traversed to reach the destination domain to be used by Path		traversed to reach the destination domain to be used by Path
	Computation Elements (PCEs) to compute inter-domain shortest		Computation Elements (PCEs) to compute inter-domain constrained
	constrained paths across a predetermined sequence of domains . This		shortest paths across a predetermined sequence of domains . This
	document also defines new subobjects to be used to encode domain		document also defines new subobjects to be used to encode domain
	identifiers.		identifiers.
	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 April 25, 2015.		This Internet-Draft will expire on July 3, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 34		skipping to change at page 2, line 34
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Detail Description . . . . . . . . . . . . . . . . . . . . . 5		3. Detail Description . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 5		3.2. Domain-Sequence . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Standard Representation . . . . . . . . . . . . . . . . . 6		3.3. Standard Representation . . . . . . . . . . . . . . . . . 6
	3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7		3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 7
	3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 7		3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 7
	3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8		3.4.1.1. Autonomous system . . . . . . . . . . . . . . . . 8
	3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 8		3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 8
	3.4.2. Update in IRO specification . . . . . . . . . . . . . 9		3.4.2. Update in IRO specification . . . . . . . . . . . . . 9
	3.4.3. IRO for domain-sequence . . . . . . . . . . . . . . . 10		3.4.3. IRO for Domain-Sequence . . . . . . . . . . . . . . . 10
	3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 11		3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 11
	3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12		3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 12
	3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 12		3.5.1.1. Autonomous system . . . . . . . . . . . . . . . . 12
	3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13		3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 13
	3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 14		3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 14
	3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 14		3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 14
	4. Other Considerations . . . . . . . . . . . . . . . . . . . . 15		4. Other Considerations . . . . . . . . . . . . . . . . . . . . 15
	4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 15		4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 15
	4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 17		4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 17
	4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17		4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 17
	skipping to change at page 3, line 23		skipping to change at page 3, line 23
	7.6. Impact On Network Operations . . . . . . . . . . . . . . 27		7.6. Impact On Network Operations . . . . . . . . . . . . . . 27
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
	9.1. Normative References . . . . . . . . . . . . . . . . . . 27		9.1. Normative References . . . . . . . . . . . . . . . . . . 27
	9.2. Informative References . . . . . . . . . . . . . . . . . 27		9.2. Informative References . . . . . . . . . . . . . . . . . 27
	1. Introduction		1. Introduction
	A PCE may be used to compute end-to-end paths across multi-domain		A PCE may be used to compute end-to-end paths across multi-domain
	environments using a per-domain path computation technique [RFC5152].		environments using a per-domain path computation technique [RFC5152].
	The so called backward recursive path computation (BRPC) mechanism		The backward recursive path computation (BRPC) mechanism [RFC5441]
	[RFC5441] defines a PCE-based path computation procedure to compute		also defines a PCE-based path computation procedure to compute inter-
	inter-domain constrained (G)MPLS TE LSPs. However, both per-domain		domain constrained path for (G)MPLS TE LSPs. However, both per-
	and BRPC techniques assume that the sequence of domains to be crossed		domain and BRPC techniques assume that the sequence of domains to be
	from source to destination is known, either fixed by the network		crossed from source to destination is known, either fixed by the
	operator or obtained by other means. Also for inter-domain point-to-		network operator or obtained by other means. Also for inter-domain
	multi-point (P2MP) tree computation, [RFC7334] assumes the domain-		point-to-multi-point (P2MP) tree computation, [RFC7334] assumes the
	tree is known in priori.		domain-tree is known in priori.
	The list of domains (domain-sequence) in a point-to-point (P2P) path		The list of domains (Domain-Sequence) in point-to-point (P2P) or a
	or a point-to-multipoint (P2MP) tree is usually a constraint in the		domain tree in point-to-multipoint (P2MP) is usually a constraint in
	path computation request. A PCE determines the next PCE to forward		inter-domain path computation procedure. A PCE determines the next
	the request based on the domain-sequence. In a multi-domain path		PCE to forward the request based on the Domain-Sequence. In a multi-
	computation, a PCC MAY indicate the sequence of domains to be		domain path computation, a Path Computation Client (PCC) MAY indicate
	traversed using the Include Route Object (IRO) defined in [RFC5440].		the sequence of domains to be traversed using the Include Route
			Object (IRO) defined in [RFC5440].
	When the sequence of domains is not known in advance, the		When the sequence of domains is not known in advance, the
	Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be		Hierarchical PCE (H-PCE) [RFC6805] architecture and mechanisms can be
	used to determine the end-to-end Domain-Sequence.		used to determine the Domain-Sequence.
	This document defines a standard way to represent and encode a		This document defines a standard way to represent and encode a
	Domain-Sequence in various deployment scenarios including P2P, P2MP		Domain-Sequence in various scenarios including P2P LSP, P2MP LSP, and
	and H-PCE.		use of H-PCE.
	The Domain-Sequence (the set of domains traversed to reach the		The Domain-Sequence (the set of domains traversed to reach the
	destination domain) is either administratively predetermined or		destination domain) is either administratively predetermined or
	discovered by some means (H-PCE) that is outside of the scope of this		discovered by some means like H-PCE.
	document.
	[RFC5440] defines the Include Route Object (IRO) and the Explicit		[RFC5440] defines the Include Route Object (IRO) and the Explicit
	Route Object (ERO); [RFC5521] defines the Exclude Route Object (XRO)		Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO)
	and the Explicit Exclusion Route Subobject (EXRS); The use of		and the Explicit Exclusion Route Subobject (EXRS). The use of
	Autonomous System (AS) (albeit with a 2-Byte AS number) as an		Autonomous System (AS) (albeit with a 2-Byte AS number) as an
	abstract node representing domain is defined in [RFC3209], this		abstract node representing a domain is defined in [RFC3209], this
	document specifies new subobjects to include or exclude domains such		document specifies new subobjects to include or exclude domains
	as an IGP area or an Autonomous Systems (4-Byte as per [RFC4893]).		including IGP area or an Autonomous Systems (4-Byte as per
			[RFC6793]).
	Further, the domain identifier may simply act as delimiter to specify		Further, the domain identifier may simply act as delimiter to specify
	where the domain boundary starts and ends.		where the domain boundary starts and ends in some cases.
	This is a companion document to Resource ReserVation Protocol -		This is a companion document to Resource ReserVation Protocol -
	Traffic Engineering (RSVP-TE) extensions for the domain identifiers		Traffic Engineering (RSVP-TE) extensions for the domain identifiers
	[DOMAIN-SUBOBJ].		[DOMAIN-SUBOBJ].
	1.1. Requirements Language		1.1. 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].
	skipping to change at page 4, line 44		skipping to change at page 4, line 45
	ASBR: Autonomous System Boundary Router.		ASBR: Autonomous System Boundary Router.
	BN: Boundary Node, Can be an ABR or ASBR.		BN: Boundary Node, Can be an ABR or ASBR.
	BRPC: Backward Recursive Path Computation		BRPC: Backward Recursive Path Computation
	Domain: As per [RFC4655], any collection of network elements within		Domain: As per [RFC4655], any collection of network elements within
	a common sphere of address management or path computational		a common sphere of address management or path computational
	responsibility. Examples of domains include Interior Gateway		responsibility. Examples of domains include Interior Gateway
	Protocol (IGP) areas and Autonomous Systems (ASs).		Protocol (IGP) area and Autonomous System (AS).
	Domain-Sequence: An ordered sequence of domains traversed to reach		Domain-Sequence: An ordered sequence of domains traversed to reach
	the destination domain.		the destination domain.
	ERO: Explicit Route Object		ERO: Explicit Route Object
	H-PCE: Hierarchical PCE		H-PCE: Hierarchical PCE
	IGP: Interior Gateway Protocol. Either of the two routing		IGP: Interior Gateway Protocol. Either of the two routing
	protocols, Open Shortest Path First (OSPF) or Intermediate System		protocols, Open Shortest Path First (OSPF) or Intermediate System
	to Intermediate System (IS-IS).		to Intermediate System (IS-IS).
	skipping to change at page 5, line 43		skipping to change at page 5, line 43
	3.1. Domains		3.1. Domains
	[RFC4726] and [RFC4655] define domain as a separate administrative or		[RFC4726] and [RFC4655] define domain as a separate administrative or
	geographic environment within the network. A domain may be further		geographic environment within the network. A domain may be further
	defined as a zone of routing or computational ability. Under these		defined as a zone of routing or computational ability. Under these
	definitions a domain might be categorized as an AS or an IGP area.		definitions a domain might be categorized as an AS or an IGP area.
	Each AS can be made of several IGP areas. In order to encode a		Each AS can be made of several IGP areas. In order to encode a
	Domain-Sequence, it is required to uniquely identify a domain in the		Domain-Sequence, it is required to uniquely identify a domain in the
	Domain-Sequence. A domain can be uniquely identified by area-id or		Domain-Sequence. A domain can be uniquely identified by area-id or
	AS or both.		AS number or both.
	3.2. Domain-Sequence		3.2. Domain-Sequence
	A domain-sequence is an ordered sequence of domains traversed to		A Domain-Sequence is an ordered sequence of domains traversed to
	reach the destination domain.		reach the destination domain.
	A domain-sequence can be applied as a constraint and carried in path		A Domain-Sequence can be applied as a constraint and carried in a
	computation request to PCE(s). A domain-sequence can also be the		path computation request to PCE(s). A Domain-Sequence can also be
	result of a path computation. For example, in the case of H-PCE		the result of a path computation. For example, in the case of H-PCE
	[RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a		[RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a
	path computation reply.		path computation reply.
	In a P2P path, the domains listed appear in the order that they are		In a P2P path, the domains listed appear in the order that they are
	crossed. In a P2MP path, the domain tree is represented as list of		crossed. In a P2MP path, the domain tree is represented as a list of
	domain sequences.		Domain-Sequences.
	A domain-sequence enables a PCE to select the next PCE to forward the		A Domain-Sequence enables a PCE to select the next domain and the PCE
	path computation request based on the domain information.		serving that domain to forward the path computation request based on
			the domain information.
	A PCC or PCE MAY add an additional constraints covering which		A PCC or PCE MAY add an additional constraint covering which Boundary
	Boundary Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be		Nodes (ABR or ASBR) or Border links (Inter-AS-links) MUST be
	traversed while defining a Domain-Sequence.		traversed while defining a Domain-Sequence.
	Thus a Domain-Sequence MAY be made up of one or more of -		Thus a Domain-Sequence MAY be made up of one or more of -
	o AS Number		o AS Number
	o Area ID		o Area ID
	o Boundary Node ID		o Boundary Node ID
	o Inter-AS-Link Address		o Inter-AS-Link Address
	Consequently, a Domain-Sequence can be used:		Consequently, a Domain-Sequence can be used:
	1. by a PCE in order to discover or select the next PCE in a		1. by a PCE in order to discover or select the next PCE in a
	collaborative path computation, such as in BRPC [RFC5441];		collaborative path computation, such as in BRPC [RFC5441];
	2. by the Parent PCE to return the Domain-Sequence when unknown,		2. by the Parent PCE to return the Domain-Sequence when unknown;
	this can further be an input to BRPC procedure [RFC6805];		this can then be an input to the BRPC procedure [RFC6805];
	3. by a PCC (or PCE) to constraint the domains used in a H-PCE path		3. by a PCC (or PCE) to constraint the domains used in a H-PCE path
	computation, explicitly specifying which domains to be expanded;		computation, explicitly specifying which domains to be expanded;
	4. by a PCE in per-domain path computation model [RFC5152] to		4. by a PCE in the per-domain path computation model [RFC5152] to
	identify the next domain(s);		identify the next domain;
	3.3. Standard Representation		3.3. Standard Representation
	Domain-Sequence MAY appear in PCEP Messages, notably in -		Domain-Sequence MAY appear in PCEP messages, notably in -
	o Include Route Object (IRO): As per [RFC5440], used to specify set		o Include Route Object (IRO): As per [RFC5440], used to specify set
	of network elements that MUST be traversed. The subobjects in IRO		of network elements that MUST be traversed. The subobjects in IRO
	are used to specify the domain-sequence that MUST be traversed to		are used to specify the Domain-Sequence that MUST be traversed to
	reach the destination.		reach the destination.
	o Exclude Route Object (XRO): As per [RFC5521], used to specify		o Exclude Route Object (XRO): As per [RFC5521], used to specify
	certain abstract nodes that MUST be excluded from whole path. The		certain abstract nodes that MUST be excluded from whole path. The
	subobjects in XRO are used to specify certain domains that MUST be		subobjects in XRO are used to specify certain domains that MUST be
	avoided to reach the destination.		avoided to reach the destination.
	o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used		o Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], used
	to specify exclusion of certain abstract nodes between a specific		to specify exclusion of certain abstract nodes between a specific
	pair of nodes. EXRS are a subobject inside the IRO. These		pair of nodes. EXRS are a subobject inside the IRO. These
	subobjects are used to specify the domains that must be excluded		subobjects are used to specify the domains that must be excluded
	between two abstract nodes.		between two abstract nodes.
	o Explicit Route Object (ERO): As per [RFC5440], used to specify a		o Explicit Route Object (ERO): As per [RFC5440], used to specify a
	computed path in the network. For example, in the case of H-PCE		computed path in the network. For example, in the case of H-PCE
	[RFC6805] Parent PCE MAY send the Domain-Sequence as a result in a		[RFC6805], a Parent PCE MAY send the Domain-Sequence as a result
	path computation reply using ERO.		in a path computation reply using ERO.
	3.4. Include Route Object (IRO)		3.4. Include Route Object (IRO)
	As per [RFC5440], IRO (Include Route Object) can be used to specify		As per [RFC5440], IRO (Include Route Object) can be used to specify
	that the computed path MUST traverse a set of specified network		that the computed path MUST traverse a set of specified network
	elements or abstract nodes.		elements or abstract nodes.
	3.4.1. Subobjects		3.4.1. Subobjects
	Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and		Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477] and
	skipping to change at page 8, line 9		skipping to change at page 8, line 9
	Type Subobject		Type Subobject
	TBD1 Autonomous system number (4 Byte)		TBD1 Autonomous system number (4 Byte)
	TBD2 OSPF Area id		TBD2 OSPF Area id
	TBD3 ISIS Area id		TBD3 ISIS Area id
	3.4.1.1. Autonomous system		3.4.1.1. Autonomous system
	[RFC3209] already defines 2 byte AS number.		[RFC3209] already defines 2 byte AS number.
	To support 4 byte AS number as per [RFC4893] following subobject is		To support 4 byte AS number as per [RFC6793] following subobject is
	defined:		defined:
	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) |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 9, line 48		skipping to change at page 9, line 48
	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.4.2. Update in IRO specification		3.4.2. Update in IRO specification
	[RFC5440] describes IRO as an optional object used to specify that		[RFC5440] describes IRO as an optional object used to specify that
	the computed path MUST traverse a set of specified network elements.		the computed path MUST traverse a set of specified network elements.
	It further state that the L bit of such sub-object has no meaning		It further state that the L bit of such subobject has no meaning
	within an IRO. It did not mention if IRO is an ordered or un-ordered		within an IRO. It did not mention if IRO is an ordered or un-ordered
	list of sub-objects.		list of subobjects.
	An update to IRO specification [IRO-UPDATE] makes IRO as an ordered		An update to IRO specification [IRO-UPDATE] makes IRO as an ordered
	list as well as support for loose bit (L-bit).		list as well as support for loose bit (L-bit).
	The use IRO for domain-sequence assumes the updated specification for		The use IRO for Domain-Sequence assumes the updated specification for
	IRO as per [IRO-UPDATE].		IRO as per [IRO-UPDATE].
	3.4.3. IRO for domain-sequence		3.4.3. IRO for Domain-Sequence
	Some subobjects for IRO are defined in [RFC3209], [RFC3473],		Some subobjects for the IRO are defined in [RFC3209], [RFC3473],
	[RFC3477] and [RFC4874], further some new subobjects related to		[RFC3477], and [RFC4874]; further some new subobjects related to
	Domain-Sequence are also added in this document as mentioned in		Domain-Sequence are also added in this document as mentioned in
	Section 3.4.		Section 3.4.
	The subobjects for IPv4, IPv6 and unnumbered Interface ID can be used		The subobject type for IPv4, IPv6, and unnumbered Interface ID can be
	to specify Boundary Node (ABR/ASBR) and Inter-AS-Links. The		used to specify Boundary Nodes (ABR/ASBR) and Inter-AS-Links. The
	subobjects for AS Number (2 or 4 Byte) and IGP Area is used to		subobject type for the AS Number (2 or 4 Byte) and the IGP Area are
	specify the domain identifiers in the domain-sequence.		used to specify the domain identifiers in the Domain-Sequence.
	The IRO MAY have both intra-domain (from the context of the ingress		The IRO MAY have both intra-domain (from the context of the ingress
	PCC) and inter-domain (domain-sequence) subobjects in a sequence in		PCC) and inter-domain (Domain-Sequence) subobjects in a sequence in
	which they must be traversed in the computed path.		which they must be traversed in the computed path.
	Thus an IRO comprising of subobjects that represents a domain-		Thus an IRO, comprising of subobjects that represents a Domain-
	sequence may constraints or define the domains involved in an inter-		Sequence, define the domains involved in an inter-domain path
	domain path computation, typically involving two or more		computation, typically involving two or more collaborative PCEs.
	collaborative PCEs.
	A Domain-Sequence can have varying degrees of granularity; it is		A Domain-Sequence can have varying degrees of granularity. It is
	possible to have a Domain-Sequence composed of, uniquely, AS		possible to have a Domain-Sequence composed of, uniquely, AS
	identifiers. It is also possible to list the involved areas for a		identifiers. It is also possible to list the involved IGP areas for
	given AS.		a given AS.
	In any case, the mapping between domains and responsible PCEs is not		In any case, the mapping between domains and responsible PCEs is not
	defined in this document. It is assumed that a PCE that needs to		defined in this document. It is assumed that a PCE that needs to
	obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via		obtain a "next PCE" from a Domain-Sequence is able to do so (e.g. via
	administrative configuration, or discovery).		administrative configuration, or discovery).
	A PCC builds an IRO to encode the Domain-Sequence, that the		A PCC builds an IRO to encode the Domain-Sequence, so that the
	cooperating PCEs should compute an inter-domain shortest constrained		cooperating PCEs should compute an inter-domain shortest constrained
	paths across the specified sequence of domains.		path across the specified sequence of domains.
	For each inclusion, the PCC clears the L-bit to indicate that the PCE		For each inclusion, the PCC clears the L-bit to indicate that the PCE
	is required to include the domain, or sets the L-bit to indicate that		is required to include the domain, or sets the L-bit to indicate that
	the PCC simply desires that the domain be included in the domain-		the PCC simply desires that the domain be included in the Domain-
	sequence.		Sequence.
	If a PCE encounters a subobject that it does not support or		If a PCE encounters a subobject that it does not support or
	recognize, it MUST act according to the setting of the L-bit in the		recognize, it MUST act according to the setting of the L-bit in the
	subobject. If the L-bit is clear, the PCE MUST respond with a PCErr		subobject. If the L-bit is clear, the PCE MUST respond with a PCErr
	with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value		with Error-Type TBD4 "Unrecognized subobject" and set the Error-Value
	to the subobject type code. If the L-bit is set, the PCE MAY respond		to the subobject type code. If the L-bit is set, the PCE MAY respond
	with a PCErr as already stated or MAY ignore the subobject: this		with a PCErr as already stated or MAY ignore the subobject: this
	choice is a local policy decision.		choice is a local policy decision.
	PCE MUST act according to the requirements expressed in the		PCE MUST act according to the requirements expressed in the
	subobject. That is, if the L-bit is clear, the PCE(s) MUST produce a		subobject. That is, if the L-bit is clear, the PCE(s) MUST produce a
	path that follows domain-sequence nodes in order identified by the		path that follows the Domain-Sequence in order identified by the
	subobjects in the path. If the L-bit is set, the PCE(s) SHOULD		subobjects in the path. If the L-bit is set, the PCE(s) SHOULD
	produce a path along the Domain-Sequence unless it is not possible to		produce a path along the Domain-Sequence unless it is not possible to
	construct a path complying with the other constraints expressed in		construct a path complying with the other constraints expressed in
	the request.		the request.
	A successful path computation reported in a PCEP reply message		A successful path computation reported in a path computation reply
	(PCRep) MUST include an ERO to specify the path that has been		message (PCRep) MUST include an ERO to specify the path that has been
	computed as specified in [RFC5440] following the sequence of domains.		computed as specified in [RFC5440] following the sequence of domains.
	In a PCRep, PCE MAY also supply IRO (with domain sequence		In a PCRep, PCE MAY also supply IRO (with Domain-Sequence
	information) with the NO-PATH object indicating that the set of		information) with the NO-PATH object indicating that the set of
	elements (domains) of the request's IRO prevented the PCEs from		elements (domains) of the request's IRO prevented the PCEs from
	finding a path.		finding a path.
	The Subobject types for domains (AS and IGP Area) affect the next		Selection of the next domain and the PCE serving that domain is
	domain selection as well as finding the PCE serving that domain.		dependent on the domain subobjects (AS and IGP area) in the IRO.
	Note that a particular domain in the domain-sequence can be		Note that a particular domain in the Domain-Sequence can be
	identified by :-		identified by :-
	o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is		o A single IGP Area: Only the IGP (OSPF or ISIS) Area subobject is
	used to identify the next domain. (Refer Figure 1)		used to identify the next domain. (Refer Figure 1)
	o A single AS: Only the AS subobject is used to identify the next		o A single AS: Only the AS subobject is used to identify the next
	domain. (Refer Figure 2)		domain. (Refer Figure 2)
	o Both an AS and an IGP Area: Combination of both AS and Area are		o Both an AS and an IGP Area: AS and Area in combination are used to
	used to identify the next domain. In this case the order is AS		identify the next domain. In this case the order is AS Subobject
	Subobject followed by Area. (Refer Figure 3)		followed by Area. (Refer Figure 3)
	The Subobjects representing an internal node, a Boundary Node or an		The Subobjects representing an internal node, a Boundary Node or an
	Inter-AS-Link MAY influence the selection of the path as well.		Inter-AS-Link MAY also influence the selection of the path.
	3.5. Exclude Route Object (XRO)		3.5. Exclude Route Object (XRO)
	The Exclude Route Object (XRO) [RFC5521] is an optional object used		The Exclude Route Object (XRO) [RFC5521] is an optional object used
	to specify exclusion of certain abstract nodes or resources from the		to specify exclusion of certain abstract nodes or resources from the
	whole path.		whole path.
	3.5.1. Subobjects		3.5.1. Subobjects
	The following subobject types are defined to be used in XRO as		The following subobject types are defined to be used in XRO as
	skipping to change at page 15, line 31		skipping to change at page 15, line 31
	TBD2 OSPF Area id		TBD2 OSPF Area id
	TBD3 ISIS Area id		TBD3 ISIS Area id
	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
	MAY also be used in the ERO to specify an abstract node (a group of		MAY also 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). Using this concept of abstraction, an explicitly routed LSP		LSP). Using this concept of abstraction, an explicitly routed LSP
	can be specified as a sequence of domains.		can be specified as a sequence of domains.
	In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested		In case of Hierarchical PCE [RFC6805], a Parent PCE MAY be requested
	to find the domain-sequence. Refer example in Section 4.6.		to find the Domain-Sequence. Refer example in Section 4.6.
	The format of the new ERO subobjects is similar to new IRO		The format of the new ERO subobjects is similar to new IRO
	subobjects, refer Section 3.4.		subobjects, refer Section 3.4.
	4. Other Considerations		4. Other Considerations
	The examples in this section are for illustration purposes only; to		The examples in this section are for illustration purposes only; to
	show how the new subobjects may be encoded.		highlight how the new subobjects may be encoded.
	4.1. Inter-Area Path Computation		4.1. Inter-Area Path Computation
	In an inter-area path computation where the ingress and the egress		In an inter-area path computation where the ingress and the egress
	nodes belong to different IGP areas within the same AS, the Domain-		nodes belong to different IGP areas within the same AS, the Domain-
	Sequence MAY be represented using a ordered list of Area subobjects.		Sequence MAY be represented using a ordered list of Area subobjects.
	The AS number MAY be skipped, as area information is enough to select		The AS number MAY be skipped, as area information is enough to select
	the next PCE.		the next PCE.
	+-------------------+ +-------------------+		+-------------------+ +-------------------+
	skipping to change at page 19, line 27		skipping to change at page 19, line 27
	| | | | | | | | | |		| | | | | | | | | |
	| | | | | | | | | |		| | | | | | | | | |
	+---------+ +---------+ +---------+ +---------+ +---------+		+---------+ +---------+ +---------+ +---------+ +---------+
	Area subobject is optional and it MAY be skipped. PCE should be able		Area subobject is optional and it MAY be skipped. PCE should be able
	to understand both notations.		to understand both notations.
	4.2.2. Example 2		4.2.2. Example 2
	As shown in Figure 3, where AS 200 is made up of multiple areas and		As shown in Figure 3, where AS 200 is made up of multiple areas and
	multiple domain-sequence exist, PCE MAY include both AS and Area		multiple Domain-Sequence exist, PCE MAY include both AS and Area
	subobject to uniquely identify the next domain and PCE.		subobject to uniquely identify the next domain and PCE.
	|		|
	| +-------------+ +----------------+		| +-------------+ +----------------+
	| |Area 2 | |Area 4 |		| |Area 2 | |Area 4 |
	| | +--+| | +--+ |		| | +--+| | +--+ |
	| | | || | | | |		| | | || | | | |
	| | +--+ +--+| | +--+ +--+ |		| | +--+ +--+| | +--+ +--+ |
	| | | | | | | | |		| | | | | | | | |
	| | *--+ | | +--+ |		| | *--+ | | +--+ |
	skipping to change at page 21, line 15		skipping to change at page 21, line 15
	If the area information cannot be provided, PCE MAY forward the path		If the area information cannot be provided, PCE MAY forward the path
	computation request to the next PCE based on AS alone. If multiple		computation request to the next PCE based on AS alone. If multiple
	PCEs are responsible, PCE MAY apply local policy to select the next		PCEs are responsible, PCE MAY apply local policy to select the next
	PCE.		PCE.
	4.3. Boundary Node and Inter-AS-Link		4.3. Boundary Node and Inter-AS-Link
	A PCC or PCE MAY add additional constraints covering which Boundary		A PCC or PCE MAY add additional constraints covering which Boundary
	Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed		Nodes (ABR or ASBR) or Border links (Inter-AS-link) MUST be traversed
	while defining a Domain-Sequence. In which case the Boundary Node or		while defining a Domain-Sequence. In which case the Boundary Node or
	Link MAY be encoded as a part of the domain-sequence using the		Link MAY be encoded as a part of the Domain-Sequence using the
	existing subobjects.		existing subobjects.
	Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6		Boundary Nodes (ABR / ASBR) can be encoded using the IPv4 or IPv6
	prefix subobjects usually the loopback address of 32 and 128 prefix		prefix subobjects usually the loopback address of 32 and 128 prefix
	length respectively. An Inter-AS link can be encoded using the IPv4		length respectively. An Inter-AS link can be encoded using the IPv4
	or IPv6 prefix subobjects or unnumbered interface subobjects.		or IPv6 prefix subobjects or unnumbered interface subobjects.
	For Figure 1, an ABR to be traversed can be specified as:		For Figure 1, an ABR to be traversed can be specified as:
	+---------+ +---------+ +---------++---------+ +---------+		+---------+ +---------+ +---------++---------+ +---------+
	skipping to change at page 22, line 8		skipping to change at page 22, line 8
	4.4. PCE Serving multiple Domains		4.4. PCE Serving multiple Domains
	A single PCE MAY be responsible for multiple domains; for example PCE		A single PCE MAY be responsible for multiple domains; for example PCE
	function deployed on an ABR. A PCE which can support 2 adjacent		function deployed on an ABR. A PCE which can support 2 adjacent
	domains can internally handle this situation without any impact on		domains can internally handle this situation without any impact on
	the neighbouring domains.		the neighbouring domains.
	4.5. P2MP		4.5. P2MP
	In case of inter-domain P2MP path computation, (Refer [RFC7334]) the		In case of inter-domain P2MP path computation, (Refer [RFC7334]) the
	path domain tree is nothing but a series of Domain Sequences, as		path domain tree is nothing but a series of Domain-Sequences, as
	shown in the below figure:		shown in the below figure:
	D1-D3-D6, D1-D3-D5 and D1-D2-D4.		D1-D3-D6, D1-D3-D5 and D1-D2-D4.
	D1		D1
	/ \		/ \
	D2 D3		D2 D3
	/ / \		/ / \
	D4 D5 D6		D4 D5 D6
	All rules of processing as applied to P2P can be applied to P2MP as		All rules of processing as applied to P2P can be applied to P2MP as
	well.		well.
	In case of P2MP, different destinations MAY have different Domain-		In case of P2MP, different destinations MAY have different Domain-
	Sequence within the domain tree, it requires domain-sequence to be		Sequence within the domain tree, it requires Domain-Sequence to be
	attached per destination. (Refer [PCE-P2MP-PER-DEST])		attached per destination. (Refer [PCE-P2MP-PER-DEST])
	4.6. Hierarchical PCE		4.6. Hierarchical PCE
	As per [RFC6805], consider a case as shown in Figure 4 consisting of		As per [RFC6805], consider a case as shown in Figure 4 consisting of
	multiple child PCEs and a parent PCE.		multiple child PCEs and a parent PCE.
	+--------+		+--------+
	| Parent |		| Parent |
	| PCE |		| PCE |
	skipping to change at page 24, line 29		skipping to change at page 24, line 29
	+---------+ +---------+ +---------+ +---------+ +---------+		+---------+ +---------+ +---------+ +---------+ +---------+
	|ERO | |Sub | |Sub | |Sub | |Sub |		|ERO | |Sub | |Sub | |Sub | |Sub |
	|Object | |Object AS| |Object | |Object | |Object |		|Object | |Object AS| |Object | |Object | |Object |
	|Header | |100 | |Area 2 | |Area 0 | |Area 4 |		|Header | |100 | |Area 2 | |Area 0 | |Area 4 |
	| | | | | | | | | |		| | | | | | | | | |
	| | | | | | | | | |		| | | | | | | | | |
	+---------+ +---------+ +---------+ +---------+ +---------+		+---------+ +---------+ +---------+ +---------+ +---------+
	4.7. Relationship to PCE Sequence		4.7. Relationship to PCE Sequence
	Instead of a domain-sequence, a sequence of PCEs MAY be enforced by		Instead of a Domain-Sequence, a sequence of PCEs MAY be enforced by
	policy on the PCC, and this constraint can be carried in the PCReq		policy on the PCC, and this constraint can be carried in the PCReq
	message (as defined in [RFC5886]).		message (as defined in [RFC5886]).
	Note that PCE-Sequence can be used along with domain-sequence in		Note that PCE-Sequence can be used along with Domain-Sequence in
	which case PCE-Sequence SHOULD have higher precedence in selecting		which case PCE-Sequence SHOULD have higher precedence in selecting
	the next PCE in the inter-domain path computation procedures. Note		the next PCE in the inter-domain path computation procedures. Note
	that Domain-Sequence IRO constraints should still be checked as per		that Domain-Sequence IRO constraints should still be checked as per
	the rules of processing IRO.		the rules of processing IRO.
	4.8. Relationship to RSVP-TE		4.8. Relationship to RSVP-TE
	[RFC3209] already describes the notion of abstract nodes, where an		[RFC3209] already describes the notion of abstract nodes, where an
	abstract node is a group of nodes whose internal topology is opaque		abstract node is a group of nodes whose internal topology is opaque
	to the ingress node of the LSP. It further defines a subobject for		to the ingress node of the LSP. It further defines a subobject for
	skipping to change at page 26, line 20		skipping to change at page 26, line 20
	the exact behavior with regard to desired inclusion and exclusion of		the exact behavior with regard to desired inclusion and exclusion of
	domains must be available for examination by an operator and may be		domains must be available for examination by an operator and may be
	configurable. Second, the behavior on receipt of an unrecognized		configurable. Second, the behavior on receipt of an unrecognized
	subobjects with the L or X-bit set should be configurable and must be		subobjects with the L or X-bit set should be configurable and must be
	available for inspection. The inspection and control of these local		available for inspection. The inspection and control of these local
	policy choices may be part of the PCEP MIB module.		policy choices may be part of the PCEP MIB module.
	7.2. Information and Data Models		7.2. Information and Data Models
	A MIB module for management of the PCEP is being specified in a		A MIB module for management of the PCEP is being specified in a
	separate document [PCEP-MIB]. That MIB module allows examination of		separate document [RFC7420]. That MIB module allows examination of
	individual PCEP messages, in particular requests, responses and		individual PCEP messages, in particular requests, responses and
	errors. The MIB module MUST be extended to include the ability to		errors. The MIB module MUST be extended to include the ability to
	view the domain-sequence extensions defined in this document.		view the Domain-Sequence extensions defined in this document.
	7.3. Liveness Detection and Monitoring		7.3. Liveness Detection and Monitoring
	Mechanisms defined in this document do not imply any new liveness		Mechanisms defined in this document do not imply any new liveness
	detection and monitoring requirements in addition to those already		detection and monitoring requirements in addition to those already
	listed in [RFC5440].		listed in [RFC5440].
	7.4. Verify Correct Operations		7.4. Verify Correct Operations
	Mechanisms defined in this document do not imply any new operation		Mechanisms defined in this document do not imply any new operation
	verification requirements in addition to those already listed in		verification requirements in addition to those already listed in
	[RFC5440].		[RFC5440].
	7.5. Requirements On Other Protocols		7.5. Requirements On Other Protocols
	In case of per-domain path computation [RFC5152], where the full path		In case of per-domain path computation [RFC5152], where the full path
	of an inter-domain TE LSP cannot be or is not determined at the		of an inter-domain TE LSP cannot be, or is not determined at the
	ingress node, and signaling message may use domain identifiers. The		ingress node, a signaling message may use the domain identifiers.
	Subobjects defined in this document SHOULD be supported by RSVP-TE.		The Subobjects defined in this document SHOULD be supported by RSVP-
	[DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding new		TE. [DOMAIN-SUBOBJ] extends the notion of abstract nodes by adding
	subobjects for IGP Areas and 4-byte AS numbers.		new subobjects for IGP Areas and 4-byte AS numbers.
	Apart from this, mechanisms defined in this document do not imply any		Apart from this, mechanisms defined in this document do not imply any
	requirements on other protocols in addition to those already listed		requirements on other protocols in addition to those already listed
	in [RFC5440].		in [RFC5440].
	7.6. Impact On Network Operations		7.6. Impact On Network Operations
	Mechanisms defined in this document do not have any impact on network		Mechanisms defined in this document do not have any impact on network
	operations in addition to those already listed in [RFC5440].		operations in addition to those already listed in [RFC5440].
	skipping to change at page 28, line 23		skipping to change at page 28, line 23
	Inter-Domain Multiprotocol Label Switching Traffic		Inter-Domain Multiprotocol Label Switching Traffic
	Engineering", RFC 4726, November 2006.		Engineering", RFC 4726, November 2006.
	[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,		[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
	"GMPLS Segment Recovery", RFC 4873, May 2007.		"GMPLS Segment Recovery", RFC 4873, May 2007.
	[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, April 2007.
	[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
	Number Space", RFC 4893, May 2007.
	[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain		[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain
	Path Computation Method for Establishing Inter-Domain		Path Computation Method for Establishing Inter-Domain
	Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC		Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC
	5152, February 2008.		5152, February 2008.
	[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving		[RFC5520] Bradford, R., Vasseur, JP., and A. Farrel, "Preserving
	Topology Confidentiality in Inter-Domain Path Computation		Topology Confidentiality in Inter-Domain Path Computation
	Using a Path-Key-Based Mechanism", RFC 5520, April 2009.		Using a Path-Key-Based Mechanism", RFC 5520, April 2009.
	[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of		[RFC5886] Vasseur, JP., Le Roux, JL., and Y. Ikejiri, "A Set of
	Monitoring Tools for Path Computation Element (PCE)-Based		Monitoring Tools for Path Computation Element (PCE)-Based
	Architecture", RFC 5886, June 2010.		Architecture", RFC 5886, June 2010.
			[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
			Autonomous System (AS) Number Space", RFC 6793, December
			2012.
	[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas,		[RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas,
	"PCE-Based Computation Procedure to Compute Shortest		"PCE-Based Computation Procedure to Compute Shortest
	Constrained Point-to-Multipoint (P2MP) Inter-Domain		Constrained Point-to-Multipoint (P2MP) Inter-Domain
	Traffic Engineering Label Switched Paths", RFC 7334,		Traffic Engineering Label Switched Paths", RFC 7334,
	August 2014.		August 2014.
	[PCEP-MIB]		[RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
	Koushik, A., Emile, S., Zhao, Q., King, D., and J.		Hardwick, "Path Computation Element Communication Protocol
	Hardwick, "PCE communication protocol(PCEP) Management		(PCEP)", RFC 7420, December 2014.
	Information Base. (draft-ietf-pce-pcep-mib)", September
	2014.
	[PCE-P2MP-PER-DEST]		[PCE-P2MP-PER-DEST]
	Dhody, D., Palle, U., and V. Kondreddy, "Supporting		Dhody, D., Palle, U., and V. Kondreddy, "Supporting
	explicit inclusion or exclusion of abstract nodes for a		explicit inclusion or exclusion of abstract nodes for a
	subset of P2MP destinations in Path Computation Element		subset of P2MP destinations in Path Computation Element
	Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp-		Communication Protocol (PCEP). (draft-dhody-pce-pcep-p2mp-
	per-destination)", September 2014.		per-destination)", September 2014.
	[DOMAIN-SUBOBJ]		[DOMAIN-SUBOBJ]
	Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,		Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
	"Domain Subobjects for Resource ReserVation Protocol -		"Domain Subobjects for Resource ReserVation Protocol -
	Traffic Engineering (RSVP-TE). (draft-dhody-ccamp-rsvp-te-		Traffic Engineering (RSVP-TE). (draft-ietf-teas-rsvp-te-
	domain-subobjects)", July 2014.		domain-subobjects-00)", December 2014.
	[IRO-SURVEY]
	Dhody, D., "Informal Survey into Include Route Object
	(IRO) Implementations in Path Computation Element
	communication Protocol (PCEP). (draft-dhody-pce-iro-
	survey-01)", October 2014.
	[IRO-UPDATE]		[IRO-UPDATE]
	Dhody, D., "Update to Include Route Object (IRO)		Dhody, D., "Update to Include Route Object (IRO)
	specification in Path Computation Element communication		specification in Path Computation Element communication
	Protocol (PCEP. (draft-dhody-pce-iro-update-00)", October		Protocol (PCEP. (draft-dhody-pce-iro-update-02)", December
	2014.		2014.
	[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.
	Authors' Addresses		Authors' Addresses
	Dhruv Dhody		Dhruv Dhody
	Huawei Technologies		Huawei Technologies
	Leela Palace		Leela Palace
	Bangalore, Karnataka 560008		Bangalore, Karnataka 560008
	INDIA		India
	EMail: dhruv.ietf@gmail.com		EMail: dhruv.ietf@gmail.com
	Udayasree Palle		Udayasree Palle
	Huawei Technologies		Huawei Technologies
	Leela Palace		Leela Palace
	Bangalore, Karnataka 560008		Bangalore, Karnataka 560008
	INDIA		India
	EMail: udayasree.palle@huawei.com		EMail: udayasree.palle@huawei.com
	Ramon Casellas		Ramon Casellas
	CTTC		CTTC
	Av. Carl Friedrich Gauss n7		Av. Carl Friedrich Gauss n7
	Castelldefels, Barcelona 08860		Castelldefels, Barcelona 08860
	SPAIN		Spain
	EMail: ramon.casellas@cttc.es		EMail: ramon.casellas@cttc.es
End of changes. 69 change blocks.
	124 lines changed or deleted		118 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/