[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" <wangaijun@tsinghua.org.cn> Tue, 13 August 2019 08:37 UTC

Return-Path: <wangaijun@tsinghua.org.cn>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1C01200C7 for <idr@ietfa.amsl.com>; Tue, 13 Aug 2019 01:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_RATIO_08=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1oJ7lsks2MY for <idr@ietfa.amsl.com>; Tue, 13 Aug 2019 01:37:02 -0700 (PDT)
Received: from m176115.mail.qiye.163.com (m176115.mail.qiye.163.com [59.111.176.115]) by ietfa.amsl.com (Postfix) with ESMTP id 153A01200B9 for <idr@ietf.org>; Tue, 13 Aug 2019 01:36:58 -0700 (PDT)
Received: from WangajPC (unknown [219.142.69.77]) by m176115.mail.qiye.163.com (Hmail) with ESMTPA id 907BC662D7B; Tue, 13 Aug 2019 16:36:48 +0800 (CST)
From: "Aijun Wang" <wangaijun@tsinghua.org.cn>
To: "'Linda Dunbar'" <linda.dunbar@futurewei.com>, <idr@ietf.org>
References: <MN2PR13MB35824E1E96BE08CDCBE8488585D30@MN2PR13MB3582.namprd13.prod.outlook.com>
In-Reply-To: <MN2PR13MB35824E1E96BE08CDCBE8488585D30@MN2PR13MB3582.namprd13.prod.outlook.com>
Date: Tue, 13 Aug 2019 16:36:49 +0800
Message-ID: <00b901d551b2$40134190$c039c4b0$@org.cn>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_00BA_01D551F5.4E368190"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdVRV+YQ5VdTuG26RVmF8buwngYjtQAS5wcg
Content-Language: zh-cn
X-HM-Spam-Status: e1kfGhgUHx5ZQUtXWQgYFAkeWUFZS1VJS0tLS0tKSUlKQ0JOSUlZV1koWU FKTEtLSjdXWS1ZQUlXWQkOFx4IWUFZNTQpNjo3JCkuNz5ZBg++
X-HM-Sender-Digest: e1kMHhlZQR0aFwgeV1kSHx4VD1lBWUc6N1E6SQw4ODlOMz8YCwwwHjQq H08KCilVSlVKTk1OTUNOT0pOTU5KVTMWGhIXVQwaFRwaEhEOFTsPCBIVHBMOGlUUCRxVGBVFWVdZ EgtZQVlJSkJVSk9JVU1CVUxMWVdZCAFZQU9JTk5MSjcG
X-HM-Tid: 0a6c8a1f639a9373kuws907bc662d7b
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6TKR7cgoqvj6ePQb-kCYUjRkEfk>
Subject: [Idr] =?gb2312?b?tPC4tDogIFNvbGljaXQgZmVlZGJhY2sgdG8gQkdQIFVQ?= =?gb2312?b?REFURSBlbmNvZGluZyBvcHRpb25zIGZvciBTRFdBTiBXQU4gcG9ydCBwcm9w?= =?gb2312?b?ZXJ0aWVzIHByb3BhZ2F0aW9uIGFtb25nIFNEV0FOIGVkZ2VzIChwcm9zICYg?= =?gb2312?b?Y29ucyB0byBkcmFmdC1kdW5iYXItaWRyLXNkd2FuLXBvcnQtc2FmaSBhbmQg?= =?gb2312?b?YWx0ZXJuYXRpdmVzKQ==?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Aug 2019 08:37:05 -0000

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 

 

发件人: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] 代表 Linda Dunbar
发送时间: 2019年8月13日 6:19
收件人: idr@ietf.org
主题: [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
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