[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 Wang" <[e-mail]>]

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:[e-mail]] 
发送时间: 2019年8月14日 4:51
收件人: Aijun Wang; [e-mail]
主题: 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, 

 

Answers to your questions are inserted below: 

 

From: Aijun Wang <[e-mail]> 
Sent: Tuesday, August 13, 2019 3:37 AM
To: Linda Dunbar <[e-mail]>; [e-mail]
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:

 

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.

[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.  

 

 

 

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?

[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.

 

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] 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 

 

发件人: [e-mail] [mailto:[e-mail]] 代表 Linda Dunbar
发送时间: 2019年8月13日 6:19
收件人: [e-mail]
主题: [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://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/

 

The Goal is for WAN Ports Property Propagation across SDWAN nodes in different domains
cid:image001.png@01D55131.F341A2B0

 

 

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. 

cid:image002.png@01D55131.F341A2B0

 

*	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

cid:image003.png@01D55131.F341A2B0

 

*	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

 

cid:image004.png@01D55131.F341A2B0

 

*	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