Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

From: Uma Chunduri <[email-masked]>
Date: Fri, 16 Oct 2020 11:42:45 -0700

Dear DMM experts,

This version is a refresh but all comments received (offline and during the
presentation at IETF106) were addressed.

Any further comments/suggestions are most welcome.

--
Uma C.

On Mon, Sep 28, 2020 at 4:44 PM <[email-masked]> wrote:

>
> A new version of I-D, draft-clt-dmm-tn-aware-mobility-07.txt
> has been successfully submitted by Uma Chunduri and posted to the
> IETF repository.
>
> Name:           draft-clt-dmm-tn-aware-mobility
> Revision:       07
> Title:          Transport Network aware Mobility for 5G
> Document date:  2020-09-28
> Group:          Individual Submission
> Pages:          28
> URL:
> https://www.ietf.org/id/draft-clt-dmm-tn-aware-mobility-07.txt
> Status:
> https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility
> Htmlized:
> https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-clt-dmm-tn-aware-mobility-07
>
> Abstract:
>    This document specifies a framework and mapping from slices in 5G
>    mobile systems to transport slices in IP and Layer 2 transport
>    networks.  Slices in 5G systems are characterized by latency bounds,
>    reservation guarantees, jitter, data rates, availability, mobility
>    speed, usage density, criticality and priority should be mapped to
>    transport slice characteristics that include bandwidth, latency and
>    criteria such as isolation, directionality and disjoint routes.
>    Mobile slice criteria need to be mapped to the appropriate transport
>    slice and capabilities offered in backhaul, midhaul and fronthaul
>    connectivity segments between radio side network functions and user
>    plane function (gateway).
>
>    This document describes how mobile network functions map its slice
>    criteria to identifiers in IP packets that transport segments use to
>    grant transport layer services.  This is based on mapping between
>    mobile and IP transport underlays (IPv6, MPLS, IPv4, Segment
>    Routing).  Applicability of this framework and a new transport
>    network underlay routing mechanism, Preferred Path Routing (PPR),
>    which brings slice properties and works with any underlying transport
>    (L2, IPv4, SR and MPLS) is also discussed.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 16 Oct 2020 18:50:16 +0000

WG – Please provide your inputs on this document. Authors have presented this earlier and like to get some feedback.

Sri

From: dmm <[email-masked]> on behalf of Uma Chunduri <[email-masked]>
Date: Friday, October 16, 2020 at 11:42 AM
To: dmm <[email-masked]>
Cc: "Luis M. Contreras" <[email-masked]>, Praveen Muley <[email-masked]>, Jeff Tantsura <[email-masked]>, Richard Li <[email-masked]>, Sridhar Bhaskaran <[email-masked]>
Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Dear DMM experts,

This version is a refresh but all comments received (offline and during the presentation at IETF106) were addressed.

--
Uma C.

On Mon, Sep 28, 2020 at 4:44 PM <[email-masked]<mailto:[email-masked]>> wrote:

Name:           draft-clt-dmm-tn-aware-mobility
Revision:       07
Title:          Transport Network aware Mobility for 5G
Document date:  2020-09-28
Group:          Individual Submission
Pages:          28
URL:            https://www.ietf.org/id/draft-clt-dmm-tn-aware-mobility-07.txt
Status:         https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility
Htmlized:       https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-clt-dmm-tn-aware-mobility-07

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 21 Oct 2020 18:20:51 +0000

Hi Uma et al,

Thank you for all the work on this document.

As described in the abstract this document defines two things:
In section 2 you describe a framework to map slices in mobile systems to slices in the transport network; while in section 3 you describe how a new transport network underlay routing mechanism, Preferred Path Routing, can be used in combination with this framework.

PPR (draft-chunduri-lsr-isis-preferred-path-routing and draft-chunduri-lsr-ospf-preferred-path-routing) was last presented in LSR WG at IETF102 if I recall correctly.
The WG highlighted issues with regards to the scalability of the proposal. https://datatracker.ietf.org/doc/minutes-102-lsr/
Further discussion took place at the LSR mailer and those scalability concerns on PPR remain unaddressed.
https://mailarchive.ietf.org/arch/msg/lsr/6TzBBkmq4hQkiqyBeuN7MMOtMs0/

In my opinion it would be good to either address the LSR scalability concerns on PPR, or perhaps move all PPR content (Section 3 and related appendix) into a separate document.
Given that PPR is unneeded to define the framework -core of the ID-; and both sections seem orthogonal, I believe splitting the document would be appropriate.

Thank you,
Pablo.

From: dmm <[email-masked]> On Behalf Of Sri Gundavelli (sgundave)
Sent: viernes, 16 de octubre de 2020 20:50
To: Uma Chunduri <[email-masked]>; dmm <[email-masked]>
Cc: Luis M. Contreras <[email-masked]>; Richard Li <[email-masked]>; Jeff Tantsura <[email-masked]>; Praveen Muley <[email-masked]>; Sridhar Bhaskaran <[email-masked]>
Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Sri

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Uma Chunduri <[email-masked]<mailto:[email-masked]>>
Date: Friday, October 16, 2020 at 11:42 AM
To: dmm <[email-masked]<mailto:[email-masked]>>
Cc: "Luis M. Contreras" <[email-masked]<mailto:[email-masked]>>, Praveen Muley <[email-masked]<mailto:[email-masked]>>, Jeff Tantsura <[email-masked]<mailto:[email-masked]>>, Richard Li <[email-masked]<mailto:[email-masked]>>, Sridhar Bhaskaran <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Dear DMM experts,

--
Uma C.

Abstract:

The IETF Secretariat

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Wed, 21 Oct 2020 20:29:03 +0000

Hi Uma et all,

Thanks for putting together this draft to describe the framework for mapping the slices in 5G mobile systems to transport slices in IP towards the UPF. This framework is valuable and we are actually looking for further extensions of the TN characteristics in non-mobility domain (SD-WAN) and that is being worked out to be submitted in RTG WG.

I would also request you to consider the Security Characteristics in addition to the current Transport Path characteristics. Preserving the security characteristics in non-mobility SD-WAN domain would be an important aspects. My suggestions would be to extend the current SST for secure traffic. As a result, it would be good if we can define additional UDP Source Port range to capture the Security characteristics for the current service types.

I would be happy to share more context on the use cases and discuss further on the approaches.

Regards,
Kausik

Sent: Friday, October 16, 2020 11:50 AM

WG – Please provide your inputs on this document. Authors have presented this earlier and like to get some feedback. Sri 
External (sgundave=[email-masked]<mailto:sgundave=[email-masked]>)
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzcyNzRhM2I1YTc1MjBiMjhjMGE4YzVkMThmMzI1MjQ5LzE2MDI4NzQyMzEuNzE=#key=11c12c5a0edd2d2ae7c93e01bdbea727>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

Sri

Dear DMM experts,

--
Uma C.

Name:           draft-clt-dmm-tn-aware-mobility
Revision:       07
Title:          Transport Network aware Mobility for 5G
Document date:  2020-09-28
Group:          Individual Submission
Pages:          28
URL:            https://www.ietf.org/id/draft-clt-dmm-tn-aware-mobility-07.txt<https://secure-web.cisco.com/1HUA6v1Gdr5_puQcsnaapEg09YhVPDRhw-Z4XfLGhWjxvpYip9j5au0XOo4oqhSGR_2XS9_cWhzz-vrhLJmGFNVAyHY6OfzQuaWpK4j23qgD5WMYvB3dXaE7R9odO7eFfJAWuGsK2IsUvwIwkL9EC0EbqhCrQ9y-JBycIhi2TypsN3YgYX34tLDTFp5SdN2uDFt5E-0E8KFk3ma-o18enNkx0ZV_QxlgxVPp8EZk6SmgykOY6NtEr0_flV_r75nOEpjetht5Lyd8ue3iUeYotxkkL8KAYgdO_TavNyDBXEQii4_Rjkh1hgkkbEn0ln3PP/https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-clt-dmm-tn-aware-mobility-07.txt>
Status:         https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/<https://secure-web.cisco.com/1o8eotE-FYKGPdoZbT2QAHiLXLo5UYi3T1-3xk2tBs3Ux8yg4xpaqu06JzppJIEKGDPX98lTEgVx7jFhfgT6ApunAtYOOSYlSFyGiczHqR5S0oRD95qvrtoYUsDv82aDn93sXMzrdwkGSqdKcO43SRODSebRHpxmuI0IAjHy5bl9FDabxLB_AnRpbp1fKr_OkhufZsx6YZMo1Xs_PbIfF6BCyzoY5BlH0uE22QhQhljrYHVWoX-wqqIBP5dt8Hcf5kRg4JgLBfxezmnEy_hInAzPhaBXfFWdo34QvEWz4zm-9vQR1FLRvBVrhFMPeAVkk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-clt-dmm-tn-aware-mobility%2F>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility<https://secure-web.cisco.com/1WBjnX_EXxhnR341AApScUFRP33oCh0xypmrVFE-xlGK06QwjC455qwn6xhtR4ooBaKkH01WhY6Zpupp-Xe_Df8ERiRnqMMkN9LJun-bAqp61ZbJEXygFM3WJ0_rDae7L6eGdyyeZal1nsP7jtKH2jOEJb1xJAICHM_IgA0LzGnwfQdrBueTi-f9qaX2tQUlyiufX3ho0pKOkLYphzv2IBGIhUswgcHvvIclRoueVFi46jqIbpIFtPAfQQ1m6EoHYLBOM5dJsEjM0SjylYSmWKLNMFvBtfx8A1Fr7qH0-JnsegcAmCXWqH5r5WtDHHVLA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility>
Htmlized:       https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07<https://secure-web.cisco.com/1KT0Y8uI3-ZZ9X_tnot7DK7_mKKxMnFk120FQseudl9UpYaWY_EA0nd9lwkczICRmCtiemIu9mp3DbAGkrSXUREC1d5vVHVMXoOfHH4aImZGLeEHjYRgt3XXA8B0AaziQImChKSCiaRyzAPPERbCxsDNOivOT3Ty5hRim80Zt5qL9DETDYs4SlgscKHVCLQs3_LOSJ0S37MtBWahPnE-SmH9VAT6XQ5MtNDVeWMJ-b9Nsy9fsmxHL5rf6FKFKdk12_zktiO3vHvIi0owaf8lnErsFvqhSf1X80cJY9lMoml5JgbJD2xpIePEoCzYm28l-/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-07>
Diff:           https://www.ietf.org/rfcdiff?url2=draft-clt-dmm-tn-aware-mobility-07<https://secure-web.cisco.com/1UAzhu6YGSP4ihbOSD939zZAkcrli5mB9NVPYyf4BAqd04KEWCWmJatff0cuRmsZoXNizC2cIK0wLTEvofDlU3dnbs2OIsqCJXiZlT1uKmGCIYr-ymBGvG6r-9cwu8CF5mR5GnbzuqVpeQsL0mzG6FGrMT25OE-CfpZqC4jZ9Eb7x_gs-X7l0w5_r63k2J2KHOMPM4OhC6t5uep_oHXDLdsl7yK-8m7ng6ftlneINEmDk487g1iRb8KIkYwG9sSLBGiJyJ8UoKRUAJrabQ_caLJGwszh9P31OaovcBF8mthbCwWabG3GiL0POtOUPSEbq/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-clt-dmm-tn-aware-mobility-07>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://secure-web.cisco.com/14Fr42g2bTEsJF34rTr62k-NbB2zi6tqG1vqgnHETQHzNo94LuoTRn2e6jLWvg1CEJo3VvetBek_OIm28HZznMnuQxZOX4cNWs_bOw10xCJaLQUntfaQcYmSelEPyV9q6DfVr-yZDhf83E24VBx1MhWkSLutkoutRLAFLzxxsWPU_ohfIKX4Hfm2LagSaAB8SSpJWtK8WDAkYT2QoLHwOEz314La6n-VQWx2_UM7Ga1qmL6NC-Me-_925b_2SVjp9diEYltTkGWz2ZvMT8fPdyePN4pzRdg6OEja2731L7iz1_WKFJajLYTEZNcBg_6cD/http%3A%2F%2Ftools.ietf.org>.

The IETF Secretariat

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 21 Oct 2020 16:36:02 -0400

I would note that it seems a little odd to do this work when we do not 
have agreement on what the exposed properties are of an IETF Network 
Slice (see the TEAS discussion), much less how packets are mapped to them.

Yours,
Joel

On 10/21/2020 4:29 PM, Majumdar, Kausik wrote:
> Hi Uma et all,
> 
> Thanks for putting together this draft to describe the framework for 
> mapping the slices in 5G mobile systems to transport slices in IP 
> towards the UPF. This framework is valuable and we are actually looking 
> for further extensions of the TN characteristics in non-mobility domain 
> (SD-WAN) and that is being worked out to be submitted in RTG WG.
> 
> I would also request you to consider the Security Characteristics in 
> addition to the current Transport Path characteristics. Preserving the 
> security characteristics in non-mobility SD-WAN domain would be an 
> important aspects. My suggestions would be to extend the current SST for 
> secure traffic. As a result, it would be good if we can define 
> additional UDP Source Port range to capture the Security characteristics 
> for the current service types.
> 
> *From:* dmm <[email-masked]> *On Behalf Of * Sri Gundavelli (sgundave)
> *Sent:* Friday, October 16, 2020 11:50 AM
> *To:* Uma Chunduri <[email-masked]>; dmm <[email-masked]>
> *Cc:* Luis M. Contreras <[email-masked]>; 
> Richard Li <[email-masked]>; Jeff Tantsura 
> <[email-masked]>; Praveen Muley <[email-masked]>; 
> Sridhar Bhaskaran <[email-masked]>
> *Subject:* Re: [DMM] New Version Notification for 
> draft-clt-dmm-tn-aware-mobility-07.txt
> 
> WG – Please provide your inputs on this document. Authors have presented 
> this earlier and like to get some feedback.
> 
> Sri
> 
> *From: *dmm <[email-masked] <mailto:[email-masked]>> on 
> behalf of Uma Chunduri <[email-masked] <mailto:[email-masked]>>
> *Date: *Friday, October 16, 2020 at 11:42 AM
> *To: *dmm <[email-masked] <mailto:[email-masked]>>
> *Cc: *"Luis M. Contreras" <[email-masked] 
> <mailto:[email-masked]>>, Praveen Muley 
> <[email-masked] <mailto:[email-masked]>>, Jeff 
> Tantsura <[email-masked] <mailto:[email-masked]>>, 
> Richard Li <[email-masked] <mailto:[email-masked]>>, 
> Sridhar Bhaskaran <[email-masked] <mailto:[email-masked]>>
> *Subject: *Re: [DMM] New Version Notification for 
> draft-clt-dmm-tn-aware-mobility-07.txt
> 
> Dear DMM experts,
> 
> This version is a refresh but all comments received (offline and during 
> the presentation at IETF106) were addressed.
> 
> On Mon, Sep 28, 2020 at 4:44 PM <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> 
>     <https://secure-web.cisco.com/1HUA6v1Gdr5_puQcsnaapEg09YhVPDRhw-Z4XfLGhWjxvpYip9j5au0XOo4oqhSGR_2XS9_cWhzz-vrhLJmGFNVAyHY6OfzQuaWpK4j23qgD5WMYvB3dXaE7R9odO7eFfJAWuGsK2IsUvwIwkL9EC0EbqhCrQ9y-JBycIhi2TypsN3YgYX34tLDTFp5SdN2uDFt5E-0E8KFk3ma-o18enNkx0ZV_QxlgxVPp8EZk6SmgykOY6NtEr0_flV_r75nOEpjetht5Lyd8ue3iUeYotxkkL8KAYgdO_TavNyDBXEQii4_Rjkh1hgkkbEn0ln3PP/https%3A%2F%2Fwww.ietf.org%2Fid%2Fdraft-clt-dmm-tn-aware-mobility-07.txt>
>     Status:
>     <https://secure-web.cisco.com/1o8eotE-FYKGPdoZbT2QAHiLXLo5UYi3T1-3xk2tBs3Ux8yg4xpaqu06JzppJIEKGDPX98lTEgVx7jFhfgT6ApunAtYOOSYlSFyGiczHqR5S0oRD95qvrtoYUsDv82aDn93sXMzrdwkGSqdKcO43SRODSebRHpxmuI0IAjHy5bl9FDabxLB_AnRpbp1fKr_OkhufZsx6YZMo1Xs_PbIfF6BCyzoY5BlH0uE22QhQhljrYHVWoX-wqqIBP5dt8Hcf5kRg4JgLBfxezmnEy_hInAzPhaBXfFWdo34QvEWz4zm-9vQR1FLRvBVrhFMPeAVkk/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-clt-dmm-tn-aware-mobility%2F>
>     Htmlized:
>     https://datatracker.ietf.org/doc/html/draft-clt-dmm-tn-aware-mobility <https://secure-web.cisco.com/1WBjnX_EXxhnR341AApScUFRP33oCh0xypmrVFE-xlGK06QwjC455qwn6xhtR4ooBaKkH01WhY6Zpupp-Xe_Df8ERiRnqMMkN9LJun-bAqp61ZbJEXygFM3WJ0_rDae7L6eGdyyeZal1nsP7jtKH2jOEJb1xJAICHM_IgA0LzGnwfQdrBueTi-f9qaX2tQUlyiufX3ho0pKOkLYphzv2IBGIhUswgcHvvIclRoueVFi46jqIbpIFtPAfQQ1m6EoHYLBOM5dJsEjM0SjylYSmWKLNMFvBtfx8A1Fr7qH0-JnsegcAmCXWqH5r5WtDHHVLA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility>
>     Htmlized:
>     <https://secure-web.cisco.com/1KT0Y8uI3-ZZ9X_tnot7DK7_mKKxMnFk120FQseudl9UpYaWY_EA0nd9lwkczICRmCtiemIu9mp3DbAGkrSXUREC1d5vVHVMXoOfHH4aImZGLeEHjYRgt3XXA8B0AaziQImChKSCiaRyzAPPERbCxsDNOivOT3Ty5hRim80Zt5qL9DETDYs4SlgscKHVCLQs3_LOSJ0S37MtBWahPnE-SmH9VAT6XQ5MtNDVeWMJ-b9Nsy9fsmxHL5rf6FKFKdk12_zktiO3vHvIi0owaf8lnErsFvqhSf1X80cJY9lMoml5JgbJD2xpIePEoCzYm28l-/https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-07>
>     Diff:
>     <https://secure-web.cisco.com/1UAzhu6YGSP4ihbOSD939zZAkcrli5mB9NVPYyf4BAqd04KEWCWmJatff0cuRmsZoXNizC2cIK0wLTEvofDlU3dnbs2OIsqCJXiZlT1uKmGCIYr-ymBGvG6r-9cwu8CF5mR5GnbzuqVpeQsL0mzG6FGrMT25OE-CfpZqC4jZ9Eb7x_gs-X7l0w5_r63k2J2KHOMPM4OhC6t5uep_oHXDLdsl7yK-8m7ng6ftlneINEmDk487g1iRb8KIkYwG9sSLBGiJyJ8UoKRUAJrabQ_caLJGwszh9P31OaovcBF8mthbCwWabG3GiL0POtOUPSEbq/https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-clt-dmm-tn-aware-mobility-07>
> 
>     Abstract:
>     until the htmlized version and diff are available at tools.ietf.org
>     <http://secure-web.cisco.com/14Fr42g2bTEsJF34rTr62k-NbB2zi6tqG1vqgnHETQHzNo94LuoTRn2e6jLWvg1CEJo3VvetBek_OIm28HZznMnuQxZOX4cNWs_bOw10xCJaLQUntfaQcYmSelEPyV9q6DfVr-yZDhf83E24VBx1MhWkSLutkoutRLAFLzxxsWPU_ohfIKX4Hfm2LagSaAB8SSpJWtK8WDAkYT2QoLHwOEz314La6n-VQWx2_UM7Ga1qmL6NC-Me-_925b_2SVjp9diEYltTkGWz2ZvMT8fPdyePN4pzRdg6OEja2731L7iz1_WKFJajLYTEZNcBg_6cD/http%3A%2F%2Ftools.ietf.org>.
> 
>     The IETF Secretariat
> 
> 
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 21 Oct 2020 17:51:00 -0700

> Slice (see the TEAS discussion), much less how packets are mapped to them.

Sure, Joel. A quick recap on this:
1. I would note. the scope is much narrower here than genericTEAS
discussion *
2. We are just seeking comments  here before asking WG to develop further.

Would be happy to consider any inputs from you.
--
Uma C.

* this predates any TEAS discussions almost an year earlier and was
developed over a period of time with many inputs from DMM experts

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 21 Oct 2020 18:10:23 -0700

Thanks Pablo for your comments. In line [Uma]:

On Wed, Oct 21, 2020 at 11:20 AM Pablo Camarillo (pcamaril) <
[email-masked]> wrote:

> In section 2 you describe a framework to map slices in mobile systems to
> slices in the transport network; while in section 3 you describe how a new
> transport network underlay routing mechanism, Preferred Path Routing, can
> be used in combination with this framework.
>

Right. But it also lays out other TE mechanisms (SR, RSVP-TE) which are
already being used in the networks and how that is applicable to the
framework described.

>
>
> PPR (draft-chunduri-lsr-isis-preferred-path-routing and
> draft-chunduri-lsr-ospf-preferred-path-routing) was last presented in LSR
> WG at IETF102 if I recall correctly.
>
> The WG highlighted issues with regards to the scalability of the proposal.
> https://datatracker.ietf.org/doc/minutes-102-lsr/
>

We did give further updates and answers in IETF 103 and further published
new work (ppr graphs work, the above links points to).
And a hackathon related to this  in IETF105. But I admit, I have not been
active further in the LSR group.
Shall follow through this further. But the larger point was it just merely
shows various segments of Xhaul (with L1/L2 and L3 transport) how different
underlying technologies can address the framework described here.

>
> In my opinion it would be good to either address the LSR scalability
> concerns on PPR, or perhaps move all PPR content (Section 3 and related
> appendix) into a separate document.
>
> Given that PPR is unneeded to define the framework -core of the ID-; and
> both sections seem orthogonal, I believe splitting the document would be
> appropriate.
>

Noted your preference Pablo, but as I said this was there merely to attest
what's been laid out and how new mobility scenarios with transport
awareness work in general. I can make it concise just to respect the
earlier agreements with feedback received (regarding example etc.).

Many thx,

--
Uma C.

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 21 Oct 2020 18:18:22 -0700

Thanks Kaushik for your comments. Need a quick clarification (see below ..)

On Wed, Oct 21, 2020 at 1:29 PM Majumdar, Kausik <
[email-masked]> wrote:

> mapping the slices in 5G mobile systems to transport slices in IP towards
> the UPF. This framework is valuable and we are actually looking for further
> extensions of the TN characteristics in non-mobility domain (SD-WAN) and
> that is being worked out to be submitted in RTG WG.
>

Thanks.

> secure traffic. As a result, it would be good if we can define additional
> UDP Source Port range to capture the Security characteristics for the
> current service types.
>

We already described the generic case where security is applied (section
2.6), when the user plane emits the packet to transport (could be N3/N9
interfaces or S1U interface terminating at SGWs).
That addresses mostly shared transport cases.
If I understand correctly, you want security done by PE's before gNB/UPF??
I can imagine few usef of this but can you explain why you are looking for
this option?

> further on the approaches.

Sure. But is this a mandatory option for your E2E use case with
SD-WAN beyond mobility domain?

--
Uma C.

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Mon, 26 Oct 2020 19:48:48 +0000

Hi Uma,

My comments are inline below.

From: dmm <[email-masked]> On Behalf Of Uma Chunduri
Sent: Wednesday, October 21, 2020 6:18 PM
To: dmm <[email-masked]>
Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Thanks Kaushik for your comments. Need a quick clarification (see below ..) 
Caution (External, [email-masked]<mailto:[email-masked]>)
Spam Content   Details<https://shared.outlook.inky.com/details?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzZhMWU2MWE2MDA2ZDBkM2ZjM2Y3ZGQ3MThmM2M5NzdmLzE2MDMzMjk1MTQuMTg=#key=907e11ca2c9278a0aa07bfcd42e9c8a7>
Report This Email<https://shared.outlook.inky.com/report?id=Y29tbXNjb3BlL2thdXNpay5tYWp1bWRhckBjb21tc2NvcGUuY29tLzZhMWU2MWE2MDA2ZDBkM2ZjM2Y3ZGQ3MThmM2M5NzdmLzE2MDMzMjk1MTQuMTg=#key=907e11ca2c9278a0aa07bfcd42e9c8a7>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<https://www.inky.com>

On Wed, Oct 21, 2020 at 1:29 PM Majumdar, Kausik <[email-masked]<mailto:[email-masked]>> wrote:
Hi Uma et all,

Thanks.

We already described the generic case where security is applied (section 2.6), when the user plane emits the packet to transport (could be N3/N9 interfaces or S1U interface terminating at SGWs).
That addresses mostly shared transport cases.
If I understand correctly, you want security done by PE's before gNB/UPF??  I can imagine few usef of this but can you explain why you are looking for this option?

Yes, I am looking for UE traffic to be secured by the PE’s before gNB/UPF. There could be specific traffic types for MIOT, EMBB, and URLLC service types where security is more important. Even this draft is addressing data path security for these service types the security characteristics needs to be preserved all the to the traffic destination, it can’t stop at SGWs or UPF. Then, the purpose for UE traffic to achieve end to end security is lost. Specially if we look into SD-WAN deployments the security is the key aspects and the SD-WAN Edge Nodes establish secure IPSec tunnels between them. Here https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-08 nicely captures SD-WAN use cases for Homogeneous and Hybrid networks. Considering that, if the UE traffic needs to go beyond SGWs/UPF to the actual destination in the Data Network connected through SD-WAN Edge Nodes (Enterprise 5G case) the security characteristics for all the SSTs need to be preserved to maintain the E2E security.

I think it would be good to expand the UDP Src Port range table captured in Figure 2. For all of the current SST types we could come up with different Range where E2E security is the key requirement for the UE traffic like below:

UDP Src Port Range Ax – Ay : SST - MIOT with Security
..

In general, if we look into the SD-WAN use cases the security is the key aspects how SD-WAN edge nodes establishes and send secure traffic between them to connect different sites branches, branch to the cloud GW.

Sure. But is this a mandatory option for your E2E use case with SD-WAN beyond mobility domain?

I would say it is a mandatory option for E2E use cases with SD-WAN beyond mobility domain. If you look into the retail stores, education, etc (small to medium enterprise deployments), majority of the connections land into cloud with a secure tunnel connectivity to the cloud GW. These enterprise SD-WAN edge devices accept connections not only from wireless APs, but also for the mobility traffic through SWGs/UPF. In the case of UE mobility traffic needs to land into large enterprise with a security aspects, the SD-WAN GW in the corporate network need to preserve that behavior for E2E security.

Hope it clarifies. How the SD-WAN GW map the TN characteristics in non-mobility domain to maintain UE’s E2E traffic characteristics is being worked out, and would be submitted.

Regards,
Kausik

--
Uma C.

Regards,
Kausik

---

From: "Majumdar, Kausik" <[email-masked]>
Date: Mon, 26 Oct 2020 20:15:28 +0000

Hi Uma,

Few more general minor comments on the draft below:

  1.  Section 2.2 talks about front haul but picture, can you please capture it in the figure 1.

  1.  Section 2.4 mentions –

   "The PE router inspects incoming
   PDU data packets for the MTNC-ID, classifies and provides the VN
   service provisioned across the transport network."

Should PE rather inspects the UDP Src Port here which mirrors MTN-ID?

3.      Section 2.7 mentions –

a) “If a PE is not co-located at the UPF then
               mapping to the underlying TE paths at PE happens based on the
               encapsulated GTP-US packet as specified in Section 2.6.”

              Should it be GTP-U packet?

b)  "o  If any other form of encapsulation (other than GTP-U) either on N3
   or N9 corresponding QFI information MUST be there in the
   encapsulation header."

               Not very clear on this. Does it need to be there?

c) "If TNF is seen as part of management
plane, this real time flexibility is lost."

                  The above statement contradicts the figure 1. We should change that to a separate management function.

Regards,
Kausik

From: Majumdar, Kausik
Sent: Monday, October 26, 2020 12:49 PM
To: Uma Chunduri <[email-masked]>; dmm <[email-masked]>
Subject: RE: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Hi Uma,

From: dmm <[email-masked]<mailto:[email-masked]>> On Behalf Of Uma Chunduri
Sent: Wednesday, October 21, 2020 6:18 PM
To: dmm <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] New Version Notification for draft-clt-dmm-tn-aware-mobility-07.txt

Thanks.

Regards,
Kausik

--
Uma C.

Regards,
Kausik

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 26 Oct 2020 17:30:08 -0700

Thanks for your review, comments in-line ..

--
Uma C.

On Mon, Oct 26, 2020 at 1:15 PM Majumdar, Kausik <
[email-masked]> wrote:

> Sure, shall fix that.

> Should PE rather inspects the UDP Src Port here which mirrors MTN-ID?
Right, UDP Src port.

>                encapsulated *GTP-US* packet as specified in Section 2.6.”
>
>
>
That's a typo. Shall correct it.

>                Not very clear on this. Does it need to be there?
Good catch. This was from the earlier versions and shall change this to be
aligned with the rest of the content. Yes, obviously it should not use QFI
anywhere..

>                   The above statement contradicts the figure 1. We should
> change that to a separate management function.
>
Thx. Shall fix this too (left out from earlier versions without getting
updated).

>
> Regards,
>
> Kausik
>
>
>
> *From:* Majumdar, Kausik
> *Sent:* Monday, October 26, 2020 12:49 PM
> *Subject:* RE: [DMM] New Version Notification for
> *From:* dmm <[email-masked]> *On Behalf Of *Uma Chunduri
> *Sent:* Wednesday, October 21, 2020 6:18 PM
> *To:* dmm <[email-masked]>
> If I understand correctly, you want security done by PE's before
> gNB/UPF??  I can imagine few usef of this but can you explain why you are
> looking for this option?
>
>
>
> Yes, I am looking for UE traffic to be secured by the PE’s before gNB/UPF.
> There could be specific traffic types for MIOT, EMBB, and URLLC service
> types where security is more important. Even this draft is addressing data
> path security for these service types the security characteristics needs to
> be preserved all the to the traffic destination, it can’t stop at SGWs or
> UPF. Then, the purpose for UE traffic to achieve end to end security is
> lost. Specially if we look into SD-WAN deployments the security is the key
> aspects and the SD-WAN Edge Nodes establish secure IPSec tunnels between
> them. Here
> https://tools.ietf.org/html/draft-dunbar-bess-bgp-sdwan-usage-08 nicely
> captures SD-WAN use cases for Homogeneous and Hybrid networks. Considering
> that, if the UE traffic needs to go beyond SGWs/UPF to the actual
> destination in the Data Network connected through SD-WAN Edge Nodes
> (Enterprise 5G case) the security characteristics for all the SSTs need to
> be preserved to maintain the E2E security.
>
>
>
> I think it would be good to expand the UDP Src Port range table captured
> in Figure 2. For all of the current SST types we could come up with
> different Range where E2E security is the key requirement for the UE
> traffic like below:
>
>
>
> In general, if we look into the SD-WAN use cases the security is the key
> aspects how SD-WAN edge nodes establishes and send secure traffic between
> them to connect different sites branches, branch to the cloud GW.
>
>
>
>
>
> I would say it is a mandatory option for E2E use cases with SD-WAN beyond
> mobility domain. If you look into the retail stores, education, etc (small
> to medium enterprise deployments), majority of the connections land into
> cloud with a secure tunnel connectivity to the cloud GW. These enterprise
> SD-WAN edge devices accept connections not only from wireless APs, but also
> for the mobility traffic through SWGs/UPF. In the case of UE mobility
> traffic needs to land into large enterprise with a security aspects, the
> SD-WAN GW in the corporate network need to preserve that behavior for E2E
> security.
>
>
>
> Hope it clarifies. How the SD-WAN GW map the TN characteristics in
> non-mobility domain to maintain UE’s E2E traffic characteristics is being
> worked out, and would be submitted.
>
>
>
> Regards,
>
> Kausik
>
>
>
> --
>
> Uma C.
>
>
>
>
>
> Regards,
>
> Kausik
>
>
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Mon, 26 Oct 2020 17:44:18 -0700

Hi Kausik,

Many thanks for your clarification below.

in-line..

--
Uma C.

On Mon, Oct 26, 2020 at 12:48 PM Majumdar, Kausik <
[email-masked]> wrote:

> *From:* dmm <[email-masked]> *On Behalf Of * Uma Chunduri

> lost.

Ack. The case currently being handled is only for shared transport
perspective and security for all the traffic and not per particular set of
traffic.

> Specially if we look into SD-WAN deployments the security is the key

I see while this can be done from UE side E2E, you are seeking a network
solution with SST granularity, not only beyond UPF in the DN but also in
the mobility domain.

I think it would be good to expand the UDP Src Port range table captured in
> Figure 2. For all of the current SST types we could come up with different
> Range where E2E security is the key requirement for the UE traffic like
> below:
>

..

> So you may need this for all SSTs then. Sure, we can enhance this part
(after consulting with other co-authors).

Hope it clarifies.

Yes, it does. Thank you!

How the SD-WAN GW map the TN characteristics in non-mobility domain to
> maintain UE’s E2E traffic characteristics is being worked out, and would be
> submitted.
>
I have a few more questions and shall talk offline.

Regards,
Kausik