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

[Robert Raszuk <[e-mail]>]

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) <[e-mail]> 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 <[e-mail]> on behalf of Robin Li <
> [e-mail]>
> *Date: *Sunday, May 5, 2019 at 9:37 PM
> *To: *li zhenqiang <[e-mail]>, Susan Hares <
> [e-mail]>, IDR List <[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
>
>
>
> Hi Zhenqiang,
>
> Please refer to my reply inline.
>
>
>
> Best Regards,
>
> Zhenbin (Robin)
>
>
>
> *From:* Idr [mailto:[e-mail]] *On Behalf Of *li zhenqiang
> *Sent:* Wednesday, April 24, 2019 3:51 PM
> *To:* Susan Hares <[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
>
>
>
> 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
> ------------------------------
>
> [e-mail]
>
>
>
> *From:* Susan Hares <[e-mail]>
>
> *Date:* 2019-04-18 22:04
>
> *To:* [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.
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>