Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14

Ketan Talaulikar <> Fri, 22 September 2023 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79A28C169510; Fri, 22 Sep 2023 05:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Status: No, score=-7.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l2pDY8Yg6sl0; Fri, 22 Sep 2023 05:21:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id C21EBC14CF12; Fri, 22 Sep 2023 05:21:44 -0700 (PDT)
Received: by with SMTP id a640c23a62f3a-9ada2e6e75fso273531966b.2; Fri, 22 Sep 2023 05:21:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1695385302; x=1695990102;; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PaazQNJxq48r6iaL4ZsHyac/GhCoW+S9otYkAH4yo1s=; b=QDYajB6hw/pzMhvVZuMkP/++6rSKFZLl6PHNSlpDvp7xIEuP455wxFMgOv1FdGC16W beZatiNiJ5PBnz7cyMmKhnziree/6+hG13MU6QW/MzKJMtITTf7INGc196YuWVzjd6lq FERs+Mm6ixMfRZ7PcCba4pI+hdt/VTxSTEoxjMIoTpnrXHc74SYCZ1bmWuMekp0quges q6wx2LvweR+gGrHV/jC1Fw50CRpIs6woMrzyAKXlcyCHq75qClUWt8GUbpjkhZ1YFmqB mNz4sHt2xbRIOM5VhDk5KYBBGUgTHrZRRMHAFsf58Vdinys98lHhy+3Ix9zv+upVaofB JtQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1695385302; x=1695990102; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PaazQNJxq48r6iaL4ZsHyac/GhCoW+S9otYkAH4yo1s=; b=fXq375fsmWoYxXe1x/kheSaCh1M7EVqs2w9+rZMX3LHsxoFnyiOln3d9hJOvJRi+iM 9lTnzRIge5g78q5v3xfnzEVuBCDVCFaMNuMgFyhwJU29YEjmAhZC1KgSKoHPAI+TSWQZ 4+rloRgLL5lD9xj1fCjiHKBFWQP2M0OdOfOK+JPOSEol8NZz91MeH1fzQY1WpcEUOjAL NYKMyfbjdukjxAFOw5cFvPGWL1oigr0eJwXYy7zw3y1ojsb9bdicvpW5s85omq32geMw q/nsyVcEROUpti457+sAIg3Xl9eX34duSYyPcyFlKKJZbm+pDPgmATzS67tX8Y0eBcGL crBw==
X-Gm-Message-State: AOJu0Yy1bFb1U2QaBwBQYUcckx77wTNwQaIfAU9s71cLF+MGUDi1OO9i gp55NjxZDNzxvI4DOA0MNkmD6R/B8j46v1MQIysrQAl2
X-Google-Smtp-Source: AGHT+IFBHMoXyGd09VGAylqRqELXibfxVHrI3zcn2/qu1U9s/hGKVQJtbH74bij/lw7BN5Thni5Kfz5Q6XZq6FtCI/I=
X-Received: by 2002:a17:906:5386:b0:9a1:aea2:d18d with SMTP id g6-20020a170906538600b009a1aea2d18dmr6647400ejo.48.1695385302073; Fri, 22 Sep 2023 05:21:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Ketan Talaulikar <>
Date: Fri, 22 Sep 2023 17:51:30 +0530
Message-ID: <>
To: "Dongjie (Jimmy)" <>
Cc: "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000b0038f0605f1a666"
Archived-At: <>
Subject: Re: [Teas] Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 22 Sep 2023 12:21:49 -0000

Hi Jie,

Thanks for your response and sharing the context for this document. Please
check inline below for responses.

On Tue, Sep 19, 2023 at 9:25 AM Dongjie (Jimmy) <> wrote:

> Hi Ketan,
> Thanks for the review and comments to help improve this work.
> Please see some replies to your high level comments inline. Some
> background and history about this work are provided to help the
> understanding and discussion.
> > -----Original Message-----
> > From: Ketan Talaulikar via Datatracker []
> > Sent: Friday, September 15, 2023 6:40 PM
> > To:
> > Cc:;
> > Subject: Rtgdir early review of draft-ietf-teas-enhanced-vpn-14
> >
> > Reviewer: Ketan Talaulikar
> > Review result: Not Ready
> >
> > I believe that the document is not ready and needs further work. I have
> some
> > major concerns that I am sharing below that I would like to bring to the
> > attention of the authors and the WG.
> >
> > Summary of the document (please correct my understanding):
> >
> > a) Introduces a notion of VPN+ that seems to describe some (so-called)
> > enhancements over (so-called) "conventional" VPN services. It goes on to
> > describe why these VPN+ services are special and different and what they
> > could provide and how they are provisioned/managed that are different
> from
> > what already exists.
> >
> > b) Introduces a VTN construct for identifying (?) a subset of the
> underlay
> > network topology with some awareness of resources associated with it that
> > are derived from the underlying physical network. A VPN+ service is
> built on
> > top of this VTN construct.
> >
> > c) Discusses the realization of the VTN constructs using existing
> technologies
> > and how it can be managed and operated. Also, how it can deliver as an
> > solution in the IETF Network Slicing framework.
> Item c) is not quite accurate. This document mainly describes the
> architecture and candidate technologies which can be used to realize VPN+
> services. VTN is just one of the constructs of this architecture.

KT> OK. So this document is not about VTN. Also, your further comment
indicates that we could replace VTN with NRP in this document. If so, that
sounds good to me.

> > Major Issues:
> >
> > 1) Use of “VPN+” & “Enhanced VPN” terminologies
> >
> > When the document creates this notion of VPN+, it is implying that this
> is
> > something new and something that can be realized using what is in the
> > document.
> > That is at best misleading.
> >
> > A service provider called X could have provided a P2P PW L2VPN service
> > some 10+ years ago over an RSVP-TE tunnel that provides guaranteed
> > bandwidth, protection, avoidance, some level of isolation and works
> around
> > network failures. Would that be considered as a VPN+ service?
> As described in the introduction, VPN+ refers to a VPN service which can
> provide not only connectivity but also guaranteed resource and
> assured/predictable performance. In section 5, RSVP-TE is not excluded from
> the candidate realization technologies, while as analyzed in section 5.2
> and 5.4, RSVP-TE tunnels were not widely used for guaranteed bandwidth for
> specific VPN services, due to scalability concerns. Thus we would say the
> convention VPN services are provided mainly for connectivity, the resources
> are not guaranteed since they are usually shared with many other VPN or
> non-VPN service in the same network.

KT> My concern is that the terms "VPN+" and "Enhanced VPN" are vague and
not really technical terms. At IETF and in the industry at large, we are
constantly enhancing and improving things. Would we next come up with terms
like VPN++ to describe the next thing? How about we use a technical term -
say something like "Guaranteed Resource Services"? I hesitate to use the
word VPN since "service" seems like it would cover a wider spectrum of
offerings by service providers.

> > My point is that the VPN+ (and enhanced VPN) sound more like marketing
> > terms to me and do not reflect how operators have deployed and are
> > deploying "enhanced"
> > VPNs for their customers. It seems futile and misleading for the IETF to
> try to
> > define what is "enhanced" and what is "conventional" VPN services.
> If you followed the network slicing discussion in IETF and TEAS WG since
> 2017, I believe you would not make the judgement that "VPN+" is a marketing
> term. It was introduced at that time when almost all IETF people said
> "network slicing is vague and broad", in IETF we need to call it something
> which can be understood by IETF people, and the work needs to reflect its
> relationship with existing IETF technologies". "VPN+" was the best term we
> could find at that time, and it seems people accepted it in IETF since its
> adoption in TEAS.
> In marketing places, we would use the term "network slice" directly.

KT> I will admit that I have not been following this work very closely
through all the twists and turns. But then maybe I benefit from that. I
have reviewed the final product from the WG though - i.e.
draft-ietf-teas-ietf-network-slices. Isn't it required to clarify the scope
and goals of this document considering the present day status when sending
it to the IESG?

> > I believe the document should focus on VTN (which to me seems like a TE
> > construct?) and how *any* VPN service can be delivered on top of it to
> > provide the benefits that VTN has to offer.
> While VTN is one important construct in the realization of VPN+ services.
> this is a framework for VPN+ service, it is more than just VTN.
> > If the authors believe they have advice to offer to operators on the
> > provisioning and management of VPN services, perhaps it should be a
> > separate draft in the OPS area?
> This document has some text about the provisioning and management of VPN+
> services, and it refers to documents in the OPS area and TEAS WG for the
> detailed management mechanisms and models. I believe this aligns with the
> approach you proposed.
> >
> > 2) Relation to IETF Network Slices document
> >
> > The draft-ietf-teas-ietf-network-slices (now with the IESG) that the WG
> has
> > sent for publication has a lot of content that is repeated in sometimes
> > different words and phrases in this document. The authors should consider
> > citing the relevant sections of that document instead of repeating. I
> > understand that this might have happened over the course of time and the
> > IETF network slicing document does acknowledge text drawn from this
> > document.
> This is about the history of the two documents (VPN+ framework and IETF
> network slice framework).
> If my memory is correct, VPN+ framework was the first network slicing
> related document in TEAS. When the Network Slice Design Team (NSDT) was
> formed in 2020, the work on network slice framework was initiated, the
> authors of the VPN+ framework proposed to reuse text of this document for
> the network slice framework, this seems reasonable as both document are on
> the same/similar topic. As you mentioned that was reflected in the
> acknowledgement in the network slice framework.

KT> Agreed

> As the network slice framework document evolves, we have been working on
> aligning the concepts and terms between the two documents, and some
> descriptions become different but still look similar. While since the scope
> of the VPN+ framework is not fully overlapped with the network slice
> framework, those texts are considered needed in this document.

KT> Could you please point me to text in either this or another document
that describes the contrast and overlap between this document and the IETF
Network slicing framework? Ideal thing would be to avoid overlap and
disambiguate the two frameworks.

> >
> > The document says that VTN is one way to deliver NRP. If so, VTN would
> fit
> > with the IETF Network Slicing framework and the content in Section 6
> should
> > be then using the terminologies of that document.
> Our intention with section 6 was to show how VPN+ framework and candidate
> technologies can be used to deliver network slice service in the context of
> network slicing. That said, the authors does not have a strong opinion on
> which terms are better to use in section 6. Currently VTN is used in the
> whole VPN+ document, and its relationship with NRP is also described. If
> the WG think NRP should be used in section 6, we are OK with that.

KT> Yes, I believe it would help bring clarity if the term NRP were used in
this document instead of VTN if those constructs are indeed synonymous.

> > But then the document says that VTN can be also used outside the context
> of
> > IETF Network Slicing.
> My thought is the WG has reached consensus on this: VPN+/VTN is generic,
> it can be used for realizing IETF network slices, and they can also be used
> for other scenarios (assume that we would not call all those services
> "slice").

KT> There is already a framework for IETF Network Slicing that is soon
going to get published as an RFC. Would it not help to focus only on the
non-slicing use-case/framework in this document? The Network Slicing
framework is done - does the WG intend to propose two frameworks for the
same problem statement?

> > Suggestion: Focus on the description of the VTN construct by itself
> > independently. Then cover its applicability in the IETF Network Slicing
> > framework in one section and the applicability independently (as an
> underlay
> > for any VPN service) in another section.
> With the above background information and explanation, hope you have
> better understanding about the relationship between VPN+/VTN and network
> slicing.

KT> I am not really there as yet - but I think I am getting there. Thanks
for your patience. More importantly, our goals should be that clarity
should ultimately emerge in the document for the benefit of any new reader.

> The applicability of VPN+ for IETF network slicing is briefly described in
> the IETF Network Slicing framework in one section. The details are in this
> document.
> > 3) Identification of VTN
> >
> > There are multiple documents out in other routing WGs (some adopted,
> > some
> > individual) and in 6man WG that talk about a VTN-ID. This document which
> is
> > used as the reference for VTN in all those places is conspicuously
> silent on
> > the aspect of an VTN-ID - i.e., Do we need a new ID or can we use
> existing
> > identifiers based on the underlying transport/underlay technologies used?
> You are right that the data plane VTN-ID is not explicitly discussed in
> this document, this is because there is another document
> draft-ietf-teas-nrp-scalability which is focusing on the scalability
> considerations of NRP, and whether to use new ID or existing identifiers
> was fully discussed there. My suggestion is we may add some brief
> description about the new data plane ID mechanism in this framework
> document, and refer to the nrp-scalability draft for details. What do you
> think?

KT> Indeed the topic is covered in draft-ietf-teas-nrp-scalability and I
agree with you that it may be best to discuss it in that document rather
than here given your explanations above.

> > I am sharing these uber-level comments first so we can have a discussion
> and
> > converge. The detailed review will follow once were are past these
> issues.
> Thanks again for your high-level comments, and hope my reply can help to
> better understand this work and the relationship with other network slicing
> work.

Thanks. Looking forward to continuing this discussion.

> Best regards,
> Jie
> >
> > Thanks,
> > Ketan
> >
> >
> >