Subject: [spring] Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 19 May 2020 10:37:59 +0000

Hi all,

The latest version of draft-dong-spring-sr-for-enhanced-vpn was uploaded in March, which describes a generic enhancement to SR to support resource representation and identification, by introducing the resource semantics to SR SIDs. With such enhancement, SR could be used not only for explicit path steering, but could also be used to build resource guaranteed paths or virtual networks. Such SR based resource guaranteed paths or virtual networks can be used as the underlay to support different VPN services. The mechanism introduced in this document is complementary to the existing SR functionalities, and helps to complete the tool set of segment routing.

Based on the discussion on mail list and the presentations on previous IETF meetings, this draft has been revised several times, all the comments received so far has been resolved and reflected in the current version. To move forward, the authors would like to know if there are further comments on this document, and people's opinion on whether it is in the right direction.

Comments and feedbacks are welcome.

Best regards,
Jie

---

From: <[email-masked]>
Date: Wed, 20 May 2020 16:38:09 +0800

Hi,

SR is widely accepted as an important technology to provide source routing
in operator networks. In order to meet the requirement of some services and
customers in our network, we always expect that resource reservation
capability can be introduced in SR. In my opinion this document provides an
useful enhancement to SR, and is in the right direction to move forward. 

Thanks.

B.R.

Zhu Yongqing

发件人: spring <[email-masked]> 代表 Dongjie (Jimmy)
发送时间: 2020年5月19日 18:38
收件人: SPRING WG <[email-masked]>
抄送: [email-masked]
主题: [spring] Progressing draft-dong-spring-sr-for-enhanced-vpn to enable
SR with resource management

Hi all,

The latest version of draft-dong-spring-sr-for-enhanced-vpn was uploaded in
March, which describes a generic enhancement to SR to support resource
representation and identification, by introducing the resource semantics to
SR SIDs. With such enhancement, SR could be used not only for explicit path
steering, but could also be used to build resource guaranteed paths or
virtual networks. Such SR based resource guaranteed paths or virtual
networks can be used as the underlay to support different VPN services. The
mechanism introduced in this document is complementary to the existing SR
functionalities, and helps to complete the tool set of segment routing.

Based on the discussion on mail list and the presentations on previous IETF
meetings, this draft has been revised several times, all the comments
received so far has been resolved and reflected in the current version. To
move forward, the authors would like to know if there are further comments
on this document, and people’s opinion on whether it is in the right
direction. 

Best regards,

Jie

---

From: "qinfengwei" <[email-masked]>
Date: Thu, 21 May 2020 10:47:09 +0800

Hi all,

         At present, 5G applications have been widely developed, recently,
many enterprises require dedicated network resources to achieve isolation
from other services in the network, such as southern power grid, Migu live
video and Tencent cloud games. This document provides the mechanism to
enhance SR with resource identification capability. This is an important
feature to meet different customer’s requirement in our network. Thus we
believe it is a generic and useful enhancement to SR, and hope it could move
forward quickly in the WG.

 

Thanks,

Fengwei Qin

发件人: spring [mailto:[email-masked]] 代表 Dongjie (Jimmy)
发送时间: 2020年5月19日 18:38
收件人: SPRING WG
抄送: [email-masked]
主题: [spring] Progressing draft-dong-spring-sr-for-enhanced-vpn to enable
SR with resource management

Hi all,

Best regards,

Jie

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 20 May 2020 23:01:06 -0400

This email (and the underlying document) asserts a need for "isolation" 
without defining isolation, and without recognizing that the service 
needs can be met by existing packet technologies.

The document also asserts that resource management requires packet based 
resource reservation.  We have significant evidence that diffserv 
treatment coupled with central (PCE or equivalent) resource management 
can address these needs.

At the very least, the discussion of isolation should be removed from 
the document before it is evaluated for adoption.

Yours,
Joel

On 5/20/2020 10:47 PM, qinfengwei wrote:
> Hi all,
> 
> At present, 5G applications have been widely developed, recently, many 
> enterprises require dedicated network resources to achieve isolation 
> from other services in the network, such as southern power grid, Migu 
> live video and Tencent cloud games. This document provides the mechanism 
> to enhance SR with resource identification capability. This is an 
> important feature to meet different customer’s requirement in our 
> network. Thus we believe it is a generic and useful enhancement to SR, 
> and hope it could move forward quickly in the WG.
> 
> Thanks,
> 
> Fengwei Qin
> 
> *发件人:*spring [mailto:[email-masked]] *代表 *Dongjie (Jimmy)
> *发送时间:*2020年5月19日18:38
> *收件人:*SPRING WG
> *抄送:[email-masked]
> *主题:*[spring] Progressing draft-dong-spring-sr-for-enhanced-vpn to 
> enable SR with resource management
> 
> Hi all,
> 
> The latest version of draft-dong-spring-sr-for-enhanced-vpn was uploaded 
> in March, which describes a generic enhancement to SR to support 
> resource representation and identification, by introducing the resource 
> semantics to SR SIDs. With such enhancement, SR could be used not only 
> for explicit path steering, but could also be used to build resource 
> guaranteed paths or virtual networks. Such SR based resource guaranteed 
> paths or virtual networks can be used as the underlay to support 
> different VPN services. The mechanism introduced in this document is 
> complementary to the existing SR functionalities, and helps to complete 
> the tool set of segment routing.
> 
> Based on the discussion on mail list and the presentations on previous 
> IETF meetings, this draft has been revised several times, all the 
> comments received so far has been resolved and reflected in the current 
> version. To move forward, the authors would like to know if there are 
> further comments on this document, and people’s opinion on whether it is 
> in the right direction.
> 
> _______________________________________________
> spring mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spring
>

---

From: "Aijun Wang" <[email-masked]>
Date: Thu, 21 May 2020 19:56:02 +0800

Hi, Joel:

There are some descriptions in
https://datatracker.ietf.org/doc/html/draft-dong-spring-sr-for-enhanced-vpn-
07#section-5 for the aim of "isolation". Maybe it is needed defined first in
the document.
And the document also say that "Also the number of such enhanced services
can be larger than the number of traffic classes with DiffServ QoS." in
"Introduction" section, then "diffserv treatment together with PCE" can't
meet the requirements in VPN clients granularity.

And after reviewing the document, I think it is ready for the WG adoption
for further discussion.

Best Regards.

Aijun Wang
China Telecom

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Joel
M. Halpern
发送时间: 2020年5月21日 11:01
收件人: qinfengwei; 'Dongjie (Jimmy)'; 'SPRING WG'
抄送: [email-masked]
主题: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn
to enable SR with resource management

This email (and the underlying document) asserts a need for "isolation" 
without defining isolation, and without recognizing that the service needs
can be met by existing packet technologies.

The document also asserts that resource management requires packet based
resource reservation.  We have significant evidence that diffserv treatment
coupled with central (PCE or equivalent) resource management can address
these needs.

At the very least, the discussion of isolation should be removed from the
document before it is evaluated for adoption.

Yours,
Joel

On 5/20/2020 10:47 PM, qinfengwei wrote:
> live video and Tencent cloud games. This document provides the 
> mechanism to enhance SR with resource identification capability. This 
> is an important feature to meet different customer’s requirement in 
> our network. Thus we believe it is a generic and useful enhancement to 
> SR, and hope it could move forward quickly in the WG.
> 
> Thanks,
> 
> Fengwei Qin
> 
> The latest version of draft-dong-spring-sr-for-enhanced-vpn was 
> uploaded in March, which describes a generic enhancement to SR to 
> support resource representation and identification, by introducing the 
> resource semantics to SR SIDs. With such enhancement, SR could be used 
> not only for explicit path steering, but could also be used to build 
> resource guaranteed paths or virtual networks. Such SR based resource 
> guaranteed paths or virtual networks can be used as the underlay to 
> support different VPN services. The mechanism introduced in this 
> document is complementary to the existing SR functionalities, and 
> helps to complete the tool set of segment routing.
> 
> comments received so far has been resolved and reflected in the 
> current version. To move forward, the authors would like to know if 
> there are further comments on this document, and people’s opinion on 
> whether it is in the right direction.
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 21 May 2020 13:07:08 +0000

Hi Joel, 

Thanks for your comment. 

In this document, isolation means resource isolation, more specifically, a set of dedicated network resources are allocated on a group of network nodes and links, and SR SIDs are used to represent the allocated network resources. As mentioned by Aijun, this is described in section 5, it could be clarified earlier in the draft if needed.

As for your statement regarding diffserv, I agree it has been widely used in network thanks to its simplicity and scalability. Whether it can address all services needs may be questionable. In IETF there have been many efforts to meet specific service requirements by reserving network resources, such as RSVP-TE, Detnet, etc. This draft aims to enhance SR with such capability. 

Best regards,
Jie

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Thursday, May 21, 2020 11:01 AM
> To: qinfengwei <[email-masked]>; Dongjie (Jimmy)
> <[email-masked]>; 'SPRING WG' <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [spring] 答复: Progressing
> draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource
> management
>

---

From: "qinfengwei" <[email-masked]>
Date: Thu, 21 May 2020 21:54:55 +0800

Hi Joel,

Diffserv is used in our network for class-based differentiated services.
Multiple types of services are grouped into the same traffic class. Diffserv
mechanism has good scalability, while services in the same class cannot be
distinguished, thus services/customers in the same class may impact each
other. To meet the strict demand of some services/customers, a set of
network resource needs to be reserved. This can be done with RSVP-TE, now we
expect SR to provide similar capability.

Recently, we provide the network service for Migu live video, and ensure our
network with SDN and Diffserv, which could meet their requirement, but they
forced us to provide a dedicated resource reservation, which avoid the
impact on the business in the case of network micro emergencies. Recently,
lots of services have raised different SLA. This draft could resolve the
issues and I think it is ready for the WG adoption for further discussion.

Thanks,
Fengwei Qin

-----邮件原件-----
发件人: Joel M. Halpern [mailto:[email-masked]] 
发送时间: 2020年5月21日 11:01
收件人: qinfengwei; 'Dongjie (Jimmy)'; 'SPRING WG'
抄送: [email-masked]
主题: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn

Yours,
Joel

---

From: Joel Halpern Direct <[email-masked]>
Date: Thu, 21 May 2020 10:08:03 -0400

Part of my concern is that the document claims that this technique is 
necessary to use resource reservation with segment routing.  Given that 
we know there are existing ways people do use resource reservation with 
SR, it is not necessary.

The term "isolation" has been extensively debated in the traffic 
engineering working group, and the proponents have not been able to make 
a clear case for it.

Yours,
Joel

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 25 May 2020 02:54:39 +0000

Hi Joel,

Could you provide some reference in IETF to the "existing ways to do resource reservation with SR" you mentioned?

Regarding the term isolation, my suggestion is to keep that generic discussion in TEAS. In the context of this draft, as described in the draft and mails, the meaning is "allocating dedicated network resources", i.e. resource isolation,  the description could be clarified further.

Best regards,
Jie

> From: Joel Halpern Direct [mailto:[email-masked]]
> Sent: Thursday, May 21, 2020 10:08 PM
> To: Dongjie (Jimmy) <[email-masked]>; qinfengwei
> <[email-masked]>; 'SPRING WG' <[email-masked]>
> necessary to use resource reservation with segment routing.  Given that we
> know there are existing ways people do use resource reservation with SR, it is
> not necessary.
> 
> The term "isolation" has been extensively debated in the traffic engineering
> working group, and the proponents have not been able to make a clear case
> for it.
> 
> Yours,
> Joel
> 
> > In this document, isolation means resource isolation, more specifically, a
> set of dedicated network resources are allocated on a group of network
> nodes and links, and SR SIDs are used to represent the allocated network
> resources. As mentioned by Aijun, this is described in section 5, it could be
> clarified earlier in the draft if needed.
> >
> > As for your statement regarding diffserv, I agree it has been widely used in
> network thanks to its simplicity and scalability. Whether it can address all
> services needs may be questionable. In IETF there have been many efforts to
> meet specific service requirements by reserving network resources, such as
> RSVP-TE, Detnet, etc. This draft aims to enhance SR with such capability.
> >
> > Best regards,
> > Jie
> >
> >> The document also asserts that resource management requires packet
> >> based resource reservation.  We have significant evidence that
> >> diffserv treatment coupled with central (PCE or equivalent) resource
> >> management can address these needs.
> >>
> >>> many enterprises require dedicated network resources to achieve
> >>> isolation from other services in the network, such as southern power
> >>> grid, Migu live video and Tencent cloud games. This document
> >>> provides the mechanism to enhance SR with resource identification
> >>> capability. This is an important feature to meet different
> >>> customer’s requirement in our network. Thus we believe it is a
> >>> generic and useful enhancement to SR, and hope it could move forward
> quickly in the WG.
> >>>
> >>> Thanks,
> >>>
> >>> Fengwei Qin
> >>>
> >>> support resource representation and identification, by introducing
> >>> the resource semantics to SR SIDs. With such enhancement, SR could
> >>> be used not only for explicit path steering, but could also be used
> >>> to build resource guaranteed paths or virtual networks. Such SR
> >>> based resource guaranteed paths or virtual networks can be used as
> >>> the underlay to support different VPN services. The mechanism
> >>> introduced in this document is complementary to the existing SR
> >>> Based on the discussion on mail list and the presentations on
> >>> previous IETF meetings, this draft has been revised several times,
> >>> all the comments received so far has been resolved and reflected in
> >>> the current version. To move forward, the authors would like to know
> >>> if there are further comments on this document, and people’s opinion
> >>> on whether it is in the right direction.
> >>>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 24 May 2020 23:30:46 -0400

No, there probably is no IETF reference.  The techniques I can think of 
do not have interoperability issues, and therefore are not IETF 
standards. They are just operations on a controller, where the 
controller manages resource allocations.  These were discussed in slide 
presentations in the early work on SR.

And I am sure there are other ways that I do not know of.

Yours,
Joel

---

From: Mach Chen <[email-masked]>
Date: Mon, 25 May 2020 07:26:45 +0000

Hi,

Is the "resource allocation" performed only on the controller? If so, sounds like a virtual resource reservation, or somehow it is more accurate to call it resource planning. In this case, the interoperability issues may not be the most concerns. The problem is how to guarantee the resource reservation on the data plane, how to prevent resource reserved for one application from using by another application. 

With current SR, operator can do resource and traffic planning on controller, while there is no way for the devices to differentiate traffic over the same link or to the same destination, because the SID used by all the flows are the same. Thus devices cannot perform resource reservation for specific customer or service.

Best regards,
Mach

> From: spring [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Monday, May 25, 2020 11:31 AM
> No, there probably is no IETF reference.  The techniques I can think of do not
> have interoperability issues, and therefore are not IETF standards. They are
> just operations on a controller, where the controller manages resource
> allocations.  These were discussed in slide presentations in the early work
> on SR.
> 
> > Could you provide some reference in IETF to the "existing ways to do
> resource reservation with SR" you mentioned?
> >
> > Regarding the term isolation, my suggestion is to keep that generic
> discussion in TEAS. In the context of this draft, as described in the draft and
> mails, the meaning is "allocating dedicated network resources", i.e. resource
> isolation,  the description could be clarified further.
> >
> > Best regards,
> > Jie
> >
> >> necessary to use resource reservation with segment routing.  Given
> >> that we know there are existing ways people do use resource
> >> reservation with SR, it is not necessary.
> >>
> >> engineering working group, and the proponents have not been able to
> >> make a clear case for it.
> >>
> >> Yours,
> >> Joel
> >>
> >> set of dedicated network resources are allocated on a group of
> >> network nodes and links, and SR SIDs are used to represent the
> >> allocated network resources. As mentioned by Aijun, this is described
> >> in section 5, it could be clarified earlier in the draft if needed.
> >>>
> >> network thanks to its simplicity and scalability. Whether it can
> >> address all services needs may be questionable. In IETF there have
> >> been many efforts to meet specific service requirements by reserving
> >> network resources, such as RSVP-TE, Detnet, etc. This draft aims to
> enhance SR with such capability.
> >>>
> >>> Best regards,
> >>> Jie
> >>>
> >>>> without defining isolation, and without recognizing that the
> >>>> service needs can be met by existing packet technologies.
> >>>>
> >>>> diffserv treatment coupled with central (PCE or equivalent)
> >>>> resource management can address these needs.
> >>>>
> >>>> At the very least, the discussion of isolation should be removed
> >>>> from the document before it is evaluated for adoption.
> >>>>
> >>>> Yours,
> >>>> Joel
> >>>>
> >>>>> isolation from other services in the network, such as southern
> >>>>> power grid, Migu live video and Tencent cloud games. This document
> >>>>> be used not only for explicit path steering, but could also be
> >>>>> used to build resource guaranteed paths or virtual networks. Such
> >>>>> SR based resource guaranteed paths or virtual networks can be used
> >>>>> as the underlay to support different VPN services. The mechanism
> >>>>> all the comments received so far has been resolved and reflected
> >>>>> in the current version. To move forward, the authors would like to
> >>>>> know if there are further comments on this document, and people’s
> >>>>> opinion on whether it is in the right direction.
> >>>>>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 25 May 2020 12:12:15 +0000

Mach and all,

From my POV saying that " With current SR ... there is no way for the devices to differentiate traffic over the same link or to the same destination, because the SID used by all the flows are the same" is inaccurate.

AFAIK it is perfectly possible to associate multiple Prefix-SIDs with the same destination prefix by associating them either with different topologies or with different algorithms (or even with a combination of these two parameters).

It is also possible to associate multiple Adj-SIDs (if you want to use them) with the same IGP adjacency by associating them with different topologies (but not with different algorithms).

Therefore it seems that the following recommendations from Section 2.1 of the draft are adequately addressed by the already defined SR-MPLS mechanisms:

   For one IGP link, multiple Adj-SIDs SHOULD be allocated, each of
   which is associated with a virtual network it participates, and MAY
   represent a subset of link resources

...

   Similarly, for one IGP node, multiple prefix-SIDs SHOULD be

   allocated, each of which is associated with a virtual network , and

   MAY represent a subset of the node resource

There may be valid reasons not to use these mechanisms for associating multiple SIDs with a given destination prefix or an IGP adjacency, but the draft does not mention any such reasons.

I defer to others to decide whether existing SRv6 mechanisms are sufficient for addressing similar requirements in Section 2.2 of the draft.

I also wonder whether draft-dong is a valid candidate for the Standards Track document since it does not define any specific protocol elements.  My gut feeling is that it could be a better fit for an Informational document.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

Email:   [email-masked]

-----Original Message-----
From: spring <[email-masked]> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; qinfengwei <[email-masked]>; 'SPRING WG' <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi,

Best regards,

Mach

> From: spring [mailto:[email-masked]] On Behalf Of Joel M.

> Halpern

> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei

> <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>

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

> No, there probably is no IETF reference.  The techniques I can think

> of do not have interoperability issues, and therefore are not IETF

> controller manages resource allocations.  These were discussed in

> slide presentations in the early work on SR.

> discussion in TEAS. In the context of this draft, as described in the

> draft and mails, the meaning is "allocating dedicated network

> resources", i.e. resource isolation,  the description could be clarified further.

> >> To: Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei

> >> <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>

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

> >> Part of my concern is that the document claims that this technique

> >> is necessary to use resource reservation with segment routing.

> >> Given that we know there are existing ways people do use resource

> >>> In this document, isolation means resource isolation, more

> >>> specifically, a

> >> allocated network resources. As mentioned by Aijun, this is

> >> described in section 5, it could be clarified earlier in the draft if needed.

> >>> As for your statement regarding diffserv, I agree it has been

> >>> widely used in

> >> been many efforts to meet specific service requirements by

> >> reserving network resources, such as RSVP-TE, Detnet, etc. This

> >> draft aims to

> >>>> To: qinfengwei <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy)

> >>>> <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>

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

> >>>> The document also asserts that resource management requires

> >>>> packet based resource reservation.  We have significant evidence

> >>>> that diffserv treatment coupled with central (PCE or equivalent)

> >>>>> At present, 5G applications have been widely developed,

> >>>>> recently, many enterprises require dedicated network resources

> >>>>> to achieve isolation from other services in the network, such as

> >>>>> southern power grid, Migu live video and Tencent cloud games.

> >>>>> This document provides the mechanism to enhance SR with resource

> >>>>> identification capability. This is an important feature to meet

> >>>>> different customer’s requirement in our network. Thus we believe

> >>>>> it is a generic and useful enhancement to SR, and hope it could

> >>>>> move forward

> >>>>> *发件人:*spring [mailto:[email-masked]] *代表 *Dongjie

> >>>> (Jimmy)

> >>>>> *主题:*[spring] Progressing draft-dong-spring-sr-for-enhanced-vpn

> >>>>> uploaded in March, which describes a generic enhancement to SR

> >>>>> to support resource representation and identification, by

> >>>>> introducing the resource semantics to SR SIDs. With such

> >>>>> enhancement, SR could be used not only for explicit path

> >>>>> steering, but could also be used to build resource guaranteed

> >>>>> paths or virtual networks. Such SR based resource guaranteed

> >>>>> different VPN services. The mechanism introduced in this

> >>>>> document is complementary to the existing SR functionalities, and helps to complete the tool set of segment routing.

> >>>>> previous IETF meetings, this draft has been revised several

> >>>>> times, all the comments received so far has been resolved and

> >>>>> reflected in the current version. To move forward, the authors

> >>>>> would like to know if there are further comments on this

> >>>>> document, and people’s opinion on whether it is in the right direction.

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

> >>>>> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=http

> >>>>> s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

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

> > https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A

> > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

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

> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%2<https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%252>

> F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

spring mailing list

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

https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Mon, 25 May 2020 14:37:30 +0000

Hi Sasha,

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

Best regards,
Jie

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, May 25, 2020 8:12 PM
To: Mach Chen <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; qinfengwei <[email-masked]>; 'SPRING WG' <[email-masked]>
Subject: RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Mach and all,

[Jie] Agree that the condition of this statement could be more accurate, to my understanding it was referring to the basic SR functionality.

[Jie] You are right that with MT or Flex-Algo, multiple prefix-SIDs can be associated with the same destination prefix , and with MT you can also have topology-specific adj-SIDs. This is also the reason of reusing MT/Flex-Algo as the corresponding control plane mechanisms.

...

[Jie] You may notice that in the above statement, each adj-SID or prefix-SID can be associated with a subset of the link or node resource. This is the resource semantics introduced to the SR SIDs by this document.

[Jie] As mentioned above, I totally agree with reusing existing control plane mechanisms to advertise multiple topology or algorithm specific SIDs, these are the approach we choose for the control plane, the detailed mechanism was proposed in LSR WG.

This SPRING draft is focusing on introducing resource semantics to SIDs, which is more related to the SR data plane and functionality. Another point is, based on the mechanism defined in this draft, it is also possible to build resource guaranteed SR paths, without introducing the concept of MT or Flex-Algo.

[Jie] I’m open to this standard track or informational discussion. As long as the functionality and information introduced in this document is considered useful to SR.

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

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

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi,

Best regards,

Mach

spring mailing list

---

From: "Wang, Weibin (NSB - CN/Shanghai)" <[email-masked]>
Date: Tue, 26 May 2020 06:46:52 +0000

Firstly I apology if interrupting the conversation;

I have a confusion on the draft-dong-enhanced-VPN, because the essential point of segment routing is reducing the protocol state maintenance in middle nodes (P) of network, only let the edge node compute and maintain source path information. So, as per way described by this draft. We have to maintain in parallel protocol states at edge nodes and middle nodes for each VPN, in this case a set of SIDs belonging to one VPN must be concurrently maintained by the edge and P nodes, so it is hard to say this way flexibility and scalable. however, in the contrast, related vpn info of tradition L3VPN is only maintained by PE, i.e. vrf, the P nodes are unaware of vpn specific info.

I think the existing flex-algo and te-attribute-reuse drafts can address your scenario.

Cheers!

Wang Weibin

From: spring <[email-masked]> On Behalf Of Dongjie (Jimmy)
Sent: 2020年5月25日 22:38
To: Alexander Vainshtein <[email-masked]>; Mach Chen <[email-masked]>
Cc: 'SPRING WG' <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; qinfengwei <[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi Sasha,

Best regards,
Jie

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, May 25, 2020 8:12 PM
To: Mach Chen <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Mach and all,

...

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi,

Best regards,

Mach

spring mailing list

---

From: Mach Chen <[email-masked]>
Date: Tue, 26 May 2020 08:50:11 +0000

Hi Jie and Sasha,

Thanks for the discussion to make my point more accurate! ☺

Currently, a SID can be associated to an adjacency, a Prefix, a Service, a topology/algorithm, my understanding of this draft is that it introduces a new function/semantic to associate a SID to a specific resource. IMHO, this would be useful in the context of networking slicing,  Deterministic networking, etc.

Thanks,
Mach

From: Dongjie (Jimmy)
Sent: Monday, May 25, 2020 10:38 PM
To: Alexander Vainshtein <[email-masked]>; Mach Chen <[email-masked]>
Cc: [email-masked]; Joel M. Halpern <[email-masked]>; qinfengwei <[email-masked]>; 'SPRING WG' <[email-masked]>
Subject: RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi Sasha,

Best regards,
Jie

Mach and all,

[Mach] Yes, I think that we are on the same page about the above points.

...

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi,

Best regards,

Mach

spring mailing list

---

From: "[email-masked]" <[email-masked]>
Date: Tue, 26 May 2020 17:13:03 +0800

Hello Mach and all,

Yes, you are right. This draft makes it possible to associate some specific resource provided by a network device  to a SID. Here the specific resource provided by a network device may be a dedicated queue, a detnet path, or a member link in LAG. The use cases of this kind SID include but not limit to network slice.

As a coauthor,  I think our WG has interests in this draft and it is ready to be a working group item after some editorial changes according to the discuss in this list.

Best Regards,
Zhenqiang Li

[email-masked]
 
发件人： Mach Chen
发送时间： 2020-05-26 16:50
收件人： Dongjie (Jimmy); Alexander Vainshtein
抄送： [email-masked]; Joel M. Halpern; qinfengwei; 'SPRING WG'
主题： RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management
Hi Jie and Sasha,
 
Thanks for the discussion to make my point more accurate! J

Thanks,
Mach
 
From: Dongjie (Jimmy) 
 
Hi Sasha, 

Best regards,
Jie

Mach and all,

 

 
 
   Similarly, for one IGP node, multiple prefix-SIDs SHOULD be   allocated, each of which is associated with a virtual network , and   MAY represent a subset of the node resource [Jie] You may notice that in the above statement, each adj-SID or prefix-SID can be associated with a subset of the link or node resource. This is the resource semantics introduced to the SR SIDs by this document.  There may be valid reasons not to use these mechanisms for associating multiple SIDs with a given destination prefix or an IGP adjacency, but the draft does not mention any such reasons. [Jie] As mentioned above, I totally agree with reusing existing control plane mechanisms to advertise multiple topology or algorithm specific SIDs, these are the approach we choose for the control plane, the detailed mechanism was proposed in LSR WG.  This SPRING draft is focusing on introducing resource semantics to SIDs, which is more related to the SR data plane and functionality. Another point is, based on the mechanism defined in this draft, it is also possible to build resource guaranteed SR paths, without introducing the concept of MT or Flex-Algo.  

 
Regards,
Sasha
 
Office: +972-39266302
Cell:      +972-549266302
 
-----Original Message-----
From: spring <[email-masked]> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; qinfengwei <[email-masked]>; 'SPRING WG' <[email-masked]>
Cc: [email-masked]
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management
 
Hi,

 
Best regards,
Mach
 
> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%2

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 26 May 2020 09:21:11 +0000

Hi Weibin,

Thanks for your comment.

Yes SR aims to reduce the amount of state maintained inside the network, one approach is to keep the path information only at the edge nodes. The mechanism described in this draft aligns with this approach, there is still no per-path state on the P nodes. This is described in section 5 of this document.

As different subset of network resources are allocated on network segments, additional SR SIDs are introduced to represent the subset of network resources reserved on network segments, this could increase the amount of segment states in the network. The granularity of resource allocation on each network segments can be flexible based on the needs.

One clarification I’d like to make is that the state introduced is NOT per-VPN state. An SR based virtual network is used as the virtual underlay network, and VPN services can be carried either by the same or different virtual networks, according to the customer’s requirement and operator’s policy.  This is described in section 4.4 of this document.

As for your last statement, please refer to my reply to Sasha regarding the relationship with Flex-Algo. And if my understanding is correct, the te-attribute-reuse mechanism you mentioned is for advertising TE attribute for different protocols, e.g. RSVP-TE and SR. A new application bit is proposed for Flex-Algo as one application, not to describe per-Flex-Algo attributes.

Hope this helps.

Best regards,
Jie

From: Wang, Weibin (NSB - CN/Shanghai) [mailto:[email-masked]]
Sent: Tuesday, May 26, 2020 2:47 PM
To: Dongjie (Jimmy) <[email-masked]>; Alexander Vainshtein <[email-masked]>; Mach Chen <[email-masked]>
Cc: 'SPRING WG' <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; qinfengwei <[email-masked]>
Subject: RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Cheers!

Wang Weibin

From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Dongjie (Jimmy)
Sent: 2020年5月25日 22:38
To: Alexander Vainshtein <[email-masked]<mailto:[email-masked]>>; Mach Chen <[email-masked]<mailto:[email-masked]>>
Cc: 'SPRING WG' <[email-masked]<mailto:[email-masked]>>; Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; qinfengwei <[email-masked]<mailto:[email-masked]>>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi Sasha,

Best regards,
Jie

Mach and all,

...

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi,

Best regards,

Mach

spring mailing list

---

From: Takuya Miyasaka <[email-masked]>
Date: Wed, 27 May 2020 15:04:01 +0900

Hi Sasha and Jie,

As for the document type (standard track or informational),  my personal 
opinion is that if we need to assign a new IANA code-point on this new 
SR resource semantics at another draft, this document will be Standards 
Track (as an example, a new IS-IS sub-TLVs (RFC8667) for the resource SID).

Regards,
Takuya

On 2020/05/25 23:37, Dongjie (Jimmy) wrote:
> *From:*Alexander Vainshtein [mailto:[email-masked]]
> *Sent:* Monday, May 25, 2020 8:12 PM
> *To:* Mach Chen <[email-masked]>
> *Cc:* [email-masked]; Joel M. Halpern 
> <[email-masked]>; Dongjie (Jimmy) <[email-masked]>; 
> qinfengwei <[email-masked]>; 'SPRING WG' <[email-masked]>
> *Subject:* RE: [spring] 答复: Progressing 
> From my POV saying that " With current SR ... there is no way for the 
> devices to differentiate traffic over the same link or to the same 
> destination, because the SID used by all the flows are the same" is 
> inaccurate.
>
> [Jie] Agree that the condition of this statement could be more 
> accurate, to my understanding it was referring to the basic SR 
> functionality.
>
> AFAIK it is perfectly possible to associate multiple Prefix-SIDs with 
> the same */destination/* */prefix/* by associating them either with 
> different topologies or with different algorithms (or even with a 
> combination of these two parameters).
>
> It is also possible to associate multiple Adj-SIDs (if you want to use 
> them) with the same IGP adjacency by associating them with different 
> topologies (but not with different algorithms).
>
> [Jie] You are right that with MT or Flex-Algo, multiple prefix-SIDs 
> can be associated with the same destination prefix , and with MT you 
> can also have topology-specific adj-SIDs. This is also the reason of 
> reusing MT/Flex-Algo as the corresponding control plane mechanisms.
>
> Therefore it seems that the following recommendations from Section 2.1 
> of the draft are adequately addressed by the already defined SR-MPLS 
> mechanisms:
>
> [Jie] You may notice that in the above statement, each adj-SID or 
> prefix-SID can be associated with a subset of the link or node 
> resource. This is the resource semantics introduced to the SR SIDs by 
> this document.
> There may be valid reasons not to use these mechanisms for associating 
> multiple SIDs with a given destination prefix or an IGP adjacency, but 
> the draft does not mention any such reasons.
> [Jie] As mentioned above, I totally agree with reusing existing 
> control plane mechanisms to advertise multiple topology or algorithm 
> specific SIDs, these are the approach we choose for the control plane, 
> the detailed mechanism was proposed in LSR WG.
> This SPRING draft is focusing on introducing resource semantics to 
> SIDs, which is more related to the SR data plane and functionality. 
> Another point is, based on the mechanism defined in this draft, it is 
> also possible to build resource guaranteed SR paths, without 
> introducing the concept of MT or Flex-Algo.
>
> I defer to others to decide whether existing SRv6 mechanisms are 
> sufficient for addressing similar requirements in Section 2.2 of the 
> draft.
>
> I also wonder whether draft-dong is a valid candidate for the 
> Standards Track document since it does not define any specific 
> protocol elements.  My gut feeling is that it could be a better fit 
> for an Informational document.
>
> [Jie] I’m open to this standard track or informational discussion. As 
> long as the functionality and information introduced in this document 
> is considered useful to SR.
>
> Regards,
>
> Sasha
>
> Office: +972-39266302
>
> Cell: +972-549266302
>
> <mailto:[email-masked]>
>
> From: spring <[email-masked] 
> <mailto:[email-masked]>> On Behalf Of Mach Chen
> To: Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked] 
> <mailto:[email-masked]>>; qinfengwei <[email-masked] 
> <mailto:[email-masked]>>; 'SPRING WG' <[email-masked] 
> <mailto:[email-masked]>>
> <mailto:[email-masked]>
> Is the "resource allocation" performed only on the controller? If so, 
> sounds like a virtual resource reservation, or somehow it is more 
> accurate to call it resource planning. In this case, the 
> interoperability issues may not be the most concerns. The problem is 
> how to guarantee the resource reservation on the data plane, how to 
> prevent resource reserved for one application from using by another 
> application.
>
> With current SR, operator can do resource and traffic planning on 
> controller, while there is no way for the devices to differentiate 
> traffic over the same link or to the same destination, because the SID 
> used by all the flows are the same. Thus devices cannot perform 
> resource reservation for specific customer or service.
>
> Best regards,
>
> Mach
>
> > To: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>>; qinfengwei
>
> > <[email-masked] <mailto:[email-masked]>>; 
> 'SPRING WG' <[email-masked] <mailto:[email-masked]>>
>
> <mailto:[email-masked]>
>
> > >> To: Dongjie (Jimmy) <[email-masked] <mailto:[email-masked]>>; 
> qinfengwei
>
> > >> <[email-masked] <mailto:[email-masked]>>; 
> 'SPRING WG' <[email-masked] <mailto:[email-masked]>>
>
> <mailto:[email-masked]>
>
> > >>>> To: qinfengwei <[email-masked] 
> <mailto:[email-masked]>>; Dongjie (Jimmy)
>
> > >>>> <[email-masked] <mailto:[email-masked]>>; 'SPRING WG' 
> <[email-masked] <mailto:[email-masked]>>
>
> <mailto:[email-masked]>
>
> > >>>>> *发件人:*spring [mailto:[email-masked]] *代表*Dongjie
>
> > >>>> (Jimmy)
>
> > >>>>> *发送时间:*2020年5月19日18:38
>
> > >>>>> *收件人:*SPRING WG
>
> > >>>>> document is complementary to the existing SR functionalities, 
> and helps to complete the tool set of segment routing.
>
> > >>>>>
>
> > >>>>> [email-masked] <mailto:[email-masked]>
>
> > > [email-masked] <mailto:[email-masked]>
>
> > [email-masked] <mailto:[email-masked]>
>
> <https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A%252>
>
> [email-masked] <mailto:[email-masked]>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 27 May 2020 14:56:35 +0000

Hi Takuya,

Thanks a lot for sharing your opinion, to my understanding it makes sense in most cases, while there are also a small number of standard track documents which do not require IANA action.

That said, we could have the technical discussion first, and let the WG to determine the document type later.

Best regards,
Jie

From: Takuya Miyasaka [mailto:[email-masked]]
Sent: Wednesday, May 27, 2020 2:04 PM
To: Dongjie (Jimmy) <[email-masked]>; Alexander Vainshtein <[email-masked]>; Mach Chen <[email-masked]>
Cc: 'SPRING WG' <[email-masked]>; Joel M. Halpern <[email-masked]>; [email-masked]; qinfengwei <[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi Sasha and Jie,

As for the document type (standard track or informational),  my personal opinion is that if we need to assign a new IANA code-point on this new SR resource semantics at another draft, this document will be Standards Track (as an example, a new IS-IS sub-TLVs (RFC8667) for the resource SID).

Regards,
Takuya

Best regards,
Jie

From: Alexander Vainshtein [mailto:[email-masked]]
Sent: Monday, May 25, 2020 8:12 PM
To: Mach Chen <[email-masked]><mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; Joel M. Halpern <[email-masked]><mailto:[email-masked]>; Dongjie (Jimmy) <[email-masked]><mailto:[email-masked]>; qinfengwei <[email-masked]><mailto:[email-masked]>; 'SPRING WG' <[email-masked]><mailto:[email-masked]>
Subject: RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Mach and all,

...

Regards,

Sasha

Office: +972-39266302

Cell:      +972-549266302

-----Original Message-----
From: spring <[email-masked]<mailto:[email-masked]>> On Behalf Of Mach Chen
Sent: Monday, May 25, 2020 10:27 AM
To: Joel M. Halpern <[email-masked]<mailto:[email-masked]>>; Dongjie (Jimmy) <[email-masked]<mailto:[email-masked]>>; qinfengwei <[email-masked]<mailto:[email-masked]>>; 'SPRING WG' <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management

Hi,

Best regards,

Mach

spring mailing list

spring mailing list