draft-ietf-idr-rfc7752bis-02.txt   draft-ietf-idr-rfc7752bis-03.txt 
Inter-Domain Routing K. Talaulikar, Ed. Inter-Domain Routing K. Talaulikar, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Obsoletes: 7752 (if approved) November 1, 2019 Obsoletes: 7752 (if approved) March 5, 2020
Intended status: Standards Track Intended status: Standards Track
Expires: May 4, 2020 Expires: September 6, 2020
Distribution of Link-State and Traffic Engineering Information Using BGP Distribution of Link-State and Traffic Engineering Information Using BGP
draft-ietf-idr-rfc7752bis-02 draft-ietf-idr-rfc7752bis-03
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 1, line 49 skipping to change at page 1, line 49
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 May 4, 2020. This Internet-Draft will expire on September 6, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 47 skipping to change at page 2, line 47
4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32
4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 35 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 35
4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36
4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36
4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37 4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37
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 . . . . . . . . . . . . . . . . . . 41 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 41
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 . . . . . . . . . 42
5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
6.1. Guidance for Designated Experts . . . . . . . . . . . . . 43 6.1. Guidance for Designated Experts . . . . . . . . . . . . . 44
7. Manageability Considerations . . . . . . . . . . . . . . . . 44 7. Manageability Considerations . . . . . . . . . . . . . . . . 44
7.1. Operational Considerations . . . . . . . . . . . . . . . 44 7.1. Operational Considerations . . . . . . . . . . . . . . . 44
7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 44
7.1.2. Installation and Initial Setup . . . . . . . . . . . 44 7.1.2. Installation and Initial Setup . . . . . . . . . . . 45
7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 44 7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 45
7.1.4. Requirements on Other Protocols and Functional 7.1.4. Requirements on Other Protocols and Functional
Components . . . . . . . . . . . . . . . . . . . . . 45 Components . . . . . . . . . . . . . . . . . . . . . 45
7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45 7.1.5. Impact on Network Operation . . . . . . . . . . . . . 45
7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45 7.1.6. Verifying Correct Operation . . . . . . . . . . . . . 45
7.2. Management Considerations . . . . . . . . . . . . . . . . 45 7.2. Management Considerations . . . . . . . . . . . . . . . . 46
7.2.1. Management Information . . . . . . . . . . . . . . . 45 7.2.1. Management Information . . . . . . . . . . . . . . . 46
7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 45 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 46
7.2.3. Configuration Management . . . . . . . . . . . . . . 48 7.2.3. Configuration Management . . . . . . . . . . . . . . 48
7.2.4. Accounting Management . . . . . . . . . . . . . . . . 48 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 49
7.2.5. Performance Management . . . . . . . . . . . . . . . 48 7.2.5. Performance Management . . . . . . . . . . . . . . . 49
7.2.6. Security Management . . . . . . . . . . . . . . . . . 49 7.2.6. Security Management . . . . . . . . . . . . . . . . . 49
8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 50 9. Security Considerations . . . . . . . . . . . . . . . . . . . 51
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.1. Normative References . . . . . . . . . . . . . . . . . . 52 12.1. Normative References . . . . . . . . . . . . . . . . . . 53
12.2. Informative References . . . . . . . . . . . . . . . . . 55 12.2. Informative References . . . . . . . . . . . . . . . . . 56
Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 57 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 57
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 59
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 38, line 26 skipping to change at page 38, line 26
would not detect or realize that the area 1 is actually partitioned. would not detect or realize that the area 1 is actually partitioned.
Also if R2 continues to report Link-State NLRIs corresponding to the Also if R2 continues to report Link-State NLRIs corresponding to the
stale copy of Router LSA of R4 and R6 nodes then R0 would prefer them stale copy of Router LSA of R4 and R6 nodes then R0 would prefer them
over the valid Link-State NLRIs for R4 and R6 that it is receiving over the valid Link-State NLRIs for R4 and R6 that it is receiving
from R3 based on its BGP decision process. This would result in the from R3 based on its BGP decision process. This would result in the
BGP-LS Consumer getting stale and inaccurate topology information. BGP-LS Consumer getting stale and inaccurate topology information.
This problems scenario is avoided if R2 were to not advertise the This problems scenario is avoided if R2 were to not advertise the
link-state information corresponding to R4 and R6 and if R3 were to link-state information corresponding to R4 and R6 and if R3 were to
not advertise similarly for R1 and R5. not advertise similarly for R1 and R5.
A BGP-LS Producer MUST withdraw all link-state objects advertised by A BGP-LS Producer SHOULD withdraw all link-state objects advertised
it in BGP when the node that originated its corresponding LSP/LSAs is by it in BGP when the node that originated its corresponding LSP/LSAs
determined to have become unreachable in the IGP and it MUST re- is determined to have become unreachable in the IGP. An
advertise those link-state objects only after that node becomes implementation MAY continue to advertise link-state objects
reachable again in the IGP domain. corresponding to unreachable nodes in a deployment use-case where the
BGP-LS Consumer is interested in receiving a topology feed
corresponding to a complete IGP LSDB view. In such deployments, it
is expected that the problem described above is mitigated by the BGP-
LS Consumer via appropriate handling of such a topology feed in
addition to the use of either a direct BGP peering with the producer
nodes or mechanisms such as [RFC7911] when using RR. Details of
these mechanisms are outside the scope of this draft.
If the BGP-LS Producer does withdraw link-state objects associated
with an IGP node based on failure of reachability check for that
node, then it MUST re-advertise those link-state objects after that
node becomes reachable again in the IGP domain.
4.8. Router-ID Anchoring Example: ISO Pseudonode 4.8. 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 32. This represents a Router-IDs are encoded. Consider Figure 32. This represents a
Broadcast LAN between a pair of routers. The "real" (non-pseudonode) Broadcast LAN between a pair of routers. The "real" (non-pseudonode)
routers have both an IPv4 Router-ID and IS-IS Node-ID. The 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, Pseudonode1) and (Pseudonode1, LAN. Two unidirectional links (Node1, Pseudonode1) and (Pseudonode1,
Node2) are being generated. Node2) are being generated.
skipping to change at page 44, line 5 skipping to change at page 44, line 36
also expected to check the clarity of purpose and use of the also expected to check the clarity of purpose and use of the
requested code points. Additionally, the DE must verify that any requested code points. Additionally, the DE must verify that any
request for one of these code points has been made available for request for one of these code points has been made available for
review and comment within the IETF: the DE will post the request to review and comment within the IETF: the DE will post the request to
the IDR Working Group mailing list (or a successor mailing list the IDR Working Group mailing list (or a successor mailing list
designated by the IESG). If the request comes from within the IETF, designated by the IESG). If the request comes from within the IETF,
it should be documented in an Internet-Draft. Lastly, the DE must it should be documented in an Internet-Draft. Lastly, the DE must
ensure that any other request for a code point does not conflict with ensure that any other request for a code point does not conflict with
work that is active or already published within the IETF. work that is active or already published within the IETF.
The IANA also requests (per [RFC8126]) that all registries with
"Expert review" allocation policies have a "Change Controller"
assigned. For these four registries, the assigned "Change
Controllers" are the chairs of the IDR working group or a successor
as designated by the IESG.
7. Manageability Considerations 7. Manageability Considerations
This section is structured as recommended in [RFC5706]. This section is structured as recommended in [RFC5706].
7.1. Operational Considerations 7.1. Operational Considerations
7.1.1. Operations 7.1.1. Operations
Existing BGP operational procedures apply. No new operation Existing BGP operational procedures apply. No new operation
procedures are defined in this document. It is noted that the NLRI procedures are defined in this document. It is noted that the NLRI
skipping to change at page 57, line 5 skipping to change at page 57, line 32
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>. February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<https://www.rfc-editor.org/info/rfc7911>.
Appendix A. Changes from RFC 7752 Appendix A. Changes from RFC 7752
This section lists the high-level changes from RFC 7752 and provides This section lists the high-level changes from RFC 7752 and provides
reference to the document sections wherein those have been reference to the document sections wherein those have been
introduced. introduced.
1. Update the Figure 1 in Section 1 and added Section 3 to 1. Update the Figure 1 in Section 1 and added Section 3 to
illustrate the different roles of a BGP implementation in illustrate the different roles of a BGP implementation in
conveying link-state information. conveying link-state information.
 End of changes. 15 change blocks. 
31 lines changed or deleted 42 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/