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

Hi Huaimo,

> draft-wu-idr-bgp-segment-allocation-ext supports to send the instructions
about SIDs to network nodes from controllers.

How do you know that the node accepts such SID?  How do you know there is
no SID conflict ? How do you remove allocated SIDs (I assume by sending
your new NLRIs in MP_UNREACH - but this is nowhere stated in the draft) etc
...

BGP is the worst mechanism for config push I can think of.

Just use any other freely available tools say as example - ansible or chef
and you will be much better off with such level of network automation. In
your DC use case such tools are already heavily used so it will make it
even more consistent with existing DC operation.

Best,
R.


On Fri, May 10, 2019 at 5:58 AM Huaimo Chen <[e-mail]> wrote:

> Hi Ketan,
>
>
>
> Thank you for your comments.
>
> My explanations are inline below with prefix [HC2].
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Ketan Talaulikar (ketant) [mailto:[e-mail]]
> *Sent:* Tuesday, May 7, 2019 4:16 AM
> *To:* Huaimo Chen <[e-mail]>; Susan Hares <[e-mail]>;
> '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
>
>
>
> Hi Huaimo,
>
>
>
> Please check inline below for my responses.
>
>
>
> *From:* Huaimo Chen <[e-mail]>
> *Sent:* 06 May 2019 20:35
> *To:* Ketan Talaulikar (ketant) <[e-mail]>; Susan Hares <
> [e-mail]>; '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
>
>
>
> Hi Ketan,
>
>
>
> Thank you for your comments.
>
> My answers/explanations are inline below with prefix [HC].
>
>
>
> Best Regards,
>
> Huaimo
>
> *From:* Idr [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* Wednesday, April 24, 2019 11:46 AM
> *To:* Susan Hares <[e-mail]>; '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
>
>
>
> 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
>
> *[KT] I have just responded to that.*
>
>
>
> 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.
>
> *[KT] It is not. SR Policies are signalled based on various triggers from
> controllers – they are in that sense dynamic and changing. Also, it is
> being done by a separate AFI/SAFI in BGP – not BGP-LS.*
>
> [HC2]: In the sense of sending instructions to network nodes from
> controllers, they should be the same or similar.
> draft-ietf-idr-segment-routing-te-policy uses a separate AFI/SAFI.
> draft-wu-idr-bgp-segment-allocation-ext can be easily changed to use a new
> AFI/SAFI.
>
>
>
> 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.
>
> *[KT] SRGB and SIDs are fundamental for enabling SR on the nodes in the
> network. Most of these are day 0 provisioning when bringing/up and enabled
> SR. e.g. when you provision a loopback interface, you assign a SR Node SID
> to it. This is not same as SR Policies.*
>
> [HC2]: In the sense of sending instructions to network nodes from
> controllers, they should be the same or similar. In case of
> draft-ietf-idr-segment-routing-te-policy, the  instructions for SR
> tunnels/paths may be sent to network nodes from controllers. In case of
> draft-wu-idr-bgp-segment-allocation-ext, the instructions for SIDs may be
> sent to network nodes from controllers.
>
>
>
> 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.
>
> *[KT] If that is the argument for this draft, then please describe and
> discuss how you propose to answer the technical response to my arguments
> above (highlighted in red this time).*
>
> [HC2]: draft-ietf-idr-segment-routing-te-policy supports to send the
> instructions about SR tunnels/paths to network nodes from controllers.
> draft-wu-idr-bgp-segment-allocation-ext supports to send the instructions
> about SIDs to network nodes from controllers. Regarding to other
> mechanisms, draft-ietf-idr-segment-routing-te-policy provides an
> alternative way in which the instructions about SR tunnels/paths are sent
> to network nodes from controllers, draft-wu-idr-bgp-segment-allocation-ext
> proposes an alternative way in which the instructions about SIDs are sent
> to network nodes from controllers. Some users may like the alternative ways
> in some cases.
>
>
>
> 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.
>
> *[KT] This is not just about adding TLVs and distributing them via BGP-LS.
> If DC network is your primary use-case, then please describe in more
> details. E.g. what happens to the provisioning done on the network node
> when the BGP-LS session flaps?*
>
> [HC2]: DC network is one use case. When a BGP session flaps, a normal BGP
> procedure should follow.
>
>
>
> *Thanks,*
>
> *Ketan*
>
>
>
> 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 <[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] <[e-mail]>] *On
> Behalf Of *li zhenqiang
> *Sent:* Wednesday, April 24, 2019 3:51 AM
> *To:* Susan Hares; [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]
>
>
>
> *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
>