draft-ietf-idr-ls-distribution-09.txt		draft-ietf-idr-ls-distribution-10.txt
	Inter-Domain Routing H. Gredler		Inter-Domain Routing H. Gredler
	Internet-Draft Juniper Networks, Inc.		Internet-Draft Juniper Networks, Inc.
	Intended status: Standards Track J. Medved		Intended status: Standards Track J. Medved
	Expires: July 25, 2015 S. Previdi		Expires: July 30, 2015 S. Previdi
	Cisco Systems, Inc.		Cisco Systems, Inc.
	A. Farrel		A. Farrel
	Juniper Networks, Inc.		Juniper Networks, Inc.
	S. Ray		S. Ray
	Cisco Systems, Inc.		Cisco Systems, Inc.
	January 21, 2015		January 26, 2015
	North-Bound Distribution of Link-State and TE Information using BGP		North-Bound Distribution of Link-State and TE Information using BGP
	draft-ietf-idr-ls-distribution-09		draft-ietf-idr-ls-distribution-10
	Abstract		Abstract
	In a number of environments, a component external to a network is		In a number of environments, a component external to a network is
	called upon to perform computations based on the network topology and		called upon to perform computations based on the network topology and
	current state of the connections within the network, including		current state of the connections within the network, including
	traffic engineering information. This is information typically		traffic engineering information. This is information typically
	distributed by IGP routing protocols within the network.		distributed by IGP routing protocols within the network.
	This document describes a mechanism by which links state and traffic		This document describes a mechanism by which links state and traffic
	skipping to change at page 2, line 12		skipping to change at page 2, line 12
	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 July 25, 2015.		This Internet-Draft will expire on July 30, 2015.
	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 3, line 10		skipping to change at page 3, line 10
	3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 32		3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 32
	3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 33		3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 33
	4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 33		4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 33
	4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 34		4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 34
	4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 34		4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 34
	4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 35		4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 35
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
	6. Manageability Considerations . . . . . . . . . . . . . . . . 36		6. Manageability Considerations . . . . . . . . . . . . . . . . 36
	6.1. Operational Considerations . . . . . . . . . . . . . . . 36		6.1. Operational Considerations . . . . . . . . . . . . . . . 36
	6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 36		6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 36
	6.1.2. Installation and Initial Setup . . . . . . . . . . . 36		6.1.2. Installation and Initial Setup . . . . . . . . . . . 37
	6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 37		6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 37
	6.1.4. Requirements on Other Protocols and Functional		6.1.4. Requirements on Other Protocols and Functional
	Components . . . . . . . . . . . . . . . . . . . . . 37		Components . . . . . . . . . . . . . . . . . . . . . 37
	6.1.5. Impact on Network Operation . . . . . . . . . . . . . 37		6.1.5. Impact on Network Operation . . . . . . . . . . . . . 37
	6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 37		6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 37
	6.2. Management Considerations . . . . . . . . . . . . . . . . 37		6.2. Management Considerations . . . . . . . . . . . . . . . . 37
	6.2.1. Management Information . . . . . . . . . . . . . . . 37		6.2.1. Management Information . . . . . . . . . . . . . . . 37
	6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 37		6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 38
	6.2.3. Configuration Management . . . . . . . . . . . . . . 38		6.2.3. Configuration Management . . . . . . . . . . . . . . 38
	6.2.4. Accounting Management . . . . . . . . . . . . . . . . 38		6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39
	6.2.5. Performance Management . . . . . . . . . . . . . . . 38		6.2.5. Performance Management . . . . . . . . . . . . . . . 39
	6.2.6. Security Management . . . . . . . . . . . . . . . . . 39		6.2.6. Security Management . . . . . . . . . . . . . . . . . 39
	7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39		7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 40		8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
	9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
	11.1. Normative References . . . . . . . . . . . . . . . . . . 41		11.1. Normative References . . . . . . . . . . . . . . . . . . 42
	11.2. Informative References . . . . . . . . . . . . . . . . . 43		11.2. Informative References . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
	1. Introduction		1. Introduction
	The contents of a Link State Database (LSDB) or a Traffic Engineering		The contents of a Link State Database (LSDB) or a Traffic Engineering
	Database (TED) has the scope of an IGP area. Some applications, such		Database (TED) has the scope of an IGP area. Some applications, such
	as end-to-end Traffic Engineering (TE), would benefit from visibility		as end-to-end Traffic Engineering (TE), would benefit from visibility
	outside one area or Autonomous System (AS) in order to make better		outside one area or Autonomous System (AS) in order to make better
	decisions.		decisions.
	skipping to change at page 12, line 9		skipping to change at page 12, line 9
	NLRIs representing Link-state objects (nodes, links or prefixes) from		NLRIs representing Link-state objects (nodes, links or prefixes) from
	the same routing universe MUST have the same 'Identifier' value;		the same routing universe MUST have the same 'Identifier' value;
	NLRIs with different 'Identifier' values MUST be considered to be		NLRIs with different 'Identifier' values MUST be considered to be
	from different routing universes. Table Table 3 lists the		from different routing universes. Table Table 3 lists the
	'Identifier' values that are defined as well-known in this draft.		'Identifier' values that are defined as well-known in this draft.
	+------------+----------------------------------+		+------------+----------------------------------+
	| Identifier | Routing Universe |		| Identifier | Routing Universe |
	+------------+----------------------------------+		+------------+----------------------------------+
	| 0 | Default Layer 3 Routing topology |		| 0 | Default Layer 3 Routing topology |
	| 1-31 | Reserved for future use |		| 1-31 | Reserved |
	+------------+----------------------------------+		+------------+----------------------------------+
	Table 3: Well-known Instance Identifiers		Table 3: Well-known Instance Identifiers
	If a given Protocol does not support multiple routing universes then		If a given Protocol does not support multiple routing universes then
	it SHOULD set the 'Identifier' field according to Table 3. However		it SHOULD set the 'Identifier' field according to Table 3. However
	an implementation MAY make the 'Identifier' configurable, for a given		an implementation MAY make the 'Identifier' configurable, for a given
	protocol.		protocol.
	Each Node Descriptor and Link Descriptor consists of one or more TLVs		Each Node Descriptor and Link Descriptor consists of one or more TLVs
	skipping to change at page 35, line 34		skipping to change at page 35, line 34
	5. IANA Considerations		5. IANA Considerations
	This document requests a code point from the registry of Address		This document requests a code point from the registry of Address
	Family Numbers. As per early allocation procedure this is AFI 16388.		Family Numbers. As per early allocation procedure this is AFI 16388.
	This document requests a code point from the registry of Subsequent		This document requests a code point from the registry of Subsequent
	Address Family Numbers named 'BGP-LS'. As per early allocation		Address Family Numbers named 'BGP-LS'. As per early allocation
	procedure this is SAFI 71.		procedure this is SAFI 71.
	This document requests a code point from the registry of Subsequent		This document requests a code point from the registry of Subsequent
	Address Family Numbers named 'BGP-LS-VPN'.		Address Family Numbers named 'BGP-LS-VPN'. The SAFI assignment does
			NOT need to be out of the range 1-63.
	This document requests a code point from the BGP Path Attributes		This document requests a code point from the BGP Path Attributes
	registry. As per early allocation procedure this is Path Attribute		registry. As per early allocation procedure this is Path Attribute
	29.		29.
			All the following Registries are BGP-LS specific and shall be
			acessible under the following URL: "http://www.iana.org/assignments/
			bgp-ls-parameters" Title "Border Gateway Protocol - Link State (BGP-
			LS) Parameters"
	This document requests creation of a new registry for BGP-LS NLRI-		This document requests creation of a new registry for BGP-LS NLRI-
	Types. Value 0 is reserved. The registry will be initialized as		Types. Value 0 is reserved. The maximum value is 65535. The
	shown in Table 1. Allocations within the registry will require		registry will be initialized as shown in Table 1. Allocations within
	documentation of the proposed use of the allocated value and approval		the registry will require documentation of the proposed use of the
	by the Designated Expert assigned by the IESG (see [RFC5226]).		allocated value (=Specification required) and approval by the
			Designated Expert assigned by the IESG (see [RFC5226]).
	This document requests creation of a new registry for BGP-LS		This document requests creation of a new registry for BGP-LS
	Protocol-IDs. Value 0 is reserved. The registry will be initialized		Protocol-IDs. Value 0 is reserved. The maximum value is 255. The
	as shown in Table 2. Allocations within the registry will require		registry will be initialized as shown in Table 2. Allocations within
	documentation of the proposed use of the allocated value and approval		the registry will require documentation of the proposed use of the
	by the Designated Expert assigned by the IESG (see [RFC5226]).		allocated value (=Specification required) and approval by the
			Designated Expert assigned by the IESG (see [RFC5226]).
	This document requests creation of a new registry for BGP-LS Well-		This document requests creation of a new registry for BGP-LS Well-
	known Instance-IDs. The registry will be initialized as shown in		known Instance-IDs. The registry will be initialized as shown in
	Table 3. Allocations within the registry will require documentation		Table 3. Allocations within the registry will require documentation
	of the proposed use of the allocated value and approval by the		of the proposed use of the allocated value (=Specification required)
	Designated Expert assigned by the IESG (see [RFC5226]).		and approval by the Designated Expert assigned by the IESG (see
			[RFC5226]).
	This document requests creation of a new registry for node anchor,		This document requests creation of a new registry for node anchor,
	link descriptor and link attribute TLVs. Values 0-255 are reserved.		link descriptor and link attribute TLVs. Values 0-255 are reserved.
	Values 256-65535 will be used for code points. The registry will be		Values 256-65535 will be used for code points. The registry will be
	initialized as shown in Table 13. Allocations within the registry		initialized as shown in Table 13. Allocations within the registry
	will require documentation of the proposed use of the allocated value		will require documentation of the proposed use of the allocated value
	and approval by the Designated Expert assigned by the IESG (see		(=Specification required) and approval by the Designated Expert
	[RFC5226]).		assigned by the IESG (see [RFC5226]).
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	6. Manageability Considerations		6. Manageability Considerations
	This section is structured as recommended in [RFC5706].		This section is structured as recommended in [RFC5706].
	6.1. Operational Considerations		6.1. Operational Considerations
End of changes. 16 change blocks.
	25 lines changed or deleted		34 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/