Hi Sasha, Thanks a lot for your comments. Please see some replies inline.
Best regards, Jie From: Alexander Vainshtein [mailto:alexander.vainsht...@ecitele.com] Sent: Monday, May 25, 2020 8:12 PM To: Mach Chen <mach.c...@huawei.com> Cc: draft-dong-spring-sr-for-enhanced-...@ietf.org; Joel M. Halpern <j...@joelhalpern.com>; Dongjie (Jimmy) <jie.d...@huawei.com>; qinfengwei <qinfeng...@chinamobile.com>; 'SPRING WG' <spring@ietf.org> Subject: RE: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management 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. [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: 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 [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 Email: alexander.vainsht...@ecitele.com<mailto:alexander.vainsht...@ecitele.com> -----Original Message----- From: spring <spring-boun...@ietf.org<mailto:spring-boun...@ietf.org>> On Behalf Of Mach Chen Sent: Monday, May 25, 2020 10:27 AM To: Joel M. Halpern <j...@joelhalpern.com<mailto:j...@joelhalpern.com>>; Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; qinfengwei <qinfeng...@chinamobile.com<mailto:qinfeng...@chinamobile.com>>; 'SPRING WG' <spring@ietf.org<mailto:spring@ietf.org>> Cc: draft-dong-spring-sr-for-enhanced-...@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-...@ietf.org> Subject: Re: [spring] 答复: Progressing draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource management 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 > -----Original Message----- > From: spring [mailto:spring-boun...@ietf.org] On Behalf Of Joel M. > Halpern > Sent: Monday, May 25, 2020 11:31 AM > To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; > qinfengwei > <qinfeng...@chinamobile.com<mailto:qinfeng...@chinamobile.com>>; 'SPRING WG' > <spring@ietf.org<mailto:spring@ietf.org>> > Cc: > draft-dong-spring-sr-for-enhanced-...@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-...@ietf.org> > Subject: Re: [spring] 答复: Progressing > draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource > management > > 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 > > On 5/24/2020 10:54 PM, Dongjie (Jimmy) wrote: > > 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 > > > >> -----Original Message----- > >> From: Joel Halpern Direct [mailto:jmh.dir...@joelhalpern.com] > >> Sent: Thursday, May 21, 2020 10:08 PM > >> To: Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; > >> qinfengwei > >> <qinfeng...@chinamobile.com<mailto:qinfeng...@chinamobile.com>>; 'SPRING > >> WG' <spring@ietf.org<mailto:spring@ietf.org>> > >> Cc: > >> draft-dong-spring-sr-for-enhanced-...@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-...@ietf.org> > >> Subject: Re: [spring] 答复: Progressing > >> draft-dong-spring-sr-for-enhanced-vpn to enable SR with resource > >> management > >> > >> 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 > >> > >> On 5/21/2020 9:07 AM, Dongjie (Jimmy) wrote: > >>> 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:j...@joelhalpern.com] > >>>> Sent: Thursday, May 21, 2020 11:01 AM > >>>> To: qinfengwei > >>>> <qinfeng...@chinamobile.com<mailto:qinfeng...@chinamobile.com>>; Dongjie > >>>> (Jimmy) > >>>> <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>; 'SPRING WG' > >>>> <spring@ietf.org<mailto:spring@ietf.org>> > >>>> Cc: > >>>> draft-dong-spring-sr-for-enhanced-...@ietf.org<mailto:draft-dong-spring-sr-for-enhanced-...@ietf.org> > >>>> Subject: 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: > >>>>> 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:spring-boun...@ietf.org] *代表 *Dongjie > >>>> (Jimmy) > >>>>> *发送时间:*2020年5月19日18:38 > >>>>> *收件人:*SPRING WG > >>>>> *抄送:*draft-dong-spring-sr-for-enhanced-...@ietf.org > >>>>> *主题:*[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. > >>>>> > >>>>> Comments and feedbacks are welcome. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Jie > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> spring mailing list > >>>>> spring@ietf.org<mailto:spring@ietf.org> > >>>>> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=http > >>>>> s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > >>>>> > > _______________________________________________ > > spring mailing list > > spring@ietf.org<mailto:spring@ietf.org> > > https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A > > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring > > > > _______________________________________________ > spring mailing list > spring@ietf.org<mailto:spring@ietf.org> > 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 spring@ietf.org<mailto:spring@ietf.org> 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. ___________________________________________________________________________
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
