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

["Ketan Talaulikar (ketant)" <[e-mail]>]

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.


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


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


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


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


  1.  Do you know of any early implementations?
No.


Thanks,
Ketan

From: Idr <[e-mail]> On Behalf Of Susan Hares
Sent: 24 April 2019 19:54
To: 'li zhenqiang' <[e-mail]>; [e-mail]
Cc: 'draft-ietf-teas-enhanced-vpn' <[e-mail]>; 'draft-dong-lsr-sr-enhanced-vpn' <[e-mail]>
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:[e-mail]] On Behalf Of li zhenqiang
Sent: Wednesday, April 24, 2019 3:51 AM
To: Susan Hares; [e-mail]<mailto:[e-mail]>
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
________________________________
[e-mail]<mailto:[e-mail]>

From: Susan Hares<mailto:[e-mail]>
Date: 2019-04-18 22:04
To: [e-mail]<mailto:[e-mail]>
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.