<?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.39 (Ruby 3.2.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sheng-idr-gw-exchange-in-sd-wan-02" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.0 -->
  <front>
    <title abbrev="Gateway Info Exchange in SDWAN">Associated Gateway Exchange in Multi-segment SD-WAN</title>
    <seriesInfo name="Internet-Draft" value="draft-sheng-idr-gw-exchange-in-sd-wan-02"/>
    <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>
    <author initials="L." surname="Dunbar" fullname="Linda Dunbar">
      <organization>Futurewei</organization>
      <address>
        <email>linda.dunbar@futurewei.com</email>
      </address>
    </author>
    <author initials="G." surname="Mishra" fullname="Gyan Mishra">
      <organization>Verizon</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
    <date year="2024" month="Feb" day="29"/>
    <area>Routing</area>
    <workgroup>Inter-Domain Routing</workgroup>
    <keyword>Multi-segment SD-WAN</keyword>
    <abstract>
      <?line 45?>

<t>The document describes the control plane enhancement for multi-segment SD-WAN to exchange the associated GW information between edges.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Inter-Domain Routing Working Group mailing list (idr@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/idr/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/VMatrix1900/draft-sheng-idr-gw-exchange-in-sd-wan"/>.</t>
    </note>
  </front>
  <middle>
    <?line 49?>

<section anchor="intro">
      <name>Introduction</name>
      <t><xref target="I-D.draft-dmk-rtgwg-multisegment-sdwan"/> describes how enterprises leverage Cloud Providers’ backbone infrastructure to interconnect their branch offices. As illustrated in Figure 1, CPE-1 and CPE-2 establish connections to their respective Cloud Gateways (GW) in distinct regions. CPE-1 and CPE-2 maintain the pairwise IPsec Security Associations (SAs). The IPsec encrypted traffic from CPE-1 to CPE-2 is encapsulated by the GENEVE header [RFC8926], with the outer destination address being the GW1.</t>
      <t><xref target="I-D.draft-dmk-rtgwg-multisegment-sdwan"/> specifies a set of sub-TLVs to convey information about the GWs associated with the destination branches, such as GW3 for CPE-2, along with additional attributes. To accomplish this, CPE-1 must be aware of the associated GW addresses of their peers. This document proposes a BGP extension, building upon <xref  target="I-D.draft-ietf-idr-sdwan-edge-discovery"/>, enabling a CPE to advertise its directly connected GW address to other CPEs .</t>
      <figure anchor="Scenario">
        <name>Multi-segment SD-WAN</name>
        <artwork><![CDATA[
  (^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
  (            Region2             )
  (            +-----+             )
  (            | GW2 |             )
  (            +-----+             )
  (           /       \            )
  (          /  Cloud  \           )
  (         /  Backbone \          )
  ( Region1/             \Region3  )
  ( +-----+               +-----+  )
  ( | GW1 |---------------| GW3 |  )
  ( +--+--+               +--+--+  )
  (^^^^|^^^^^^^^^^^^^^^^^^^^^|^^^^^)
       |                     |
    +--+--+               +--+--+
    |CPE 1|               |CPE 2|
    +-----+               +-----+
]]></artwork>
      </figure>
    </section>
    <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?>

<t>The following acronyms and terms are used in this document:</t>
      <ul spacing="normal">
        <li>Cloud DC:     Off-Premises Data Center, managed by 3rd party, that hosts applications, services, and workload for different organizations or tenants.</li>
        <li>CPE:        Customer (Edge) Premises Equipment.</li>
        <li>OnPrem:               On Premises data centers and branch offices.</li>
        <li>RR          Route Reflector.</li>
        <li>SD-WAN:               Software Defined Wide Area Network. In this document, “SD-WAN” refers to a policy-driven transporting of IP packets over multiple underlay networks for better WAN bandwidth management, visibility, and control.</li>
        <li>VPN         Virtual Private Network.</li>
      </ul>
    </section>
    <section anchor="extension-to-sd-wan-underlay-update-for-associated-gws">
      <name>Extension to SD-WAN Underlay UPDATE for Associated GWs</name>
      <t>The Client Routes Update is the same as described in <xref section="5" sectionFormat="of" target="I-D.draft-ietf-idr-sdwan-edge-discovery"/>.</t>
    
 	  <section anchor="NLRI-SD-WAN-SAFI"> 
		<name>NLRI SD-WAN SAFI Route Type For GW</name>
		<t>Adding a new attribute (Associated-Gateway Sub-TLV) to the SD-WAN-Hybrid Tunnel Encoding which is included in the SD-WAN SAFI (=74) Underlay Tunnel Update:
		</t>
		 <artwork><![CDATA[
+------------------+
|    Route Type    | 2 octet
+------------------+  
|     Length       | 2 Octet
+------------------+   
|   Type Specific  |  
~ Value (Variable) ~  
|                  |  
+------------------+ 

]]></artwork>
	<t>NLRI Route-Type = 2: For advertising the detailed properties of the transit gateways for the edge. The SD-WAN NLRI Route-Type =2 has the following encoding:
	</t>
         <artwork><![CDATA[
+------------------+
|  Route Type = 2  | 2 octet
+------------------+
|     Length       | 2 Octet
+------------------+  
|   SD-WAN Color   | 4 octets 
+------------------+
|  SD-WAN-Node-ID  | 4 or 16 octets
+------------------+
]]></artwork>
	<t> SD-WAN-Color: To represent a group of tunnels that correlate with the Color-Extended-community included in a client route UPDATE. When multiple SD-WAN edges can reach a client route co-located at one site, the SD-WAN- Color can represent a group of tunnels terminated at those SD-WAN edges co-located at the site, which effectively represents the site.</t>
	<t>SD-WAN Node ID: The node's IPv4 or IPv6 address.</t>

	 </section>	
	  <section anchor="Associated-gw-sub-tlv">
        <name>Associated GW Sub-TLV</name>
        <t>The Associated GW Sub-TLV, within the SD-WAN-Hybrid Tunnel TLV (code point 25), carries the associated GW address(es) with which the SD-WAN edge is associated.</t>
        <t>The following is the structure of the associated GW Sub-TLV:</t>
        <artwork><![CDATA[
    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=TBD    |    length     |  Priority         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Associated GW Addr Family     | Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable)                    +
   ~                                                               ~
   |             Associated GW Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
	<t>Priority (1-255) indicate the preference of the GW. The higher the value, the more preference is the GW.</t>
	<t>Priority = 0 represents that the connection exists but request Cloud Backbone not to choose the GW if possible.  
	</t>
    </section>
    </section>
	    <section anchor="Manageability-Considerations">
      <name>Manageability Considerations</name>
      <t>Effective management of SD-WAN edge nodes and the exchange of associated cloud gateway information are critical aspects in ensuring a robust and scalable SD-WAN deployment.</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>Need IANA to assign a new Sub-TLV Type under the SD-WAN-Hybrid Tunnel TLV.</t>
      <t>-	SD-WAN Associated GW Sub-TLV. </t>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="I-D.draft-dmk-rtgwg-multisegment-sdwan">
        <front>
          <title>Multi-segment SD-WAN via Cloud DCs</title>
          <author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
            <organization>Microsoft</organization>
          </author>
          <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
            <organization>Futurewei</organization>
          </author>
          <author fullname="Venkit Kasiviswanathan" initials="V." surname="Kasiviswanathan">
            <organization>Arista</organization>
          </author>
          <author fullname="Ashok Ramchandra" initials="A." surname="Ramchandra">
            <organization>Microsoft</organization>
          </author>
          <date day="31" month="May" year="2023"/>
          <abstract>
            <t>   The document describes the methods to optimize the stitching of
   multiple SD-WAN segments on transit nodes across Cloud DCs.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-dmk-rtgwg-multisegment-sdwan-07"/>
      </reference>
      <reference anchor="RFC8926">
        <front>
          <title>Geneve: Generic Network Virtualization Encapsulation</title>
          <author fullname="J. Gross" initials="J." role="editor" surname="Gross"/>
          <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/>
          <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/>
          <date month="November" year="2020"/>
          <abstract>
            <t>Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8926"/>
        <seriesInfo name="DOI" value="10.17487/RFC8926"/>
      </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-12"/>
      </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>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61Y63IbtxX+v09xKv+oVGsZkXYSm5MbRdKWZmSJFSV7MnXb
AXexJKolsAGwYhhdxq+RmXSmz9JH8ZP0O9glRUpU4kwKe6TdswcH534+KI7j
yHmh03+K3GjZJm9LGSXCy7Gx8zY5n0auHE2Vc8ros3kBlsP+2atIFTYwO9/a
23u514pyocdtkjqKvPI52LrGWukKo1Olx/QaImdiTv0fkwk4JSlNb8rcq9jJ
8VRqT8Ne/K5zHInRyMrL9nLDoc7M2q5hj9lSk2gxxTGpFZmP3UTqcaxSG49n
say5Y6Vjl8YzoeO9ZmRGzuTSS9eOyiIV4eEJ8UObWnutVrzH/ymOA42Uo0zl
uUz5TFF6MxVeJSLP5zSa04/TvGWzhFRG2ngaq0u2XFgp2rR1akoPm7eimbEX
Y2vKAsRD7aWNexADeUuO6GLWjojizb6IcO7EWHDEYFLawasNGrKteK/s7/Lb
kmbsWGj1E1Q1uk0HpZhJBbLzVkrfpn2pfuBonBqRgpwoPw/Ef6mwW0K5HEFn
YQn/+G4SJDQSM13R4YB1UEsNDkRQQD1+/FKu4ri8XJNK1nC2yFR5Yz9d1cSU
2nOGdidKixXljhrUK/VI2KV+R0qn4o64ruOr0pdWrqmZM38jDfzfZYvvQdso
ipEfYgQlReKj6GwiCZlYhqCl0iVWjaQjD3JioJ/JqUBhSNQFLE9k4MuMpemG
cJM3tEjdWsRaBb2Dgdg7DZrTSPqZlBqOG0vXqBSbqjTNZYS0PuTD0zIJrFdP
FL/eRNHV1Z8O416jqpl0ehFbP56N46BNrQwqBgVzc3PPHMnpW1hwOULu5uon
1qmbmzKlgTWXKpXWffzwM41EcjFCK2FrFG+CI7RMPEtRlkYWfpiQyTKVQG/q
OKSFmWmusldqDF9Tc5e6g37cJLSl8NQiFBbVclCQkFwJY++AhOKrNambhqPt
1+92WGSqskxa9rGVY/gCJ96XzQXpuSjZzEIoO4ORdDhwMqFhBxs4yNWr1Imd
F0EFeBAWUGbNtJYIrSqB6BxgFIUrc8G8aBcs+nX/uP+2TxMp4CpCJE5fdV+8
bH1xc7NLM+UngQl9AR/herSHKs4iTWGmQ7zZ4UHQu2aDfk8k2UkqU4icICc9
nE/o6fHZ0VvHWifC2krF1fwCU3WYWzyualWFUbpdko1xYxdsz0Je1+GCcw22
WBLeI4dgFKfomSGRoIyKXDk2V/hFpLWUadDlQptZHdxCIqP+/LAIaofIEBn4
ell/hTWFccHK/dcDlJKX2gVlhUMYuBBWnaakz8LECG6KuY7iVLnEXEo7h9fY
HMH6sV4iBZU9S8rjSGWRdpgEdzl5pxizV8ZjL5sd3d7eorts/+M31g4z0co6
DSnbWiXRA6anMa+nv850Df1a+PmHJX1W/37/K0zgqapxjWudCTz7i0bx/j5T
ZXfzM1pd7yvqswXTJm1XbKiY2O4mXcfr6zqk6/WKpKcbJT29k8Txud4Ytetl
7MK6pk3rOloTuemgwHHN6da8LyNQW0sZj5sdMu2qTU+GidTCKkMUwNjXW5vg
xRYGAkbFqfyhRD7zB0dHGD6lGMtqtF3IOQHDoDS33pwPz7Z2q990fBKeT/t/
PT887ff4eXjQOTpaPkQ1x/Dg5Pyod/d0t7N78uZN/7hXbQaV1kjR1pvO9/jC
jWTrZHB2eHLcOdqi0KRXS57nAsptJKtRU1jJtShctBheAb3tdwf//U/zed1z
W83mS5R33YCbXz7HywxgpzrNaJR19YoankeiKKSwAQPmOVplobzI0fbEYm6h
0CWK/C9/Y8/8vU1fjZKi+fybmsAGrxEXPlsjBp89pDzYXDlxA2nDMUtvrtHv
eXpd3873a+8Lv68Qv/oW4EhS3Hzx7TdRlSOZyXMz494sEmv0fOqCHxENfkJ8
SldFYS1ybQCWukv0uu2QwydZFg+QhwFi9IRH7w2gYxcTWiMlwyB9ZlPMaOvn
u2F+0MQ4ZC2ClAOb82RCaJy0lwwuqoAyBs+BIUM/v4MDqygQE85CYS1QAQ3W
a9BvLyqrixuOmaKZb/cxIHZoqWEfVVOwKbzjRDO9fa8qT/Qde8oGJcGgykH3
gBCEnJ7ebeULgkRpZjnGi7H8uSra+2cMTeZn7OaezBCalN4BiVEHFxE6BkKE
8Q2AwXXn79LHD79U4j5++DeQUcZK8ZSjwsCR8zi1fKFhlKMxei3fVRgFHA7g
/ORCwuU8JSsUW+SIsQamyXFb09WZLngbEJXRDEPbEUyeqRQopwpmpcalcmoE
LMnhZJ/UmJmtfTs4Xtr4VllfihzOVJd8NVsYxt2rv5zy0L/G0ecLbc4Hvc5Z
vwIm92CEq7K3myvOhuBuR+fF4urHeMfh9sB1vtZLrq6GskLVnwePfCqcYGWf
PNCChhUOq5V55GuFD2uEWtkYH8xHVqV0VgKA5AQm2k4MIl8YdEJqfb6zG3Cd
Wt5GNqOobel2KvQ5m6hksnJCuFiwK4RzJlGMZBv3K37hKG9x02DoXiPFxwxp
L7AQ0R41qUXP6Dn8+AV9SS/o5e+hRWHo/cF/UT2v+c8aX5/t95bzO8fVFy6p
32EKOgrCv5zk/6eTH7ipg6DQKzFVmEH43qkB5eb1aZrQ9iWAgBjl6F0bVtDk
9pETPnXdLhx5tzaa9rgtn2zObzqW8wttAUVaWvQVKILugHZQNXpO4FX8kBrU
B/8BR9X3ZRS85i42wxSpJSRrEkLTOewcdx5K3u/V13C+Akf/A22PUchaEwAA

-->

</rfc>
