Re: [bess] solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation

[Linda Dunbar <[e-mail]>]

Basil,

Thank you very much for the comments.
Your suggested wording change will be incorporated in the next revision.

As for your suggestion of Segment and Segment ID of a SDWAN node (to be included in the BGP UPDATE), does the "Segment" mean the different Underlay?
In the figure below, C-PE1 has 3 WAN ports: 2 to MPLS network and 1 to Public Internet.
Do you mean C-PE1 has 3 WAN "segments"?
If not, can you elaborate more?

[cid:image002.png@01D5DA75.D86A6DA0]


Thanks, Linda

From: Najem, Basil <[e-mail]>
Sent: Sunday, February 02, 2020 5:48 PM
To: Linda Dunbar <[e-mail]>; [e-mail]
Cc: [e-mail]
Subject: RE: solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation


Hello Linda;

I haven't gone through the entire document; however, I have the following quick comments


  1.  Regarding the following paragraph:


  1.  Augment of transport, which refers to utilizing overlay paths over different underlay networks. Very often there are multiple parallel overlay paths between any two SDWAN edges, some of which are private networks over which traffic can traverse without encryption, others require encryption, e.g. over untrusted public networks.

The traffic that traverses the privet networks can be either encrypted or unecrypted (in other words, the assumption that the traffic is NOT encrypted is not always correct). I would change the parpagaph to the following (for clarity):


  1.  Augment of transport, which refers to utilizing overlay paths over different underlay networks. Very often there are multiple parallel overlay paths between any two SDWAN edges, some of which are private networks over which traffic can traverse with or without encryption, others require encryption, e.g. over untrusted public networks.



  1.  Another thing that we need to discuss is the Segment ID; each Segment (at the SD-WAN Edge) MUST have an ID. The SD-WAN Policy will map the Application Flow to the Segment. Since the Segment is a "routing domain", the BGP update will be exchanged with the memebers of a particular Segment.



As such: Should we include the Segment ID as an attribute in the BGP update messages? Perhaps we need to further discuss this in details.

Any feedback is welcomed and it's highly appreciated.

Regards;

Basil


From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: January-31-20 5:17 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT]solicit feedback on draft-dunbar-bess-bgp-sdwan-usage description of using BGP UPDATE messages to achieve SD-WAN Application Based Segmentation

BESS participants:

"SDWAN" networks is characterized by:

  1.  Augment of transport, which refers to utilizing overlay paths over different underlay networks. Very often there are multiple parallel overlay paths between any two SDWAN edges, some of which are private networks over which traffic can traverse without encryption, others require encryption, e.g. over untrusted public networks.
  2.  Enable direct Internet access from remote sites, instead hauling all traffic to Corporate HQ for centralized policy control.
  3.  Some traffic are routed based on application IDs instead of based on destination IP addresses.


https://datatracker.ietf.org/doc/draft-dunbar-bess-bgp-sdwan-usage/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dunbar-bess-bgp-sdwan-usage%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1f725814c8924c2e4d6c08d7a83a7306%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637162841310506376&sdata=Z5wrL%2BhyBnovmn7ojkMq6x0TaEJrzhbnPb6PEP2wYB4%3D&reserved=0> describes examples of using BGP UPDATE messages to achieve the SDWAN Application Based Segmentation,  assuming that the applications are assigned with unique IP addresses.
In the Figure below, the following BGP Updates can be advertised to ensure that Payment Application only communicates with the Payment Gateway:

[cid:image001.png@01D5DA73.0566B910]

BGP UPDATE #1 from C-PE2 to RR for the RED P2P topology (only propagated to Payment GW node:

-        MP-NLRI Path Attribute:

        *   30.1.1.x/24

-        Tunnel Encap Path Attribute

        *   IPsec Attributes for PaymentGW ->C-PE2


BGP UPDATE #2 from C-PE2 to RR for the routes to be reached by Purple:

-        MP-NLRI Path Attribute:

        *   10.1.x.x
        *   12.4.x.x

-        TunnelEncap Path Attribute:

        *   Any node to C-PE2


Your feedback is greatly appreciated.

Thank you very much.

Linda Dunbar
________________________________
External Email: Please use caution when opening links and attachments / Courriel externe: Soyez prudent avec les liens et documents joints