draft-ietf-idr-ls-distribution-06.txt   draft-ietf-idr-ls-distribution-07.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: March 20, 2015 S. Previdi Expires: May 19, 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.
September 16, 2014 November 15, 2014
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-06 draft-ietf-idr-ls-distribution-07
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 March 20, 2015. This Internet-Draft will expire on May 19, 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 3, line 11 skipping to change at page 3, line 11
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 . . . . . . . . . . . 36
6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 36 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 . . . . . . . . . . . . . . . . . . 37
6.2.3. Configuration Management . . . . . . . . . . . . . . 37 6.2.3. Configuration Management . . . . . . . . . . . . . . 38
6.2.4. Accounting Management . . . . . . . . . . . . . . . . 38 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 38
6.2.5. Performance Management . . . . . . . . . . . . . . . 38 6.2.5. Performance Management . . . . . . . . . . . . . . . 38
6.2.6. Security Management . . . . . . . . . . . . . . . . . 38 6.2.6. Security Management . . . . . . . . . . . . . . . . . 39
7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 38 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
11.1. Normative References . . . . . . . . . . . . . . . . . . 41 11.1. Normative References . . . . . . . . . . . . . . . . . . 41
11.2. Informative References . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
skipping to change at page 6, line 48 skipping to change at page 6, line 48
2.2. ALTO Server Network API 2.2. ALTO Server Network API
An ALTO Server [RFC5693] is an entity that generates an abstracted An ALTO Server [RFC5693] is an entity that generates an abstracted
network topology and provides it to network-aware applications over a network topology and provides it to network-aware applications over a
web service based API. Example applications are p2p clients or web service based API. Example applications are p2p clients or
trackers, or CDNs. The abstracted network topology comes in the form trackers, or CDNs. The abstracted network topology comes in the form
of two maps: a Network Map that specifies allocation of prefixes to of two maps: a Network Map that specifies allocation of prefixes to
Partition Identifiers (PIDs), and a Cost Map that specifies the cost Partition Identifiers (PIDs), and a Cost Map that specifies the cost
between PIDs listed in the Network Map. For more details, see between PIDs listed in the Network Map. For more details, see
[I-D.ietf-alto-protocol]. [RFC7285].
ALTO abstract network topologies can be auto-generated from the ALTO abstract network topologies can be auto-generated from the
physical topology of the underlying network. The generation would physical topology of the underlying network. The generation would
typically be based on policies and rules set by the operator. Both typically be based on policies and rules set by the operator. Both
prefix and TE data are required: prefix data is required to generate prefix and TE data are required: prefix data is required to generate
ALTO Network Maps, TE (topology) data is required to generate ALTO ALTO Network Maps, TE (topology) data is required to generate ALTO
Cost Maps. Prefix data is carried and originated in BGP, TE data is Cost Maps. Prefix data is carried and originated in BGP, TE data is
originated and carried in an IGP. The mechanism defined in this originated and carried in an IGP. The mechanism defined in this
document provides a single interface through which an ALTO Server can document provides a single interface through which an ALTO Server can
retrieve all the necessary prefix and network topology data from the retrieve all the necessary prefix and network topology data from the
skipping to change at page 8, line 32 skipping to change at page 8, line 32
TLV is not padded to four-octet alignment. Unrecognized types are TLV is not padded to four-octet alignment. Unrecognized types are
preserved and propagated. In order to compare NLRIs with unknown preserved and propagated. In order to compare NLRIs with unknown
TLVs all TLVs MUST be ordered in ascending order by TLV Type. If TLVs all TLVs MUST be ordered in ascending order by TLV Type. If
there are more TLVs of the same type, then the TLVs MUST be ordered there are more TLVs of the same type, then the TLVs MUST be ordered
in ascending order of the TLV value within the TLVs with the same in ascending order of the TLV value within the TLVs with the same
type. All TLVs that are not specified as mandatory are considered type. All TLVs that are not specified as mandatory are considered
optional. optional.
3.2. The Link-State NLRI 3.2. The Link-State NLRI
The MP_REACH and MP_UNREACH attributes are BGP's containers for The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers
carrying opaque information. Each Link-State NLRI describes either a for carrying opaque information. Each Link-State NLRI describes
node, a link or a prefix. either a node, a link or a prefix.
All non-VPN link, node and prefix information SHALL be encoded using All non-VPN link, node and prefix information SHALL be encoded using
AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be AFI 16388 / SAFI 71. VPN link, node and prefix information SHALL be
encoded using AFI 16388 / SAFI 128. encoded using AFI 16388 / SAFI TBD.
In order for two BGP speakers to exchange Link-State NLRI, they MUST In order for two BGP speakers to exchange Link-State NLRI, they MUST
use BGP Capabilities Advertisement to ensure that they both are use BGP Capabilities Advertisement to ensure that they both are
capable of properly processing such NLRI. This is done as specified capable of properly processing such NLRI. This is done as specified
in [RFC4760], by using capability code 1 (multi-protocol BGP), with in [RFC4760], by using capability code 1 (multi-protocol BGP), with
an AFI 16388 / SAFI 71 and AFI 16388 / SAFI 128 for the VPN flavor. an AFI 16388 / SAFI 71 and AFI 16388 / SAFI TBD for the VPN flavor.
The format of the Link-State NLRI is shown in the following figure. The format of the Link-State NLRI is shown in the following figure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NLRI Type | Total NLRI Length | | NLRI Type | Total NLRI Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Link-State NLRI (variable) // // Link-State NLRI (variable) //
skipping to change at page 9, line 31 skipping to change at page 9, line 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Route Distinguisher + + Route Distinguisher +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
// Link-State NLRI (variable) // // Link-State NLRI (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Link-State VPN AFI 16388 / SAFI 128 NLRI Format Figure 6: Link-State VPN AFI 16388 / SAFI TBD NLRI Format
The 'Total NLRI Length' field contains the cumulative length, in The 'Total NLRI Length' field contains the cumulative length, in
octets, of rest of the NLRI not including the NLRI Type field or octets, of rest of the NLRI not including the NLRI Type field or
itself. For VPN applications, it also includes the length of the itself. For VPN applications, it also includes the length of the
Route Distinguisher. Route Distinguisher.
+------+---------------------------+ +------+---------------------------+
| Type | NLRI Type | | Type | NLRI Type |
+------+---------------------------+ +------+---------------------------+
| 1 | Node NLRI | | 1 | Node NLRI |
skipping to change at page 11, line 35 skipping to change at page 11, line 35
| 1 | IS-IS Level 1 | | 1 | IS-IS Level 1 |
| 2 | IS-IS Level 2 | | 2 | IS-IS Level 2 |
| 3 | OSPFv2 | | 3 | OSPFv2 |
| 4 | Direct | | 4 | Direct |
| 5 | Static configuration | | 5 | Static configuration |
| 6 | OSPFv3 | | 6 | OSPFv3 |
+-------------+----------------------------------+ +-------------+----------------------------------+
Table 2: Protocol Identifiers Table 2: Protocol Identifiers
Both OSPF and IS-IS may run multiple routing protocol instances over The 'Direct' and 'Static' protocol types SHOULD be used when BGP-LS
is sourcing local information. For all information, derived from
other protocols the corresponding protocol-ID MUST be used. If BGP-
LS has got direct access to interface information and wants to
advertise a local link then the protocol-ID 'Direct' SHOULD be used.
For modeling virtual links, like described in Section 4 the protocol-
ID 'Static configuration' SHOULD be used.
Both OSPF and IS-IS MAY run multiple routing protocol instances over
the same link. See [RFC6822] and [RFC6549]. These instances define the same link. See [RFC6822] and [RFC6549]. These instances define
independent "routing universes". The 64-Bit 'Identifier' field is independent "routing universes". The 64-Bit 'Identifier' field is
used to identify the "routing universe" where the NLRI belongs. The used to identify the "routing universe" where the NLRI belongs. The
NLRIs representing IGP objects (nodes, links or prefixes) from the NLRIs representing Link-state objects (nodes, links or prefixes) from
same routing universe MUST have the same 'Identifier' value; NLRIs the same routing universe MUST have the same 'Identifier' value;
with different 'Identifier' values MUST be considered to be from NLRIs with different 'Identifier' values MUST be considered to be
different routing universes. Table Table 3 lists the 'Identifier' from different routing universes. Table Table 3 lists the
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 | L3 packet topology | | 0 | L3 packet topology |
| 1 | L1 optical topology | | 1 | L1 optical topology |
+------------+---------------------+ +------------+---------------------+
Table 3: Well-known Instance Identifiers Table 3: Well-known Instance Identifiers
If a given Protocol does not support multiple routing universes then
it SHOULD set the 'Identifier' field according to Table 3. However
an implementation MAY make the 'Identifier' configurable, for a given
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
described in the following sections. described in the following sections.
3.2.1. Node Descriptors 3.2.1. Node Descriptors
Each link is anchored by a pair of Router-IDs that are used by the Each link is anchored by a pair of Router-IDs that are used by the
underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit underlying IGP, namely, 48 Bit ISO System-ID for IS-IS and 32 bit
Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more Router-ID for OSPFv2 and OSPFv3. An IGP may use one or more
additional auxiliary Router-IDs, mainly for traffic engineering additional auxiliary Router-IDs, mainly for traffic engineering
purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE purposes. For example, IS-IS may have one or more IPv4 and IPv6 TE
skipping to change at page 21, line 13 skipping to change at page 21, line 38
router, it can be a subset of the FQDN, or it can be any string router, it can be a subset of the FQDN, or it can be any string
operators want to use for the router. The use of FQDN or a subset of operators want to use for the router. The use of FQDN or a subset of
it is strongly RECOMMENDED. it is strongly RECOMMENDED.
The Value field is encoded in 7-bit ASCII. If a user-interface for The Value field is encoded in 7-bit ASCII. If a user-interface for
configuring or displaying this field permits Unicode characters, that configuring or displaying this field permits Unicode characters, that
user-interface is responsible for applying the ToASCII and/or user-interface is responsible for applying the ToASCII and/or
ToUnicode algorithm as described in [RFC5890] to achieve the correct ToUnicode algorithm as described in [RFC5890] to achieve the correct
format for transmission or display. format for transmission or display.
Altough [RFC5301] is an IS-IS specific extension, usage of the Node Although [RFC5301] is an IS-IS specific extension, usage of the Node
Name TLV is possible for all protocols. How a router derives and Name TLV is possible for all protocols. How a router derives and
injects node names for e.g. OSPF nodes, is outside of the scope of injects node names for e.g. OSPF nodes, is outside of the scope of
this document. this document.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Node Name (variable) // // Node Name (variable) //
skipping to change at page 23, line 17 skipping to change at page 23, line 20
| Point | | /Sub-TLV | | | Point | | /Sub-TLV | |
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | | | | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | | | | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | | | | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | | | | Remote Node | | |
| 1032 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 | | 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | | | | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 |
| | bandwidth | | | | | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | | | | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | | | | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3/ | | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3/ |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
skipping to change at page 24, line 16 skipping to change at page 24, line 16
The MPLS Protocol TLV carries a bit mask describing which MPLS The MPLS Protocol TLV carries a bit mask describing which MPLS
signaling protocols are enabled. The length of this TLV is 1. The signaling protocols are enabled. The length of this TLV is 1. The
value is a bit array of 8 flags, where each bit represents an MPLS value is a bit array of 8 flags, where each bit represents an MPLS
Protocol capability. Protocol capability.
Generation of the MPLS Protocol Mask TLV is only valid for Generation of the MPLS Protocol Mask TLV is only valid for
originators which have local link insight, like for example Protocol- originators which have local link insight, like for example Protocol-
IDs 'Static' or 'Direct' as per Table 2. The MPLS Protocol Mask TLV IDs 'Static' or 'Direct' as per Table 2. The MPLS Protocol Mask TLV
MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-IS MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-IS
L2', 'OSPFv2' or 'OSPFv3' as per Table 2. L2', 'OSPFv2' or 'OSPFv3' as per Table 2. The 'Protocol Mask' TLV
MUST NOT be generated in NLRIs with a protocol-ID of 'IS-IS Level 1',
'IS-IS Level 2', 'OSPFv2' or 'OSPFv3'.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R| Reserved | |L|R| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 19: MPLS Protocol TLV Figure 19: MPLS Protocol TLV
skipping to change at page 25, line 21 skipping to change at page 25, line 21
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: TE Default Metric TLV format Figure 20: TE Default Metric TLV format
3.3.2.4. IGP Metric TLV 3.3.2.4. IGP Metric TLV
The IGP Metric TLV carries the metric for this link. The length of The IGP Metric TLV carries the metric for this link. The length of
this TLV is variable, depending on the metric width of the underlying this TLV is variable, depending on the metric width of the underlying
protocol. IS-IS small metrics have a length of 1 octet (the two most protocol. IS-IS small metrics have a length of 1 octet (the two most
significant bits are ignored). OSPF link metrics have a length of significant bits are ignored). OSPF link metrics have a length of
two octects. IS-IS wide-metrics have a length of three octets. two octets. IS-IS wide-metrics have a length of three octets.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IGP Link Metric (variable length) // // IGP Link Metric (variable length) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Metric TLV format Figure 21: Metric TLV format
skipping to change at page 26, line 28 skipping to change at page 26, line 28
Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG
information is carried in two different TLVs: the IPv4 (SRLG) TLV information is carried in two different TLVs: the IPv4 (SRLG) TLV
(Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139) (Type 138) defined in [RFC5307], and the IPv6 SRLG TLV (Type 139)
defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG defined in [RFC6119]. In Link-State NLRI both IPv4 and IPv6 SRLG
information are carried in a single TLV. information are carried in a single TLV.
3.3.2.6. Opaque Link Attribute TLV 3.3.2.6. Opaque Link Attribute TLV
The Opaque link Attribute TLV is an envelope that transparently The Opaque link Attribute TLV is an envelope that transparently
carries optional link atrribute TLVs advertised by a router. An carries optional link attribute TLVs advertised by a router. An
originating router shall use this TLV for encoding information originating router shall use this TLV for encoding information
specific to the protocol advertised in the NLRI header Protocol-ID specific to the protocol advertised in the NLRI header Protocol-ID
field or new protocol extensions to the protocol as advertised in the field or new protocol extensions to the protocol as advertised in the
NLRI header Protocol-ID field for which there is no protocol neutral NLRI header Protocol-ID field for which there is no protocol neutral
representation in the BGP link-state NLRI. The primary use of the representation in the BGP link-state NLRI. The primary use of the
Opaque Link Attribute TLV is to bridge the document lag between e.g. Opaque Link Attribute TLV is to bridge the document lag between e.g.
a new IGP Link-state attribute being defined and the 'protocol- a new IGP Link-state attribute being defined and the 'protocol-
neutral' BGP-LS extensions being published. neutral' BGP-LS extensions being published.
0 1 2 3 0 1 2 3
skipping to change at page 32, line 24 skipping to change at page 32, line 24
Figure 31: IS-IS Pseudonodes Figure 31: IS-IS Pseudonodes
3.7. Router-ID Anchoring Example: OSPF Pseudonode 3.7. Router-ID Anchoring Example: OSPF Pseudonode
Encoding of a broadcast LAN in OSPF provides a good example of how Encoding of a broadcast LAN in OSPF provides a good example of how
Router-IDs and local Interface IPs are encoded. Consider Figure 32. Router-IDs and local Interface IPs are encoded. Consider Figure 32.
This represents a Broadcast LAN between a pair of routers. The This represents a Broadcast LAN between a pair of routers. The
"real" (=non pseudonode) routers have both an IPv4 Router-ID and an "real" (=non pseudonode) routers have both an IPv4 Router-ID and an
Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4 Area Identifier. The pseudonode does have an IPv4 Router-ID, an IPv4
interface Address (for disambiguation) and an OSPF Area. Node1 is interface Address (for disambiguation) and an OSPF Area. Node1 is
the DIS for the LAN, hence its local IP address 10.1.1.1 is used both the DR for the LAN, hence its local IP address 10.1.1.1 is used both
as the Router-ID and Interface IP for the Pseudonode keys. Two as the Router-ID and Interface IP for the Pseudonode keys. Two
unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2) unidirectional links (Node1, Pseudonode 1) and (Pseudonode1, Node2)
are being generated. are being generated.
The link NRLI of (Node1, Pseudonode1) is encoded as follows: The link NRLI of (Node1, Pseudonode1) is encoded as follows:
o Local Node Descriptor o Local Node Descriptor
TLV #515: IGP Router ID: 11.11.11.11 TLV #515: IGP Router ID: 11.11.11.11
skipping to change at page 35, line 30 skipping to change at page 35, line 30
: : : :
Figure 35: Multi-AS aggregation Figure 35: Multi-AS aggregation
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. As per early allocation procedure this is Address Family Numbers named 'BGP-LS'. As per early allocation
SAFI 71. procedure this is SAFI 71.
This document requests a code point from the registry of Subsequent
Address Family Numbers named 'BGP-LS-VPN'.
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.
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 registry will be initialized as
shown in Table 1. Allocations within the registry will require shown in Table 1. Allocations within the registry will require
documentation of the proposed use of the allocated value and approval documentation of the proposed use of the allocated value and approval
by the Designated Expert assigned by the IESG (see [RFC5226]). by the Designated Expert assigned by the IESG (see [RFC5226]).
skipping to change at page 36, line 9 skipping to change at page 36, line 13
by the Designated Expert assigned by the IESG (see [RFC5226]). 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 and approval by the
Designated Expert assigned by the IESG (see [RFC5226]). 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 Codepoints. 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 and approval by the Designated Expert assigned by the IESG (see
[RFC5226]). [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
skipping to change at page 37, line 34 skipping to change at page 37, line 39
Existing BGP procedures apply. In addition, an implementation SHOULD Existing BGP procedures apply. In addition, an implementation SHOULD
allow an operator to: allow an operator to:
o List neighbors with whom the Speaker is exchanging Link-State o List neighbors with whom the Speaker is exchanging Link-State
NLRIs NLRIs
6.2. Management Considerations 6.2. Management Considerations
6.2.1. Management Information 6.2.1. Management Information
This document does not mandate any new MIB information or NETCONF/
YANG models.
6.2.2. Fault Management 6.2.2. Fault Management
TBD. If an implementation of BGP-LS detects a malformed attribute, then it
SHOULD use the 'Attribute Discard' action as per
[I-D.ietf-idr-error-handling] Section 2.
An implementation of BGP-LS MUST perform the following syntactic
checks for determining if a message is malformed.
o Does the sum of all TLVs found in the BGP LS attribute correspond
to the BGP LS path attribute length ?
o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute
correspond to the BGP MP_REACH_NLRI length ?
o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI
attribute correspond to the BGP MP_UNREACH_NLRI length ?
o Does the sum of all TLVs found in a Node-, Link or Prefix
Descriptor NLRI attribute correspond to the Node-, Link- or Prefix
Descriptors 'Total NLRI Length' field ?
o Does any fixed length TLV correspond to the TLV Length field in
this document ?
6.2.3. Configuration Management 6.2.3. Configuration Management
An implementation SHOULD allow the operator to specify neighbors to An implementation SHOULD allow the operator to specify neighbors to
which Link-State NLRIs will be advertised and from which Link-State which Link-State NLRIs will be advertised and from which Link-State
NLRIs will be accepted. NLRIs will be accepted.
An implementation SHOULD allow the operator to specify the maximum An implementation SHOULD allow the operator to specify the maximum
rate at which Link-State NLRIs will be advertised/withdrawn from rate at which Link-State NLRIs will be advertised/withdrawn from
neighbors. neighbors.
skipping to change at page 39, line 34 skipping to change at page 40, line 11
| 1027 | IS-IS Area | variable | Section 3.3.1.2 | | 1027 | IS-IS Area | variable | Section 3.3.1.2 |
| | Identifier | | | | | Identifier | | |
| 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Local Node | | | | | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Local Node | | | | | Local Node | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
| | Remote Node | | | | | Remote Node | | |
| 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 |
| | Remote Node | | | | | Remote Node | | |
| 1032 | Link Local/Remote | 22/4 | [RFC5307]/1.1 |
| | Identifiers | | |
| 1088 | Administrative | 22/3 | [RFC5305]/3.1 | | 1088 | Administrative | 22/3 | [RFC5305]/3.1 |
| | group (color) | | | | | group (color) | | |
| 1089 | Maximum link | 22/9 | [RFC5305]/3.3 | | 1089 | Maximum link | 22/9 | [RFC5305]/3.3 |
| | bandwidth | | | | | bandwidth | | |
| 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 |
| | link bandwidth | | | | | link bandwidth | | |
| 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 |
| | bandwidth | | | | | bandwidth | | |
| 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 |
| 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 |
skipping to change at page 40, line 16 skipping to change at page 40, line 39
| 1152 | IGP Flags | --- | Section 3.3.3.1 | | 1152 | IGP Flags | --- | Section 3.3.3.1 |
| 1153 | Route Tag | --- | [RFC5130] | | 1153 | Route Tag | --- | [RFC5130] |
| 1154 | Extended Tag | --- | [RFC5130] | | 1154 | Extended Tag | --- | [RFC5130] |
| 1155 | Prefix Metric | --- | [RFC5305] | | 1155 | Prefix Metric | --- | [RFC5305] |
| 1156 | OSPF Forwarding | --- | [RFC2328] | | 1156 | OSPF Forwarding | --- | [RFC2328] |
| | Address | | | | | Address | | |
| 1157 | Opaque Prefix | --- | Section 3.3.3.6 | | 1157 | Opaque Prefix | --- | Section 3.3.3.6 |
| | Attribute | | | | | Attribute | | |
+-----------+---------------------+---------------+-----------------+ +-----------+---------------------+---------------+-----------------+
Table 13: Summary Table of TLV/Sub-TLV Codepoints Table 13: Summary Table of TLV/Sub-TLV code points
8. Security Considerations 8. 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.
In the context of the BGP peerings associated with this document, a In the context of the BGP peerings associated with this document, a
BGP Speaker SHOULD NOT accept updates from a Consumer peer. That is, BGP Speaker SHOULD NOT accept updates from a Consumer peer. That is,
skipping to change at page 43, line 7 skipping to change at page 43, line 26
Identifier for BGP-4", RFC 6286, June 2011. Identifier for BGP-4", RFC 6286, June 2011.
[RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi-
Instance Extensions", RFC 6549, March 2012. Instance Extensions", RFC 6549, March 2012.
[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. [RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. Ward, "IS-IS Multi-Instance", RFC 6822, December 2012.
11.2. Informative References 11.2. Informative References
[I-D.ietf-alto-protocol] [I-D.ietf-idr-error-handling]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", draft- Chen, E., Scudder, J., Mohapatra, P., and K. Patel,
ietf-alto-protocol-27 (work in progress), March 2014. "Revised Error Handling for BGP UPDATE Messages", draft-
ietf-idr-error-handling-16 (work in progress), November
2014.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
4272, January 2006. 4272, January 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, August 2006. Element (PCE)-Based Architecture", RFC 4655, August 2006.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007. Router Capabilities", RFC 4970, July 2007.
skipping to change at page 44, line 5 skipping to change at page 44, line 26
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", RFC Management of New Protocols and Protocol Extensions", RFC
5706, November 2009. 5706, November 2009.
[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, May 2013. Guide", RFC 6952, May 2013.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, September
2014.
Authors' Addresses Authors' Addresses
Hannes Gredler Hannes Gredler
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: hannes@juniper.net Email: hannes@juniper.net
 End of changes. 29 change blocks. 
38 lines changed or deleted 83 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/