Subject: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

From: Linda Dunbar <[email-masked]>
Date: Mon, 12 Aug 2019 22:18:30 +0000

IDR participants:

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page: https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/

The Goal is for WAN Ports Property Propagation across SDWAN nodes in different domains

The constraints are those SDWAN edges can be spread across different geographical locations, their connection to RR can be over untrusted networks, and they might not know the reachable addresses for the peers they need to communicate (therefore needing RR to propagate).

There are many ways to skin the cat... different encoding for BGP Update Messages

Option 1: Extending Tunnel-Encap with existing IP's SAFI to achieve WAN port registration.

  *   Pros:
     *   no new SAFI introduced, the update messages can traverse existing routers
  *   Cons:
     *   Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is very different from clients' routes attached to the C-PEs.
     *   The receivers (RR) has to do extra processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.

Option 2: Tunnel-Encap with SDWAN NLRI for SDWAN WAN Ports Prosperities & Policies described by draft-dunbar-idr-sdwan-port-safi-02

  *   Pros:
     *   Clean design and processing on the receivers (RRs). Simpler processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.
  *   Cons:
     *   New NLRI is introduced, the update messages can't traverse existing routers
        *   Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is strictly between SDWAN edge nodes and their respective RR(s) via a secure tunnel, the SDWAN UPDATE messages are not going to traverse existing routers. Therefore, it doesn't cause any issues.

Option 3: Using the new SAFI introduced for BGP labeled Colored Unicast  described by draft-szarecki-idr-bgp-lcu-traffic-steering

  *   Pros:
     *   leverage the newly proposed NLRI for carrying Traffic Color across domains
     *   Similar goal as SDWAN needing to propagating WAN port properties across domain/geolocations
  *   Cons:
     *   Need to attach the attributes which haven't been specified by the draft yet.

Need to ask merging the content from draft-dunbar-idr-sdwan-port-safi-02.

We are looking for feedback to those analysis and options.

Thank you very much
Linda Dunbar

---

From: "Wanghaibo (Rainsword)" <[email-masked]>
Date: Tue, 13 Aug 2019 07:52:13 +0000

Hi Linda,
I think both option 1 & 2 is Ok , but use for different scenario.
For option 2, it may use for all service share same SDWAN tunnel. For option 1, it may use for each service has different requirement.
Though option 1 also can realize the share same SDWAN tunnel, but it will choose one or more routes to advertise the SDWAN tunnel info , it may cause the tunnel deploy complex.

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, August 13, 2019 6:19 AM
To: [email-masked]
Subject: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

IDR participants:

*       Pros:
-      no new SAFI introduced, the update messages can traverse existing routers
*       Cons:
-      Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is very different from clients' routes attached to the C-PEs.
-     The receivers (RR) has to do extra processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.

*       Pros:
-      Clean design and processing on the receivers (RRs). Simpler processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.
*       Cons:
-      New NLRI is introduced, the update messages can't traverse existing routers
*       Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is strictly between SDWAN edge nodes and their respective RR(s) via a secure tunnel, the SDWAN UPDATE messages are not going to traverse existing routers. Therefore, it doesn't cause any issues.

*       Pros:
-      leverage the newly proposed NLRI for carrying Traffic Color across domains
-      Similar goal as SDWAN needing to propagating WAN port properties across domain/geolocations
*       Cons:
-      Need to attach the attributes which haven't been specified by the draft yet.

Need to ask merging the content from draft-dunbar-idr-sdwan-port-safi-02..

Thank you very much
Linda Dunbar

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Aug 2019 10:16:13 +0200

Hi Linda,

I must up front say that your efforts in this area are very useful ! Thank
you for this work.

But in the same time I need to ask why are we so much hostage of BGP and
attempt to propagate all of this opaque information in BGP ? SDWANs by
design are to span globe and out of the information you would inject into
global BGP only tiny fraction (if even that much) would benefit - for rest
of the users it will be unneeded data.

My suggestion here is to think outside of the box and while BGP could carry
some short reference the actual information should be kept outside of it in
one of the new global databases. See today I operate a global SDWAN and it
works just fine when my controller is distributed in AWS cloud.

I would be actually afraid to advertise anything in my EBGP sessions to my
providers and it may just attract attacks and hackers towards my sides
without any real value to the sites I am interconnecting.

So perhaps we should spend this energy on building secure NNI to the
interface of such public database rather to keep loading more and more
service info into flat BGP ?

Many thx,
R.

PS. Natural question POPs up - what's wrong with using LISP mapping plane
for it ? Sure some are allergic to LISP just like some were allergic to
MPLS, but is this really a right reason not to explore full spectrum of
options ?

On Tue, Aug 13, 2019 at 12:48 AM Linda Dunbar <[email-masked]>
wrote:

> IDR participants:
>
>
>
> Many thanks to the feedback from IETF105 discussion on
> draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with
> Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible
> encoding options. I put together an analysis of multiple BGP UPDATE
> encoding options to achieve SDWAN WAN port properties propagation among
> SDWAN edges. Please see the slides in the IDR WIKI page:
> https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/
>
>
>
> The constraints are those SDWAN edges can be spread across different
> geographical locations, their connection to RR can be over untrusted
> networks, and they might not know the reachable addresses for the peers
> they need to communicate (therefore needing RR to propagate).
>
>
>
> There are many ways to skin the cat… different encoding for BGP Update
> Messages
>
> *Option 1: Extending Tunnel-Encap with existing IP’s SAFI to achieve WAN
> port registration. *
>
>
>
>    - *Pros:*
>    - *Cons:*
>       - Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is
>       very different from clients’ routes attached to the C-PEs.
>       - The receivers (RR) has to do extra processing to differentiate
>       the UPDATE messages  from the attached routes UPDATE messages.
>
>
>
> *Option 2: Tunnel-Encap with SDWAN NLRI for SDWAN WAN Ports Prosperities &
> Policies described by draft-dunbar-idr-sdwan-port-safi-02*
>
>
>
>    - *Pros:*
>       - *Clean design and processing on the receivers (RRs). Simpler *processing
>       to differentiate the UPDATE messages  from the attached routes UPDATE
>       messages.
>    - *Cons:*
>       - New NLRI is introduced, the update messages can’t traverse
>       existing routers
>          - Since the the Tunnel UPDATE message with the new SDWAN
>          NLRI/SAFI is strictly between SDWAN edge nodes and their respective RR(s)
>          via a secure tunnel, the SDWAN UPDATE messages are not going to traverse
>          existing routers. Therefore, it doesn’t cause any issues.
>
>
>
> *Option 3: Using the new SAFI introduced for BGP labeled Colored Unicast
>  described by draft-szarecki-idr-bgp-lcu-traffic-steering*
>
>
>
>
>
>    - *Pros:*
>    - *Cons:*
>       - Need to attach the attributes which haven’t been specified by the
>       draft yet.
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 13 Aug 2019 16:36:49 +0800

Hi, Linda:

Thanks for your analysis on this topic.

Would you like to make more clarifications for the following questions?

1.  What extra work will the RR do in Option 1? In my understanding, RR just
send these updates to other ends. Only the other end needs to process these
extended updates.

2.  NAT transverse procedures for the communication between CPEs is complex,
considering there are many different type NAT devices located within the
network.  There is no easy way to detect the NAT type between them(It’s
maybe easier to infer such information between CPE and RR). Then is it
necessary to transfer the NAT related information in Option 2?

3. Is it more flexible to make the IPsec encapsulation information
associated with other tunnel types that defined in https://datatracker.ietf.
org/doc/draft-ietf-idr-tunnel-encaps/?, which is under the existing
AFI/SAFI.  If so, option 1 seems more acceptable?

Best Regards.

Aijun Wang

China Telecom 

发件人: [email-masked] [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2019年8月13日 6:19
收件人: [email-masked]
主题: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN
port properties propagation among SDWAN edges (pros & cons to
draft-dunbar-idr-sdwan-port-safi and alternatives)

IDR participants:

Many thanks to the feedback from IETF105 discussion on
draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with
Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible
encoding options. I put together an analysis of multiple BGP UPDATE encoding
options to achieve SDWAN WAN port properties propagation among SDWAN edges.
Please see the slides in the IDR WIKI page:
<https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/>
https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/

The Goal is for WAN Ports Property Propagation across SDWAN nodes in
different domains

The constraints are those SDWAN edges can be spread across different
geographical locations, their connection to RR can be over untrusted
networks, and they might not know the reachable addresses for the peers they
need to communicate (therefore needing RR to propagate). 

Option 1: Extending Tunnel-Encap with existing IP’s SAFI to achieve WAN
port registration. 

*	Pros:

*	no new SAFI introduced, the update messages can traverse existing
routers

*	Cons:

*	Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is
very different from clients’ routes attached to the C-PEs. 
*	The receivers (RR) has to do extra processing to differentiate the
UPDATE messages  from the attached routes UPDATE messages. 

Option 2: Tunnel-Encap with SDWAN NLRI for SDWAN WAN Ports Prosperities &
Policies described by draft-dunbar-idr-sdwan-port-safi-02

*	Pros:

*	Clean design and processing on the receivers (RRs). Simpler
processing to differentiate the UPDATE messages  from the attached routes
UPDATE messages. 

*	Cons:

*	New NLRI is introduced, the update messages can’t traverse existing
routers

*	Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is
strictly between SDWAN edge nodes and their respective RR(s) via a secure
tunnel, the SDWAN UPDATE messages are not going to traverse existing
routers. Therefore, it doesn’t cause any issues. 

Option 3: Using the new SAFI introduced for BGP labeled Colored Unicast
described by draft-szarecki-idr-bgp-lcu-traffic-steering

*	Pros:

*	leverage the newly proposed NLRI for carrying Traffic Color across
domains
*	Similar goal as SDWAN needing to propagating WAN port properties
across domain/geolocations 

*	Cons:

*	Need to attach the attributes which haven’t been specified by the
draft yet. 

 

Thank you very much 

Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Aug 2019 18:07:23 +0000

Robert,

Thanks for the quick feedback. It is interesting that you mentioned LISP, I had “LISP” listed as the 4th option in my first version of the analysis, then decided to remove it because the discussion is in IDR group. Legitimate question on WHY BGP?

In addition to looking into your suggested “out of box thinking” that BGP carrying some short reference the actual information should be kept outside of it in one of the new global databases,  here are some of the Compelling reasons of using BGP to distribute SDWAN edge properties among peers that might be spread across the globe:
(note: the BGP for SDWAN Edges is running at different layers than the BGP for underlay networks, i.e. not “FLAT” BGP. They are among SDWAN edges, not for exposing to underlay provider as you stated EBGP. When the underlay network service providers use SDWAN to temporarily expand bandwidth in some segments, they have more reason to use BGP to minimize amount of learning & configuration of introducing new protocols in their environment)

     *   BGP already widely deployed as sole protocol (see RFC 7938). Even if not for this purpose of propagating SDWAN WAN port properties, the BGP base protocol implementation is supported by virtually all switches/routers (virtual & physical).  Even AWS VPC export the BGP routes.
     *   Wide acceptance – minimal learning (which is very important requirement for operations)
     *   Robust and simple implementation,
     *   Reliable transport
     *   Guaranteed in-order delivery
     *   Incremental updates
     *   No flooding and selective filtering
     *   RR already has the capability to apply policies to communications among peers.
Bottom line:  It is much easier to add one function than adding a brand-new protocol stack.

Alternative: extending LISP, NHRP, DSVPN/DMVPN

     *   In addition to more proposal changes needed, NHRP/DSVPN/DMVPN don’t scale well.
     *   More learning, more barrier to be deployed, just think how many decades of painful journey deploying IPv6.
     *
Prior extension of BGP for non-client routes reachability: Flowspec, BGP LS, Segment routing policies, etc

Linda

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, August 13, 2019 3:16 AM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

Hi Linda,

I must up front say that your efforts in this area are very useful ! Thank you for this work.

But in the same time I need to ask why are we so much hostage of BGP and attempt to propagate all of this opaque information in BGP ? SDWANs by design are to span globe and out of the information you would inject into global BGP only tiny fraction (if even that much) would benefit - for rest of the users it will be unneeded data.

My suggestion here is to think outside of the box and while BGP could carry some short reference the actual information should be kept outside of it in one of the new global databases. See today I operate a global SDWAN and it works just fine when my controller is distributed in AWS cloud.

I would be actually afraid to advertise anything in my EBGP sessions to my providers and it may just attract attacks and hackers towards my sides without any real value to the sites I am interconnecting.

So perhaps we should spend this energy on building secure NNI to the interface of such public database rather to keep loading more and more service info into flat BGP ?

Many thx,
R.

PS. Natural question POPs up - what's wrong with using LISP mapping plane for it ? Sure some are allergic to LISP just like some were allergic to MPLS, but is this really a right reason not to explore full spectrum of options ?

On Tue, Aug 13, 2019 at 12:48 AM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
IDR participants:

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page: https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1dcce2de7b98451f28ac08d71fc68923%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012809899266710&sdata=pOfkTPzzGqHfcukg6Oz5gtcNmFNPnd5D73H76OTEr5E%3D&reserved=0>

There are many ways to skin the cat… different encoding for BGP Update Messages

Option 1: Extending Tunnel-Encap with existing IP’s SAFI to achieve WAN port registration.

  *   Pros:

  *   Cons:

     *   Same IPv4/IPv6 SAFI NLRI carries the WAN port information that is very different from clients’ routes attached to the C-PEs.
     *   The receivers (RR) has to do extra processing to differentiate the UPDATE messages  from the attached routes UPDATE messages.

  *   Pros:

  *   Cons:

     *   New NLRI is introduced, the update messages can’t traverse existing routers

        *   Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is strictly between SDWAN edge nodes and their respective RR(s) via a secure tunnel, the SDWAN UPDATE messages are not going to traverse existing routers. Therefore, it doesn’t cause any issues.

  *   Pros:

  *   Cons:

     *   Need to attach the attributes which haven’t been specified by the draft yet.

Thank you very much
Linda Dunbar
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1dcce2de7b98451f28ac08d71fc68923%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012809899266710&sdata=t%2B11tSNemH%2FSteHUL%2FefOgSi1WB8QPfvKxocxbcnkBE%3D&reserved=0>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 13 Aug 2019 21:06:27 +0200

Hi Linda,

> note: the BGP for SDWAN Edges is running at different layers than the BGP
for underlay networks, i.e. not “FLAT” BGP

So I was under impression that you are to discover the interested SDWAN
peers with this extension - well apparently not if what you are defining is
an overlay BGP.

But then if you have to discover the peers dynamically in some other way
prior to establishing said BGP sessions - why not to add this information
as part of auto discovery mechanism ?

Many thx,
R.

On Tue, Aug 13, 2019 at 8:07 PM Linda Dunbar <[email-masked]>
wrote:

> Robert,
>
>
>
> Thanks for the quick feedback. It is interesting that you mentioned LISP,
> I had “LISP” listed as the 4th option in my first version of the analysis,
> then decided to remove it because the discussion is in IDR group.
> Legitimate question on WHY BGP?
>
>
>
> In addition to looking into your suggested “out of box thinking” that BGP
> carrying some short reference the actual information should be kept outside
> of it in one of the new global databases,  here are some of the Compelling
> reasons of using BGP to distribute SDWAN edge properties among peers that
> might be spread across the globe:
>
> (note: the BGP for SDWAN Edges is running at different layers than the BGP
> for underlay networks, i.e. not “FLAT” BGP. They are among SDWAN edges, not
> for exposing to underlay provider as you stated EBGP. When the underlay
> network service providers use SDWAN to temporarily expand bandwidth in some
> segments, they have more reason to use BGP to minimize amount of learning &
> configuration of introducing new protocols in their environment)
>
>
>
>    - BGP already widely deployed as sole protocol (see RFC 7938). Even if
>       not for this purpose of propagating SDWAN WAN port properties, the BGP base
>       protocol implementation is supported by virtually all switches/routers
>       (virtual & physical).  Even AWS VPC export the BGP routes.
>       - Wide acceptance – minimal learning (which is very important
>       requirement for operations)
>       - Robust and simple implementation,
>       - Reliable transport
>       - Guaranteed in-order delivery
>       - Incremental updates
>       - No flooding and selective filtering
>       - RR already has the capability to apply policies to communications
>       among peers.
>
>    - In addition to more proposal changes needed, NHRP/DSVPN/DMVPN don’t
>       scale well.
>       - More learning, more barrier to be deployed, just think how many
>       decades of painful journey deploying IPv6.
>       -
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* Tuesday, August 13, 2019 3:16 AM
> *To:* Linda Dunbar <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Idr] Solicit feedback to BGP UPDATE encoding options for
> SDWAN WAN port properties propagation among SDWAN edges (pros & cons to
> My suggestion here is to think outside of the box and while BGP could
> carry some short reference the actual information should be kept outside of
> it in one of the new global databases. See today I operate a global SDWAN
> and it works just fine when my controller is distributed in AWS cloud.
>
>
>
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1dcce2de7b98451f28ac08d71fc68923%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012809899266710&sdata=pOfkTPzzGqHfcukg6Oz5gtcNmFNPnd5D73H76OTEr5E%3D&reserved=0>
>
>
>
>    - New NLRI is introduced, the update messages can’t traverse existing
>       routers
>
>
>    - Since the the Tunnel UPDATE message with the new SDWAN NLRI/SAFI is
> <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C1dcce2de7b98451f28ac08d71fc68923%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012809899266710&sdata=t%2B11tSNemH%2FSteHUL%2FefOgSi1WB8QPfvKxocxbcnkBE%3D&reserved=0>
>
>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Aug 2019 19:50:59 +0000

Robert,

We have been using modified NHRP for the auto discovery for peer’s WAN port properties. But NHRP doesn’t scale well (beyond 100 nodes).

Linda

From: Robert Raszuk <[email-masked]>
Sent: Tuesday, August 13, 2019 2:06 PM
To: Linda Dunbar <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

Hi Linda,

> note: the BGP for SDWAN Edges is running at different layers than the BGP for underlay networks, i.e. not “FLAT” BGP

So I was under impression that you are to discover the interested SDWAN peers with this extension - well apparently not if what you are defining is an overlay BGP.

But then if you have to discover the peers dynamically in some other way prior to establishing said BGP sessions - why not to add this information as part of auto discovery mechanism ?

Many thx,
R.

On Tue, Aug 13, 2019 at 8:07 PM Linda Dunbar <[email-masked]<mailto:[email-masked]>> wrote:
Robert,

Linda

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 13, 2019 3:16 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

Hi Linda,

Many thx,
R.

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page: https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7092d1c4992a4d66cb5608d720215f72%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637013200028894654&sdata=HkoRuXrUSqHe2yAZ7KQMBVne19jI8Xax%2FO%2FKCs%2FK13I%3D&reserved=0>

  *   Pros:

  *   Cons:

  *   Pros:

  *   Cons:

  *   Pros:

  *   Cons:

Thank you very much
Linda Dunbar
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Clinda.dunbar%40futurewei.com%7C7092d1c4992a4d66cb5608d720215f72%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637013200028894654&sdata=ftinztVeWaMOm%2Fqq%2B8OPZzJ%2BhldNadPfyih9k7XhxjM%3D&reserved=0>

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Aug 2019 19:58:06 +0000

Hai Bo,

Thank you very much expressing the opinion.

Linda

From: Wanghaibo (Rainsword) <[email-masked]>
Sent: Tuesday, August 13, 2019 2:52 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: RE: Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

Hi Linda,

Regards,
Haibo

From: Idr [mailto:[email-masked]] On Behalf Of Linda Dunbar
Sent: Tuesday, August 13, 2019 6:19 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

IDR participants:

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page: https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce76da2f496794f4e351b08d71fc32ef3%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637012795493805809&sdata=5OOslEWtsLIAQhgDzaPxv5mm16VYH0YxX076Itet4VY%3D&reserved=0>

  *   Pros:

  *   Pros:

  *   Pros:

Thank you very much
Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Aug 2019 20:01:18 +0000

Robert

Yes, it is “Overlay BGP”. Thank you very much for suggesting the name. I will incorporate it into the draft.

Linda

Hi Linda,

Many thx,
R.

Linda

Hi Linda,

Many thx,
R.

  *   Pros:

  *   Cons:

  *   Pros:

  *   Cons:

  *   Pros:

  *   Cons:

Thank you very much
Linda Dunbar

---

From: Linda Dunbar <[email-masked]>
Date: Tue, 13 Aug 2019 20:50:30 +0000

Aijun,

Answers to your questions are inserted below:

From: Aijun Wang <[email-masked]>
Sent: Tuesday, August 13, 2019 3:37 AM
To: Linda Dunbar <[email-masked]>; [email-masked]
Subject: 答复: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

Hi, Linda:

  1.  What extra work will the RR do in Option 1? In my understanding, RR just send these updates to other ends. Only the other end needs to process these extended updates.

[Linda] RR will also receive the BGP UPDATE messages for the client routes attached to the SDWAN edge such as the regular IPv4/IPv6 SAFI/NLRI, EVPN SAFI/NLRI, etc.

If the WAN Port related information are advertised using the regular IPv4/IPv6 SAFI/NLRI, the RR must dig in deeper the received UPDATE to discover that the received UPDATE is actually for the edge WAN PORT properties (such as NAT properties). When a different address family identifier is used for SDWAN WAN properties propagation, the implementation on the receiver (i.e. RR) is clearer and less prone for route leaking or improper handling.

That is why the BGP-LS, FlowSpec, Segment Routing Policies all have different SAFI/NLRI.

  1.  NAT transverse procedures for the communication between CPEs is complex, considering there are many different type NAT devices located within the network.  There is no easy way to detect the NAT type between them(It’s maybe easier to infer such information between CPE and RR). Then is it necessary to transfer the NAT related information in Option 2?

[Linda] What you said further proves that it is necessary for SDWAN edge node to advertise its NAT property (which is specified in the Extended Sub-TLV of draft-dunbar-idr-sdwan-port-safi).  A SDWAN edge node can inquire STUN (Session Traversal of UDP Through Network Address Translation RFC 3489) Server to get the NAT property, the public IP address and the Public Port number to pass to peers via RR.

  1.  Is it more flexible to make the IPsec encapsulation information associated with other tunnel types that defined in https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-tunnel-encaps%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a584462e164a9cdc7108d71fc967f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637012822256265775&sdata=Xb2UloigBCKdxLsPaSdWNzN9mATUzTy7qjLo7q4VFLw%3D&reserved=0>?, which is under the existing AFI/SAFI.  If so, option 1 seems more acceptable?

[Linda] as explained in the answer to your #1, it is cleaner implementation to have a different address family identifier for advertising WAN port properties. Yes, we should still use the TUNNEL-encap to carry the extended IPsec information.

Linda

Best Regards.

Aijun Wang
China Telecom

发件人: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] 代表 Linda Dunbar
发送时间: 2019年8月13日 6:19
收件人: [email-masked]<mailto:[email-masked]>
主题: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

IDR participants:

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page: https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a584462e164a9cdc7108d71fc967f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637012822256275769&sdata=%2BtMlJi7kO%2FT5TCvG%2BjrhswkJqrEkM64Lvn%2B0iAJEogY%3D&reserved=0>

  *   Pros:

  *   Pros:

  *   Pros:

Thank you very much
Linda Dunbar

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 15 Aug 2019 16:08:41 +0800

Hi, Linda:

Will the RR act as STUN/TURN server and the CE follow the ICE procedure?

If so, it will be appropriate to define new AFI/SAFI, but the related BGP extensions will be complex, and I do not know whether IDR is the appropriate group to accomplish such work?

If not, the RR doesn’t need to dig into the update BGP message. It just needs to relay it to other endpoint.  

And if not, how you make sure the CEs that located behind NAT can communicate with each other successfully? Only sending the port properties information isn’t enough.

Best Regards.

Aijun Wang

China Telecom

发件人: Linda Dunbar [mailto:[email-masked]] 
发送时间: 2019年8月14日 4:51
收件人: Aijun Wang; [email-masked]
主题: RE: [Idr] Solicit feedback to BGP UPDATE encoding options for SDWAN WAN port properties propagation among SDWAN edges (pros & cons to draft-dunbar-idr-sdwan-port-safi and alternatives)

Aijun, 

Hi, Linda:

 

2.	NAT transverse procedures for the communication between CPEs is complex, considering there are many different type NAT devices located within the network.  There is no easy way to detect the NAT type between them(It’s maybe easier to infer such information between CPE and RR). Then is it necessary to transfer the NAT related information in Option 2?

3.	Is it more flexible to make the IPsec encapsulation information associated with other tunnel types that defined in https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/ <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-idr-tunnel-encaps%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a584462e164a9cdc7108d71fc967f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637012822256265775&sdata=Xb2UloigBCKdxLsPaSdWNzN9mATUzTy7qjLo7q4VFLw%3D&reserved=0> ?, which is under the existing AFI/SAFI.  If so, option 1 seems more acceptable?

Linda 

Best Regards.

Aijun Wang

China Telecom 

IDR participants:

Many thanks to the feedback from IETF105 discussion on draft-dunbar-idr-sdwan-port-safi, especially the hallway discussions with Ali Sajassi, John Drake, Keyur Patel and Sue Hares on other possible encoding options. I put together an analysis of multiple BGP UPDATE encoding options to achieve SDWAN WAN port properties propagation among SDWAN edges. Please see the slides in the IDR WIKI page:  <https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.ietf.org%2Ftrac%2Fidr%2Fattachment%2Fwiki%2FWikiStart%2F&data=02%7C01%7Clinda.dunbar%40futurewei.com%7Ce5a584462e164a9cdc7108d71fc967f0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637012822256275769&sdata=%2BtMlJi7kO%2FT5TCvG%2BjrhswkJqrEkM64Lvn%2B0iAJEogY%3D&reserved=0> https://trac.ietf.org/trac/idr/attachment/wiki/WikiStart/

 

 

*	Pros:

*	Cons:

 

*	Pros:

*	Cons:

 

*	Pros:

*	Cons:

 

Thank you very much 

Linda Dunbar