< draft-ketant-idr-rfc7752bis-00.txt   draft-ketant-idr-rfc7752bis-01.txt >
Inter-Domain Routing K. Talaulikar, Ed. Inter-Domain Routing K. Talaulikar, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track H. Gredler Intended status: Standards Track H. Gredler
Expires: September 26, 2019 Rtbrick Expires: January 9, 2020 Rtbrick
J. Medved J. Medved
Cisco Systems, Inc. Cisco Systems, Inc.
S. Previdi S. Previdi
Individual Contributor Individual Contributor
A. Farrel A. Farrel
Juniper Networks, Inc. Old Dog Consulting
S. Ray S. Ray
Individual Contributor Individual Contributor
March 25, 2019 July 8, 2019
Distribution of Link-State and Traffic Engineering Information Using BGP Distribution of Link-State and Traffic Engineering Information Using BGP
draft-ketant-idr-rfc7752bis-00 draft-ketant-idr-rfc7752bis-01
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 (TE) information. This is information typically Traffic Engineering (TE) 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 link-state and TE This document describes a mechanism by which link-state and TE
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 26, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 36 4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 36
4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38 4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38
4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39 4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39
4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40 4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40
5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 40 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 40
5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41
5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 41 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 41
5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
6.1. Guidance for Designated Experts . . . . . . . . . . . . . 43 6.1. Guidance for Designated Experts . . . . . . . . . . . . . 43
7. Manageability Considerations . . . . . . . . . . . . . . . . 43 7. Manageability Considerations . . . . . . . . . . . . . . . . 44
7.1. Operational Considerations . . . . . . . . . . . . . . . 43 7.1. Operational Considerations . . . . . . . . . . . . . . . 44
7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 43 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44
7.1.2. Installation and Initial Setup . . . . . . . . . . . 44 7.1.2. Installation and Initial Setup . . . . . . . . . . . 44
7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 44 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 44
7.1.4. Requirements on Other Protocols and Functional 7.1.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . 44 Components . . . . . . . . . . . . . . . . . . . . . 44
7.1.5. Impact on Network Operation . . . . . . . . . . . . . 44 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45
7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 44 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45
7.2. Management Considerations . . . . . . . . . . . . . . . . 45 7.2. Management Considerations . . . . . . . . . . . . . . . . 45
7.2.1. Management Information . . . . . . . . . . . . . . . 45 7.2.1. Management Information . . . . . . . . . . . . . . . 45
7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 45 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 45
7.2.3. Configuration Management . . . . . . . . . . . . . . 47 7.2.3. Configuration Management . . . . . . . . . . . . . . 48
7.2.4. Accounting Management . . . . . . . . . . . . . . . . 48 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 48
7.2.5. Performance Management . . . . . . . . . . . . . . . 48 7.2.5. Performance Management . . . . . . . . . . . . . . . 48
7.2.6. Security Management . . . . . . . . . . . . . . . . . 48 7.2.6. Security Management . . . . . . . . . . . . . . . . . 49
8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 48 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
12.1. Normative References . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . 52
12.2. Informative References . . . . . . . . . . . . . . . . . 54 12.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 55 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
The contents of a Link-State Database (LSDB) or of an IGP's Traffic The contents of a Link-State Database (LSDB) or of an IGP's Traffic
Engineering Database (TED) describe only the links and nodes within Engineering Database (TED) describe only the links and nodes within
an IGP area. Some applications, such as end-to-end Traffic an IGP area. Some applications, such as end-to-end Traffic
Engineering (TE), would benefit from visibility outside one area or Engineering (TE), would benefit from visibility outside one area or
Autonomous System (AS) in order to make better decisions. Autonomous System (AS) in order to make better decisions.
skipping to change at page 12, line 33 skipping to change at page 12, line 33
itself. For VPN applications, it also includes the length of the itself. For VPN applications, it also includes the length of the
Route Distinguisher. Route Distinguisher.
+-------------+---------------------------+ +-------------+---------------------------+
| Type | NLRI Type | | Type | NLRI Type |
+-------------+---------------------------+ +-------------+---------------------------+
| 1 | Node NLRI | | 1 | Node NLRI |
| 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 |
| 32768-65535 | Private Use | | 65000-65535 | Private Use |
+-------------+---------------------------+ +-------------+---------------------------+
Table 1: NLRI Types Table 1: NLRI Types
Route Distinguishers are defined and discussed in [RFC4364]. 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
skipping to change at page 14, line 31 skipping to change at page 14, line 31
+-------------+----------------------------------+ +-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol | | Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+ +-------------+----------------------------------+
| 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 |
| 128-255 | Private Use | | 200-255 | Private Use |
+-------------+----------------------------------+ +-------------+----------------------------------+
Table 2: Protocol Identifiers Table 2: Protocol Identifiers
The 'Direct' and 'Static configuration' protocol types SHOULD be used The 'Direct' and 'Static configuration' protocol types SHOULD be used
when BGP-LS is sourcing local information. For all information when BGP-LS is sourcing local information. For all information
derived from other protocols, the corresponding Protocol-ID MUST be derived from other protocols, the corresponding Protocol-ID MUST be
used. If BGP-LS has direct access to interface information and wants used. If BGP-LS has direct access to interface information and wants
to advertise a local link, then the Protocol-ID 'Direct' SHOULD be to advertise a local link, then the Protocol-ID 'Direct' SHOULD be
used. For modeling virtual links, such as described in Section 5, used. For modeling virtual links, such as described in Section 5,
skipping to change at page 25, line 36 skipping to change at page 25, line 36
| Reserved (Rsvd) | Reserved for future use | | | Reserved (Rsvd) | Reserved for future use | |
+-----------------+-------------------------+------------+ +-----------------+-------------------------+------------+
Table 7: Node Flag Bits Definitions Table 7: Node Flag Bits Definitions
4.3.1.2. IS-IS Area Identifier TLV 4.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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Area Identifier (variable) // // Area Identifier (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 40, line 4 skipping to change at page 40, line 4
TLV #515: IGP Router-ID: 11.11.11.11: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
10.1.1.1/24 10.1.1.2/24
+-----------------+ +-----------------+ +-----------------+ +-------------+ +-------------+ +-------------+
| Node1 | | Pseudonode1 | | Node2 | | Node1 | | Pseudonode1 | | Node2 |
| 11.11.11.11 |--->| 11.11.11.11 |--->| 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 33: OSPF Pseudonodes Figure 33: OSPF Pseudonodes
The LAN subnet 10.1.1.0/24 is not included in the Router LSA of Node1
or Node2. The Network LSA for this LAN advertised by the DR Node1
contains the subnet mask for the LAN along with the DR address. A
Prefix NLRI corresponding to the LAN subnet is advertised with the
Pseudonode1 used as the Local node using the DR address and the
subnet mask from the Network LSA.
4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration 4.10. 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
coordination requires identifying a given physical link in both IGPs. coordination requires identifying a given physical link in both IGPs.
The IPv4 Router-ID provides that "glue", which is present in the Node The IPv4 Router-ID provides that "glue", which is present in the Node
Descriptors of the OSPF Link NLRI and in the link attribute of the Descriptors of the OSPF Link NLRI and in the link attribute of the
IS-IS Link NLRI. IS-IS Link NLRI.
Consider a point-to-point link between two routers, A and B, that Consider a point-to-point link between two routers, A and B, that
skipping to change at page 42, line 45 skipping to change at page 43, line 8
Parameters" registry. Parameters" registry.
IANA has created a new "Border Gateway Protocol - Link State (BGP-LS) IANA has created a new "Border Gateway Protocol - Link State (BGP-LS)
Parameters" registry at <http://www.iana.org/assignments/bgp-ls- Parameters" registry at <http://www.iana.org/assignments/bgp-ls-
parameters>. All of the following registries are BGP-LS specific and parameters>. All of the following registries are BGP-LS specific and
are accessible under this registry: are accessible under this registry:
o "BGP-LS NLRI-Types" registry o "BGP-LS NLRI-Types" registry
Value 0 is reserved. The maximum value is 65535. The range Value 0 is reserved. The maximum value is 65535. The range
32768-65535 is for Private Use. The registry has been populated 65000-65535 is for Private Use. The registry has been populated
with the values shown in Table 1. Allocations within the registry with the values shown in Table 1. Allocations within the registry
require documentation of the proposed use of the allocated value 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 [RFC8126]). assigned by the IESG (see [RFC8126]).
o "BGP-LS Protocol-IDs" registry o "BGP-LS Protocol-IDs" registry
Value 0 is reserved. The maximum value is 255. The range 128-255
Value 0 is reserved. The maximum value is 255. The range 200-255
is for Private Use. The registry has been populated with the is for Private Use. The registry has been populated with the
values shown in Table 2. Allocations within the registry require values shown in Table 2. Allocations within the registry require
documentation of the proposed use of the allocated value 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 [RFC8126]). assigned by the IESG (see [RFC8126]).
o "BGP-LS Well-Known Instance-IDs" registry o "BGP-LS Well-Known Instance-IDs" registry
This registry was setup via [RFC7752] and is no longer required. This registry was setup via [RFC7752] and is no longer required.
It may be retained as deprecated. It may be retained as deprecated.
o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and o "BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and
Attribute TLVs" registry Attribute TLVs" registry
Values 0-255 are reserved. Values 256-65535 will be used for code Values 0-255 are reserved. Values 256-65535 will be used for code
points. The range 32768-65535 is for Private Use. The registry points. The range 65000-65535 is for Private Use. The registry
has been populated with the values shown in Table 12. Allocations has been populated with the values shown in Table 12. Allocations
within the registry require documentation of the proposed use of within the registry require documentation of the proposed use of
the allocated value (Specification Required) and approval by the the allocated value (Specification Required) and approval by the
Designated Expert assigned by the IESG (see [RFC8126]). Designated Expert assigned by the IESG (see [RFC8126]).
6.1. Guidance for Designated Experts 6.1. Guidance for Designated Experts
In all cases of review by the Designated Expert (DE) described here, In all cases of review by the Designated Expert (DE) described here,
the DE is expected to ascertain the existence of suitable the DE is expected to ascertain the existence of suitable
documentation (a specification) as described in [RFC8126] and to documentation (a specification) as described in [RFC8126] and to
skipping to change at page 47, line 15 skipping to change at page 47, line 29
information for that object and not assume its deletion/withdraw. information for that object and not assume its deletion/withdraw.
This also makes it possible for a network operator to trace back to This also makes it possible for a network operator to trace back to
the BGP-LS Propagator which actually detected a fault with the BGP-LS the BGP-LS Propagator which actually detected a fault with the BGP-LS
Attribute. Attribute.
An implementation SHOULD log an error for any errors found during An implementation SHOULD log an error for any errors found during
syntax validation for further analysis. syntax validation for further analysis.
A BGP-LS Propagator SHOULD NOT perform semantic validation of the A BGP-LS Propagator SHOULD NOT perform semantic validation of the
Link-State NLRI or the BGP-LS Attribute to determine if it is Link-State NLRI or the BGP-LS Attribute to determine if it is
malformed or invalid. Such validation can be expected to be malformed or invalid. Some types of semantic validation that are not
performed by the BGP-LS Consumer. Some types of semantic validation to be performed by a BGP-LS Propagator are as follows (and this is
that are not to be performed by a BGP-LS Propagator are as follows not to be considered as an exhaustive list):
(and this is not to be considered as an exhaustive list):
o is a mandatory TLV present or not? o is a mandatory TLV present or not?
o is the length of a fixed length TLV correct or the length of a o is the length of a fixed length TLV correct or the length of a
variable length TLV a valid/permissible? variable length TLV a valid/permissible?
o are the values of TLV fields valid or permissible? o are the values of TLV fields valid or permissible?
o are the inclusion and use of TLVs/sub-TLVs with specific Link- o are the inclusion and use of TLVs/sub-TLVs with specific Link-
State NLRI types valid? State NLRI types valid?
skipping to change at page 51, line 22 skipping to change at page 51, line 37
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 RFC7752. he gave to RFC7752.
11. Acknowledgements 11. Acknowledgements
This document update to the BGP-LS specification [RFC7752] is a This document update to the BGP-LS specification [RFC7752] is a
result of feedback and inputs from the discussions in the IDR working result of feedback and inputs from the discussions in the IDR working
group. It also incorporates certain details and clarifications based group. It also incorporates certain details and clarifications based
on implementation and deployment experience with BGP-LS. on implementation and deployment experience with BGP-LS.
Cengiz Alaettinoglu and Parag Amritkar brought forward the need to
clarify the advertisement of LAN subnet for OSPF.
We would like to thank Balaji Rajagopalan, Srihari Sangli and
Shraddha Hegde for their review and feedback on this document.
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, Yakov Rekhter, Alvaro Retana, Barry Leiba, and Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and
Ben Campbell for their comments on RFC7752. Ben Campbell for their comments on RFC7752.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-idr-bgp-extended-messages] [I-D.ietf-idr-bgp-extended-messages]
Bush, R., Patel, K., and D. Ward, "Extended Message Bush, R., Patel, K., and D. Ward, "Extended Message
support for BGP", draft-ietf-idr-bgp-extended-messages-29 support for BGP", draft-ietf-idr-bgp-extended-messages-33
(work in progress), March 2019. (work in progress), July 2019.
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate System to Intermediate System intra-domain "Intermediate System to Intermediate System intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", ISO/ connectionless-mode network service (ISO 8473)", ISO/
IEC 10589, November 2002. IEC 10589, November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 57, line 5 skipping to change at page 57, line 28
8. Update the usage of OSPF Route Type TLV to mandate its use for 8. Update the usage of OSPF Route Type TLV to mandate its use for
OSPF prefixes in Section 4.2.3.1 since this is required for OSPF prefixes in Section 4.2.3.1 since this is required for
segregation of intra-area prefixes that are used to reach a node segregation of intra-area prefixes that are used to reach a node
(e.g. a loopback) from other types of inter-area and external (e.g. a loopback) from other types of inter-area and external
prefixes. prefixes.
9. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF 9. Updated the Node Name TLV in Section 4.3.1.3 with the OSPF
specification. specification.
10. Introduced Private Use TLV code point space and specified their 10. Clarified the advertisement of the prefix corresponding to the
LAN segment in an OSPF network in Section 4.9.
11. Introduced Private Use TLV code point space and specified their
encoding in Section 4.4. encoding in Section 4.4.
11. Introduced Section 4.7 where issues related to consistency of 12. Introduced Section 4.7 where issues related to consistency of
reporting IGP link-state along with their solutions are covered. reporting IGP link-state along with their solutions are covered.
12. Handling of large size of BGP-LS Attribute with growth in BGP-LS 13. Handling of large size of BGP-LS Attribute with growth in BGP-LS
information is explained in Section 4.3 along with mitigation of information is explained in Section 4.3 along with mitigation of
errors arising out of it. errors arising out of it.
13. Added recommendation for isolation of BGP-LS sessions from other 14. Added recommendation for isolation of BGP-LS sessions from other
BGP route exchange to avoid errors and faults in BGP-LS BGP route exchange to avoid errors and faults in BGP-LS
affecting the normal BGP routing. affecting the normal BGP routing.
14. Updated the Fault Management section with detailed rules based 15. Updated the Fault Management section with detailed rules based
on the role in the BGP-LS information propagation flow. on the role in the BGP-LS information propagation flow.
Authors' Addresses Authors' Addresses
Ketan Talaulikar (editor) Ketan Talaulikar (editor)
Cisco Systems Cisco Systems
India India
Email: ketant@cisco.com Email: ketant@cisco.com
Hannes Gredler Hannes Gredler
Rtbrick Rtbrick
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
skipping to change at page 58, line 4 skipping to change at page 58, line 29
US US
Email: jmedved@cisco.com Email: jmedved@cisco.com
Stefano Previdi Stefano Previdi
Individual Contributor Individual Contributor
Rome Rome
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Adrian Farrel Adrian Farrel
Juniper Networks, Inc. Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Saikat Ray Saikat Ray
Individual Contributor Individual Contributor
Email: raysaikat@gmail.com Email: raysaikat@gmail.com
 End of changes. 30 change blocks. 
42 lines changed or deleted 58 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/