draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04.txt		draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05.txt
	Inter-Domain Routing P. Sarkar, Ed.		Inter-Domain Routing P. Sarkar, Ed.
	Internet-Draft H. Gredler		Internet-Draft Individual Contributor
	Intended status: Standards Track Individual Contributor		Intended status: Standards Track H. Gredler
	Expires: November 14, 2016 S. Litkowski		Expires: May 18, 2017 RtBrick, Inc.
			S. Litkowski
	Orange		Orange
	May 13, 2016		November 14, 2016
	Advertising Node Admin Tags in BGP Link-State Advertisements		Advertising Node Admin Tags in BGP Link-State Advertisements
	draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04		draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05
	Abstract		Abstract
	This document describes the protocol extensions to collect node		This document describes the protocol extensions to collect node
	administrative tags adevertised in IGP Link State advertisements and		administrative tags adevertised in IGP Link State advertisements and
	disseminate the same in BGP Link-State advertisement protocol, to		disseminate the same in BGP Link-State advertisement protocol, to
	facilitate inter-AS TE applications that may need the same node		facilitate inter-AS TE applications that may need the same node
	administrative tags to associate a subset of network devices spanning		administrative tags to associate a subset of network devices spanning
	across more than one AS with a specific functionality.		across more than one AS with a specific functionality.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 44 ¶
	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 14, 2016.		This Internet-Draft will expire on May 18, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4		2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4
	3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4		3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 5
	3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5		3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5
	4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7		4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7
	5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8		5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	7. Manageability Considerations . . . . . . . . . . . . . . . . 9		7. Manageability Considerations . . . . . . . . . . . . . . . . 9
	7.1. Operational Considerations . . . . . . . . . . . . . . . 9		7.1. Operational Considerations . . . . . . . . . . . . . . . 9
	7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9		7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9
	8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9		8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 9		9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
	11.1. Normative References . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 9
	11.2. Informative References . . . . . . . . . . . . . . . . . 10		11.2. Informative References . . . . . . . . . . . . . . . . . 10
	11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10		11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Advertising Node Administrative Tags in Link State protocols like IS-		Advertising Node Administrative Tags in Link State protocols like IS-
	IS [I-D.ietf-isis-node-admin-tag] and OSPF		IS [RFC7917] and OSPF [RFC7777] allows adding an optional operational
	[I-D.ietf-ospf-node-admin-tag] allows adding an optional operational
	capability, that allows tagging and grouping of the nodes in a IGP		capability, that allows tagging and grouping of the nodes in a IGP
	domain. This, among other applications, allows simple management and		domain. This, among other applications, allows simple management and
	easy control over route and path selection, based on local configured		easy control over route and path selection, based on local configured
	policies. However node administrative tags advertised in IGP		policies. However node administrative tags advertised in IGP
	advertisements let network operators associate nodes within a single		advertisements let network operators associate nodes within a single
	AS (if not a single area). This limits the use of such node		AS (if not a single area). This limits the use of such node
	administrative tags and applications that need to associate a subset		administrative tags and applications that need to associate a subset
	of network devices spanning across multiple AS with a specific		of network devices spanning across multiple AS with a specific
	functionality cannot use them.		functionality cannot use them.
	To address the need for applications that require visibility into		To address the need for applications that require visibility into
	LSDB across IGP areas, or even across ASes, the BGP-LS address-		LSDB across IGP areas, or even across ASes, the BGP-LS address-
	family/sub-address-family have been defined that allows BGP to carry		family/sub-address-family have been defined that allows BGP to carry
	LSDB information. The BGP Network Layer Reachability Information		LSDB information. The BGP Network Layer Reachability Information
	(NLRI) encoding format for BGP-LS and a new BGP Path Attribute called		(NLRI) encoding format for BGP-LS and a new BGP Path Attribute called
	BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The		BGP-LS attribute are defined in [RFC7752]. The identifying key of
	identifying key of each LSDB object, namely a node, a link or a		each LSDB object, namely a node, a link or a prefix, is encoded in
	prefix, is encoded in the NLRI and the properties of the object are		the NLRI and the properties of the object are encoded in the BGP-LS
	encoded in the BGP-LS attribute. Figure 1 describes a typical		attribute. Figure 1 describes a typical deployment scenario. In
	deployment scenario. In each IGP area, one or more nodes are		each IGP area, one or more nodes are configured with BGP-LS. These
	configured with BGP-LS. These BGP speakers form an IBGP mesh by		BGP speakers form an IBGP mesh by connecting to one or more route-
	connecting to one or more route-reflectors. This way, all BGP		reflectors. This way, all BGP speakers - specifically the route-
	speakers - specifically the route-reflectors - obtain LSDB		reflectors - obtain LSDB information from all IGP areas (and from
	information from all IGP areas (and from other ASes from EBGP peers).		other ASes from EBGP peers). An external component connects to the
	An external component connects to the route-reflector to obtain this		route-reflector to obtain this information (perhaps moderated by a
	information (perhaps moderated by a policy regarding what information		policy regarding what information is sent to the external component,
	is sent to the external component, and what information isn't).		and what information isn't).
	+------------+		+------------+
	| Consumer |		| Consumer |
	+------------+		+------------+
	^		^
	|		|
	v		v
	+-------------------+		+-------------------+
	| BGP Speaker | +-----------+		| BGP Speaker | +-----------+
	| (Route-Reflector) | | Consumer |		| (Route-Reflector) | | Consumer |
	skipping to change at page 3, line 48 ¶		skipping to change at page 4, line 5 ¶
	+-----------+ +-----------+ +-----------+		+-----------+ +-----------+ +-----------+
	^ ^ ^		^ ^ ^
	| | |		| | |
	IGP IGP IGP		IGP IGP IGP
	Figure 1: Link State info collection		Figure 1: Link State info collection
	For the purpose of advertising node administrative tags within BGP		For the purpose of advertising node administrative tags within BGP
	Link-State advertisements, a new Node Attribute TLV to be carried in		Link-State advertisements, a new Node Attribute TLV to be carried in
	the corresponding BGP-LS Node NLRI is proposed. For more details on		the corresponding BGP-LS Node NLRI is proposed. For more details on
	the Node Attribute TLVs please refer to section 3.3.1 in		the Node Attribute TLVs please refer to section 3.3.1 in [RFC7752]
	[I-D.ietf-idr-ls-distribution]
	2. Per-Node Administrative Tag		2. Per-Node Administrative Tag
	An administrative Tag is a 32-bit integer value that can be used to		An administrative Tag is a 32-bit integer value that can be used to
	identify a group of nodes in the entire routing domain. The new sub-		identify a group of nodes in the entire routing domain. The new sub-
	TLV specifies one or more administrative tag values. A BGP Link-		TLV specifies one or more administrative tag values. A BGP Link-
	State speaker that also participates in the IGP link state		State speaker that also participates in the IGP link state
	advertisements exchange may learn one or more node administrative		advertisements exchange may learn one or more node administrative
	tags advertised by another router in the same IGP domain. Such BGP-		tags advertised by another router in the same IGP domain. Such BGP-
	LS speaker shall encode the same set of node administrative tags in		LS speaker shall encode the same set of node administrative tags in
	skipping to change at page 4, line 44 ¶		skipping to change at page 4, line 46 ¶
	To be able to distinguish between the significance of a per-area(or		To be able to distinguish between the significance of a per-area(or
	level) administrative tag learnt in one area, from that advertised in		level) administrative tag learnt in one area, from that advertised in
	another area, or another AS, any applications receiving such a BGP-LS		another area, or another AS, any applications receiving such a BGP-LS
	advertisements MUST consider the scope associated with each node		advertisements MUST consider the scope associated with each node
	administrative tag with 'per-area (or per-level) along with the		administrative tag with 'per-area (or per-level) along with the
	area(or level in IS-IS) associated with corresponding IGP link state		area(or level in IS-IS) associated with corresponding IGP link state
	advertisement and the AS number associated with the originating node.		advertisement and the AS number associated with the originating node.
	The area(or level) associated with corresponding IGP link state		The area(or level) associated with corresponding IGP link state
	advertisement and the AS number associated with the originating node		advertisement and the AS number associated with the originating node
	can be derived from appropriate node attributes (already defined in		can be derived from appropriate node attributes (already defined in
	BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the		BGP-LS [RFC7752]) attached with the corresponding Node NLRI.
	corresponding Node NLRI.
	3. BGP-LS Extensions for Per-Node Administrative Tags		3. BGP-LS Extensions for Per-Node Administrative Tags
	The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI.		The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI.
	The corresponding BGP-LS attribute is a node attribute, a link		The corresponding BGP-LS attribute is a node attribute, a link
	attribute or a prefix attribute. BGP-LS		attribute or a prefix attribute. BGP-LS [RFC7752] defines the TLVs
	[I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state		that map link-state information to BGP-LS NLRI and BGP-LS attribute.
	information to BGP-LS NLRI and BGP-LS attribute. This document adds		This document adds an new Node Attribute TLV called 'Node Admin Tag
	an new Node Attribute TLV called 'Node Admin Tag TLV' to encode node		TLV' to encode node administrative tags information.
	administrative tags information.
	[I-D.ietf-isis-node-admin-tag] defines the 'Node Admin Tag' sub-TLV		[RFC7917] defines the 'Node Admin Tag' sub-TLV in the Router
	in the Router Capability TLV (type 242) in IS-IS Link State PDUs to		Capability TLV (type 242) in IS-IS Link State PDUs to encode node
	encode node administrative tags. Similarly		administrative tags. Similarly [RFC7917] defines the 'Node
	[I-D.ietf-isis-node-admin-tag] defines the 'Node Administrative Tag'		Administrative Tag' TLV in OSPF Router Information LSAs to encode
	TLV in OSPF Router Information LSAs to encode node administrative		node administrative tags in OSPF Link State update packets. The node
	tags in OSPF Link State update packets. The node administrative tags		administrative tags TLVs learnt from the IGP link state
	TLVs learnt from the IGP link state advertisements of a specific node		advertisements of a specific node will all be inserted in a new Node
	will all be inserted in a new Node Admin Tag TLV and added to the		Admin Tag TLV and added to the corresponding Node are mapped to the
	corresponding Node are mapped to the corresponding BGP-LS Node NLRI.		corresponding BGP-LS Node NLRI. Node administrative tags from IGP
	Node administrative tags from IGP advertisements are mapped to the		advertisements are mapped to the corresponding Node Admin Tag TLV in
	corresponding Node Admin Tag TLV in the following way.		the following way.
	+----------+---------------+----------+---------------+-------------+		+----------+---------------+----------+---------------+-------------+
	| TLV Code | Description | Length | IS-IS TLV | OSPF |		| TLV Code | Description | Length | IS-IS TLV | OSPF |
	| Point | | | /sub-TLV | LSA/TLV |		| Point | | | /sub-TLV | LSA/TLV |
	+----------+---------------+----------+---------------+-------------+		+----------+---------------+----------+---------------+-------------+
	| TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD |		| TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD |
	| | Tag TLV | | | [2] |		| | Tag TLV | | | [2] |
	+----------+---------------+----------+---------------+-------------+		+----------+---------------+----------+---------------+-------------+
	Table 1: Node Admin Tag TLV Mapping from IGP		Table 1: Node Admin Tag TLV Mapping from IGP
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	carried by the Node Admin Tag TLV SHOULD be used to indicate a		carried by the Node Admin Tag TLV SHOULD be used to indicate a
	independent characteristics of the node in IGP domain that originated		independent characteristics of the node in IGP domain that originated
	it. The TLV SHOULD be considered as an unordered list. Whilst		it. The TLV SHOULD be considered as an unordered list. Whilst
	policies may be implemented based on the presence of multiple tags		policies may be implemented based on the presence of multiple tags
	(e.g., if tag A AND tag B are present), they MUST NOT be reliant upon		(e.g., if tag A AND tag B are present), they MUST NOT be reliant upon
	the order of the tags (i.e., all policies should be considered		the order of the tags (i.e., all policies should be considered
	commutative operations, such that tag A preceding or following tag B		commutative operations, such that tag A preceding or following tag B
	does not change their outcome).		does not change their outcome).
	For more details on guidance on usage of node administrative tags		For more details on guidance on usage of node administrative tags
	please refer to section 4 [3] in [I-D.ietf-isis-node-admin-tag].		please refer to section 4 [3] in [RFC7917].
	5. Applications		5. Applications
	[I-D.ietf-isis-node-admin-tag] and [I-D.ietf-ospf-node-admin-tag]		[RFC7917] and [RFC7777] present some applications of node
	present some applications of node administrative tags.		administrative tags.
	The policy-based Explicit routing use case can be extended to inter-		The Policy-based Explicit routing use case can be extended to inter-
	area or inter-AS scenarios where an end to end path needs to avoid or		area or inter-AS scenarios where an end to end path needs to avoid or
	include nodes that have particular properties. Following are some		include nodes that have particular properties. Following are some
	examples.		examples.
	1. Geopolitical routing : preventing traffic from country A to		1. Geopolitical routing : preventing traffic from country A to
	country B to cross country C. In this case, we may use node		country B to cross country C. In this case, we may use node
	administrative tags to encode geographical information (country).		administrative tags to encode geographical information (country).
	Path computation will be required to take into account node		Path computation will be required to take into account node
	administrative tag to permit avoidance of nodes belonging to		administrative tag to permit avoidance of nodes belonging to
	country C.		country C.
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 44 ¶
	in the network. For example, legacy nodes may not be carrier		in the network. For example, legacy nodes may not be carrier
	class (no high availability), and service provider wants to		class (no high availability), and service provider wants to
	ensure that critical traffic only uses nodes that are providing		ensure that critical traffic only uses nodes that are providing
	high availability.		high availability.
	In case of inter-AS Traffic-Engineering applications, different ASes		In case of inter-AS Traffic-Engineering applications, different ASes
	SHOULD share their administrative tag policies. They MAY also need		SHOULD share their administrative tag policies. They MAY also need
	to agree upon some common tagging policy for specific applications.		to agree upon some common tagging policy for specific applications.
	For more details on some possible applications with node		For more details on some possible applications with node
	administrative tags please refer to section 5 [4] in		administrative tags please refer to section 3 [4] in [RFC7777].
	[I-D.ietf-isis-node-admin-tag].
	6. IANA Considerations		6. IANA Considerations
	This document requests assigning code-points from the registry for		This document requests assigning code-points from the registry for
	BGP-LS attribute TLVs based on table Table 2.		BGP-LS attribute TLVs based on table Table 2.
	7. Manageability Considerations		7. Manageability Considerations
	This section is structured as recommended in [RFC5706].		This section is structured as recommended in [RFC5706].
	skipping to change at page 9, line 38 ¶		skipping to change at page 9, line 38 ¶
	9. Security Considerations		9. Security Considerations
	Procedures and protocol extensions defined in this document do not		Procedures and protocol extensions defined in this document do not
	affect the BGP security model. See the 'Security Considerations'		affect the BGP security model. See the 'Security Considerations'
	section of [RFC4271] for a discussion of BGP security. Also refer to		section of [RFC4271] for a discussion of BGP security. Also refer to
	[RFC4272] and [RFC6952] for analysis of security issues for BGP.		[RFC4272] and [RFC6952] for analysis of security issues for BGP.
	10. Acknowledgements		10. Acknowledgements
	TBD.		TBA.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-idr-ls-distribution]
	Gredler, H., Medved, J., Previdi, S., Farrel, A., and S.
	Ray, "North-Bound Distribution of Link-State and TE
	Information using BGP", draft-ietf-idr-ls-distribution-13
	(work in progress), October 2015.
	[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>.
	[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A		[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
	Border Gateway Protocol 4 (BGP-4)", RFC 4271,		Border Gateway Protocol 4 (BGP-4)", RFC 4271,
	DOI 10.17487/RFC4271, January 2006,		DOI 10.17487/RFC4271, January 2006,
	<http://www.rfc-editor.org/info/rfc4271>.		<http://www.rfc-editor.org/info/rfc4271>.
	11.2. Informative References		[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
			S. Ray, "North-Bound Distribution of Link-State and
	[I-D.ietf-isis-node-admin-tag]		Traffic Engineering (TE) Information Using BGP", RFC 7752,
	Sarkar, P., Gredler, H., Hegde, S., Litkowski, S.,		DOI 10.17487/RFC7752, March 2016,
	Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H.		<http://www.rfc-editor.org/info/rfc7752>.
	Raghuveer, "Advertising Per-node Admin Tags in IS-IS",
	draft-ietf-isis-node-admin-tag-00 (work in progress),
	December 2014.
	[I-D.ietf-ospf-node-admin-tag]		11.2. Informative References
	Hegde, S., Raghuveer, H., Gredler, H., Shakir, R.,
	Smirnov, A., Li, Z., and B. Decraene, "Advertising per-
	node administrative tags in OSPF", draft-ietf-ospf-node-
	admin-tag-00 (work in progress), October 2014.
	[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",		[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
	RFC 4272, DOI 10.17487/RFC4272, January 2006,		RFC 4272, DOI 10.17487/RFC4272, January 2006,
	<http://www.rfc-editor.org/info/rfc4272>.		<http://www.rfc-editor.org/info/rfc4272>.
	[RFC5706] Harrington, D., "Guidelines for Considering Operations and		[RFC5706] Harrington, D., "Guidelines for Considering Operations and
	Management of New Protocols and Protocol Extensions",		Management of New Protocols and Protocol Extensions",
	RFC 5706, DOI 10.17487/RFC5706, November 2009,		RFC 5706, DOI 10.17487/RFC5706, November 2009,
	<http://www.rfc-editor.org/info/rfc5706>.		<http://www.rfc-editor.org/info/rfc5706>.
	[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of		[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
	BGP, LDP, PCEP, and MSDP Issues According to the Keying		BGP, LDP, PCEP, and MSDP Issues According to the Keying
	and Authentication for Routing Protocols (KARP) Design		and Authentication for Routing Protocols (KARP) Design
	Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,		Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
	<http://www.rfc-editor.org/info/rfc6952>.		<http://www.rfc-editor.org/info/rfc6952>.
			[RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B.
			Decraene, "Advertising Node Administrative Tags in OSPF",
			RFC 7777, DOI 10.17487/RFC7777, March 2016,
			<http://www.rfc-editor.org/info/rfc7777>.
			[RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S.,
			and B. Decraene, "Advertising Node Administrative Tags in
			IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016,
			<http://www.rfc-editor.org/info/rfc7917>.
	11.3. URIs		11.3. URIs
	[1] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag-		[1] http://tools.ietf.org/html/rfc7917#section-3.1
	00#section-3.1
	[2] http://tools.ietf.org/html/draft-ietf-ospf-node-admin-tag-		[2] http://tools.ietf.org/html/rfc7777#section-2.1
	00#section-4.1
	[3] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag-		[3] http://tools.ietf.org/html/rfc7917#section-4
	00#section-4
	[4] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag-		[4] http://tools.ietf.org/html/rfc7777#section-3
	00#section-5
	Authors' Addresses		Authors' Addresses
	Pushpasis Sarkar (editor)		Pushpasis Sarkar (editor)
	Individual Contributor		Individual Contributor
	Email: pushpasis.ietf@gmail.com		Email: pushpasis.ietf@gmail.com
	Hannes Gredler		Hannes Gredler
	Individual Contributor		RtBrick, Inc.
	Email: hannes@gredler.at		Email: hannes@rtbrick.com
	Stephane Litkowski		Stephane Litkowski
	Orange		Orange
	Email: stephane.litkowski@orange.com		Email: stephane.litkowski@orange.com
End of changes. 28 change blocks.
	79 lines changed or deleted		67 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/