[Teas] [non-zip]RE: A question about draft-ietf-teas-te-service-mapping-yang

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Fri, 16 April 2021 02:54 UTC

Return-Path: <ke-oogaki@kddi.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 662FF3A1038; Thu, 15 Apr 2021 19:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=o365kddi.onmicrosoft.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 SG473U1Atb5U; Thu, 15 Apr 2021 19:54:45 -0700 (PDT)
Received: from kddi.com (athena6.kddi.com [27.90.165.211]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47EB13A103A; Thu, 15 Apr 2021 19:54:44 -0700 (PDT)
Received: from kddi.com ([127.0.0.1]) by LTMC3102.kddi.com (mc MTA5 1.4) with ESMTP id 521041611543744500.26997 ; Fri, 16 Apr 2021 11:54:37 +0900
Received: from kddi.com ([10.206.2.120]) by LTMC3102.kddi.com (mc MTA4 1.4) with ESMTP id 421041611543664100.26962 ; Fri, 16 Apr 2021 11:54:36 +0900
Received: from kddi.com ([127.0.0.1]) by LTKC3124.kddi.com (mc MTA19 1.4) with ESMTP id j21041611543560700.11430 ; Fri, 16 Apr 2021 11:54:35 +0900
Received: from localhost ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA16 1.4) with SMTP id g21041611543462500.11354 ; Fri, 16 Apr 2021 11:54:31 +0900
Received: from localhost ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA11 1.4) with SMTP id b21041611543363300.11286 ; Fri, 16 Apr 2021 11:54:31 +0900
Received: from localhost ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA8 1.4) with SMTP id 821041611543264200.11233 ; Fri, 16 Apr 2021 11:54:31 +0900
Received: from LTKC3132.kddi.com ([10.206.20.239]) by LTKC3124.kddi.com (mc MTA6 1.4) with ESMTP id 621041611543168900.11158 ; Fri, 16 Apr 2021 11:54:31 +0900
Received: from LTKC3132.kddi.com (localhost.localdomain [127.0.0.1]) by LTKC3132.kddi.com with ESMTP id 13G2sV5c012642; Fri, 16 Apr 2021 11:54:31 +0900
Received: from LTKC3132.kddi.com.mid_1046521 (localhost.localdomain [127.0.0.1]) by LTKC3132.kddi.com with ESMTP id 13G2iQ1P006968; Fri, 16 Apr 2021 11:44:27 +0900
X-SA-MID: 1046521
Received: from LTKC3146.kddi.com ([10.206.20.232]) by LTKC3124.kddi.com (mc MTA 1.4) with ESMTP id 121041611442552700.05065 ; Fri, 16 Apr 2021 11:44:25 +0900
Received: from LTKC3146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 4BF7513C0069; Fri, 16 Apr 2021 11:44:25 +0900 (JST)
Received: from kddi.com (LTMC3101 [10.206.2.41]) by LTKC3146.kddi.com (Postfix) with ESMTP id 3AD0413C0055; Fri, 16 Apr 2021 11:44:25 +0900 (JST)
Received: from APC01-PU1-obe.outbound.protection.outlook.com ([104.47.126.52/tls]) by LTMC3101.kddi.com (mc MTA 1.4) with ESMTP id 121041611442488302.24285 ; Fri, 16 Apr 2021 11:44:24 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NhCqktP9CJf1UmbWvn9OWFQKhQ2Db4fVly0Q0G/SSOfKaZeXYENJs3tKXNLF7OMzMtj3T95aN2zfdN2q9lmOUZEUMV6MfHKS9y7V1vXEDKwmM6XFeqoCBiJgRVe7oidFobZPs/P4e12ge9W6sJ68kI6K1hTDXA1XtvomLNCDm6xblrLvt+4hOkQn/5tdBHdGJ+wMhtVQ6QHfTOgD2suJ4GAHVqoHboWcG01mEFxMHlLBZewBhofnZ/52fFE2WXXXfOnONh1eftUnsm9+tmotZm2n5vLioOxsM7Cg18OMadWAvO0duuP4iaNF7neHeNAFvney83uzTL9M5QhX2KEpHQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WOkTDON2qSrPnzDtKqgU1d1b1/71U5MZAyS2euAiulM=; b=KJjexUitwxxAeNlgxh2XcFgZ2/GIoLqMwcKxw/9pVto/zWwH6np7sUvRWe8dSKr7mKzl8sY+xNc0bgFuecRz1FjJ8qVvF2yR6/1Dk2VF1dYWbq3V+uxP7NC1FlUndgydwILM1O80VGKsOyjLp2OiQdkQ9+UFlSB5thlqlNhvQ7Q+f/vGsUDNJEWVV0ECSvhXhnYpSZ4tsAnowEaEQ+aBy3xJCTSrLtFgiTFvi44CS6G5IjpIX9y6db6zkCV0uAPuW8PmOD8C9ooN2W8rCgIxlnKuilZUKSN6gd2aTj5Kmzn+iZXZdYEM0Jp0Zbhj9B+CgiSUcY1/lAqI9Oij1auPJg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kddi.com; dmarc=pass action=none header.from=kddi.com; dkim=pass header.d=kddi.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o365kddi.onmicrosoft.com; s=selector2-o365kddi-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WOkTDON2qSrPnzDtKqgU1d1b1/71U5MZAyS2euAiulM=; b=Wejs+QjsgNC5myg93E1RTlCBu5Hjo8JWnus99MCI4IbGpeiKcUjdB+l3VYfWUcbgc6T6xyuUjlcm5UwuIpLZka4g9xTurhWr1wj86D6I6caKKzNr7QH/tc6X97kUs6q/EPph2ghYiHX1xwSQrBKm1a4h2TYP8e/UH+Xs5jrgMCk=
Received: from TY2PR01MB3562.jpnprd01.prod.outlook.com (2603:1096:404:d5::14) by TY2PR01MB2682.jpnprd01.prod.outlook.com (2603:1096:404:78::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16; Fri, 16 Apr 2021 02:44:22 +0000
Received: from TY2PR01MB3562.jpnprd01.prod.outlook.com ([fe80::68f8:ea85:dc21:a4ba]) by TY2PR01MB3562.jpnprd01.prod.outlook.com ([fe80::68f8:ea85:dc21:a4ba%6]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 02:44:22 +0000
From: "Ogaki, Kenichi" <ke-oogaki@kddi.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, =?utf-8?B?J09zY2FyIEdvbnrDoWxleiBkZSBEaW9zJw==?= <oscar.gonzalezdedios@telefonica.com>, "'Dhruv Dhody'" <dhruv.ietf@gmail.com>
CC: "draft-ietf-teas-te-service-mapping-yang@ietf.org" <draft-ietf-teas-te-service-mapping-yang@ietf.org>, "'TEAS WG'" <teas@ietf.org>, "ta-miyasaka@kddi.com" <ta-miyasaka@kddi.com>, "ry-fukui@kddi.com" <ry-fukui@kddi.com>
Thread-Topic: [non-zip]RE: [Teas] A question about draft-ietf-teas-te-service-mapping-yang
Thread-Index: AdcwzUBvBwL6k6P+RL6+/Q/LUgxBRABZ0poAAAuiFhA=
Date: Fri, 16 Apr 2021 02:44:22 +0000
Message-ID: <TY2PR01MB356235800BE70273302BB48F904C9@TY2PR01MB3562.jpnprd01.prod.outlook.com>
References: <TY2PR01MB3562540E0CC73E39184AB8F4904E9@TY2PR01MB3562.jpnprd01.prod.outlook.com> <00d501d73234$8dae2f50$a90a8df0$@olddog.co.uk>
In-Reply-To: <00d501d73234$8dae2f50$a90a8df0$@olddog.co.uk>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; dmarc=none action=none header.from=kddi.com;
x-originating-ip: [175.129.6.66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 540b0fa4-9955-4052-24f1-08d900818a7b
x-ms-traffictypediagnostic: TY2PR01MB2682:
x-ld-processed: 040b5c43-0c27-49b3-b8e6-cdec886abcee,ExtFwd
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <TY2PR01MB2682E51E0910278A8313B9D0904C9@TY2PR01MB2682.jpnprd01.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nrfCXbpcKtTBwZZx0iAsmBUmy4ELshqVTvDygdDhL3y+fVHF6gItwzL8yQ2P4JdA4W0jBM7rQt+GSjhrOjROZYjE5bUC0vZAzz6DEF+HgA5vGt605Hl9z/RmimbLsVklsLbLCTcN8iKqwRyiJuXKs4xJsc2HfuKPtGnb4Q3WqGFWWrtNZu8pJBBrK10r3CXgCpXhGPArFv7gH7wTq7U15K0iAJexyXS0fSf8ZyGmqCuO2RR/kWIMd9Rjzl/Em/75UR+Mg1+UdWRHBKrRvZvJmsZEuFpvUdkpXuqA4V6pdqpovx5EhqpGgcEi6ElMxtJ4kLGIjeKNMgp4EQ5T6EdETYQ+nPxW1UHJzsj3hKSxwZ4NmPeE3ka4MRFTf08gU+7ReHztiSbMxM4HMqaPeoRPz2CVQPpIaRxZnhieJ+dFXxUzRcHVkDWaII/ERWA1CDGrRjUY5jnOeo7Rq+XbYtqPi6Rof6USYDZl1SU1djjUdeo+BYcxvD2EEleKRQa1Xuxev/SDd4KAIQer2MNrKwrz6Gxdwp/UEuRcvhHcU2IopSexV9HODP3C56nDICICzL+yT47lH4M3u6Br8dFseBeK6EeKeRdvnu872P5yHh8cUbI=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TY2PR01MB3562.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(39860400002)(136003)(396003)(38100700002)(8676002)(54906003)(110136005)(55016002)(122000001)(107886003)(76116006)(5660300002)(85182001)(30864003)(33656002)(2906002)(86362001)(53546011)(316002)(7696005)(52536014)(71200400001)(66446008)(66946007)(66556008)(66476007)(26005)(6506007)(66574015)(186003)(83380400001)(478600001)(9686003)(8936002)(64756008)(4326008)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?R1kxenYzdXIzZWVjZXRCcXlQbVo4ZXRFZ3F4bTRoaGhxOGhGcGhUcXRuUEVv?= =?utf-8?B?cEVEYy9DUndHZTErRU5GdnBsZG8zVk5abEtuOEhxb3hDTVhvemlUOWFRQkVT?= =?utf-8?B?c29VOGc4LzdabHB5VjRTT2lLYlRGcnVNR1c1ZytzdkxiWldEUHhONFBSZ21G?= =?utf-8?B?bUM3QjcvUERYM2JjVDZ2c3d0WmxzNzFHcFBDQ29mV0N2OURidVk5Q1lrVmVI?= =?utf-8?B?Z1VYTTZPUlV2eGtlVVVzaWJTVmE1bjNLMUJqMkdCZEdaOEgrb0xNWDhIYm5H?= =?utf-8?B?cGFtdkNjTkFIWUcrd01EWEpvcGwxQSs1OThYTXRoRzVjS3I1THR5eWFjbC9m?= =?utf-8?B?QXM4clJpbTlJOElVZHpWQjFwaTM3K1pSWkk0cGVHdXJ3RkloNE1XVUlFV0w0?= =?utf-8?B?TW9kVE93dFF6VnNJb2xrbkFIMWlnRFVsYStwNjlyaldPc0l5YjFLUmdNSkVC?= =?utf-8?B?NzlpZ2F6ZDlzK0ViY2U4WENFelh0aU55NUMyTDZ6d1c0QUIrRm9mYU14OFEz?= =?utf-8?B?b0FmcDYvckwwOTVBOE9xd2c5WFgwblJpZWRQTkFmOUFoTTYra3F6VUJSZ21V?= =?utf-8?B?MmsvbFlsbnI3MU01clhEcFQ1Vldvbkx3cFluWDZjUnJpSC9IRXhxQ0ViTjBj?= =?utf-8?B?RVNMaFErT241SEIyOW5XMzVYL2xGSCtUL1BxQ3J1eXdDWEhCbDlMSlc3ZG90?= =?utf-8?B?UFY4VmxJQUJOVWVWR2pNZ25kL2xyV0RSemdhNWJ1cjRxNXByb3AzZ1E0bjZV?= =?utf-8?B?SGNsRXJyU3NZcDNkSWplVmE3bDVIeHpiaXdpQjYyOXg0a0V1Z1pMQ0Y0OU0v?= =?utf-8?B?UVNMandWUWU3OGpmR29TR00zTXg2ODFOTWFiMEZKem5qa1FtRTlqRXE2ci9R?= =?utf-8?B?OEJkWEYvdXpxK1Nva0c2YUZkQTN3Um9mU29VTHlLYWUvZFV5azIzbTk4Mjlv?= =?utf-8?B?TGhaRWh3Z3VwVnFiakVyOEtmMkFXaGtqdzJkZ1VDcnZKSGd6QzlsYTQ2MHFY?= =?utf-8?B?dHhERHBZY293VEhoc0phVW1sWFhWemJ6c0pGOHlCd1hlR3RyZG9ySVFRdzZO?= =?utf-8?B?aWgyYW90d1hRUkxHRm5FQWpEVzBBMEMyejI3elBqRlk4MS91SHdyYUl6Q0dV?= =?utf-8?B?WCtXVUZpRWIvRUE3ek1BeWJrOWxXZGRyMHdQL3BRQzV6NUFtOGtyaU5ZWTJl?= =?utf-8?B?VjZrNFdFSlJ3VkJCS3BJWUNrQ0FVL1pZOXNZY3lOanF5MlIwbzhCa3Bic2sr?= =?utf-8?B?d2ZQZWJldnh4QXo4WWdramIxaThrdndUbDR6T2ovYnBzK2V1RVkzeEFUWjZS?= =?utf-8?B?YWV6YlIzVkkvQ3hwUDdUbTZoU0x6dHVsMFY5T0h4aXJ6WWc4WS9zVERIK2tN?= =?utf-8?B?ZVZnTkllZi9KZEs4ZFpveVZ4eU8yV1JBTWlGcjE0ZENrVFJEaTd3MVVYTUZQ?= =?utf-8?B?Z1Ira0o5c0U3eVVkOVYvYURhWU5VZGQ0VkhPYndEcCs3aG9RcmlLZFFBLytq?= =?utf-8?B?b1BKbVRrenpUclFHR05yWVF2QmxQcFBPRGRsanYxVU5xNjlJdGx4VWFxOWpo?= =?utf-8?B?bGFSSE5odW1DQ0JLMUVvaDFqRnZCTTRLbEhqSk1ta3RWTExoaVBjcldzMlRB?= =?utf-8?B?ZUw1RWEzOEZpZkoyVFNxMzlGdXBJTHRKankxMnJVRDFUaDVvTU53T2JiTUR0?= =?utf-8?B?UGh4bSsrcDEwYU1oNEJCUDdpdHFSOW5rWHdwUS94eEJoSkxMellBMzlVMFpt?= =?utf-8?Q?rXv6lijTRe0CHDx/6c=3D?=
Content-Type: multipart/alternative; boundary="_000_TY2PR01MB356235800BE70273302BB48F904C9TY2PR01MB3562jpnp_"
MIME-Version: 1.0
X-OriginatorOrg: kddi.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: TY2PR01MB3562.jpnprd01.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 540b0fa4-9955-4052-24f1-08d900818a7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Apr 2021 02:44:22.2553 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 040b5c43-0c27-49b3-b8e6-cdec886abcee
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: S70bQnd1JbrTaQQqSyU+bvKu0gL4wO6gqhAy060W5EJuMKfRrOb17X7Fkc8cBGsko3J8apNb1xmk0wdpf0DxGg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2682
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nzNkM3AogUvS1GAQhsf0LerQzF4>
Subject: [Teas] [non-zip]RE: 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, 16 Apr 2021 02:54:53 -0000

Hi Adrian,

Thank you for continuous discussion.

In the case of “VN as a service” (Yes, we agree that no one is offering this as a service to external customers yet, but perhaps it is offered as a service to other divisions of the same company? In that case, the “consumer” should be treated as a separate administrative organisation.) the VN is *realised* inside the Provider space, but it is handed over to the Consumer as a separate network that the Consumer operates.

[KO4] Yes, I believe this is the first usecase.

In the other situations, where the VN is entirely inside the Provider network, the Consumer is actually unaware that there is a VN. The Consumer just asks for a VPN service to be provided by the Provider. If the Provider chooses to build a VN to support the Consumer’s VPN that is a private matter for the Provider – It is a bit like the Provider deciding to make some network slices to support different customer requests.

[KO4] This is my scenario 1). I agree this should be solved the extension/augmentation of the current LxSM with additional characteristics constraints as you draw.
The question is why my scenario 2) re-drawn below is not allowed?
Especially, once VN as a service is preliminary offered inside a Provider like us, the VPN service division somewhat wants to control and be aware how the underlying network is characterized even if this is abstracted.
Even now, our account SE is commonly requested a kind of affinity as Oscar wrote from our customer, and puts them into the provisioning order as possible, also sometimes is required to explain how network is composed to the customer.
When a provider begins to commit the characteristics provided by VN, this should escalate. This may be only Japanese customer’s case…

                                  +----------+
         CNC-1 (Controller for VN)| VPN'as a | CNC-1 (Controller for VPN)
            :                     | service  |  :
            :                     +----------+-CMI-LxSM-VPN service request---
                                                  w/ te-service-mapping
            :                     |          |  :
            :                     |   VPN    | MDSC-1 VPN Orchestrator (LxNM)
            :                     | instance |  :
            :                     |          |  :
            :                     |          |  :
Consumer --CMI VN service request-+----------+-MPI-------
            :                     |          |  :
---------   :                     |   VN     | PNC-1 (VN)
          MDSC-2 VN Orchestrator  | instance |
            :                     |          |
Provider --MPI--------------------+----------+---------
            :                     | Physical |
          PNC-2 (Phys network)    | Network  |
                                  +----------+

Thanks,
Kenichi

From: Adrian Farrel <adrian@olddog.co.uk>
Sent: Friday, April 16, 2021 5:19 AM
To: 大垣 健一 <ke-oogaki@kddi.com>om>; 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com>om>; 'Dhruv Dhody' <dhruv.ietf@gmail.com>
Cc: draft-ietf-teas-te-service-mapping-yang@ietf.org; 'TEAS WG' <teas@ietf.org>rg>; 宮坂 拓也 <ta-miyasaka@kddi.com>om>; 福井 良平 <ry-fukui@kddi.com>
Subject: RE: [non-zip]RE: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

Thanks for continuing this discussion, Kenichi. I believe it is helping me to understand the differences as well.

What I find very significant is that in all your figures you place the VN insider the Provider space.

In the case of “VN as a service” (Yes, we agree that no one is offering this as a service to external customers yet, but perhaps it is offered as a service to other divisions of the same company? In that case, the “consumer” should be treated as a separate administrative organisation.) the VN is *realised* inside the Provider space, but it is handed over to the Consumer as a separate network that the Consumer operates. I would draw…



         +----------+

         | VPN as a | CNC-1 (Controller for VPN)

         | service  |  :

         +----------+-CMI-LxSM-VPN service request-----

         |          |  :

         |   VPN    | MDSC-1 VPN Orchestrator (LxNM)

         | instance |  :

         |          |  :       CNC-2 (Controller for VN)

         |          |  :         :

Consumer +----------+-MPI-------CMI VN service request-

         |          |  :         :

---------|   VN     | PNC-1 (VN) :

         | instance |          MDSC-2 VN Orchestrator

         |          |            :

Provider +----------+-----------MPI--------------------

         | Physical |            :

         | Network  |          PNC-2 (Phys network)

         +----------+


A bit complicated 😊 But this is the consequence of providing a service on top of another service

In the other situations, where the VN is entirely inside the Provider network, the Consumer is actually unaware that there is a VN. The Consumer just asks for a VPN service to be provided by the Provider. If the Provider chooses to build a VN to support the Consumer’s VPN that is a private matter for the Provider – It is a bit like the Provider deciding to make some network slices to support different customer requests.

Essentially, where a VN is used, this figure remains exactly the same except that the line separating the Consumer and the Provider can be moved upwards when the VN is hidden from the Consumer.

Of course, an implementation may bundle MDSC-1 with CNC-2 into a single code component. Similarly, PNC-1 and MDSC-2 may be bundled together.

Best,
Adrian

From: Ogaki, Kenichi <ke-oogaki@kddi.com>
Sent: 14 April 2021 02:27
To: adrian@olddog.co.uk; 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com>om>; 'Dhruv Dhody' <dhruv.ietf@gmail.com>
Cc: draft-ietf-teas-te-service-mapping-yang@ietf.org; 'TEAS WG' <teas@ietf.org>rg>; ta-miyasaka@kddi.com; ry-fukui@kddi.com
Subject: [non-zip]RE: [Teas] A question about draft-ietf-teas-te-service-mapping-yang


Hi Adrian,



I understood what’s difference between what you and I see.

I don’t object the following Scenario 1) and 3) at all, but I have seen Scenario 2) with te-service-mapping-yang as a first scenario, once VN service emerges/is exposed to consumer.

If this is not general requirement for providers like us, we only use the current version of te-service-mapping-yang as LxSM augmentation even if LxSM augmentation is omitted in the future version.





Scenario 1)



Consumer

              VPN' as a service

------------+--------------+----LxSM-------

              | VPN'instance |     LxNM

Provider     +--------------+     MDSC

              |  VN instance |

              +--------------+





Scenario 2)



Consumer

              VPN' as a service

-----------+--------+---+--------+--LxSM’--MDSC-

             |  VPN    | + |    VN   |   LxNM

Provider   |instance|    |instance|

             +--------+    +--------+







Scenario 3)



               VPN' as a service

Consumer      +--------------+    LxSM

                | VPN'instance |    LxNM

-------------+--------------+----MDSC--------

                |  VN instance |

Provider      +--------------+







[AF2] When the VN is provided as a service to the consumer, the operation of the VN belongs to the consumer.

If the consumer decides to operate a VPN over the VN then the consumer is responsible for realising the VPN over the VN.

That means that the consumer runs the VN Orchestrator. In this case, the LxNM is present in the consumer's management space, and it is augmented by the mapping model to coordinate with the resources in the VN. But the LxSM is still unaware of the tunnels and network resources.



[AF2] I think I still disagree ☹

When the VN is exposed as a service, it is the customer's job to manage that VN. In particular, it is the customer's job to orchestrate the VN to support the VPN service.

The LxSM is how the customer configures and requests a VPN service.

The LxNM is how the orchestrator operates the network to support the VPN service.

That means the LxNM is used by the VN orchestrator to manage the VN.

In my opinion, that means that the LxSM never has knowledge of the underlying network resources, but the LxNM does have that knowledge.



[KO3] I can’t still understand why the consumer run the VN Orchestrator in cases of Scenario 2) and 3). What do you mean “the operation of the VN”, “manage that VN” and “orchestrate the VN”? If you are saying that the consumer create a different VN on top of the provided VN using VN orchestrator, I agree. But, if the case that the consumer just uses the provided VN like provided VPN, the consumer doesn’t need the VN Orchestrator. Am I something misunderstanding?



Thanks,

Kenichi





-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk<mailto:adrian@olddog.co.uk>>
Sent: Tuesday, April 13, 2021 6:46 PM
To: 大垣 健一 <ke-oogaki@kddi.com<mailto:ke-oogaki@kddi.com>>; 'Oscar González de Dios' <oscar.gonzalezdedios@telefonica.com<mailto:oscar.gonzalezdedios@telefonica.com>>; 'Dhruv Dhody' <dhruv.ietf@gmail.com<mailto:dhruv.ietf@gmail.com>>
Cc: draft-ietf-teas-te-service-mapping-yang@ietf.org<mailto:draft-ietf-teas-te-service-mapping-yang@ietf.org>; 'TEAS WG' <teas@ietf.org<mailto:teas@ietf.org>>; 宮坂 拓也 <ta-miyasaka@kddi.com<mailto:ta-miyasaka@kddi.com>>; 福井 良平 <ry-fukui@kddi.com<mailto:ry-fukui@kddi.com>>
Subject: RE: [Teas] A question about draft-ietf-teas-te-service-mapping-yang



Hello again 😊



> 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



[KO2] If this layering is correct, meaning VN as a service is not commonly used by an end-customer like our current VPN users, I agree.



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.



[KO2] What do you mean by "are both within the customer's control"? What "are both within the customer's control"



[AF2] When the VN is provided as a service to the consumer, the operation of the VN belongs to the consumer.

If the consumer decides to operate a VPN over the VN then the consumer is responsible for realising the VPN over the VN.

That means that the consumer runs the VN Orchestrator. In this case, the LxNM is present in the consumer's management space, and it is augmented by the mapping model to coordinate with the resources in the VN. But the LxSM is still unaware of the tunnels and network resources.



[AF2]Talking to someone else yesterday, they suggested that the VN may be created by the operator to enable services for a customer, but that the VN is not exposed to the customer. It is a way for the operator to "partition" their network and provide service guarantees to the customer.

I think this is OK, but in this case the consumer is entirely unaware of the VN. When the consumer asks for a VPN service they do not see any difference if there is a VN or no VN. That is, the LxSM model is not augmented by the mapping model.

The operator may need features to map the VPN service onto the VN, and this shows up in the LxNM via the mapping model.



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



[KO2] You are right. I just indicated a possible next step, not current situation.

I may require a shortcut solution for a) and A,B,C,D), once VN service with actn-vn-yang , for example, emerges.

As you wrote, VN service should exist behind LxNM optimally and not be exposed to any end-customer. However, once we decide that VN service is exposed to an end-customer like a large enterprise user, this becomes a case.



[AF2] I think I still disagree ☹

When the VN is exposed as a service, it is the customer's job to manage that VN. In particular, it is the customer's job to orchestrate the VN to support the VPN service.

The LxSM is how the customer configures and requests a VPN service.

The LxNM is how the orchestrator operates the network to support the VPN service.

That means the LxNM is used by the VN orchestrator to manage the VN.

In my opinion, that means that the LxSM never has knowledge of the underlying network resources, but the LxNM does have that knowledge.



Best,

Adrian