Re: [spring] Limited domains ...

"徐小虎(义先)" <xiaohu.xxh@alibaba-inc.com> Thu, 28 May 2020 01:12 UTC

Return-Path: <xiaohu.xxh@alibaba-inc.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 576B03A086A; Wed, 27 May 2020 18:12:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com
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 9qnPLEKAcL9a; Wed, 27 May 2020 18:12:42 -0700 (PDT)
Received: from out0-146.mail.aliyun.com (out0-146.mail.aliyun.com [140.205.0.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F133A0841; Wed, 27 May 2020 18:12:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1590628359; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=gFtYluHB8sQLcRCLKKSgWIabkga2bG3tPT02y13jIjs=; b=GRPGs9p7tV2qaql78JsJLGs2WNG0sjjgt9dy+pfJX/tl4GTlh6aCtMCZ1PK1nm3+JOgW0x8QicAOD9r4RsBxZck1UV3k6vn4Sr/C4p/IxkVaSQKAcQb4iFFSrLlXLb/o1awfpwfcT07JwylEOnZb1mwrQE5+SAdXZ8X9aEytI/Y=
X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R191e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03293; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=7; SR=0; TI=W4_5899425_v5ForWebDing_0A93269B_1590627739235_o7001c45h;
Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5899425_v5ForWebDing_0A93269B_1590627739235_o7001c45h]) by e02c03273.eu6 at Thu, 28 May 2020 09:12:37 +0800
Date: Thu, 28 May 2020 09:12:37 +0800
From: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" <xiaohu.xxh@alibaba-inc.com>
To: "spring" <spring-bounces@ietf.org>, "=?UTF-8?B?WmFmYXIgQWxpICh6YWxpKQ==?=" <zali@cisco.com>
Cc: "Ron Bonica" <rbonica=40juniper.net@dmarc.ietf.org>, "spring@ietf.org" <spring@ietf.org>, "6man" <6man@ietf.org>, "Brian E Carpenter" <brian.e.carpenter@gmail.com>, "Andrew Alston" <Andrew.Alston@liquidtelecom.com>
Reply-To: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" <xiaohu.xxh@alibaba-inc.com>
Message-ID: <969f8ab1-e57d-4c75-acae-6ab28e18484f.xiaohu.xxh@alibaba-inc.com>
Subject: =?UTF-8?B?UmU6IFtzcHJpbmddIExpbWl0ZWQgZG9tYWlucyAuLi4=?=
X-Mailer: [Alimail-Mailagent revision 4][W4_5899425][v5ForWebDing][Safari]
MIME-Version: 1.0
References: <75BF2317-5D28-4038-ABB1-31C588ACD165@cisco.com> <DM6PR05MB6348D86E8BE339067C5238E4AEB10@DM6PR05MB6348.namprd05.prod.outlook.com> <30C37AC0-B03A-45B1-BE0F-7E185361BBBC@liquidtelecom.com> <CAOj+MME+kkfTKFQaS1zvW7wgQvLqui6jFQH9-eai6eY32t9fmQ@mail.gmail.com> <b8cd530c-e07b-f74f-0f58-43414441b6ef@gmail.com> <1E239000-24BD-4E8A-A0D0-6876CE666137@cisco.com>, <CAOj+MMFCYoHD4hdXvVtfWUup3vbPBi5M-=mWUWHsm_d9RXpybg@mail.gmail.com>
x-aliyun-mail-creator: W4_5899425_v5ForWebDing_NjATW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA1LjEuMTUgKEtIVE1MLCBsaWtlIEdlY2tvKSBWZXJzaW9uLzEyLjAuMyBTYWZhcmkvNjA1LjEuMTU=XQ
In-Reply-To: <CAOj+MMFCYoHD4hdXvVtfWUup3vbPBi5M-=mWUWHsm_d9RXpybg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_33346_50bf5940_5ecf1005_bf4349"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DO7vjFk2XVTsL-wQux6S2JS5jBo>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2020 01:12:53 -0000

It makes sense of using source routing across the Internet. For example, using source routing for traffic steering across edge networks just like Akamai's SureRoute which is a limited domain over the Internet indeed. In that case, it's necessary to protect the source route information carried within packets by some means (e.g., indirection), in other words, it'd better not to directly carry the source routes in the form of an IP address list within the source routed packets. BTW, it may be worthwhile to consider the scenario where the source routed packets need to traverse both IPv4 and IPv6 Internet along the path towards their final destinations.

Of course, whether using CRH or RFC8663 is purely a matter of personal preference from my point of view, just like someone prefers to use VXLAN rather than MPLS-over-UDP (http://tools.ietf.org/html/rfc7510) for network virtualization, and someone prefers to use EVPN rather than Virtual Subnet (https://tools.ietf.org/html/rfc7814) which is fully built on the mature MPLS/BGP L3VPN (https://tools.ietf.org/html/rfc4364) for pure Layer3-based overlays. 

Best regards,
Xiaohu





------------------------------------------------------------------
From:Robert Raszuk <robert@raszuk.net>
Send Time:2020年5月28日(星期四) 06:40
To:Zafar Ali (zali) <zali@cisco.com>
Cc:Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org>rg>; spring@ietf.org <spring@ietf.org>rg>; 6man <6man@ietf.org>rg>; Brian E Carpenter <brian.e.carpenter@gmail.com>om>; Andrew Alston <Andrew.Alston@liquidtelecom.com>
Subject:[spring] Limited domains ...

/*adjusting subject */

> The scope of CRH is “limited domain” and not the “Internet”.  

Well that is only what the document under adoption call says. 

However we have all seen described use cases over Internet  ... so much of limited domain. Explanation given is that "limited domain" does not to be continuous ... very clever indeed ! 

I am observing this point as my use case is also over Internet. 

So if I apply any RH on my application host_1 carry it over Internet to my server host_2 clearly those two hosts create a "limited domain". 

Maybe we should just drop right here this "limited domain" restriction/scope for any solution being discussed here ? 

Thx,
R.

On Thu, May 28, 2020 at 12:32 AM Zafar Ali (zali) <zali@cisco.com> wrote:
Hi, 
 
The authors of CRH has already have multiple drafts and more CP/ DP changes will be required. E.g., it will require 
ISIS changes (draft-bonica-lsr-crh-isis-extensions)
To carry VPN information (draft-bonica-6man-vpn-dest-opt) 
For SFC (draft-bonica-6man-seg-end-opt)
BGP changes (draft-alston-spring-crh-bgp-signalling, draft-ssangli-idr-bgp-vpn-srv6-plus)
PCEP extension (TBA)
OAM for debugging the mapping table
Yang interface 
More to come  
 
The scope of CRH is “limited domain” and not the “Internet”. 
 
Given this, where the IETF community discuss how these so-called “building blocks” fits together? 
 
If author’s claim is that the home for the architecture work is not Spring, then the authors should create a BoF in routing area to first defined architecture, use-case and requirements. 
This is the hard worked everyone else did before the CRH authors. 
Why they are looking for a short cut? 
 
CRH is a “major” change and outside the scope of 6man charter. 
It should follow the proper IETF review process. 
 
Why CRH authors are trying to “skip the queue” and “skip the routing area”? 
 
Thanks
 
Regards … Zafar