draft-ietf-idr-bgpls-inter-as-topology-ext-07.txt   draft-ietf-idr-bgpls-inter-as-topology-ext-08.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: April 2, 2020 Futurewei Expires: October 4, 2020 Futurewei
K. Talaulikar K. Talaulikar
Cisco Systems Cisco Systems
S. Zhuang S. Zhuang
Huawei Technologies Huawei Technologies
S. Ma April 2, 2020
Mellanox Technologies
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-07 draft-ietf-idr-bgpls-inter-as-topology-ext-08
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 48 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 April 2, 2020. This Internet-Draft will expire on October 4, 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 5, line 18 skipping to change at page 5, line 18
The semantics of "Local Node Descriptors" and "Stub Link Descriptors" The semantics of "Local Node Descriptors" and "Stub Link Descriptors"
are same as that defined in [RFC7752] for "Node Descriptors" and are same as that defined in [RFC7752] for "Node Descriptors" and
"Link Descriptor". "Link Descriptor".
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 [RFC8735] describes the situation that operator needs some
that operator needs some traffic engineering solution for the inter- traffic engineering solution for the inter-as native IP environment.
as native IP environment. In such situation, different domain may In such situation, different domain may run different IGP protocol.
run different IGP protocol. The operator needs to know the inter-as The operator needs to know the inter-as topology first to calculate
topology first to calculate the end to end optimal path centrally. 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" For OSPF, when the interface is configured as passive, the "Linktype"
field in corresponding Router LSA will be set to 3, to indicate it field in corresponding Router LSA will be set to 3, to indicate it
connects with stub network. Other routers in the IGP domain can connects with stub network. Other routers in the IGP domain can
identify such interfaces via this characteristics, and report them identify such interfaces via this characteristics, and report them
via the newly defined "Stub Link NLRI". via the newly defined "Stub Link NLRI".
For ISIS, currently there is no such mechanism to distinguish the For ISIS, [I-D.wang-lsr-passive-interface-attribute] describe the
passive interfaces from other normal interfaces. One viable way is method to label the passive interfaces within the network. The
to judge the adjacency of interfaces. If the number of adjacency of router that runs BGP-LS can extract these passive interfaces from
the interface is zero, then such interfaces can be reported via the other interfaces that participate in the IGP protocol and report them
newly defined "Stub Link NLRI". via the newly defined "Stub Link NLRI". Or else such router can only
extract such information from 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 protocol,
protocol,[RFC5316] and [RFC5392] define IS-IS and OSPF extensions [RFC5316] and [RFC5392] define IS-IS and OSPF extensions respectively
respectively to deal with the situation for inter-AS traffic to deal with the situation for inter-AS traffic engineering. Three
engineering. Three new sub-TLVs(Remote AS Number、IPv4 Remote new sub-TLVs(Remote AS Number、IPv4 Remote ASBR ID、IPv6
ASBR ID、IPv6 Remote ASBR ID) which are associated with the Remote ASBR ID) which are associated with the inter-AS TE link are
inter-AS TE link are defined. defined.
These TLVs are flooded within the IGP domain automatically. They These TLVs are flooded within the IGP domain automatically. They
should be carried within the newly defined Stub Link NLRI within the should be carried within the newly defined Stub Link NLRI within the
BGP-LS protocol, as the descriptors for the inter-AS stub link. BGP-LS protocol, as the descriptors for the inter-AS stub link.
The "Local Node Descriptors" should describe the the characteristics The "Local Node Descriptors" should describe the the characteristics
of ASBRs that are connected these inter-AS TE links. of ASBRs that are connected these inter-AS TE links.
If the SDN controller knows these information via one of the interior If the SDN controller knows these information via one of the interior
router that runs BGP-LS protocol, the SDN controller can rebuild the router that runs BGP-LS protocol, the SDN controller can rebuild the
skipping to change at page 7, line 12 skipping to change at page 7, line 12
parts in [RFC5316] and [RFC5392], which keeps the BGP-LS protocol 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 (see Section 9 ) and is 4
octets in length. The format is as follows: octets in length. The format is as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote AS Number | | Remote AS Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Remote AS Number TLV Format Figure 4: Remote AS Number TLV Format
skipping to change at page 7, line 37 skipping to change at page 7, line 37
when a router advertises an inter-AS TE link. when a router advertises an inter-AS TE link.
6.2. IPv4 Remote ASBR ID 6.2. IPv4 Remote ASBR ID
A new TLV, which is referred to as the IPv4 remote ASBR ID TLV, is A new TLV, which is referred to as the IPv4 remote ASBR ID TLV, is
defined for inclusion in the link descriptor when advertising inter- defined for inclusion in the link descriptor when advertising inter-
AS TE links. The IPv4 remote ASBR ID TLV specifies the IPv4 AS TE links. The IPv4 remote ASBR ID TLV specifies the IPv4
identifier of the remote ASBR to which the advertised inter-AS link identifier of the remote ASBR to which the advertised inter-AS link
connects. This could be any stable and routable IPv4 address of the connects. This could be any stable and routable IPv4 address of the
remote ASBR. Use of the TE Router ID as specified in the Traffic remote ASBR. Use of the TE Router ID as specified in the Traffic
Engineering router ID TLV [RFC5305] is RECOMMENDED. Engineering router ID TLV [RFC5316] is RECOMMENDED.
The IPv4 remote ASBR ID TLV is TLV type TBD (see Section 9) and is 4 The IPv4 remote ASBR ID TLV is TLV type TBD (see Section 9) and is 4
octets in length. The format of the IPv4 remote ASBR ID sub-TLV is octets in length. The format of the IPv4 remote ASBR ID sub-TLV is
as follows: as follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 19 skipping to change at page 8, line 19
ASBR ID TLV MAY both be present in an inter-AS TE link NLRI. ASBR ID TLV MAY both be present in an inter-AS TE link NLRI.
6.3. IPv6 Remote ASBR ID 6.3. IPv6 Remote ASBR ID
A new TLV, which is referred to as the IPv6 remote ASBR ID TLV, is A new TLV, which is referred to as the IPv6 remote ASBR ID TLV, is
defined for inclusion in the link descriptor when advertising inter- defined for inclusion in the link descriptor when advertising inter-
AS links. The IPv6 remote ASBR ID TLV specifies the IPv6 identifier AS links. The IPv6 remote ASBR ID TLV specifies the IPv6 identifier
of the remote ASBR to which the advertised inter-AS link connects. of the remote ASBR to which the advertised inter-AS link connects.
This could be any stable and routable IPv6 address of the remote This could be any stable and routable IPv6 address of the remote
ASBR. Use of the TE Router ID as specified in the IPv6 Traffic ASBR. Use of the TE Router ID as specified in the IPv6 Traffic
Engineering router ID TLV [RFC6119] is RECOMMENDED. Engineering router ID TLV [RFC5316] is RECOMMENDED.
The IPv6 remote ASBR ID TLV is TLV type TBD (see Section 9) and is 16 The IPv6 remote ASBR ID TLV is TLV type TBD (see Section 9) and is 16
octets in length. The format of the IPv6 remote ASBR ID TLV is as octets in length. The format of the IPv6 remote ASBR ID TLV is as
follows: follows:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 10, line 23 skipping to change at page 10, line 23
| TBD | Remote AS Number | Allocation from IANA | | TBD | Remote AS Number | Allocation from IANA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |IPv4 Remote ASBR ID| Allocation from IANA | | TBD |IPv4 Remote ASBR ID| Allocation from IANA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD |IPv6 Remote ASBR ID| Allocation from IANA | | TBD |IPv6 Remote ASBR ID| Allocation from IANA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: BGP-LS Link Descriptors TLV Figure 8: BGP-LS Link Descriptors TLV
10. Acknowledgement 10. Acknowledgement
The author would like to thank Acee Lindem, Jie Dong, Jeff Tantsura The author would like to thank Acee Lindem, Jie Dong, Shaowen Ma,
and Dhruv Dhody for their valuable comments and suggestions. Jeff Tantsura and Dhruv Dhody for their valuable comments and
suggestions.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 10, line 49 skipping to change at page 11, line 5
[RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316,
December 2008, <https://www.rfc-editor.org/info/rfc5316>. December 2008, <https://www.rfc-editor.org/info/rfc5316>.
[RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in
Support of Inter-Autonomous System (AS) MPLS and GMPLS Support of Inter-Autonomous System (AS) MPLS and GMPLS
Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392,
January 2009, <https://www.rfc-editor.org/info/rfc5392>. January 2009, <https://www.rfc-editor.org/info/rfc5392>.
[RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic
Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119,
February 2011, <https://www.rfc-editor.org/info/rfc6119>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8735] Wang, A., Huang, X., Kou, C., Li, Z., and P. Mi,
"Scenarios and Simulation Results of PCE in a Native IP
Network", RFC 8735, DOI 10.17487/RFC8735, February 2020,
<https://www.rfc-editor.org/info/rfc8735>.
11.2. Informative References 11.2. Informative References
[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.wang-lsr-passive-interface-attribute]
Wang, A., Huang, X., Qou, C., Li, Z., and P. Mi, Wang, A. and Z. Hu, "Passive Interface Attribute", draft-
"Scenarios and Simulation Results of PCE in Native IP wang-lsr-passive-interface-attribute-00 (work in
Network", draft-ietf-teas-native-ip-scenarios-09 (work in progress), January 2020.
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 12, line 11 skipping to change at line 519
Cisco Systems Cisco Systems
Email: ketant@cisco.com Email: ketant@cisco.com
Shunwan Zhuang Shunwan Zhuang
Huawei Technologies Huawei Technologies
Huawei Building, No.156 Beiqing Rd. Huawei Building, No.156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: zhuangshunwan@huawei.com Email: zhuangshunwan@huawei.com
Shaowen Ma
Mellanox Technologies
Email: mashaowen@gmail.com
 End of changes. 16 change blocks. 
37 lines changed or deleted 39 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/