[Teas] Re: [DMM] I-D Action: draft-ietf-dmm-tn-aware-mobility-11.txt

[[e-mail]]

Hi John,

As this is about a service model, the intent should be explicit enough so that the resulting tunnel provisioning at both sides of an AC is deterministic. The tunnel indicated in "type" should be unambiguous.

I would suggest you define two identities to cover GTP-U and ESP-in-UDP. Then, do a check "type=gtp or esp-in-udp" when adding the udp port numbers data nodes.

Cheers,
Med

De : Kaippallimalil John <[e-mail]>
Envoyé : mardi 15 octobre 2024 18:35
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>; [e-mail]; TEAS WG ([e-mail]) <[e-mail]>
Objet : RE: [DMM] I-D Action: draft-ietf-dmm-tn-aware-mobility-11.txt

Hi Med,

Thank you for the detailed review and suggestions.
We'll implement the changes based on the comments and proposed revisions.

One aspect on the l3-tunnel-service perhaps needs a bit more consideration.
In some cases, the operator may secure GTP-U with IPsec across SEG (Security gateways) and in this case the draft has proposed a UDP encapsulation of ESP (I-D.xu-ipsecme-esp-in-udp-lb).
So the draft needs to consider UDP source port for both GTP-U and the UDP encapsulated ESP/IPsec.
In the proposed structure revision below, would it be reasonable to consider "udp-tunnel" in place of "gtp" to cover both?

Best regards,
John



From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, October 15, 2024 7:58 AM
To: Kaippallimalil John <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [DMM] I-D Action: draft-ietf-dmm-tn-aware-mobility-11.txt

Hi John,

(adding teas as I see that you also sent a message to teas on the same topic).

(1)

Thank you for considering the applicability of the ACaaS to the GTP-U mapping approach (and l3 tunnels in general).

(2)

I think that it would be better to include a provision in the base AC docs themselves for future layer 3 encaps. The structure is similar to what you suggested with some slight changes as your can see below:

OLD:

           |  ...

           +--rw ac* [name]

              ...

              +--rw ip-connection  {ac-common:layer3-ac}?

              |  |...

              |  +--rw (l3-service)?

              |    +--: (l3-tunnel-service)

                       < IPv4 addr, IPv6 prefix and ports for source, destination >

NEW:

           |  ...

           +--rw ac* [name]

              ...

              +--rw ip-connection  {ac-common:layer3-ac}?

              |  |...

              |  +--rw (l3-service)?  <======== base AC models

              |     +--:(l3-tunnel-service)

             |        +--rw l3-tunnel-service

             |           +--rw type?   identityref

              |           +--gtp  <========== DMM Extension

                       < IPv4 addr, IPv6 prefix and ports for source, destination >


I exercised that path to see what would be needed to support that. The changes are straightforward as you can see in:


  *   AC Common: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-common-ac.txt&url_2=https://boucadair.github.io/attachment-circuit-model/l3-tunnel-service/draft-ietf-opsawg-teas-common-ac.txt
  *   ACaaS: https://author-tools.ietf.org/api/iddiff?url_1=https://boucadair.github.io/attachment-circuit-model/draft-ietf-opsawg-teas-attachment-circuit.txt&url_2=https://boucadair.github.io/attachment-circuit-model/l3-tunnel-service/draft-ietf-opsawg-teas-attachment-circuit.txt

Your document can graft the GTP-U based on a ckeck on type=gtp and add the missing data nodes.

I think this approach is cleaner for other tunneling technologies as they simply need to define a new identity based on ac-common:l3-tunnel-type.

Does this make sense?

(3)

FWIW, please find a quick review of the dmm spec:


  *   pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2024/draft-ietf-dmm-tn-aware-mobility-11-rev%20Med.pdf
  *   doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/refs/heads/master/2024/draft-ietf-dmm-tn-aware-mobility-11-rev%20Med.doc

I think there is a room to simplify and leverage TEAS documents to focus more on what I see as a key contribution of your spec: applicability of the UDP source port number as a mapping method of 5G slices to TN slices. The GTP-U (and /IPsec) ACaaS extension is definitely worth documenting here. This will complement the AC assessment work in draft-ietf-teas-5g-network-slice-application.

(4)

Also, as the title focuses in "mobility-aware" slicing, I was expecting to see some elaboration on the mobility matters but seems those are not relevant as the mapping realization between 5G legs and TN is hidden to UEs/customers. May be add a clarification to the draft.

Thank you.

Cheers,
Med

De : Kaippallimalil John <[e-mail]<mailto:[e-mail]>>
Envoyé : mardi 15 octobre 2024 10:27
À : [e-mail]<mailto:[e-mail]>; BOUCADAIR Mohamed INNOV/NET <[e-mail]<mailto:[e-mail]>>
Objet : RE: [DMM] I-D Action: draft-ietf-dmm-tn-aware-mobility-11.txt


Hi,

We posted a new version of dmm-tn-aware-mobility (see links below) that is related /proposes some extensions to work in teas ACaaS.



When the authors were revising draft-ietf-dmm-tn-aware-mobility' to use ACaaS, we realized that it is closely related to I-D.ietf-opsawg-teas-attachment-circuit and we were expecting to use those as building blocks.

Except that GTP is not in any of the module descriptions as it is not an IETF protocol. So, we updated the dmm draft with extensions to support a UDP encapsulation (like GTP, ...).

Outline of the tree structure:

           |  ...

           +--rw ac* [name]

              ...

              +--rw ip-connection  {ac-common:layer3-ac}?

              |  |...

              |  +--rw (l3-service)?

              |    +--: (l3-tunnel-service)

                       < IPv4 addr, IPv6 prefix and ports for source, destination >





The extensions are more generally applicable than just for the dmm draft (which is mainly considering a GTP UDP encapsulation).



Since OPSAWG is currently considering adoption of a GTP-related draft ([OPSAWG]CALL FOR ADOPTION: Export of GTP-U Information in IP Flow Information Export (IPFIX) (ietf.org)<https://mailarchive.ietf.org/arch/msg/opsawg/LkJKuxfs4ZiW8c404kluVtVPz3c/>;)

we would like your feedback.



BR,

John







> -----Original Message-----

> From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>

> Sent: Tuesday, October 15, 2024 2:58 AM

> To: [e-mail]<mailto:[e-mail]>

> Cc: [e-mail]<mailto:[e-mail]>

> Subject: [DMM] I-D Action: draft-ietf-dmm-tn-aware-mobility-11.txt

>

> Internet-Draft draft-ietf-dmm-tn-aware-mobility-11.txt is now available. It is a

> work item of the Distributed Mobility Management (DMM) WG of the IETF.

>

>    Title:   Mobility aware Transport Network Slicing for 5G

>    Authors: Uma Chunduri

>             John Kaippallimalil

>             Sridhar Bhaskaran

>             Jeff Tantsura

>             Luis M. Contreras

>    Name:    draft-ietf-dmm-tn-aware-mobility-11.txt

>    Pages:   25

>    Dates:   2024-10-15

>

> Abstract:

>

>    Network slicing in 5G supports logical networks for communication

>    services of multiple 5G customers to be multiplexed over the same

>    infrastructure.  While 5G slicing covers logical separation of

>    various aspects of 5G services, user's data plane packets over the

>    radio access network (RAN) and mobile core network (5GC) use IP

>    transport in many segments of the end-to-end 5G slice.  When end-to-

>    end slices in a 5G system use IP network resources, they are mapped

>    to corresponding IP transport network slice(s) which in turn provide

>    the bandwidth, latency, isolation and other criteria requested by the

>    5G slice.

>

>    This document describes mapping of 5G slices to IP or Layer 2

>    transport network slices when the IP transport network (slice

>    provider) is separated by an "attachment circuit" from the networks

>    in which the 5G network functions are deployed, for example, 5G

>    functions that are distributed across data centers.  The slice

>    mapping proposed here is supported transparently when a 5G user

>    device moves across 5G attachment points and session anchors.

>

> The IETF datatracker status page for this Internet-Draft is:

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata<https://data/>

> tracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware-

> mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C6

> b5939a219504232d51608dcecef7311%7C0fee8ff2a3b240189c753a1d559

> 1fedc%7C1%7C0%7C638645760398257636%7CUnknown%7CTWFpbGZsb3

> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0

> %3D%7C0%7C%7C%7C&sdata=IZHwz5M21EGhaP8IA3NvTiI7waxcpYqAYg78

> 0m5vAZ8%3D&reserved=0

>

> There is also an HTMLized version available at:

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata<https://data/>

> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-dmm-tn-aware-mobility-

> 11&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C6b5939a21

> 9504232d51608dcecef7311%7C0fee8ff2a3b240189c753a1d5591fedc%7C1

> %7C0%7C638645760398279674%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi

> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0

> %7C%7C%7C&sdata=eKPT%2FYt6fewNJLYVd2NMWXMblK%2FLWUm5%2FW

> LbJ53tL3s%3D&reserved=0

>

> A diff from the previous version is available at:

> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth<https://auth/>

> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-dmm-tn-aware-mobility-

> 11&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C6b5939a21

> 9504232d51608dcecef7311%7C0fee8ff2a3b240189c753a1d5591fedc%7C1

> %7C0%7C638645760398291845%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi

> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0

> %7C%7C%7C&sdata=068Axl%2BIoPhjpkLc%2BnVbcbXMByOnGXUW2uPY0k

> 8Dtzs%3D&reserved=0

>

> Internet-Drafts are also available by rsync at:

> rsync.ietf.org::internet-drafts

>

>

> _______________________________________________

> dmm mailing list -- [e-mail]<mailto:[e-mail]>

> To unsubscribe send an email to [e-mail]<mailto:[e-mail]>

____________________________________________________________________________________________________________

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.