draft-ietf-idr-ls-distribution-10.txt   draft-ietf-idr-ls-distribution-11.txt 
Inter-Domain Routing H. Gredler Inter-Domain Routing H. Gredler, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: July 30, 2015 S. Previdi Expires: December 6, 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. June 4, 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-10 draft-ietf-idr-ls-distribution-11
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 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 July 30, 2015. This Internet-Draft will expire on December 6, 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 2, line 36 skipping to change at page 2, line 34
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5
2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5
2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 6
3. Carrying Link State Information in BGP . . . . . . . . . . . 7 3. Carrying Link State Information in BGP . . . . . . . . . . . 7
3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8 3.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 8
3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 12 3.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 12
3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 16 3.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 16
3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 17 3.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 17
3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 19 3.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 19
3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19 3.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 19
3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 22 3.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 22
3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 27 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 27
3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 30 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 30
3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 31 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 30 skipping to change at page 3, line 27
6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39
6.2.5. Performance Management . . . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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.
The IETF has defined the Path Computation Element (PCE) [RFC4655] as The IETF has defined the Path Computation Element (PCE) [RFC4655] as
skipping to change at page 11, line 48 skipping to change at page 11, line 48
LS has got direct access to interface information and wants to LS has got direct access to interface information and wants to
advertise a local link then the protocol-ID 'Direct' SHOULD be used. advertise a local link then the protocol-ID 'Direct' SHOULD be used.
For modeling virtual links, like described in Section 4 the protocol- For modeling virtual links, like described in Section 4 the protocol-
ID 'Static configuration' SHOULD be used. ID 'Static configuration' SHOULD be used.
Both OSPF and IS-IS MAY run multiple routing protocol instances over 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 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 3 lists the 'Identifier'
'Identifier' values that are defined as well-known in this draft. 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 | | 1-31 | Reserved |
+------------+----------------------------------+ +------------+----------------------------------+
Table 3: Well-known Instance Identifiers Table 3: Well-known Instance Identifiers
skipping to change at page 12, line 30 skipping to change at page 12, line 30
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
Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be Router-IDs [RFC5305], [RFC6119]. These auxiliary Router-IDs MUST be
included in the link attribute described in Section Section 3.3.2. included in the link attribute described in Section 3.3.2.
It is desirable that the Router-ID assignments inside the Node It is desirable that the Router-ID assignments inside the Node
Descriptor are globally unique. However there may be Router-ID Descriptor are globally unique. However there may be Router-ID
spaces (e.g. ISO) where no global registry exists, or worse, Router- spaces (e.g. ISO) where no global registry exists, or worse, Router-
IDs have been allocated following private-IP RFC 1918 [RFC1918] IDs have been allocated following private-IP RFC 1918 [RFC1918]
allocation. We use Autonomous System (AS) Number and BGP-LS allocation. We use Autonomous System (AS) Number and BGP-LS
Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as
described in Section 3.2.1.1. described in Section 3.2.1.1.
3.2.1.1. Globally Unique Node/Link/Prefix Identifiers 3.2.1.1. Globally Unique Node/Link/Prefix Identifiers
One problem that needs to be addressed is the ability to identify an One problem that needs to be addressed is the ability to identify an
IGP node globally (by "global", we mean within the BGP-LS database IGP node globally (by "global", we mean within the BGP-LS database
collected by all BGP-LS speakers that talk to each other). This can collected by all BGP-LS speakers that talk to each other). This can
be expressed through the following two requirements: be expressed through the following two requirements:
(A) The same node must not be represented by two keys (otherwise one (A) The same node MUST NOT be represented by two keys (otherwise one
node will look like two nodes). node will look like two nodes).
(B) Two different nodes must not be represented by the same key (B) Two different nodes MUST NOT be represented by the same key
(otherwise, two nodes will look like one node). (otherwise, two nodes will look like one node).
We define an "IGP domain" to be the set of nodes (hence, by extension We define an "IGP domain" to be the set of nodes (hence, by extension
links and prefixes), within which, each node has a unique IGP links and prefixes), within which, each node has a unique IGP
representation by using the combination of Area-ID, Router-ID, representation by using the combination of Area-ID, Router-ID,
Protocol, Topology-ID, and Instance ID. The problem is that BGP may Protocol, Topology-ID, and Instance ID. The problem is that BGP may
receive node/link/prefix information from multiple independent "IGP receive node/link/prefix information from multiple independent "IGP
domains" and we need to distinguish between them. Moreover, we can't domains" and we need to distinguish between them. Moreover, we can't
assume there is always one and only one IGP domain per AS. During assume there is always one and only one IGP domain per AS. During
IGP transitions it may happen that two redundant IGPs are in place. IGP transitions it may happen that two redundant IGPs are in place.
In section Section 3.2.1.4 a set of sub-TLVs is described, which In Section 3.2.1.4 a set of sub-TLVs is described, which allows
allows specification of a flexible key for any given Node/Link specification of a flexible key for any given Node/Link information
information such that global uniqueness of the NLRI is ensured. such that global uniqueness of the NLRI is ensured.
3.2.1.2. Local Node Descriptors 3.2.1.2. Local Node Descriptors
The Local Node Descriptors TLV contains Node Descriptors for the node The Local Node Descriptors TLV contains Node Descriptors for the node
anchoring the local end of the link. This is a mandatory TLV in all anchoring the local end of the link. This is a mandatory TLV in all
three types of NLRIs. The length of this TLV is variable. The value three types of NLRIs. The length of this TLV is variable. The value
contains one or more Node Descriptor Sub-TLVs defined in contains one or more Node Descriptor Sub-TLVs defined in
Section 3.2.1.4. Section 3.2.1.4.
0 1 2 3 0 1 2 3
skipping to change at page 21, line 28 skipping to change at page 21, line 28
// Area Identifier (variable) // // Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: IS-IS Area Identifier TLV Format Figure 16: IS-IS Area Identifier TLV Format
3.3.1.3. Node Name TLV 3.3.1.3. Node Name TLV
The Node Name TLV is optional. Its structure and encoding has been The Node Name TLV is optional. Its structure and encoding has been
borrowed from [RFC5301]. The value field identifies the symbolic borrowed from [RFC5301]. The value field identifies the symbolic
name of the router node. This symbolic name can be the FQDN for the name of the router node. This symbolic name can be the FQDN for the
router, it can be a subset of the FQDN, or it can be any string router, it can be a subset of the FQDN (e.g. a hostname), or it can
operators want to use for the router. The use of FQDN or a subset of be any string operators want to use for the router. The use of FQDN
it is strongly RECOMMENDED. The maximum length of the 'Node Name or a subset of it is strongly RECOMMENDED. The maximum length of the
TLV' is 255 octets. 'Node Name TLV' is 255 octets.
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.
Although [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
skipping to change at page 23, line 5 skipping to change at page 23, line 5
attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/ attribute with a link NLRI. Each 'Link Attribute' is a Type/Length/
Value (TLV) triplet formatted as defined in Section 3.1. The format Value (TLV) triplet formatted as defined in Section 3.1. The format
and semantics of the 'value' fields in some 'Link Attribute' TLVs and semantics of the 'value' fields in some 'Link Attribute' TLVs
correspond to the format and semantics of value fields in IS-IS correspond to the format and semantics of value fields in IS-IS
Extended IS Reachability sub-TLVs, defined in [RFC5305] and Extended IS Reachability sub-TLVs, defined in [RFC5305] and
[RFC5307]. Other 'Link Attribute' TLVs are defined in this document. [RFC5307]. Other 'Link Attribute' TLVs are defined in this document.
Although the encodings for 'Link Attribute' TLVs were originally Although the encodings for 'Link Attribute' TLVs were originally
defined for IS-IS, the TLVs can carry data sourced either by IS-IS or defined for IS-IS, the TLVs can carry data sourced either by IS-IS or
OSPF. OSPF.
The following 'Link Attribute' TLVs are are valid in the LINK_STATE The following 'Link Attribute' TLVs are valid in the LINK_STATE
attribute: attribute:
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| TLV Code | Description | IS-IS TLV | Defined in: | | TLV Code | Description | IS-IS TLV | Defined in: |
| 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 | | |
skipping to change at page 24, line 13 skipping to change at page 24, line 13
multiple TLVs are used to encode them. multiple TLVs are used to encode them.
3.3.2.2. MPLS Protocol Mask TLV 3.3.2.2. MPLS Protocol Mask TLV
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 that have local link insight, like for example Protocol-
IDs 'Static' or 'Direct' as per Table 2. The 'MPLS Protocol Mask' 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- TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS-
IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2. IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2.
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 |
skipping to change at page 24, line 43 skipping to change at page 24, line 43
| 'L' | Label Distribution Protocol (LDP) | [RFC5036] | | 'L' | Label Distribution Protocol (LDP) | [RFC5036] |
| 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] | | 'R' | Extension to RSVP for LSP Tunnels (RSVP- | [RFC3209] |
| | TE) | | | | TE) | |
| 'Reserved' | Reserved for future use | | | 'Reserved' | Reserved for future use | |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 10: MPLS Protocol Mask TLV Codes Table 10: MPLS Protocol Mask TLV Codes
3.3.2.3. TE Default Metric TLV 3.3.2.3. TE Default Metric TLV
The TE Default Metric TLV carries the TE-metric for this link. The The TE Default Metric TLV carries the Traffic engineering metric for
length of this TLV is fixed at 4 octets. If a source protocol (e.g. this link. The length of this TLV is fixed at 4 octets. If a source
IS-IS) does not support a Metric width of 32 bits then the high order protocol (e.g. IS-IS) does not support a Metric width of 32 bits
octet MUST be set to zero. then the high order octet MUST be set to zero.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE Default Link Metric | | TE Default Link Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 20: TE Default Metric TLV format Figure 20: TE Default Metric TLV format
skipping to change at page 26, line 19 skipping to change at page 26, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value | | Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// ............ // // ............ //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Shared Risk Link Group Value | | Shared Risk Link Group Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Shared Risk Link Group TLV format Figure 22: Shared Risk Link Group TLV format
Note that there is no SRLG TLV in OSPF-TE. In IS-IS the SRLG The SRLG TLV for OSPF-TE is defined in [RFC4203]. 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 attribute 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
skipping to change at page 28, line 8 skipping to change at page 28, line 8
| | Address | | | | | Address | | |
| 1157 | Opaque Prefix | variable | Section 3.3.3.6 | | 1157 | Opaque Prefix | variable | Section 3.3.3.6 |
| | Attribute | | | | | Attribute | | |
+---------------+----------------------+----------+-----------------+ +---------------+----------------------+----------+-----------------+
Table 11: Prefix Attribute TLVs Table 11: Prefix Attribute TLVs
3.3.3.1. IGP Flags TLV 3.3.3.1. IGP Flags TLV
IGP Flags TLV contains IS-IS and OSPF flags and bits originally IGP Flags TLV contains IS-IS and OSPF flags and bits originally
assigned tothe prefix. The IGP Flags TLV is encoded as follows: assigned to the prefix. The IGP Flags TLV is encoded as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|N|L|P| Resvd.| |D|N|L|P| Resvd.|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 25: IGP Flag TLV format Figure 25: IGP Flag TLV format
skipping to change at page 33, line 10 skipping to change at page 33, line 10
TLV #514: OSPF Area-ID: ID:0.0.0.0 TLV #514: OSPF Area-ID: ID:0.0.0.0
o Remote Node Descriptor o Remote Node Descriptor
TLV #515: IGP Router ID: 33.33.33.34 TLV #515: IGP Router ID: 33.33.33.34
TLV #514: OSPF Area-ID: ID:0.0.0.0 TLV #514: OSPF Area-ID: ID:0.0.0.0
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 | | Node1 | | Pseudonode1 | | Node2 |
| 11.11.11.11 |--->| 10.1.1.1 |--->| 33.33.33.34 | | 11.11.11.11 |--->| 11.11.11.11 |--->| 33.33.33.34 |
| | | 10.1.1.1 | | | | | | 10.1.1.1 | | |
| Area 0 | | Area 0 | | Area 0 | | Area 0 | | Area 0 | | Area 0 |
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
Figure 32: OSPF Pseudonodes Figure 32: OSPF Pseudonodes
3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration
Graceful migration from one IGP to another requires coordinated Graceful migration from one IGP to another requires coordinated
operation of both protocols during the migration period. Such a operation of both protocols during the migration period. Such a
skipping to change at page 35, line 26 skipping to change at page 35, line 26
| : : vR0 | : : vR0
| : : / | : : /
R2-------R4----- R2-------R4-----
: : : :
: : : :
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 is the reference for Address Family Number 16388, 'BGP-
Family Numbers. As per early allocation procedure this is AFI 16388. LS'.
This document requests a code point from the registry of Subsequent This document requests code point 71 from the registry of Subsequent
Address Family Numbers named 'BGP-LS'. As per early allocation Address Family Numbers named 'BGP-LS'.
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'. The SAFI assignment does Address Family Numbers named 'BGP-LS-VPN'. The SAFI assignment does
NOT need to be out of the range 1-63. NOT need to be out of the range 1-63 and MAY come out of the "First
Come First Served" range 128-240.
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 All the following Registries are BGP-LS specific and shall be
acessible under the following URL: "http://www.iana.org/assignments/ accessible under the following URL: "http://www.iana.org/assignments/
bgp-ls-parameters" Title "Border Gateway Protocol - Link State (BGP- bgp-ls-parameters" Title "Border Gateway Protocol - Link State (BGP-
LS) Parameters" 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 maximum value is 65535. The Types. Value 0 is reserved. The maximum value is 65535. The
registry will be initialized as shown in Table 1. Allocations within registry will be initialized as shown in Table 1. Allocations within
the registry will require documentation of the proposed use of the the registry will require documentation of the proposed use of the
allocated value (=Specification required) and approval by the allocated value (=Specification required) and approval by the
Designated Expert assigned by the IESG (see [RFC5226]). Designated Expert assigned by the IESG (see [RFC5226]).
skipping to change at page 38, line 8 skipping to change at page 38, line 8
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/ This document does not mandate any new MIB information or NETCONF/
YANG models. YANG models.
6.2.2. Fault Management 6.2.2. Fault Management
If an implementation of BGP-LS detects a malformed attribute, then it If an implementation of BGP-LS detects a malformed attribute, then it
SHOULD use the 'Attribute Discard' action as per MUST use the 'Attribute Discard' action as per
[I-D.ietf-idr-error-handling] Section 2. [I-D.ietf-idr-error-handling] Section 2.
An implementation of BGP-LS MUST perform the following syntactic An implementation of BGP-LS MUST perform the following syntactic
checks for determining if a message is malformed. checks for determining if a message is malformed.
o Does the sum of all TLVs found in the BGP LS attribute correspond o Does the sum of all TLVs found in the BGP LS attribute correspond
to the BGP LS path attribute length ? to the BGP LS path attribute length ?
o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute
correspond to the BGP MP_REACH_NLRI length ? correspond to the BGP MP_REACH_NLRI length ?
skipping to change at page 39, line 23 skipping to change at page 39, line 23
o Total number of Link-State NLRI updates sent/received o Total number of Link-State NLRI updates sent/received
o Number of Link-State NLRI updates sent/received, per neighbor o Number of Link-State NLRI updates sent/received, per neighbor
o Number of errored received Link-State NLRI updates, per neighbor o Number of errored received Link-State NLRI updates, per neighbor
o Total number of locally originated Link-State NLRIs o Total number of locally originated Link-State NLRIs
6.2.6. Security Management 6.2.6. Security Management
An operator SHOULD define ACLs to limit inbound updates as follows: An operator SHOULD define an import policy to limit inbound updates
as follows:
o Drop all updates from Consumer peers o Drop all updates from Consumer peers
An implementation MUST have means to limit inbound updates.
7. TLV/Sub-TLV Code Points Summary 7. TLV/Sub-TLV Code Points Summary
This section contains the global table of all TLVs/Sub-TLVs defined This section contains the global table of all TLVs/Sub-TLVs defined
in this document. in this document.
+-----------+---------------------+---------------+-----------------+ +-----------+---------------------+---------------+-----------------+
| TLV Code | Description | IS-IS TLV/ | Value defined | | TLV Code | Description | IS-IS TLV/ | Value defined |
| Point | | Sub-TLV | in: | | Point | | Sub-TLV | in: |
+-----------+---------------------+---------------+-----------------+ +-----------+---------------------+---------------+-----------------+
| 256 | Local Node | --- | Section 3.2.1.2 | | 256 | Local Node | --- | Section 3.2.1.2 |
skipping to change at page 41, line 13 skipping to change at page 41, line 16
Table 13: Summary Table of TLV/Sub-TLV code points 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 MUST NOT accept updates from a Consumer peer. That is, a
a participating BGP Speaker, should be aware of the nature of its participating BGP Speaker, should be aware of the nature of its
relationships for link state relationships and should protect itself relationships for link state relationships and should protect itself
from peers sending updates that either represent erroneous from peers sending updates that either represent erroneous
information feedback loops, or are false input. Such protection can information feedback loops, or are false input. Such protection can
be achieved by manual configuration of Consumer peers at the BGP be achieved by manual configuration of Consumer peers at the BGP
Speaker. Speaker.
An operator SHOULD employ a mechanism to protect a BGP Speaker An operator SHOULD employ a mechanism to protect a BGP Speaker
against DDoS attacks from Consumers. The principal attack a consumer against DDoS attacks from Consumers. The principal attack a consumer
may apply is to attempt to start multiple sessions either may apply is to attempt to start multiple sessions either
sequentially or simultaneously. Protection can be applied by sequentially or simultaneously. Protection can be applied by
skipping to change at page 41, line 44 skipping to change at page 41, line 47
9. Contributors 9. Contributors
We would like to thank Robert Varga for the significant contribution We would like to thank Robert Varga for the significant contribution
he gave to this document. he gave to this document.
10. Acknowledgements 10. Acknowledgements
We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek
Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les
Ginsberg, Liem Nguyen, Manish Bhardwaj, Mike Shand, Peter Psenak, Rex Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand,
Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas
Vipin Kumar, Naiming Shen, Balaji Rajagopalan and Yakov Rekhter for Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro,
their comments. Balaji Rajagopalan and Yakov Rekhter for their comments.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990. dual environments", RFC 1195, December 1990.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
skipping to change at page 42, line 33 skipping to change at page 42, line 33
1999. 1999.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, January "Multiprotocol Extensions for BGP-4", RFC 4760, January
2007. 2007.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
4915, June 2007. 4915, June 2007.
skipping to change at page 45, line 4 skipping to change at page 45, line 6
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., [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285, September Traffic Optimization (ALTO) Protocol", RFC 7285, September
2014. 2014.
Authors' Addresses Authors' Addresses
Hannes Gredler
Hannes Gredler (editor)
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
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170, West Tasman Drive 170, West Tasman Drive
skipping to change at page 45, line 37 skipping to change at page 45, line 40
Adrian Farrel Adrian Farrel
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave. 1194 N. Mathilda Ave.
Sunnyvale, CA 94089 Sunnyvale, CA 94089
US US
Email: afarrel@juniper.net Email: afarrel@juniper.net
Saikat Ray Saikat Ray
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: sairay@cisco.com Email: raysaikat@gmail.com
 End of changes. 33 change blocks. 
50 lines changed or deleted 53 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/