Re: [Teas] A review of draft-ietf-teas-enhanced-vpn

["Dongjie (Jimmy)" <[e-mail]>]

Hi Adrian, 

Thanks a lot for your detailed review and suggestion. 

We are working on a new revision and will incorporate your comments and suggestions into it. 

Best regards,
Jie

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Tuesday, September 6, 2022 10:21 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: A review of draft-ietf-teas-enhanced-vpn
> 
> Hi,
> 
> As the slicing framework is queued for working group last call, I thought it
> would be helpful to do a review of this draft to get it ready for last call as well.
> 
> As you might expect, I found a number of nits, and some small comments. My
> general view is that this document is in pretty good shape.
> 
> Cheers,
> Adrian
> 
> ===
> 
> Throughout
> 
> You use "Layer-3", "layer-3", "Layer 3", and "layer 3" in this document.
> Need to pick one.
> 
> ---
> 
> Abstract
> 
> s/over/beyond/
> s/traditional/existing/
> 
> ---
> 
> 1.
> 
> s/a connectivity services/a connectivity service/ s/IETF network slices/IETF
> Network Slices/ s/"IETF network slice"/"IETF Network Slice"/ s/ [RFC7926] and/
> [RFC7926], and/ s/underlay and the overlay/overlay and the underlay/
> d/traditional/    twice
> s/enhanced data plane/data plane for enhanced VPNs/
> 
> ---
> 
> 2.
> 
> s/provides the/provides/
> s/VTN has the/A VTN has the/
> 
> ---
> 
> 2. List of terms
> 
> Probably worth adding SLA, SLE, and SLO in this list with references to the slicing
> framework.
> 
> VTN might be better to reference RFC 8453 rather than the YANG model.
> 
> ---
> 
> 3.1
> 
> s/This can be achieved/This could be achieved/
> 
> It is OK to say that per-VPN TE-LSPs are not widely deployed. But maybe also
> say, "...the more common approach of aggregating multiple VPNs onto
> common TE-LSPs results in shared bandwidth and so may reduce the assurance
> of bandwidth to any one service."
> 
> s/provide these guarantees/provide a guaranteed upper bound to latency/
> s/considered./considered when a guaranteed latency service is required./
> s/attempts to deliver/attempts to deliver a copy of/ s/loss due to/loss in the
> event of/
> 
> ---
> 
> 3.2
> 
> s/isolation./insolation within the underlay network./
> 
> ---
> 
> 3.2.1
> 
> OLD
>    resources, a significant
>    economic advantage when compared to a dedicated, or a Time Division
>    Multiplexing (TDM) network.
> NEW
>    resources: a significant
>    economic advantage when compared to a dedicated or a Time Division
>    Multiplexing (TDM) network.
> END
> 
> ---
> 
> 3.2.1
> 
>    Clearly, there is no need to provide
>    more isolation than is required by the applications, ...
> 
> Is "application" right? The service provider is unaware of the application.
> Perhaps...
> 
>    Clearly, there is no need for a customer to request more isolation
>    than their applications require, and no need for a service provider
>    to provide more isolation than requested by their customer, ...
> 
> ---
> 
> 3.2.1
> 
> s/in most cases/in most cases when hard isolation is requested/
> 
> ---
> 
> 3.3
> 
> s/demanded by an/demanded of an/
> 
> ---
> 
> 3.4
> 
> s/disruptive to that VPN,/disruptive to that VPN itself,/ s/Section 5.1,Section
> 5.2/Section 5.1, Section 5.3/
> 
> ---
> 
> 3.4
> 
> Maybe the last two paragraphs would sit better as the 2nd and 3rd paragraphs
> of the section.
> 
> ---
> 
> 3.5
> 
> s/However, depends/However, depending/
> 
> ---
> 
> 4.
> 
> s/and a corresponding VTN/and mapped to a corresponding VTN/
> 
> ---
> 
> 4.1
> 
> s/resource partitioning,/resource partitioning of the physical network
> infrastructure,/ s/and is associated/and each associated/ s/Thus VTN is/Thus
> the VTN is/ s/its customers/the service provider's customers/
> 
> ---
> 
> 4.4
> 
> s/even in future/even in the future/
> 
> ---
> 
> 5.1
> 
> s/which provide/which can provide/
> 
> ---
> 
> 5.1.1
> 
> s/fixed- bandwidth/fixed-bandwidth/
> 
> ---
> 
> 5.2.1
> 
> s/Virtual Transport Path (VTP)/ Virtual Transport Paths (VTPs)/
> 
> ---
> 
> 5.2.3
> 
> The section should indicate MPLS and IPv6 data plane are both supported.
> 
> ---
> 
> 5.2.3
> 
>    An SR traffic engineered path operates with a granularity of a link.
>    Hints about priority are provided using the Traffic Class (TC) or
>    Differentiated Services Code Point (DSCP) field in the packet header.
> 
> I think the naming is wrong here. In both MPLS and IPv6 the field is called the
> Traffic Class field.
> 
> ---
> 
> 5.4
> 
> s/requirements on connectivity/requirements for connectivity/
> 
> ---
> 
> 5.6
> 
> s/a SDN/an SDN/
> 
> ---
> 
> 6.
> 
> The framework has change the name from NBI to "IETF Network Slice Service
> Interface".
> 
> ---
> 
> 6.1
> 
> s/need to be created/need to be created to support the requested enhanced
> VPNs/
> 
> ---
> 
> 6.4
> 
> s/by operator's policy/by the operator's policy/
> 
> ---
> 
> 7.
> 
> Maybe give some clue about what is coming next. Such as
>    The sections that follow describe some of
>    the scalability concerns that need to be considered.
> 
> ---
> 
> 7.2
> 
> s/traditional/established/
> 
> ---
> 
> Perhaps sections 8 and 9 could be combined into a single section on
> "Management Considerations"?
> 
> ---
> 
> 11.
> 
> d/traditional/
> 
> ---
> 
> 12.
> 
> Maybe add a final paragraph like...
>    An enhanced VPN (even one with hard isolation requirements) does not
>    provide any additional guarantees of privacy for customer traffic
>    compared to regular VPNs: the traffic within the network may be
>    intercepted and errors may lead to mis-delivery.  Users who wish to
>    ensure the privacy of their traffic must take their own precautions
>    including end-to-end encryption.
> 
> ---
> 
> 16.2
> 
> I think [I-D.ietf-teas-actn-yang] is not used.
> 
> 
>