<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.37 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sheng-lsvr-bgp-spf-for-sdwan-00" category="bcp" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->
  <front>
    <title abbrev="BGP-LS-SPF for Multi-segment SD-WAN">Usage of BGP-LS-SPF in Multi-segment SD-WAN</title>
    <seriesInfo name="Internet-Draft" value="draft-sheng-lsvr-bgp-spf-for-sdwan-00"/>
    <author initials="C." surname="Sheng" fullname="Cheng Sheng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Beiqing Road</street>
          <city>Beijing</city>
        </postal>
        <email>shengcheng@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Shi" fullname="Hang Shi" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <date year="2023" month="July" day="10"/>
    <area>routing</area>
    <workgroup>LSVR</workgroup>
    <keyword>SDWAN</keyword>
    <abstract>
      <?line 39?>

<t>This document introduces the usage of BGP-LS-SPF protocol in multi-segment SD-WAN scenarios. It allows SD-WAN tunnels to be published as logical links, which can cross the internet, MPLS networks, and various operator network. The BGP-LS-SPF protocol can construct an overlay network topology for logical links and physical links across these heterogeneous networks, and calculate the reachability routes of overlay network nodes based on this topology.</t>
    </abstract>
  </front>
  <middle>
    <?line 43?>

<section anchor="intro">
      <name>Introduction</name>
      <t>As pointed out in <xref target="I-D.draft-ietf-rtgwg-net2cloud-problem-statement"/>, enterprises are migrating their workloads to cloud service. The enterprise branch interconnection and enterprise site to cloud DC connection may cross heterogeneous network such as operator networks, enterprise-owned backbone networks or direct connection lines.</t>
      <t>For large enterprises to access the cloud service and interconnect their branches, a PoP GWs network can be built to provide multi-cloud, multi-tenant, and multi-branch interconnection. Depending on the geographical distribution of the enterprise branches, the PoP GWs network may be a cross-regional or even a global network. The PoP GW can be connected to the operator network or the enterprise-owned backbone network. The PoP GWs devices can also be directly connected through dedicated lines.</t>
      <t>According to <xref target="I-D.draft-ietf-bess-bgp-sdwan-usage"/>, SD-WAN tunnels can be established between two GWs devices connected to the operator network, MPLS VPN network, or internet network through the WAN ports of the two PoP GWs devices. All GWs are under the control of one BGP instance. <xref target="I-D.draft-ietf-idr-sdwan-edge-discovery"/> defines the mechanism for SD-WAN edges to discover each other's properties via BGP update through RR. This allows the interconnection between enterprise branches and multi-cloud to pass through multiple SD-WAN tunnels or direct connection lines, as shown in <xref target="pop-gw"/>.</t>
      <t>This draft provides a way to use the BGP-LS-SPF protocol to collect the identification of PoP GW device node and the topology of SD-WAN tunnel and direct connection lines. In this way, each PoP GW device can learn the PoP GWs network topology, and calculate the route to any other PoP GW.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This specification reuses terms defined in <xref section="5.2" sectionFormat="of" target="I-D.draft-ietf-lsvr-bgp-spf"/> including BGP-LS-SPF Node NLRI, BGP-LS-SPF Link NLRI, Dijkstra Algorithm.</t>
      <ul spacing="normal">
        <li>PoP GW: Point of Presence Gateway</li>
        <li>SD-WAN: Software Defined Wide Area Network. In this document, "SD-WAN" refers to policy-driven transporting IP packets over multiple different underlay networks to get better WAN bandwidth management, visibility and control.</li>
        <li>RR: Route Reflector</li>
        <li>Cloud DC: Off-Premise Data Centers that usually host applications and workload owned by different organizations or tenants.</li>
      </ul>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="usage-of-bgp-ls-spf-in-multi-segment-sd-wan">
      <name>Usage of BGP-LS-SPF in Multi-segment SD-WAN</name>
      <figure anchor="pop-gw">
        <name>PoP GWs network</name>
        <artwork><![CDATA[
      + - - - +- - - - - - - - - - - -|RR| - - - - - - - - - -+ - - - - +
      |       |                        |                      |         |
      |    +--|--+                  +--|--+                +--|--+      |
      |    | GW1 |------------------| GW2 | -Physical link-| GW3 |      |
      |    +--|--+10.1.1.1  20.1.1.1+-----+                +--|--+      |
      |       |     SD-WAN Tunnel  /                 Physical |30.1.1.1 |
      |       |    ----------------                      Link |         |
      |       |   / over Internet                             |40.1.1.1 |
      |    +--|--+                                         +--|--+      |
      |+--+| GW5 |---------SD-WAN Tunnel over MPLS---------| GW4 |+-----+
           +--|--+                                         +--|--+
              |                                               |
+ - -+      + - -+                                         + - -+     +- - - +
|User|------|CPE1|                                         |CPE2|-----| APPs |
+ - -+      + - -+                                         + - -+     + - - -+
]]></artwork>
      </figure>
      <t>As shown in <xref target="pop-gw"/>, GW1, GW2, GW5 are connected to the same internet/ISP network. The GW2 and GW3 are connected through direct dedicated links. GW5 and GW4 are connected by MPLS VPN. BGP-SD-WAN neighbors are established between GWs through RR. BGP-LS-SPF neighbors are established between each GW and RR. SD-WAN tunnel links are established between GWs through BGP-SD-WAN neighbors reflecting SD-WAN routes(see <xref target="I-D.draft-ietf-idr-sdwan-edge-discovery"/>), as shown in the SD-WAN Tunnel between GW1 and GW2 with WAN port IP addresses of 10.1.1.1 and 20.1.1.1, respectively. GW nodes reflect the SD-WAN tunnel topology information to all GWs, including dedicated line-connected GWs, through BGP-LS-SPF neighbors with RR.</t>
      <t>GW2-GW3-GW4 are connected through dedicated lines. BGP-LS-SPF neighbors are established between GWs through dedicated lines, and also between GWs and RR. The BGP-LS-SPF neighbors between dedicated lines are used to discover the topology information of the dedicated lines, such as the direct link with port IP addresses of 30.1.1.1 and 40.1.1.1 between GW3 and GW4 shown in the figure. The dedicated line topology information is reflected to all GWs, including SD-WAN tunnel-connected GWs, through BGP-LS-SPF neighbors with RR.</t>
      <t>The BGP-LS-SPF LINK NLRI is used to carry the two endpoint IP address of the SD-WAN tunnel or dedicated lines. The BGP-LS-SPF NODE NLRI is used to carry PoP GW device node identification. They are advertised to other GWs through the RR. In this way, all GW learns the topology of whole PoP GWs network and can calculate the next hop to any other GW using Dijkstra Algorithm.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not introduce any new security considerations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="I-D.draft-ietf-bess-bgp-sdwan-usage">
          <front>
            <title>SD-WAN edge nodes are commonly interconnected by multiple types of underlay networks owned and managed by different network providers.</title>
            <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
              <organization>Cisco</organization>
            </author>
            <author fullname="John Drake" initials="J." surname="Drake">
              <organization>Juniper</organization>
            </author>
            <author fullname="Basil Najem" initials="B." surname="Najem">
              <organization>Bell Canada</organization>
            </author>
            <date day="7" month="July" year="2023"/>
            <abstract>
              <t>   The document discusses the usage and applicability of BGP as the
   control plane for multiple SD-WAN scenarios. The document aims to
   demonstrate how the BGP-based control plane is used for large-scale
   SD-WAN overlay networks with little manual intervention.

   SD-WAN edge nodes are commonly interconnected by multiple types of
   underlay networks owned and managed by different network providers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-bgp-sdwan-usage-13"/>
        </reference>
        <reference anchor="I-D.draft-ietf-idr-sdwan-edge-discovery">
          <front>
            <title>BGP UPDATE for SD-WAN Edge Discovery</title>
            <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Hickory Hill Consulting</organization>
            </author>
            <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
              <organization>Arrcus</organization>
            </author>
            <author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
              <organization>Microsoft</organization>
            </author>
            <author fullname="Gyan Mishra" initials="G. S." surname="Mishra">
              <organization>Verizon</organization>
            </author>
            <author fullname="Venkit Kasiviswanathan" initials="V." surname="Kasiviswanathan">
              <organization>Arista</organization>
            </author>
            <date day="23" month="June" year="2023"/>
            <abstract>
              <t>   The document describes the encoding of BGP UPDATE messages for the
   SD-WAN edge node property discovery.

   In the context of this document, BGP Route Reflector (RR) is the
   component of the SD-WAN Controller that receives the BGP UPDATE from
   SD-WAN edges and in turns propagates the information to the intended
   peers that are authorized to communicate via the SD-WAN overlay
   network.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-idr-sdwan-edge-discovery-10"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.draft-ietf-rtgwg-net2cloud-problem-statement">
          <front>
            <title>Status of this Memo</title>
            <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Andrew G. Malis" initials="A. G." surname="Malis">
              <organization>Malis Consulting</organization>
            </author>
            <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
              <organization>Orange</organization>
            </author>
            <author fullname="Mehmet Toy" initials="M." surname="Toy">
              <organization>Verizon</organization>
            </author>
            <author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
              <organization>Microsoft</organization>
            </author>
            <date day="24" month="April" year="2023"/>
            <abstract>
              <t>   This document describes the network-related problems enterprises
   face at the moment of writing this specification when
   interconnecting their branch offices with dynamic workloads in
   third-party data centers (a.k.a. Cloud DCs) and some mitigation
   practices. There can be many problems associated with connecting to
   or among Cloud DCs; the Net2Cloud problem statements are mainly for
   enterprises that already have traditional VPN services and are
   interested in leveraging those networks (instead of altogether
   abandoning them). Other problems are out of the scope of this
   document.
   This document also describes the mitigation practices for getting
   around the identified problems.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-net2cloud-problem-statement-26"/>
        </reference>
        <reference anchor="I-D.draft-ietf-lsvr-bgp-spf">
          <front>
            <title>BGP Link-State Shortest Path First (SPF) Routing</title>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization>Arrcus, Inc.</organization>
            </author>
            <author fullname="Acee Lindem" initials="A." surname="Lindem">
         </author>
            <author fullname="Shawn Zandi" initials="S." surname="Zandi">
              <organization>LinkedIn</organization>
            </author>
            <author fullname="Wim Henderickx" initials="W." surname="Henderickx">
              <organization>Nokia</organization>
            </author>
            <date day="19" month="June" year="2023"/>
            <abstract>
              <t>   Many Massively Scaled Data Centers (MSDCs) have converged on
   simplified layer 3 routing.  Furthermore, requirements for
   operational simplicity have led many of these MSDCs to converge on
   BGP as their single routing protocol for both their fabric routing
   and their Data Center Interconnect (DCI) routing.  This document
   describes extensions to BGP to use BGP Link-State distribution and
   the Shortest Path First (SPF) algorithm.  In doing this, it allows
   BGP to be efficiently used as both the underlay protocol and the
   overlay protocol in MSDCs.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lsvr-bgp-spf-26"/>
        </reference>
      </references>
    </references>
    <?line 121?>

<section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Donglei Pang for his contribution to the document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61Z63LbuBX+z6dAnR+9WFRsxTvdaLabai0n0dQXVXI2s9Pp
dEASorCmAC5BWqtazrP0Wfpk/Q5AUqRENUmndCaiQOBcvnOnfN/3TM5V9A+e
aCWGLM8K4YU8F7HONkMWhKlnimAljZFa3W9SbJlc3b/1ZJrZzSYfnJ29Pht4
CVfxkAnlebnME2z7YHgsmF6wH95N/eu5P5++ZVKxmyLJpW9EvBIqZ/Ox/3F0
6/EgyMTjsLl1obPuvZEOFV+BQZTxRe6bpVCxn5jHzA/i1DfpwsdR30Rrrvyz
M08HRiciF2boFWnE7c0LRjdDNjgbDPwz+sd8364xadhCJomISFZe5HrFcxny
JNmwYMN+XSWDbBEyuWBK5yyWj6QwzwQfskwXuVSxt9bZQ4wv6ZBdz3+ced7D
eugx5kN+Et8D0aXOsORjVSozZJd9Nict8N1pdknf6jWdxVzJf0IOrYbsfcHX
QmLZ5JkQOTAT8hfwZTPNIyyHMt/YxZ+lPS1WXCZDZmEK6b8/Ly2FfqhXDRne
kwyyluA9twLI4+xrunKJva9bVIEFeYCIZK6zLxc11IXKyesul1Jxz/NhFB7g
MA9zz7tfwjYwfmGdQWKnjopQGJYvBSs6nC3NdK5DnZAlVx2exEwoFM+kNn02
yRlsrNemepYXSokExDULBEuLIJGAMGLcsETH5BEskerB9Nh6KcMlC7liYaaN
EwfSiUyJvMduptdzhjvyCmxGpLFH4lkYplORcQBUPe6zexztUsAS1wpIFCEE
VUw/iizhm+okpEw1xNrYqGnJZzmmy41pLtWCGsGWiI1Mx0IJkqktKY6ERUJh
QUrBy8MlD2QCs1lvB/ZAfF8WpSM8CLgBWlrhpDS1fH1n1JWMokR4iMNJaUZy
Lvb0wlr12fNGhqWaQASJgozNnp7eTPxx38W8FPnCz/J4HfvgOggTXUQ+0AoS
sfKRznJBZn5+7iEfQbs0kwYiIUzBOQbm5IPQSGaMJE7gjdbQlg4zInuUoXDW
2J1nQcYVDG1NC2Mo4YQmnBq7jCS0KlrjS9bYugJKDvpO0JkpQJ8fOoZp6uHr
tQIsAQ8fAmTseg/ilEUyA6smSxhcGKD+lvyCZ7FoIQI5eYgQck7bUt/q1dS1
BMyhIMhB2FRP2buPO/nJTREsQSGTnGjDIo8yEmXwWfK98kuOyFO58zK30g1v
n41FKlREFrPOJFgsNGyYLq1DRxJBIYPCKgtnzLtsRtLSg315yR6Qlzuj+JmI
QQVEgZVAYseDONEBFloB6qhUypaiwiJQmJjsG4+otaU6YsEmdSQ6QVYwlg1P
jM1CzryoRA2mSwRivMT2SFLVjmqLj8JQZxY3CPb09Ju96AlgdVcwbaG0+ZMC
Zi/9lVoKBFWVAQOIK4AOhG5L+jkkymT44/R2t4KnVa7cJbNSJ6JBsqQ6y01l
XOK6h1GfjZLELlCEFyoSDnEIhGyS2BylbGKlUodmh4L7EBEZVV2DiGLhw7NC
Sm2b52cwWhCqlupKIAkqaVY215Zw0QkbTtUpRrmSaRzIfmsoEIBFLrHnUXIr
ietFal1nMzI/MmVZheoi0ojlCvgO/27EkYtiij5u49rRt8/SROzb93jS6FEm
Mkv4qku/qU79eP383K8qMSFXhTgEYGtEE9gWxlWLrjpGeVGjuXLZhOGgyuWC
HLcM3zK2nGFtJbGaWcNXJQ7bWkrYHccyHwqMq0CQrueM0uZBDp4InqnODFEx
7SyHVAFtClUbZ+nyeJ8K273IVlLZwyVgJhXhTtlMFDYDY5sp/StyQM9LBb7p
D0jX/bLX7HThmlKFSWHDvAH4LQF3ez2b9Jqr1yj+5epY/vxAfRUiB32+zJcr
qsyl/EN8wvesPTK0CIgX9g5aA0LPL7Efsrle5GsKuHEp/EdK9SM0Cey2SmgV
+FXX1mMn7vgJ9F+IzIYMEJbhxo8yaqYxUnBlKOJJpckUXhw+CAp/CqraiyO5
wHFq5Wy4N9oPSzJGNkG0AFybQAIYby2jHGHAFfKcE+VRGlk2M9a4Llv0oeJs
NkSLStadiQV5K5pYn12WFX3I7hYLH8isKALHPOfs0oYkRRuHRKaw48JSG/Rq
aZqUJndBWjUcrCwCm4YuzU7bhqarkpTNX7yALL8U8HIS3rBr9NwFVCHfEuxB
bIgwupiTmw/z+5Oe+2S3d/Z+dvXXD5PZ1Zju5+9H19f1jVfumL+/+3A93t3t
Tl7e3dxc3Y7dYayy1pJ3cjP66cRFx8nd9H5ydzu6PiE/btndJmbXSUuXvERu
e2kPqSNE/Xa+/8Pl9N//Or+g3Dx7ezk4P38NB3dfvj3/4wW+rDHAOG5aAWL3
FaG38QA0otgObQk1zKnMUTYbSQzxKQDkH/5GyPx9yL7DaHt+8X25QAq3FivM
WosWs8OVg8MOxI6lDjY1mq31PaTb8o5+an2vcG8sfveG0h/zz799871H6ehr
hnHv06dPmMboOsXYSn+nPuv8285m26710/r2tKS0Ze3Pg+vIg93ytknp1Pe3
PtgcXEcetJZblLbIeOcMD/cvejDAY3/anJ7s8qtKrC6Zzs/65/TH2KC8O7X0
vkKm+rMsdPeu0LGXB+rWsm1fVWw7Ke0rdwgcXbZCHEG8/HzpMvGkatr+27W9
6JTpqO2OXN04YfWUbPFNw3ZtuKyg1HK2THphj5I9vGM8vlwmr7161LmPXFvv
1EWLo9m4/xIRdttPq1jbfsD4VuKxvZxenX+5RLR9sC1hGk2n5v8nXZkTbF55
GrIXrpVkzL4o/NPJXtN14ub/jtazR6FK/w161vBUVQ6mDsNXu/cvLyfzaXu+
opim+kFBvHe+GqVcK9maqB7QSVqO9uTF3kkU8Wqy6dsEW/qhEjJeBjpzg0nX
DEVqN0eARnb+/GHbzaKTJaHocLsrLl/1fAHjTokz1/lQF1Y+c298fmeE+Krh
6fftQYJM1A7TnUjnJb4DtkZLWs9+1AbyKEIratwbpzrD0vYqyfYgMrXYOdrI
ZEPmKt9ElZo0OZcQ1SOFVJjlVq4xp4bejZO9RnPdnq/9ne3tviaSB+azusA+
ngfNfPidf+hBx8b4r3OIplH3KLmmqXyRsNtduc7ei8cdq2rzHjk3aRsXdfXM
2xrTmpiWs/uBTNULL/vQhR25rYOs0/Svmqavy8tOpVd1iLY8biHjIitf6bWl
6BZY1m7jVOzwiJYr/Y8OsQf79eT2L3ZAI/4VuiHPsk396kOoyL4YbQBTodv2
bRrs951pj93t3fjqCLuOObw9rFtiG+sGPHqkdxvleTcINz2RZCMfa03iDlA3
eZuD+X691MnhMO5GcLU3hivxa45ZK21P4qBdGDJT56T7gmHILjIa/S4xakG1
zA1d+78yRBpuR7/01D83WB5KrJmpKIQtCpb6ZHQ7+gzlJSfCbicPq6PUmdF7
QSIyCh+UXieUT+3M59zF/XoEFHWRkGEfhCt8HGEz1ipOhGRT+vGG3k4RRzvX
Vm9IyxpZSdH3/gNRNF45ABwAAA==

-->

</rfc>
