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

[Huaimo Chen <[e-mail]>]

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]<mailto:[e-mail]>>
Sent: 06 May 2019 20:35
To: Ketan Talaulikar (ketant) <[e-mail]<mailto:[e-mail]>>; Susan Hares <[e-mail]<mailto:[e-mail]>>; 'li zhenqiang' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'draft-ietf-teas-enhanced-vpn' <[e-mail]<mailto:[e-mail]>>; 'draft-dong-lsr-sr-enhanced-vpn' <[e-mail]<mailto:[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]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, April 24, 2019 11:46 AM
To: Susan Hares <[e-mail]<mailto:[e-mail]>>; 'li zhenqiang' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'draft-ietf-teas-enhanced-vpn' <[e-mail]<mailto:[e-mail]>>; 'draft-dong-lsr-sr-enhanced-vpn' <[e-mail]<mailto:[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]<mailto:[e-mail]>> On Behalf Of Susan Hares
Sent: 24 April 2019 19:54
To: 'li zhenqiang' <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: 'draft-ietf-teas-enhanced-vpn' <[e-mail]<mailto:[e-mail]>>; 'draft-dong-lsr-sr-enhanced-vpn' <[e-mail]<mailto:[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.