Re: [Teas] NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]

Joel Halpern <jmh.direct@joelhalpern.com> Wed, 28 September 2022 13:02 UTC

Return-Path: <jmh.direct@joelhalpern.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 2E7DFC15E6C4 for <teas@ietfa.amsl.com>; Wed, 28 Sep 2022 06:02:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5ts-gCtPnhS for <teas@ietfa.amsl.com>; Wed, 28 Sep 2022 06:02:33 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D58C15E6E1 for <teas@ietf.org>; Wed, 28 Sep 2022 06:00:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4McxSB24XKz6G7ft; Wed, 28 Sep 2022 06:00:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1664370042; bh=HSUby4Nt1Q1/roOPAg59P0wul4ckHFyRo/zwumpTEes=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=HSjB7LfJlkp8OKbUP2OdCpQBvnUP2aFDBstAeBiqOPKmIV+vNBPCFf67f3fw/ios3 qzQWtWsZaq6qQkwi3GM+Zl0M/UnZ62Gt8hv4Stv9rAS1oahuYiT5xmLRZ0yi2z6uOk fDgp0W1UwO59ZAiQSvAaPSDvUHTHCW/ZG7THxzxw=
X-Quarantine-ID: <4HDMpxCItulz>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.23.73] (unknown [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4McxS75T1cz6GdCd; Wed, 28 Sep 2022 06:00:39 -0700 (PDT)
Message-ID: <1ed620c5-dd98-d2d5-b8b5-cfcd0f5fbcd3@joelhalpern.com>
Date: Wed, 28 Sep 2022 09:00:37 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0
Content-Language: en-US
To: mohamed.boucadair@orange.com, "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Cc: TEAS WG <teas@ietf.org>
References: <165956437769.55050.16490105634807702976@ietfa.amsl.com> <184d1468-8fec-6425-05fc-f8fe41833985@joelhalpern.com> <CABNhwV0f37Y8WULLSq5COZyFyfg81OP_8JHRUaLGWEtUp10dLg@mail.gmail.com> <20d1ffc2-276a-90d8-d03f-a60b9bb2ab65@joelhalpern.com> <CA+YzgTsiFTbe=w6yX2BR9p8q31pgDnvn_3mhbPN9yEMCGwNtxw@mail.gmail.com> <BY3PR05MB8081ED2E8CCFCFE3EDCA2773C74F9@BY3PR05MB8081.namprd05.prod.outlook.com> <3ab8c72e-7813-05ff-6d3d-72fca5e7d252@joelhalpern.com> <BY3PR05MB80812E4C8381F24FEF9B43F4C74F9@BY3PR05MB8081.namprd05.prod.outlook.com> <0FE5FD9A-A52B-4046-A16A-BBC7D7EFE402@gmail.com> <452c2098-eaf0-337d-dd2d-53ae38ca8f5e@joelhalpern.com> <053301d8cea4$8763c250$962b46f0$@olddog.co.uk> <231f5c29-f91b-1048-17ca-3a29f0cdb8ad@joelhalpern.com> <20679_1664288628_63330774_20679_80_1_1ea712e55e964ea195f8127e7aa9ba02@orange.com> <352d41e1-6ca7-bbbf-7356-c272ef530fa4@joelhalpern.com> <17547_1664353401_63340479_17547_477_1_3d3b7eabcc22421ea560d048f59094d6@orange.com>
From: Joel Halpern <jmh.direct@joelhalpern.com>
In-Reply-To: <17547_1664353401_63340479_17547_477_1_3d3b7eabcc22421ea560d048f59094d6@orange.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/oNSUHkUsB9g4qlN23W7c14avr28>
Subject: Re: [Teas] NRP definition [Was: Repeated call for last call on draft-ietf-teas-ietf-network-slices]
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.39
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: Wed, 28 Sep 2022 13:02:37 -0000

I do not see the NRP in the configuration you provide.

One way of getting at what I am asking is to define, presumably for a 
range of technologies, what it means to configure an NRP. If it 
corresponds to a resource SID,  I understand that.  But that is not what 
the definition leads me to understand.

Yours,

Joel

On 9/28/2022 4:23 AM, mohamed.boucadair@orange.com wrote:
> Hi Joel,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Joel Halpern <jmh@joelhalpern.com>
>> Envoyé : mardi 27 septembre 2022 17:26
>> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
>> adrian@olddog.co.uk
>> Cc : TEAS WG <teas@ietf.org>
>> Objet : Re: [Teas] NRP definition [Was: Repeated call for last
>> call on draft-ietf-teas-ietf-network-slices]
>>
>> If the NRP concept does not map to how packets are treated, and
>> does not map to some other configuration in the IETF network slice
>> controller / entry / support, then what difference does it make?
>>
> [Med] If NRPs are used, then the NSC maintains a mapping between a slice service and an NRP. Classification/steering policies will also need to be provisioned on ingresses to make sure the  appropriate NRP-related resources are invoked. A concrete example is, when we use L3NM (RFC9182) or L2NM (RFC9291) to implement slices, the NSC can bind a VPN with an NRP by setting the following parameter in the LxNM:
>
>                +--rw underlay-transport
>                |  +-- (type)?
>                |     +--:(abstract)
>                |     |  +--rw transport-instance-id?   string
>                |     |  +--rw instance-type?           identityref
>                |     +--:(protocol)
>                |        +--rw protocol*                identityref
>
>
>           +------------------------------------------+
>           |                 Customer                 |
>           |                                          |
>           +------------------------------------------+
>                                A
>                                | IETF Network Slice service interface
>                                V
>           +------------------------------------------+
>           |        Network Slice Controller (NSC)    |
>           +------------------------------------------+
>                                A
>                       L3NM     | Network Configuration Interface
>                      NRP Model V
>           +------------------------------------------+
>           |           Network Controller(s)          |
>           +------------------------------------------+
>                                A
>                                |    Device model
>                                V
>        +------------------------------------------------+
>                              Network
>
> Of course, the use of NRPs is not mandatory to offer slice services. Relying upon such yet-another abstraction is deployment-specific. For example, manipulating customized sets of resources from the underly network (i.e., NRPs) might be a useful in networks to reason about slice aggregates.
>
>
>> As oine person put it, they thought that NRP corresponded to the
>> proposal for Resource SIDs.  If it is a vague concept unrealted to
>> behavior, then I don't know what it is.  And the current text in
>> the framework does not lead me to understand it.  Whatever we end
>> up with, please, let's clean up the definition.
> [Med] Sure. It would be helpful if you can provide text from draft-ietf-teas-ietf-network-slices which you think is confusing so that it can be fixed.
>
> For example, I would not be against simplifying Section 6.1 among these lines:
> * Change the title from "Architecture to Realize IETF Network Slices" to "An Architecture to Realize IETF Network Slices" to further insist this is just an example, not a recommended arch.
> * Avoid introducing new terms when not justified. For example, I would avoid having the "Filtered Topology" concept as this is redundant with NRPs.
> * Reorder the text to first introduce NRPs, and then focus on the customized topology as an approach to build NRPs.
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>