Hi John, Thank you for the new version, taking into account the comments raised after the last IETF meeting. I have been through and it could be ready for WGLC.
However, if I may, I think the draft could be simplified a bit. As it is, the document is structured as a self-contained document whereas it might not be required. For instance, the section describing the 3GPP system and the mapping between 3GPP and IETF slice concepts is already covered in other documents referenced in the draft, as already indicated in the intro: Several network scenarios and mechanisms to map 3GPP and IETF network slices are found in [I-D.ietf-teas-5g-network-slice-application<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.html#I-D.ietf-teas-5g-network-slice-application>] and [I-D.ietf-teas-5g-ns-ip-mpls<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.html#I-D.ietf-teas-5g-ns-ip-mpls>]. This document defines another mechanism where the source UDP port number of a layer 3 GTP bearer (or UDP encapsulated GTP) is used to map to the TN slice at the Provider Edge (PE). 3GPP slice management ([TS.28.541-3GPP<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.html#TS.28.541-3GPP>]) and Attachment Circuit (AC) in [I-D.ietf-opsawg-teas-attachment-circuit<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.html#I-D.ietf-opsawg-teas-attachment-circuit>] provide the basis for the necessary mapping. Extensions to attachment circuit as a service to support a layer 3 GTP-U (or UDP encapsulated GTP) bearer as an attachment circuit is described in Section 2.4<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.html#SLICE-MAP> and Section 4<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.html#UDPTunnel>. Therefore, section 2.1, 2.2, 2.3 might not be needed. Having multiple descriptions might lead to confusion, wrong interpretation, etc. Removing them would simplify the reading to focus on the real purpose of the document, the technical body part beginning with the section 2.4. It is just a proposal. But it could be worth to look into this direction. Best Regards, Lionel From: Kaippallimalil John <john.kaippallima...@futurewei.com> Sent: vendredi 15 novembre 2024 16:49 To: Lionel Morand <lionel.mor...@huawei.com>; mohamed.boucad...@orange.com; d...@ietf.org Cc: t...@ietf.org; opsawg@ietf.org Subject: draft-ietf-dmm-tn-aware-mobility-14 Hi Med, Lionel, all, The draft is now updated to address all the review comments. Please have a look at the draft / diff to see the changes. Links from submission: Name: draft-ietf-dmm-tn-aware-mobility Revision: 14 Title: Mobility-aware Transport Network Slicing for 5G Date: 2024-11-15 Group: dmm Pages: 24 URL: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-dmm-tn-aware-mobility-14.txt&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C1d8993b8422d4d34695f08dd058cbde2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638672824234983450%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=t5%2FodCZmUVjYtyRdM0aY%2BiRHW9hRRUdsn6c2PTi07Nk%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-14.txt> Status: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware-mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C1d8993b8422d4d34695f08dd058cbde2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638672824235278658%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hCMK4pOt2BNEU%2B2s9YktQz3HtUd9BeX9Ze%2BL3XpqgLE%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/> HTMLized: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C1d8993b8422d4d34695f08dd058cbde2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638672824235306292%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wxFVjgZfET%2FafmecL%2FDPDO3x3fjeQl8XEASYnqCNylM%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility> Diff: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-14&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C1d8993b8422d4d34695f08dd058cbde2%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638672824235332772%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=wdJg3JkEi7wEojaYQ9IWTRsOY2leEwsNLAsDbBOCh9U%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-14> Best Regards, John From: Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>> Sent: Thursday, November 14, 2024 10:44 AM To: Lionel Morand <lionel.mor...@huawei.com<mailto:lionel.mor...@huawei.com>>; mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; d...@ietf.org<mailto:d...@ietf.org> Cc: t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: [Teas] Re: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi Lionel, Med, Will revise to point to RFC8085, 5.1.1 for UDP port and entropy. Lionel’s point about the L3 tunnel service type is a good one. The authors had discussed making the model general to allow GTPU and other UDP encapsulations (ESP-UDP, VXLAN, GENEVE or GRE) but was not done in earlier revisions. One approach is to revise the module name from “ietf-ac-gtpu” to “ietf-ac-udpt” The model itself would be pretty much the same, but text in the draft would now accommodate AC with GTPU and the other UDP encapsulations. Best Regards, John From: Lionel Morand <lionel.mor...@huawei.com<mailto:lionel.mor...@huawei.com>> Sent: Thursday, November 14, 2024 3:13 AM To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>>; d...@ietf.org<mailto:d...@ietf.org> Cc: t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: RE: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi Med, John, I agree that it would be safer to point to RFC8085, especially if this draft is now in the normative track (due to IANA assignment requirements). Now, coming back to the point 2 in my previous email (L3 Tunnel service type), the required AC is an IPsec tunnel between gNB and SEG and between SEGs in the core network side. And this draft specifies that the IPsec encapsulation with preservation of the UDP source port. Therefore, I would recommend not to mention “GTPU” in the YANG model name but something related to ESP-UDP (I don’t have any concrete proposal). GTP-U is only one example of protocols that would use this service. Regards, Lionel From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Sent: jeudi 14 novembre 2024 07:22 To: Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>>; Lionel Morand <lionel.mor...@huawei.com<mailto:lionel.mor...@huawei.com>>; d...@ietf.org<mailto:d...@ietf.org> Cc: t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: RE: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi John, all, As suggested in a previous review, I would drop the reference to I-D.xu-ipsecme-esp-in-udp-lb. You can consider pointing to https://datatracker.ietf.org/doc/html/rfc8085#section-5.1.1, instead. Cheers, Med De : Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>> Envoyé : mercredi 13 novembre 2024 22:19 À : Lionel Morand <lionel.mor...@huawei.com<mailto:lionel.mor...@huawei.com>>; Lionel Morand <lionel.morand=40huawei....@dmarc.ietf.org<mailto:lionel.morand=40huawei....@dmarc.ietf.org>>; BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>>; Sri Gundavelli (sgundave) <sgundave=40cisco....@dmarc.ietf.org<mailto:sgundave=40cisco....@dmarc.ietf.org>>; d...@ietf.org<mailto:d...@ietf.org> Cc : t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : [Teas] Re: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi Lionel, Med, Thank you for the review and comments. Re: comment 1/ : The text in the draft mixes 2 aspects: copying the UDP source port used for LB entropy (I-D.xu-ipsecme-esp-in-udp-lb) – and – copying the UDP source port for mapping to slice. Proposed resolution - reword the sentence in 2.4 with the following 2 sentences: “The IPSec secured GTP-U packet should be UDP encapsulated with the source port number copied from the GTP-U source port number for the PE to select the slice. When GTP-U packets use the source port number as an entropy field for load balancing, copying it to the outer UDP source port number would preserve this as intended for load balancing [I-D.xu-ipsecme-esp-in-udp-lb].” In 4.1 – reword to: “'l3-tunnel-service' in [I-D.ietf-opsawg-teas-attachment-circuit] is extended in this document to carry UDP source port number/range.” Re: comment 2/ Considering the text above, I-D.xu-ipsecme-esp-in-udp-lb does not need to be a normative reference (may be better this way since it is not yet an adopted draft ?) However, I’m open to suggestions from the group. Re: comment 3/ IANA considerations: It does seem like the module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844]. This was something I had missed bringing up during the dmm session, and thank you for that. Will revise to standards track. I will also implement the proposals from Med on adding the reference in 2.1, fixing the Figure 4, removing Figure 5, IANA point code additions, and security section updates. Best Regards, John . From: Lionel Morand <lionel.mor...@huawei.com<mailto:lionel.mor...@huawei.com>> Sent: Wednesday, November 13, 2024 12:39 PM To: Lionel Morand <lionel.morand=40huawei....@dmarc.ietf.org<mailto:lionel.morand=40huawei....@dmarc.ietf.org>>; mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>>; Sri Gundavelli (sgundave) <sgundave=40cisco....@dmarc.ietf.org<mailto:sgundave=40cisco....@dmarc.ietf.org>>; d...@ietf.org<mailto:d...@ietf.org> Cc: t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: RE: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi John, Med, I’m reviewing the draft and I have some questions for clarification. I’m really sorry if these questions have been already addressed. 1/ Dependency on I-D.xu-ipsecme-esp-in-udp-lb In section 2.4, it is said: --- [Mechanisms described in [I-D.xu-ipsecme-esp-in-udp-lb] may be used to encapsulate the ESP packet in UDP for better load balancing and this can also be used to preserve the UDP source port of GTP-U packet.] Where “may” implying that it a possible option to preserve the UDP source port. However, in section 4.1, it is said: --- [The overall tree structure of the AC service in [I-D.ietf-opsawg-teas-attachment-circuit] is extended to support attachment circuits that are encapsulated layer 3 such as GTP and GTPU in ESP-UDP encapsulation (IPSec (ESP) UDP encapsulation as in [I-D.xu-ipsecme-esp-in-udp-lb]).] Which indicates that the proposed extension does rely on implementation of the draft draft-xu-ipsecme-esp-in-udp-lb. If it is correct, I think that the draft should be referenced as normative and not informative. 2/ L3 tunnel service type If the support of draft-xu-ipsecme-esp-in-udp-lb is a prerequisite, I was wondering if the service provided by the AC is rather ESP in UDP encapsulation (with a specific semantic of the source UDP port and deactivation of loadbalancing) than GTP-U per se. I would maybe more accurate to focus on ESP in UDP encapsulation, even if the draft explains how it is used to handle GTP-U traffic. IMHO, it would remove the weird impression that an GTP-U based L3 tunnel service could be described using only a source UDP port. 3/ IANA considerations Because Med has commented that a new YANG module name has to be registered by IANA, I have checked and it said in RFC6020 that: --- [The module name prefix 'ietf-' is reserved for IETF stream documents [RFC4844]] Which would mean, if I’m correct, that the draft should be published as Standards-Track RFC (and not informational). Again, sorry if these points have been already addressed. Regards, Lionel From: Lionel Morand <lionel.morand=40huawei....@dmarc.ietf.org<mailto:lionel.morand=40huawei....@dmarc.ietf.org>> Sent: mercredi 13 novembre 2024 12:30 To: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>; Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>>; Sri Gundavelli (sgundave) <sgundave=40cisco....@dmarc.ietf.org<mailto:sgundave=40cisco....@dmarc.ietf.org>>; d...@ietf.org<mailto:d...@ietf.org> Cc: t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi Med, There is typo in the proposed change below: it is should be “extension” instead of “extenstion” 😊 OLD: | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref | +--rw (ietf-ac-gtpu)? NEW | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref | <--ietf-ac-gtpu extenstion--> From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Sent: mercredi 13 novembre 2024 07:51 To: Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>>; Sri Gundavelli (sgundave) <sgundave=40cisco....@dmarc.ietf.org<mailto:sgundave=40cisco....@dmarc.ietf.org>>; d...@ietf.org<mailto:d...@ietf.org> Cc: t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Subject: [DMM] Re: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi John, all, This version looks better. Please see below some quick comments: * I still think that a pointer to draft-ietf-teas-5g-ns-ip-mpls-13#name-5g-network-slicing-integrat would be helpful to add in your Section 2.1. I know that you already cite that doc, but that citation is specific to QoS mapping. * fix the formatting of Figure 4 * I would remove figure 5, but if you maintain it please (a) fix the indent of the first line and (b) also fix this part to indicate the location of your extension OLD: | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref | +--rw (ietf-ac-gtpu)? NEW | +--rw (l3-service)? | +--:(l3-tunnel-service) | +--rw l3-tunnel-service | +--rw type? identityref | <--ietf-ac-gtpu extenstion--> * Add a note to the RFC editor to replace “RFC SSSS” with the RFC number to be assigned to I-D.ietf-opsawg-teas-attachment-circuit * List I-D.ietf-opsawg-teas-attachment-circuit and RFC8519 as normative. I think that RFC9543 has to be cited as normative as well. * The IANA considerations should be updated as follows: OLD: This document has no requests for IANA code point allocations. NEW: IANA is requested to register the following URI in the "ns" subregistry within the "IETF XML Registry" [RFC3688]: URI: urn:ietf:params:xml:ns:yang:ietf-ac-gtpu Registrant Contact: The IESG. XML: N/A; the requested URI is an XML namespace. IANA is requested to register the following YANG module in the "YANG Module Names" subregistry [RFC6020] within the "YANG Parameters" registry. Name: ietf-ac-gtpu Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-ac-gtpu Prefix: ac-gtpu Reference: RFC XXXX * Update the security considerations to follow the template at https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc8407bis-20#name-security-considerations-sect Hope this helps. Cheers, Med De : Kaippallimalil John <john.kaippallima...@futurewei.com<mailto:john.kaippallima...@futurewei.com>> Envoyé : mardi 12 novembre 2024 22:26 À : Sri Gundavelli (sgundave) <sgundave=40cisco....@dmarc.ietf.org<mailto:sgundave=40cisco....@dmarc.ietf.org>>; d...@ietf.org<mailto:d...@ietf.org> Cc : t...@ietf.org<mailto:t...@ietf.org>; opsawg@ietf.org<mailto:opsawg@ietf.org> Objet : [OPSAWG]Re: draft-ietf-dmm-tn-aware-mobility-12 - Review request Hi all, For the dmm reviews, please use version 13 that we just posted. The revision was to align with the new revision of I-D.ietf-opsawg-teas-attachment-circuit that already provides the model for l3-service and l3-tunnel-service. This new version also has a complete Yang model for ietf-ac-gtpu that was generated and compiled for accuracy – Thanks, Med! Please see the revisions in Diff below, or sectios 4.1 and 4.2. Best Regards, John Links from the submission: A new version of Internet-Draft draft-ietf-dmm-tn-aware-mobility-13.txt has been successfully submitted by John Kaippallimalil and posted to the IETF repository. Name: draft-ietf-dmm-tn-aware-mobility Revision: 13 Title: Mobility-aware Transport Network Slicing for 5G Date: 2024-11-12 Group: dmm Pages: 23 URL: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-dmm-tn-aware-mobility-13.txt&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C76ae387a78d94165b4dd08dd035b0678%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638670411751507514%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=uN51leVcie%2BsvnVTD4u1oE1jUT23j9lKgnu%2FSOu4fjk%3D&reserved=0<https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-13.txt> Status: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware-mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C76ae387a78d94165b4dd08dd035b0678%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638670411751538820%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=oso3Ee01PHBPxc8ywUiug65E921iohcxLBLEEWCpng4%3D&reserved=0<https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/> HTMLized: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C76ae387a78d94165b4dd08dd035b0678%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638670411751561084%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=djsHs3lOyrSgdWlZVIzugh8a%2F%2BTmaOvY9hM55nNLbbQ%3D&reserved=0<https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility> Diff: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-13&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C76ae387a78d94165b4dd08dd035b0678%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638670411751581043%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=k1D0ngmXlOgN4X%2BzuHKOE7Y7bbR2jYCKymXIDEwje7Y%3D&reserved=0<https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-13> From: Sri Gundavelli (sgundave) <sgundave=40cisco....@dmarc.ietf.org<mailto:sgundave=40cisco....@dmarc.ietf.org>> Sent: Thursday, November 7, 2024 7:51 AM To: d...@ietf.org<mailto:d...@ietf.org> Subject: [DMM] draft-ietf-dmm-tn-aware-mobility-12 - Review request All: This document, draft-ietf-dmm-tn-aware-mobility, went through several revisions. Authors have presented the details on the latest changes. Please review and provide your feedback. If all the technical issues are resolved, we will issue LC. Sri Cisco Confidential ____________________________________________________________________________________________________________ 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. ____________________________________________________________________________________________________________ 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.
_______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
