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

From: Lizhenbin <[email-masked]>
Date: Mon, 6 May 2019 01:35:23 +0000

Hi Zhenqiang,
Please refer to my reply inline.

Best Regards,
Zhenbin (Robin)

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

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

---

From: Huaimo Chen <[email-masked]>
Date: Mon, 6 May 2019 15:05:14 +0000

Hi Ketan,

Thank you for your comments.
My answers/explanations are inline below with prefix [HC].

Best Regards,
Huaimo
From: Idr [mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, April 24, 2019 11:46 AM
To: Susan Hares <[email-masked]>; 'li zhenqiang' <[email-masked]>; [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' <[email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <[email-masked]>
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

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

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.

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.

No.

No.

Thanks,
Ketan

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

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

Best Regards,
Zhenqiang Li

Sue Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Tue, 7 May 2019 09:25:23 +0800

Hi, Robin:

Can the mechanism described in draft-ietf-idr-bgpls-segment-routing-epe solve the scenarios that you mentioned for BGP-only environment?

Under the BGP-only environment, the controller/router may know only the PeerNode, PeerAdj and PeerSet information, then it is possible to reuse these SIDs for the allocation.

Best Regards.

Aijun Wang

Network R&D and Operation Support Department

China Telecom Corporation Limited Beijing Research Institute,Beijing, China.

发件人: Lizhenbin [mailto:[email-masked]] 
发送时间: 2019年5月6日 9:35
收件人: li zhenqiang; Susan Hares; [email-masked]
抄送: draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
主题: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Zhenqiang,

Best Regards,

Zhenbin (Robin)

Hi Sue and All,

[Robin]

 

Best Regards,

Zhenqiang Li

  _____  

[email-masked]

From: Susan Hares <mailto:[email-masked]> 

Date: 2019-04-18 22:04

To: [email-masked]

Sue Hares

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 7 May 2019 09:38:15 +0800

Hi Susan and ALL,

  The Centralized control and delivery IDs mechanism is good for us to deploy the Segment Routing， especially in cross AS situation.
  As the BGP/BGP-LS has better interaction to different brand equiment than other southbound protocols, it would be an optional choise for deployment.
  I support this draft adoption. 
  Thanks.

HUANAN CHEN（陈华南）
Data Communication Research Department
Guangdong Research Institute of China Telecom Co.,Ltd.
Mail：[email-masked] 
 
From: Susan Hares
Date: 2019-04-18 22:04
To: [email-masked]

 

 
Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 7 May 2019 08:08:12 +0000

Hi Robin,

Please see inline for some comments.

From: Idr <[email-masked]> On Behalf Of Lizhenbin
Sent: 06 May 2019 07:05
To: li zhenqiang <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: draft-ietf-teas-enhanced-vpn <[email-masked]>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

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

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.
[KT] Topology by it’s very nature is dynamic and changes due to planned and unplanned network events. That presents the case to advertise it via BGP-LS. The provisioning use-case is not quite on the same lines.

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.
[KT] PCEP is a p2p connection oriented protocol with a very transactional aspects to it’s protocol interactions – BGP is not.

3. For the possible methods of BGP extensions for the purpose, there can be other way such as introducing a new AFI/SAFI, etc.
[KT] If at all BGP, then that would perhaps be the way to approach this use-case/functionality.

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.
[KT] I think this is not just about re-use of BGP-LS TLVs anymore. It is a more fundamental shift in the BGP-LS use-case. The authors of the draft need to cover all possible aspects of this interactions, failures and other scenarios to explain how BGP is going to be used for doing day 0 and day X SR provisioning.

Thanks,
Ketan

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

Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Tue, 7 May 2019 08:15:48 +0000

Hi Huaimo,

Please check inline below for my responses.

From: Huaimo Chen <[email-masked]>
Sent: 06 May 2019 20:35
To: Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; 'li zhenqiang' <[email-masked]>; [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' <[email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <[email-masked]>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Ketan,

Best Regards,
Huaimo
To: Susan Hares <[email-masked]<mailto:[email-masked]>>; 'li zhenqiang' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Sue/All,

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

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

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.

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

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?

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.

  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

Zhengquiang:

<wg-chair hat on>

<wg-member hat on>

Sue Hares

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 7 May 2019 14:02:25 +0000

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 <[email-masked]> on behalf of Robin Li <[email-masked]>
Date: Sunday, May 5, 2019 at 9:37 PM
To: li zhenqiang <[email-masked]>, Susan Hares <[email-masked]>, IDR List <[email-masked]>
Cc: draft-ietf-teas-enhanced-vpn <[email-masked]>, draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: oliverxu(许锋) <[email-masked]>
Date: Wed, 8 May 2019 00:59:29 +0000

Hi experts,

Support adoption. For yang/oc-yang, It’s too long time to wait the standardization process。

Oliver.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Thursday, April 18, 2019 10:05 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

  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?

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 7 May 2019 22:26:49 -0400

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) <[email-masked]> 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 <[email-masked]> on behalf of Robin Li <
> [email-masked]>
> *Date: *Sunday, May 5, 2019 at 9:37 PM
> *To: *li zhenqiang <[email-masked]>, Susan Hares <
> [email-masked]>, IDR List <[email-masked]>
> *Cc: *draft-ietf-teas-enhanced-vpn <[email-masked]>,
> draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
> *Subject: *Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18
> - 5/2/2019] - 2 week WG adoption call
>
>
>
> Hi Zhenqiang,
>
> *From:* Idr [mailto:[email-masked]] *On Behalf Of *li zhenqiang
> *Sent:* Wednesday, April 24, 2019 3:51 PM
> *To:* Susan Hares <[email-masked]>; [email-masked]
> *Cc:* draft-ietf-teas-enhanced-vpn <[email-masked]>;
> draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
> *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,
>
>
>
> 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
> ------------------------------
>
> [email-masked]
>
>
>
> *From:* Susan Hares <[email-masked]>
>
> *Date:* 2019-04-18 22:04
>
> *To:* [email-masked]
>
> *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:
>
>
>
> 1)      Does this draft mechanisms for  extending BGP-LS to provide IDs
> for allocation provide a beneficial addition to BGP mechanisms for segment
> routing?
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Wed, 8 May 2019 04:01:19 +0000

+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 <[email-masked]> On Behalf Of Robert Raszuk
Sent: 08 May 2019 07:57
To: Acee Lindem (acee) <[email-masked]>
Cc: [email-masked]; draft-ietf-teas-enhanced-vpn <[email-masked]>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]>; Susan Hares <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robin, Huaimo,

Thanks,
Acee

From: Idr <[email-masked]<mailto:[email-masked]>> on behalf of Robin Li <[email-masked]<mailto:[email-masked]>>
Date: Sunday, May 5, 2019 at 9:37 PM
To: li zhenqiang <[email-masked]<mailto:[email-masked]>>, Susan Hares <[email-masked]<mailto:[email-masked]>>, IDR List <[email-masked]<mailto:[email-masked]>>
Cc: draft-ietf-teas-enhanced-vpn <[email-masked]<mailto:[email-masked]>>, draft-dong-lsr-sr-enhanced-vpn <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

From: Idr [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of li zhenqiang

Hi Sue and All,

Best Regards,
Zhenqiang Li

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr

---

From: Gaurav Dawra <[email-masked]>
Date: Tue, 7 May 2019 22:03:31 -0700

+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) <[email-masked]> wrote:
> 
> +1
>

---

From: Srihari Sangli <[email-masked]>
Date: Wed, 8 May 2019 09:55:10 +0000

+1. I vote to keep the provisioning and topology discovery/propagation to be separate. This document should not be accepted in the current form.

srihari…

From: Idr <[email-masked]> on behalf of Gaurav Dawra <[email-masked]>
Date: Wednesday, 8 May 2019 at 10:34 AM
To: "Ketan Talaulikar (ketant)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Robert Raszuk <[email-masked]>, draft-ietf-teas-enhanced-vpn <[email-masked]>, draft-dong-lsr-sr-enhanced-vpn <[email-masked]>, Susan Hares <[email-masked]>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Cheers,

Gaurav
LinkedIn
Sent from my iPhone

On May 7, 2019, at 9:01 PM, Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>> wrote:
+1

Thanks,
Ketan

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Robert Raszuk
Sent: 08 May 2019 07:57
To: Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; draft-ietf-teas-enhanced-vpn <[email-masked]<mailto:[email-masked]>>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Acee,

Best regards,
R.

Thanks,
Acee

Cc: draft-ietf-teas-enhanced-vpn <draft-ietf-teas-enhanced-vpn@ietf..org<mailto:[email-masked]>>, draft-dong-lsr-sr-enhanced-vpn <[email-masked]<mailto:[email-masked]>>

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

Cc: draft-ietf-teas-enhanced-vpn <draft-ietf-teas-enhanced-vpn@ietf..org<mailto:[email-masked]>>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]<mailto:[email-masked]>>

Hi Sue and All,

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/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Denhanced-2Dvpn_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=D2PxhI4eSYvYupK3D7veb79n9CFF8cAUYGNtuecl6W0&m=82Cm4rG5uc1AEsOt1D1dbk-qN6XJEgfLWaVm3mJcFoM&s=9_AJyrjXNjHVdfrjeYvXHL3A98Mm4A3QazNEfY5QWPo&e=> and https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddong-2Dlsr-2Dsr-2Denhanced-2Dvpn_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=D2PxhI4eSYvYupK3D7veb79n9CFF8cAUYGNtuecl6W0&m=82Cm4rG5uc1AEsOt1D1dbk-qN6XJEgfLWaVm3mJcFoM&s=FZqDsw5Cjkp6iIkCIGpKTMTW2KlTRC3nqjHzSPVNUME&e=>.

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dteas-2Dpcecc-2Duse-2Dcases-2D02&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=D2PxhI4eSYvYupK3D7veb79n9CFF8cAUYGNtuecl6W0&m=82Cm4rG5uc1AEsOt1D1dbk-qN6XJEgfLWaVm3mJcFoM&s=zfKrB6nl3fXzFtFlTl01S6hi4OwB6Veah_4r98-a7_8&e=>). 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

https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwu-2Didr-2Dbgp-2Dsegment-2Dallocation-2Dext_&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=D2PxhI4eSYvYupK3D7veb79n9CFF8cAUYGNtuecl6W0&m=82Cm4rG5uc1AEsOt1D1dbk-qN6XJEgfLWaVm3mJcFoM&s=lMjGdv5BCe6KmADS56IrspQgYNgBrGnjgHt0qnYHCGg&e=>

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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=D2PxhI4eSYvYupK3D7veb79n9CFF8cAUYGNtuecl6W0&m=82Cm4rG5uc1AEsOt1D1dbk-qN6XJEgfLWaVm3mJcFoM&s=vFD2oXbztH_8cUDUnxKSRc9mBDumnnNOrVL1LPibKto&e=>
_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=D2PxhI4eSYvYupK3D7veb79n9CFF8cAUYGNtuecl6W0&m=82Cm4rG5uc1AEsOt1D1dbk-qN6XJEgfLWaVm3mJcFoM&s=vFD2oXbztH_8cUDUnxKSRc9mBDumnnNOrVL1LPibKto&e=>

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 8 May 2019 11:15:32 +0000

Robert,

From: Robert Raszuk <[email-masked]>
Date: Tuesday, May 7, 2019 at 10:27 PM
To: Acee Lindem <[email-masked]>
Cc: Robin Li <[email-masked]>, li zhenqiang <[email-masked]>, Susan Hares <[email-masked]>, IDR List <[email-masked]>, draft-ietf-teas-enhanced-vpn <[email-masked]>, draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Acee,

I don’t think it is a good idea either and was requesting justification to initiate a technical discussion of the purported benefits of the proposal. In the future, please read my entire Email and refrain from taking one sentence out of context.

Acee

Best regards,
R.

Thanks,
Acee

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: Lizhenbin <[email-masked]>
Date: Wed, 8 May 2019 13:41:51 +0000

Hi Aijun,
BGP-LS EPE is to distribute the BGP Peer SIDs from ASBRs to the controller. The requirement of the BGP extensions described in the draft is to allocate SID from the controller to the network devices (including ASBRs).
The SID encoding in draft-ietf-idr-bgpls-segment-routing-epe can be reused. But an extra TLV has to be introduced to indicate allocating SIDs instead of reporting SID info if BGP-LS is used for the purpose.

Best Regards,
Robin

From: Aijun Wang [mailto:[email-masked]]
Sent: Tuesday, May 07, 2019 9:25 AM
To: Lizhenbin <[email-masked]>; 'li zhenqiang' <[email-masked]>; 'Susan Hares' <[email-masked]>; [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' <[email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <[email-masked]>
Subject: 答复: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi, Robin:

Best Regards.

Aijun Wang

发件人: Lizhenbin [mailto:[email-masked]]
发送时间: 2019年5月6日 9:35
收件人: li zhenqiang; Susan Hares; [email-masked]<mailto:[email-masked]>
抄送: draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
主题: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: ruoxin huang <[email-masked]>
Date: Wed, 8 May 2019 15:26:10 +0000

support.

Best Regards,
Huoruoxin

Sent from Outlook<http://aka.ms/weboutlook>

________________________________
From: Idr <[email-masked]> on behalf of Lizhenbin <[email-masked]>
Sent: Wednesday, May 8, 2019 9:41 PM
To: Aijun Wang; 'li zhenqiang'; 'Susan Hares'; [email-masked]
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 Aijun,

Best Regards,

Robin

Hi, Robin:

Best Regards.

Aijun Wang

Hi Zhenqiang,

Best Regards,

Zhenbin (Robin)

Hi Sue and All,

[Robin]

Best Regards,

Zhenqiang Li

Date: 2019-04-18 22:04

Sue Hares

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 8 May 2019 11:24:23 -0700

Hi,

We shouldn’t be doing things just because we can...
Can we use BGP-LS for provisioning? - yes, we can. Should we?  - We better not to, BGP is not a suitable technology to do the work proposed, it doesn’t have proper feedback mechanics built in and can’t semantically validate the change made (as the opposite of for example PCEP). There’s quite some difference between distribution of: reachability (primarily job of BGP), policies (BGP does this opportunistically) and configuration (BGP is wrong tool).
In general - management plane is a much more suitable way to do so, netconf as an example.
To Acee’s point - life cycle management becomes an issue, operational/derived states inconstancies at scale are not easy to troubleshoot, and without single source of truth simply impossible.

Cheers,
Jeff

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 9 May 2019 08:45:48 +0800

Hi, Robin:

>From the discussion of this thread, I support to accomplish this work via different BGP AFI/SAFI, reuse the TLV/SID that defined in draft-ietf-idr-bgpls-segment-routing-epe.

This can eliminate the confusion with the definition/usage of BGP-LS, and align with other similar usage of BGP, for example BGP-flowspec.

The message structural of the newly defined AFI/SAFI need also not same as that in the BGP-LS, which is rooted from the IGP topology.

Best Regards.

Aijun Wang

发件人: Lizhenbin [mailto:[email-masked]] 
发送时间: 2019年5月8日 21:42
收件人: Aijun Wang; 'li zhenqiang'; 'Susan Hares'; [email-masked]
抄送: 'draft-ietf-teas-enhanced-vpn'; 'draft-dong-lsr-sr-enhanced-vpn'
主题: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Aijun,

Best Regards,

Robin

Hi, Robin:

 

Best Regards.

Aijun Wang

Hi Zhenqiang,

Best Regards,

Zhenbin (Robin)

Hi Sue and All,

[Robin]

 

Best Regards,

Zhenqiang Li

  _____  

[email-masked]

Date: 2019-04-18 22:04

To: [email-masked]

Sue Hares

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 9 May 2019 09:09:36 +0800

Hi, Jeff:

Actually, it is more acceptable to use BGP-LS to report the topology info and use the PCEP to do the control work. But as described in this draft, there are situations that the network deployed only the BGP, then this draft wants to find some solution to these scenarios.  I think such capability is supplementary to the portfolio of provisioning tools.

We have ever paid more attention to the NETCONF/YANG for the configuration work. But as I knew, the implementations of these standardization YANGs are not as ideal as we have imaged.  The TLV extensions mechanism may be more optimistic to fulfill the newly requirements, as that done in IGP, BGP and PCEP.

Best Regards.

Aijun Wang

发件人: Jeff Tantsura [mailto:[email-masked]] 
发送时间: 2019年5月9日 2:24
收件人: Lizhenbin; li zhenqiang; Susan Hares; [email-masked]; Acee Lindem (acee)
抄送: draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
主题: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi,

Can we use BGP-LS for provisioning? - yes, we can.. Should we?  - We better not to, BGP is not a suitable technology to do the work proposed, it doesn’t have proper feedback mechanics built in and can’t semantically validate the change made (as the opposite of for example PCEP). There’s quite some difference between distribution of: reachability (primarily job of BGP), policies (BGP does this opportunistically) and configuration (BGP is wrong tool).

 

Cheers, 

Jeff

Hi Robin, Huaimo,

Thanks,

Acee

Hi Zhenqiang,

Best Regards,

Zhenbin (Robin)

Hi Sue and All,

[Robin]

 

Best Regards,

Zhenqiang Li

  _____  

[email-masked]

Date: 2019-04-18 22:04

To: [email-masked]

Sue Hares

---

From: "Guyunan (Yunan Gu, IP Technology Research Dept. NW)" <[email-masked]>
Date: Thu, 9 May 2019 02:34:30 +0000

Hi all,

Speaking from the vendor perspective, we have received requirements from clients, who have concerns regarding the YANG standardization process, asking for alternative solutions such as BGP and PCEP. And we also have clients who want BGP only. Thus, using either BGP-LS or BGP for SID provisioning is worth discussion.

BGP, as its current state, might be not as mature as PCEP regarding SID management. However, necessary augmented works to BGP can be done, and can serve as a workable way.

Yunan

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.

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 9 May 2019 07:22:13 +0000

Hi Ketan,

One point raised during the discussion is that provisioning is relatively static, and signaling is usually dynamic. As the SIDs will be extended to represent various functions and resources, it is likely that some types of the SIDs will to be dynamically instantiated. In that case, it seems BGP could be an option for the SID allocation.

As for whether BGP-LS is the right option, or some other BGP mechanism should be defined, we can have further discussion on this.

Best regards,
Jie

From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Tuesday, May 07, 2019 12:08 PM
To: Lizhenbin <[email-masked]>; li zhenqiang <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: draft-ietf-teas-enhanced-vpn <[email-masked]>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Robin,

From: Idr <[email-masked]<mailto:[email-masked]>> On Behalf Of Lizhenbin
Sent: 06 May 2019 07:05
To: li zhenqiang <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: draft-ietf-teas-enhanced-vpn <[email-masked]<mailto:[email-masked]>>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

Hi Sue and All,

Thanks,
Ketan

Best Regards,
Zhenqiang Li

Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Thu, 9 May 2019 09:57:57 +0000

Hi Jie,

Sure, we would have SIDs which would need to be dynamically instantiated. Their allocation may even be done automatically by the node – it does not necessary imply the need/requirement always for a controller. But I think this argument is secondary.

Based on the discussions so far, my sense was that we need the authors to come up with an updated draft that covers the various aspects of provisioning via BGP and covers/clarifies on the points raised as part of this adoption call. I also believe that this is outside the scope of BGP-LS and we can discuss on doing this as a different AFI in BGP based on an updated draft.

Thanks,
Ketan

From: Dongjie (Jimmy) <[email-masked]>
Sent: 09 May 2019 12:52
To: Ketan Talaulikar (ketant) <[email-masked]>; Lizhenbin <[email-masked]>; li zhenqiang <[email-masked]>; Susan Hares <[email-masked]>; [email-masked]
Cc: draft-ietf-teas-enhanced-vpn <[email-masked]>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Ketan,

Best regards,
Jie

To: Lizhenbin <[email-masked]<mailto:[email-masked]>>; li zhenqiang <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Robin,

Hi Zhenqiang,

Best Regards,
Zhenbin (Robin)

Hi Sue and All,

Thanks,
Ketan

Best Regards,
Zhenqiang Li

Sue Hares

---

From: Huaimo Chen <[email-masked]>
Date: Fri, 10 May 2019 03:57:54 +0000

Hi Ketan,

Thank you for your comments.
My explanations are inline below with prefix [HC2].

Best Regards,
Huaimo
From: Ketan Talaulikar (ketant) [mailto:[email-masked]]
Sent: Tuesday, May 7, 2019 4:16 AM
To: Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>; 'li zhenqiang' <[email-masked]>; [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' <[email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <[email-masked]>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Huaimo,

From: Huaimo Chen <[email-masked]<mailto:[email-masked]>>
Sent: 06 May 2019 20:35
To: Ketan Talaulikar (ketant) <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; 'li zhenqiang' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: 'draft-ietf-teas-enhanced-vpn' <[email-masked]<mailto:[email-masked]>>; 'draft-dong-lsr-sr-enhanced-vpn' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Ketan,

Best Regards,
Huaimo

Hi Sue/All,

[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

Thanks,
Ketan

Zhengquiang:

<wg-chair hat on>

<wg-member hat on>

Sue Hares

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: "Ketan Talaulikar (ketant)" <[email-masked]>
Date: Fri, 10 May 2019 06:37:59 +0000

Hi Huaimo,

Thanks for your response. Will look forward to the updated draft that describes your revised proposal and addresses the points raised during this discussion.

Thanks,
Ketan

Sent: 10 May 2019 09:28

Hi Ketan,

Best Regards,
Huaimo
To: Huaimo Chen <[email-masked]<mailto:[email-masked]>>; Susan Hares <[email-masked]<mailto:[email-masked]>>; 'li zhenqiang' <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Huaimo,

Hi Ketan,

Best Regards,
Huaimo

Hi Sue/All,

Thanks,
Ketan

Thanks,
Ketan

Zhengquiang:

<wg-chair hat on>

<wg-member hat on>

Sue Hares

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 10 May 2019 10:56:33 +0200

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 <[email-masked]> wrote:

> *From:* Ketan Talaulikar (ketant) [mailto:[email-masked]]
> *Sent:* Tuesday, May 7, 2019 4:16 AM
> *To:* Huaimo Chen <[email-masked]>; Susan Hares <[email-masked]>;
> 'li zhenqiang' <[email-masked]>; [email-masked]
> *Cc:* 'draft-ietf-teas-enhanced-vpn' <
> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <
> [email-masked]>
> *Subject:* RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18
> *From:* Huaimo Chen <[email-masked]>
> *Sent:* 06 May 2019 20:35
> *To:* Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <
> [email-masked]>; 'li zhenqiang' <[email-masked]>; [email-masked]
> *Cc:* 'draft-ietf-teas-enhanced-vpn' <
> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <
> [email-masked]>
> *Subject:* RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18
> *From:* Idr [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Ketan Talaulikar (ketant)
> *Sent:* Wednesday, April 24, 2019 11:46 AM
> *To:* Susan Hares <[email-masked]>; 'li zhenqiang' <
> [email-masked]>; [email-masked]
> *Cc:* 'draft-ietf-teas-enhanced-vpn' <
> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <
> [email-masked]>
> 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.
>
>
>
> *[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?*
>
> *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.
>
>
>
> 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.
>
>
>
> *From:* Idr <[email-masked]> *On Behalf Of *Susan Hares
> *Sent:* 24 April 2019 19:54
> *To:* 'li zhenqiang' <[email-masked]>; [email-masked]
> *Cc:* 'draft-ietf-teas-enhanced-vpn' <
> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' <
> [email-masked]>
> 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:[email-masked] <[email-masked]>] *On
> Behalf Of *li zhenqiang
> *Sent:* Wednesday, April 24, 2019 3:51 AM
> *To:* Susan Hares; [email-masked]
> *Cc:* draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn
> https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/..
>
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 10 May 2019 12:28:27 -0700

Hi Aijun,

philosophical part:
"As protocol designers, before we propose any changes/additions(increasing complexity), we should always do trade-off analysis (and if you haven’t found any, you haven’t looked well enough :)) that should include full life cycle of the change you are proposing, in context of the draft discussed, at least - configuration/operation/decommission."

To also bring the comparison with draft-ietf-idr-segment-routing-te-policy.
There’s fundamental difference of what the 2 drafts are proposing
draft-ietf-idr-segment-routing-te-policy is used to distribute policies that augment reachabiity, which is clearly day 2 operation, creates ephemeral state and is reasonably in scope of BGP
draft-wu-idr-bgp-segment-allocation-ext is used to configure devices, which is clearly a day 0 operation and hence creates operational state, which is IMO is very much out of scope.
How do you verify that operational state is the intended one (configurational), e.g. SIDs distributed are accepted, instantiated, installed, etc? How do you remove/change the state?
What happens on reload?

Cheers,
Jeff

---

From: Huaimo Chen <[email-masked]>
Date: Sat, 11 May 2019 03:06:51 +0000

Hi Robert,

Thank you for your comments and questions.
As you suggested, removing allocated SIDs can be done through using MP_UNREACH. We will update the draft accordingly.
When the SIDs are allocated by a centralized place, there should not be SID conflict.
When a node does not accept a SID, something abnormal may happen and it should give some indication.

Best Regards,
Huaimo
From: Robert Raszuk [mailto:[email-masked]]
Sent: Friday, May 10, 2019 4:57 AM
To: Huaimo Chen <[email-masked]>
Cc: Ketan Talaulikar (ketant) <[email-masked]>; Susan Hares <[email-masked]>; li zhenqiang <[email-masked]>; [email-masked]; draft-ietf-teas-enhanced-vpn <[email-masked]>; draft-dong-lsr-sr-enhanced-vpn <[email-masked]>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

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

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ketan,

Best Regards,
Huaimo
From: Ketan Talaulikar (ketant) [mailto:[email-masked]<mailto:[email-masked]>]

Hi Huaimo,

Hi Ketan,

Best Regards,
Huaimo

Hi Sue/All,

Thanks,
Ketan

Thanks,
Ketan

Zhengquiang:

<wg-chair hat on>

<wg-member hat on>

Sue Hares

Hi Sue and All,

Best Regards,
Zhenqiang Li

Sue Hares

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 29 May 2019 22:06:54 -0400

Huaimo and co-authors: 

It appears there is interest in this solution, but that several issues need to be address from emails.  The summary is that a revised draft or two drafts (separated topology and provisioning). 

Here are some issues that the emails discussed: 

1)      removal of allocated SIDs (Robert Razuk),  

2)      indicating aspects of allocation (dynamic, static, or mid-range) that require this draft,  

3)      aspects of control that require this draft instead of PCP, 

4)      when Yang should be used for allocation instead of this draft. 

Would you spin a revised draft(s) addressing the issues raised.  

After you send out the revised draft, we will do a second adoption call.  The interest in the drafts shows that you should work on the revised drafts so that the WG can examine the drafts. 

Sue Hares  

From: Idr [mailto:[email-masked]] On Behalf Of Huaimo Chen
Sent: Friday, May 10, 2019 11:07 PM
To: Robert Raszuk
Cc: [email-masked]; draft-ietf-teas-enhanced-vpn; draft-dong-lsr-sr-enhanced-vpn; Susan Hares
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Robert,

Best Regards,

Huaimo

Hi Huaimo,

Best,

R.

Hi Ketan,

Best Regards,

Huaimo

From: Ketan Talaulikar (ketant) [mailto: <mailto:[email-masked]> [email-masked]] 
Sent: Tuesday, May 7, 2019 4:16 AM
To: Huaimo Chen < <mailto:[email-masked]> [email-masked]>; Susan Hares < <mailto:[email-masked]> [email-masked]>; 'li zhenqiang' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Huaimo,

From: Huaimo Chen < <mailto:[email-masked]> [email-masked]> 
Sent: 06 May 2019 20:35
To: Ketan Talaulikar (ketant) < <mailto:[email-masked]> [email-masked]>; Susan Hares < <mailto:[email-masked]> [email-masked]>; 'li zhenqiang' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>
Subject: RE: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

Hi Ketan,

Best Regards,

Huaimo

From: Idr [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Ketan Talaulikar (ketant)
Sent: Wednesday, April 24, 2019 11:46 AM
To: Susan Hares < <mailto:[email-masked]> [email-masked]>; 'li zhenqiang' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>
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,

Thanks,

Ketan

No.

No.

No.

Thanks,

Ketan

From: Idr < <mailto:[email-masked]> [email-masked]> On Behalf Of Susan Hares
Sent: 24 April 2019 19:54
To: 'li zhenqiang' < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]
Cc: 'draft-ietf-teas-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>; 'draft-dong-lsr-sr-enhanced-vpn' < <mailto:[email-masked]> [email-masked]>
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> 

<wg-chair hat off> 

<wg-member hat on>

<wg-member hat off> 

Sue Hares 

From: Idr [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of li zhenqiang
Sent: Wednesday, April 24, 2019 3:51 AM
To: Susan Hares;  <mailto:[email-masked]> [email-masked]
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,

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/> https://datatracker.ietf.org/doc/draft-ietf-teas-enhanced-vpn/ and  <https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/> https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/..

Best Regards,

Zhenqiang Li

  _____  

 <mailto:[email-masked]> [email-masked]

From:  <mailto:[email-masked]> Susan Hares

Date: 2019-04-18 22:04

To:  <mailto:[email-masked]> [email-masked]

 <https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/> https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/

Sue Hares

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 30 May 2019 12:04:06 +0000

Hi Sue,

    Thank you very much for your summary.
    We will revise the draft to address the issues accordingly.

Best Regards,
Huaimo
________________________________
From: Susan Hares <[email-masked]>
Sent: Wednesday, May 29, 2019 10:06 PM
To: 'Huaimo Chen'
Cc: [email-masked]; '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

Huaimo and co-authors:

Sue Hares

Hi Robert,

Best Regards,

Huaimo

Hi Huaimo,

Best,

R.

Hi Ketan,

Best Regards,

Huaimo

Hi Huaimo,

Hi Ketan,

Best Regards,

Huaimo

Hi Sue/All,

https://mailarchive.ietf.org/arch/msg/idr/gIMSFeL0rmNjJy-3ySd1ygyOzyo<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FgIMSFeL0rmNjJy-3ySd1ygyOzyo&data=02%7C01%7Chchen%40futurewei.com%7C631e8221d90047495b7108d6e4a38b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636947788423294746&sdata=aysScDWKZJT93%2Bwm3sIJis%2FxCKoztqXtvexjH7XhKLs%3D&reserved=0>

Thanks,

Ketan

No.

No.

No.

Thanks,

Ketan

Zhengquiang:

<wg-chair hat on>

<wg-chair hat off>

<wg-member hat on>

<wg-member hat off>

Sue Hares

Hi Sue and All,

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/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-teas-enhanced-vpn%2F&data=02%7C01%7Chchen%40futurewei.com%7C631e8221d90047495b7108d6e4a38b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636947788423304744&sdata=ncIjs8Pu8nGZZiSQcJji48VvWhaKoo%2BNqMvGbpW3f%2Bk%3D&reserved=0> and https://datatracker.ietf.org/doc/draft-dong-lsr-sr-enhanced-vpn/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dong-lsr-sr-enhanced-vpn%2F&data=02%7C01%7Chchen%40futurewei.com%7C631e8221d90047495b7108d6e4a38b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636947788423304744&sdata=SnC%2BLiAB2u%2BzwqYzai1VAH8u4ZS%2FKQoHi%2BgCYjF76oo%3D&reserved=0>..

Best Regards,

Zhenqiang Li

Date: 2019-04-18 22:04

https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wu-idr-bgp-segment-allocation-ext%2F&data=02%7C01%7Chchen%40futurewei.com%7C631e8221d90047495b7108d6e4a38b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636947788423314734&sdata=oSHs64ovdrq9h56Dgd6eStS1lmpF1y46j%2Fvk6M3gO1A%3D&reserved=0>

Sue Hares

_______________________________________________
Idr mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/idr<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fidr&data=02%7C01%7Chchen%40futurewei.com%7C631e8221d90047495b7108d6e4a38b4b%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C636947788423314734&sdata=YOYfjELLnYmJtMKlEOy3%2B%2Bfcw7YUJVyjfxA2KuavuEw%3D&reserved=0>