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: +972-39266302
Cell: +972-549266302
Email: alexander.vainsht...@ecitele.com
-----Original Message-----
From: spring <spring-boun...@ietf.org> On Behalf Of Dongjie (Jimmy)
Sent: Monday, October 21, 2019 8:22 AM
To: 'SPRING WG List' <spring@ietf.org>
Cc: spring-cha...@ietf.org
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: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org>
[mailto:internet-dra...@ietf.org]
Sent: Wednesday, October 16, 2019 3:28 PM
To: Takuya Miyasaka <ta-miyas...@kddi.com<mailto:ta-miyas...@kddi.com>>;
Zhenqiang Li <li_zhenqi...@hotmail.com<mailto:li_zhenqi...@hotmail.com>>;
Fengwei Qin <qinfeng...@chinamobile.com<mailto:qinfeng...@chinamobile.com>>;
Stewart Bryant <stewart.bry...@gmail.com<mailto:stewart.bry...@gmail.com>>;
Yongqing Zhu <zhuyq...@chinatelecom.cn<mailto:zhuyq...@chinatelecom.cn>>;
Dongjie (Jimmy) <jie.d...@huawei.com<mailto:jie.d...@huawei.com>>
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
spring@ietf.org<mailto:spring@ietf.org>
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.
___________________________________________________________________________
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring