draft-ietf-idr-bgpls-inter-as-topology-ext-05.txt   draft-ietf-idr-bgpls-inter-as-topology-ext-06.txt 
IDR Working Group A. Wang IDR Working Group A. Wang
Internet-Draft China Telecom Internet-Draft China Telecom
Intended status: Standards Track H. Chen Intended status: Standards Track H. Chen
Expires: March 12, 2020 Futurewei Expires: April 2, 2020 Futurewei
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
S. Zhang
Huawei Technologies
S. Ma S. Ma
Mellanox Technologies Mellanox Technologies
September 9, 2019 September 30, 2019
BGP-LS Extension for Inter-AS Topology Retrieval BGP-LS Extension for Inter-AS Topology Retrieval
draft-ietf-idr-bgpls-inter-as-topology-ext-05 draft-ietf-idr-bgpls-inter-as-topology-ext-06
Abstract Abstract
This document describes the process to build Border Gateway Protocol- This document describes the process to build Border Gateway Protocol-
Link State (BGP-LS) key parameters in inter-domain scenario, defines Link State (BGP-LS) key parameters in inter-domain scenario, defines
one new BGP-LS Network Layer Reachability Information (NLRI) type one new BGP-LS Network Layer Reachability Information (NLRI) type
(Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic
Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let
Software Definition Network (SDN) controller retrieve the network Software Definition Network (SDN) controller retrieve the network
topology automatically under various inter-AS environments. topology automatically under various inter-AS environments.
skipping to change at page 1, line 46 skipping to change at page 1, line 48
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 12, 2020. This Internet-Draft will expire on April 2, 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Inter-AS Domain Scenarios. . . . . . . . . . . . . . . . . . 3 4. Inter-AS Domain Scenarios. . . . . . . . . . . . . . . . . . 3
5. Stub Link NLRI . . . . . . . . . . . . . . . . . . . . . . . 4 5. Stub Link NLRI . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Inter-AS Native IP Scenario . . . . . . . . . . . . . . . 5 5.1. Inter-AS Native IP Scenario . . . . . . . . . . . . . . . 5
5.2. Inter-AS TE Scenario . . . . . . . . . . . . . . . . . . 5 5.2. Inter-AS TE Scenario . . . . . . . . . . . . . . . . . . 6
6. Inter-AS TE NLRI related TLVs . . . . . . . . . . . . . . . . 6 6. Inter-AS TE NLRI related TLVs . . . . . . . . . . . . . . . . 6
6.1. Remote AS Number TLV . . . . . . . . . . . . . . . . . . 6 6.1. Remote AS Number TLV . . . . . . . . . . . . . . . . . . 7
6.2. IPv4 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7 6.2. IPv4 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7
6.3. IPv6 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 7 6.3. IPv6 Remote ASBR ID . . . . . . . . . . . . . . . . . . . 8
7. Topology Reconstruction. . . . . . . . . . . . . . . . . . . 8 7. Topology Reconstruction. . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. New BGP-LS NLRI type . . . . . . . . . . . . . . . . . . 9 9.1. New BGP-LS NLRI type . . . . . . . . . . . . . . . . . . 9
9.2. New Link Descriptors . . . . . . . . . . . . . . . . . . 9 9.2. New Link Descriptors . . . . . . . . . . . . . . . . . . 10
10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
BGP-LS [RFC7752] describes the methodology that using BGP protocol to BGP-LS [RFC7752] describes the methodology that using BGP protocol to
transfer the Link-State information. Such method can enable SDN transfer the Link-State information. Such method can enable SDN
controller to collect the underlay network topology automatically, controller to collect the underlay network topology automatically,
but normally it can only get the information within one Interior but normally it can only get the information within one Interior
Gateway Protocol (IGP) domain. If the operator has more than one IGP Gateway Protocol (IGP) domain. If the operator has more than one IGP
domain, and these domains interconnect with each other, there is no domain, and these domains interconnect with each other, there is no
skipping to change at page 5, line 30 skipping to change at page 5, line 30
as native IP environment. In such situation, different domain may as native IP environment. In such situation, different domain may
run different IGP protocol. The operator needs to know the inter-as run different IGP protocol. The operator needs to know the inter-as
topology first to calculate the end to end optimal path centrally. topology first to calculate the end to end optimal path centrally.
When IGP A or IGP B in Figure 1 runs native IS-IS/OSPF protocol, the When IGP A or IGP B in Figure 1 runs native IS-IS/OSPF protocol, the
operator can use passive feature for the inter-domain links to let operator can use passive feature for the inter-domain links to let
the routers within the IGP domain know these links. Such stub links the routers within the IGP domain know these links. Such stub links
information can then be carried within the Stub Link NLRI reported information can then be carried within the Stub Link NLRI reported
via the BGP-LS protocol to the SDN controller. via the BGP-LS protocol to the SDN controller.
For OSPF, when the interface is configured as passive, the "Linktype"
field in corresponding Router LSA will be set to 3, to indicate it
connects with stub network. Other routers in the IGP domain can
identify such interfaces via this characteristics, and report them
via the newly defined "Stub Link NLRI".
For ISIS, currently there is no such mechanism to distinguish the
passive interfaces from other normal interfaces. One viable way is
to judge the adjacency of interfaces. If the number of adjacency of
the interface is zero, then such interfaces can be reported via the
newly defined "Stub Link NLRI".
The "Local Node Descriptors" should describe the characteristics of The "Local Node Descriptors" should describe the characteristics of
ASBRs that are connected these stub links. ASBRs that are connected these stub links.
When such information is reported via the BGP-LS protocol, the SDN When such information is reported via the BGP-LS protocol, the SDN
controller can construct the underlay inter-domain topology according controller can construct the underlay inter-domain topology according
to procedure described in Section 7 to procedure described in Section 7
5.2. Inter-AS TE Scenario 5.2. Inter-AS TE Scenario
When IGP A or IGP B in Figure 1 runs IS-IS TE/OSPF-TE When IGP A or IGP B in Figure 1 runs IS-IS TE/OSPF-TE
skipping to change at page 8, line 36 skipping to change at page 8, line 48
Figure 6: IPv6 Remote ASBR ID TLV Format Figure 6: IPv6 Remote ASBR ID TLV Format
The IPv6 remote ASBR ID TLV MUST be included if the neighboring ASBR The IPv6 remote ASBR ID TLV MUST be included if the neighboring ASBR
has an IPv6 address. If the neighboring ASBR does not have an IPv6 has an IPv6 address. If the neighboring ASBR does not have an IPv6
address, the IPv4 remote ASBR ID TLV MUST be included instead. An address, the IPv4 remote ASBR ID TLV MUST be included instead. An
IPv4 remote ASBR ID TLV and IPv6 remote ASBR ID TLV MAY both be IPv4 remote ASBR ID TLV and IPv6 remote ASBR ID TLV MAY both be
present in an inter-AS TE link NLRI. present in an inter-AS TE link NLRI.
7. Topology Reconstruction. 7. Topology Reconstruction.
When SDN Controller gets such information from BGP-LS protocol, it When SDN controller gets such information from BGP-LS protocol, it
should compares the proximity of these stub links. If they are under should compares the proximity of these stub links. If they are under
the same network scope, then it should find the corresponding the same network scope and in different AS, then it should find the
associated router information, build the link between these two corresponding associated router information, build the link between
border routers. these two border routers.
If the prefixes reported via the "Stub Link" NLRI are under the same
network scope, and in the same AS, the SDN controller can then
determine there is some IGP adjacency irregular. The usage of such
information is out of scope of this draft.
After iterating the above procedures for all of the stub links, the After iterating the above procedures for all of the stub links, the
SDN controller can then retrieve the connection topology between SDN controller can then retrieve the connection topology between
different domains automatically. different domains automatically.
8. Security Considerations 8. Security Considerations
It is common for one operator to occupy several IGP domains that are It is common for one operator to occupy several IGP domains that are
composited by its backbone network and several MAN(Metrio-Area- composited by its backbone network and several MAN(Metrio-Area-
Network)s/Internet Data Centers (IDCs). When they do traffic Network)s/Internet Data Centers (IDCs). When they do traffic
skipping to change at page 11, line 8 skipping to change at page 11, line 22
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray, Previdi, S., Talaulikar, K., Filsfils, C., Patel, K., Ray,
S., and J. Dong, "BGP-LS extensions for Segment Routing S., and J. Dong, "BGP-LS extensions for Segment Routing
BGP Egress Peer Engineering", draft-ietf-idr-bgpls- BGP Egress Peer Engineering", draft-ietf-idr-bgpls-
segment-routing-epe-19 (work in progress), May 2019. segment-routing-epe-19 (work in progress), May 2019.
[I-D.ietf-teas-native-ip-scenarios] [I-D.ietf-teas-native-ip-scenarios]
Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in Native IP "Scenarios and Simulation Results of PCE in Native IP
Network", draft-ietf-teas-native-ip-scenarios-08 (work in Network", draft-ietf-teas-native-ip-scenarios-09 (work in
progress), August 2019. progress), September 2019.
Authors' Addresses Authors' Addresses
Aijun Wang Aijun Wang
China Telecom China Telecom
Beiqijia Town, Changping District Beiqijia Town, Changping District
Beijing, Beijing 102209 Beijing, Beijing 102209
China China
Email: wangaj3@chinatelecom.cn Email: wangaj3@chinatelecom.cn
skipping to change at page 11, line 32 skipping to change at page 12, line 4
Futurewei Futurewei
Boston, MA Boston, MA
USA USA
Email: hchen@futurewei.com Email: hchen@futurewei.com
Ketan Talaulikar Ketan Talaulikar
Cisco Systems Cisco Systems
Email: ketant@cisco.com Email: ketant@cisco.com
Shunwan Zhuang
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Beijing 100095
China
Email: zhuangshunwan@huawei.com
Shaowen Ma Shaowen Ma
Mellanox Technologies Mellanox Technologies
Email: mashaowen@gmail.com Email: mashaowen@gmail.com
 End of changes. 16 change blocks. 
16 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/