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/