Re: [spring] Request for WG adoption of draft-dong-spring-sr-for-enhanced-vpn-05

[Alexander Vainshtein <[e-mail]>]

Hi all,

I have read the document and I think that matches the two criteria that are usually considered for deciding whether the draft can be adopted:

1.       It discusses a high relevant problem within the scope of the WG Charter

2.       It provides a reasonable basis for the solution of this problem.



At the same time I have some concerns about this draft. These concerns are not blockers for adoption, but, IMHOL and FWIW, should be resolved before the draft moves further.



Several fragments in Section 2.1 need some additional work IMHO. E.g. (the problematic fragments are highlighted)::



1.       The following text may be misleading


   For one particular IGP link, multiple Adj-SIDs SHOULD be allocated,
   each of which is associated with a particular virtual network
   topology, and MAY represent a subset of link resources.  Several
   approaches can be used to partition the link resource, such as
   logical sub-interfaces, dedicated queues, etc.



I am not sure a single IGP link can be split into multiple logical sub-interfaces. As I see it, logical sub-interfaces of a link usually act as individual IGP links of and by themselves.



2.       Immediately after that the draft says that:



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

   allocated, each of which is associated with a specific virtual

   network topology, and may represent a subset of the node resource

   (e.g. the processing resources).



I wonder why only Node-SIDs and not any Prefix-SID can be associated with  a specific virtual topology. Among other things, such a restriction prevents using Anycast SIDs (which, by definition, are not Node-SIDs).



3.       The following text seems to contradict the basic architecture of SR:



   A group of adj-SIDs and node-SIDs associated with the same virtual

   network can be used to construct the SR SID-lists (either strict or

   loose) to steer the traffic of a particular enhanced VPN service.

   This group of SIDs MAY also represent the set of network resources

   which are reserved for a specific enhanced VPN, or a group of

   enhanced VPNs.



It seems to suggest that a list of SIDs may be associated with a particular network resource while specific SIDs in this list are not associated with this resource. But in SR-MPLS, only the current active SID defines all aspects of the packet disposition, including the resources used for its forwarding.





4.       The following restriction looks excessively strong to me:



When a node-SID is used in the SID-list to build an SR loose path, the

transit nodes use the node-SID to identify the virtual network, and

MAY process the packet using the local resources allocated for the

corresponding virtual network.  Note in this case, Penultimate Hop

Popping (PHP) [RFC3031<https://tools.ietf.org/html/rfc3031>] MUST be disabled.



IMHO and FWIW the no PHP requirement may be relaxed, because the virtual topology and the resources associated with it would be derived from the next active SID (if any). And if there is no next SID, these resources could be inferred from the specific instance of the enhanced VPN service.  (Maybe the draft should explicitly state that a given enhanced VPN service instance should be restricted to using a given virtual topology and a given set of network resources.)



The procedures described in Section 4 of the draft seem to assume that each enhanced VPN service will use its own virtual topology and resources in the underlay.

At the same time the draft mentions in many places that a given virtual topology and its associated set of network resources can be used by a group of enhanved VPN service instances.

The latter looks like a much nore scalable approach to me.



As already mentioned, I do not see any of my comments as blockers for adoption of the draft.  Hopefully they will be useful.



Regards,

Sasha



Office: [phone]

Cell:      [phone]

Email:   [e-mail]





-----Original Message-----
From: spring <[e-mail]> On Behalf Of Dongjie (Jimmy)
Sent: Monday, October 21, 2019 8:22 AM
To: 'SPRING WG List' <[e-mail]>
Cc: [e-mail]
Subject: [spring] Request for WG adoption of draft-dong-spring-sr-for-enhanced-vpn-05



Dear WG and Chairs,



A new revision of draft-dong-spring-sr-for-enhanced-vpn has been uploaded to resolve some recently received comments. This document describes the Segment Routing based mechanism to provide enhanced VPN, which aligns with the enhanced VPN (VPN)+ framework document in TEAS WG. The mechanism could be used to enable transport network slicing for 5G.



The major changes compared to the -04 version are:



  1. Update the draft template.



  2. Add reference to the definition of network slicing in 3GPP TS23.501 and the definition of transport network slicing in draft-ietf-teas-enhanced-vpn-03 respectively.



  3. Editorial changes in several sections to clarify and improve the readability.



  4. Change some coauthors' affiliation and mail address.



This update shows that the major content of this draft has become stable and solid, thus the authors would like to request the WG to consider the adoption of this document.



Comments are always welcome. Thanks.



Best regards,

Jie



-----Original Message-----

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]]

Sent: Wednesday, October 16, 2019 3:28 PM

To: Takuya Miyasaka <[e-mail]<mailto:[e-mail]>>; Zhenqiang Li <[e-mail]<mailto:[e-mail]>>; Fengwei Qin <[e-mail]<mailto:[e-mail]>>; Stewart Bryant <[e-mail]<mailto:[e-mail]>>; Yongqing Zhu <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>

Subject: New Version Notification for draft-dong-spring-sr-for-enhanced-vpn-05.txt





A new version of I-D, draft-dong-spring-sr-for-enhanced-vpn-05.txt

has been successfully submitted by Jie Dong and posted to the IETF repository.



Name:                  draft-dong-spring-sr-for-enhanced-vpn

Revision:              05

Title:                      Segment Routing for Enhanced VPN Service

Document date:               2019-10-16

Group:                  Individual Submission

Pages:                   20

URL:            https://clicktime.symantec.com/3ALPFrm3RynBsKbF1oU2uum6H2?u=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-dong-spring-sr-for-enhanced-vpn-05.txt

Status:         https://clicktime.symantec.com/3Ke26NtAMQpPmNpsJSjbjfC6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-dong-spring-sr-for-enhanced-vpn%2F

Htmlized:       https://clicktime.symantec.com/38csYFW7vnAShtJtkSWCXTa6H2?u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dong-spring-sr-for-enhanced-vpn-05

Htmlized:       https://clicktime.symantec.com/354AuwRvQiKbYh6cGRF6EnT6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-dong-spring-sr-for-enhanced-vpn

Diff:           https://clicktime.symantec.com/3HgF1QzcMezZQRxNmfgfoeE6H2?u=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-dong-spring-sr-for-enhanced-vpn-05



Abstract:

   Enhanced VPN (VPN+) is an enhancement to VPN services to enable it to

   support the needs of new applications, particularly applications that

   are associated with 5G services.  These applications require better

   isolation from both control and data plane's perspective and have

   more stringent performance requirements than can be provided with

   overlay VPNs.  The characteristics of an enhanced VPN as perceived by

   its tenant needs to be comparable to those of a dedicated private

   network.  This requires tight integration between the overlay VPN and

   the underlay network topology and resources in a scalable manner.  An

   enhanced VPN may form the underpinning of 5G network slicing, but

   will also be of use in its own right.  This document describes how to

   use segment routing based mechanisms to provide the enhanced VPN

   service with the required network topology and resources.  The

   overall mechanism of providing segment routing based enhanced VPN

   service is also described.  The proposed mechanism is applicable to

   both segment routing with MPLS data plane (SR-MPLS) and segment

   routing with IPv6 data plane (SRv6).











Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat



_______________________________________________

spring mailing list

[e-mail]<mailto:[e-mail]>

https://clicktime.symantec.com/3Sp5waqnzS9HdVXRw1FadGh6H2?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.
___________________________________________________________________________