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

[Takuya Miyasaka <[e-mail]>]

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:
>
> Hi Sasha,
>
> Thanks a lot for your comments. Please see some replies inline.
>
> Best regards,
>
> Jie
>
> *From:*Alexander Vainshtein [mailto:[e-mail]]
> *Sent:* Monday, May 25, 2020 8:12 PM
> *To:* Mach Chen <[e-mail]>
> *Cc:* [e-mail]; Joel M. Halpern 
> <[e-mail]>; Dongjie (Jimmy) <[e-mail]>; 
> qinfengwei <[e-mail]>; 'SPRING WG' <[e-mail]>
> *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: [phone]
>
> Cell: [phone]
>
> Email: [e-mail] 
> <mailto:[e-mail]>
>
> -----Original Message-----
> From: spring <[e-mail] 
> <mailto:[e-mail]>> On Behalf Of Mach Chen
> Sent: Monday, May 25, 2020 10:27 AM
> To: Joel M. Halpern <[e-mail] 
> <mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail] 
> <mailto:[e-mail]>>; qinfengwei <[e-mail] 
> <mailto:[e-mail]>>; 'SPRING WG' <[e-mail] 
> <mailto:[e-mail]>>
> Cc: [e-mail] 
> <mailto:[e-mail]>
> 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:[e-mail]] On Behalf Of Joel M.
>
> > Halpern
>
> > Sent: Monday, May 25, 2020 11:31 AM
>
> > To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]>>; qinfengwei
>
> > <[e-mail] <mailto:[e-mail]>>; 
> 'SPRING WG' <[e-mail] <mailto:[e-mail]>>
>
> > Cc: [e-mail] 
> <mailto:[e-mail]>
>
> > 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:[e-mail]]
>
> > >> Sent: Thursday, May 21, 2020 10:08 PM
>
> > >> To: Dongjie (Jimmy) <[e-mail] <mailto:[e-mail]>>; 
> qinfengwei
>
> > >> <[e-mail] <mailto:[e-mail]>>; 
> 'SPRING WG' <[e-mail] <mailto:[e-mail]>>
>
> > >> Cc: [e-mail] 
> <mailto:[e-mail]>
>
> > >> 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:[e-mail]]
>
> > >>>> Sent: Thursday, May 21, 2020 11:01 AM
>
> > >>>> To: qinfengwei <[e-mail] 
> <mailto:[e-mail]>>; Dongjie (Jimmy)
>
> > >>>> <[e-mail] <mailto:[e-mail]>>; 'SPRING WG' 
> <[e-mail] <mailto:[e-mail]>>
>
> > >>>> Cc: [e-mail] 
> <mailto:[e-mail]>
>
> > >>>> 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:[e-mail]] *代表*Dongjie
>
> > >>>> (Jimmy)
>
> > >>>>> *发送时间:*2020年5月19日18:38
>
> > >>>>> *收件人:*SPRING WG
>
> > >>>>> *抄送:*[e-mail]
>
> > >>>>> *主题:*[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
>
> > >>>>> [e-mail] <mailto:[e-mail]>
>
> > >>>>> https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=http
>
> > >>>>> s%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
> > >>>>>
>
> > > _______________________________________________
>
> > > spring mailing list
>
> > > [e-mail] <mailto:[e-mail]>
>
> > > https://clicktime.symantec.com/3Vi2XF9rXtn95ip934LJk1v6H2?u=https%3A
>
> > > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fspring
>
> > >
>
> > 
>
> > _______________________________________________
>
> > spring mailing list
>
> > [e-mail] <mailto:[e-mail]>
>
> > 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
>
> [e-mail] <mailto:[e-mail]>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spring