Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

From: "Gengxuesong (Geng Xuesong)" <[email-masked]>
Date: Mon, 1 Feb 2021 10:03:44 +0000

Hi WG,

I support WG adoption of this document, which gives good instructions about how to use resoucer-aware SIDs to build SR based VTN.
While in the next version, maybe it is better to add more specifications about VTN control plane functions and protocol extensions.  (There is some text in section 3 of the existing version, which I think is not sufficient)

Best
Xuesong

From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 7:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This message starts a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending February 10th 2021.

After review of the document please indicate support (or not) for WG adoption to the mailing list and if you are willing to work on the document, please state this explicitly. This gives the chairs an indication of the energy level of people in the working group willing to work on this document. Please also provide comments/reasons for your support (or lack thereof) as this is a stronger way to indicate your (non) support as this is not a vote.

Thanks!

Jim, Bruno & Joel

---

From: Tarek Saad <[email-masked]>
Date: Tue, 2 Feb 2021 04:25:22 +0000

Hi WG/authors,

My understanding is this draft proposes allocation of per VTN resource-aware SID for each topological element in a network.

This means a specific node may carry per VTN state (in control plane and dataplane) for each topological element (node or link).
In general, to avoid state explosion, SR endorses carrying additional information/context inside the packet.

In draft-bestbar-spring-scalable-ns, we propose to carry a separate ID inside the packet that allows a node to identify the packet belonging to slice-aggregate (or VTN). This decouples SR SIDs used to steer on topological elements from the dataplane ID needed to infer a slice-aggregate (or VTN) so to enforce a specific forwarding treatment. This avoids the per VTN SID state explosion in control and data plane.

Also, when resource allocation/reservation is strictly done in the control plane, it appears per VTN resource SIDs would not serve any further benefit. In fact, a PCE or ingress can readily use the regular SIDs to steer any packet along a specific path that satisfies the requested resources guarantees as verified in the control plane.

Lastly, I draw your attention to draft-bestbar-teas-ns-packet which proposes a network wide slice policy as a vehicle that allows allocation of control and/or dataplane resources for each slice-aggregate (or VTN) on specific network elements.

Regards,
Tarek

On 1/27/21, 6:46 AM, "spring on behalf of James Guichard" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Dear WG:

Thanks!

Jim, Bruno & Joel

Juniper Business Use Only

---

From: Tarek Saad <[email-masked]>
Date: Tue, 2 Feb 2021 04:48:19 +0000

Hi Robert,

RFC3270 talks about two models for reserving resources for LSPs in a MPLS Diffserv network (namely E-LSP and L-LSP). While former is the more popular implementation amongst vendors, implementations of the latter exist for some vendors – i.e. L-LSP which will do per LSP resource allocation.
I agree in non DS-TE deployments, most RSVP-TE implementations I worked with will just do control plane reservations/validation for LSP path placement. However, for RSVP DS-TE deployments, there is still resources provisioned per class in the dataplane – this is to ensure the differentiated treatment for class traffic on shared links.

Along those lines, draft-bestbar-teas-ns-packet extends this and proposes ability to apply QoS treatment on slice aggregate traffic that traverses a shared resource/link. The packet will need to be identified as belonging to the slice aggregate. For this, draft-bestbar-teas-ns-packet proposes that a separate field can be carried in the packet so it can be used to identify the slice aggregate the packet belongs to.

Regards,
Tarek

On 1/31/21, 12:24 PM, "spring on behalf of Robert Raszuk" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Lou,

If you mean ingress policing that this is not what I was referring to - however for most if not all shipping RSVP-TE aka MPLS-TE implementation I am not aware of any per TE-LSP data plane resource allocation in the date plane. Keen on being corrected, but with facts and proof not with claims and statements.

If there are any please kindly enumerate what resources are being reserved and how (ie. what RE/RP tells LC to "reserve"). No need to reveal the implementation name(s), but if you provide a detailed pointer it would be helpful.

Cheers,
R.

On Sun, Jan 31, 2021 at 6:10 PM Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:

Robert,

I'm amazed that after all these decades of RSVP and rsvp-te implementations there are those who still state that there is no resource allocation or management in the data plane. The RFCs are quiet on the topic of how reservations are managed/enforced and it is up to the vendor to choose what to implement and the user to decide what features are important to them, i.e., that they are willing to pay for.

While it is certainly true that there is a well-known vendor that doesn't do much in the data plane and there are some who wish that this was the only choice, there are certainly TE implementations that do manage/allocate resources in the data plane to match reservations established via RSVP or more modern sdn-te techniques.

Lou

________________________________

On January 31, 2021 8:08:31 AM Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi Adrian,

> To your 3209 comments: I believe that *some* implementations have pushed the “reservation”
> into the data plane so that in-network policing is performed to conform data flows with reservations or,

Sure thing that any decent TE implementation and deployment must provide ingress policing into TE-LSPs. But this is ingress policing not reservation of actual data plane resources which explicitly Jie explained as the intention here.

Best,
R.

> On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Yeah, thanks Robert.

Actually, removing the comparison with other protocols is probably wise. This is a document describing how to do stuff with SR. In that context we don’t need to talk about the benefits or limitations of other protocols.

To your 3209 comments: I believe that *some* implementations have pushed the “reservation” into the data plane so that in-network policing is performed to conform data flows with reservations or, at least, ensure that the parts of any flow that exceed reservation are treated as best effort. But this is an aside to the discussion of the draft at hand.

I think that the document should note that the SR control plane does not currently have the capability to make reservations (in the control plane) at the network nodes. This can be achieved using a central controller to keep tabs on all resource accounting, and it could use a southbound interface to install that information in the (management/control parts of the) network nodes.

Cheers,
Adrian

From: Robert Raszuk <[email-masked]<mailto:[email-masked]>>
Sent: 31 January 2021 00:46
To: Adrian Farrel <[email-masked]<mailto:[email-masked]>>
Cc: James Guichard <[email-masked]<mailto:[email-masked]>>; SPRING WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi Adrian,

Just to make sure my point was correctly understood ... I am not questioning if either data plane or control plane resource reservations should or should not be done for SR.

What I am questioning is that the draft says:

   When
   compared with RSVP-TE [RFC3209], SR currently does not have the
   capability to reserve network resources or identify different sets of
   network resources reserved for different customers and/or services.

The crux of the matter is that RFC3209 DOES NOT reserve anything in the data plane of any network element while this spec clearly intends to. RSVP-TE keeps all reservations in control plane counters only. Constrained based path computation/selection happens based on those control plane information. (Yes nearly 20 years after this feature shipped I am still meeting people who believe otherwise :).

So to start I recommend we remove any reference to RSVP-TE as this is purely not applicable to what this document is trying to accomplish.

I admit I did not follow all the recent advancements in TEAS nor in DETNET as far as actually reserving data plane resources in data plane for some traffic types. If authors want to build a solution with that - by all means green light and full speed ahead - market will decided - especially when it will really understand the cost :) But let's make sure the document is crystal clear on what building blocks it is talking about.

Best,
R.

On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Jim,

I’ve been following the enhanced VPN work in TEAS and I see it as a key piece of the network slicing work.

It’s time that we had some protocol solutions that serve the VPN framework, and this is a suitable starting point. I like that it is not specifying additional protocol widgets but has looked at what we already have and is pointing up ways to use those tools to deliver new function.

I see Robert’s point about the resource reservation aspects of traffic engineering applied to an SR network, but this is not an insurmountable problem. The question might be asked, “Why would you want to do that?” but that is a question that (as Yakov would have said) the market can decide. It seems that there are a couple of vendors and a couple of operators who have an interest.

So I think we should adopt this draft and see whether we can turn it into something that has great utility.

Cheers,
Adrian

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of James Guichard
Sent: 27 January 2021 11:47
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring

---

From: Lizhenbin <[email-masked]>
Date: Tue, 2 Feb 2021 09:15:07 +0000

Hi WG,
I support the adoption as the contributor. It has been three years since the first version of the draft was proposed. After long-term work, the solution is mature and well-accepted. The draft is well written and ready for adoption.

Best Regards,
Zhenbin (Robin)

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 2 Feb 2021 09:29:55 +0000

Hi Xuesong,

Thanks for your support and comment.

As this document mainly describes the SR data plane mechanisms and the procedures of building SR based VTNs, the descriptions about the control plane are brief, and the details are left to the control plane drafts. That said, we could add some more descriptions about the related control plane functions in next version.

Best regards,
Jie

From: Gengxuesong (Geng Xuesong)
Sent: Monday, February 1, 2021 6:04 PM
To: James Guichard <[email-masked]>; [email-masked]
Cc: [email-masked]
Subject: RE: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG,

Best
Xuesong

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 2 Feb 2021 10:36:26 +0100

Hi Terek,

Sure that MPLS supports diff-serve from day one. No one ever stated that it
does not. In fact if you go back to one of the messages I explicitly stated
this already and even encourage its use to the problem at hand.

But the label inferred class of service or such carried in EXP bits is
really nothing close to per individual LSP resource reservations some
imagine is taking place.

So by all means using QoS in MPLS networks - both MPLS TE or LDP is a good
thing. It is just from practical point (limited number of classes) not per
customer or per LSP-TE reservation of any sort. Another problem arises that
to do it well you must use central controller which would be controlling
all ingress points to your network for this class of service. It is
important to also note that this class of service must have priority over
*any* other traffic type - including control plane itself. Needless to say
you also need to inspect and rewrite if needed any other non
compliant traffic attempting to also be placed in this type of PQ.

I have a feeling that some people in the industry think that they can bring
back TDM paradigm into connectionless IP transport. This is easy to do in
SDH/SONET layers ... not above it when all traffic is squeezed into shared
space containers. Sure at most we could say F/C class goes in/out first at
each hop, but that's about it.

Best,
R.

On Tue, Feb 2, 2021 at 5:48 AM Tarek Saad <[email-masked]> wrote:

> Hi Robert,
>
>
>
> RFC3270 talks about two models for reserving resources for LSPs in a MPLS
> Diffserv network (namely E-LSP and L-LSP). While former is the more popular
> implementation amongst vendors, implementations of the latter exist for
> some vendors – i.e. L-LSP which will do per LSP resource allocation.
>
> I agree in non DS-TE deployments, most RSVP-TE implementations I worked
> with will just do control plane reservations/validation for LSP path
> placement. However, for RSVP DS-TE deployments, there is still resources
> provisioned per class in the dataplane – this is to ensure the
> differentiated treatment for class traffic on shared links.
>
>
>
> Along those lines, draft-bestbar-teas-ns-packet extends this and proposes
> ability to apply QoS treatment on slice aggregate traffic that traverses a
> shared resource/link. The packet will need to be identified as belonging to
> the slice aggregate. For this, draft-bestbar-teas-ns-packet proposes that a
> separate field can be carried in the packet so it can be used to identify
> the slice aggregate the packet belongs to.
>
>
>
> Regards,
>
> Tarek
>
>
>
>
>
>
>
> On 1/31/21, 12:24 PM, "spring on behalf of Robert Raszuk" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>
>
> Lou,
>
>
>
> If you mean ingress policing that this is not what I was referring to -
> however for most if not all shipping RSVP-TE aka MPLS-TE implementation I
> am not aware of any per TE-LSP data plane resource allocation in the date
> plane. Keen on being corrected, but with facts and proof not with claims
> and statements.
>
>
>
> If there are any please kindly enumerate what resources are being reserved
> and how (ie. what RE/RP tells LC to "reserve"). No need to reveal the
> implementation name(s), but if you provide a detailed pointer it would
> be helpful.
>
>
>
> Cheers,
>
> R.
>
>
>
>
>
> On Sun, Jan 31, 2021 at 6:10 PM Lou Berger <[email-masked]> wrote:
>
> Robert,
>
> I'm amazed that after all these decades of RSVP and rsvp-te
> implementations there are those who still state that there is no resource
> allocation or management in the data plane. The RFCs are quiet on the topic
> of how reservations are managed/enforced and it is up to the vendor to
> choose what to implement and the user to decide what features are important
> to them, i.e., that they are willing to pay for.
>
> While it is certainly true that there is a well-known vendor that doesn't
> do much in the data plane and there are some who wish that this was the
> only choice, there are certainly TE implementations that do manage/allocate
> resources in the data plane to match reservations established via RSVP or
> more modern sdn-te techniques.
>
> Lou
> ------------------------------
>
> On January 31, 2021 8:08:31 AM Robert Raszuk <[email-masked]> wrote:
>
> Hi Adrian,
>
>
>
> > To your 3209 comments: I believe that **some** implementations have
> pushed the “reservation”
>
> Sure thing that any decent TE implementation and deployment must provide
> ingress policing into TE-LSPs. But this is ingress policing not reservation
> of actual data plane resources which explicitly Jie explained as the
> intention here.
>
>
>
> Best,
> R.
>
>
>
>
>
> > On Sun, Jan 31, 2021 at 1:06 PM Adrian Farrel <[email-masked]>
> wrote:
>
> Yeah, thanks Robert.
>
>
>
> Actually, removing the comparison with other protocols is probably wise.
> This is a document describing how to do stuff with SR. In that context we
> don’t need to talk about the benefits or limitations of other protocols.
>
>
>
> To your 3209 comments: I believe that **some** implementations have
> pushed the “reservation” into the data plane so that in-network policing is
> performed to conform data flows with reservations or, at least, ensure that
> the parts of any flow that exceed reservation are treated as best effort.
> But this is an aside to the discussion of the draft at hand.
>
>
>
> I think that the document should note that the SR control plane does not
> currently have the capability to make reservations (in the control plane)
> at the network nodes. This can be achieved using a central controller to
> keep tabs on all resource accounting, and it could use a southbound
> interface to install that information in the (management/control parts of
> the) network nodes.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> *From:* Robert Raszuk <[email-masked]>
> *Sent:* 31 January 2021 00:46
> *To:* Adrian Farrel <[email-masked]>
> *Cc:* James Guichard <[email-masked]>; SPRING WG <
> [email-masked]>; [email-masked]
> *Subject:* Re: [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Hi Adrian,
>
>
>
> Just to make sure my point was correctly understood ... I am not
> questioning if either data plane or control plane resource reservations
> should or should not be done for SR.
>
>
>
> The crux of the matter is that RFC3209 DOES NOT reserve anything in the
> data plane of any network element while this spec clearly intends to.
> RSVP-TE keeps all reservations in control plane counters only.
> Constrained based path computation/selection happens based on those
> control plane information. (Yes nearly 20 years after this feature shipped
> I am still meeting people who believe otherwise :).
>
>
>
> So to start I recommend we remove any reference to RSVP-TE as this is
> purely not applicable to what this document is trying to accomplish.
>
>
>
> I admit I did not follow all the recent advancements in TEAS nor in DETNET
> as far as actually reserving data plane resources in data plane for some
> traffic types. If authors want to build a solution with that - by all means
> green light and full speed ahead - market will decided - especially when it
> will really understand the cost :) But let's make sure the document is
> crystal clear on what building blocks it is talking about.
>
>
>
> Best,
> R.
>
>
>
>
>
> On Sat, Jan 30, 2021 at 11:20 PM Adrian Farrel <[email-masked]>
> wrote:
>
> Thanks, Jim,
>
>
>
> It’s time that we had some protocol solutions that serve the VPN
> framework, and this is a suitable starting point. I like that it is not
> specifying additional protocol widgets but has looked at what we already
> have and is pointing up ways to use those tools to deliver new function.
>
>
>
> I see Robert’s point about the resource reservation aspects of traffic
> engineering applied to an SR network, but this is not an insurmountable
> problem. The question might be asked, “Why would you want to do that?” but
> that is a question that (as Yakov would have said) the market can decide.
> It seems that there are a couple of vendors and a couple of operators who
> have an interest.
>
>
>
> *From:* spring <[email-masked]> *On Behalf Of *James Guichard
> *Sent:* 27 January 2021 11:47
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [spring] WG Adoption Call for
> draft-dong-spring-sr-for-enhanced-vpn
>
>
>
> Dear WG:
>
>
>
> This message starts a 2 week WG adoption call for
> https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/
> ending February 10th 2021.
>
>
>
> After review of the document please indicate support (or not) for WG
> adoption to the mailing list and if you are willing to work on the
> document, please state this explicitly. This gives the chairs an indication
> of the energy level of people in the working group willing to work on this
> document. Please also provide comments/reasons for your support (or lack
> thereof) as this is a stronger way to indicate your (non) support as this
> is not a vote.
>
>
>
> Thanks!
>
>
>
> Jim, Bruno & Joel
>
>
>
>
>
>
>
> [email-masked]

---

From: Giuseppe Fioccola <[email-masked]>
Date: Tue, 2 Feb 2021 14:01:17 +0000

Hi All,
I have read it and support WG adoption for this draft that provides a mechanism based on resource-aware SIDs in order to build SR based VTNs for Enhanced VPN.

Regards,

Giuseppe

From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Tarek Saad <[email-masked]>
Date: Tue, 2 Feb 2021 14:15:03 +0000

Thanks. We are mostly in agreement.

Regards,
Tarek

On 2/2/21, 4:36 AM, "spring on behalf of Robert Raszuk" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Terek,

Sure that MPLS supports diff-serve from day one. No one ever stated that it does not. In fact if you go back to one of the messages I explicitly stated this already and even encourage its use to the problem at hand.

But the label inferred class of service or such carried in EXP bits is really nothing close to per individual LSP resource reservations some imagine is taking place.

So by all means using QoS in MPLS networks - both MPLS TE or LDP is a good thing. It is just from practical point (limited number of classes) not per customer or per LSP-TE reservation of any sort. Another problem arises that to do it well you must use central controller which would be controlling all ingress points to your network for this class of service. It is important to also note that this class of service must have priority over *any* other traffic type - including control plane itself. Needless to say you also need to inspect and rewrite if needed any other non compliant traffic attempting to also be placed in this type of PQ.

I have a feeling that some people in the industry think that they can bring back TDM paradigm into connectionless IP transport. This is easy to do in SDH/SONET layers ... not above it when all traffic is squeezed into shared space containers. Sure at most we could say F/C class goes in/out first at each hop, but that's about it.

Best,
R.

On Tue, Feb 2, 2021 at 5:48 AM Tarek Saad <[email-masked]<mailto:[email-masked]>> wrote:
Hi Robert,

Regards,
Tarek

Lou,

Cheers,
R.

Robert,

Lou

Best,
R.

Yeah, thanks Robert.

Cheers,
Adrian

Hi Adrian,

   When

Best,
R.

Cheers,
Adrian

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 2 Feb 2021 15:49:58 +0000

Hi all,
There is the general trend to encode the action into the packet, not to distribute states in the control plane for all possible traffic types. Granularity, programmability are better.
This type of virtualization is fully in-line with this trend.
Support.
Eduard
From: spring [mailto:[email-masked]] On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: stefano previdi <[email-masked]>
Date: Tue, 2 Feb 2021 18:37:05 +0100

Hi,

I support the WG adoption of this draft.

Thanks.

s.

> On Jan 27, 2021, at 12:46 PM, James Guichard <[email-masked]> wrote:
> 
> Dear WG:
>  
> This message starts a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ ending February 10th2021.
>

---

From: Tarek Saad <[email-masked]>
Date: Tue, 2 Feb 2021 17:54:40 +0000

Hi Eduard,

Inline..

On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi all,

[TS]: Indeed, we are in agreement on encoding the information in packet as opposed to distributing states in the control plane. In draft-bestbar-spring-scalable-ns, a separate ID inside the packet is proposed to carry the needed information. However, this draft <draft-dong-spring-sr-for-enhanced-vpn> is proposing distributing per VTN state in the network which is completely against your argument ...

Regards,
Tarek

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Colby Barth <[email-masked]>
Date: Tue, 2 Feb 2021 14:19:22 -0500

Tarek, indeed …

draft-bestbar-spring-scalable-ns-00 provides a relevant example of the rather enormous amount of state the solution described in draft-dong-spring-sr-for-enhanced-vpn results in:

   "Notably, this approach requires maintaining per slice state for each
   topological element on every router in the network in both the
   control and data plane.  For example, a network composed of 'N'
   nodes, where each node has up to 'K' adjacencies to its neighbors, a
   node would have to assign and advertise 'M' Slice Prefix-SIDs and 'M'
   Slice Adjacency-SID(s) to each of it 'K' adjacencies.  Consequently,
   a router will have to maintain up to (N+K)*M SIDs in the control
   plane, and an equal number of label routes in its forwarding plane."

Put in practical terms, this implicitly limits the number of VTNs or, in draft-bestbar-teas-ns-packet-01 terminology, the number of Slice aggregates that can be offered.  It also introduces a dependency between the network size and the number of VTNs.  i.e. the larger the network, the smaller the number of VTNs that can be supported.

—Colby

> On Feb 2, 2021, at 12:54 PM, Tarek Saad <tsaad=[email-masked]> wrote:
> 
> Hi Eduard,
>  
> Inline..
>  
> On 2/2/21, 10:50 AM, "spring on behalf of Vasilenko Eduard" <[email-masked] on behalf of [email-masked]> wrote:
>  
> Hi all,

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 2 Feb 2021 14:54:02 -0500

Colby, you are, as far as I can tell, correct that the potential for 
state explosion is extremely risky and requires careful management. 
That is why the bestbar draft emphasis that the state is abotu slice 
aggregates, not end-to-end slices, and probably not even individual IETF 
network slices.

Yours,
Joel

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 3 Feb 2021 08:31:27 +0800

I support the adoption of this document. 
The capability of providing different services with customized virtual networks and resources is important for a multi-service network operator.

HUANAN CHEN（陈华南）
Data Communication Research Department
Research Institute of China Telecom Co.,Ltd.

From: James Guichard
Date: 2021-01-27 19:46
To: [email-masked]
CC: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
Dear WG:

 
Thanks!
 
Jim, Bruno & Joel

---

From: Zhuangzhuang Qin(联通北京市北京市分公司) <[email-masked]>
Date: Wed, 3 Feb 2021 12:56:49 +0000

Hi, WG:

I support the adoption. Using of resource-aware SIDs to build SR based VTNs is very helpful in building our 5G SA transport network.

Regards,

ZhuangZhuang Qin

发件人: James Guichard <[email-masked]>
日期: 2021年1月27日 星期三 下午7:46
收件人: "[email-masked]" <[email-masked]>
抄送: "[email-masked]" <[email-masked]>
主题: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

如果您错误接收了该邮件，请通过电子邮件立即通知我们。请回复邮件到 [email-masked]，即可以退订此邮件。我们将立即将您的信息从我们的发送目录中删除。 If you have received this email in error please notify us immediately by e-mail. Please reply to [email-masked] ,you can unsubscribe from this mail. We will immediately remove your information from send catalogue of our.

---

From: Greg Mirsky <[email-masked]>
Date: Wed, 3 Feb 2021 14:01:42 -0800

Dear All,
I've edited the subject though left the original line in place to indicate
the relationship between threads of discussion.
Several comments already have referenced *bestbar* drafts that, in my
understanding of them, propose a different solution to the problem
addressed in draft-dong-spring-sr-for-enhanced-vpn. The situation when more
than a single technical solution being offered is not unusual, probably
that is what one can expect at IETF. And I think that "let's ensure that
this is solid technical work while allowing the market to decide whether it
is better than others" is very reasonable and removes non-technical
considerations from a WG AP (or LC). If we use that paradigm, other
solutions, for example, *bestbar* drafts, would be considered for
adoption and, if adopted, progress on the Standards track. If that is what
the WG decides to do, standardize sound technical solutions, no matter how
many, then, by all means, I support it. What I feel uneasy about is if
adopting one proposal would create a situation preventing standardization
of other solutions. The WG faced a similar problem just recently and a
design team has been formed with a clear task and deliverables. Perhaps
another design team can be formed to work to analyze the problem and
proposed solutions? I've attempted to capture what seems to be relevant to
the problem:

   - related to the data plane

https://tools.ietf.org/html/draft-ali-spring-network-slicing-building-blocks-03

https://tools.ietf.org/html/draft-peng-teas-network-slicing-04

https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01

https://tools.ietf.org/html/draft-bestbar-spring-scalable-ns-00

https://tools.ietf.org/html/draft-decraene-mpls-slid-encoded-entropy-label-id-00

https://tools.ietf.org/html/draft-dong-6man-enhanced-vpn-vtn-id-02

https://tools.ietf.org/html/draft-filsfils-spring-srv6-stateless-slice-id-02

<https://tools.ietf.org/html/draft-ali-spring-network-slicing-building-blocks-03>

   - related to the control plane extensions:

https://tools.ietf.org/html/draft-zch-lsr-isis-network-slicing-06

https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01

https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-02

https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-05

https://tools.ietf.org/html/draft-dong-lsr-sr-enhanced-vpn-04

https://tools.ietf.org/html/draft-chen-idr-bgp-ls-transport-slice-02

https://tools.ietf.org/html/draft-xie-idr-bgpls-sr-vtn-mt-02

https://tools.ietf.org/html/draft-zhu-idr-bgpls-sr-vtn-flexalgo-00

https://tools.ietf.org/html/draft-chen-idr-bgp-ls-transport-slice-srv6-01

https://tools.ietf.org/html/draft-dong-idr-bgpls-sr-enhanced-vpn-02.

<https://tools.ietf.org/html/draft-zch-lsr-isis-network-slicing-06>

Regards, <https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01>

Greg

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 4 Feb 2021 02:23:39 +0000

Dear WG,

I support the WG adoption of the draft.
It is true that the enhanced-vpn mechanism requires additional processing.
For some special environment, such as the 5G  Edge Computing servers within  N6 network, some operators may be willing to add the additional processing (in the confined network) to achieve the desired QoS for the premium services.
In addition, with zero rating (or zero rating +) applications increase, the future may call for  more premium VPN+ services.

Linda Dunbar

From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 5:47 AM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Huaimo Chen <[email-masked]>
Date: Thu, 4 Feb 2021 02:24:04 +0000

Hi Everyone,

    I support for its WG adoption. It uses resource aware SIDs to provide different SR based Virtual Transport Networks for different service requirements from customers. In addition, One VTN may be separated from the others. This is useful.
    I have a couple of comments. In Section 2.2, "VTN.s" in the first sentence should be "VTNs.".  In section 3.2, it seems better also to add stateful PCE as a reference.

Best Regards,
Huaimo
________________________________
From: spring <[email-masked]> on behalf of James Guichard <[email-masked]>
Sent: Wednesday, January 27, 2021 6:46 AM
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

This message starts a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dong-spring-sr-for-enhanced-vpn%2F&data=04%7C01%7Chuaimo.chen%40futurewei.com%7C279f0709bae94787fa4f08d8c2b93a2c%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473448126500112%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0&sdata=L2XVwYEN3hJfTxqqI1ZH%2BhKWdL8nxhHSc3JSLCWjWyU%3D&reserved=0> ending February 10th 2021.

Thanks!

Jim, Bruno & Joel

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 4 Feb 2021 20:26:39 +0000

Greg,

Thank you very much for listing all those drafts related to Network Slicing.

But some of the drafts are only describing virtual partitioning of physical networks and methods to guarantee their end to end quality. Those virtual partitioning of one physical networks using tags (MPLS, VLAN, RT, etc.)  have been deployed for decades.

Is there any draft identifying the gaps between virtual partitioning of physical network and end to end Network Slicing?  In 3GPP, a Network Slice includes the capabilities to manage, control and orchestrate the subset of network resources independently from other Network Slices.

Linda Dunbar

From: spring <[email-masked]> On Behalf Of Greg Mirsky
Sent: Wednesday, February 3, 2021 4:02 PM
To: Adrian Farrel <[email-masked]>
Cc: James Guichard <[email-masked]>; spring <[email-masked]>; [email-masked]
Subject: [spring] When we have multiple proposals addressing the same problem [Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]

Dear All,
I've edited the subject though left the original line in place to indicate the relationship between threads of discussion.
Several comments already have referenced *bestbar* drafts that, in my understanding of them, propose a different solution to the problem addressed in draft-dong-spring-sr-for-enhanced-vpn. The situation when more than a single technical solution being offered is not unusual, probably that is what one can expect at IETF. And I think that "let's ensure that this is solid technical work while allowing the market to decide whether it is better than others" is very reasonable and removes non-technical considerations from a WG AP (or LC). If we use that paradigm, other solutions, for example, *bestbar* drafts, would be considered for adoption and, if adopted, progress on the Standards track. If that is what the WG decides to do, standardize sound technical solutions, no matter how many, then, by all means, I support it. What I feel uneasy about is if adopting one proposal would create a situation preventing standardization of other solutions. The WG faced a similar problem just recently and a design team has been formed with a clear task and deliverables. Perhaps another design team can be formed to work to analyze the problem and proposed solutions? I've attempted to capture what seems to be relevant to the problem:

  *   related to the data plane

https://tools.ietf.org/html/draft-ali-spring-network-slicing-building-blocks-03<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ali-spring-network-slicing-building-blocks-03&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284047643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=51SeXlrqKkEPcZlZ%2B1crrkbbd2zmgPmY2ZUlV%2B7tL94%3D&reserved=0>

https://tools.ietf.org/html/draft-peng-teas-network-slicing-04<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-peng-teas-network-slicing-04&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284047643%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Ehe%2B2jm5%2BId2FHzDmsuV6uB%2BCjjSBrY9vq2EHD6Lwhs%3D&reserved=0>

https://tools.ietf.org/html/draft-bestbar-teas-ns-packet-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bestbar-teas-ns-packet-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284057627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=C2NNOnyu5%2BB9RhZCGdNRcl34KSjPJhhBGtxXLn2%2BNwo%3D&reserved=0>

https://tools.ietf.org/html/draft-bestbar-spring-scalable-ns-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-bestbar-spring-scalable-ns-00&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284057627%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=vgrBT6GHXtqQmmCuzlpxiMG%2BP5lHoVbsKfeC671ZMJ8%3D&reserved=0>

https://tools.ietf.org/html/draft-decraene-mpls-slid-encoded-entropy-label-id-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-decraene-mpls-slid-encoded-entropy-label-id-00&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284067622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=bou6PkNKBYw2vpWL1Novlh%2B4Ohfa1lbR8EaeMcjUeJk%3D&reserved=0>

https://tools.ietf.org/html/draft-dong-6man-enhanced-vpn-vtn-id-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dong-6man-enhanced-vpn-vtn-id-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284067622%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=lsdX%2FQRDJw8%2BJ%2FDgJtG6mErs0DTQnIm1PeqNZbn5oTI%3D&reserved=0>

https://tools.ietf.org/html/draft-filsfils-spring-srv6-stateless-slice-id-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-filsfils-spring-srv6-stateless-slice-id-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284077616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=K3wuvuGj5haU%2F9q3iAYnAV3STPT5myVK2I8Nw4mrciE%3D&reserved=0>

  *   related to the control plane extensions:

https://tools.ietf.org/html/draft-zch-lsr-isis-network-slicing-06<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zch-lsr-isis-network-slicing-06&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284087610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=ftetWylCnasP1DtpOP44r4xwIKa%2B%2BM1AgV6eB69aLho%3D&reserved=0>

https://tools.ietf.org/html/draft-zhu-lsr-isis-sr-vtn-flexalgo-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhu-lsr-isis-sr-vtn-flexalgo-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284087610%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wnRokkAz33KV3ap%2FZfeygG97xY4fW5o9FjfibQPmQss%3D&reserved=0>

https://tools.ietf.org/html/draft-xie-lsr-isis-sr-vtn-mt-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-xie-lsr-isis-sr-vtn-mt-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284097608%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GBMS4s8E4vZWfohhaOP%2FTCSS5inBhEtEa3GWWS32AAY%3D&reserved=0>

https://tools.ietf.org/html/draft-peng-lsr-flex-algo-l2bundles-05<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-peng-lsr-flex-algo-l2bundles-05&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284117593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=xJQjtASnEIWrRmkHGU35x9AaKKwHS2sPI%2BN%2FTsNmyeU%3D&reserved=0>

https://tools.ietf.org/html/draft-dong-lsr-sr-enhanced-vpn-04<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dong-lsr-sr-enhanced-vpn-04&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284117593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=Cy5adYf2aA7MoJHH4xNY7pRSgPYiGlqcxyGeQhYFvQE%3D&reserved=0>

https://tools.ietf.org/html/draft-chen-idr-bgp-ls-transport-slice-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-idr-bgp-ls-transport-slice-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284127587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7C%2Bp9XSzzwRT2YFgsNMvZN9cl8arcV0EA1xKUSczgOU%3D&reserved=0>

https://tools.ietf.org/html/draft-xie-idr-bgpls-sr-vtn-mt-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-xie-idr-bgpls-sr-vtn-mt-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284127587%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=EAEEZWGVkgdV37PveAU55PUEf6fwxYRwqynFcd8%2FlpU%3D&reserved=0>

https://tools.ietf.org/html/draft-zhu-idr-bgpls-sr-vtn-flexalgo-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhu-idr-bgpls-sr-vtn-flexalgo-00&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284137580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FUAcv2MIb6l%2Fg78Rd9gyMYh5qEK3xmH1DwWFLqa6Q6E%3D&reserved=0>

https://tools.ietf.org/html/draft-chen-idr-bgp-ls-transport-slice-srv6-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-chen-idr-bgp-ls-transport-slice-srv6-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284137580%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=1sZQeDHREsTpGJTsX7FmMXBxyit5Fm6A80f8vDhMqD8%3D&reserved=0>

https://tools.ietf.org/html/draft-dong-idr-bgpls-sr-enhanced-vpn-02<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dong-idr-bgpls-sr-enhanced-vpn-02&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284147571%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=A%2Fyot%2FTvLE6pE8J05OAQokerlrvDC1NpbVEiWuHdf2w%3D&reserved=0>.

Regards,

Greg

On Sat, Jan 30, 2021 at 2:20 PM Adrian Farrel <[email-masked]<mailto:[email-masked]>> wrote:
Thanks, Jim,

I've been following the enhanced VPN work in TEAS and I see it as a key piece of the network slicing work.

It's time that we had some protocol solutions that serve the VPN framework, and this is a suitable starting point. I like that it is not specifying additional protocol widgets but has looked at what we already have and is pointing up ways to use those tools to deliver new function.

I see Robert's point about the resource reservation aspects of traffic engineering applied to an SR network, but this is not an insurmountable problem. The question might be asked, "Why would you want to do that?" but that is a question that (as Yakov would have said) the market can decide. It seems that there are a couple of vendors and a couple of operators who have an interest.

Cheers,
Adrian

Dear WG:

This message starts a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dong-spring-sr-for-enhanced-vpn%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284157569%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=18n%2FINEjeHbAkRirnct0YAHxP1neXCY386Yrwwanb28%3D&reserved=0> ending February 10th 2021.

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Ce8ca98ef08ee41f2335708d8c88f585d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637479865284167567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=FN6H4CR0LRYnTPF3gZuWS8KL88hACbL%2FsBOZYTZyLeQ%3D&reserved=0>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 5 Feb 2021 19:00:09 +0800

Working Group,

I have reviewed the draft and believe that it is a good starting point 
for the wg to create the Enhanced VPN standard.

/Loa

On 27/01/2021 19:46, James Guichard wrote:
> <https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/> ending 
> February 10^th 2021.
> 
> document, please state this explicitly. This gives the chairs an 
> indication of the energy level of people in the working group willing to 
> work on this document. Please also provide comments/reasons for your 
> support (or lack thereof) as this is a stronger way to indicate your 
> (non) support as this is not a vote.
> 
> Thanks!
> 
> Jim, Bruno & Joel
> 
> 

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Bronze Dragon Consulting             phone: +46 739 81 21 64

---

From: "Francois Clad (fclad)" <[email-masked]>
Date: Fri, 5 Feb 2021 14:46:15 +0000

Hi chairs, WG,

Support as a co-author.

Thanks,
Francois

Date: Wednesday, 27 January 2021 at 12:47

Thanks!

Jim, Bruno & Joel

---

From: Vishnu Pavan Beeram <[email-masked]>
Date: Fri, 5 Feb 2021 10:43:04 -0600

WG, Hi!

<draft-bestbar-spring-scalable-ns> advocates a couple of options for
determining which slice-aggregate the packet belongs to:
(a) Segment Range as Slice Selector
(b) Global Identifier as Slice Selector
In option (a), which is what is relevant
for draft-dong-spring-sr-for-enhanced-vpn, the following is advocated:

   ".. multiple per slice aggregate Prefix-SIDs (Slice Prefix-SIDs) can
   be assigned for the same prefix such that they all share the same IGP
   computed path over one topology and optimized for one algorithm to
   allow the steering of traffic to the same prefix along a path but
   over different slice aggregates.."

I have reviewed the latest version (rev 13) of
draft-dong-spring-sr-for-enhanced-vpn and it is good to see the above point
incorporated in section 2.3. Thanks to the authors for embracing this
important aspect – it does significantly enhance the scaling story for the
proposed solution.

Regards,
-Pavan

---

From: Ahmed MostafaSaleh ElSawaf <[email-masked]>
Date: Sat, 6 Feb 2021 15:26:36 +0000

Hello
I am Supporting  the adoption of this document. The mechanism provided in this document can help us to build customized virtual networks for different types of services with diverse performance requirements.

From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 2:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

The information in this email may contain confidential material and it is intended solely for the addresses. Access to this  email by anyone else is unauthorized. If you are not the intended recipient, please delete the email and destroy any copies of it, any disclosure, copying, distribution is prohibited and may be considered unlawful. Contents of this email and any attachments may be altered, Statement and opinions expressed in this email are those of the sender, and do not necessarily  reflect those of Saudi Telecommunications Company (STC).

---

From: <[email-masked]>
Date: Sun, 7 Feb 2021 11:53:12 +0800 (CST)

Hi WG/authors,

I have to point out that the VTN-ID in draft-dong-spring-sr-for-enhanced-vpn is actually the AII in draft-peng-teas-network-slicing, just a new name. That can be seen from the evolution of the historical versions of the these two drafts. 

I draw your attention to draft draft-peng-teas-network-slicing which analyzes in detail the reasons for the introduction of slice identifier (AII) in the network, and maintains the resource partition of each slice and the allocation of SID per AII in the network. All this happened before draft-dong-spring-sr-for-enhanced-vpn.

In addition, the idea that multiple slices share the same virtual topology (such as flex-algo) is also copied from draft-bestbar-teas-ns-packet, which can significantly reduce the state in the network, especially without maintaining SPT per slice, which means that multiple SIDs per slice can share the forwarding action of SPT per VN and at the same time can do resource guarantee by SID per slice (or slice-id in packet).

Thus, from a purely technical point of view, I see no reason for this document to be adopted. 

Regards,

PSF

原始邮件

发件人：JamesGuichard
收件人：[email-masked];
抄送人：[email-masked];
日 期 ：2021年01月27日 19:47
主 题 ：[spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

 

 

Thanks!

Jim, Bruno & Joel

---

From: <[email-masked]>
Date: Sun, 7 Feb 2021 12:14:56 +0800 (CST)

Hi Linda,

You mentioned that:

"Is there any draft identifying the gaps between virtual partitioning of physical network and end to end Network Slicing? "

In fact, draft-peng-teas-network-slicing has a detailed discussion on this gaps, see section "5.  Overview of Existing Identifiers". 

Although draft-peng-teas-network-slicing assumes the creation of a virtual topology per slice in the network, leading to scalability issues, that can be addressed with the combination of draft-bestbar-teas-ns-packet.

Note that SID per slice allocation by draft-peng-teas-network-slicing is resource-aware SID defined in draft-ietf-spring-resource-aware-segments. Although we all know that SID is allocated with associated resource within the context of slice requirements, draft-ietf-spring-resource-aware-segments makes the concept clear. Please don't use this concept to oppose other documents.

Regards,

PSF

原始邮件

发件人：LindaDunbar
收件人：Greg Mirsky;Adrian Farrel;
抄送人：James Guichard;spring;[email-masked];
日 期 ：2021年02月05日 04:27
主 题 ：Re: [spring] When we have multiple proposals addressing the same problem [Re: WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn]

Greg,

 

 

 

Linda Dunbar

 

Dear All,

related to the data plane

related to the control plane extensions:

Regards,

Greg

Thanks, Jim,

 

 

 

 

Cheers,

Adrian

 

Dear WG:

 

 

Thanks!

Jim, Bruno & Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Sun, 7 Feb 2021 06:08:13 +0000

From: spring [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, February 7, 2021 11:53 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG/authors,

[Jie] The VTN (virtual network) concept is introduced in draft-ietf-teas-enhanced-vpn, which is long before the draft you mentioned.

In control plane, a VTN can be identified by existing control plane IDs, and VTN-ID is used when multiple VTNs share the same topology. IMO this is different from what the AII is used for.

[Jie] If you follow the SPRING WG closely, you would know that the first version of draft-dong-spring-sr-for-enhanced-vpn was submitted in March 2018, which is one and a half year earlier than the draft you mentioned.

And if you want people to read or discuss another draft, you could start a thread in the WG which the draft belongs to.

[Jie] The mechanism of multiple VTNs sharing the same topology was first described in draft-dong-teas-enhanced-vpn-vtn-scalability one year ago in Feb 2020. Further discussion about the scalability optimizations in that document will happen in the TEAS WG.

Best regards,

Jie

Regards,

PSF

原始邮件
发件人：JamesGuichard
收件人：[email-masked]<mailto:[email-masked]>;
抄送人：[email-masked]<mailto:[email-masked]>;
日 期 ：2021年01月27日 19:47
主 题 ：[spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
_______________________________________________
spring mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/spring
Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: <[email-masked]>
Date: Sun, 7 Feb 2021 18:14:45 +0800 (CST)

Hi Jie,

Thanks for you reply. 

Please see in-line [PSF]

Regards,

PSF

 

Hi WG/authors,

[PSF] No, Let's look at the timeline. 

[PSF] draft-peng-lsr-network-slicing-00 (February 25, 2019) first discussed the introduction of slice based identifier in control plane and forwarding plane, which we call AII.

[PSF] Before that, the previous control plane schemes of Enhanced VPN, such as draft-dong-lsr-sr-enhanced-vpn-01 (October 22, 2018), have been discussed always based on MTR ID. You originally think that a slice is an MTR.

[PSF] After that, the later control plane schemes of Enhanced VPN, such as draft-dong-lsr-sr-enhanced-vpn-02 (November 4, 2019), also discussed the introduction of slice based identifier in control plane and forwarding plane, which you call TNSI.

[PSF] In fact, VTN was formally defined till in draft-ietf-teas-enhanced-vpn-05 (2020.2.18). Before that, you mentioned that it is a sub topology that is a virtual SR network composed of a group of SIDs (with associated resources). However, it does not describe how to create this virtual SR network. That is the key issue. Note that the so-called "using a set of SIDs to form a virtual SR network" is putting the cart before the horse. My means is that, for example, people can create Flex-algo plane based on the key ID, i.e, algorithm with its related FAD, while SID per algorithm is just an attribute of the created Flex-algo plane. Nobody knows how the Flex-algo plane is created just according to "a set of SIDs per algorithm". 

[PSF] Anyway, what I mentioned is a slice based ID introduced in the control and forwarding plane, but you mention VTN concept, they are NOT the same thing. Once the slice based ID is introduced, it can be used to distinguish which slice the service belongs to, and that is not related with whether different slice can or not share the same topology. 

[PSF] Sure, but it seems that it has no substance mechanism to create the virtual SR network? You might say "using a set of SIDs to form a virtual SR network", that is  putting the cart before the horse IMO.

[PSF] Thanks for clarification for this point. draft-bestbar-spring-scalable-ns clearly desribed that multiple per slice Prefix-SIDs (Slice Prefix-SIDs) can be assigned for the same prefix such that they all share the same IGP computed path over one topology and optimized for one algorithm to allow the steering of traffic to the same prefix along a path but over different network slices. If that is exactly what did draft-dong-teas-enhanced-vpn-vtn-scalability(5.1. Control Plane Optimization) want to do, I suggest adding an explicit description similar as draft-bestbar-spring-scalable-ns.

Best regards,

Jie

Regards,

PSF

原始邮件

发件人：JamesGuichard

收件人：[email-masked];

日 期 ：2021年01月27日 19:47

Dear WG:

 

 

Thanks!

Jim, Bruno & Joel

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 7 Feb 2021 12:39:44 -0000

I think that, before jumping in to criticise draft-dong-spring-sr-for-enhanced-vpn too much for the *potential* for state explosion, everyone should read draft-ietf-teas-enhanced-vpn and draft-dong-teas-enhanced-vpn-vtn-scalability with some care (as Pavan appears to have done :-) to see the difference between a slice and a slice. The VTN construct is a virtual network topology with associated resources (a macro slice, if you like) that can support multiple network slices or enhanced VPNs that are subject to the same class of treatment (micro slices, perhaps). The number of VTNs need not be large although, my understanding is that the authors do not prevent operators from deciding to shoot themselves.

One could, if so minded, call the VTN a "slice aggregate".

Cheers,
Adrian

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Joel M. Halpern
Sent: 02 February 2021 19:54
To: Colby Barth <[email-masked]>; [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Yours,
Joel

---

From: Tianran Zhou <[email-masked]>
Date: Sun, 7 Feb 2021 13:17:02 +0000

"Thus, from a purely technical point of view, I see no reason for this document to be adopted.”

Could you please explain the technical point why this document can’t be adopted?

IMO, all your statements just show support and consensus on the technology.

Tianran

Sent from WeLink
发件人： peng.shaofu<[email-masked]<mailto:[email-masked]>>
收件人： james.n.guichard<[email-masked]<mailto:[email-masked]>>
抄送： spring<[email-masked]<mailto:[email-masked]>>;spring-chairs<[email-masked]<mailto:[email-masked]>>
主题： Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn
时间： 2021-02-07 11:53:59

Hi WG/authors,

Regards,

PSF

原始邮件
发件人：JamesGuichard
收件人：[email-masked];

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: Tarek Saad <[email-masked]>
Date: Mon, 8 Feb 2021 15:13:45 +0000

I agree with Shaofu. A slice aggregate is independent of the forwarding plane (i.e. it is not a virtual network). A single flex-algo (that defines a forwarding plane) can be sliced into multiple slice-aggregates. If per slice SIDs are used, it allows IGP to share the forwarding next-hops for each of those slice SIDs (i.e., makes determining SID next-hop independent of # of slice-aggregates). This was described in detail in draft-bestbar-spring-scalable-ns. It’s good to see draft-dong-spring-sr-for-enhanced-vpn has incorporated this change from draft-bestbar-spring-scalable-ns in its latest rev.

Regards,
Tarek

On 2/6/21, 10:53 PM, "spring on behalf of [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi WG/authors,

Regards,

PSF

原始邮件
发件人：JamesGuichard
收件人：[email-masked];

Thanks!

Jim, Bruno & Joel

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 9 Feb 2021 01:04:50 +0900

Hi WG,

I think that this document is good enough as starting point for the WG, and
I support the adoption. There are many drafts related to network slice with
SR (e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I
hope it will be clarified which is the best in future work.

The following are my comments to the draft.
- The example describes three isolated VTNs. I assume (hard) isolation will
cause split loss, and oversubscription will be sometimes needed. Hence, it
may be better to allow a resource-aware SID to belong to multiple VTNs.

- From network slicing (i.e., NaaS model) perspective, I assume visibility
will be especially important. As one more important requirement, network
operators want to provide only information of the VTN whose customer uses
to that customer. For example, if a customer gets VTN information with
BGP-LS, some mechanisms to prevent to leak other VTNs information in BGP-LS
would be needed.

- There is a typo in figure2. The adj-SID of the link from 203 to 204 in
green VTN should be 2002.

Regards,

Shunsuke

---

From: <[email-masked]>
Date: Tue, 9 Feb 2021 11:54:27 +0800 (CST)

Hi WG,

What are the advantages of this draft compared with other drafts? (such as draft-bestbar-spring-scalable-ns, draft-peng-lsr-network-slicing),and is it just explain the concept of virtual SR network beyond the concept of resource-aware SID? 

Many people are thinking about how to realize slicing in the network and made many contributions. Although I am originally a co-author of draft draft-peng-lsr-network-slicing, I think so far draft-bestbar-spring-scalable-ns, comparatively speaking, is to grasp the essence of the problem, and have a complete thoughts.

So, I do not think draft-dong-spring-sr-for-enhanced-vpn is now ready to become a working group draft.

Best Regards,

Ran

原始邮件

发件人：JamesGuichard
收件人：[email-masked];

Dear WG:

 

 

Thanks!

Jim, Bruno & Joel

---

From: Yingzhen Qu <[email-masked]>
Date: Mon, 8 Feb 2021 21:39:02 -0800

Hi,

I support the WG adoption of this draft, and I believe it’s a good starting point for the WG to work on this topic, and see how existing technologies can be integrated to provide new capabilities.

Resource reservation has always been a controversial topic, whether it is needed, or efficient, or can it scale? Can we just deliver low latency service with high bandwidth? All these are valid questions, as a WG we can continue to improve the solutions and make the deployments easier. As Adrian said the market will decide whether this is the right technology or the right timing. 

So I support the adoption of this draft and I’m willing to work on it.

Thanks,
Yingzhen

> This message starts a 2 week WG adoption call for https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/ <https://datatracker.ietf.org/doc/draft-dong-spring-sr-for-enhanced-vpn/> ending February 10th 2021.
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 9 Feb 2021 06:46:49 +0000

Hi Shunsuke,

Thanks a lot for your review and comments. Please see some replies inline:

From: spring [mailto:[email-masked]] On Behalf Of Shunsuke Homma
Sent: Tuesday, February 9, 2021 12:05 AM
To: James Guichard <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Hi WG,

I think that this document is good enough as starting point for the WG, and I support the adoption. There are many drafts related to network slice with SR (e.g., SR + Flex-algo, draft-bestbar-spring-scalable-ns, etc.) and I hope it will be clarified which is the best in future work.

[Jie] Thanks for your support.

The following are my comments to the draft.
- The example describes three isolated VTNs. I assume (hard) isolation will cause split loss, and oversubscription will be sometimes needed. Hence, it may be better to allow a resource-aware SID to belong to multiple VTNs.

[Jie] In the context of SR based VTN, each resource-aware SID is associated with one VTN. Multiple services which are mapped to the same VTN can use the same group of SIDs to guide the packet forwarding, thus  a resource-aware SID and the associated resources can be shared by multiple services.

- From network slicing (i.e., NaaS model) perspective, I assume visibility will be especially important. As one more important requirement, network operators want to provide only information of the VTN whose customer uses to that customer. For example, if a customer gets VTN information with BGP-LS, some mechanisms to prevent to leak other VTNs information in BGP-LS would be needed.

[Jie] Yes, depends on the operator’s policy, the amount and the granularity of information exposed to a customer should be controlled. The considerations about this is described in section 3.5 VTN Visibility to Customer. The required control plane mechanism can be based on  BGP-LS mechanism in RFC7752 (and the in progress draft-7752bis), some extension may be introduced if needed.

- There is a typo in figure2. The adj-SID of the link from 203 to 204 in green VTN should be 2002.

[Jie] Thanks for catching the typo. We will fix it in next revision.

Best regards,
Jie

Regards,

Shunsuke

On Wed, Jan 27, 2021 at 8:47 PM James Guichard <[email-masked]<mailto:[email-masked]>> wrote:
Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Chengli (Cheng Li)" <[email-masked]>
Date: Wed, 10 Feb 2021 03:55:35 +0000

Hi SPRING,

I have read the document and think it is mature and ready to be adopted.

This document describes how to implement SR-based VTN using resource-aware SIDs, which is very helpful for people to understand.

I would like to work on it as well!  :)

Thanks to the authors!
Cheng

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]" <[email-masked]>
Date: Wed, 10 Feb 2021 11:26:49 +0000

Dear WG
I support the adoption of this document. It describes a useful mechanism to build multiple SR based virtual networks for different purposes.

​Warm regards,
Luc-Fabrice
 
Ndifor
Specialist - IP Access and Data center
[email-masked]
T +237 677 55 02 13
Head Office: 360, Rue Drouot
​P.O. Box 15 574 Douala, Cameroon
T +237 679 00 90 90
 | mtn.cm
This email is confidential. If you have received it in error, you are on notice of its status. Please notify ​the ​​sender immediately by 
​reply email and then delete this message from your system. Please do not copy it ​or use it for any purpose or disclose its content 
​to any other person as to do so could be a breach of ​confidentiality.
​
 Please be informed that no employee or agent is authorized to conclude any legally binding agreement ​on behalf of MTN Cameroon
​via email. This can be only done if the email is confirmed explicitly in writing ​by an MTN Cameroon authorized officer. In no event 
​will this email or its content be construed as a written ​approval.
From: spring <[email-masked]> On Behalf Of James Guichard
Sent: Wednesday, January 27, 2021 12:47 PM
To: [email-masked]
Cc: [email-masked]
Subject: [spring] WG Adoption Call for draft-dong-spring-sr-for-enhanced-vpn

Dear WG:

Thanks!

Jim, Bruno & Joel

---

From: "Luis M. Contreras" <[email-masked]>
Date: Wed, 10 Feb 2021 19:31:26 +0100

Hi all,

acknowledging the scalability concerns discussed on the list, I think there
could be some scenarios that could be yet benefited from this approach. So
I'm in favor of supporting the adoption of the document.

Best regards

Luis

-- 
___________________________________________
Luis M. Contreras
[email-masked]
[email-masked]
Global CTIO unit / Telefonica