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

+1 to Ketan’s and Robert’s points and I don’t believe this document in its current form should be adopted.

One of the reason LS has been well adopted is for it to serve the targeted purpose of discovery of Topology and services. Let’s keep it simple! (Please).

Cheers,

Gaurav
LinkedIn 

Sent from my iPhone

> On May 7, 2019, at 9:01 PM, Ketan Talaulikar (ketant) <ketant@cisco.com> wrote:
> 
> +1
>  
> Leaving aside for a moment the practicality/benefit of such use of BGP, let us at least not give the wrong impression that this is yet another BGP-LS extension draft. This provisioning use-case is fundamentally different from what BGP-LS was intended for and how it is handled by BGP Speakers today.
>  
> Thanks,
> Ketan
>  
> From: Idr <idr-bounces@ietf.org> On Behalf Of Robert Raszuk
> Sent: 08 May 2019 07:57
> To: Acee Lindem (acee) <acee@cisco.com>
> Cc: idr@ietf.org; 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>; Susan Hares <shares@ndzh.com>
> Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call
>  
> Acee,
>  
> > I agree that it is possible to use BGP-LS to provision these SIDs spaces.
>  
> A lot of things is possible - but it does not make it automatically a good idea. 
>  
> For this discussion can we at least rename the feature to BGP-PT (BGP-Provisioning Tool) to at very min reflect the intent. And yes get new SAFI for it ... why not. 
>  
> Best regards,
> R.
>  
>  
> On Tue, May 7, 2019 at 10:03 AM Acee Lindem (acee) <acee@cisco.com> wrote:
> Hi Robin, Huaimo,
>  
> I agree that it is possible to use BGP-LS to provision these SIDs spaces. In the case of the Flow-Spec and SR TE Policy Address Families, these AFs were conceived for the purpose of dynamic provisioning. Now, if we are going to expand the original purpose of BGP-LS to include provisioning, we should have some compelling technical reasons to repurpose it. One reason not to do it is that it adds yet another source of truth for configuration.  With each source one adds more complexity to the implementations.
>  
> As Ketan commented, you will need to define the life the SID allocation relative to both the BGP-LS session and the network device state. For example, is it ephemeral similar to the I2RS data store? You could reference Sue’s presentation on the preference of Flow-Spec data from multiple sources as a good example.
>  
> Thanks,
> Acee
>  
>  
> From: Idr <idr-bounces@ietf.org> on behalf of Robin Li <lizhenbin@huawei.com>
> Date: Sunday, May 5, 2019 at 9:37 PM
> To: li zhenqiang <li_zhenqiang@hotmail.com>, Susan Hares <shares@ndzh.com>, IDR List <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 Zhenqiang,
> Please refer to my reply inline.
>  
> Best Regards,
> Zhenbin (Robin)
>  
> From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of li zhenqiang
> Sent: Wednesday, April 24, 2019 3:51 PM
> To: Susan Hares <shares@ndzh.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 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.
> [Robin]
> 1. To be honest, there is much concern about the standardization process, inter-operability, performance on Netconf/YANG. It is necessary to think about the other option. Just like topology collection, there existed the way to use SNMP/MIB or Netconf/YANG to collect topology info from the network, later BGP-LS was proposed.
> 2. There is already PCE work to allocate SID in the centralized way (Refer to PCECC work proposed by https://tools.ietf.org/html/draft-ietf-teas-pcecc-use-cases-02) But there truly exists the BGP-only scenarios. It is difficult to introduce one more control protocol which may increase the complexity of network operation and maintenance. That is the reason why we introduced the BGP extension to allocate SID which also can reduce the possible complexity.
> 3. For the possible methods of BGP extensions for the purpose, there can be other way such as introducing a new AFI/SAFI, etc. But we think the BGP-LS extension may be the easiest way. Since BGP-LS can collect info of all kinds of SIDs from the network devices to the controller, it is only to define a TLV/Sub-TLV to indicate the SID allocation from the controller to the network devices. All the existing TLV/Sub-TLV using by BGP-LS will be reused without any change. If use other ways, there has to define some new TLVs/Sub-TLVs or the transition from the corresponding BGP-LS TLV/Sub-TLVs to the new TLVs/Sub-TLVs. But the option is open. We would like to solicit comments from BGPers.
>  
>  
>  
>  
> Best Regards,
> Zhenqiang Li
> li_zhenqiang@hotmail.com
>  
> From: Susan Hares
> 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.
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr