Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Huaimo Chen <huaimo.chen@huawei.com> Mon, 06 May 2019 15:05 UTC

Return-Path: <huaimo.chen@huawei.com>
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 9899D12006D; Mon, 6 May 2019 08:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 SWib3O85ohX0; Mon, 6 May 2019 08:05:21 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 58D9D12018E; Mon, 6 May 2019 08:05:21 -0700 (PDT)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 6A0616051D31B6A795BE; Mon, 6 May 2019 16:05:19 +0100 (IST)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 6 May 2019 16:05:18 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.119]) by SJCEML702-CHM.china.huawei.com ([169.254.4.150]) with mapi id 14.03.0439.000; Mon, 6 May 2019 08:05:15 -0700
From: Huaimo Chen <huaimo.chen@huawei.com>
To: "Ketan Talaulikar (ketant)" <ketant@cisco.com>, Susan Hares <shares@ndzh.com>, 'li zhenqiang' <li_zhenqiang@hotmail.com>, "idr@ietf.org" <idr@ietf.org>
CC: 'draft-ietf-teas-enhanced-vpn' <draft-ietf-teas-enhanced-vpn@ietf.org>, 'draft-dong-lsr-sr-enhanced-vpn' <draft-dong-lsr-sr-enhanced-vpn@ietf.org>
Thread-Topic: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
Thread-Index: AdT17jAMyz+sjMM6SRqyoxzf6xKAMQE9cjIAAALgRYACSoCCcA==
Date: Mon, 06 May 2019 15:05:14 +0000
Message-ID: <5316A0AB3C851246A7CA5758973207D463BA96C8@sjceml521-mbx.china.huawei.com>
References: <013301d4f5ef$b1b51310$151f3930$@ndzh.com> <HK0PR06MB2564F6AA8D6EAC625A9B4698FC3C0@HK0PR06MB2564.apcprd06.prod.outlook.com> <025301d4faa9$4d6308e0$e8291aa0$@ndzh.com> <SN6PR11MB28456A80F88A032C7B3D3966C13C0@SN6PR11MB2845.namprd11.prod.outlook.com>
In-Reply-To: <SN6PR11MB28456A80F88A032C7B3D3966C13C0@SN6PR11MB2845.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.244.193]
Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463BA96C8sjceml521mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/A6632LrsrW7b-s-C__GTEEA5fak>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
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: Mon, 06 May 2019 15:05:26 -0000

Hi Ketan,

Thank you for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo
From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, April 24, 2019 11:46 AM
To: Susan Hares <shares@ndzh.com>; 'li zhenqiang' <li_zhenqiang@hotmail.com>; idr@ietf.org
Cc: 'draft-ietf-teas-enhanced-vpn' <draft-ietf-teas-enhanced-vpn@ietf.org>; 'draft-dong-lsr-sr-enhanced-vpn' <draft-dong-lsr-sr-enhanced-vpn@ietf.org>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Sue/All,

I concur with Zhengquiang on the point that this draft proposes extension to BGP-LS which alters the basic purpose of BGP-LS as stated in RFC7752. BGP-LS is about reporting topology and related information from the network – the advertisements originating from routers/BGP Speakers and being used by BGP-LS consumer applications (e.g. controller). It has never been about using it to provision routers from controllers – at least not yet.

[HC]: Refer to the response to Zhenqiang’s email.
https://mailarchive.ietf.org/arch/msg/idr/gIMSFeL0rmNjJy-3ySd1ygyOzyo

I had expressed these concerns at the mike at the IDR meeting in Prague in the context of draft-chen-idr-bgp-srv6-sid-allocation and this draft is its equivalent for SR-MPLS. I don’t think the WG should adopt either drafts.

The WG needs to think long and hard if we want to use BGP as a provisioning tool (I am aware we are using BGP for Flowspec and SR Policies – but one can argue that those are in some sense signalling based on computation/events by controllers). Here we are talking about pure play configuration elements. We have other mechanisms being standardized at the IETF for this purpose. We need to see strong arguments how provisioning work flows (including day 0 bring up, failures, etc.) are handled and handled better via BGP as opposed to mechanisms already standardized/deployed.

[HC]: draft-wu-idr-bgp-segment-allocation-ext uses BGP to distribute the SIDs to their corresponding network elements, which is similar to draft-ietf-idr-segment-routing-te-policy “Advertising Segment Routing Policies in BGP” that uses BGP to distribute Segment Routing Policies to their corresponding network elements. As said in draft-ietf-idr-segment-routing-te-policy, there are already a number of different mechanisms, e.g., CLI, NetConf and PCEP for this purpose, it specifies a way in which BGP may be used to distribute the Segment Routing Policies. draft-wu-idr-bgp-segment-allocation-ext describes a way in which BGP may be used to distribute the SIDs.
I do not think that draft-wu-idr-bgp-segment-allocation-ext and draft-ietf-idr-segment-routing-te-policy want to use BGP as a pure configuration tools. draft-wu-idr-bgp-segment-allocation-ext uses BGP and some advantages of BGP to make segment routing easier to operate and maintain. For example, in a network using BGP, the operators of the network with segment routing may not need to deploy, operate and maintain PCEP (another protocol) for sending the SIDs to the network elements from the centralized controller. Thus using fewer protocols in a network may make the OAM on the network easier.
It may also make the segment routing applicable to more networks. In a network (such as a DC network) running BGP as the only routing protocol, there is not any IGP (OSPF or IS-IS) running on any router of the network to distribute the SIDs in the network. It may be hard to deploy or use segment routing in this network. When BGP is extended to distribute the SIDs to their corresponding network elements or routers, it may be easy for us to deploy and use the segment routing in this network. For example, for a node SID allocated for a router by the centralized controller, the node SID can be easily distributed to all the routers in the network through BGP’s RR function. Thus, the segment routing can be easily applicable to a network with only BGP but without IGP.

1)    Does this draft mechanisms for  extending BGP-LS to provide IDs for allocation provide a beneficial addition to BGP mechanisms for segment routing?
No. SID, SRGB and related SR configuration elements are crucial for SR operations and have yang models defined for the same. Many of these are initial and one-time kind of config objects at router bring up. They are not suitable for BGP and even more so not for BGP-LS.

2)    Is the mechanism well-formed enough to adopted as a WG draft?
No.

3)    Do you see any problems with using these IDs for flow redirection?
The flowspec aspect is separate and can be covered in a different draft. I don’t see the relation to SR SRGB and SID provisioning.

4)    Do you support extending BGP-LS?
No. Not for this since it is attempting to take BGP-LS in a direction which was not what it was intended for.

5)    Should we provide an early allocation for this technology?
No.

6)    Do you know of any early implementations?
No.


Thanks,
Ketan

From: Idr <idr-bounces@ietf.org<mailto:idr-bounces@ietf.org>> On Behalf Of Susan Hares
Sent: 24 April 2019 19:54
To: 'li zhenqiang' <li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>>; idr@ietf.org<mailto:idr@ietf.org>
Cc: 'draft-ietf-teas-enhanced-vpn' <draft-ietf-teas-enhanced-vpn@ietf.org<mailto:draft-ietf-teas-enhanced-vpn@ietf.org>>; 'draft-dong-lsr-sr-enhanced-vpn' <draft-dong-lsr-sr-enhanced-vpn@ietf.org<mailto:draft-dong-lsr-sr-enhanced-vpn@ietf.org>>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Zhengquiang:

<wg-chair hat on>
This is a good question to raise during the adoption of an IDR draft.

I hope that the authors of the draft and others will indicate why they desire the BGP-LS method of allocating the SIDs.  As you are aware, the NETCONF based mechanism utilize a secure transport during the allocation.  BGP SHOULD run over an authenticated transport (MD5 or better yet TLS), but all BGP peers within a network may not run over the secure transport.
<wg-chair hat off>

<wg-member hat on>
As a WG member, I realize that each network makes choices on allocating SIDs and their control path.   Some of the reasons may not be able to be disclosed on a public mailing list.  However, it would be good for the authors to provide some reasons “Why BGP-LS” for allocation.
<wg-member hat off>

Sue Hares


From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of li zhenqiang
Sent: Wednesday, April 24, 2019 3:51 AM
To: Susan Hares; idr@ietf.org<mailto:idr@ietf.org>
Cc: draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Sue and All,

Zhenqiang Li from China Mobile.

I see the value to allocate SIDs in a centralized way, especially for the SIDs representing network resources as proposed in https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/ and https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/..

However, I want to know why BGP-LS is chosen to to complete this work, not PCEP or netconf? BGP-LS is mainly used to collect information from network, other than configure network from a controller.

Best Regards,
Zhenqiang Li
________________________________
li_zhenqiang@hotmail.com<mailto:li_zhenqiang@hotmail.com>

From: Susan Hares<mailto:shares@ndzh.com>
Date: 2019-04-18 22:04
To: idr@ietf.org<mailto:idr@ietf.org>
Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
This begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocation-ext-02.txt.  You can access the draft at:

https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/

In your comments, consider:


1)      Does this draft mechanisms for  extending BGP-LS to provide IDs for allocation provide a beneficial addition to BGP mechanisms for segment routing?

2)      Is the mechanism well-formed enough to adopted as a WG draft?

3)      Do you see any problems with using these IDs for flow redirection?

4)      Do you support extending BGP-LS?

5)      Should we provide an early allocation for this technology?

6)      Do you know of any early implementations?

By answering these questions during WG Adoption call, you will help John and I determine what issues need to be considered prior to finalizing this WG draft.    Your answer will help us increase the speed of processing BGP-LS drafts.

If enough people indicate that they wish an early allocation upon adoption, I will then send this early allocation to Alvaro.

Sue Hares

PS – I’m trying new methods of WG adoption calls to help speed up the process in IDR WG.   Please send any thoughts on these new methods to me or John.