draft-ietf-idr-ls-distribution-11.txt   draft-ietf-idr-ls-distribution-12.txt 
Inter-Domain Routing H. Gredler, Ed. Inter-Domain Routing H. Gredler, Ed.
Internet-Draft Juniper Networks, Inc. Internet-Draft Private Contributor
Intended status: Standards Track J. Medved Intended status: Standards Track J. Medved
Expires: December 6, 2015 S. Previdi Expires: April 6, 2016 S. Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
A. Farrel A. Farrel
Juniper Networks, Inc. Juniper Networks, Inc.
S. Ray S. Ray
June 4, 2015 October 4, 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-11 draft-ietf-idr-ls-distribution-12
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 10 skipping to change at page 2, line 10
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 6, 2015. This Internet-Draft will expire on April 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
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 . . . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 23
3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 27 3.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 28
3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 30 3.4. BGP Next Hop Information . . . . . . . . . . . . . . . . 31
3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 31 3.5. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 32
3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 31 3.6. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 32
3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 32 3.7. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 33
3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 33 3.8. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 34
4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 33 4. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 34
4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 34 4.1. Example: No Link Aggregation . . . . . . . . . . . . . . 35
4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 34 4.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 35
4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 35 4.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 36
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
6. Manageability Considerations . . . . . . . . . . . . . . . . 36 5.1. Guidance for Designated Experts . . . . . . . . . . . . . 37
6.1. Operational Considerations . . . . . . . . . . . . . . . 36 6. Manageability Considerations . . . . . . . . . . . . . . . . 37
6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 36 6.1. Operational Considerations . . . . . . . . . . . . . . . 37
6.1.2. Installation and Initial Setup . . . . . . . . . . . 37 6.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 37
6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 37 6.1.2. Installation and Initial Setup . . . . . . . . . . . 38
6.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 38
6.1.4. Requirements on Other Protocols and Functional 6.1.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . 37 Components . . . . . . . . . . . . . . . . . . . . . 38
6.1.5. Impact on Network Operation . . . . . . . . . . . . . 37 6.1.5. Impact on Network Operation . . . . . . . . . . . . . 38
6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 37 6.1.6. Verifying Correct Operation . . . . . . . . . . . . . 38
6.2. Management Considerations . . . . . . . . . . . . . . . . 37 6.2. Management Considerations . . . . . . . . . . . . . . . . 39
6.2.1. Management Information . . . . . . . . . . . . . . . 37 6.2.1. Management Information . . . . . . . . . . . . . . . 39
6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 38 6.2.2. Fault Management . . . . . . . . . . . . . . . . . . 39
6.2.3. Configuration Management . . . . . . . . . . . . . . 38 6.2.3. Configuration Management . . . . . . . . . . . . . . 39
6.2.4. Accounting Management . . . . . . . . . . . . . . . . 39 6.2.4. Accounting Management . . . . . . . . . . . . . . . . 40
6.2.5. Performance Management . . . . . . . . . . . . . . . 39 6.2.5. Performance Management . . . . . . . . . . . . . . . 40
6.2.6. Security Management . . . . . . . . . . . . . . . . . 39 6.2.6. Security Management . . . . . . . . . . . . . . . . . 40
7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 39 7. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 40
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 43
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
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 8, line 17 skipping to change at page 8, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (variable) // // Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: TLV format Figure 4: TLV format
The Length field defines the length of the value portion in octets The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of zero). The (thus a TLV with no value portion would have a length of zero). The
TLV is not padded to four-octet alignment. Unrecognized types are TLV is not padded to four-octet alignment. Unrecognized types MUST
preserved and propagated. In order to compare NLRIs with unknown be 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 by treating the entire value field an opaque hexadecimal string
optional. and comparing leftmost octets first regardless of the length of the
string. . All TLVs that are not specified as mandatory are
considered optional.
3.2. The Link-State NLRI 3.2. The Link-State NLRI
The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers The MP_REACH_NLRI and MP_UNREACH_NLRI attributes are BGP's containers
for carrying opaque information. Each Link-State NLRI describes for carrying opaque information. Each Link-State NLRI describes
either a 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 TBD. 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 TBD for the VPN flavor. AFI 16388 / SAFI 71 for BGP-LS, and AFI 16388 / SAFI TBD for BGP-LS-
VPN.
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 49 skipping to change at page 9, line 49
| Type | NLRI Type | | Type | NLRI Type |
+------+---------------------------+ +------+---------------------------+
| 1 | Node NLRI | | 1 | Node NLRI |
| 2 | Link NLRI | | 2 | Link NLRI |
| 3 | IPv4 Topology Prefix NLRI | | 3 | IPv4 Topology Prefix NLRI |
| 4 | IPv6 Topology Prefix NLRI | | 4 | IPv6 Topology Prefix NLRI |
+------+---------------------------+ +------+---------------------------+
Table 1: NLRI Types Table 1: NLRI Types
Route Distinguishers are defined and discussed in [RFC4364].
The Node NLRI (NLRI Type = 1) is shown in the following figure. The Node NLRI (NLRI Type = 1) 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Protocol-ID | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
| (64 bits) | | (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
The 'Direct' and 'Static' protocol types SHOULD be used when BGP-LS The 'Direct' and 'Static configuration' protocol types SHOULD be used
is sourcing local information. For all information, derived from when BGP-LS is sourcing local information. For all information,
other protocols the corresponding protocol-ID MUST be used. If BGP- derived from other protocols the corresponding protocol-ID MUST be
LS has got direct access to interface information and wants to used. If BGP-LS has got direct access to interface information and
advertise a local link then the protocol-ID 'Direct' SHOULD be used. wants to advertise a local link then the protocol-ID 'Direct' SHOULD
For modeling virtual links, like described in Section 4 the protocol- be used. For modeling virtual links, like described in Section 4 the
ID 'Static configuration' SHOULD be used. protocol-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 3 lists the 'Identifier' from different routing universes. Table 3 lists the 'Identifier'
values that are defined as well-known in this draft. values that are defined as well-known in this draft.
skipping to change at page 12, line 36 skipping to change at page 12, line 36
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 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. BGP-LS uses the Autonomous System (AS) Number and BGP-LS
Identifier (Paragraph 2) in order to disambiguate the Router-IDs, as Identifier (see Section 3.2.1.4) 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
skipping to change at page 13, line 22 skipping to change at page 13, line 22
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 3.2.1.4 a set of sub-TLVs is described, which allows In Section 3.2.1.4 a set of sub-TLVs is described, which allows
specification of a flexible key for any given Node/Link information specification of a flexible key for any given Node/Link 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 (node, link, and prefix). The length of this
contains one or more Node Descriptor Sub-TLVs defined in TLV is variable. The value contains one or more Node Descriptor Sub-
Section 3.2.1.4. TLVs defined in Section 3.2.1.4.
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 Descriptor Sub-TLVs (variable) // // Node Descriptor Sub-TLVs (variable) //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 13 skipping to change at page 16, line 13
Figure 12: Multi-Topology ID TLV format Figure 12: Multi-Topology ID TLV format
where Type is 263, Length is 2*n and n is the number of MT-IDs where Type is 263, Length is 2*n and n is the number of MT-IDs
carried in the TLV. carried in the TLV.
The MT-ID TLV MAY be present in a Link Descriptor, a Prefix The MT-ID TLV MAY be present in a Link Descriptor, a Prefix
Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or Descriptor, or in the BGP-LS attribute of a node NLRI. In a Link or
Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of Prefix Descriptor, only a single MT-ID TLV containing the MT-ID of
the topology where the link or the prefix is reachable is allowed. the topology where the link or the prefix is reachable is allowed.
In case one wants to advertise multiple topologies for a given Link In case one wants to advertise multiple topologies for a given Link
Descriptor or Prefix Descriptor, multiple NRLIs need to be generated Descriptor or Prefix Descriptor, multiple NLRIs need to be generated
where each NLRI contains an unique MT-ID. In the BGP-LS attribute of where each NLRI contains an unique MT-ID. In the BGP-LS attribute of
a node NLRI, one MT-ID TLV containing the array of MT-IDs of all a node NLRI, one MT-ID TLV containing the array of MT-IDs of all
topologies where the node is reachable is allowed. topologies where the node is reachable is allowed.
3.2.2. Link Descriptors 3.2.2. Link Descriptors
The 'Link Descriptor' field is a set of Type/Length/Value (TLV) The 'Link Descriptor' field is a set of Type/Length/Value (TLV)
triplets. The format of each TLV is shown in Section 3.1. The 'Link triplets. The format of each TLV is shown in Section 3.1. The 'Link
descriptor' TLVs uniquely identify a link among multiple parallel descriptor' TLVs uniquely identify a link among multiple parallel
links between a pair of anchor routers. A link described by the Link links between a pair of anchor routers. A link described by the Link
skipping to change at page 18, line 23 skipping to change at page 18, line 23
| | Information | | | | | Information | | |
+--------------+-----------------------+----------+-----------------+ +--------------+-----------------------+----------+-----------------+
Table 6: Prefix Descriptor TLVs Table 6: Prefix Descriptor TLVs
3.2.3.1. OSPF Route Type 3.2.3.1. OSPF Route Type
OSPF Route Type is an optional TLV that MAY be present in Prefix OSPF Route Type is an optional TLV that MAY be present in Prefix
NLRIs. It is used to identify the OSPF route-type of the prefix. It NLRIs. It is used to identify the OSPF route-type of the prefix. It
is used when an OSPF prefix is advertised in the OSPF domain with is used when an OSPF prefix is advertised in the OSPF domain with
multiple route-types. The Route Type TLV allows to discrimination of multiple route-types. The Route Type TLV allows the discrimination
these advertisements. The format of the OSPF Route Type TLV is shown of these advertisements. The format of the OSPF Route Type TLV is
in the following figure. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Type | | Route Type |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 13: OSPF Route Type TLV Format Figure 13: OSPF Route Type TLV Format
skipping to change at page 20, line 35 skipping to change at page 20, line 35
The Node Flag Bits TLV carries a bit mask describing node attributes. The Node Flag Bits TLV carries a bit mask describing node attributes.
The value is a variable length bit array of flags, where each bit The value is a variable length bit array of flags, where each bit
represents a node capability. represents a node capability.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|T|E|B| Reserved| |O|T|E|B|R|V| Rsvd|
+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+
Figure 15: Node Flag Bits TLV format Figure 15: Node Flag Bits TLV format
The bits are defined as follows: The bits are defined as follows:
+----------+-------------------------+-----------+ +-----------------+-------------------------+-----------+
| Bit | Description | Reference | | Bit | Description | Reference |
+----------+-------------------------+-----------+ +-----------------+-------------------------+-----------+
| 'O' | Overload Bit | [RFC1195] | | 'O' | Overload Bit | [RFC1195] |
| 'T' | Attached Bit | [RFC1195] | | 'T' | Attached Bit | [RFC1195] |
| 'E' | External Bit | [RFC2328] | | 'E' | External Bit | [RFC2328] |
| 'B' | ABR Bit | [RFC2328] | | 'B' | ABR Bit | [RFC2328] |
| Reserved | Reserved for future use | | | 'R' | Router Bit | [RFC5340] |
+----------+-------------------------+-----------+ | 'V' | V6 Bit | [RFC5340] |
| Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+-----------+
Table 8: Node Flag Bits Definitions Table 8: Node Flag Bits Definitions
3.3.1.2. IS-IS Area Identifier TLV 3.3.1.2. IS-IS Area Identifier TLV
An IS-IS node can be part of one or more IS-IS areas. Each of these An IS-IS node can be part of one or more IS-IS areas. Each of these
area addresses is carried in the IS-IS Area Identifier TLV. If area addresses is carried in the IS-IS Area Identifier TLV. If
multiple Area Addresses are present, multiple TLVs are used to encode multiple Area Addresses are present, multiple TLVs are used to encode
them. The IS-IS Area Identifier TLV may be present in the BGP-LS them. The IS-IS Area Identifier TLV may be present in the BGP-LS
attribute only when advertised in the Link-State Node NLRI. attribute only when advertised in the Link-State Node NLRI.
skipping to change at page 23, line 5 skipping to change at page 23, line 28
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 valid in the LINK_STATE The following 'Link Attribute' TLVs are valid in the BGP-LS attribute
attribute: with a link NLRI:
+-----------+---------------------+--------------+------------------+ +-----------+---------------------+--------------+------------------+
| 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 | | |
| 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 |
skipping to change at page 24, line 7 skipping to change at page 24, line 50
The local/remote IPv4/IPv6 Router-ID TLVs are used to describe The local/remote IPv4/IPv6 Router-ID TLVs are used to describe
auxiliary Router-IDs that the IGP might be using, e.g., for TE auxiliary Router-IDs that the IGP might be using, e.g., for TE
purposes. All auxiliary Router-IDs of both the local and the remote purposes. All auxiliary Router-IDs of both the local and the remote
node MUST be included in the link attribute of each link NLRI. If node MUST be included in the link attribute of each link NLRI. If
there are more than one auxiliary Router-ID of a given type, then there are more than one auxiliary Router-ID of a given type, then
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 Mask 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 and
originators that have local link insight, like for example Protocol- SHOULD only be used with originators that have local link insight,
IDs 'Static' or 'Direct' as per Table 2. The 'MPLS Protocol Mask' like for example the Protocol-IDs 'Static' or 'Direct' as per
TLV MUST NOT be included in NLRIs with protocol-IDs 'IS-IS L1', 'IS- Table 2. The 'MPLS Protocol Mask' TLV MUST NOT be included in NLRIs
IS L2', 'OSPFv2' or 'OSPFv3' as per Table 2. with the other Protocol-IDs listed in 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 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 19: MPLS Protocol TLV Figure 19: MPLS Protocol Mask TLV
The following bits are defined: The following bits are defined:
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| Bit | Description | Reference | | Bit | Description | Reference |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| '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 Traffic engineering metric for The TE Default Metric TLV carries the Traffic Engineering metric for
this link. The length of this TLV is fixed at 4 octets. If a source this link. The length of this TLV is fixed at 4 octets. If a source
protocol (e.g. IS-IS) does not support a Metric width of 32 bits protocol uses a Metric width of less than 32 bits then the high order
then the high order octet MUST be set to zero. bits of this field MUST be padded with 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 27, line 31 skipping to change at page 28, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link Name (variable) // // Link Name (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: Link Name format Figure 24: Link Name format
3.3.3. Prefix Attribute TLVs 3.3.3. Prefix Attribute TLVs
Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set Prefixes are learned from the IGP topology (IS-IS or OSPF) with a set
of IGP attributes (such as metric, route tags, etc.) that MUST be of IGP attributes (such as metric, route tags, etc.) that MUST be
reflected into the LINK_STATE attribute. This section describes the reflected into the BGP-LS attribute with a link NLRI. This section
different attributes related to the IPv4/IPv6 prefixes. Prefix describes the different attributes related to the IPv4/IPv6 prefixes.
Attributes TLVs SHOULD be used when advertising NLRI types 3 and 4 Prefix Attributes TLVs SHOULD be used when advertising NLRI types 3
only. The following attributes TLVs are defined: and 4 only. The following attributes TLVs are defined:
+---------------+----------------------+----------+-----------------+ +---------------+----------------------+----------+-----------------+
| TLV Code | Description | Length | Reference | | TLV Code | Description | Length | Reference |
| Point | | | | | Point | | | |
+---------------+----------------------+----------+-----------------+ +---------------+----------------------+----------+-----------------+
| 1152 | IGP Flags | 1 | Section 3.3.3.1 | | 1152 | IGP Flags | 1 | Section 3.3.3.1 |
| 1153 | Route Tag | 4*n | Section 3.3.3.2 | | 1153 | Route Tag | 4*n | Section 3.3.3.2 |
| 1154 | Extended Tag | 8*n | Section 3.3.3.3 | | 1154 | Extended Tag | 8*n | Section 3.3.3.3 |
| 1155 | Prefix Metric | 4 | Section 3.3.3.4 | | 1155 | Prefix Metric | 4 | Section 3.3.3.4 |
| 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 | | 1156 | OSPF Forwarding | 4 | Section 3.3.3.5 |
skipping to change at page 29, line 29 skipping to change at page 30, line 29
Length is a multiple of 8. Length is a multiple of 8.
The 'Extended Route Tag' field contains one or more Extended Route The 'Extended Route Tag' field contains one or more Extended Route
Tags as learned in the IGP topology. Tags as learned in the IGP topology.
3.3.3.4. Prefix Metric TLV 3.3.3.4. Prefix Metric TLV
Prefix Metric TLV is an optional attribute and may only appear once. Prefix Metric TLV is an optional attribute and may only appear once.
If present, it carries the metric of the prefix as known in the IGP If present, it carries the metric of the prefix as known in the IGP
topology [RFC5305] (and therefore represents the reachability cost to topology as described in Section 4 of [RFC5305] (and therefore
the prefix). If not present, it means that the prefix is advertised represents the reachability cost to the prefix). If not present, it
without any reachability. means that the prefix is advertised without any reachability.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Metric | | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: Prefix Metric TLV Format Figure 28: Prefix Metric TLV Format
skipping to change at page 31, line 40 skipping to change at page 32, line 40
3.6. Router-ID Anchoring Example: ISO Pseudonode 3.6. Router-ID Anchoring Example: ISO Pseudonode
Encoding of a broadcast LAN in IS-IS provides a good example of how Encoding of a broadcast LAN in IS-IS provides a good example of how
Router-IDs are encoded. Consider Figure 31. This represents a Router-IDs are encoded. Consider Figure 31. This represents a
Broadcast LAN between a pair of routers. The "real" (=non Broadcast LAN between a pair of routers. The "real" (=non
pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID. pseudonode) routers have both an IPv4 Router-ID and IS-IS Node-ID.
The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for The pseudonode does not have an IPv4 Router-ID. Node1 is the DIS for
the LAN. Two unidirectional links (Node1, Pseudonode 1) and the LAN. Two unidirectional links (Node1, Pseudonode 1) and
(Pseudonode1, Node2) are being generated. (Pseudonode1, Node2) are being generated.
The link NRLI of (Node1, Pseudonode1) is encoded as follows: the IGP The link NLRI of (Node1, Pseudonode1) is encoded as follows: the IGP
Router-ID TLV of the local node descriptor is 6 octets long Router-ID TLV of the local node descriptor is 6 octets long
containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of containing ISO-ID of Node1, 1920.0000.2001; the IGP Router-ID TLV of
the remote node descriptor is 7 octets long containing the ISO-ID of the remote node descriptor is 7 octets long containing the ISO-ID of
Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link Pseudonode1, 1920.0000.2001.02. The BGP-LS attribute of this link
contains one local IPv4 Router-ID TLV (TLV type 1028) containing contains one local IPv4 Router-ID TLV (TLV type 1028) containing
192.0.2.1, the IPv4 Router-ID of Node1. 192.0.2.1, the IPv4 Router-ID of Node1.
The link NRLI of (Pseudonode1. Node2) is encoded as follows: the IGP The link NLRI of (Pseudonode1. Node2) is encoded as follows: the IGP
Router-ID TLV of the local node descriptor is 7 octets long Router-ID TLV of the local node descriptor is 7 octets long
containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP containing the ISO-ID of Pseudonode1, 1920.0000.2001.02; the IGP
Router-ID TLV of the remote node descriptor is 6 octets long Router-ID TLV of the remote node descriptor is 6 octets long
containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of containing ISO-ID of Node2, 1920.0000.2002. The BGP-LS attribute of
this link contains one remote IPv4 Router-ID TLV (TLV type 1030) this link contains one remote IPv4 Router-ID TLV (TLV type 1030)
containing 192.0.2.2, the IPv4 Router-ID of Node2. containing 192.0.2.2, the IPv4 Router-ID of Node2.
+-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+ +-----------------+
| Node1 | | Pseudonode1 | | Node2 | | Node1 | | Pseudonode1 | | Node2 |
|1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00| |1920.0000.2001.00|--->|1920.0000.2001.02|--->|1920.0000.2002.00|
skipping to change at page 32, line 29 skipping to change at page 33, line 29
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 DR 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 NLRI 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
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: 10.1.1.1:10.1.1.1 TLV #515: IGP Router ID: 11.11.11.11:10.1.1.1
TLV #514: OSPF Area-ID: ID:0.0.0.0 TLV #514: OSPF Area-ID: ID:0.0.0.0
The link NRLI of (Pseudonode1, Node2) is encoded as follows: The link NLRI of (Pseudonode1, Node2) is encoded as follows:
o Local Node Descriptor o Local Node Descriptor
TLV #515: IGP Router ID: 10.1.1.1:10.1.1.1 TLV #515: IGP Router ID: 11.11.11.11:10.1.1.1
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 |
skipping to change at page 34, line 14 skipping to change at page 35, line 14
specific links or aggregated links is an operator's policy choice. specific links or aggregated links is an operator's policy choice.
To highlight the varying levels of exposure, the following deployment To highlight the varying levels of exposure, the following deployment
examples are discussed. examples are discussed.
4.1. Example: No Link Aggregation 4.1. Example: No Link Aggregation
Consider Figure 33. Both AS1 and AS2 operators want to protect their Consider Figure 33. Both AS1 and AS2 operators want to protect their
inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to inter-AS {R1,R3}, {R2, R4} links using RSVP-FRR LSPs. If R1 wants to
compute its link-protection LSP to R3 it needs to "see" an alternate compute its link-protection LSP to R3 it needs to "see" an alternate
path to R3. Therefore the AS2 operator exposes its topology. All path to R3. Therefore the AS2 operator exposes its topology. All
BGP TE enabled routers in AS1 "see" the full topology of AS and BGP TE enabled routers in AS1 "see" the full topology of AS2 and
therefore can compute a backup path. Note that the decision if the therefore can compute a backup path. Note that the decision if the
direct link between {R3, R4} or the {R4, R5, R3) path is used is made direct link between {R3, R4} or the {R4, R5, R3) path is used is made
by the computing router. by the computing router.
AS1 : AS2 AS1 : AS2
: :
R1-------R3 R1-------R3
| : | \ | : | \
| : | R5 | : | R5
| : | / | : | /
skipping to change at page 36, line 27 skipping to change at page 37, line 27
[RFC5226]). [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
(=Specification required) and approval by the Designated Expert (=Specification required) and approval by the Designated Expert
assigned by the IESG (see [RFC5226]). assigned by the IESG (see [RFC5226]).
Note to RFC Editor: this section may be removed on publication as an 5.1. Guidance for Designated Experts
RFC.
In all cases of review by Designated Expert (DE) described here, the
DE is expected to ascertain the existence of suitable documentation
(a specification) as described in [RFC5226], and to verify the
permanent and publically ready availability of the document. The DE
is also expected to check the clarity of purpose and use of the
requested code points. Lastly, the DE must verify that any
specification produced in the IETF that requests one of these code
points has been made available for review by the IDR working group,
and that any specification produced outside the IETF does not
conflict with work that is active or already published within the
IETF.
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
6.1.1. Operations 6.1.1. Operations
Existing BGP operational procedures apply. No new operation Existing BGP operational procedures apply. No new operation
skipping to change at page 37, line 49 skipping to change at page 39, line 9
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/ The IDR working group has documented and continues to document parts
YANG models. of the Management Information Base and YANG models for managing and
monitoring BGP speakers and the sessions between them. It is
currently believed that the BGP session running BGP-LS is not
substantially different from any other BGP session and can be managed
using the same data 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
MUST use the 'Attribute Discard' action as per MUST use the 'Attribute Discard' action as per [RFC7606] 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?
o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI
attribute correspond to the BGP MP_UNREACH_NLRI length ? attribute correspond to the BGP MP_UNREACH_NLRI length?
o Does the sum of all TLVs found in a Node-, Link or Prefix o Does the sum of all TLVs found in a Node-, Link or Prefix
Descriptor NLRI attribute correspond to the Node-, Link- or Prefix Descriptor NLRI attribute correspond to the Node-, Link- or Prefix
Descriptors 'Total NLRI Length' field ? Descriptors 'Total NLRI Length' field?
o Does any fixed length TLV correspond to the TLV Length field in o Does any fixed length TLV correspond to the TLV Length field in
this document ? 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 38, line 51 skipping to change at page 40, line 13
number of Link-State NLRIs stored in router's RIB. number of Link-State NLRIs stored in router's RIB.
An implementation SHOULD allow the operator to create abstracted An implementation SHOULD allow the operator to create abstracted
topologies that are advertised to neighbors; Create different topologies that are advertised to neighbors; Create different
abstractions for different neighbors. abstractions for different neighbors.
An implementation SHOULD allow the operator to configure a 64-bit An implementation SHOULD allow the operator to configure a 64-bit
instance ID. instance ID.
An implementation SHOULD allow the operator to configure a pair of An implementation SHOULD allow the operator to configure a pair of
ASN and BGP-LS identifier (Paragraph 2) per flooding set in which the ASN and BGP-LS identifier (Section 3.2.1.4) per flooding set in which
node participates. the node participates.
6.2.4. Accounting Management 6.2.4. Accounting Management
Not Applicable. Not Applicable.
6.2.5. Performance Management 6.2.5. Performance Management
An implementation SHOULD provide the following statistics: An implementation SHOULD provide the following statistics:
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
These statistics should be recorded as absolute counts since system
or session start time. An implementation MAY also enhance this
information by also recording peak per-second counts in each case.
6.2.6. Security Management 6.2.6. Security Management
An operator SHOULD define an import policy to limit inbound updates An operator SHOULD define an import policy to limit inbound updates
as follows: 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. An implementation MUST have means to limit inbound updates.
7. TLV/Sub-TLV Code Points Summary 7. TLV/Sub-TLV Code Points Summary
skipping to change at page 41, line 50 skipping to change at page 43, line 17
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, Matt Miller, Mike Shand, Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand,
Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas
Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro,
Balaji Rajagopalan and Yakov Rekhter for their comments. Balaji Rajagopalan, Yakov Rekhter, and Alvaro Retana 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, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545, March Extensions for IPv6 Inter-Domain Routing", RFC 2545,
1999. DOI 10.17487/RFC2545, March 1999,
<http://www.rfc-editor.org/info/rfc2545>.
[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, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<http://www.rfc-editor.org/info/rfc4202>.
[RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in
of Generalized Multi-Protocol Label Switching (GMPLS)", Support of Generalized Multi-Protocol Label Switching
RFC 4203, October 2005. (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005,
<http://www.rfc-editor.org/info/rfc4203>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[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,
2007. DOI 10.17487/RFC4760, January 2007,
<http://www.rfc-editor.org/info/rfc4760>.
[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",
4915, June 2007. RFC 4915, DOI 10.17487/RFC4915, June 2007,
<http://www.rfc-editor.org/info/rfc4915>.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Specification", RFC 5036, October 2007. "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008. Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<http://www.rfc-editor.org/info/rfc5120>.
[RFC5130] Previdi, S., Shand, M., and C. Martin, "A Policy Control [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy
Mechanism in IS-IS Using Administrative Tags", RFC 5130, Control Mechanism in IS-IS Using Administrative Tags",
February 2008. RFC 5130, DOI 10.17487/RFC5130, February 2008,
<http://www.rfc-editor.org/info/rfc5130>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, October 2008. Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, October 2008. Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5307] Kompella, K. and Y. Rekhter, "IS-IS Extensions in Support [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions
of Generalized Multi-Protocol Label Switching (GMPLS)", in Support of Generalized Multi-Protocol Label Switching
RFC 5307, October 2008. (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008,
<http://www.rfc-editor.org/info/rfc5307>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5890] Klensin, J., "Internationalized Domain Names for [RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework", Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010. RFC 5890, DOI 10.17487/RFC5890, August 2010,
<http://www.rfc-editor.org/info/rfc5890>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, February 2011. Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <http://www.rfc-editor.org/info/rfc6119>.
[RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP [RFC6286] Chen, E. and J. Yuan, "Autonomous-System-Wide Unique BGP
Identifier for BGP-4", RFC 6286, June 2011. Identifier for BGP-4", RFC 6286, DOI 10.17487/RFC6286,
June 2011, <http://www.rfc-editor.org/info/rfc6286>.
[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, DOI 10.17487/RFC6549,
March 2012, <http://www.rfc-editor.org/info/rfc6549>.
[RFC6822] Previdi, S., Ginsberg, L., Shand, M., Roy, A., and D. [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D.
Ward, "IS-IS Multi-Instance", RFC 6822, December 2012. Ward, "IS-IS Multi-Instance", RFC 6822,
DOI 10.17487/RFC6822, December 2012,
<http://www.rfc-editor.org/info/rfc6822>.
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<http://www.rfc-editor.org/info/rfc7606>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-idr-error-handling] [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
Chen, E., Scudder, J., Mohapatra, P., and K. Patel, and E. Lear, "Address Allocation for Private Internets",
"Revised Error Handling for BGP UPDATE Messages", draft- BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
ietf-idr-error-handling-18 (work in progress), December <http://www.rfc-editor.org/info/rfc1918>.
2014.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
4272, January 2006. RFC 4272, DOI 10.17487/RFC4272, January 2006,
<http://www.rfc-editor.org/info/rfc4272>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <http://www.rfc-editor.org/info/rfc4364>.
[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,
DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007. Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July
2007, <http://www.rfc-editor.org/info/rfc4970>.
[RFC5073] Vasseur, J. and J. Le Roux, "IGP Routing Protocol [RFC5073] Vasseur, J., Ed. and J. Le Roux, Ed., "IGP Routing
Extensions for Discovery of Traffic Engineering Node Protocol Extensions for Discovery of Traffic Engineering
Capabilities", RFC 5073, December 2007. Node Capabilities", RFC 5073, DOI 10.17487/RFC5073,
December 2007, <http://www.rfc-editor.org/info/rfc5073>.
[RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Path Computation Method for Establishing Inter-Domain Per-Domain Path Computation Method for Establishing Inter-
Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC Domain Traffic Engineering (TE) Label Switched Paths
5152, February 2008. (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008,
<http://www.rfc-editor.org/info/rfc5152>.
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, December 2008. Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <http://www.rfc-editor.org/info/rfc5316>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, January 2009. Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
January 2009, <http://www.rfc-editor.org/info/rfc5392>.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October Optimization (ALTO) Problem Statement", RFC 5693,
2009. DOI 10.17487/RFC5693, October 2009,
<http://www.rfc-editor.org/info/rfc5693>.
[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",
5706, November 2009. RFC 5706, DOI 10.17487/RFC5706, November 2009,
<http://www.rfc-editor.org/info/rfc5706>.
[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, DOI 10.17487/RFC6952, May 2013,
<http://www.rfc-editor.org/info/rfc6952>.
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
Traffic Optimization (ALTO) Protocol", RFC 7285, September "Application-Layer Traffic Optimization (ALTO) Protocol",
2014. RFC 7285, DOI 10.17487/RFC7285, September 2014,
<http://www.rfc-editor.org/info/rfc7285>.
Authors' Addresses Authors' Addresses
Hannes Gredler (editor) Hannes Gredler (editor)
Juniper Networks, Inc. Private Contributor
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: hannes@juniper.net Email: hannes@gredler.at
Jan Medved Jan Medved
Cisco Systems, Inc. Cisco Systems, Inc.
170, West Tasman Drive 170, West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200 Via Del Serafico, 200
Rome 00142 Rome 00142
Italy Italy
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Adrian Farrel Adrian Farrel
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA 94089
US
Email: afarrel@juniper.net Email: adrian@olddog.co.uk
Saikat Ray Saikat Ray
Email: raysaikat@gmail.com Email: raysaikat@gmail.com
 End of changes. 83 change blocks. 
190 lines changed or deleted 255 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/