[Teas] Re: OAM Considerations in draft-ietf-teas-5g-ns-ip-mpls [Re: [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls]

Greg Mirsky <gregimirsky@gmail.com> Wed, 05 June 2024 20:44 UTC

Return-Path: <gregimirsky@gmail.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 546CEC18DB93; Wed, 5 Jun 2024 13:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 (2048-bit key) header.d=gmail.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 U7KeV2FquCue; Wed, 5 Jun 2024 13:44:44 -0700 (PDT)
Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B2813C1840FD; Wed, 5 Jun 2024 13:44:44 -0700 (PDT)
Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-627eb38eb1bso1487657b3.1; Wed, 05 Jun 2024 13:44:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717620283; x=1718225083; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iiM9Xyf4sCNzCdareGEdYecaI2KdmKPjTfE/uob70gU=; b=ck6QiRnlGlqaX/H2mrN7MfSQytT0FqBuuaEMxb8J+NcFkrAB2/RtVhU3VnhFVmwRI0 WPkQS3NGngnfZnqC3sZWs2UhLhLOL5N1LPpM8snQQ68daFTQJeAb8NzIJVcULT46QBc+ eOpDd2+1mpcGZ0OsfCztEFSCqtd3pbWV8EnovpvYPOJ74ieaMcSIxBJtUl1AzbpMe1KZ R7GHOAxS2jQbli1zDaiCRdg59GnpKwZGr4mgGR9VnnrBqyopG1s6k/wMclpAzCyl88Rx 7bidPOua4xd2GIkIPNGJ3hxxD1Ybkeo6c8B2jm4talc/9lJwpEEDk2dtjV/rOkFaQUPp yopQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717620283; x=1718225083; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iiM9Xyf4sCNzCdareGEdYecaI2KdmKPjTfE/uob70gU=; b=O+/TZfs4/8T2fzZ4FoMtoJUvcnpSHYzK/9z0iCZzwPHWa7PbjIHIEVzu1y7+L2WsYf nYZI4ILn9ljJDdrt+PbYAs0xyvak62qCr29UndpcvrHp577FbjFBoYF53jAuZ9uqPjBw yq/7M/8T8L6VmoaQq9Ip6f5uyPxRzl/PLtiqbHu1SFRL/vmehfWjCcS3TilKWZO96xvA Mrvg7eyanuM03+RWb9N9/q32pCCISE9bKAMbyhT7rA5DwKpGL322DXDL5azzVQi5UuHy S0cmHgiqyQhBD57aFND7KgyYd18mgh5eWOqbyW1yVmpi9gBhlZXbDZ76x3ME7MW8iPfC 8QtA==
X-Forwarded-Encrypted: i=1; AJvYcCX7oLWdINObUGhSJuolcTFdS4slhmP13hkHxjUFSWJbLVx81VuYva2/CeYr/PqQpYV4L/wY1BCWC4woq7qcSzvzPqhqBG3L+ztwLNKLF631E7ELfUcjIOFSKv0+g39wXCsUuXvu7g==
X-Gm-Message-State: AOJu0Yyez3BLzWQliXLAhoKV6KGbNdgmXebASWEiIl9GwikuDp8KhOPw Trgt0K7Vz7BeYEdSKeScMQ/r9XG+kFizqKa7KILZBIM77+Wnh+pXhBCLXDXxyB7oLj+2/R1dEjh GF7mBXo2R+CIkYYmV3pljKejWwMLfog==
X-Google-Smtp-Source: AGHT+IGNmLOnmtiWVXgaSIUD6nLTNBY78Dfv7EFC/ah8epv+CtN/UQhgP3yghbUcNQJuyjvjhdiUtC4U4Fp/WjtroDg=
X-Received: by 2002:a81:ae21:0:b0:61a:e856:85f1 with SMTP id 00721157ae682-62cbb4d916cmr39086647b3.13.1717620283148; Wed, 05 Jun 2024 13:44:43 -0700 (PDT)
MIME-Version: 1.0
References: <0ac301da99b1$d7bc8b90$8735a2b0$@olddog.co.uk> <DU2PR02MB10160A2D5721B11043AB1FDA488E42@DU2PR02MB10160.eurprd02.prod.outlook.com> <75715215-BB21-435F-B046-9B1ACE84A3A4@juniper.net> <172301daa1f2$b69beac0$23d3c040$@olddog.co.uk> <DU2PR02MB10160150AAE536CDBB4BAE73D88E32@DU2PR02MB10160.eurprd02.prod.outlook.com> <CA+YzgTvViqQWUf+UE44L7FMqouLdaMn9-3k-ss2tqkBUf_tTcA@mail.gmail.com> <1edf01daa69a$d11b90b0$7352b210$@olddog.co.uk> <CH0PR02MB829175F67760F0FBAAA91700D6EC2@CH0PR02MB8291.namprd02.prod.outlook.com> <DU2PR02MB10160E11FBAD36E01EAA7D69388ED2@DU2PR02MB10160.eurprd02.prod.outlook.com> <DU2PR02MB10160598E6F883F2F44B8819388ED2@DU2PR02MB10160.eurprd02.prod.outlook.com> <048901dab14d$0c6bf210$2543d630$@olddog.co.uk> <DU2PR02MB101604441DA3034C20A0AB09188FD2@DU2PR02MB10160.eurprd02.prod.outlook.com> <CA+RyBmXGaRzGY8Nv0W6PuX9dxNFEOg_Wk+WNWZCB1pC3VtKe2w@mail.gmail.com> <DU2PR02MB10160CD9CCFB969F7039EF66F88F92@DU2PR02MB10160.eurprd02.prod.outlook.com>
In-Reply-To: <DU2PR02MB10160CD9CCFB969F7039EF66F88F92@DU2PR02MB10160.eurprd02.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 05 Jun 2024 13:44:32 -0700
Message-ID: <CA+RyBmWG=UTQvA8a6Dyv+H-O=toZQsc7sdBvN39quK8y1x-rGA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Content-Type: multipart/alternative; boundary="000000000000d6142f061a2aa21f"
Message-ID-Hash: VDPS4IMOCVG4V5HY77B5UE6Q3HAE4JDP
X-Message-ID-Hash: VDPS4IMOCVG4V5HY77B5UE6Q3HAE4JDP
X-MailFrom: gregimirsky@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-teas.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: TEAS WG Chairs <teas-chairs@ietf.org>, TEAS WG <teas@ietf.org>, "draft-ietf-teas-5g-ns-ip-mpls@ietf.org" <draft-ietf-teas-5g-ns-ip-mpls@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Re: OAM Considerations in draft-ietf-teas-5g-ns-ip-mpls [Re: [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls]
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/3owcWo0DnqWH3QWiEl5Ml6WS7xc>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Owner: <mailto:teas-owner@ietf.org>
List-Post: <mailto:teas@ietf.org>
List-Subscribe: <mailto:teas-join@ietf.org>
List-Unsubscribe: <mailto:teas-leave@ietf.org>

Hi Med,
thank you for the clarification and references.

Regards,
Greg

On Tue, Jun 4, 2024 at 11:05 PM <mohamed.boucadair@orange.com> wrote:

> Hi Greg,
>
>
>
> Thank you for the comments.
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Greg Mirsky <gregimirsky@gmail.com>
> *Envoyé :* mardi 4 juin 2024 21:51
> *À :* TEAS WG Chairs <teas-chairs@ietf.org>; TEAS WG <teas@ietf.org>;
> draft-ietf-teas-5g-ns-ip-mpls@ietf.org
> *Objet :* OAM Considerations in draft-ietf-teas-5g-ns-ip-mpls [Re: [Teas]
> Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls]
>
>
>
> Dear Authors,
>
> apologies for my belated questions. I appreciate that you've analyzed
> Network Slice OAM in Section 8. I have several questions and greatly
> appreciate your consideration:
>
>    - RFC7276 <https://www.rfc-editor.org/rfc/rfc7276> is 10 years old and
>    there are many things that have changed since it was published. In your
>    opinion, is the set of OAM tools developed for IP and MPLS networks
>    comprehensive for the task of operating and maintaining a Network Slice or
>    have you identified certain gaps that may be addressed in the future?
>
> *[Med] This draft leverages existing tools to implement the service (VPNs,
> class of services, customized paths, etc.). The intent is to leverage
> related OAM tools as well. The main missing item from 7276 is when some
> service chaining is used within the slice. For that one, we used to have
> this text till -05 but we removed it because we don’t provide realization
> SFC details:*
>
>       SFC OAM [RFC9451] should also be supported for slices that make
>
>       uses of service function chaining [RFC7665].  An example of SFC
>
>       OAM technique to Continuity Check, Connectivity Verification, or
>
>       tracing service functions is specified in [RFC9516].
>
>
>
> *There might be missing OAM tools if the realization required data/control
> plane extensions, but this is not the scope of this document*.
>
>    - I very much agree with
>
> Providers that deploy network slicing capabilities should be able to
> select whatever OAM technology or specific feature that would address their
> needs.
>
> And one of the tasks that OAM addresses is:
>
> assessing whether flow isolation characteristics are in conformance with
> the Network Slice Service requirements
>
> With that, Do you see how that task can be achieved with the OAM tools
> available today?
>
>
>
> *[Med] Isolation is used here as defined in
> https://datatracker.ietf.org/doc/html/rfc9543#name-isolation-in-ietf-network-sl.
> <https://datatracker.ietf.org/doc/html/rfc9543#name-isolation-in-ietf-network-sl.T>
> Operators who deploy VPN services have a variety of tools out there: Tools
> to check that the traffic of a given customer is placed in a specific
> VPN/transfer plane, only customer sites of the same customer can reach each
> other, tracing with marking, etc. RFC7276 points already to VPN OAM
> frameworks 4176 & 6136.*
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sat, Jun 1, 2024 at 2:09 AM <mohamed.boucadair@orange.com> wrote:
>
> Hi Adrian, all,
>
>
>
> ==
>
> [Med] Bingo, but it is unfortunate to see that readers may find that
> mention too late. Updated the intro to call that out early in the doc.
>
> [AF] Excellent, but still dangling is…
>
> ==
>
>
>
> Many change are made in -08 with this comment in mind. Also, merged some
> section and moved some details to other parts of the text, group
> scalability in one single place, etc.
>
>
>
> Aaah, also changed almost all the figures as idnits was not happy despite
> we were using unicode (900 warnings!!). Managed to have all these fixed but
> idnits still show two warnings, but we can’t change Éric and Rüdiger names
> :-)
>
>
>
> Your feedback on the content organization is appreciated. Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Adrian Farrel <adrian@olddog.co.uk>
> *Envoyé :* mercredi 29 mai 2024 00:19
> *À :* BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@orange.com>;
> 'BRUNGARD, DEBORAH A' <db3546@att.com>; 'Vishnu Pavan Beeram' <
> vishnupavan@gmail.com>
> *Cc :* 'Krzysztof Szarkowicz' <kszarkowicz@juniper.net>; 'TEAS WG' <
> teas@ietf.org>; 'TEAS WG Chairs' <teas-chairs@ietf.org>;
> draft-ietf-teas-5g-ns-ip-mpls@ietf.org
> *Objet :* RE: [Teas] Re: Late WGLC review of draft-ietf-teas-5g-ns-ip-mpls
>
>
>
>
>
> Hi Med,
>
>
>
> Sorry for the delay. Thanks for posting the updates.
>
>
>
> I looked at the diff between -05 (which I reviewed) and -07 (that you just
> posted).
>
>
>
> A lot of really good changes. Many thanks.
>
>
>
> I hope the colour coding works. Please shout if it doesn’t and I’ll do
> something else.
>
>
>
> Cheers,
>
> Adrian
>
>
>
> [Deborah] I agree with Adrian – it is not helpful for good SDO
> relationships to include in an IETF document (even as an appendix) a
> description of another SDO’s technology without requesting a review. While
> it may appear to be “process”, in the past, when another, unnamed, SDO made
> assumptions on an IETF technology, IETF was not happy. It became a very
> contentious technical argument. Recommend, either send a liaison (can be
> done in parallel with IESG review/request for publication) or remove (can
> enhance the current figures/terms if needed). While some have commented
> they found this Appendix helpful, I find it too detailed. With all the
> on-going architectural discussion in ORAN and 3GPP on these interfaces and
> components (and resulting presumptions on implementation), if want to keep,
> it should be scoped only to what is relevant to IETF.
>
>
>
> I don’t know how we’re going to resolve this. Obviously, Deborah and I are
> unconvinced about including the Appendix, certainly in its current form.
> The chairs have called “consensus” to include the appendix. I’m a little
> disappointed with that call as I didn’t see the arguments in favour except
> “We find it helpful.”
>
>
>
> [Deborah] Looking at the updated document on Adrian’s comments, I also
> find what Adrian commented as still not being clear in 3.3.3. To say in
> this document, that another TEAS working group document has shortcomings,
> is not a fair statement.
>
> [Med] That’s not the intent of the text. We only explain why we don’t
> mention PBR or relying on source port numbers for slice identification
> purposes. There is nothing against the app I-D.
>
> [Deborah] If don’t want to include the proposals of the other document,
> suggest simply delete this paragraph. The paragraph above already says this
> document lists a few (lists few/s/lists a few).
>
> [Med] Let’s try that and avoid spending more cycles on this.
>
>
>
> I’m happy with that solution.
>
>
>
> The document could really benefit from the addition of a section
>
> called "Scalability Considerations."
>
>
>
> draft-ietf-teas-nrp-scalability says...
>
>
>
> [snip]
>
> [Med] I hear the comment even if the NRP advice does not directly apply
> here. We added a new section about scalability implications and added new
> text to remind that we inherit scalability properties of current
> technologies. We added pointers for readers interested in such scalability
> assessment.
>
> [AF] Even your choice to have just one NRP is still an NRP, and thinking
> about scalability is important especially as the chosen approach does have
> some scaling limits. So thanks for the section.
>
> [Med] ACK.
>
>
>
> Your new section is nice. Thanks.
>
>
>
> 3.1
>
>
>
>   The term "Transport Network" is used for disambiguation with
>
>   5G network (e.g., IP, packet-based forwarding vs RAN and CN).
>
>   Consequently, the disambiguation applies to Transport Network
>
>   Slicing vs. 5G End-to-End Network Slicing (Section 3.2) as well the
>
>   management domains: RAN, CN, and TN domains.
>
>
>
> I thought I understood what was meant by TN in this document
>
> until I reached this paragraph. The previous text in 3.1 (and in
>
> the references) seems clear as to what a TN is. This text,
>
> however, confuses me and I can't extract anything useful from it.
>
> After all, haven't you just explained that:
>
>
>
>   Appendix B provides an overview of 5G network building blocks:
>
>   the Radio Access Network (RAN), Core Network (CN), and
>
>   Transport Network (TN).  The Transport Network is defined by
>
>  the 3GPP as the "part supporting connectivity within and between
>
>  CN and RAN parts" (Section 1 of [TS-28.530]).
>
>
>
> [Med] This is still under discussion among authors.
>
> [Med] With the updated Intro, we do think that this text is not needed
> anymore. So, deleted it.
>
>
>
> Yup. OK.
>
>
>
> Figure 5 finally makes it clear that you are trying to
>
> distinguish a "network slice" from a "TN slice".
>
>
>
> [Med] Bingo, but it is unfortunate to see that readers may find that
> mention too late. Updated the intro to call that out early in the doc.
>
> [AF] Excellent, but still dangling is…
>
>
>
> In practice, I think you are trying to say that the slices of the different
>
> domains may be combined to form an end-to-end slice in the
>
> IP/MPLS technology. This is certainly supported by 3.4.2 and is
>
> consistent with draft-li-teas-composite- network-slices, but you
>
> need to work out which way you are slicing (sic)
>
> this:
>
>
>
> [snip]
>
>
>
> [Med] I hope this is now better articulated with the changes.
>
>
>
> Yes, the new mini-paragraph just before Figure 6 is good.
>
>
>
> In 3.4.2 and with reference to Figure 5, it appears that your
>
> realisation is based on RFC 9543 Figure 1 Type 3. That's great,
>
> could you say so somewhere early in the document? It would help.
>
> [Med] Added a statement that the realization is based on types 3/4.
>
>
>
> Good.
>
>
>
> By the time we get to Figure 6, you are talking about "slice
>
> segments" and that is really helping because now we can
>
> consider stitching those segments together.
>
>
>
> [Med] Moved that figure to the introduction.
>
>
>
> Yeah, that is a good call. Makes the reader pay attention to the
> architecture.
>
>
>
> 3.4.2
>
>
>
>   In other words, the main
>
>   focus for the enforcement of end-to-end SLOs is managed at the
>
>   Network Slice between PE interfaces connected to the AC.
>
>
>
> Would that be more clearly stated with reference to the SDP?
>
> [Med] I think this is covered by the note about types 3/4.
>
>
>
> OK
>
>
>
> 3.5
>
>
>
> There seems to be a difference between the title of the
>
> section...
>
>      Mapping Schemes Between 5G Network Slices and Transport
>
>     Network Slices
>
> ...and the first line of text
>
>   There are multiple options for mapping 5G Network Slices to TN
>
>   slices:
>
> That is, the text talks about a unidirectional mapping (5G to TN)
>
> while the title says "between".
>
> [Med] Updated to “Mapping 5G Network Slices to Transport Network Slices”
> for consistency.
>
>
>
> So far, so good…
>
>
>
> But I think I object to the word "mapping".
>
> While, in one
>
> direction, the word is fine and clearly describes how one type of
>
> slice is projected onto another type of slice, the problem is
>
> more complicated because in the other direction (at the receiving
>
> end of the data flow) we need to "un-map".
>
> [Med] Why should we be concerned with that? Isn’t that part of the non-TN
> job?
>
>
>
> This depends on whether you are simply tunnelling (“map” means which 5G
> slices will be carried by which TN slice) or if you are aggregating (“map”
> means that a set of 5G slices “become” a TN slice). As you exit the TN
> slice, you need to go back to processing the individual 5G slices, and that
> is easy in the tunnelling case. But it is more complicated to demux when
> the mapping does not preserve the identity of the 5G slice.
>
>
>
> [snip]
>
>
>
> Section 4 is pretty clear and helpful. Thanks. I think it is
>
> where the real work of the draft begins (23 pages in). I wonder
>
> whether we can do something to get here more quickly.
>
> [AF] Seems like you’re not rising to this :-)
>
> I wonder whether the introduction can steal a few lines from this section
> to set the document up a bit better.
>
> [Med] Good suggestion. Moved some text around.
>
>
>
> Thanks. Good.
>
>
>
> In Section 6, have you invented the Filter Topology when you use
>
> the term "transport plane"? I think you have, and it would be
>
> helpful
>
> either:
>
> - to say "when we say transport plane, this is equivalent to the
>
>    term Filter Topology defined in RFC 9542"
>
> - to replace all mentions of "transport plane"
>
>
>
> I prefer the second of these.
>
> [Med] I'm not sure filtered topology is exactly identical to. I heard
> other comments that this is similar to NRP. We prefer to use a term that is
> close to what is currently used in deployments. For example, this is
> consistent with RFC9182 and several RFCs out there which include the
> following:
>
>
>
>   'underlay-transport':  Describes the preference for the transport
>
>      technology to carry the traffic of the VPN service.  This
>
>      preference is especially useful in networks with multiple domains
>
>      and Network-to-Network Interface (NNI) types.  The underlay
>
>      transport can be expressed as an abstract transport instance
>
>      (e.g., an identifier of a VPN+ instance, a virtual network
>
>      identifier, or a network slice name) or as an ordered list of the
>
>      actual protocols to be enabled in the network.
>
>
>
>      A rich set of protocol identifiers that can be used to refer to an
>
>      underlay transport are defined in [RFC9181].
>
> [AF] Two points here:
>
> 1.       If this sounds like NRPs, then you are acknowledging multiple
> NRPs, which is OK but is counter to your assertion that there is a single
> NRP in all aspects of this document.
>
> [Med] I wasn’t saying that I agree with that NRP comment.
>
> 2.       The quoted text from 9182 sounds exactly like filtered topology
> to me
>
> [Med] Still this can be done using the same topology. We updated the text
> with a new text to explain the notion of “transport plane”:
>
>
>
> NEW:
>
> A transport plane refers to a specific forwarding behavior between PEs in
> order to provide packet delivery that is consistent with the corresponding
> SLOs.
>
>
>
> Well, I don’t think we are converging :-(
>
> This is a document about IETF network slices, so it should link back to
> the terminology in RFC 9543. It doesn’t have to use that terminology, but
> it should link to it.
>
> So, keep all your text about “transport plane” if you like (noting that
> ITU-T people may find this a little confusing), but let’s still try to
> understand where this fits in the architecture and in this document.
>
> You have: “A network operator can define multiple transport planes.”
>
> So, does a transport plane map to:
>
>    - A TN slice
>    - An NRP
>    - A filtered topology
>
> Re-reading, I see that the transport plane could be a collection of
> tunnels. That certainly sounds like an NRP. It is partitioning the links
> that might be selected by a filtered topology, so it isn’t a filtered
> topology. But it is providing connectivity mechanisms that could be used by
> multiple TN slices, so it isn’t a TN slice. Hence, NRP.
>
> But the document is pretty adamant that “The realization model described
> in this document uses a single Network Resource Partition (NRP) (Section
> 7.1 of [RFC9543]).  The applicability to multiple NRPs is out of scope.” So
> why talk about multiple transport planes?
>
>
>
> [snip]
>
> ____________________________________________________________________________________________________________
>
> 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.
>
> _______________________________________________
> Teas mailing list -- teas@ietf.org
> To unsubscribe send an email to teas-leave@ietf.org
>
> ____________________________________________________________________________________________________________
> 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.
>
>