Content-Type: text/html

	< draft-ietf-ospf-node-admin-tag-07.txt		draft-ietf-ospf-node-admin-tag-08.txt >
	Open Shortest Path First IGP S. Hegde		Open Shortest Path First IGP S. Hegde
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Intended status: Standards Track R. Shakir		Intended status: Standards Track R. Shakir
	Expires: April 11, 2016 Individual		Expires: April 13, 2016 Individual
	A. Smirnov		A. Smirnov
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Z. Li		Z. Li
	Huawei Technologies		Huawei Technologies
	B. Decraene		B. Decraene
	Orange		Orange
	October 9, 2015		October 11, 2015
	Advertising per-node administrative tags in OSPF		Advertising per-node administrative tags in OSPF
	draft-ietf-ospf-node-admin-tag-07		draft-ietf-ospf-node-admin-tag-08
	Abstract		Abstract
	This document describes an extension to OSPF protocol to add an		This document describes an extension to OSPF protocol to add an
	optional operational capability, that allows tagging and grouping of		optional operational capability, that allows tagging and grouping of
	the nodes in an OSPF domain. This allows simplification, ease of		the nodes in an OSPF domain. This allows simplification, ease of
	management and control over route and path selection based on		management and control over route and path selection based on
	configured policies. This document describes an extension to OSPF		configured policies. This document describes an extension to OSPF
	protocol to advertise per-node administrative tags. The node-tags		protocol to advertise per-node administrative tags. The node-tags
	can be used to express and apply locally-defined network policies		can be used to express and apply locally-defined network policies
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	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 11, 2016.		This Internet-Draft will expire on April 13, 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 43		skipping to change at page 2, line 43
	3.2. Elements of procedure . . . . . . . . . . . . . . . . . . 4		3.2. Elements of procedure . . . . . . . . . . . . . . . . . . 4
	4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Applications . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Service auto-discovery . . . . . . . . . . . . . . . . . 6		4.1. Service auto-discovery . . . . . . . . . . . . . . . . . 6
	4.2. Fast-Re-routing policy . . . . . . . . . . . . . . . . . 6		4.2. Fast-Re-routing policy . . . . . . . . . . . . . . . . . 6
	4.3. Controlling Remote LFA tunnel termination . . . . . . . . 7		4.3. Controlling Remote LFA tunnel termination . . . . . . . . 7
	4.4. Mobile back-haul network service deployment . . . . . . . 8		4.4. Mobile back-haul network service deployment . . . . . . . 8
	4.5. Explicit routing policy . . . . . . . . . . . . . . . . . 9		4.5. Explicit routing policy . . . . . . . . . . . . . . . . . 9
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	6. Operational Considerations . . . . . . . . . . . . . . . . . 11		6. Operational Considerations . . . . . . . . . . . . . . . . . 11
	7. Manageability Considerations . . . . . . . . . . . . . . . . 11		7. Manageability Considerations . . . . . . . . . . . . . . . . 11
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	11.1. Normative References . . . . . . . . . . . . . . . . . . 12		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
	11.2. Informative References . . . . . . . . . . . . . . . . . 13		11.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	It is useful to assign a per-node administrative tag to a router in		It is useful to assign a per-node administrative tag to a router in
	the OSPF domain and use it as an attribute associated with the node.		the OSPF domain and use it as an attribute associated with the node.
	The per-node administrative tag can be used in variety of		The per-node administrative tag can be used in variety of
	applications, for ex: - Traffic-engineering applications to provide		applications, for ex: - Traffic-engineering applications to provide
	different path-selection criteria, - Prefer or prune certain paths in		different path-selection criteria, - Prefer or prune certain paths in
	Loop Free Alternate (LFA) backup selection via local policies.		Loop Free Alternate (LFA) backup selection via local policies.
	skipping to change at page 4, line 35		skipping to change at page 4, line 35
	of tags advertised.		of tags advertised.
	Value: A sequence of multiple 4 octets defining the administrative		Value: A sequence of multiple 4 octets defining the administrative
	tags. At least one tag MUST be carried if this TLV is included in		tags. At least one tag MUST be carried if this TLV is included in
	the RI-LSA.		the RI-LSA.
	3.2. Elements of procedure		3.2. Elements of procedure
	Meaning of the Node administrative tags is generally opaque to OSPF.		Meaning of the Node administrative tags is generally opaque to OSPF.
	Router advertising the per-node administrative tag (or tags) may be		Router advertising the per-node administrative tag (or tags) may be
	configured to do so without knowing (or even explicitly supporting)		configured to do so without knowing (or even without supporting
	functionality implied by the tag.		processing of) functionality implied by the tag.
	Interpretation of tag values is specific to the administrative domain		Interpretation of tag values is specific to the administrative domain
	of a particular network operator, and hence tag values SHOULD NOT be		of a particular network operator, and hence tag values SHOULD NOT be
	propagated outside the administrative domain to which they apply.		propagated outside the administrative domain to which they apply.
	The meaning of a per-node administrative tag is defined by the		The meaning of a per-node administrative tag is defined by the
	network local policy and is controlled via the configuration. If a		network local policy and is controlled via the configuration. If a
	receiving node does not understand the tag value or does not have a		receiving node does not understand the tag value or does not have a
	local policy corresponding to the tag, it ignores the specific tag		local policy corresponding to the tag, it ignores the specific tag
	and floods the RI LSA without any change as defined in [RFC4970].		and floods the RI LSA without any change as defined in [RFC4970].
	skipping to change at page 5, line 21		skipping to change at page 5, line 21
	AND tag B are present), they MUST NOT be reliant upon the order of		AND tag B are present), they MUST NOT be reliant upon the order of
	the tags (i.e., all policies should be considered commutative		the tags (i.e., all policies should be considered commutative
	operations, such that tag A preceding or following tag B does not		operations, such that tag A preceding or following tag B does not
	change their outcome).		change their outcome).
	To avoid incomplete or inconsistent interpretations of the per-node		To avoid incomplete or inconsistent interpretations of the per-node
	administrative tags the same tag value MUST NOT be advertised by a		administrative tags the same tag value MUST NOT be advertised by a
	router in RI LSAs of different scopes. The same tag MAY be		router in RI LSAs of different scopes. The same tag MAY be
	advertised in multiple RI LSAs of the same scope, for example, OSPF		advertised in multiple RI LSAs of the same scope, for example, OSPF
	Area Border Router (ABR) may advertise the same tag in area-scope RI		Area Border Router (ABR) may advertise the same tag in area-scope RI
	LSAs in multiple areas connected to the ABR.		LSAs in multiple areas connected to the ABR. If a node
			administrative tag is received in different scopes, the conflicting
			tag SHOULD not be used and this situation SHOULD be logged as an
			error including the tag with conflicting scopes and the
			originator(s).
	The per-node administrative tags are not meant to be extended by the		The per-node administrative tags are not meant to be extended by the
	future OSPF standards. The new OSPF extensions MUST NOT require use		future OSPF standards. The new OSPF extensions MUST NOT require use
	of per-node administrative tags or define well-known tag values.		of per-node administrative tags or define well-known tag values.
	Node administrative tags are for generic use and do not require IANA		Node administrative tags are for generic use and do not require IANA
	registry. The future OSPF extensions requiring well known values MAY		registry. The future OSPF extensions requiring well known values MAY
	define their own data signalling tailored to the needs of the feature		define their own data signalling tailored to the needs of the feature
	or MAY use capability TLV as defined in [RFC4970].		or MAY use capability TLV as defined in [RFC4970].
	Being part of the RI LSA, the per-node administrative tag TLV must be		Being part of the RI LSA, the per-node administrative tag TLV must be
	skipping to change at page 11, line 20		skipping to change at page 11, line 20
	geographical location or other sensitive information. As indicated		geographical location or other sensitive information. As indicated
	in [RFC2328] and [RFC5340] OSPF authentication mechanisms do not		in [RFC2328] and [RFC5340] OSPF authentication mechanisms do not
	provide confidentiality and the information carried in node		provide confidentiality and the information carried in node
	administrative tags could be leaked to an IGP snooper.		administrative tags could be leaked to an IGP snooper.
	Advertisement of tag values for one administrative domain into		Advertisement of tag values for one administrative domain into
	another risks misinterpretation of the tag values (if the two domains		another risks misinterpretation of the tag values (if the two domains
	have assigned different meanings to the same values), which may have		have assigned different meanings to the same values), which may have
	undesirable and unanticipated side effects.		undesirable and unanticipated side effects.
			[RFC4593] and [RFC6863] discuss the generic threats to routing
			protocols and OSPF respectively. These security threats are also
			applicable to the mechanisms described in this document.OSPF
			authentication described in [RFC2328] and [RFC5340] or extended
			authentication mechanisms described in [RFC7474] or [RFC7166] SHOULD
			be used in deployments where attackers have access to the physical
			networks and nodes included in the OSPF domain are vulnerable.
	6. Operational Considerations		6. Operational Considerations
	Operators can assign meaning to the node administrative tags which is		Operators can assign meaning to the node administrative tags which is
	local to the operator's administrative domain. The operational use		local to the operator's administrative domain. The operational use
	of node administrative tags is analogical to the IS-IS prefix tags		of node administrative tags is analogical to the IS-IS prefix tags
	[RFC5130] and BGP communities [RFC1997]. Operational discipline and		[RFC5130] and BGP communities [RFC1997]. Operational discipline and
	procedures followed in configuring and using BGP communities and ISIS		procedures followed in configuring and using BGP communities and ISIS
	Prefix tags is also applicable to the usage of node administrative		Prefix tags is also applicable to the usage of node administrative
	tags.		tags.
	skipping to change at page 13, line 33		skipping to change at page 13, line 42
	[I-D.ietf-rtgwg-policy-model]		[I-D.ietf-rtgwg-policy-model]
	Shaikh, A., rjs@rob.sh, r., D'Souza, K., and C. Chase,		Shaikh, A., rjs@rob.sh, r., D'Souza, K., and C. Chase,
	"Routing Policy Configuration Model for Service Provider		"Routing Policy Configuration Model for Service Provider
	Networks", draft-ietf-rtgwg-policy-model-00 (work in		Networks", draft-ietf-rtgwg-policy-model-00 (work in
	progress), September 2015.		progress), September 2015.
	[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities		[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
	Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,		Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
	<http://www.rfc-editor.org/info/rfc1997>.		<http://www.rfc-editor.org/info/rfc1997>.
			[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
			Routing Protocols", RFC 4593, DOI 10.17487/RFC4593,
			October 2006, <http://www.rfc-editor.org/info/rfc4593>.
	[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy		[RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy
	Control Mechanism in IS-IS Using Administrative Tags",		Control Mechanism in IS-IS Using Administrative Tags",
	RFC 5130, DOI 10.17487/RFC5130, February 2008,		RFC 5130, DOI 10.17487/RFC5130, February 2008,
	<http://www.rfc-editor.org/info/rfc5130>.		<http://www.rfc-editor.org/info/rfc5130>.
	[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for		[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
	IP Fast Reroute: Loop-Free Alternates", RFC 5286,		IP Fast Reroute: Loop-Free Alternates", RFC 5286,
	DOI 10.17487/RFC5286, September 2008,		DOI 10.17487/RFC5286, September 2008,
	<http://www.rfc-editor.org/info/rfc5286>.		<http://www.rfc-editor.org/info/rfc5286>.
			[RFC6863] Hartman, S. and D. Zhang, "Analysis of OSPF Security
			According to the Keying and Authentication for Routing
			Protocols (KARP) Design Guide", RFC 6863,
			DOI 10.17487/RFC6863, March 2013,
			<http://www.rfc-editor.org/info/rfc6863>.
			[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting
			Authentication Trailer for OSPFv3", RFC 7166,
			DOI 10.17487/RFC7166, March 2014,
			<http://www.rfc-editor.org/info/rfc7166>.
			[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
			"Security Extension for OSPFv2 When Using Manual Key
			Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
			<http://www.rfc-editor.org/info/rfc7474>.
	Authors' Addresses		Authors' Addresses
	Shraddha Hegde		Shraddha Hegde
	Juniper Networks, Inc.		Juniper Networks, Inc.
	Embassy Business Park		Embassy Business Park
	Bangalore, KA 560093		Bangalore, KA 560093
	India		India
	Email: shraddha@juniper.net		Email: shraddha@juniper.net
	Rob Shakir		Rob Shakir
	Individual		Individual
	Email: rjs@rob.sh		Email: rjs@rob.sh
	Anton Smirnov		Anton Smirnov
	Cisco Systems, Inc.		Cisco Systems, Inc.
	De Kleetlaan 6a		De Kleetlaan 6a
	Diegem 1831		Diegem 1831
	Belgium		Belgium
End of changes. 12 change blocks.
	9 lines changed or deleted		42 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/