[Teas] Re: Ketan Talaulikar's Discuss on draft-ietf-teas-5g-ns-ip-mpls-16: (with DISCUSS and COMMENT)

[[e-mail]]

Hi Ketan,

Thanks for the comments. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Ketan Talaulikar via Datatracker <[e-mail]>
> Envoyé : mercredi 2 avril 2025 17:45
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> Objet : Ketan Talaulikar's Discuss on draft-ietf-teas-5g-ns-ip-
> mpls-16: (with DISCUSS and COMMENT)
> 
> 
> Ketan Talaulikar has entered the following ballot position for
> draft-ietf-teas-5g-ns-ip-mpls-16: Discuss
> 
> When responding, please keep the subject line intact and reply to
> all email addresses included in the To and CC lines. (Feel free to
> cut this introductory paragraph, however.)
> 
> ------------------------------------------------------------------
> DISCUSS:
> ------------------------------------------------------------------
> 
> There are a couple of aspects in the document that I would like to
> discuss:
> 
> 
> 185	   provider networks.  The model uses (1) Layer 2 Virtual
> Private
> 186	   Network (L2VPN) [RFC4664] and/or Layer 3 Virtual Private
> Network
> 
> <discuss-1> Any reason by EVPN was not considered? There are a few
> other
> places where there is reference to L2VPN but not EVPN.

[Med] EVPN is covered indirectly by the following: 

   These protocols can be controlled, e.g., by tuning the protocol list
   under the "underlay-transport" data node defined in the L3VPN Network
   Model (L3NM) [RFC9182] and the L2VPN Network Model (L2NM) [RFC9291].

With RFC92191 

==
   The L2NM is scoped for a variety of Layer 2 Virtual Private Networks
   such as:

   *  Virtual Private LAN Service (VPLS) [RFC4761] [RFC4762]
   *  Virtual Private Wire Service (VPWS) (Section 3.1.1 of [RFC4664])
   *  Various flavors of EVPNs:
      -  VPWS EVPN [RFC8214],
      -  Provider Backbone Bridging Combined with Ethernet VPNs (PBB-
         EVPNs) [RFC7623],
      -  EVPN over MPLS [RFC7432], and
      -  EVPN over Virtual Extensible LAN (VXLAN) [RFC8365].
===

That's said, the document does not claim to be comprehensive and cite every tool that can be used for the realization. Please note that we do say the following in the introduction:

   The document is not
   intended to be a BCP and does not claim to specify mandatory
   mechanisms to realize network slices.  Rather, a key goal of the
   document is to provide pragmatic implementation approaches by
   leveraging existing readily-available, widely-deployed techniques.

> 
> 187	   (L3VPN) [RFC4364] service instances for logical
> separation, (2) fine-
> 188	   grained resource control at the Provider Edges (PEs), (3)
> coarse-
> 189	   grained resource control within the provider network, and
> (4)
> 190	   capacity planning/management.  More details are provided
> in Sections
> 191	   3.7, 5, 6, and 7.
> 
> 
> 1124	4.3.  MPLS Label Hand-off
> 
> <discuss-2> The document does cover both MPLS and IP/IPv6/SRv6 as
> two technology
> options in the TN in several places. However, I see that SRv6
> Hand-off is missing.
> I would like to discuss if there were any specific challenges in
> including that
> or if there was any other consideration for that exclusion?
> 

[Med] We actually picked few ones to exemplify the realization.


CURRENT:
   The following sections list few
   hand-off methods for slice mapping between customer sites and
   provider networks.

   More details about the mapping between 3GPP and RFC 9543 Network
   Slices is provided in [I-D.ietf-teas-5g-network-slice-application].

Readers can look at I-D.ietf-teas-5g-network-slice-application which includes a discussion on mapping based on SRv6

   6.  Methods for Mapping Between 3GPP E2E Network Slice and IETF
           Network Slice . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Mapping based on VLAN ID  . . . . . . . . . . . . . . . .  19
     6.2.  Mapping based on MPLS Label or SR-MPLS SID  . . . . . . .  20
     6.3.  Mapping based on SRv6 SID . . . . . . . . . . . . . . . .  21

The document is already dense. We need to find a balance ;-)


> 
> ------------------------------------------------------------------
> COMMENT:
> ------------------------------------------------------------------
> 
> Following are some comments provided in the idnits output for v16
> of the document:
> 
> 112	1.  Introduction
> 
> 114	   This document focuses on network slicing for 5G networks,
> covering
> 115	   the connectivity between Network Functions (NFs) across
> multiple
> 116	   domains such as edge clouds, data centers, and the Wide
> Area Network
> 117	   (WAN).  The document describes a Network Slice realization
> approach
> 118	   that fulfills 5G slicing requirements by using existing
> IP/MPLS
> 
> <major> By "existing", do you mean "available and widely deployed
> at the time
> of writing this document" ... or something like that? The term
> "existing" will
> not age well in an RFC.

[Med] Yes. We used to have similar constructs ("At the time of writing (2024)") but removed them in the WGLC.

> 
> 
> 182	   Unlike approaches that require new protocol extensions
> (e.g.,
> 183	   [I-D.ietf-teas-ns-ip-mpls]), the realization model
> described in this
> 184	   document uses a set of building blocks commonly used in
> service
> 
> <major> By "commonly" perhaps you imply ... commonly used in
> service provider
> networks at the time of writing of this document?

[Med] Yes. We don't use "time of writing" because we will be repeating it several times, which may be heavy and simply saying the obvious.

> 
> 185	   provider networks.
> 
> 193	   This realization model uses a single Network Resource
> Partition (NRP)
> 194	   (Section 7.1 of [RFC9543]).  The applicability to multiple
> NRPs is
> 195	   out of scope.
> 
> <major> The document does talk about QoS realization and carving
> out
> resources based on DSCP/EXP. Is the use of QoS classes mapped to
> NRPs
> precluded from to realize multiple (or rather a handful of) NRPs
> as specified in
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> www.ietf.org%2Farchive%2Fid%2Fdraft-ietf-teas-ns-ip-mpls-
> 05.html%23section-
> 4.1&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cfe334d8d025f45
> c6c50208dd71fd49e9%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63
> 8792054853640448%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsI
> lYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3
> D%7C0%7C%7C%7C&sdata=kKzpGU6MFrz0A3%2B7w8aASz071QDPxlXG2Hn2H10q%2B
> Dk%3D&reserved=0
> ?

[Med] No. Multiples QoS classes can be used for the realization of multiple NRPs assuming "other measures" are implemented. A QoC class is not an NRP.

> 
> 
> 197	   Although this document focuses on 5G, the realizations are
> not
> 198	   fundamentally constrained by the 5G use case.  The
> document is not
> 199	   intended to be a BCP and does not claim to specify
> mandatory
> 200	   mechanisms to realize network slices.  Rather, a key goal
> of the
> 201	   document is to provide pragmatic implementation approaches
> by
> 202	   leveraging existing readily-available, widely-deployed
> techniques.
> 
> <minor> ... at the time of writing of this document.

[Med] Idem as above.

> 
> 203	   The document is also intended to align the mobile and the
> IETF
> 204	   perspectives of slicing from a realization perspective.
> 
> 
> 2651	12.2.  Informative References
> 
> <major> There are many references below (e.g., for VPNs) that are
> required and
> necessary for the realization of the solution in this document. I
> would think
> that they would become normative? There are a lot of references
> and a closer
> relook would be helpful.
> 

[Med] These are provided as realization examples. Hence the current classification.

> 

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