Re: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

Dhruv Dhody <dhruv.ietf@gmail.com> Fri, 09 April 2021 06:29 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 639DA3A1047; Thu, 8 Apr 2021 23:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHOr0FpgP1Kh; Thu, 8 Apr 2021 23:28:56 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706CB3A102D; Thu, 8 Apr 2021 23:28:56 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id x16so4834757iob.1; Thu, 08 Apr 2021 23:28:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DNyLmHc+Hl7aLspqfwH7Unr7tzV0ceq23kro8oGzA3A=; b=YYac1IC4dkpiNY7CPs1NssVltVNnUvtrCplaa3SE9JUet7FPa1KpWJ9ZiWtJJHKVpo FKOVTkFLAswMSLOxVJyuqrOK6NF1/e35VucPqq8qpt6uCShNaEj6OZH8iiwTJN6N43Uj NFihOT65fCA855gikVunNxtmNpmM9+I4Zk8AF6ohl4iqjQXHoR/ZscoVVuWByX+HsDHA 7js5TkjhN+ujOYVVpkhb4Woy5VFRsgrQ8K6K5Gkm7DylTICgoaaBsMSx2mHku/9noNrs DUg7lq7tCwj8eRkOGyuyzhTTGlepGioMgmYmyKgo/yuSaltPDZXh1Ud91YT4c36NWR7J Og2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DNyLmHc+Hl7aLspqfwH7Unr7tzV0ceq23kro8oGzA3A=; b=bjY1xABU+66oQnZSLy1u8H9ClsAAE7didxn8I2QQ+RLmMk6GLu9WAM6OJg7cdd3wzD zYxsT3gsSBqBp6Cx4sPAVjbixDTkwayTATl7EcMljyQ+HWy9g9GafhNfXRmISm5chark Ezz0CKZWMkpbbBRML1kBhOo+8rlnLRTot8ycthHTSexRghoD/PHZquLKmlFPeV8fsBW0 fB5tohtyGRHAiYRsEn0pa3eTClW1HpIFupgBWUndRRwrX+d3L+KqMZHwPIezouckqIzE 8q1iGMvuQ1OOR1XXHMrRgHK0qbthtqmZVU+Mx7oc6rzEIozxIRyyIClMTo5+ko2vQsb6 2gTg==
X-Gm-Message-State: AOAM530PM30MkciD5YvpJMIegArUuykJppCb2L2Flt1NrpSq8NRQpL08 cFjJcdHfF3ZGu9wDTf/C9MqG0kuu8lZe02NWoJSefq9ZzrHssQ==
X-Google-Smtp-Source: ABdhPJzliTuyUNC3TexJIu4ru078gJj+8xSm+sae/5Cm98/23qoK+IKpXtI6irk0dllWM84yrTBeZPOVIZeo5bK1Fp0=
X-Received: by 2002:a05:6638:3399:: with SMTP id h25mr12919702jav.15.1617949734696; Thu, 08 Apr 2021 23:28:54 -0700 (PDT)
MIME-Version: 1.0
References: <085201d72cbd$ff5ff9c0$fe1fed40$@olddog.co.uk>
In-Reply-To: <085201d72cbd$ff5ff9c0$fe1fed40$@olddog.co.uk>
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Fri, 9 Apr 2021 11:58:18 +0530
Message-ID: <CAB75xn7918o5CcJ8zaGUPw7B-f4HtbYDGf=4Hi3y==eUL38ydQ@mail.gmail.com>
To: Farrel Adrian <adrian@olddog.co.uk>
Cc: draft-ietf-teas-te-service-mapping-yang@ietf.org, "TEAS WG (teas@ietf.org)" <teas@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003379a105bf844731"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/a21neKZl-CZ4kGmgVoRM9gPXedI>
Subject: Re: [Teas] A question about draft-ietf-teas-te-service-mapping-yang
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2021 06:29:01 -0000

Hi Adrian,

Thanks for your review and clear explanation. I will try to build this
description into the draft.

On Fri, Apr 9, 2021 at 2:57 AM Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi authors, all,
>
> As the L3NM draft is going through last call in OPSAWG, now seemed like
> a good time to give this document a bit of a review.
>
> I have a top-level question that is puzzling me quite a bit. It concerns
> the purpose of the YANG model (and so the purpose of the draft). The
> question is which of these cases applies:
>
> 1. The user of the LxSM models have the option to control which TE
>    tunnels are used to support the VPN service. The user can use the
>    model at the service interface to write this information.
>
> 2. The user of the LxSM models have an interest in which TE tunnels are
>    used and the operator can report the relationship. The user can use
>    model at the service interface to read this information.
>
> 3. The information about the tunnels is not exposed at the service
>    interface, but is important for service realisation. In this case the
>    model augments the LxNM models but not the LxSM models.
>
> This needs to be made super-clear in the Abstract and Introduction so
> that the reader can understand the purpose of the work. The text in the
> document is currently somewhat unclear about this, but as I worked
> through the document (and especially once I reached the tree diagrams)
> it seems clear that all three of these bullets are intended to be
> supported.
>
>
I will work on adding this upfront.



> Now, I wonder whether the document is conflating several objectives:
>
> a. Provide some additional service characteristics for the LxSM models
>    in order to support the sort of service features that might be
>    included in a request for an enhanced VPN. I can see why this would
>    be done as an augmentation of the LxSM models, and it is a fine thing
>    to do.
>
> b. Provide some additional service characteristics for the LxNM models
>    in order to assist with the realisation of the LxVPN services. Again,
>    I see why this would be done as an augmentation (in this case of the
>    LxNM models), and it is also a fine thing to do.
>
> c. Provide a mapping to assist in realisation of the LxVPN services by
>    identifying which TE tunnels are used (and how). To me, this feels
>    like an augmentation of the LxNM models as it allows the operator's
>    management software to make the association for control purposes and
>    also allows the mapping to be visible to the operator for diagnostic
>    purposes.
>
> d. Provide a mapping so that the customer can control/see which TE
>    tunnels are used to realise the LxVPN services. This would be an
>    augmentation of the LxSM models but I don't understand the required
>    function here. Surely the customer cannot control which TE tunnels
>    are used to operate an LxVPN service: the tunnels are the property of
>    the operator, and the customer can neither specify that the be used
>    nor control how they are used. It is true that the customer may want
>    certain service characteristics that will dictate how the provider
>    operates the TE tunnels, but these characteristics (see point a.) are
>    specified as service features not as implementation/deployment
>    behaviors. I can also see that the customer may be interested to know
>    which tunnels are in use to support the service, but the chances are
>    that the customer would not know what these TE tunnels are.
>
> There is one further comment about point d. It is quite possible that
> the customer has requested that TE tunnels be set up as services for the
> customer to use. But these would not be available for support of the
> LxVPN service as they are already services in their own right.
>
> Now, perhaps we should consider the ACTN use case where a VN has been
> built for and delivered to the customer. In this case, the question
> arises as to whether the LxVPN is supported over the VN or supported
> over the provider's network using the resources of the VN. In my view of
> this, the LxVPN is supported over the VN: it is the VN's management
> system that realises the VPN using TE tunnels in the VN, and the VN with
> it's management system and TE tunnels is treated just like a real
> network.
>
>
Yes, at the high level, the mapping could be made to either (1) VN, or (2)
TE topology abstract node (and its connectivity matrix), or (3) set of
tunnels.

The key idea here was to have full flexibility from the YANG point of view
with the use of a 'choice'. As highlighted by you, in the case of LxSM
model, (3) may not be common and in the case of LxNM, (1) would not be
commonly used. There were some discussions on limiting the scope but it was
seen as useful for the YANG to allow various mapping combinations. We could
check if that has changed and in which case we might limit the choice.



> And, on top of all this, now that ietf-vpn-common has been created, I am
> wondering whether that is the sweet spot for augmentation, not the
> LxS/NM models.
>
> This all leaves me thinking:
> A. You want an augmentation to LxSM for enabling enhanced VPN service
>    requests.
> B. You want an augmentation to LxNM for realising enhanced VPN service
>    requests.
> C. You want an augmentation to LxNM to show how TE tunnels are used to
>    realise the VPNs.
>
> A. and B. can probably be done as a common augmentation of
> ietf-vpn-common and should be in a separate document. C. is what this
> document is about. And there is deliberately no D. because exposing the
> TE tunnels in the LxSM is neither meaningful nor possible.
>
>
I am not sure I understand how a common augmentation of ietf-vpn-common can
help.

ietf-vpn-common has a set of groupings that are meant to be used by LxNM
(and future update of LxSM) model.

Currently, the ietf-te-service-mapping-types model contains groupings and a
container for configuration of the te-mapping-templates.
Then ietf-lxsm-te-service-mapping augments LxSM
and ietf-lxnm-te-service-mapping augments LxNM models using the common
groupings.

Even if we make the ietf-te-service-mapping-types to augment ietf-vpn-common,
it would not automatically lead to augmentation of LxSM and LxNM models. Am
I missing something regarding your point on common augmentation?

We did discuss in TEAS and OPSAWG about the best home for LxNM
augmentation, and at that time the preference was for this draft. We could
check if that has changed.

I will work on updating the initial section to better describe the scope of
the I-D.

Thanks!
Dhruv


> Thanks,
> Adrian
>
>