draft-ietf-idr-bgpls-inter-as-topology-ext-04.txt   draft-ietf-idr-bgpls-inter-as-topology-ext-05.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: February 27, 2020 Futurewei Expires: March 12, 2020 Futurewei
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
S. Ma S. Ma
Mellanox Technologies Mellanox Technologies
August 26, 2019 September 9, 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-04 draft-ietf-idr-bgpls-inter-as-topology-ext-05
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 46
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 February 27, 2020. This Internet-Draft will expire on March 12, 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 13 skipping to change at page 3, line 13
domain, and these domains interconnect with each other, there is no domain, and these domains interconnect with each other, there is no
mechanic within current BGP- LS to transfer the interconnect topology mechanic within current BGP- LS to transfer the interconnect topology
information. information.
Draft [I-D.ietf-idr-bgpls-segment-routing-epe] defines some Draft [I-D.ietf-idr-bgpls-segment-routing-epe] defines some
extensions for exporting BGP peering node topology information extensions for exporting BGP peering node topology information
(including its peers, interfaces and peering ASs) in a way that is (including its peers, interfaces and peering ASs) in a way that is
exploitable in order to compute efficient BGP Peering Engineering exploitable in order to compute efficient BGP Peering Engineering
policies and strategies. Such information can also be used to policies and strategies. Such information can also be used to
calculate the interconnection topology among different IGP domains, calculate the interconnection topology among different IGP domains,
but it requires the border routers to run BGP-LS protocol and report but it requires every border router to run BGP-LS protocol and report
the information to the SDN controller, which restricts the solution the information to SDN controller. Considering there will be several
border routers on the network boundary, such solution restricts its
deployment flexibility. deployment flexibility.
This draft analysis the situations that the SDN controller needs to This draft analysis the situations that the SDN controller needs to
get the interconnected topology information between different AS get the interconnected topology information between different AS
domains, defines the new Stub Link NLRI and some new TLVs within the domains, defines the new Stub Link NLRI and some new TLVs within the
BGP-LS protocol to transfer the key information related to them. BGP-LS protocol to transfer the key information related to them.
After that, the SDN controller can then deduce the multi-domain After that, the SDN controller can then deduce the multi-domain
topology automatically based on the information from BGP-LS protocol. topology automatically based on the information from BGP-LS protocol.
2. Conventions used in this document 2. Conventions used in this document
skipping to change at page 5, line 22 skipping to change at page 5, line 22
This newly defined NLRI can be used to describe the link that has This newly defined NLRI can be used to describe the link that has
only one end located within the IGP domain, as described in the only one end located within the IGP domain, as described in the
following sections. following sections.
5.1. Inter-AS Native IP Scenario 5.1. Inter-AS Native IP Scenario
Draft [I-D.ietf-teas-native-ip-scenarios] describes the situation Draft [I-D.ietf-teas-native-ip-scenarios] describes the situation
that operator needs some traffic engineering solution for the inter- that operator needs some traffic engineering solution for the inter-
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 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.
The "Local Node Descriptors" should describe the the characteristics The "Local Node Descriptors" should describe the characteristics of
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
protocol,[RFC5316] and [RFC5392] define IS-IS and OSPF extensions protocol,[RFC5316] and [RFC5392] define IS-IS and OSPF extensions
respectively to deal with the situation for inter-AS traffic respectively to deal with the situation for inter-AS traffic
skipping to change at page 6, line 34 skipping to change at page 6, line 34
| TBD |Remote AS Number | 24/21 | [RFC5316]/3.3.1| | TBD |Remote AS Number | 24/21 | [RFC5316]/3.3.1|
| | | | [RFC5392]/3.3.1| | | | | [RFC5392]/3.3.1|
| TBD |IPv4 Remote ASBR ID | 25/22 | [RFC5316]/3.3.2| | TBD |IPv4 Remote ASBR ID | 25/22 | [RFC5316]/3.3.2|
| | | | [RFC5392]/3.3.2| | | | | [RFC5392]/3.3.2|
| TBD |IPv6 Remote ASBR ID | 26/24 | [RFC5316]/3.3.3| | TBD |IPv6 Remote ASBR ID | 26/24 | [RFC5316]/3.3.3|
| | | | [RFC5392]/3.3.3| | | | | [RFC5392]/3.3.3|
+-----------+---------------------+--------------+----------------+ +-----------+---------------------+--------------+----------------+
Figure 3: Link Descriptor TLVs Figure 3: Link Descriptor TLVs
Detail encoding of these TLVs are synchronized with the corresponding Detail encoding of these TLVs are synchronized with the corresponding
parts in [RFC5316] and [RFC5392], which keeps the BGP-LS protocol is parts in [RFC5316] and [RFC5392], which keeps the BGP-LS protocol
agnostic to the underly protocol. agnostic to the underly protocol.
6.1. Remote AS Number TLV 6.1. Remote AS Number TLV
A new TLV, the remote AS number TLV, is defined for inclusion in the A new TLV, the remote AS number TLV, is defined for inclusion in the
link descriptor when advertising inter-AS TE links. The remote AS link descriptor when advertising inter-AS TE links. The remote AS
number TLV specifies the AS number of the neighboring AS to which the number TLV specifies the AS number of the neighboring AS to which the
advertised link connects. advertised link connects.
The remote AS number TLV is TLV type TBD (seeSection 9 ) and is 4 The remote AS number TLV is TLV type TBD (seeSection 9 ) and is 4
skipping to change at page 11, line 8 skipping to change at page 11, line 8
[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-06 (work in Network", draft-ietf-teas-native-ip-scenarios-08 (work in
progress), June 2019. progress), August 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
 End of changes. 9 change blocks. 
12 lines changed or deleted 13 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/