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

Adrian Farrel <adrian@olddog.co.uk> Mon, 12 April 2021 09:22 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 6FC983A1477; Mon, 12 Apr 2021 02:22:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.783
X-Spam-Level:
X-Spam-Status: No, score=0.783 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=2.699, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 2v5Ao7G-ZG_8; Mon, 12 Apr 2021 02:22:28 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 D18F43A1475; Mon, 12 Apr 2021 02:22:27 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 13C9MNfH013179; Mon, 12 Apr 2021 10:22:23 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C9A5E22161; Mon, 12 Apr 2021 10:22:22 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id B3A1422160; Mon, 12 Apr 2021 10:22:22 +0100 (BST)
Received: from LAPTOPK7AS653V (74.197.bbplus.pte-ag1.dyn.plus.net [81.174.197.74] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 13C9MLfr018575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Apr 2021 10:22:21 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Ogaki, Kenichi'" <ke-oogaki@kddi.com>, "=?UTF-8?Q?'Oscar_Gonz=C3=A1lez_de_Dios'?=" <oscar.gonzalezdedios@telefonica.com>, "'Dhruv Dhody'" <dhruv.ietf@gmail.com>
Cc: <draft-ietf-teas-te-service-mapping-yang@ietf.org>, "'TEAS WG'" <teas@ietf.org>, <ta-miyasaka@kddi.com>, <ry-fukui@kddi.com>
References: <085201d72cbd$ff5ff9c0$fe1fed40$@olddog.co.uk> <CAB75xn7918o5CcJ8zaGUPw7B-f4HtbYDGf=4Hi3y==eUL38ydQ@mail.gmail.com> <PAXPR06MB787220F5CB9936C46C042A28FD739@PAXPR06MB7872.eurprd06.prod.outlook.com> <091701d72d3f$5ae2edd0$10a8c970$@olddog.co.uk> <TY2PR01MB3562A0265D671FCFB905973D90709@TY2PR01MB3562.jpnprd01.prod.outlook.com>
In-Reply-To: <TY2PR01MB3562A0265D671FCFB905973D90709@TY2PR01MB3562.jpnprd01.prod.outlook.com>
Date: Mon, 12 Apr 2021 10:22:22 +0100
Organization: Old Dog Consulting
Message-ID: <0a8e01d72f7d$589ef970$09dcec50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHuybqhXPeuqzK5WVjkh5P9WVHmOgH2EXzjAhz5gPQDDzYBtwEXj2B9qj+ShRA=
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-26086.007
X-TM-AS-Result: No--15.717-10.0-31-10
X-imss-scan-details: No--15.717-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26086.007
X-TMASE-Result: 10--15.717000-10.000000
X-TMASE-MatchedRID: CxmI61mtwh/xIbpQ8BhdbDjNGpWCIvfTkYC3rjkUXRLe6dEbvIyrxVJg /9hqcAh+Hj1jg5yS41KlSAHrgJy+OV+Eq67yG12isgYw1+LBrk3XJ9TQ+cQuGvizcX4KtjQMZ6W GoMAL2MnyagOiApv6cz3GIUknTeR/wEqviKZerF2Vd49c0zgWMxlKjo8zguyK1+OTFqKF59kpXI Os5jngRvut55Fksf0tg9vDTbe8QshqEf6Xr7r2WBn0wrEetTLheF6MevMVZUArhioeAJKilU21a kWPLhVXbLObj8FxY/3TqsqrPjni5O8z/FxAXLyC8hkWz3JvTZIiJN3aXuV/obhHzo8pkdgW+/Kq neiC8jaXjkx9ZOu8Qp09pgURDiYV8TjCRfuqbuzece0aRiX9Wt8h+E5Uefev31GU/N5W5BDjAsu +V4KeapFbAbroydJRYcswpLgslFHLn7BI/CexuzZoNXJMbH+n+w0sO/h8u3noN8DSoota+WG7iT A2/9zRcQAnYVY/iCrhyWvr4b2LOfJpYN2UUHMHbWsCUkrA4ElMJn8zcSZbbW3D6f6IpbLILAvtN ByreRz3dI+pW+jRBBwrUyfYFQArnvp70Y6l9AoCPm8/Dzv8BaUYIgxuvuD+RtqpRW8sWyLLqKAd rGpCH9/yNnbhIISMxN+vL5OujHSeqycFZQnNCw8ztOE++IFo8wxV8JR3Nqgh44tUX96R0EVO09M eWy6ccZqk11vJs+UBKjVc0+Gs+tDXdVxY6XqG8+CtAqvHcH6WGk93C/VnSlAoBBK61BhcGdRnwO gRQQulJJRwFJayM/KwMfDyrD1mGs6SE2BAIlaeAiCmPx4NwFkMvWAuahr8m5N2YHMD0b8MyrfP9 j+C1d934/rDAK3zGjFMngtLLWicA6dTiL9841n/fKWeayT48P48nX0qe76lIG5bXvRJ0X1V9oGS pGJciO9ir6gAXDU=
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/QToatI0KqqtZVSs1bNpR29PqFZs>
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: Mon, 12 Apr 2021 09:22:33 -0000

Hi Kenichi,

Thanks for your input.

[snip]

> But
> what was NOT included in the draft is any detail on a) how the network 
> is “traffic engineered” b) which charateristics must this traffic 
> engineering have and c) which traffic of the VPN goes into which 
> tunnel…. One of the main reasons to leave that out was to avoid the “boiling the ocean”
> problem and limit the scope to opsawg. TE… would be dealt of course in 
> TEAS ☺

OK, and those three objectives (a, b, c) are reasonable things to put into the network model. Just not, IMHO, into the customer service model.

[KO] As Adrian described below, when VN is a service and our customer uses the VN as a service, why is the VN put into the network model reasonable? Am I something misunderstanding?
 "In this case, in my opinion, the cooked topology delivered to the customer is in the form of a service already. It might be a VN or it might be a set of connectivity services (i.e., tunnels). In this case, the delivery of a service over a service is highly ambiguous and I don’t think it falls within the operator’s capabilities to achieve it. The cooked topology is for the customer to use as they see fit."

[AF] I think the key here is to understand the layering. So when you say *the* network model I think there may be some ambiguity.

I see...

VPN
------- LxSM model -- Customer ask for a VPN operated over the VN
------- LxNM model -- VN orchestrator plans and provisions the VPN over the VN
VN
------- VN service model -- Customer asks for a VN over the operator network
------- VN network model -- Operator's network orchestrator provisions the VN

In this case, the LxNM is operating in the customer's management space. The operator is unaware of the VPN and is unaware of how the VN is being used by the customer.

We must be careful to not think that the LxSM is the interface between customer and operator. It is the interface between consumer and provider which, in this case, are both within the customer's control.

Similarly, we must be careful to not think that the LxNM is an internal interface in the operator's domain. It is an internal interface for orchestrating a network, but in this case that network is the VN and is owned and managed by the customer.

[snip]

>>> 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.
>
> [Oscar] If by TE tunnel you mean the real tunnels deployed in the 
> operator network, I would say that as a general rule NO. Precisely the 
> goal of the Service model is to provide an abstraction and capture the 
> requirements without needing the customer to know the internals of the 
> operator network.

So far so good.

> If by TE tunnel you mean an abstraction of a topology “cooked” and exposed
> to the customer, the answer is yes….   

OK. Here we have some disagreement.

In this case, in my opinion, the cooked topology delivered to the customer is in the form of a service already. It might be a VN or it might be a set of connectivity services (i.e., tunnels). In this case, the delivery of a service over a service is highly ambiguous and I don’t think it falls within the operator’s capabilities to achieve it. The cooked topology is for the customer to use as they see fit.

So how would this work? Well, the cooked topology has a cooked-topology-orchestrator that is able to control and provision services over the cooked topology using, for example, an LxNM to realise a VPN service over the cooked topology. In this case, the LxSM is unchanged, and the LxNM for the cooked topology refers to the tunnels etc. in the cooked topology.

[KO] When the cooked topology is VN, then MDSC should be a cooked-topology-orchestrator and the cooked-topology is provided by CMI. In my understanding, CMI is a kind of LxSM.

[AF] Yes, that it (IMHO). As noted in the ACTN work, the MDSCs can be stacked recursively. There is an MDSC for managing the deployment of services in the VN, and there is another MDSC for manging the deployment of the VN in the operator's network.

[snip] 

>>> 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.

[KO] I think this might be technically correct, but VN service and VN's management system have never commercially existed yet, and there are only LxVPN's management systems. Under this situation, operators should desire the existing LxVPN's management systems to utilize/map VN resources for the existing LxVPN service, when the VN service has emerged. Thus, I believe te-service-mapping-yang should exist.

[AF] I'm having trouble following this.
I think you are saying that (today) no one sells a VN, and (in consequence) there is no such thing as a management system for a VN. I can believe that.
But then you say that it is important to be able to map the VPN onto the VN resources. This I can't understand because a VN is a service, and you have said that service doesn't exist. In particular, the customer will not be aware of the VN resources because they are not aware of the VN service.

I wonder whether what is going on is that the ACTN VN is being used (or thought about) as a way for the operator to partition the operator's network resources to make different pools of resources available for different customers. This is similar to network slicing, but it is being done privately by the operator in order that they can guarantee the services requested by the customer. 

I'm guessing about that, but it would make good sense. However, in that case, the customer is still not aware of the VN, and it is for the LxNM to include the mapping to TE tunnels.

[snip]

> [Oscar] Don’t forget the missing piece. We have focused on tunnels and 
> how they map to the service. BUT, we need to steer the traffic into 
> the tunnels. So, we still have the problem or where to indicate the 
> policies that tell
> - The customer traffic matching the charactericts A,B,C (a ToS field, 
> coming from a prefix or any kind of hint by the customer) goes into which tunnel.

Oh, this looks remarkably like the same problem we have for:
- MPLS LSPs (see also draft-ietf-pce-pcep-flowspec)
- BGP flows (see also RFC 8955)
- SFC classification (RFC 7665)
- Service mapping (per VPN+ and network slicing)

This looks like a generic problem that needs a YANG model that can be used at a number of layers to describe flows and provider a pointer to their disposition

[KO] We have had the same requirements and requested to te-service-mapping-yang, and then Dhruv already put them in the following thread.
https://mailarchive.ietf.org/arch/msg/teas/R6HH4w6pr2V205aPCScCGbw0Mjs/

[AF] Yes. I read that thread (thanks for reminding me) to be about how you might support different flow characteristics within one VPN by mapping the different flows to different VNs or different TE tunnels to meet the different quality demands.

Best,
Adrian