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

"Susan Hares" <shares@ndzh.com> Fri, 26 April 2019 13:00 UTC

Return-Path: <shares@ndzh.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 D8B10120183; Fri, 26 Apr 2019 06:00:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.947
X-Spam-Level:
X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 6x_dvvgz8SUw; Fri, 26 Apr 2019 06:00:35 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AAD5120147; Fri, 26 Apr 2019 06:00:34 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72;
From: Susan Hares <shares@ndzh.com>
To: "'Ketan Talaulikar (ketant)'" <ketant@cisco.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>
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>
Date: Fri, 26 Apr 2019 09:00:23 -0400
Message-ID: <01e701d4fc30$032679f0$09736dd0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E8_01D4FC0E.7C174AF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQCo3XkoQTpnez42PLUrnLEMTDc8HgHT6zliAWS4mqwBkqXsA6iASo1g
Content-Language: en-us
X-Antivirus: AVG (VPS 190426-0, 04/26/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/W-PPlXlpsZ3LTXfrZb5_OGplpks>
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: Fri, 26 Apr 2019 13:00:38 -0000

Ketant: 

 

Thank you for the thoughtful reply.   I hope the authors reply to you regarding your comments during the adoption call. 

 

Sue Hares

 

From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] 
Sent: Wednesday, April 24, 2019 11:46 AM
To: Susan Hares; 'li zhenqiang'; 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/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.

 

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.

 

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> On Behalf Of Susan Hares
Sent: 24 April 2019 19:54
To: '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

 

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

 

From: Susan Hares <mailto:shares@ndzh.com> 

Date: 2019-04-18 22:04

To: 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.