Re: [Idr] Comments about BGP UPDATE for SDWAN Edge Discovery

[Linda Dunbar <[e-mail]>]

Haobo,

Thank you very much for the comment.
What you suggested is an optimization.
Using the Figure below as an example, there are multiple IPsec SAs terminated at 192.0.0.1 port and multiple IPsec SAs terminated 170.0.0.1 respectively on C-PE2. C-PE2 can use flat IPsec SA IDs to distinguish all the SAs, such as SA-ID =1~5 refers to the IPsec SAs terminated at the port 192.0.0.1. SA-ID = 100~105 refers to the IPsec SAs terminated at 170.0.0.1.
Then the route update for prefix 10.1.1.x can  just  include a list of SA-IDs that the prefix 10.1.1.x can be carried in the Tunnel -Encap Attribute.


[cid:image002.png@01D65478.B2B95F30]


[cid:image006.png@01D65478.B2B95F30]


What illustrated in the draft is the first step for IDR  WG to agree upon the basic scheme. The optimization can be added after the IDR WG agrees upon the basic scheme of using pointer to SA ID, instead of attaching all the SA attributes.

Linda Dunbar

From: Wanghaibo (Rainsword) <[e-mail]>
Sent: Tuesday, July 7, 2020 7:22 AM
To: [e-mail]; 'idr@ietf. org' <[e-mail]>
Subject: Comments about BGP UPDATE for SDWAN Edge Discovery

Hi authors,

3.2. Basic Schemes
   BGP UPDATE from C-PE2 for the attached client routes is like:

         Extended community: RT for SDWAN Instance 1
         Prefix: 10.1.1.x; 20.1.1.x
         NH: C-PE 2
         Tunnel Encap Attr [AFI/SAFI = 1/1)
           MPLS-in-GRE [tunnel type=11]
             Sub-TLV for MPLS-in-GRE [Section 3.2.6<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-idr-sdwan-edge-discovery-00%23section-3.2.6&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C196ceb7841244c30cba908d822706a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297213507921765&sdata=F8VGU3Hx4XxGxm5b8dbfZN4hyi6dnc6P8pkhOax%2BCv4%3D&reserved=0> of Tunnel-encap]
           IPSec SA for 192.0.0.1 [tunnel type=4]
             Tunnel-End-Point Sub-TLV [Section 3.1<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-idr-sdwan-edge-discovery-00%23section-3.1&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C196ceb7841244c30cba908d822706a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297213507931768&sdata=gXQxD%2FO0VLRAr%2BzcDRO4VJnm87nIdKUpGimPtcwFBjI%3D&reserved=0> of Tunnel-encap]
             IPsec SA sub-TLV [See the Section 5<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dunbar-idr-sdwan-edge-discovery-00%23section-5&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C196ceb7841244c30cba908d822706a8b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637297213507931768&sdata=M8%2FRDP%2Bkw3aBV6ktdVnVRqq4LTHAry8mqxxK8%2FoCeYY%3D&reserved=0>]
         Tunnel Encap Attr [AFI/SAFI = 1/1)
           IPSec SA for 170.0.0.1
             Tunnel-End-Point Sub-TLV /*the address*/
             IPsec SA sub-TLV
  // Here one client route contained several Tunnel-Encap Attribute, but for BGP Updates, any attribute should not appears more than once
 // Another question. Why we use this attrbute to associate client routes with SD-WAN routes? Perhaps we may use some simple info like color extend-community (like sr-policy)

Regards
Haibo