[Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)

Krzysztof Szarkowicz <kszarkowicz@gmail.com> Fri, 20 September 2024 13:42 UTC

Return-Path: <kszarkowicz@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 DD062C151094; Fri, 20 Sep 2024 06:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Level:
X-Spam-Status: No, score=-2.104 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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 (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 x47S_VBj-6GH; Fri, 20 Sep 2024 06:42:16 -0700 (PDT)
Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536D8C151084; Fri, 20 Sep 2024 06:42:16 -0700 (PDT)
Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-7178df70f28so1554754b3a.2; Fri, 20 Sep 2024 06:42:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726839736; x=1727444536; darn=ietf.org; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=r0QJTiccKL0/4O1WQyU8hyCEBPHzJE1Urs1KMlNDDbc=; b=J+O0dLv07rI1d7x241gh6mKqoZeRuWNZiYOE4RU5caUZ4CV2ehgfs9NpNBoYmSF6Un Uhq1T+M2ZX72+jqoJEyyoXrQlL7yrQD445VX9vYYw4KpqwaR9rvQaDSTdR4QqaCwTfTw UFqsbIjhv0huxfdgcrml8vzdM+LKlgFyzfI5zJ6dT0+GTWWVVSBtfvH4rf/i2ibvL+nz 2aSS3Zf7DUGp12WZdL7Rqo4mEx60mJ0FAgJURYwyGD4mI7AUQgdp86sEyuTC3Zu1UjIc V02aVbUqjpH4Dijcagyn/uLLHEEFhZikdGuf/va+6zfMrH9T6HNxi43dRIBPRDlL92JN b/7g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726839736; x=1727444536; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=r0QJTiccKL0/4O1WQyU8hyCEBPHzJE1Urs1KMlNDDbc=; b=j/m1w+GO5NgEk6eeGG6k4UYI1Tlcl/KHj5rcuHTcWMzO8QfuEKRCBdNGOuJTOWt7oI 2ZcMTptTKGOq3aP4Vmt+sQWQtqm0ZibzQEQ1nB8alAqeNMlTfr2Ekq52p7/Qzx9Yel3A v/wO7+JwiQxSBhsxlFfnMwBGLIqJBN1c3Eu/fR0RgEQbbkjyE7tphjtz6rPoC7innJcd bFW9maqCWXeRLjyBaMGongBKk6fnLAGmr8ZPyj/2oiYGHXiJH7oDsx7fiJS6m+UYqZ4q PpG6drv7Em56+ONiOYiiQvQYOoKcXeuq6WjdQzK/7CtvCIPStO/akE5JPR8KGj1UrRBm Lc8Q==
X-Forwarded-Encrypted: i=1; AJvYcCVdHOiEjNtfW7Ksh4tGSWthsFNgUgEJLzAIjKzWnmEWasW+ihv0ddJEqnqkb/IAjx4/4qNy4g==@ietf.org, AJvYcCWj8AHsBSC8aIa6l1WGL7Qc+xyOC+Fyr+pGH4y8Xwu0N0HijsvrduXSRHa2EuJETYf3gRL+kDYjSDoP+w==@ietf.org
X-Gm-Message-State: AOJu0YzY6NkT5gRV217P+P8v0+1uO3zcuxLzcQLBVtMP3t2Qg53yMYqO 6Lf6x5pSyd5hQFvyndxsl4+geskHFQK009hgJn0RGOP5viKfUtFZwcrHNfcB
X-Google-Smtp-Source: AGHT+IFxadzWZQc/zue01htB0CGXb59ZsvZCQDm9P8CmYeleHRJ+S30NtgglrTqAQawP/Z8qAM0/Cw==
X-Received: by 2002:a05:6a21:168d:b0:1ce:f77a:67bf with SMTP id adf61e73a8af0-1d30aa3c1f4mr4586351637.49.1726839735362; Fri, 20 Sep 2024 06:42:15 -0700 (PDT)
Received: from smtpclient.apple (jpams-nat11.juniper.net. [193.110.49.11]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71944ab49d4sm9823535b3a.45.2024.09.20.06.42.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Sep 2024 06:42:14 -0700 (PDT)
From: Krzysztof Szarkowicz <kszarkowicz@gmail.com>
Message-Id: <FBE57281-2748-4B57-A519-657CC9BEB2FE@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9514928A-56F5-4111-AC23-E5B11A28401E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Date: Fri, 20 Sep 2024 15:42:00 +0200
In-Reply-To: <19d31c2b1128439594dc6bbacbf2ee5b@huawei.com>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>
References: <CA+YzgTuwRDSxfy7rHR21A3LqAmRcQtcFZWo1KD6KQZaEFMcODQ@mail.gmail.com> <d27ef01a787a42a9945b818124728c2c@huawei.com> <4E60C28E-D0D2-424B-A49F-D22CD2F0760C@gmail.com> <19d31c2b1128439594dc6bbacbf2ee5b@huawei.com>
X-Mailer: Apple Mail (2.3776.700.51.11.1)
Message-ID-Hash: 4EHPFLPG7SXIWXOBHYSGLIRQVVM7ZY6N
X-Message-ID-Hash: 4EHPFLPG7SXIWXOBHYSGLIRQVVM7ZY6N
X-MailFrom: kszarkowicz@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: "EXT-vishnupavan@gmail.com" <vishnupavan@gmail.com>, TEAS WG <teas@ietf.org>, TEAS WG Chairs <teas-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Teas] Re: 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/y9i_RvWaDnNPtvx34SkNAC1EI9s>
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 Jie,

Thank your for your feedback. 

Please see my comments inline.

Best regards,
Krzysztof


> On Sep 14, 2024, at 04:14, Dongjie (Jimmy) <jie.dong@huawei.com> wrote:
> 
> Hi Krzysztof,
>  
> Thanks for the feedback and sorry for the late reply. I’ve read the diff of -09 and -10,  which looks good in general.
>  
> Please find some further replies inline:
>  
> Best regards,
> Jie
>  
> From: Krzysztof Szarkowicz [mailto:kszarkowicz@gmail.com]
> Sent: Friday, September 6, 2024 11:53 PM
> To: Dongjie (Jimmy) <jie.dong@huawei.com <mailto:jie.dong@huawei.com>>
> Cc: EXT-vishnupavan@gmail.com <mailto:EXT-vishnupavan@gmail.com> <vishnupavan@gmail.com <mailto:vishnupavan@gmail.com>>; TEAS WG <teas@ietf.org <mailto:teas@ietf.org>>; TEAS WG Chairs <teas-chairs@ietf.org <mailto:teas-chairs@ietf.org>>
> Subject: Re: [Teas] 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)
>  
> Dear Jie,
>  
> Please see my comments below.
>  
>  
> Best regards,
> Krzysztof
>  
> 
> 
> On Aug 28, 2024, at 11:21, Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org <mailto:jie.dong=40huawei.com@dmarc.ietf.org>> wrote:
>  
> Dear authors and WG,
>  
> Thanks for the efforts in updating the document. I’ve read the diffs between -04 and -09, and please find below a few comments to the changes.
>  
> The line numbers generated by the idnits are used.
>  
>  
> 133        technologies.  Specifically, this document explains how RFC 9543
> 134        Network Slices are realized within provider networks and how such
> 135        slices are stitched to Transport Network resources in a customer site
> 136        in the context of Transport Network Slices (Figure 1).
>  
> [Jie] Suggest to change this to: this document explains one approach of realizing RFC 9543 Network Slices within provider networks…
>  
> [Krzysztof] Ack. We will update the text in the next revision.
>  
> [Jie]Thanks for the update.
>  
> 
> 177        3, or Layer 4).  The realization of the mapping between customer
> 178        sites and provider networks is refered to as the "hand-off".
> 179        Section 4 lists a set of such hand-off methods.
>  
> [Jie] From the context it seems the mapping refers to the mapping between 5G network slices and network slices in TN domain. But the text here just says mapping is between customer sites and provider networks. It is suggested to clarify the scope of the mapping is for network slices.
>  
> As for the term “hand-off”, it seems it is used in the wireless world for something else. If this draft wants to use this term for the network slice mapping mechanism, I’d suggest to make it clear that it is “network slice hand-off in data plane”.
>  
> And it is suggested this section also refer to draft-ietf-teas-5g-network-slice-application for the methods of network slice mapping/hand-off in data plane. 
>  
> [Krzysztof] Not sure, how you come to the conclusion that the context indicates that mapping is between 5G network slices and network slices in the TN domain. We clearly described in the text, that it is between customer sites and provider networks, so scope is already clearly specified.
>  
> [Jie] The sentence right before the one I quoted says:
>  
>       “5G domains can expose the 5G slices to the transport domain by mapping to explicit data plane identifiers (e.g., Layer 2, Layer 3, or Layer 4). ” Also the previous paragraph talks about mapping between 3GPP and IETF network slice services.
>  
> This indicates the text following that sentence continues talking about the mapping between 5G slices to TN network slices. It is OK to mention the mapping is between customer sites and provider networks, while it is better to mention it is about “network slice mapping”.
>  

[Krzysztof2]  OK. We explicitly mention, that the hand-off term is used for mapping between customer sites and provider network, to avoid any confusion.


> [Krzysztof] “hand-off” is very generic term, used in many contexts. We clarified the term “hand-off” in the context of this draft, and using it in the similar manner as term “hand-off/handoff” in the draft-ietf-teas-5g-network-slice-application, for consistency between two drafts.
>  
> [Jie] This term is introduced by this document, and draft-ietf-teas-5g-network-slice-application uses it just for consistency with this document. It is fine if you think it has been clarified in this context. 

[Krzysztof2] Ack.

>  
>  
> [Krzysztof] In the context of mapping, this section already references draft-ietf-teas-5g-network-slice-application (one paragraph earlier). 
>  
> [Jie] It is OK as long as both paragraphs talk about network slice mapping. Then my comment above applies.

[Krzysztof2] Ack.

> 
>  
>  
> 186        resource control at the Provider Edges (PEs), (3) coarse-grained
> 187        resource control at within the provider network, 
>  
> [Jie] s/at within/within
>  
>  
> [Krzysztof] Ack. We will update the text in the next revision.
> 
> 
>  
> 432        While in most cases CEs connect to PEs using IP (e.g., VLANs
> 433        subinterface on a Layer 3 interface), a CE may also connect to the
>  
> [Jie] s/VLANs subinterface on a Layer 3 interface/via layer-3 VLAN subinterfaces
>  
> [Krzysztof] Ack. We will update the text in the next revision.
> 
> 
>  
>  
> 573        A TN slice might be considered as a variant of horizontal composition
> 574        of Network Slices mentioned in Appendix A.6 of [RFC9543].
>  
> [Jie] For composition of network slices, it is suggested to also add a reference to draft-li-teas-composite-network-slices.
>  
> [Krzysztof] We reference RFC 9543 for slice composition. We don’t see as necessary to reference individual drafts at this point of time.
>  
> [Jie] The reference would be informative and there is no limit on the document status.
>  
> That said, it is just a suggestion and is on the authors’ discretion.

[Krzysztof2] Ack.

> 
> 
>  
> 782     3.6.  First 5G Slice versus Subsequent Slices
>  
> 784        An operational 5G Network Slice incorporates both 5G control plane
> 785        and user plane capabilities.  For instance, consider a slice based on
> 786        split-CU in the RAN, both CU-UP and Centralized Unit Control Plane
> 787        (CU-CP) need to be deployed along with the associated interfaces E1,
> 788        F1-c, F1-u, N2, and N3 which are conveyed in the TN.  In this regard,
> 789        the creation of the "first slice" can be subject to a specific logic
> 790        that does not apply to subsequent slices.
>  
> [Jie] Section 3.6 assumes that the deployment of the first 5G slice is different from the deployment of subsequent slices. This may be true for the example in Figure 10, where the control plane for different 5G slices are shared. While it is possible the control plane of different 5G slices need to be separated, then the deployment of TN slices would be different from the description in this section.
>  
> It is suggested to clarify the presumption of shared slice for control plane in the beginning of section 3.6.
>  
> [Krzysztof] Section 3.6 describes very common model, where CP is shared between slices (so, 2nd slice shares the CP with 2st slice), as an example (“For instance”). At the same time, there are no presumptions. Depending on the operational guidelines, operator might deploy slices with shared CP, or slices with separate CPs. Or, could have some mixture of slices with shared CPs, and slices with separate CPs.
>  
> [Jie] Agree it may be a common model in some deployments , but AFAIK it is not the default procedure for creating 5G slices. There is some presumption about specific deployment model, which IMO needs to be made clear either in the title or in the beginning of this subsection.
>  
> Specifically, for the text “the creation of the "first slice" can be subject to a specific logic that does not apply to subsequent slices”, is there anything in 3GPP which could be referenced? 

[Krzysztof2] We have reworked the text in this section as follows (will be published with the next draft version). To make clear, it is just example (which might be common is some deployments), and to make clear it is not default or standard procedure.

An operational 5G Network Slice incorporates both 5G control plane and user plane capabilities.
For instance, in some deployments, in the case of a slice based on split-CU in the RAN, both CU-UP and Centralized Unit Control Plane (CU-CP) may need to be deployed along with the associated interfaces E1, F1-c, F1-u, N2, and N3 which are conveyed in the TN. In this regard, the creation of the "first slice" can be subject to a specific logic that does not apply to subsequent slices. Let us consider the example depicted in {{figure-7}} to illustrate this deployment. In this example, the first 5G slice relies on the deployment of NF-CP and NF-UP functions together with two TN slices for control and user planes (INS-CP and INS-UP1). Next, in many cases, the deployment of a second slice relies solely on the instantiation of a UPF (NF-UP2) together with a dedicated user plane TN slice (INS-UP2). In this example, the control plane of the first 5G slice is also updated to integrate the second slice: the TN slice (INS-CP) and Network Functions (NF-CP) are shared. The model described here in which the control plane is shared among multiple slices is likely to be common, it is not mandatory. Deployment models with a separate control plane for each slice are also possible.

>  
>  
>  
> 790        that does not apply to subsequent slices.  Let us consider the
> 791        example depicted in Figure 10 to illustrate this deploloyment.  In
>  
> [Jie]  s/deploloyment/deployment
>  
> [Krzysztof] Ack. We will update the text in the next revision.
>  
>  
>  
> 918           methods used here can range from careful network planning, to
> 919           ensure a more or less equal traffic distribution (i.e., equal cost
> 920           load balancing), to advanced TE techniques, with or without
> 921           bandwidth reservations, to force more consistent load distribution
> 922           even in non-ECMP friendly network topologies. 
>  
> [Jie] Section 3.7 mentions that coarse-grained resource control with up to 8 traffic classes is used at the transit links in the provider network. Then in capacity planning/management, it mentions “advanced TE techniques, with or without bandwidth reservation”. It is not very clear whether bandwidth reservation is at coarse granularity (up to 8 traffic classes), or it can be done at finer granularity (e.g. per path)? If it is the latter, does it conflict with “coarse-grained resource control”?
>  
> [Krzysztof] We are not perspective, and not dictating any concrete granularity of bandwidth reservation. Typical deployments today use non-coarse, per path (not per traffic class) BW reservation. Some time ago, Diff-Serv Aware Traffic Engineering BW reservation modes (RFC 4128) were standardized by IETF. These model could be in prinicple used here as well. Saying that, these models didn’t gain much attention among operators (real production network deployments), comparing to simple per-path BW reservation model.
>  
> [Jie] Thanks for the clarification. So you confirmed that per-path BW reservation would be used for the approach described in this document.
>  
> Then my question still applies: does per-path BW reservation conflict with the “coarse-grained resource control” model as mentioned in the introduction?

[Krzysztof2] The most typical deployments of traffic engineering have BW reservations at the per-path level, without regard to QoS classes. QoS could be coarse or fin in these TE deployment models. So, there is no conflict. 
>  
>  
> 1097    4.2.1.  An Example of Local IPv6 Addressing Plan for Network Functions
>  
> [Jie] I appreciate the update in the text which explains the example of embedding S-NSSAI into IPv6 address. While since it is about the IPv6 addressing of the 5G NFs, which is out of the scope of the TN network, and IMO not the focus of this document. It is suggested to either move this section to the appendix or remove it from this document.
>  
> [Krzysztof] IP addressing and IP allocation scheme is an important aspect of TN network. One allocation scheme is provided as an example in section 4.2.1.
>  
> [Jie] It may depend on the operation model, for some operators the planning and allocation of IP addresses to mobile network functions is the duty of the mobile team. 

[Krzysztof2] Ack. The context of this subsection is the IP address used as identifier during hand-off mechanism towards provider network. In such case, regardless which group allocates the IP addresses (i.e. mobile or transport group) there must be an agreement. Otherwise, provider network might cannot properly map received IP packets to appropriate slices. And, here one method is such agreement is presented as an example. It doesn’t preclude, that there could be other methods.

>  
>  
> 2049    6.  PEs Underlay Transport Mapping Models
>  
> 2058       It is worth noting that TN QoS Classes and underlay transport are
> 2059       orthogonal.  
>  
> 2091       Similar to the QoS mapping models discussed in Section 5, for mapping
> 2092       to underlay transports at the ingress PE, both 5QI-unaware and 5QI-
> 2093       aware models are defined. 
>  
> [Jie] Does it mean the underlay transport can be aware of 5QI, while is orthogonal to TN QoS Classes? Then how are the QoS mapping models combined with the underlay transport mapping model? For example, can the 5QI-unaware QoS model be combined with the 5QI-aware underlay transport mapping model?  Or they always need to be consistent on 5QI-aware or unawareness?
>  
> [Krzysztof] We will slightly update the first sentence: “It is worth noting that TN QoS Classes and underlay transport are each related to different engineering objectives”. And, since they are independent and addressing different engineering objectives, then yes, the 5QI-unaware QoS model can be combined with the 5QI-aware underlay transport mapping model, as described in subsections of Section 5 and Section 6.
>  
> [Jie] Thanks for the clarification. I’m fine with the updated sentence. Basically any combination between the QoS model and the underlay transport mapping model is allowed, is that correct?

[Krzysztof2] Yes, that is correct.

>  
>  
> 2404    7.2.2.  Scheme 2: TE Paths with Fixed Bandwidth Reservations
>  
> 2410       slice.  Note that the "reservations" would be in the mind of the
> 2411       transport controller - it is not necessary (or indeed possible for
> 2412       SR-TE) to reserve bandwidth at the network layer.
>  
> [Jie] With some mechanisms resource reservation can also be done on the network devices. If section 7.2.2 only talks about bandwidth reservation in the mind of the controller, it is suggested to make this explicit in the title of this section.
>  
> As for segment routing with resource reservation at the network layer, this document may consider to add a reference to draft-ietf-spring-resource-aware-segments.
>  
>  
> [Krzysztof] Good catch! We will adjust the text in this section to “allow" reservations in the controller or the network devices. 
>  
> [Jie] OK.
>  
> [Krzysztof] As the draft title says, this draft focuses on “current IP/MPLS Technologies”, with broad deployment status, therefore we don’t see the possibility to reference draft-ietf-spring-resource-aware-segments, which is new, emerging technology.
>  
> [Jie] That’s fine if the authors consider resource-aware segments as new technology. Then I’d suggest to make some changes to the text below:
>  
> OLD:  it is not necessary (or indeed possible for SR-TE) to reserve bandwidth at the network layer
>  
> NEW: it is not necessary (or indeed possible for current SR-TE technology) to reserve bandwidth at the network layer

[Krzysztof2] Ack, we will make changes in the next draft revision.

>  
>  
>  
> Best regards,
> Jie
>  
>  
> From: Vishnu Pavan Beeram [mailto:vishnupavan@gmail.com] 
> Sent: Thursday, August 22, 2024 2:28 AM
> To: TEAS WG <teas@ietf.org <mailto:teas@ietf.org>>
> Cc: TEAS WG Chairs <teas-chairs@ietf.org <mailto:teas-chairs@ietf.org>>
> Subject: [Teas] 2nd WG Last Call: draft-ietf-teas-5g-ns-ip-mpls-09 (*one* week)
>  
> All,
>  
> This starts the 2nd working group last call on
> https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/
>  <https://datatracker.ietf.org/doc/draft-ietf-teas-5g-ns-ip-mpls/>
>  
> Please note that the previous last call was for version 4 of the document and several changes have been made to the document since then. The changes have been discussed on the list and a summary presented during the WG session in IETF 120.
>  
> As this is a 2nd last call that is primarily focused on changes since the previous last call, it closes in *one" week. The working group last call ends on August 28th, 2024. Please send your comments to the working group mailing list.
>  
> A diff (v4-v9) can be found at:
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-teas-5g-ns-ip-mpls-04&url2=draft-ietf-teas-5g-ns-ip-mpls-09&difftype=--html
>  
> Thank you,
> Pavan and Oscar
> ps: The following comment from Greg will be considered as part of this 2nd LC -
> https://mailarchive.ietf.org/arch/msg/teas/Pr7hvoB_RS9ZgGIRGEdCf2rn4bE/
> _______________________________________________
> Teas mailing list -- teas@ietf.org <mailto:teas@ietf.org>
> To unsubscribe send an email to teas-leave@ietf.org <mailto:teas-leave@ietf.org>
>