[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] 答复: 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)
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
- [Idr] Solicit feedback to BGP UPDATE encoding opt… Linda Dunbar
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Wanghaibo (Rainsword)
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Robert Raszuk
- [Idr] 答复: Solicit feedback to BGP UPDATE encoding… Aijun Wang
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Linda Dunbar
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Robert Raszuk
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Linda Dunbar
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Linda Dunbar
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Linda Dunbar
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Linda Dunbar
- [Idr] 答复: Solicit feedback to BGP UPDATE encoding… Aijun Wang
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Linda Dunbar
- Re: [Idr] Solicit feedback to BGP UPDATE encoding… Wanghaibo (Rainsword)