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

Adrian Farrel <adrian@olddog.co.uk> Thu, 08 April 2021 21:27 UTC

Return-Path: <adrian@olddog.co.uk>
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 82B283A1D65; Thu, 8 Apr 2021 14:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.802
X-Spam-Level:
X-Spam-Status: No, score=0.802 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=2.699, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 hPR5LgfjAij5; Thu, 8 Apr 2021 14:27:44 -0700 (PDT)
Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70BEF3A1D64; Thu, 8 Apr 2021 14:27:41 -0700 (PDT)
Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 138LRdFZ019015; Thu, 8 Apr 2021 22:27:39 +0100
Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DBC3C2203D; Thu, 8 Apr 2021 22:27:38 +0100 (BST)
Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id C327B2203C; Thu, 8 Apr 2021 22:27:38 +0100 (BST)
Received: from LAPTOPK7AS653V (74.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.74] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 138LRcRx004956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Apr 2021 22:27:38 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-ietf-teas-te-service-mapping-yang@ietf.org>
Cc: <teas@ietf.org>
Date: Thu, 8 Apr 2021 22:27:36 +0100
Organization: Old Dog Consulting
Message-ID: <085201d72cbd$ff5ff9c0$fe1fed40$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdcsvdezyQQF/L3zSuGnrgrzYkyiGw==
Content-Language: en-gb
X-Originating-IP: 81.174.197.74
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26078.007
X-TM-AS-Result: No--8.406-10.0-31-10
X-imss-scan-details: No--8.406-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26078.007
X-TMASE-Result: 10--8.405600-10.000000
X-TMASE-MatchedRID: fr/TTUtmA4NlJLKspAhkh7IGMNfiwa5NRiPTMMc/MmmlCu6kKVgvEooq qJHJHX2WBNyCmIook0ffHbErV3r4kdpUsVk2Y0Y0naqtHOuEdaqOQOsE4nDCdHNAt+hcPnO5IdT h+A4NuJsZzVHwb6jDWS71bM5lZ8jz6sEU5+BT/F0zxdO2BTO20yv2BWU4g3/qBCzD0Dc8iUuw0F FGdeCd9m/ILrZx6RXvoUsqvjzSYSp+lRw5ka19jkUzvZoSFxuNQR7lWMXPA1sFqrxVoN14OvevB 5ALQlRg8HOIRFU6KmrRRjITm+/ALKlGv9OFH1+e8ZJ/Hrqb5oxVogWRsEaR/iJ8zskw0dbrTTq9 jtlTP+dVNqJhpVgoH1dYEZ0gI+wHZHlaVj9ksvl2GcWKGZufBcnlJe2gk8vIMCFeUKir/8pPFK6 BTThqe82RBibhhNngVmQnTTPLPg/txRbVyxLzpsU6SdzkI293pWOBfK9L1z8tferJ/d7Ab0+ddn 27YiEdmuvQwTBFk21Eqnyat/KgieuGGicLyrxDwY28o+cGA5oKF0jiwuWuOKff6cBm538VVhYZj y1spv57rwrQYudi9iShuNitBQucnjW/JqMkoPMsYOarN8c4H2AW2j9VWc0le2C7O9LWcZK0y3Da 3B9hq+LzNWBegCW2XC3N7C7YzrfQqQhSw0x2VN0H8LFZNFG7bkV4e2xSge5yG0IzoFcBTBX8+Tl FEAhaYJdXRQpLZ08ZCjUPS5BY5RyFdNnda6Rv
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/QtgcES7S0P2yg6YLSlZosPVfQVI>
Subject: [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: Thu, 08 Apr 2021 21:27:48 -0000

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.

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.

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.

Thanks,
Adrian