draft-ietf-idr-rfc7752bis-01.txt   draft-ietf-idr-rfc7752bis-02.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) September 14, 2019 Obsoletes: 7752 (if approved) November 1, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: March 17, 2020 Expires: May 4, 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-01 draft-ietf-idr-rfc7752bis-02
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 March 17, 2020. This Internet-Draft will expire on May 4, 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 2, line 34 skipping to change at page 2, line 34
2. Motivation and Applicability . . . . . . . . . . . . . . . . 5 2. Motivation and Applicability . . . . . . . . . . . . . . . . 5
2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5 2.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . 5
2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7 2.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 7
3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 7 3. BGP Speaker Roles for BGP-LS . . . . . . . . . . . . . . . . 7
4. Carrying Link-State Information in BGP . . . . . . . . . . . 9 4. Carrying Link-State Information in BGP . . . . . . . . . . . 9
4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10 4.2. The Link-State NLRI . . . . . . . . . . . . . . . . . . . 10
4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 14 4.2.1. Node Descriptors . . . . . . . . . . . . . . . . . . 14
4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 18 4.2.2. Link Descriptors . . . . . . . . . . . . . . . . . . 18
4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 21 4.2.3. Prefix Descriptors . . . . . . . . . . . . . . . . . 21
4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 22 4.3. The BGP-LS Attribute . . . . . . . . . . . . . . . . . . 23
4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 23 4.3.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . 23
4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 26 4.3.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . 27
4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 31 4.3.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . 32
4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 34 4.4. Private Use . . . . . . . . . . . . . . . . . . . . . . . 35
4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 35 4.5. BGP Next-Hop Information . . . . . . . . . . . . . . . . 36
4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 35 4.6. Inter-AS Links . . . . . . . . . . . . . . . . . . . . . 36
4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 36 4.7. Handling of Unreachable IGP Nodes . . . . . . . . . . . . 37
4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 37 4.8. Router-ID Anchoring Example: ISO Pseudonode . . . . . . . 38
4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 38 4.9. Router-ID Anchoring Example: OSPF Pseudonode . . . . . . 39
4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 39 4.10. Router-ID Anchoring Example: OSPFv2 to IS-IS Migration . 40
5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 40 5. Link to Path Aggregation . . . . . . . . . . . . . . . . . . 41
5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 40 5.1. Example: No Link Aggregation . . . . . . . . . . . . . . 41
5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 40 5.2. Example: ASBR to ASBR Path Aggregation . . . . . . . . . 41
5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 41 5.3. Example: Multi-AS Path Aggregation . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
6.1. Guidance for Designated Experts . . . . . . . . . . . . . 42 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 . . . . . . . . . . . 43 7.1.2. Installation and Initial Setup . . . . . . . . . . . 44
7.1.3. Migration Path . . . . . . . . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . . . 45
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 . . . . . . . . . . . . . . . . 44 7.2. Management Considerations . . . . . . . . . . . . . . . . 45
7.2.1. Management Information . . . . . . . . . . . . . . . 44 7.2.1. Management Information . . . . . . . . . . . . . . . 45
7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 44 7.2.2. Fault Management . . . . . . . . . . . . . . . . . . 45
7.2.3. Configuration Management . . . . . . . . . . . . . . 47 7.2.3. Configuration Management . . . . . . . . . . . . . . 48
7.2.4. Accounting Management . . . . . . . . . . . . . . . . 47 7.2.4. Accounting Management . . . . . . . . . . . . . . . . 48
7.2.5. Performance Management . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 50
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 50 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
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 . . . . . . . . . . . . . . . . . 55
Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 56 Appendix A. Changes from RFC 7752 . . . . . . . . . . . . . . . 57
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58 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.
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 10, line 17 skipping to change at page 10, line 17
Propagator. This ensures that multiple copies of the same NLRI from Propagator. This ensures that multiple copies of the same NLRI from
multiple BGP-LS Producers and the ambiguity arising there from is multiple BGP-LS Producers and the ambiguity arising there from is
prevented. prevented.
All TLVs within the NLRI that are not specified as mandatory are All TLVs within the NLRI that are not specified as mandatory are
considered optional. All TLVs within the BGP-LS Attribute are considered optional. All TLVs within the BGP-LS Attribute are
considered optional unless specified otherwise. considered optional unless specified otherwise.
The TLVs within the BGP-LS Attribute MAY be ordered in ascending The TLVs within the BGP-LS Attribute MAY be ordered in ascending
order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be order by TLV type. BGP-LS Attribute with unordered TLVs MUST NOT be
consider malformed. considered malformed.
4.2. The Link-State NLRI 4.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. This specification defines three for carrying opaque information. This specification defines three
Link-State NLRI types that describes either a node, a link, and a Link-State NLRI types that describes either a node, a link, and a
prefix. 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
skipping to change at page 20, line 5 skipping to change at page 20, line 5
local/remote identifiers are present, then the Link Local/Remote local/remote identifiers are present, then the Link Local/Remote
Identifiers TLV MUST be included in the Link Descriptor. The Link Identifiers TLV MUST be included in the Link Descriptor. The Link
Local/Remote Identifiers MUST be included in the Link Descriptor Local/Remote Identifiers MUST be included in the Link Descriptor
also in the case of links having only IPv6 link-local addressing also in the case of links having only IPv6 link-local addressing
on them. on them.
The Multi-Topology Identifier TLV MUST be included in Link The Multi-Topology Identifier TLV MUST be included in Link
Descriptor if the underlying IGP link object is associated with a Descriptor if the underlying IGP link object is associated with a
non-default topology. non-default topology.
The TLVs/sub-TLVs corresponding to the interface addresses and/or the
local/remote identfiers may not always be signaled in the IGPs unless
their advertisement is enabled specifically. In such cases, a BGP-LS
Producer may not be able to generate valid Link NLRIs for such link
advertisements from the IGPs.
4.2.2.1. Multi-Topology ID 4.2.2.1. Multi-Topology ID
The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF The Multi-Topology ID (MT-ID) TLV carries one or more IS-IS or OSPF
Multi-Topology IDs for a link, node, or prefix. Multi-Topology IDs for a link, node, or prefix.
Semantics of the IS-IS MT-ID are defined in Section 7.1 and 7.2 of Semantics of the IS-IS MT-ID are defined in Section 7.1 and 7.2 of
RFC 5120 [RFC5120]. Semantics of the OSPF MT-ID are defined in RFC 5120 [RFC5120]. Semantics of the OSPF MT-ID are defined in
Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV is Section 3.7 of RFC 4915 [RFC4915]. If the value in the MT-ID TLV is
derived from OSPF, then the upper 5 bits of the MT-ID field MUST be derived from OSPF, then the upper 5 bits of the MT-ID field MUST be
set to 0. set to 0.
skipping to change at page 23, line 13 skipping to change at page 23, line 22
ignored for all other address families. ignored for all other address families.
The Node Attribute TLVs, Link Attribute TLVs and Prefix Attribute The Node Attribute TLVs, Link Attribute TLVs and Prefix Attribute
TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute TLVs are sets of TLVs that may be encoded in the BGP-LS Attribute
associated with a Node NLRI, Link NLRI and Prefix NLRI respectively. associated with a Node NLRI, Link NLRI and Prefix NLRI respectively.
The BGP-LS Attribute may potentially grow large in size depending on The BGP-LS Attribute may potentially grow large in size depending on
the amount of link-state information associated with a single Link- the amount of link-state information associated with a single Link-
State NLRI. The BGP specification [RFC4271] mandates a maximum BGP State NLRI. The BGP specification [RFC4271] mandates a maximum BGP
message size of 4096 octets. It is RECOMMENDED that an message size of 4096 octets. It is RECOMMENDED that an
implementation support [I-D.ietf-idr-bgp-extended-messages] in order implementation support [RFC8654] in order to accommodate larger size
to accommodate larger size of information within the BGP-LS of information within the BGP-LS Attribute. BGP-LS Producers MUST
Attribute. BGP-LS Producers MUST ensure that they limit the TLVs ensure that they limit the TLVs included in the BGP-LS Attribute to
included in the BGP-LS Attribute to ensure that a BGP update message ensure that a BGP update message for a single Link-State NLRI does
for a single Link-State NLRI does not cross the maximum limit for a not cross the maximum limit for a BGP message. The determination of
BGP message. The determination of the types of TLVs to be included the types of TLVs to be included MAY be made by the BGP-LS Producer
MAY be made by the BGP-LS Producer based on the BGP-LS Consumer based on the BGP-LS Consumer applications requirement and is outside
applications requirement and is outside the scope of this document. the scope of this document. When a BGP-LS Propagator finds that it
When a BGP-LS Propagator finds that it is exceeding the maximum BGP is exceeding the maximum BGP message size due to addition or update
message size due to addition or update of some other BGP Attribute of some other BGP Attribute (e.g. AS_PATH), it MUST consider the
(e.g. AS_PATH), it MUST consider the BGP-LS Attribute to be BGP-LS Attribute to be malformed and handle the propagation as
malformed and handle the propagation as described in Section 7.2.2. described in Section 7.2.2.
4.3.1. Node Attribute TLVs 4.3.1. Node Attribute TLVs
The following Node Attribute TLVs are defined for the BGP-LS The following Node Attribute TLVs are defined for the BGP-LS
Attribute associated with a Node NLRI: Attribute associated with a Node NLRI:
+-------------+----------------------+----------+-------------------+ +-------------+----------------------+----------+-------------------+
| TLV Code | Description | Length | Reference | | TLV Code | Description | Length | Reference |
| Point | | | (RFC/Section) | | Point | | | (RFC/Section) |
+-------------+----------------------+----------+-------------------+ +-------------+----------------------+----------+-------------------+
skipping to change at page 51, line 38 skipping to change at page 52, line 38
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]
Bush, R., Patel, K., and D. Ward, "Extended Message
support for BGP", draft-ietf-idr-bgp-extended-messages-36
(work in progress), August 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
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 54, line 29 skipping to change at page 55, line 24
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
2017, <https://www.rfc-editor.org/info/rfc8202>. 2017, <https://www.rfc-editor.org/info/rfc8202>.
[RFC8654] Bush, R., Patel, K., and D. Ward, "Extended Message
Support for BGP", RFC 8654, DOI 10.17487/RFC8654, October
2019, <https://www.rfc-editor.org/info/rfc8654>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-idr-bgpls-inter-as-topology-ext] [I-D.ietf-idr-bgpls-inter-as-topology-ext]
Wang, A., Chen, H., Talaulikar, K., and S. Ma, "BGP-LS Wang, A., Chen, H., Talaulikar, K., Zhuang, S., and S. Ma,
Extension for Inter-AS Topology Retrieval", draft-ietf- "BGP-LS Extension for Inter-AS Topology Retrieval", draft-
idr-bgpls-inter-as-topology-ext-05 (work in progress), ietf-idr-bgpls-inter-as-topology-ext-07 (work in
September 2019. progress), September 2019.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006, RFC 4272, DOI 10.17487/RFC4272, January 2006,
<https://www.rfc-editor.org/info/rfc4272>. <https://www.rfc-editor.org/info/rfc4272>.
 End of changes. 13 change blocks. 
66 lines changed or deleted 71 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/