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

"Ogaki, Kenichi" <ke-oogaki@kddi.com> Tue, 13 April 2021 03:16 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 CE6483A10FF; Mon, 12 Apr 2021 20:16:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 OVkkaY9AyVxP; Mon, 12 Apr 2021 20:16:35 -0700 (PDT)
Received: from kddi.com (athena7.kddi.com [27.90.165.212]) (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 76FCB3A10B3; Mon, 12 Apr 2021 20:16:35 -0700 (PDT)
Received: from kddi.com ([127.0.0.1]) by LTMC3103.kddi.com (mc MTA5 1.4) with ESMTP id 521041312163208700.28785 ; Tue, 13 Apr 2021 12:16:32 +0900
Received: from kddi.com ([10.206.2.120]) by LTMC3103.kddi.com (mc MTA4 1.4) with ESMTP id 421041312163130100.28753 ; Tue, 13 Apr 2021 12:16:31 +0900
Received: from kddi.com ([127.0.0.1]) by LTKC3121.kddi.com (mc MTA19 1.4) with ESMTP id j21041312163027000.23345 ; Tue, 13 Apr 2021 12:16:30 +0900
Received: from localhost ([10.206.20.239]) by LTKC3121.kddi.com (mc MTA16 1.4) with SMTP id g21041312162929100.23289 ; Tue, 13 Apr 2021 12:16:27 +0900
Received: from localhost ([10.206.20.239]) by LTKC3121.kddi.com (mc MTA11 1.4) with SMTP id b21041312162829600.23223 ; Tue, 13 Apr 2021 12:16:27 +0900
Received: from localhost ([10.206.20.239]) by LTKC3121.kddi.com (mc MTA8 1.4) with SMTP id 821041312162730100.23170 ; Tue, 13 Apr 2021 12:16:27 +0900
Received: from LTKC3131.kddi.com ([10.206.20.239]) by LTKC3121.kddi.com (mc MTA6 1.4) with ESMTP id 621041312162707500.23121 ; Tue, 13 Apr 2021 12:16:27 +0900
Received: from LTKC3131.kddi.com (localhost.localdomain [127.0.0.1]) by LTKC3131.kddi.com with ESMTP id 13D3GQn9011491; Tue, 13 Apr 2021 12:16:26 +0900
Received: from LTKC3131.kddi.com.mid_1491599 (localhost.localdomain [127.0.0.1]) by LTKC3131.kddi.com with ESMTP id 13D36LOm007782; Tue, 13 Apr 2021 12:06:21 +0900
X-SA-MID: 1491599
Received: from LTKC3146.kddi.com ([10.206.20.232]) by LTKC3122.kddi.com (mc MTA 1.4) with ESMTP id 121041312062037400.09202 ; Tue, 13 Apr 2021 12:06:20 +0900
Received: from LTKC3146.kddi.com (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with ESMTP id 4294E13C006E; Tue, 13 Apr 2021 12:06:20 +0900 (JST)
Received: from kddi.com (LTMC3104 [10.206.2.56]) by LTKC3146.kddi.com (Postfix) with ESMTP id 2C1E113C0053; Tue, 13 Apr 2021 12:06:20 +0900 (JST)
Received: from JPN01-TY1-obe.outbound.protection.outlook.com ([104.47.93.50/tls]) by LTMC3104.kddi.com (mc MTA 1.4) with ESMTP id 121041312062006300.27318 ; Tue, 13 Apr 2021 12:06:20 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FeXDlzD++0UzTYm4a+3ZsNej6EaiHBmP6dgVMB0oqn9YXUFZbi0d2a1b3Gy4vE1nsfh/nYfurU2fvzSFuXXNMoe0+zf8KB5SKaTor25CtKjNGxF3oEoNjBEHkft3aoEZzomywmYOSgG+G1k5jy+p8Yg44TX4frqGserlqHf/VGahG9HbKII4MvtTxOkL8qV/xJjsBOxYjcGwmfb4u88oyCbsFRKFXkviumk1Z7Psx+l+MTg2evqduQUo+BuATVkPPuRr6PnoK4N2pFY4ATIdj0y/hGIZ/cGBfk63E8PQrY4OwcSSKM1ZiZYWkauKnj1bdyAaDjT2boXaFE5vKmQLrw==
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=Y6jAia+GTscja1GWSpbqGU0SgAozOjNJgcAY2aM/sqU=; b=cr5eHH2IjvWsG0FwAaPeXIPtU+yzMBrJ6hrTJ06n03V04SHVhJsRzBWeH/z+NLygW3IgG43YI0VqmNJ8N9afppZdAmE6DoSdFsyjPYsFthBIZdK8f4tmAbJ/89lqx8uDzVBwp5sXFmFDbXYYIyLs1Z/kzY5+IDx0O5JO5jaanYLpDEs8PAwsstmGNvp3l8n28mOE0dDi2q53j/zwtqEyrxvKwjDOE8RFUoa2zgLa0m2FI2FrzCuu0AHCFOvbKK/3CNS1eioc2k7/MgyrMleaXVJruAzLs/Cja0cndZaJ2J1rkVe0cBev/0CmbPrHvxBtooeOTlokBLCYe5aPyPZLDQ==
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=Y6jAia+GTscja1GWSpbqGU0SgAozOjNJgcAY2aM/sqU=; b=Fno2WxK3KIM9Io0PJ5jJZDetur1kr/yzJ2pmkjcsCUDxkZ/0V2W/LVJMvKWS3ikZvcmln4epHjRFIHfn9wFAE0PkIZl4QDNQgkC2XSvg108LN3FPKOuUUF7HkWbOioNtUW0N8cAxZRFV5ykjCstnOCLsJzIfbFN2YMXmoLnZCPY=
Received: from TY2PR01MB3562.jpnprd01.prod.outlook.com (2603:1096:404:d5::14) by TYAPR01MB2605.jpnprd01.prod.outlook.com (2603:1096:404:88::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4020.18; Tue, 13 Apr 2021 03:06:18 +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.4020.022; Tue, 13 Apr 2021 03:06:18 +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: [Teas] A question about draft-ietf-teas-te-service-mapping-yang
Thread-Index: AdcsvdezyQQF/L3zSuGnrgrzYkyiGwAS6+sAAAGUQiAAC+BMAACLTjjgAAQxUAAAJO0G0A==
Date: Tue, 13 Apr 2021 03:06:17 +0000
Message-ID: <TY2PR01MB356236299E2F68FE0B55D73F904F9@TY2PR01MB3562.jpnprd01.prod.outlook.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> <0a8e01d72f7d$589ef970$09dcec50$@olddog.co.uk>
In-Reply-To: <0a8e01d72f7d$589ef970$09dcec50$@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.68]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 84d1eac1-3765-4e8c-1f8e-08d8fe291b73
x-ms-traffictypediagnostic: TYAPR01MB2605:
x-ld-processed: 040b5c43-0c27-49b3-b8e6-cdec886abcee,ExtFwd
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <TYAPR01MB2605A88431B3F12FB36C1D43904F9@TYAPR01MB2605.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: frskaqPGcF6A9fd4JeJI1jn+tGD1QAzYcBVH0n+JntSTxqIzWsnNv6PAqMsfz+5gdhMezQmY/ml2dFIId0Unckdmj1G5E4FTI2kHx+Qj9UYLMA2MEPRB/bce4+4ogbAJByZqWfOyTnYvWnhTL6imew8CaIOWiacBbNV/h829VrxhqVU9lTxqgfdDfUiB3UxNr1OZzsdEMgl0DIc3ki7J/F/Xppy7slQyqYlUIaETK/Fp/i6YLUh8mC+FQsE8CE9soFhSn4JlE/WCkH9Qn1p2QqFlHo6I6HNcKSMZx3dc46AyDT1Fcx9SOr2475e1qmnCdWRAadEftIWJXkY7WT9rIlo+IrJnbi6/gfev2eGzsAJj50xKp62jGnptxCjiHez5Ydi116HxwRzPPZW8yuQdja0z22NMamZL/wDbFKIUamGrK37STMngJC9xp1K84qhwIS2carTYQjpjCUYB/nYU1JLrFQO62UefY4q7pypbPO+ax5RH0z6KSrttX6xQkYPeaAS+hySzBhPXo1yRuV8uAIiB76ee1Y9mvVKMpdS7LhiI02GLmPzkzhg8YCX6tk0WECg7IZ3wdY4rJSjTCeI1xv5x3oEhiRKkO7+lSVPGxf2YnKjs5lNYdwy36QmNZeCQrxGMcmNM1iJs1lM0k2nXYBYnE1qPnQLpWsmipLEko9uanx7JuXysOE+ADEp1R9jQ
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:(346002)(136003)(366004)(39860400002)(396003)(376002)(9686003)(107886003)(26005)(5660300002)(85182001)(186003)(66556008)(54906003)(966005)(86362001)(66574015)(2906002)(7696005)(66446008)(4326008)(71200400001)(33656002)(83380400001)(66946007)(8936002)(8676002)(316002)(110136005)(66476007)(55016002)(6506007)(53546011)(64756008)(38100700002)(478600001)(52536014)(122000001)(76116006); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?MzR1OENVaEEzOEN6bGduT3dCMGpsS1UrNTNucDI5V1RVTGJhb0xnclU0WTll?= =?utf-8?B?aktCWnh0QmtuSUVQUnIvRHR1M28vaUEzU09NWmJEdnk1L3BTdlpoTGtHSytO?= =?utf-8?B?VFZzSkhydUdnUUZWeExYY080SUVtV2VuSnFleGJiM01aZ29wTFRSL3pYZWY4?= =?utf-8?B?U1BIYngxWUFUODF0QU5pUEIvNzdNM002akhwaG4xRzNRcVhUNzFrUzlud0lP?= =?utf-8?B?a3NLTUpORm1jUWFnRWtibmtzNmFUSmxjUjIvbzVmK0RLTXNDYUZNLzVRVWZV?= =?utf-8?B?RlNFSzRWSTFFeEJwL1U4Q0IwK1A1V0pmcnpBcTdCODEwL3c1RnR3Rm9lMkRr?= =?utf-8?B?cE9WRXlKbXdubkwrUzlEMDBGbS8wVzd3YmhJZzV6WnNFdmtjWkl2aWM2d3Zr?= =?utf-8?B?SkttRkQwMCtKclJUWmtiNWJJTlM5cU9MbXZJdmRiTmFDcFY5a0hTRkZ0ckZq?= =?utf-8?B?WGhsSHNiZ0M3eUQvVjZodWxGcGlhYnFlUUEwekpaaDVTS3VSQW1iM2FneFFz?= =?utf-8?B?VFIzZDYwamhVeThGVDJnREZDQlg2VU5RVHJsYm5GT0g0cXc3SWRXcHlMd2NG?= =?utf-8?B?N1RkUmE0S0ZkUUhsSTdjS3owd1NxY0xyWExFTEJzNnVqSFNId0d5cEp2dkpl?= =?utf-8?B?bUhObllNRlpya2ZHdEVEV2N5NW5NRlQ0cDdIR25lcGJrYzRYRys5MUpCYWpD?= =?utf-8?B?QkRiN2xGU2ZHbC92d1lBZGRxRUpyNHZKNFpzbS8waVl5YUtyOFVncGpvRTlx?= =?utf-8?B?bzFQTFMvNG95SEw5dG01WDM5aVZvUVhxb3JncDZoUDJneS9hNkNwZ1lYRnVP?= =?utf-8?B?Q1JsUVJzWlZUQ2dQYmErd0tGL0dHY2llcnc0anNnV3ZYZjBnc3VFUWtjbUpQ?= =?utf-8?B?ZWZEVlBtUHVUZ2xudVpiWjIwY0VTRmNxbUxsSTR1YmFvdHZjSk9va3Nxdity?= =?utf-8?B?bWt1YUdmb2NhTVVRN0JoOVljWllqYnNvZ2VxOTA3aVVwY0hraVdnUEdQdEs3?= =?utf-8?B?YURFOFBHcjZuWlNTMW04R05FbnlydlJkWDNGODVGcGk4cGtsR25EVEJoUkIz?= =?utf-8?B?Z1VYRC9xNWNJNTQxVWFRK3pwK0J4bDVWaHhidHJRcE1OaldvTU5OaktJck5x?= =?utf-8?B?bG9lY0d5TzUweU5FUUZSY1FLOTdoblhVcVBQUlJrM2RCTml6UEYwbzdLMk0x?= =?utf-8?B?VjkwL1d6QmFQaDNCcllzNjd5a3F1dW5iRUkybUw5dWxUSTMwMG4rR3hMNXYv?= =?utf-8?B?T2xaWUFpVWJlZGErZ3BMZHhEOVQ0Z3NWVG5vZ3Iwck9CSVZXUjRnenFUcUVW?= =?utf-8?B?Y1JyUlhYTnlZUlhxc3F5czdMdWxKa2xtam5CeklFNHp5YWZoZU9kK29NWnFz?= =?utf-8?B?SC9MUmRVYWxBR1ZvaURPOGdVNldveW1QWDRCd1FaT3Y4M0lnU1AvZDR6YWVv?= =?utf-8?B?SEtuT24ralkyYXdvMDZMVkFIU0sxb2xnWE1IYVFnejJEYkEwNm9DOFBJVGNx?= =?utf-8?B?VGVoUjdVbkEvNDcvRTJMNUhPeFMvZVRNbzQ3S3Iyd1Y3aWJoRlFMck5NRklE?= =?utf-8?B?TWJWNjkyQ0k4ZzMwTTdBS1VJbTBDU0xzSCtCR25BTlZXM2xvVHdlMG1lWUxq?= =?utf-8?B?VmlrcDBqY3ZNWDN1eW5PazdwdjBpVXZzOWwzajFpRGhSaUplclJVaTdZeE9t?= =?utf-8?B?OU8yR1FYZkU5SjdXUTlUOEZLRWs2eHI1dnVSREZaMU8zWFIyZ005TnkxOGlx?= =?utf-8?Q?d7c0GPE3uB0rYBqAnGloIJ2fhb3qt9N0PeZGMtF?=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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: 84d1eac1-3765-4e8c-1f8e-08d8fe291b73
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Apr 2021 03:06:17.8969 (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: e0kkg0Uo4QPEQY8ORRRtBFhjcf82XEv8s+BiLgejK7JWsMquO8UEweBwGyzbNarl//EdvSGWMpsKTil8CNkGUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2605
X-TM-AS-GCONF: 00
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nDT5qSftAAnx3YqVyjM7N0y3mcg>
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: Tue, 13 Apr 2021 03:16:47 -0000

Hi Adrian,

Thanks for your reply.

I added responses [KO2], inline.

Thanks,
Kenichi

-----Original Message-----
From: Adrian Farrel <adrian@olddog.co.uk> 
Sent: Monday, April 12, 2021 6:22 PM
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: [Teas] A question about draft-ietf-teas-te-service-mapping-yang

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

[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"


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.

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


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