Re: [DMM] Presentation of https://datatracker.ietf.org/doc/draft-zzhang-bess-ipvpn-payload-only/

[Uma Chunduri]

"For example, PE1 can advertise a label for a (source, destination,

   IP/UDP payload type) tuple with the local semantics being that
   incoming traffic will be encapsulated in an IP or IP+UDP header and
   then routed out.  When PE2 receives IP or IP+UDP traffic from the
   UPF, if there is a label for the corresponding (source, destination,
   IP/UDP payload type) tuple, it removes the IP or IP/UDP headers and
   simply transport the remaining payload.  In this 5G scenario, it is
   still GTP - just that the IP/UDP headers are not present between PE1
   and PE2.

"

Very useful.

And this doesn't have to be tied to GTP overlays.  I would recommend
generalizing this (just keep the overlay header intact) - though you can
point to GTP as an example.
UDP might be needed for load balancing the traffic in the transport
network. So better to keep this intact.
UDP Src port (is one way) to encode the slicing information as specified in
https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility

Thx!
--
Uma C.

On Thu, Jul 28, 2022 at 6:08 PM Jeffrey (Zhaohui) Zhang  wrote:

> Hi,
>
> Due to a glitch the slides for the above draft were not available so it
> was not presented as planned in the DMM session in IETF114.
> However, it was presented in the BESS session and the following are the
> video recording and slides:
>
> https://youtu.be/V2r68JhrQag?t=660
>
> https://datatracker.ietf.org/meeting/114/materials/slides-114-bess-draft-zzhang-bess-ipvpn-payload-only-00
>
> The direct use case that triggered the draft is GTP-U transportation, so I
> hope it is of interest to this group. Appreciate your comments.
>
> Thanks.
> Jeffrey
>
> Juniper Business Use Only
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Dear All,

This is just a refresh (with affiliation changes and corrected references).

Appreciate further feedback/comments.

--
Uma C.



On Mon, Jul 11, 2022 at 3:20 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the
> IETF.
>
> Title   : Mobility aware Transport Network Slicing for 5G
>         Authors : Uma Chunduri
>   John Kaippallimalil
>   Sridhar Bhaskaran
>   Jeff Tantsura
>   Praveen Muley
>   Filename: draft-ietf-dmm-tn-aware-mobility-04.txt
>   Pages   : 24
>   Date: 2022-07-11
>
> Abstract:
>This document specifies a framework and mapping of slices in 5G
>mobile systems to transport network slices in IP, Layer 2 or Layer 1
>transport networks.  Slices in 5G systems are characterized by
>latency bounds, reservation guarantees, jitter, data rates,
>availability, mobility speed, usage density, criticality and
>priority.  These characteristics are mapped to transport network
>slice include bandwidth, latency and criteria such as isolation,
>directionality and disjoint routes.  Mobile slice criteria are 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 a mobile network slice is mapped to a
>slice in IP or Layer 2 transport network between 3GPP provisioning
>end points.  The same mapping mechanisms apply during initial UE
>session setup and following UE mobility.  Applicability of this
>framework and underlying transport networks, which can enable
>different slice properties are also discussed.  This is based on
>mapping between mobile and transport underlays (L2, Segment Routing,
>IPv6, MPLS and IPv4).
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-04
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-tn-aware-mobility-04
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Dear All,

Sligh changes in Section 1 wording by John & me to take care of a few
earlier open comments.

We again request chairs to link the individual draft (pre-IETF version of
this document) to track the disclosed IPRs.

--
Uma C.

On Sat, Mar 5, 2022 at 10:36 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the
> IETF.
>
> Title   : Mobility aware Transport Network Slicing for 5G
>     Authors : Uma Chunduri
>   John Kaippallimalil
>   Sridhar Bhaskaran
>   Jeff Tantsura
>   Praveen Muley
> Filename: draft-ietf-dmm-tn-aware-mobility-03.txt
> Pages   : 24
> Date: 2022-03-05
>
> Abstract:
>This document specifies a framework and mapping of slices in 5G
>mobile systems to transport network slices in IP, Layer 2 or Layer 1
>transport networks.  Slices in 5G systems are characterized by
>latency bounds, reservation guarantees, jitter, data rates,
>availability, mobility speed, usage density, criticality and
>priority.  These characteristics are mapped to transport network
>slice include bandwidth, latency and criteria such as isolation,
>directionality and disjoint routes.  Mobile slice criteria are 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 a mobile network slice is mapped to a
>slice in IP or Layer 2 transport network between 3GPP provisioning
>end points.  The same mapping mechanisms apply during initial UE
>session setup and following UE mobility.  Applicability of this
>framework and underlying transport networks, which can enable
>different slice properties are also discussed.  This is based on
>mapping between mobile and transport underlays (L2, Segment Routing,
>IPv6, MPLS and IPv4).
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-tn-aware-mobility-03
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Dear DMM WG,

Some of the recent discussions in DMM and routing areas regarding this
draft have been addressed in 01 and 02 versions.

Feel free to post your comments.  We (John K.)  will go over the updates in
the next IETF meeting.

Have a great day!
--
Uma C.

On Fri, Oct 22, 2021 at 2:23 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the
> IETF.
>
> Title   : Mobility aware Transport Network Slicing for 5G
>         Authors : Uma Chunduri
>   John Kaippallimalil
>   Sridhar Bhaskaran
>   Jeff Tantsura
>   Praveen Muley
> Filename: draft-ietf-dmm-tn-aware-mobility-02.txt
> Pages   : 24
> Date: 2021-10-22
>
> Abstract:
>This document specifies a framework and mapping of slices in 5G
>mobile systems to transport network slices in IP, Layer 2 or Layer 1
>transport networks.  Slices in 5G systems are characterized by
>latency bounds, reservation guarantees, jitter, data rates,
>availability, mobility speed, usage density, criticality and
>priority.  These characteristics are mapped to transport network
>slice include bandwidth, latency and criteria such as isolation,
>directionality and disjoint routes.  Mobile slice criteria are 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 a mobile network slice is mapped to a
>slice in IP or Layer 2 transport network between 3GPP provisioning
>end points.  The same mapping mechanisms apply during initial UE
>session setup and following UE mobility.  Applicability of this
>framework and underlying transport networks, which can enable
>different slice properties are also discussed.  This is based on
>mapping between mobile and transport underlays (L2, Segment Routing,
>IPv6, MPLS and IPv4).
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-tn-aware-mobility-02
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] What is the slice ID in MBH?

[Uma Chunduri]

Hi Eduard,

Sorry, couldn't respond to this earlier (my email filters put this into a
different bucket!)

In-line [Uma]:

--
Uma C.

On Thu, Aug 19, 2021 at 2:43 AM Vasilenko Eduard <
vasilenko.edu...@huawei.com> wrote:

> Hi Uma,
>
> Just SRH itself maybe 216B:
>
> +  40B additional IPv6 basic header
>
> +  16B SRH itself
>
> +  16B*10 SIDs
>
> Compressed SID should cut it to something like 108B:
>
> +  40B additional IPv6 basic header
>
> +  16B SRH itself
>
> +  4B*10 SIDs (the last one would be 16B anyway)
>
>
>
> After this would be 40B of original IPv6
>
> And only then 8B UDP.
>
> It means that even after compressed SID adoption UDP could cross 128B
> (156B for 10*SIDs compressed).
>
> From one point of view 10*SIDs look like a rear case in MBH, but from
> another point of view compressed SID is assumed for 16*SIDs as the design
> goal.
>
>
>
[Uma]: Your math is absolutely spot-on. But you are missing the key point I
indicated earlier.
Today there is no 3GPP spec indicating UP function (gNB..)
should be emitting transport headers and topology related information like
SRH and MPLS. On the contrary gNB
 doesn't want to know anything about transport paths, TE and
topology etc,.
 So I am not sure I would worry about this scenario at all.

 If iOAM or ordinary fragmentation would happen – it would be an additional
challenge to parse.


>
> Hence, slice ID buried so deep into the packet make sense only on the 1st
> hop from the 3GPP node with the goal: to duplicate it into something close
> to the packet head.
>
> If some 3GPP node would merge with PE then lookup for UDP would be
> extremely difficult, hence built-in PE should remap Slice ID to something
> close to the packet head.
>
>
>
> IETF needs to discuss Slice ID position/indicator that would be convenient
> for the data plane and many other WGs should agree on it.
>
> It is desirable for 3GPP and IP nodes to have the common/unified Slice ID
> indicator.
>
[Uma]: Yes. But we can separate what needs to be done at the edge nodes
(PEs) and what needs to be done at the cellular end points
(GNB/DU/CU/PSA-UPF, UPF etc.)
 You would quickly get into unnecessary complications for
existing operators (managing cellular part of the network and transport
part of the network, I am not talking about a
 shared transport network serving multiple cellular providers)..


> Because it is better if the Slice ID field could be just copied than
> filtered by UDP port range (additional complexity).
>
> Discussion for what to use for Slice ID on the 1st hop from the 3GPP node
> is needed too but it should be accompanied by the discussion for what to
> use for Slice ID in MBH in general (on other hops).
>
> I am surprised that it is missing anywhere in IETF.
> draft-ietf-dmm-tn-aware-mobility-00
> <https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-00> 
> looks
> a good place for such discussion but I may be wrong – maybe another WG is
> better.
>
>
>
[Uma]: This draft discussed all possible options in IETF 105 and IETF 106
to settle down at where we are.
Also not there are L2 network segments in the F1U interface
(DU-CU) and all sorts of transport today in N3/S1U (IPv4, IPv6, MPLS and
SRH). So this factored into the decisions made.



> PS: Small reminder (probably you know):
>
> There is a policy in IPv6 primary RFC 8200 that EHs should not be changed
> in transit. Hence, any new functionality (like SRH or iOAM) is only
> possible by tunneling (additional IPv6 header).
>
> It means that whatever 3GPP node would signal (even if it would be more
> convenient than UDP port range) – it would be buried deep into the packet.
>
[Uma]: Please see again above (or the link in my original response). We are
happy to extend the headers in L3/L2.5 if 3GPP approves the same.



> Hence, slice ID on the link to the 3GPP node and slice ID inside the MBH
> should be different instances, unfortunately.
>
>
>
> Eduard
>
> *From:* Uma Chunduri [mailto:umac.i...@gmail.com]
> *Sent:* Thursday, August 19, 2021 4:29 AM
> *To:* Vasilenko Eduard 
> *Cc:* Majumdar, Kausik ; RTGWG <
> rt...@ietf.org>; Dongjie (Jimmy) 
> *Subject:* Re: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility
> draft
>
>
>
>
>
>
>
> I have read draft-ietf-dmm-tn-aware-mobility-00
>
> And I am not happy that IPv6 was not accounted for as the possible
> infrastructure data plane.
>
> Because IPv6 has a lot of functionality packed inside EHs, it would create
> a big problem to use Slice ID buried so deep into the packet (UDP source
> port offset could easily cross 128B).
>
&g

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Uma Chunduri]

Dear Dave,

I got what you are saying.

>The sorts of features we are seeing in the larger 3GPP picture AFAIK are
more recent additions for URLLC, CIoT etc.
>So picking and choosing based on convenience is not an option; the problem
space is not a matter of choosing what to support,
>but in replicating the functionality exists and having similar
extensibility.


In this particular case, I am afraid we can even take that kind of
undertaking to create a complete "Stunt Double" as you put it.  I also
believe this is not under the purview of IETF and inevitably we intervene
with their control plane procedures to create this kind of framework.

I still believe we ought to develop value addition functionalities in
the transport network layer, applicable to these deployments which brings a
better E2E service. At the end of the day neither a packet traversing the
network doesn't know which SDO owns this nor the end user consuming the
service.

This is a generic comment and I am not implying to any particular work
being done here.


BR!
--
Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Additional questions/comments on draft-ietf-dmm-srv6-mobile-uplane-13

[Uma Chunduri]

Hi Dave,

Very good list and I am sure there could be a bit more functionalities GTP
overlay  has been supporting over a period of time *and* still currently
being used in various parts of the cellular networks.

Replacing overlays may be a good goal if we can bring the same technical
benefits different underlays (L2, L2.5, IPv4, IPv6) bring to the table in
various parts of the networks, in this case cellular deployments. We(IETF)
should develop tools towards the objective but I suspect we are there to
replace any overlay (if this is the central goal) with a single underlay
mechanism. Dino presented multiple times on this topic in various
WGs/pre-bofs/BoFs and also asked to "get over with it" (a thin overlay).

One of the things that we all should ask ourselves is - what overlay
functionalities we want to bring to underlay (L3/L2.5) as opposed to
complete replacement of the overlay. IMO, this is a better question than
"replacing".

Appreciate your thoughts and views on this.

Thank you!
--
Uma C.



On Fri, Jul 23, 2021 at 10:50 AM David Allan I  wrote:

> Hi:
>
> Looking over this draft it strikes me that IF you are discussing a GTP
> replacement, there are a few unaddressed gaps...or at least I see no
> mention of them.
>
> -  adding X2 to the list of interfaces to be supported
> -  support for end-marker for handoff stream synchronization (probably
> could fit the unused bit in Args.Mob.Session but frankly I have not studied
> this in detail)
> -  support for QMP (quality measurement protocol), which I believe needs
> to also extend across the radio interface so is not simply local to the GTP
> domain and can be "stunt doubled"
> -  support for paging policy presence/indication
>
> If this has come up elsewhere, let me know
>
> Cheers
> Dave
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Dear Chairs & All,

This version has yet to address a couple of TBD comments during WG adoption
and bit before. Authors would be taking care of those soon.

Thanks for all here and looking forward to improving this further.

--
Uma C.


On Tue, Mar 9, 2021 at 8:37 AM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Distributed Mobility Management WG of the
> IETF.
>
> Title   : Transport Network aware Mobility for 5G
>     Authors : Uma Chunduri
>   John Kaippallimalil
>   Sridhar Bhaskaran
>   Jeff Tantsura
>   Praveen Muley
> Filename: draft-ietf-dmm-tn-aware-mobility-00.txt
> Pages   : 24
> Date: 2021-03-08
>
> Abstract:
>This document specifies a framework and mapping from slices in 5G
>mobile systems to transport slices in IP, Layer 2 and Layer 1
>transport networks.  Slices in 5G systems are characterized by
>latency bounds, reservation guarantees, jitter, data rates,
>availability, mobility speed, usage density, criticality and
>priority.  These characteristics should be mapped to the transport
>network 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 and Layer 2 packets that transport
>network segments use to grant transport layer services during UE
>mobility scenarios.  Applicability of this framework and underlying
>transport networks, which can enable different slice properties are
>also discussed.  This is based on mapping between mobile and
>transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4).
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dmm-tn-aware-mobility-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility-00
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] Fwd: New Version Notification for draft-clt-dmm-tn-aware-mobility-09.txt

[Uma Chunduri]

Dear All,

This update covers the comments received related to TEAS work reference (in
the list and off the list).

Please review & comment and we will continue to improve this further (with
other TBDs, after the adoption call concludes).

--
Uma C. (on behalf of all co-authors).

-- Forwarded message -
From: 
Date: Fri, Feb 12, 2021 at 5:07 PM
Subject: New Version Notification for draft-clt-dmm-tn-aware-mobility-09.txt
To: Luis M. Contreras , Jeff
Tantsura , John Kaippallimalil <
john.kaippallima...@futurewei.com>, Praveen Muley ,
Richard Li , Sridhar Bhaskaran <
sridh...@altiostar.com>, Uma Chunduri 



A new version of I-D, draft-clt-dmm-tn-aware-mobility-09.txt
has been successfully submitted by Uma Chunduri and posted to the
IETF repository.

Name:   draft-clt-dmm-tn-aware-mobility
Revision:   09
Title:  Transport Network aware Mobility for 5G
Document date:  2021-02-12
Group:  Individual Submission
Pages:  24
URL:
https://www.ietf.org/archive/id/draft-clt-dmm-tn-aware-mobility-09.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-09
Diff:
https://www.ietf.org/rfcdiff?url2=draft-clt-dmm-tn-aware-mobility-09

Abstract:
   This document specifies a framework and mapping from slices in 5G
   mobile systems to transport slices in IP, Layer 2 and Layer 1
   transport networks.  Slices in 5G systems are characterized by
   latency bounds, reservation guarantees, jitter, data rates,
   availability, mobility speed, usage density, criticality and
   priority.  These characteristics should be mapped to the transport
   network 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 and Layer 2 packets that transport
   network segments use to grant transport layer services during UE
   mobility scenarios.  Applicability of this framework and underlying
   transport networks, which can enable different slice properties are
   also discussed.  This is based on mapping between mobile and
   transport underlays (L2, Segment Routing, IPv6, MPLS and IPv4).





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
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Teas] draft-ietf-teas-ietf-network-slice-definition-00

[Uma Chunduri]

Hi Reza,

Many thx for your reply.

See a quick response in-line.

--
Uma C.

On Fri, Feb 12, 2021 at 6:46 AM Rokui, Reza (Nokia - CA/Ottawa) <
reza.ro...@nokia.com> wrote:

> Hi Uma,
>
> The comments are inlined.
>
>
>
> Reza
>
>
>
>
>
>
>
> *From: *Teas  on behalf of Uma Chunduri <
> umac.i...@gmail.com>
> *Date: *Thursday, February 11, 2021 at 7:26 PM
> *To: *TEAS WG 
> *Cc: *dmm 
> *Subject: *[Teas] draft-ietf-teas-ietf-network-slice-definition-00
>
>
>
> Dear All,
>
>
>
> 2 questions on this draft:
>
>
>
> 1.
>
> Section 4.2 defines 'IETF Network Slice endpoints'
>
>
>
> It Says -
>
>
>
> " o They are conceptual points of connection of a consumer network,
>
>   network function, device, or application to the IETF network
>
>   slice.  This might include routers, switches, firewalls, WAN,
>
>   4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep
>
>   Packet Inspection (DPI), server load balancers, NAT44 [RFC3022 
> <https://tools.ietf.org/html/rfc3022>],
>
>   NAT64 [RFC6146 <https://tools.ietf.org/html/rfc6146>], HTTP header 
> enrichment functions, and TCP
>
>   optimizers."
>
>
>
>
>
> I presume 4G/5G RAN nodes, you meant eNB, gNB-DU, gNB-CU-UP etc. If yes,
>
> there was a question from one of the 3GPP delegates on how this can be called 
> as
>
> 'IETF Network Slice Endpoint'?
>
>
>
> [Reza] Yes 4G/5G RAN nodes means eNB, gNB-DU, gNB-CU-UP etc. However, the 
> fundamental aspect to be considered for IETF Network Slice is that it is 
> technology-agonistic.
>
> Note that also that RAN nodes for example have two logical components; Radio 
> components and transport component. The IETF Network Slice addresses the 
> connectivity from *Transport component of RAN*
>
>  (which in today’s technology it is the data-path) to other endpoints. It is 
> called 'IETF Network Slice Endpoint' because user’s traffic starts from this 
> entry point.
>
> * [Uma]: Indeed and  in all these cases i.e., between DU-CU, gNB-UPF or
eNB-SGW, SGW-PGW, UPF-UPF the packet emitted would be UDP/IP packet
encapsulating the user payload with the overlay header. But just because it
is emitting the IP packet we might not want to rename these as  'IETF
Network Slice Endpoint'.  As we are speaking about this particular use case
in the document, let me say I clearly got feedback that: from the 3GPP
point of view only UE and UPF are the slice endpoints and all the nodes in
between RAN, PE nodes  etc., are slice realization endpoints. So we are a
bit off here w.r.t terminology for this use case and this would be
indicated as such in the update to be made
https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08
<https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08>. So my
sincere suggestion would be to use terms neutral as you agreed on the other
thread.*

>
>
> I guess, we ought to be cognizant when we tag 'IETF' for some of
>
> these definitions.
>
>
>
> The above also mentions 4G/5G Core nodes aka SGW/PGW/all-variants-of-UPFs and
>
> these are again not typically 'IETF Network Slice Endpoints'.
>
> [Reza] As mentioned above the 'IETF Network Slice  and 'IETF Network Slice 
> Endpoint are technology-agnostics. In draft these nodes are are called DAN 
> (Device, Application, NF)
>
> which shows its true technology-agnostics.
>
> *[Uma]: Agree and that aspect clearly specified in the document. *

>
>
> Could you please give your thoughts here?
>
> [Reza]
>
>
>
> 2.
>
>
>
> Section 1 says
>
>
>
> "IETF network slices are created and managed within the scope of one
>
>or more network technologies (e.g., IP, MPLS, optical). :
>
>
>
>
>
> Obviously, optical is a bigger topic and if we talk about optical solutions 
> like
>
> OTN (Layer 1)  and SPN (Layer 1.5) are more controlled by other SDOs. SPN has
>
> a complete slicing solution with not much bearing to IETF.
>
>
>
> So, could you please expand 'optical' in the list above? Is it the  various 
> optical control plane
>
> specifications done here, you were referring to?
>
>
>
> --
>
> Uma C.
>
>
>
>
>
>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

[DMM] draft-ietf-teas-ietf-network-slice-definition-00

[Uma Chunduri]

Dear All,

2 questions on this draft:

1.
Section 4.2 defines 'IETF Network Slice endpoints'

It Says -

" o They are conceptual points of connection of a consumer network,

  network function, device, or application to the IETF network
  slice.  This might include routers, switches, firewalls, WAN,
  4G/5G RAN nodes, 4G/5G Core nodes, application acceleration, Deep
  Packet Inspection (DPI), server load balancers, NAT44 [RFC3022
],
  NAT64 [RFC6146 ], HTTP
header enrichment functions, and TCP
  optimizers."



I presume 4G/5G RAN nodes, you meant eNB, gNB-DU, gNB-CU-UP etc. If yes,

there was a question from one of the 3GPP delegates on how this can be
called as

'IETF Network Slice Endpoint'?


I guess, we ought to be cognizant when we tag 'IETF' for some of

these definitions.


The above also mentions 4G/5G Core nodes aka SGW/PGW/all-variants-of-UPFs and

these are again not typically 'IETF Network Slice Endpoints'.


Could you please give your thoughts here?


2.


Section 1 says


"IETF network slices are created and managed within the scope of one

   or more network technologies (e.g., IP, MPLS, optical). :



Obviously, optical is a bigger topic and if we talk about optical
solutions like

OTN (Layer 1)  and SPN (Layer 1.5) are more controlled by other SDOs. SPN has

a complete slicing solution with not much bearing to IETF.


So, could you please expand 'optical' in the list above? Is it the
various optical control plane

specifications done here, you were referring to?


--

Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core

[Uma Chunduri]

Hi Sridhar, Xuesong,

Quick thoughts below [Uma]:

--
Uma C.

On Sun, Jan 31, 2021 at 8:42 PM Sridhar Bhaskaran <
sridhar.bhaska...@gmail.com> wrote:

> Hi Gengxuesong,
>
> On,
>
> >> Maybe the existing question becomes whether DSCP is sufficient for
> passing information from the mobile network to transport network? whether
> there is any simplification or omission of information in the mapping to
> the DSCP?
>

[Uma]: First of all, a lot of discussion below was discussed during 04
version of https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08.
It was presented by John in one the IETF DMM sessions that time.  And yes,
it was limiting and moreover a lot of implementations reset DSCP bits in
the shared transport scenarios (like WAN  scenario).

>
>
> 3GPP allows mapping of a GTP-u tunnel (PDU session) to an index to a
> transport network configuration / policy via "Network Instance" concept.
> When the GTP-u tunnel is setup in the UPF by the signalling plane, it
> provides a "Network Instance" which is just a string that acts as an index
> into UPF's transport layer configuration.
>

[Uma]:  Right and that's natural as overlay is processed at the tunnel
endpoints (gNB/PSA-UPF/ULCL-UPF/BP-UPF).


> Now what the transport layer configuration is - 3GPP doesn't care as it is
> out of their remit. If you are using just plain IP routing, then DSCP (for
> IPv4) and Flow label (IPv6) are the options to map a QFI within a GTP-u
> tunnel to IP transport. However if you are using - say a source routing
> technology like SRv6, you may potentially configure the UPF to map a slice
> (PDU session / TEID) and QFI to a specific SID list. If you use PPR
> (Preferred path routing), then MTCN-ID is an option.
>

[Uma]: I am afraid this may not be possible in all scenarios for example
gNB may not be knowing the all underlying transport information to encode
that way. However, if 5G-AN node is integrated with the PE this is a
possibility. Another possibility is SRv6 user plane where interoperability
scenarios  and overall user plane are described in
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-09

>
> Also note that on the N3 interface between UPF and gNB, if it is going to
> traverse a public network, operators would employ IPSec tunneling for
> security. So any markings at the transport protocol layer (e.g. UDP source
> port) will not be visible to on path routers due to IPSec. In such a case,
> the mapping of Slice (PDU Session / TEID) and QFI should be to the outer IP
> header in the IPSec tunnel. This is where a solution at IP header level
> helps (e.g DSCP / flow label / SID list)
>

[Uma]: Or one can use
https://tools.ietf.org/html/draft-xu-ipsecme-esp-in-udp-lb-07 (note RFC
3948 UDP encap only for nat traversal scenarios)

>
> Regards
> Sridhar
>
> On Mon, Feb 1, 2021 at 8:10 AM Gengxuesong (Geng Xuesong) <
> gengxues...@huawei.com> wrote:
>
>> Hi Sridhar,
>>
>>
>>
>> Thanks for your explanation. It is much clearer for me as the following:
>>
>> ž   UPF < - GTP-u tunnel [PDU session]-- > gNB
>>
>> ž   PDU session contains multiple QoS flows [QFI marker->5QI]
>>
>> ž   QFI marker in GTP-u extension header
>>
>> 5QI is not in GTP-u header directly but could be indicated by QFI. So the
>> QoS requirements presented by 5QI can’t be used/seen by transport network
>> in the existing in the current implementation (TEID is similar). And DSCP
>> can act as a mediator between transport network and UPF/gNB.
>>
>> Maybe the existing question becomes whether DSCP is sufficient for
>> passing information from the mobile network to transport network? whether
>> there is any simplification or omission of information in the mapping to
>> the DSCP?
>>
>>
>>
>> Best
>>
>> Xuesong
>>
>>
>>
>>
>>
>> *From:* Apn [mailto:apn-boun...@ietf.org] *On Behalf Of *Sridhar
>> Bhaskaran
>> *Sent:* Friday, January 29, 2021 8:06 PM
>> *To:* Gengxuesong (Geng Xuesong) 
>> *Cc:* a...@ietf.org; Uma Chunduri ; Kaippallimalil
>> John ; dmm ; Lizhenbin <
>> lizhen...@huawei.com>
>> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core
>>
>>
>>
>> Hi Gengxuesong,
>>
>>
>>
>> QFI (mapped to 5QI) and TEID are to identify QoS flows and PDU sessions
>> within UPF and gNB. They are not meant for transport network to look into.
>> UPF and gNB map QFI to DSCP marking in the outer IP header which the
>> transport network can use for differentiated services.
>>
>>
>>
>> Regards
>>
>> Sridhar
>>
>>
>

Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document - Objections

[Uma Chunduri]

Dear All,

As suggested by WG chairs, we would like to spin one more version to
address the comments during the adoption call and in that process will
reach out to Joel and Hannu (separately)  for specific inputs where
terminology alignment has to happen w.r.t TEAS slicing definition draft.

Will keep you updated on the WG soon.
--
Uma C.

On Wed, Jan 6, 2021 at 2:40 PM Joel M. Halpern  wrote:

> In line,
> Joel
>
> On 1/6/2021 5:29 PM, Kaippallimalil John wrote:
> > Joel,
> > This draft is not attempting to lay out a new architecture. The figure
> and architecture section are there to provide context for the reader.
> >
> > The draft is also not asserting that these are the only ways to solve
> the issue.
> > The last portion of the draft only refers to applicability since several
> IETF technology (and even non IETF data plane like L2) may be used E2E in
> the transport underlay corresponding to a 3GPP overlay (F1/W1, N3, N9).
> > The draft is agnostic to any specific underlay. It is concerned with how
> the slice type/QoS properties between 3GPP provider and subscriber (UE) is
> realized as the data plane GTP packets (overlay) traverse one or more
> transport underlay segments on path.
>
> At the veyr least, the draft needs significant rewording so taht it
> clealry explains what you are saying here.  As currently worded, it does
> not lead the reader to that understanding.  And as such, calls into
> doubt what the supporters of adoption believe they are adopting.
>
> >
> > The dmm working group seems to be a natural choice as folks there have
> background and expertise in both IETF and 3GPP technologies.
>
> A WG looking like "the natural place" for something does not mean that
> said working group actually has the given work in its charter. For
> example, there were quite a number of drafts which were presented in the
> SFC WG as the natural place for initial discussion, but which did not
> fit within the SFC charter and therefore were not adopted by SFC as work
> items.
>
> >
> > Best Regards,
> > John
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document

[Uma Chunduri]

Hi Jie,

In-line ..

--
Uma C.
On Wed, Jan 20, 2021 at 5:22 PM Dongjie (Jimmy)  wrote:

> Dear Chairs,
>
>
>
> Sorry for the late reply.
>
>
>
> After reading this document and the discussion on the list, I also think
> some alignment with the TEAS working group on the definition, terminology
> and framework of network slice would be helpful.
>
[Uma]: I supported and gave my suggestions on the TEAS WG definitions draft
(where the adoption call for the same ended 2 days ago there). Though there
were few opinions, it seems 'IETF Network Slice' terminology may not be
changed as a lot of debate happened on that name and it was also being
chosen to differentiate  the scope from other SDOs (working on various
aspects of slicing in general). In any case, as mentioned earlier wherever
applicable we will use the terminology (of course, agreeable to this WG).


> As for the technical aspects, to my understanding this document proposes a
> mechanism to provide the transport path information to the mobile network
> endpoints, which IMO may also be used in networks without network slicing.
>
[Uma]: I am not sure why you get that understanding. Could you please
elaborate on what caused you to prompt that understanding. AFAIS, that is
not the case. Thx!

> If this understanding is correct, I’d suggest to clarify the relationship
> between the proposed mechanism and the network slicing use case.
>
>
>
> Best regards,
>
> Jie
>
>
>
> *From:* dmm [mailto:dmm-boun...@ietf.org] *On Behalf Of *Sri Gundavelli
> (sgundave)
> *Sent:* Thursday, January 21, 2021 2:43 AM
> *To:* dmm 
> *Subject:* Re: [DMM] Call for adoption of
> draft-clt-dmm-tn-aware-mobility-08 as a WG document
>
>
>
> Thank you all. This adoption call is now closed. We will review the
> feedback.
>
>
>
> -  Chairs
>
>
>
>
>
> *From: *dmm  on behalf of "Sri Gundavelli
> (sgundave)" 
> *Date: *Thursday, January 14, 2021 at 10:56 AM
> *To: *dmm 
> *Subject: *Re: [DMM] Call for adoption of
> draft-clt-dmm-tn-aware-mobility-08 as a WG document
>
>
>
> Gentle reminder.
>
>
>
> This adoption call with expire on 18th Jan. Please provide your feedback.
>
>
>
> Just to structure the discussion, we want to understand a.) if the WG
> agrees with the problem statement and is relevant for mobility working
> group, b.) is the proposed solution/approach is a reasonable approach, and
> if it is a good starting point
>
>
>
> On the comments on where this work needs to happen etc , feedback is
> welcome but I would not worry too much about that now. Let’s agree upon the
> problem statement first and focus more on the technical aspects. If this is
> a valid problem, we can always decide to do that work here, or in some
> other group and that’s based on AD/Chair inputs and  on the review
> expertise that is needed for this work completion.
>
>
>
> -Chairs
>
>
>
>
>
>
>
>
>
>
>
> *From: *dmm  on behalf of "Sri Gundavelli
> (sgundave)" 
> *Date: *Wednesday, December 30, 2020 at 10:45 AM
> *To: *dmm 
> *Subject: *[DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08
> as a WG document
>
>
>
> Folks:
>
>
>
> The authors of the document, Transport Network aware Mobility for 5G, have
> presented the proposal and the need for standardization in multiple IETF WG
> meetings. There have been good amount of discussions in the mailers and
> there is some level of interest for the work from the community. We are
> therefore considering the adoption of this document as a DMM WG document,
> to be moved on Informational Standards track.
>
>
>
> *Transport Network aware Mobility for 5G*
>
> https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08
>
>
>
>
>
> With this background, we would like to ask the WG to provide some feedback
> on their interest for this work. Please provide substantial comments as why
> this SHOULD be adopted, or why it SHOULD NOT be adopted. If there is
> interest, and if there are no other concerns from AD/IESG/Others, then we
> may take up this work.
>
>
>
> The adoption call will end on 18th of January, 2021.
>
>
>
> Regards
>
> DMM WG Chairs
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core

[Uma Chunduri]

Indeed & it's better to disambiguate sooner if APN@IETF folks are seeking
to work with cellular domain in general.

--
Uma C.

On Mon, Jan 18, 2021 at 12:27 PM David Lake  wrote:

> Hi
>
>
>
> EEK!   This could be a problem then if we have TWO definitions of APN….
>
>
>
> David
>
>
>
> *From:* Uma Chunduri 
> *Sent:* 18 January 2021 20:26
> *To:* Lake, David (PG/R - Elec Electronic Eng) 
> *Cc:* Lizhenbin ; a...@ietf.org; dmm 
> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core
>
>
>
> Hi David,
>
>
>
> Many excellent points below w.r.t GTP-u and the Access Point Name (APN)
> which defines the network path for all cellular data connectivity.
>
>
>
> However, I presume Robin was referring to a different APN -
> https://datatracker.ietf.org/wg/apn/about/
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fapn%2Fabout%2F=04%7C01%7Cd.lake%40surrey.ac.uk%7C607b41fb513c48c361f908d8bbef44ae%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637465983616671466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=i%2Fou%2ByUAzdg5kIL1N2sdXlCLM41q%2BWSnBc9lymZbgNo%3D=0>
>
>
>
>
> --
>
> Uma C.
>
>
>
> On Mon, Jan 18, 2021 at 12:10 PM David Lake  wrote:
>
> The APN provides the linkage between the application profile and the radio
> bearers.  GTP-u is manner by which the traffic is tunnelled to the anchor
> point and you MAY end up with different end points for each of the GTP
> bearers.
>
>
>
> Traffic at both the UE and the PGW (in LTE – UPF in 5G) are directed to
> the correct APN by a Traffic Flow Template (TFT).  This is to ensure that
> traffic goes across both the correct radio bearer and is marked correctly
> in the IP network.
>
>
>
> Users will often be unaware of multiple APNs on their UE; the most common
> hidden APN is one for VoLTE which, with the use of the TFT, will ensure
> that the VoIP frames (media) are put across the QCI 9 radio bearer and into
> the correct class on the IP network.  QCI 9 maps to a specific numerology
> on the Air Interface so that quality can be maintained for the voice call.
>
>
>
> In theory, multiple APNs all with their own TFT rules and potentially
> multiple GTP-u tunnels could be used but this is very rarely done.
>
>
>
> David
>
>
>
> *From:* Apn  *On Behalf Of *Uma Chunduri
> *Sent:* 18 January 2021 19:17
> *To:* Lizhenbin 
> *Cc:* a...@ietf.org; dmm 
> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core
>
>
>
> Hi Robin,
>
>
>
> In-line..
>
>
>
> Cheers!
> --
>
> Uma C.
>
>
>
> On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin  wrote:
>
> Hi APNers and DMMers,
>
> I remember that in the mobile core scenarios the GTP-u tunnel can be set
> up according to the user and application requirements, but I do not
> understand the details.
>
>
>
> [Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uou
> should look into
> https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-5g-uplane-analysis%2F=04%7C01%7Cd.lake%40surrey.ac.uk%7C607b41fb513c48c361f908d8bbef44ae%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637465983616671466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=d1al4%2Fco3GeSDbG5EMXSZU7q35vFm%2BFv5sA4WnzTpos%3D=0>
> where lot more details and other references related this topic was analyzed
> (primarily started after/during REL-15, when  any other use plane other
> than GTP-U is worthwhile is debated for 5G N9 interface).
>
>
>
> I think when the packet tunneled by GTP-u traverses the APN-based
> transport network, it may be mapped to the corresponding tunnel according
> to the user and application requirements to implement the uniform service.
> If you are familiar with the principle of GTP-u in the mobile core, please
> help provide some details.
>
>
>
>
>
> Best Regards,
>
> Zhenbin (Robin)
>
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm=04%7C01%7Cd.lake%40surrey.ac.uk%7C607b41fb513c48c361f908d8bbef44ae%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637465983616681466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=Rr%2FLGzBbK%2FK0qdUeDoizGiWzS7LWWHIxsBodhu6ScLI%3D=0>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Apn] Regarding APN Usecase in Mobile Core

[Uma Chunduri]

Hi David,

Many excellent points below w.r.t GTP-u and the Access Point Name (APN)
which defines the network path for all cellular data connectivity.

However, I presume Robin was referring to a different APN -
https://datatracker.ietf.org/wg/apn/about/

--
Uma C.

On Mon, Jan 18, 2021 at 12:10 PM David Lake  wrote:

> The APN provides the linkage between the application profile and the radio
> bearers.  GTP-u is manner by which the traffic is tunnelled to the anchor
> point and you MAY end up with different end points for each of the GTP
> bearers.
>
>
>
> Traffic at both the UE and the PGW (in LTE – UPF in 5G) are directed to
> the correct APN by a Traffic Flow Template (TFT).  This is to ensure that
> traffic goes across both the correct radio bearer and is marked correctly
> in the IP network.
>
>
>
> Users will often be unaware of multiple APNs on their UE; the most common
> hidden APN is one for VoLTE which, with the use of the TFT, will ensure
> that the VoIP frames (media) are put across the QCI 9 radio bearer and into
> the correct class on the IP network.  QCI 9 maps to a specific numerology
> on the Air Interface so that quality can be maintained for the voice call.
>
>
>
> In theory, multiple APNs all with their own TFT rules and potentially
> multiple GTP-u tunnels could be used but this is very rarely done.
>
>
>
> David
>
>
>
> *From:* Apn  *On Behalf Of *Uma Chunduri
> *Sent:* 18 January 2021 19:17
> *To:* Lizhenbin 
> *Cc:* a...@ietf.org; dmm 
> *Subject:* Re: [Apn] [DMM] Regarding APN Usecase in Mobile Core
>
>
>
> Hi Robin,
>
>
>
> In-line..
>
>
>
> Cheers!
> --
>
> Uma C.
>
>
>
> On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin  wrote:
>
> Hi APNers and DMMers,
>
> I remember that in the mobile core scenarios the GTP-u tunnel can be set
> up according to the user and application requirements, but I do not
> understand the details.
>
>
>
> [Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uou
> should look into
> https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-5g-uplane-analysis%2F=04%7C01%7Cd.lake%40surrey.ac.uk%7C984c8fa55bbf4ea5b98908d8bbe5aa2d%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637465942368442430%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=namC6OofWdMQvTEjFwNkZT0ornR2gx1Q%2BV8SXxIHUis%3D=0>
> where lot more details and other references related this topic was analyzed
> (primarily started after/during REL-15, when  any other use plane other
> than GTP-U is worthwhile is debated for 5G N9 interface).
>
>
>
> I think when the packet tunneled by GTP-u traverses the APN-based
> transport network, it may be mapped to the corresponding tunnel according
> to the user and application requirements to implement the uniform service.
> If you are familiar with the principle of GTP-u in the mobile core, please
> help provide some details.
>
>
>
>
>
> Best Regards,
>
> Zhenbin (Robin)
>
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
> <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdmm=04%7C01%7Cd.lake%40surrey.ac.uk%7C984c8fa55bbf4ea5b98908d8bbe5aa2d%7C6b902693107440aa9e21d89446a2ebb5%7C0%7C0%7C637465942368452424%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=00LmTEJXUJZfwFAMcs5abdCXTBvrrVSEMFeykW175u8%3D=0>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Regarding APN Usecase in Mobile Core

[Uma Chunduri]

Hi Robin,

In-line..

Cheers!
--
Uma C.

On Mon, Jan 18, 2021 at 5:25 AM Lizhenbin  wrote:

> Hi APNers and DMMers,
>
> I remember that in the mobile core scenarios the GTP-u tunnel can be set
> up according to the user and application requirements, but I do not
> understand the details.
>

[Uma]: Obviously, the best reference for GTP-U is TS 29.281. However, uou
should look into
https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/ where
lot more details and other references related this topic was analyzed
(primarily started after/during REL-15, when  any other use plane other
than GTP-U is worthwhile is debated for 5G N9 interface).


> I think when the packet tunneled by GTP-u traverses the APN-based
> transport network, it may be mapped to the corresponding tunnel according
> to the user and application requirements to implement the uniform service.
> If you are familiar with the principle of GTP-u in the mobile core, please
> help provide some details.
>

>
>
>
> Best Regards,
>
> Zhenbin (Robin)
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document

[Uma Chunduri]

Hi Joel,

I would let John reply to you further , but a quick comment:

--
Uma C.

On Tue, Jan 5, 2021 at 2:40 PM Joel Halpern Direct <
jmh.dir...@joelhalpern.com> wrote:

> It is quite hard for me to understand what is itnended due to the
> terminology differences.  It would be helpful before adoption if there
> were better alignment.
>

[Uma]:  As I noted in the other response, I am afraid, even the latest
change in terminology from 'Transport Slice' to 'IETF Network Slice'  (
https://tools.ietf.org/html/draft-nsdt-teas-ietf-network-slice-definition-02
)
 may not capture  the full scope here.

>
> Also, clarity as to whether we are discussing the service interface (how
> to map the 3GPP needs to the services defined by the IETF network
> slicing abstraction) or the de3livery mechanisms (how to use various
> IETF technologies to deliver the services defined by the abstractions
> and mapped to the 3GPP structures.


[Uma]: Obviously not the delivery mechanisms as you noted it can cross many
WGs from
LSR (for routing), TEAS, PCE (for related-TE stuff),  or RTGWG (IP fast
reroute) to data plane (6Man, Spring, MPLS etc).


> I would not expect DMM to need to
> get into how to map to the mechanisms,


[Uma]: I am not sure why. We saw this is the most appropriate place when we
started this work way back in 2018 (00 version, predates TEAS slicing
design team started with a wider scope for generic slicing), given the
mobility domain expertise and  many 3GPP/IETF related items being  worked
out here
like -
   a. 3GPP User plane work
https://datatracker.ietf.org/doc/draft-ietf-dmm-5g-uplane-analysis/
   b. SR work which can co-exist with GTP based 3GPP user
plane and vatious inter-working scenarios in
https://datatracker.ietf.org/doc/draft-ietf-dmm-srv6-mobile-uplane/
   c. While, not directly related to this sub-opic, another
important work like
https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/

Again, as you pointed out TEAS has produced many pioneering works
applicable here are already being referred here and make sure to align in
future  wherever applicable.

Many Thx,
--
Uma C.

as that is an ever-evolving
> domain and one that is dealt with by the various domain WGs (TEAS, MPLS,
> SPRING, ...)
>
> Yours,
> Joel
>
> On 1/5/2021 5:33 PM, Kaippallimalil John wrote:
> > Joel,
> > Commenting as an author:
> > I too agree that the draft should use terminology on transport and
> slicing that TEAS defines so that there is consistency. We can either add
> it in the next revision/or put place holders now.
> >
> > Given that, my view is that the work in TEAS and DMM are complementary.
> >
> > TEAS defines transport and slicing applicable across various domains and
> solutions in a more generic fashion, while the DMM draft would provide how
> to apply it in a 3GPP context.
> > There isn't a 1:1 mapping between TEAS /IETF slice offered to the 3GPP
> provider, and a slice which the 3GPP provider provisions for its subscriber
> (UE).
> > The focus of the DMM draft is to define how a UE/3GPP transport packet
> (GTP packet across F1/W1, N3, N9, for a slice defined between 3GPP provider
> and subscriber) should be mapped to various transport network segments (SR,
> MPLS, IP, L2 etc).
> >
> > Regards,
> > John
> >
> >
> > -Original Message-
> > From: dmm  On Behalf Of Joel M. Halpern
> > Sent: Monday, January 04, 2021 6:23 PM
> > To: dmm@ietf.org
> > Subject: Re: [DMM] Call for adoption of
> draft-clt-dmm-tn-aware-mobility-08 as a WG document
> >
> > Hmmm.
> >
> > It seems to me that this document ought to align with the ongoing work
> in the TEAS working group that is attempting to define terminology and
> framework (and then any necessary protocol mechanisms) for IETF network
> slices.  That work is explicitly intended to support 3GPP end-to-end
> network slices.
> >
> > First, the discussion there exlicitly conluded that the term "Transport"
> > was confusing and misleading.  Which is why the work is now called IETF
> network slicing.
> >
> > Second, it seems that we want one IETF framework for this, not two
> competing frameworks.  Why is DMM doing this separately.  It seems to fall
> squarely into CCAMP and TEAS.  I presume we want a solution that works for
> 3GPP and works for other use cases?
> >
> > Yours,
> > Joel M. Halpern
> >
> > On 1/4/2021 7:11 PM, Linda Dunbar wrote:
> >> Support WG adoption.
> >>
> >> Linda Dunbar
> >>
> >> ---
> >> From: *Sri Gundavelli (sgundave)*  >> >
> >> Date: Wed, Dec 30, 2020 at 10:45 AM
> >> Subject: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08
> >> as a WG document
> >> To: dmm mailto:dmm@ietf.org>>
> >>
> >> Folks:
> >>
> >> The authors of the document, Transport Network aware Mobility for 5G,
> >> have presented the proposal and the need for standardization in
> >> multiple IETF WG meetings. There have been good amount of 

Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document

[Uma Chunduri]

Dear Hannu,

Indeed you raised this point w.r.t terminology in IETF109 and I responded
we will consider that as appropriate. I would note the following w.r.t
"transport network" aspect:

a. Till last quarter TEAS draft was referring to  "transport slices
terminology" -



 as in
https://tools.ietf.org/html/draft-nsdt-teas-transport-slice-definition-04#section-3





b. However most recently we do see the change to IETF Network Slice in Q42020

  https://tools.ietf.org/html/draft-nsdt-teas-ietf-network-slice-definition-00


c. I have also gone through other ongoing  individual documents in
TEAS and they still refer to transport slices, transport networks.


AFAIU, from the TEAS discussion earlier, when you work on generic slicing
effort transport network terminology may  be confusing to some folks (with
transport layer?).
However, if the scope is a mobility domain(3GPP network)  it is obvious as
the context it is discussed will be very
specific w.r.t other parts of the networks, viz.,  RAN and 5GC/Core
Network.

But, I still see an issue with the latest terminology in #b  (though it's
more appropriate for me to comment there in TEAS).
IETF Network slice may not represent all segments in fronthaul or F1U/W1U
in L2 switched environments or even in N3 and N9  which may be deployed
without IP/MPLS.

I also requested in the IETF109 DMM WG meeting, to give specific comments
or suggestions w.r.t terminology or any other aspects and we will consider
those and we haven't received any.

Any ways, we will keep this as TBD and we change it eventually as agreeable
to the DMM and IETF TEAS community.

Many Thx,
--
Uma C.

On Tue, Jan 5, 2021 at 1:00 AM Flinck, Hannu (Nokia - FI/Espoo) <
hannu.fli...@nokia-bell-labs.com> wrote:

> Hello
>
> I raised the same concern in the last meeting as Joel now in his mail. The
> authors then told that the work is aligned with TEAS. But it seems not to
> be clear after all.
> It would help to start the alignment by adding a refer to TEAS slicing
> drafts. And the use it in the text...
>
> Best regards
> Hannu
>
> -Original Message-
> From: dmm  On Behalf Of Joel M. Halpern
> Sent: Tuesday, January 5, 2021 3:46 AM
> To: Kiran Makhijani ; Joel M. Halpern <
> j...@joelhalpern.com>; dmm@ietf.org
> Subject: Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08
> as a WG document
>
> Kiran, the TEAS work is focused on defining the structures and semantics
> for an interface to request services from what 3GPP calls a transport
> network.  It seems really odd for another working group to define how to
> map to the "transport" network differently from the way TEAS is defining
> it.  If the TEAS definitions are wrong, we need to fix them.   If they
> are right, we need to use them.  Having another document that attempts to
> define the mapping separately seems like a recipe for difficulties.
>
> Yours,
> Joel
>
> On 1/4/2021 8:39 PM, Kiran Makhijani wrote:
> > Hi Joel,
> > The IETF network slices work under teas focuses on control and managing
> slices 'with in' the IP/MPLS networks. Actually, in TEAS 3GPP is just one
> of the use cases not the only use case. Also, TEAS wanted to replace
> "transport" because it could mean different things.
> >
> > But this document only focuses on 3GPP mobility scenarios and heavily
> relies on terms and components used in 5G architecture - here 'transport
> network' is a standard term. The work presented here is new and covers
> mobility procedures and corresponding mappings between AN and UPFs.
> >
> > I have read this document and I agree the relationship between the 2
> activities should be discussed (once TEAS adopts slice
> terminology/framework), maybe in section 2.7. But I feel this is not a
> major change to the way procedures are described in the document.
> >
> > I support this work.
> > FWIW, I think a bit restructuring of the document will improve its
> readability. For example, section 2 should be split into 'xhaul background'
> and 'TN mobility procedure' - things related to mapping and management of
> TN context and its mobility.
> >
> > -Kiran
> >
> >> 

Re: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08 as a WG document

[Uma Chunduri]

Hi Kiran,

Thanks for your support and  your inputs as a co-authoring member of TEAS
ongoing  work.

See in-line [Uma]:

--
Uma C.

On Mon, Jan 4, 2021 at 5:39 PM Kiran Makhijani  wrote:

> Hi Joel,
> The IETF network slices work under teas focuses on control and managing
> slices 'with in' the IP/MPLS networks. Actually, in TEAS 3GPP is just one
> of the use cases not the only use case. Also, TEAS wanted to replace
> "transport" because it could mean different things.
>
> But this document only focuses on 3GPP mobility scenarios and heavily
> relies on terms and components used in 5G architecture - here 'transport
> network' is a standard term. The work presented here is new and covers
> mobility procedures and corresponding mappings between AN and UPFs.
>
> I have read this document and I agree the relationship between the 2
> activities should be discussed (once TEAS adopts slice
> terminology/framework), maybe in section 2.7. But I feel this is not a
> major change to the way procedures are described in the document.
>

Thanks for your observation. The content in the sections was not changed
much from early stages of the draft (may by in early 2019). I
definitely look forward to your specific input to further update.

>
> I support this work.
> FWIW, I think a bit restructuring of the document will improve its
> readability. For example, section 2 should be split into 'xhaul background'
> and 'TN mobility procedure' - things related to mapping and management of
> TN context and its mobility.
>

[Uma]: Noted and keep this in our TBD item(s) for future updates. Shall
respond to Joel's email in a bit.


>
> -Kiran
>
> > -Original Message-
> > From: dmm  On Behalf Of Joel M. Halpern
> > Sent: Monday, January 4, 2021 4:23 PM
> > To: dmm@ietf.org
> > Subject: Re: [DMM] Call for adoption of
> draft-clt-dmm-tn-aware-mobility-08 as
> > a WG document
> >
> > Hmmm.
> >
> > It seems to me that this document ought to align with the ongoing work
> in the
> > TEAS working group that is attempting to define terminology and framework
> > (and then any necessary protocol mechanisms) for IETF network slices.
> That
> > work is explicitly intended to support 3GPP end-to-end network slices.
> >
> > First, the discussion there exlicitly conluded that the term "Transport"
> > was confusing and misleading.  Which is why the work is now called IETF
> > network slicing.
> >
> > Second, it seems that we want one IETF framework for this, not two
> competing
> > frameworks.  Why is DMM doing this separately.  It seems to fall
> squarely into
> > CCAMP and TEAS.  I presume we want a solution that works for 3GPP and
> > works for other use cases?
> >
> > Yours,
> > Joel M. Halpern
> >
> > On 1/4/2021 7:11 PM, Linda Dunbar wrote:
> > > Support WG adoption.
> > >
> > > Linda Dunbar
> > >
> > > ---
> > > From: *Sri Gundavelli (sgundave)*  > > >
> > > Date: Wed, Dec 30, 2020 at 10:45 AM
> > > Subject: [DMM] Call for adoption of draft-clt-dmm-tn-aware-mobility-08
> > > as a WG document
> > > To: dmm mailto:dmm@ietf.org>>
> > >
> > > Folks:
> > >
> > > The authors of the document, Transport Network aware Mobility for 5G,
> > > have presented the proposal and the need for standardization in
> > > multiple IETF WG meetings. There have been good amount of discussions
> > > in the mailers and there is some level of interest for the work from
> > > the community. We are therefore considering the adoption of this
> > > document as a DMM WG document, to be moved on Informational Standards
> > track.
> > >
> > > *Transport Network aware Mobility for 5G*
> > >
> > > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> > > s.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-
> > 08data=04%7C0
> > >
> > 1%7Ckiranm%40futurewei.com%7C93dbff7d775842c2409108d8b1101f02%7C
> > 0fee8f
> > >
> > f2a3b240189c753a1d5591fedc%7C1%7C0%7C637454030107896985%7CUnkn
> > own%7CTW
> > >
> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVC
> > I6
> > >
> > Mn0%3D%7C3000sdata=34KQ%2Fo0EvC8uta4EF1pa3i1N5etAd6RKUcU
> > 8%2BH72rW
> > > I%3Dreserved=0
> > >  > > ls.ietf.org%2Fhtml%2Fdraft-clt-dmm-tn-aware-mobility-
> > 08data=04%7C
> > >
> > 01%7Ckiranm%40futurewei.com%7C93dbff7d775842c2409108d8b1101f02%7
> > C0fee8
> > >
> > ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637454030107906979%7CUnk
> > nown%7CT
> > >
> > WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> > VCI
> > >
> > 6Mn0%3D%7C3000sdata=YR1gDCJtkfwjBxxsBtSYbbbQZpUlDzp3IXraMq
> > BXA0w%3
> > > Dreserved=0>
> > >
> > > With this background, we would like to ask the WG to provide some
> > > feedback on their interest for this work. Please provide substantial
> > > comments as why this SHOULD be adopted, or why it SHOULD NOT be
> > adopted.
> > > If there is interest, and if there are no other concerns from
> > > AD/IESG/Others, 

Re: [DMM] FW: dmm - Requested session has been scheduled for IETF 109

[Uma Chunduri]

Dear Chairs,

While the document is far from perfect, it does address all the comments
received during the discussions before IETF109 in 08 version (
https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-08 ) and over a
period of time before. Updates reflecting various points were reflected in
the IET109 presentation.
At this point, we request WG adoption of the same (and obviously shall
continue to improve this in future).
--
Uma C.






>
> I just want to further elaborate on some of my reposses:
>
> a. Keeping the MTNC-ID in the packet header creates complications for L2
> (mid/backhaul) and V4 (backhaul) only scenarios. This was discussed in
> IETF105 presentation (issue/discussion) and IETF106 presentation with
> various options before settling on to the current approach. I standby on my
> response to Pablo's question and the aspect mostly de-associated now.
>
> b. Most of this work is orthogonal to overarching and generic slicing
> effort in routing WGs (including various YANG models). The scope of this
> document is much narrow and in the mobility domain and section 3 is mostly
> applicable to the framework proposed, for GTP-based UDP encap environments,
> currently used in N3 and N9 interfaces.
> As I said we would continue to take comments to address further, if any
> suggestions/proposals.
>
>
> Many thx for your feedback/comments.
>
> --
> Uma C.
>
>
> On Tue, Dec 1, 2020 at 5:00 PM Sri Gundavelli (sgundave)  40cisco@dmarc.ietf.org> wrote:
>
>> Thanks Pablo for taking capturing the meeting minutes.
>>
>>
>>
>> https://codimd.ietf.org/notes-ietf-109-dmm#
>>
>>
>>
>> WG -  Please review
>>
>>
>>
>> Sri
>>
>>
>>
>>
>>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FW: dmm - Requested session has been scheduled for IETF 109

[Uma Chunduri]

Dear Sri & WG

Thx Pable for the minutes and they look good to me.

I just want to further elaborate on some of my reposses:

a. Keeping the MTNC-ID in the packet header creates complications for L2
(mid/backhaul) and V4 (backhaul) only scenarios. This was discussed in
IETF105 presentation (issue/discussion) and IETF106 presentation with
various options before settling on to the current approach. I standby on my
response to Pablo's question and the aspect mostly de-associated now.

b. Most of this work is orthogonal to overarching and generic slicing
effort in routing WGs (including various YANG models). The scope of this
document is much narrow and in the mobility domain and section 3 is mostly
applicable to the framework proposed, for GTP-based UDP encap environments,
currently used in N3 and N9 interfaces.
As I said we would continue to take comments to address further, if any
suggestions/proposals.


Many thx for your feedback/comments.

--
Uma C.


On Tue, Dec 1, 2020 at 5:00 PM Sri Gundavelli (sgundave)  wrote:

> Thanks Pablo for taking capturing the meeting minutes.
>
>
>
> https://codimd.ietf.org/notes-ietf-109-dmm#
>
>
>
> WG -  Please review
>
>
>
> Sri
>
>
>
>
>
> *From: *dmm  on behalf of "Sri Gundavelli
> (sgundave)" 
> *Date: *Friday, November 13, 2020 at 7:00 AM
> *To: *dmm 
> *Subject: *[DMM] FW: dmm - Requested session has been scheduled for IETF
> 109
>
>
>
> Please review the agenda for IETF 109.
>
>
>
> https://datatracker.ietf.org/meeting/109/materials/agenda-109-dmm-00.txt
>
>
>
> Satoru & Sri
>
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FW: dmm - Requested session has been scheduled for IETF 109

[Uma Chunduri]

Dear Sri,

We would like to ask a 10 mins slot to update the WG for the to be
published draft-clt-dmm-tn-aware-mobility (08 version - would be done on
11/02). The changes are mostly  to address the  recent comments received in
the list.

--
Uma C.

On Mon, Oct 26, 2020 at 3:49 PM Sri Gundavelli (sgundave)  wrote:

> Folks - We have the meeting scheduled for Nov 17th. Please send any topics
> that you want to present.
>
> Sri
>
>
>
>
>
> On 10/23/20, 2:16 PM, ""IETF Secretariat""  wrote:
>
> Dear Sri Gundavelli,
>
> The session(s) that you have requested have been scheduled.
> Below is the scheduled session information followed by
> the original request.
>
>
> dmm Session 1 (1:00 requested)
> Tuesday, 17 November 2020, Session II 1430-1530
> Room Name: Room 3 size: 503
> -
>
>
> iCalendar: https://datatracker.ietf.org/meeting/109/sessions/dmm.ics
>
> Request Information:
>
>
> -
> Working Group Name: Distributed Mobility Management
> Area Name: Internet Area
> Session Requester: Sri Gundavelli
>
>
> Number of Sessions: 1
> Length of Session(s):  1 Hour
> Number of Attendees: 35
> Conflicts to Avoid:
>
>
>
>
>
>
>
>
> People who must be present:
>   Sri Gundavelli
>   Erik Kline
>   Dapeng Liu
>   Satoru Matsushima
>
> Resources Requested:
>
> Special Requests:
>
> -
>
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Hi Kausik,

Many thanks for your clarification below.

in-line..

--
Uma C.

On Mon, Oct 26, 2020 at 12:48 PM Majumdar, Kausik <
kausik.majum...@commscope.com> wrote:

> Hi Uma,
>
>
>
> My comments are inline below.
>
>
>
> *From:* dmm  *On Behalf Of * Uma Chunduri
> *Sent:* Wednesday, October 21, 2020 6:18 PM
> *To:* dmm 
> *Subject:* Re: [DMM] New Version Notification for
> draft-clt-dmm-tn-aware-mobility-07.txt
>
>
>
>

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


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
> 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 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:
>

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

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



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

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
>

>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

Thanks for your review, comments in-line ..

--
Uma C.

On Mon, Oct 26, 2020 at 1:15 PM Majumdar, Kausik <
kausik.majum...@commscope.com> wrote:

> 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.
>
> Sure, shall fix that.


>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?
>
>
>
Right, UDP Src port.

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?
>
>
>
That's a typo. Shall correct it.

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

>
>
> 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.
>
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
> *To:* Uma Chunduri ; dmm 
> *Subject:* RE: [DMM] New Version Notification for
> draft-clt-dmm-tn-aware-mobility-07.txt
>
>
>
> Hi Uma,
>
>
>
> My comments are inline below.
>
>
>
> *From:* dmm  *On Behalf Of *Uma Chunduri
> *Sent:* Wednesday, October 21, 2020 6:18 PM
> *To:* dmm 
> *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 ..)
>
>
>
> On Wed, Oct 21, 2020 at 1:29 PM Majumdar, Kausik <
> kausik.majum...@commscope.com> 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.
>
>
>
> Thanks.
>
>
>
>
>
> 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.
>
>
>
> 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
>

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

[Uma Chunduri]

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

On Wed, Oct 21, 2020 at 1:29 PM Majumdar, Kausik <
kausik.majum...@commscope.com> 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.
>

Thanks.


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

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?


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

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

--
Uma C.


>
>
> Regards,
>
> Kausik
>
>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

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

On Wed, Oct 21, 2020 at 11:20 AM Pablo Camarillo (pcamaril) <
pcama...@cisco.com> wrote:

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

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/
>
> Further discussion took place at the LSR mailer and those scalability
> concerns on PPR remain unaddressed.
>
> https://mailarchive.ietf.org/arch/msg/lsr/6TzBBkmq4hQkiqyBeuN7MMOtMs0/
>

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.


>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

On Wed, Oct 21, 2020 at 1:36 PM Joel M. Halpern  wrote:

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

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


>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] requesting feedback on draft-clt-dmm-tn-aware-mobility-06

[Uma Chunduri]

Thanks John for the detailed message and updates in the 06 version of this.

Dear All,

As I indicated,
https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07 was mostly a
refresh.


We are seeking to request WG adoption of this soom and would be happy to
hear any feedback before too.

--
Uma C.

On Tue, Apr 28, 2020 at 12:16 PM Kaippallimalil John <
john.kaippallima...@futurewei.com> wrote:

> Hi,
>
> We submitted draft-clt-dmm-tn-aware-mobility-06 prior to the IETF meeting
> in March.
>
> Since there was no dmm session, we are requesting for feedback on the
> mailing list.
>
>
>
> The authors believe that all the feedback from IETF 106 have been
> incorporated into the new version:
>
>1. VLAN as a means to convey MTNC-ID (Huawei)
>*Action*: Added new chapter 2.2 on Front haul describes scenario and
>VLAN, L2 mechanisms.
>2. Document sections to describes provisioning; second which describes
>user plane handling (Huawei)
>*Action*: revised figures, chapters etc to address the comment.
>Provisioning and user plane handling are separate (at least sub chapters)
>3. Source port range /mechanisms (Dave) – already addressed in draft.
>*no action* needed.
>4. Source port checksum (Suresh)
>*Action*: add text in draft to state that UDP /GTP encap is from E2E.
>Checksums are not affected.
>Checksum clarification added in chapter 2.7
>5. 3GPP operator/IPSec Gateways (Altiostar):
>*Action*: Revision to address how the this works in the presence of
>IPSec gateways – added in section 2.6
>
> Would appreciate reviews and suggestions.
>
>
>
> Best Regards,
>
> John
>
>
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

[Uma Chunduri]

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  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
>
>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF106 - Call for Agenda Items

[Uma Chunduri]

Dear Satoru & Sri

Based on the inputs from  DMM group and offline discussions with other
folks at IETF105  we published the 05 version

https://datatracker.ietf.org/doc/draft-clt-dmm-tn-aware-mobility/?include_text=1



It would be great if you can put at least 10 minutes for the above in the
agenda. Either John or I would present the same.

Cheers!

--
Uma C.
(on behalf of all co-authors)



On Mon, Oct 21, 2019 at 8:07 PM Satoru Matsushima <
satoru.matsush...@gmail.com> wrote:

> Folks,
>
> The DMM chairs are planning the dmm meeting in Singapore at IETF106:
>
> 18th November, Monday Afternoon Session II (15:50-17:50)
>
> If you have a draft or any topics you would like to discuss, please send
> your request for agenda time to the dmm chairs. Please include the
> information in the request as following:
>
> The title of the presentation:
> Presenter name:
> Time you need:
> Draft reference:
>
> Please have agenda items to us by 2019-11-04 (November 4th).
>
> Reminder:
> The draft cut-off date: 14th November UTC 23:59 (2 weeks before the
> meeting).
>
> Dapeng & Sri & Satoru
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments on draft-clt-dmm-tn-aware-mobility-02

[Uma Chunduri]

>
> Hi Sridhar,
>
>
> Thanks for your review.
>
> My response in-line [Uma]:
>
> --
> Uma C.
>
>
> On Wed, Jan 30, 2019 at 6:49 PM Sridhar Bhaskaran <
> sridhar.bhaska...@huawei.com> wrote:
>
>> Dear all,
>>
>> I reviewed draft-clt-dmm-tn-aware-mobility-02 and I have the following
>> comments based on 3GPP architectural definitions in TS 23.501 / 23.502
>>
>> 1. Section 2.1 - RQI is just a flag to tell the UE that it has to reflect
>> back the same QFI in the uplink packet. RQI on its own is not a QoS
>> indicator. Hence the use of RQI in the following sentence is not correct
>>
>>Mapping of the PDU sessions to TE
>>paths can be done based on the source UDP port ranges (if these are
>>assigned based on the PDU session QCIs, as done in some deployments
>>with 4G/LT) of the GTP-U encapsulated packet or based on the 5QI or
>>RQI values in the GTP-U header.
>>
>
> [Uma]: Agree.  References to RQI for down link and 5QI for uplink too
> would be corrected to QFI in the header.
>
>
>>
>> 2. Section 2.1, 2.2 - and almost everywhere - Restricting to description
>> of gNB as the radio side is not correct. 5G architecture allows the radio
>> or access node to be any of the following:
>> a)  gNB (which means radio is NR)
>> b)  Ng-eNB (which means radio is EUTRA)
>> c)  Untrusted WLAN
>> d)  From R16 onwards wireline and Trusted wireless LAN access
>>
>> So the draft should generally mention as 5G-AN and not as gNB.
>>
> [Uma]: Shall fix this. Does  Standalone or non-standalone mode  of NR make
> any difference w.r.t what's been laid out?
>
>>
>> 3. The draft mixes SSC modes with slicing concept. SSC modes and slicing
>> are two independent concepts. UL/CL and BP UPF are applicable to all SSC
>> modes. SSC modes do not have any relevance when selecting a transport path.
>> The description of SSC modes need to be corrected to rather reflect how /
>> where the PPR-ID is applied for different SSC modes.
>>
>
> [Uma]: Shall remove UL/CL discussion specific to SSC mode 3 (as this is
> applicable to any mode). But shall keep the SSC mode 3 for BP UPF case to
> describe the E2E path with PPR-ID.
>
>>
>> Regards
>> Sridhar Bhaskaran
>>
>>
>>
>>
>> ___
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>>
>
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comment on SRv6-mobile-userplane

[Uma Chunduri]

Hi Pablo,

>As I already clarified in my previous email, the proposal of 
>draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
Great. Thanks.
>As I already said in my previous email, we will clarify this in the next 
>revision of the draft.
Sure.

Btw, you responded to Arash’s comments addressing me.

Some parts of the draft already maintained that independence with SRv6 features 
in underlay (for example Section 5.3).
In summary if you could address:


1.   Section 5.1 Traditional mode (Tom’s comment on terminology and 
IP-in-IP with no relation to SR?)

2.   Section 5.2 Enhanced mode. Here SR path steering features are used and 
not fully described what happens to TEID (as GTP is gone).

3.   And if TEID after GTP removal is encoded in each SID in the SRH or 
this is only specific to some PDU session as you indicated in your first email.

Thx!
--
Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comment on SRv6-mobile-userplane

[Uma Chunduri]

Tom,

In-line [Uma]:
--
Uma C.


-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net] 
Sent: Wednesday, July 18, 2018 12:12 PM
To: Uma Chunduri 
Cc: Arashmid Akhavain ; Pablo Camarillo 
(pcamaril) ; spr...@ietf.org; dmm@ietf.org
Subject: Re: [DMM] Comment on SRv6-mobile-userplane

On Wed, Jul 18, 2018 at 8:56 AM, Uma Chunduri  wrote:
> Tom,
>
> >I think the terminology being used in the draft might be making this 
> seem complicated than it actually is. AFAICT, SRv6 traditional mode is 
> nothing more than IP in IP encapsulation, so the requirement of the underlay 
> is that it
> >forwards IPv6 and intermediate nodes treat the traffic as 
> "normal IPv6 traffic". There is no segment routing involved, no extension 
> headers needed, and the only upgrade for the network is to support IPv6.
>
> I am not sure that is the case. Please re-read Section 5.1 (and 5.1.3)
> " This 1-for-1 mapping is
>replicated here to replace the GTP encaps with the SRv6 
> encaps, while
>not changing anything else."
>
Uma,

Right, there is where the terminology of the draft is confusing. SRv6 defines a 
routing extension header not an encapsulation protocol.

[Uma]: Agree.


"SRv6 encaps" here means IP packets (presumably either IPv4 or IPv6) are 
encapsulated in IPv6 using standard IP/IP encpasulation.

[Uma]: Sure. But, I think, I would see  
https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01  
folks speak.  As of now, one should go by what's there in this draft.


Concurrent with that encapsulation, a segment routing header or other extension 
headers may be added to the outer IP header (this is consistent with RFC8200 
requirement that only source nodes can set extension headers). So there is 
really no such thing as SRv6 encapsulation, and in the text above replacing 
SRv6 with IP-in-IP would be much clearer as to how the protocol works.

[Uma]: If we just replace SRv6 with IP-in-IP (IPv6) - I am not sure what's 
being achieved and how that encapsulation is relevant  to this draft? 


Tom

> --
> Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comment on SRv6-mobile-userplane

[Uma Chunduri]

Hi Arashmid,


>>[Uma]:  2 quick and minor corrections for the above first.“we encode the TEID 
>>into a SID”  ==> 
>>https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  
>>says “Note that in this mode the TEID is embedded in each SID.”
>>(section 5.1.3 confirms this)

 >[Arashmid] Embed vs Encode? Is this issue?

[Uma2:]It’s not embed or encode. It says each SID.



>[Arashmid] Today each PDU session gets its own set of TEIDs between eNB and 
>SGW and between SGW and PGW. For example for a UE with both internet access 
>and VoLTE, there are two GTP tunnels between the eNB and the SGW and two other 
>GTP tunnels between the SGW and the PGW.
>We maintain this in traditional mode.

[Uma2]: I am not questioning how each bearer get a different TEID or how 
separate tunnels are maintained per PDU session between eNB-SGW or SGW-PGW.  
It’s good this being planned to achieve in traditional mode. However, if this 
is seen as GTP replacement option, by moving TEID of the GTP header encoded 
into each SRv6 SID, the unintended consequence is we are making 3GPP 
functionalities that are associated with TEID specific to one transport 
underlay.
There are various other modes defined in the document, for example 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.3 
(called Enhanced mode with unchanged gNB GTP behavior)
In that case I see separation maintained and with a possibility of multiple 
SRv6 features, that can be applied in underlay as needed.

--
Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comment on SRv6-mobile-userplane

[Uma Chunduri]

Tom,

>I think the terminology being used in the draft might be making this 
seem complicated than it actually is. AFAICT, SRv6 traditional mode is nothing 
more than IP in IP encapsulation, so the requirement of the underlay is that it 
>forwards IPv6 and intermediate nodes treat the traffic as 
"normal IPv6 traffic". There is no segment routing involved, no extension 
headers needed, and the only upgrade for the network is to support IPv6. 

I am not sure that is the case. Please re-read Section 5.1 (and 5.1.3)
" This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 
encaps, while
   not changing anything else."

--
Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comment on SRv6-mobile-userplane

[Uma Chunduri]

Arash,


In-line [Uma]:

--
Uma C.

From: Arashmid Akhavain
Sent: Wednesday, July 18, 2018 9:18 AM


Hi Uma,
I am not sure if I understand your concern. In traditional mode, we encode the 
TEID into a SID. This is the mode that draft bogineni refers to as the simplest 
form of using SRv6 for the N9 interface.

[Uma]:  2 quick and minor corrections for the above first.

1.  “we encode the TEID into a SID”  ==> 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1  
says “Note that in this mode the TEID is embedded in each SID.” (section 5.1.3 
confirms this)

2.  Traditional mode as documented ietf-dmm-srv6 applies to both N3 and N9

>Only the head nodes know that TEID has been encoded into the SID. Tandem nodes 
>treat the traffic as normal SRv6 traffic. Are you saying that the use of SRv6 
>in general forces the underlying say MPLS transport to convert to SRv6?

[Uma]:  The problem with removing GTP header and keeping the same in each SRH 
SIDs make the underlay specific to SRv6.
 Pablo’s below response says – “The Traditional mode is only 
offering GTP replacement for specific PDU sessions with complete independence 
from the transport network.”
I don’t see the draft text reflects this.




Cheers,
Arash

From: Uma Chunduri
Sent: Tuesday, July 17, 2018 3:10 PM
To: Pablo Camarillo (pcamaril) mailto:pcama...@cisco.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>; 
spr...@ietf.org<mailto:spr...@ietf.org>
Subject: RE: Comment on SRv6-mobile-userplane

[Added Spring too, as one of the chairs, Bruno asked us to discuss]

Hi Pablo,

Please see in in-line [Uma]:

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri mailto:uma.chund...@huawei.com>>
Cc: dmm@ietf.org<mailto:dmm@ietf.org>; Arashmid Akhavain 
mailto:arashmid.akhav...@huawei.com>>; Alberto 
Rodriguez Natal (natal) mailto:na...@cisco.com>>
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you 
have raised a comment saying that SRv6 mandates an integration in between the 
overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions 
with complete independence from the transport network. No matter whether the 
transport is MPLS, IPv6 or whatever -without any SR at all-.


[Uma]:  It is positioned as one of the alternative to replace GTP-U in the data 
path.

From Section 5.1

“   In the traditional mobile network, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 encaps, while
   not changing anything else.

   This mode minimizes the changes required to the entire system and it
   is a good starting point for forming the common basis.  Note that in
   this mode the TEID is embedded in each SID.”

I also believe, that way because this is being sent as response to CT4 as a 
replacement alternative to GTP-U with SRv6 underlay in traditional mode.

https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1


“   In its most basic form, SRv6 can be used as a simple drop-in

   alternative for GTP tunnels.  The control plane in this approach

   remains the same, and still attempts to establish GTP-U tunnels and

   communicate TEIDs between the tunnel end points.  However, at the

   next level, SRv6 capable nodes use SIDs to direct user traffic

   between the UPFs.”


If we propose this is a drop-in replacement for GTP-U –  this could force (with 
the approval of IETF and 3GPP)  every operator to use SRv6; as TEID 
functionality is basic to any 3GPP procedure (not only for Xn, N2 and whatever 
mobility case out there, service request, paging and you name it..).
I don’t think you want to exclude SR-MPLS if operator wants (or any TE) it or 
transitioning to.

On the other hand if it is only for some PDU sessions then this need to be 
specifically mentioned in the draft as well as the “optimized mobile user 
plane” response.


Hence, if an operator would like to have integration of the overlay and 
underlay (for end-to-end network slicing), he can have such integration. If 
this is not desired, the dmm-srv6-mobile-uplane proposal can work completely 
independently from the transport, as already documented in the draft.

[Uma]: It would be great if we strive to achieve that independence as much as 
possible while focusing on the value and feature SRv6 brings it to the table.

I will check with the rest of co-authors of the draft to see whether w

Re: [DMM] Comment on SRv6-mobile-userplane

[Uma Chunduri]

[Added Spring too, as one of the chairs, Bruno asked us to discuss]

Hi Pablo,

Please see in in-line [Uma]:

--
Uma C.

From: Pablo Camarillo (pcamaril) [mailto:pcama...@cisco.com]
Sent: Tuesday, July 17, 2018 11:25 AM
To: Uma Chunduri 
Cc: dmm@ietf.org; Arashmid Akhavain ; Alberto 
Rodriguez Natal (natal) 
Subject: Comment on SRv6-mobile-userplane

Hi Uma,

During the presentation of draft-bogineni-dmm-optimized-mobile-user-plane you 
have raised a comment saying that SRv6 mandates an integration in between the 
overlay and the underlay transport network.

I would like to clarify that this is NOT true. Please read 
https://tools.ietf.org/html/draft-ietf-dmm-srv6-mobile-uplane-02#section-5.1
The Traditional mode is only offering GTP replacement for specific PDU sessions 
with complete independence from the transport network. No matter whether the 
transport is MPLS, IPv6 or whatever -without any SR at all-.


[Uma]:  It is positioned as one of the alternative to replace GTP-U in the data 
path.

From Section 5.1

“   In the traditional mobile network, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps with the SRv6 encaps, while
   not changing anything else.

   This mode minimizes the changes required to the entire system and it
   is a good starting point for forming the common basis.  Note that in
   this mode the TEID is embedded in each SID.”

I also believe, that way because this is being sent as response to CT4 as a 
replacement alternative to GTP-U with SRv6 underlay in traditional mode.

https://tools.ietf.org/html/draft-bogineni-dmm-optimized-mobile-user-plane-01#section-6.1


“   In its most basic form, SRv6 can be used as a simple drop-in

   alternative for GTP tunnels.  The control plane in this approach

   remains the same, and still attempts to establish GTP-U tunnels and

   communicate TEIDs between the tunnel end points.  However, at the

   next level, SRv6 capable nodes use SIDs to direct user traffic

   between the UPFs.”


If we propose this is a drop-in replacement for GTP-U –  this could force (with 
the approval of IETF and 3GPP)  every operator to use SRv6; as TEID 
functionality is basic to any 3GPP procedure (not only for Xn, N2 and whatever 
mobility case out there, service request, paging and you name it..).
I don’t think you want to exclude SR-MPLS if operator wants (or any TE) it or 
transitioning to.

On the other hand if it is only for some PDU sessions then this need to be 
specifically mentioned in the draft as well as the “optimized mobile user 
plane” response.


Hence, if an operator would like to have integration of the overlay and 
underlay (for end-to-end network slicing), he can have such integration. If 
this is not desired, the dmm-srv6-mobile-uplane proposal can work completely 
independently from the transport, as already documented in the draft.

[Uma]: It would be great if we strive to achieve that independence as much as 
possible while focusing on the value and feature SRv6 brings it to the table.

I will check with the rest of co-authors of the draft to see whether we should 
clarify in the draft the independence from the transport network.

[Uma]: Sure, thanks for your consideration.

Cheers,
Pablo.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Uma Chunduri]

Hi Satoru,

In-line [Uma]:

Cheers!
--
Uma C.
(responding as an individual)

-Original Message-
From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] 
Sent: Tuesday, May 29, 2018 6:23 PM
To: Uma Chunduri 
Cc: Dino Farinacci ; dmm 
Subject: Re: [DMM] User Plane Protocol Study in 3GPP

Hello Uma, let me clarify something. 

Are you proposing that we need to work on mobile user plane protocol with IPv4 
NAPT?
[Uma]: Nope, I did not say that.
Or, does your employer plan to develop NAPT traversal cellular equipments and 
application gateway for the user plane protocol?
[Uma]:  You are assuming on something which I didn't say anything about.  I was 
just responding to Dino's question on "IPv6 only NGC" ..
 

It seems reinvent of PPTP.

Cheers,
-satoru

> 2018/05/24 2:07、Uma Chunduri のメール:
> 
> Dear All,
> 
> For the Dino's question -
> 
>> Do you think carriers will build an IPv6-only NGC at this point in time?
> 
> I don't think so (from the existing deployments perspective, including early 
> 5G transitions). 
> 
> So, IMO - any mobility solution ought to be underlay independent - to allow 
> flexibility for the operators. I see this discussion is independent of 
> address space exhaustion or IPv6 address to UE..
> 
> --
> Uma C.
> 
> 
> -Original Message-
> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
> Sent: Tuesday, March 20, 2018 5:02 PM
> To: Satoru Matsushima 
> Cc: dmm 
> Subject: Re: [DMM] User Plane Protocol Study in 3GPP
> 
> That sounds like you want to do IPv4 over IPv6. Do you think carriers will 
> build an IPv6-only NGC at this point in time?
> 
> Dino
> 
>> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima  
>> wrote:
>> 
>> Next header type maybe?
>> Interestingly GTP-U doesn’t have it.
>> 
>> Sent from my iPhone
>> 
>> 2018/03/20 18:17、Dino Farinacci のメール:
>> 
>>> How? Please summarize in one sentence and don’t me to a draft.
>>> 
>>> Dino
>>> 
>>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>>>  wrote:
>>>> 
>>>> Yes , supports IPv4 PDU with minimum effort.
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>> 2018/03/20 16:47、Lyle Bertz のメール:
>>>> 
>>>>> I did not get to ask but I know your presentation talks about IPv6 but is 
>>>>> there a requirement to support IPv4 mobile or dual stack?
>>>>> 
>>>>> Lyle
>>>> 
>>>> ___
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>> 
> 
> ___
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] User Plane Protocol Study in 3GPP

[Uma Chunduri]

Dear All,

For the Dino's question -

> Do you think carriers will build an IPv6-only NGC at this point in time?

I don't think so (from the existing deployments perspective, including early 5G 
transitions). 

So, IMO - any mobility solution ought to be underlay independent - to allow 
flexibility for the operators. I see this discussion is independent of address 
space exhaustion or IPv6 address to UE..

--
Uma C.


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Dino Farinacci
Sent: Tuesday, March 20, 2018 5:02 PM
To: Satoru Matsushima 
Cc: dmm 
Subject: Re: [DMM] User Plane Protocol Study in 3GPP

That sounds like you want to do IPv4 over IPv6. Do you think carriers will 
build an IPv6-only NGC at this point in time?

Dino

> On Mar 20, 2018, at 6:33 PM, Satoru Matsushima  
> wrote:
> 
> Next header type maybe?
> Interestingly GTP-U doesn’t have it.
> 
> Sent from my iPhone
> 
> 2018/03/20 18:17、Dino Farinacci のメール:
> 
>> How? Please summarize in one sentence and don’t me to a draft.
>> 
>> Dino
>> 
>>> On Mar 20, 2018, at 10:24 AM, Satoru Matsushima 
>>>  wrote:
>>> 
>>> Yes , supports IPv4 PDU with minimum effort.
>>> 
>>> Sent from my iPhone
>>> 
>>> 2018/03/20 16:47、Lyle Bertz のメール:
>>> 
 I did not get to ask but I know your presentation talks about IPv6 but is 
 there a requirement to support IPv4 mobile or dual stack?
 
 Lyle
>>> 
>>> ___
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>> 

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC"

[Uma Chunduri]

> Now, keeping this in mind, if there is a good reason not to send the LS 
> Response now, delay it by some time, or if we believe there is nothing to 
> respond, we can discuss and decide to do just that. Hope this makes sense.

+1

--
Uma C.

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Friday, April 13, 2018 4:06 PM
To: Arashmid Akhavain ; dmm@ietf.org
Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User 
Plane Protocol in 5GC"

Hi Arashmid,


I am not seeing a relation to the LS Response and the July 2018 deadline that 
you are referring to. I think there is some disconnect here. Lets review what 
we the chairs are thinking.


1. The work in IETF related to User-Plane optimizations will continue for many 
months. When there is a LS Request, we will send a LS response. We will use LS 
query/response as a means to gather feedback from the SDO community, and 
provide an update on the status of all the documents in DMM at this time. The 
status includes update on WG documents and individual I-D’s under discussions.

2. We are not going with the assumption that there will only be a single LS 
request/response for this entire UP Study, but we will keep exchanging 
information based on the progress, and whenever we need additional 
clarifications. 

3. There are multiple proposals in IETF. As we have indicated in the past, we 
are not going to recommend THE single solution and put it on a platter for 3GPP 
consumption, but rather the focus will be on characterization of each approach 
that we take up in DMM WG.

Now, keeping this in mind, if there is a good reason not to send the LS 
Response now, delay it by some time, or if we believe there is nothing to 
respond, we can discuss and decide to do just that. Hope this makes sense.

Bottomline, all feedback is welcome!


Sri 




On 4/13/18, 1:35 PM, "Arashmid Akhavain" 
wrote:

>Hi Sri,
>Thank you for getting back to us. They listed a few dates there. The 
>final deadline is I guess July 2018.
>Are we targeting anything earlier?
>
>Arashmid
>
>> -Original Message-
>> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
>> Sent: 13 April 2018 12:47
>> To: Arashmid Akhavain ; dmm@ietf.org
>> Subject: Re: New Liaison Statement, "CP-173160: New Study Item on 
>> User Plane Protocol in 5GC"
>> 
>> Hi Arashmid,
>> 
>> We provide the status of the related work items in DMM, and seek any  
>>clarifications on their CT4 work. Key thing from our point of view is 
>>to get  their feedback on the work we are doing and try to meet their 
>>timelines.
>> 
>> Sri
>> 
>> 
>> On 4/12/18, 10:53 AM, "Arashmid Akhavain"
>> 
>> wrote:
>> 
>> >Hi Sri,
>> >
>> >Any idea what the plan is once we pass this information to CT4?
>> >
>> >Arashmid
>> >
>> >> -Original Message-
>> >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri 
>> >> Gundavelli
>> >> (sgundave)
>> >> Sent: 12 April 2018 12:47
>> >> To: dmm@ietf.org
>> >> Subject: Re: [DMM] New Liaison Statement, "CP-173160: New Study 
>> >> Item on User Plane Protocol in 5GC"
>> >>
>> >> Please review and post your comments. Chairs will draft a response 
>> >>for WG  review.
>> >>
>> >> Sri
>> >>
>> >>
>> >> On 4/11/18, 11:16 AM, "Liaison Statement Management Tool"
>> >> 
>> >> wrote:
>> >>
>> >> >Title: CP-173160: New Study Item on User Plane Protocol in 5GC 
>> >> >Submission Date: 2018-04-11 URL of the IETF Web page:
>> >> >https://datatracker.ietf.org/liaison/1572/
>> >> >Please reply by 2018-07-20
>> >> >From: Satoru Matsushima 
>> >> >To: Sri Gundavelli ,Dapeng Liu 
>> >> >
>> >> >Cc: Dapeng Liu ,Terry Manderson 
>> >> >,Distributed Mobility Management 
>> >> >Discussion List ,Sri Gundavelli 
>> >> >,Suresh Krishnan  Response
>> Contacts:
>> >> >georg.mayer.hua...@gmx.com,3gppliai...@etsi.org
>> >> >Technical Contacts:
>> >> >Purpose: For action
>> >> >
>> >> >Body: 1. Overall Description:
>> >> >3GPP working group of CT4 (Core and Terminal) would like to 
>> >> >inform the IETF that CT4 has initiated a study item on user plane 
>> >> >protocol in 5GC for Release-16 of 5G phase 2 (see CP-173160).
>> >> >
>> >> >Based on the outcome from the IETF / 3GPP Coordination meeting at 
>> >> >IETF#100, 3GPP CT4 got aware that IETF DMM WG is currently 
>> >> >working on a possible candidate protocol for the 3GPP 5G user 
>> >> >plane
>>protocol.
>> >> >
>> >> >3GPP CT4 wants to emphasize that currently there is no related 
>> >> >evaluation ongoing in 3GPP. Nevertheless, a study item was 
>> >> >approved for such a study to start in the second half of 2018. 
>> >> >The study will evaluate between existing 

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Uma Chunduri]

In-line..
--
Uma C.

-Original Message-
From: Tom Herbert [mailto:t...@quantonium.net]
Sent: Tuesday, March 27, 2018 11:23 AM
To: Uma Chunduri <uma.chund...@huawei.com>
Cc: Sri Gundavelli (sgundave) <sgund...@cisco.com>; dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 10:27 AM, Uma Chunduri 
<uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>> wrote:
> Hi Sri,
>
> >
> > I am really hoping we will be able to apply SRH insertion without 
> the
> > need for IP encapsulation. At least for mobile environments within a
> > closed administrative domains, there should be exceptions for 
> allowing
> > insertion of SRH by a on-path node.
>
> While I see you intention to see a way to reduce the RFC8200 encap
> overhead; for mobile/cellular environments  I see its paramount to
> have a  standardized solutions because it's mostly multi-vendor equipment 
> from most of the operators deployments. Regardless if it's a closed 
> administrative domain or not.
>
>
> However, it might be fine if it is an inside a DC (for example DC
> underlay) kind of  environment and  this exception could be made; as the 
> diversity of different vendor equipment can be less.
>
That story line has played out many times before. In a closed system like a DC 
there is always seems to be some motivation to deploy proprietary solutions. 
Often this is done for convenience and because something is viewed as something 
critically needed today. In the long run, this is self defeating. It is a lot 
of effort to maintain proprietary protocols, and even worse can force the 
network into vendor lock-in. It's almost always better to stick with open 
standards from day one even in closed systems.

[Uma]:  Tom, I am all for open standards (regardless of which SDO). I was just 
comparing the realities of two different environments and both in MSDC or 
medium sized DCs today we have *both* proprietary protocols and single vendor 
equipment is prevalent.
   I was just saying this is not the case in other case (cellular). 
Otherwise I agree with your observation.

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] IETF101 DMM WG Meeting Notes #1

[Uma Chunduri]

Hi Sri,

>
> I am really hoping we will be able to apply SRH insertion without the 
> need for IP encapsulation. At least for mobile environments within a 
> closed administrative domains, there should be exceptions for 
allowing 
> insertion of SRH by a on-path node.

While I see you intention to see a way to reduce the RFC8200 encap overhead; 
for mobile/cellular environments  I see its paramount to have a  standardized 
solutions because 
it's mostly multi-vendor equipment from most of the operators deployments. 
Regardless if it's a closed administrative domain or not.


However, it might be fine if it is an inside a DC (for example DC underlay) 
kind of  environment and  this exception could be made;
as the diversity of different vendor equipment can be less.


But the best course still would be to have this documented clearly and if 
possible do an update to RFC8200 @ 6man as pointed below by Tom.

--
Uma C.

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Tuesday, March 27, 2018 8:05 AM
To: Sri Gundavelli (sgundave) 
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Tue, Mar 27, 2018 at 7:17 AM, Sri Gundavelli (sgundave)  
wrote:
>
>
> On 3/26/18, 5:16 PM, "Tom Herbert"  wrote:
>
>>> With regards to SR encapsulation: "this is using IP-in-IP as default.
>>> Why not using UDP encapsulation?"
>>
>
> I am really hoping we will be able to apply SRH insertion without the 
> need for IP encapsulation. At least for mobile environments within a 
> closed administrative domains, there should be exceptions for allowing 
> insertion of SRH by a on-path node. I realize there are issues with 
> ICMP error messages hitting the source etc, but we should be able to 
> document those issues and specify work arounds. I understand there 
> have been discussions on this topic before, but I hope authors will 
> find some agreements for the same.
>
Sri,

There's been quite a bit of discussion on this on 6man list with reference to 
draft-voyer-6man-extension-header-insertion. The problem is that extension 
header insertion would violate RFC8200: "Extension headers (except for the 
Hop-by-Hop Options header) are not processed, inserted, or deleted by any node 
along a packet's delivery path".

In addition to the the protocol ramifications of doing this (dealing with MTU, 
ICMP error, etc.) there were questions as to whether the benefit is significant 
enough to justify the cost, as well as what does it mean to define Internet 
protocols that only work in a "controlled domain".

I believe 6man is the right place for further discussions on this.

Tom




>
> Sri
> 
>

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] some test results of different network overlay methods

[Uma Chunduri]

Great work, Thank you Kalyani & Tom.

2 quick questions:

1.  I presume SR inline is just SRH with 2 SIDs as mentioned - didn't see the 
topology used. Do intermediate nodes handle these SIDs, with pointer update in 
SRH?
2.  Also for Geneve  - it's IP4 encap and VNI no TLVs?

--
Uma C.


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bogineni, Kalyani
Sent: Friday, March 16, 2018 11:16 AM
To: dmm 
Subject: [DMM] some test results of different network overlay methods


All:

Here are some raw performance test results based on our understanding of the 
different network overlay methods. We welcome discussion and comments.

Kalyani and Tom
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt

[Uma Chunduri]

>A Big progress is that the draft supports interworking with GTP over IPv6 in 
>addition to GTP over IPv4.
>And we have made change SRv6 function to IPv6 encapsulation with SRH instead 
>of SRH insertion by default.

Good to see this and this addresses the RFC 8200 issue – but yes, little bit 
more overhead if you include encapsulating  IPv6 address and SRH with all the 
IPv6 SIDs.
We have just published LSR-WG individual draft which significantly reduce the 
SRH overhead at least with NSPF-ID=4 (v6 SRH data plane). Check this out.


https://www.ietf.org/internet-drafts/draft-ct-isis-nspfid-for-sr-paths-00.txt


This would be presented in IS-IS (LSR) WG and/or SPRING.


--
Uma C.


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Uma Chunduri]

>Let me think just an example, if a SMF sees an IPv6 address as an UPF 
address, is actually an IPv6 segment ID of a TE path through several IPv6 
routers and links, a southbound could be PCEP but not limited. 
>BGP-LS should work to disseminate that segment and FPC may 
work to disclose it to the SMF and the TE path would be attached mobility 
sessions by the SMF as if it is an UPF. 

Thx. 
I see what you are saying; this is after N3 termination and full charging, LI 
and bit rate enforcement is done and to move the packet on the provided TE path 
to the UPF on N9. 
My original question was more on SFC functionalities that ought to be done on 
N6 (I know the draft you pointed 
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00 and I 
still see that as alternative to NSH) and any of these have to be done on N9. 
The only thing I see is TE on N9.
I think, there is no bearing on SMF for Gi LAN stuff on N6.

--
Uma C.


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Uma Chunduri]

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Thursday, February 08, 2018 6:18 PM
To: Uma Chunduri <uma.chund...@huawei.com>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com>; Marco Liebsch <marco.lieb...@neclab.eu>; Dino Farinacci 
<farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Uma - It will support mobility scenarios similar to what SGW/PGW support in 4G.
[Uma]:  Yes, then ILA-N has to be on gNB  and ILA-R has to be on the UPF where 
N6 is there.
 But current draft suggests ILA-N on another UPF (perhaps BP 
UPF) and the address transformation between only between UPFs on N9. I don't 
see any mobility in that case..
 Perhaps you have to adjust the draft to move ILA-N to gNB. 
Yes, with this N3 comes into picture.

And will also support local access to the DN.
[Uma]: ??

Kalyani

From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, February 8, 2018 9:13 PM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Kalyani -

In-line [Uma]:

--
Uma C.

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Thursday, February 08, 2018 6:07 PM
To: Uma Chunduri <uma.chund...@huawei.com<mailto:uma.chund...@huawei.com>>; Sri 
Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; Marco 
Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Uma:

The goal of the white paper is to understand how each of the proposals impact 
N3, N4, SMF and gNB as is listed in Section of the white paper.
[Uma]: Absolutely. I got that. But I am not asking about the whitepaper below.
I am not getting which mobility scenario is covered by ILA 
proposal in the subject line if you don't include N3?


Here is the extract from Section 4 of the CT4 study item. They say that 
coordination with other working groups will be done as needed. So
documenting the proposals is important.


- from CT4 Study item 

As CT4 is not responsible for selecting the user plane protocol in the RAN 
(e.g. N3, F1-U), and since the user plane protocol in the 5GC cannot be decided 
irrespectively of the user plane protocol supported in the RAN, the study will 
have to involve coordination with RAN3.

Coordination will also be required with CT3 for potential impacts on N6, and 
with SA2 if the work has possible impacts on the stage 2 specifications.

-

Kalyani

From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, February 8, 2018 8:07 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Tom, Kalyani -

I fully agree what Sri said below.

>From Section 7.2 of the subject line:


 ---> --->--->
DN to ILA-R  ILA-R to ILA-N   ILA-N to gNB gNB to UE
   ++   ++   ++   ++
   | Application|   | Application|   | Application|   | Application|
   ++   ++   ++   ++
   | L4 |   | L4 |   | L4 |   | L4 |
   ++   ++   ++   ++
   |IPv6|   | IPv6 (ILA) |   |IPv6|   |  PDU Layer |
   ++ | ++ | ++   ++
   | L2 | | | L2 | | |   GTP-U|   | AN Protocol|
   ++ | ++ | ++   |   Layers   |
  || |   UDP/IP   |   ||
 N6   <

Re: [DMM] [Ila] [E] Re: Fwd: New Version Notification for draft-herbert-ila-mobile-00.txt

[Uma Chunduri]

Kalyani -

In-line [Uma]:

--
Uma C.

From: Bogineni, Kalyani [mailto:kalyani.bogin...@verizonwireless.com]
Sent: Thursday, February 08, 2018 6:07 PM
To: Uma Chunduri <uma.chund...@huawei.com>; Sri Gundavelli (sgundave) 
<sgund...@cisco.com>; Marco Liebsch <marco.lieb...@neclab.eu>; Dino Farinacci 
<farina...@gmail.com>
Cc: i...@ietf.org; dmm <dmm@ietf.org>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt


Uma:

The goal of the white paper is to understand how each of the proposals impact 
N3, N4, SMF and gNB as is listed in Section of the white paper.
[Uma]: Absolutely. I got that. But I am not asking about the whitepaper below.
I am not getting which mobility scenario is covered by ILA 
proposal in the subject line if you don't include N3?


Here is the extract from Section 4 of the CT4 study item. They say that 
coordination with other working groups will be done as needed. So
documenting the proposals is important.


- from CT4 Study item 

As CT4 is not responsible for selecting the user plane protocol in the RAN 
(e.g. N3, F1-U), and since the user plane protocol in the 5GC cannot be decided 
irrespectively of the user plane protocol supported in the RAN, the study will 
have to involve coordination with RAN3.

Coordination will also be required with CT3 for potential impacts on N6, and 
with SA2 if the work has possible impacts on the stage 2 specifications.

-

Kalyani

From: Uma Chunduri [mailto:uma.chund...@huawei.com]
Sent: Thursday, February 8, 2018 8:07 PM
To: Sri Gundavelli (sgundave) <sgund...@cisco.com<mailto:sgund...@cisco.com>>; 
Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: RE: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

Hi Tom, Kalyani -

I fully agree what Sri said below.

>From Section 7.2 of the subject line:


 ---> --->--->
DN to ILA-R  ILA-R to ILA-N   ILA-N to gNB gNB to UE
   ++   ++   ++   ++
   | Application|   | Application|   | Application|   | Application|
   ++   ++   ++   ++
   | L4 |   | L4 |   | L4 |   | L4 |
   ++   ++   ++   ++
   |IPv6|   | IPv6 (ILA) |   |IPv6|   |  PDU Layer |
   ++ | ++ | ++   ++
   | L2 | | | L2 | | |   GTP-U|   | AN Protocol|
   ++ | ++ | ++   |   Layers   |
  || |   UDP/IP   |   ||
 N6   <--N9 -->   N3 ++   ++
 |L2  |
 ++

If this were to be nextgen and seeking key benefits of ID/LOCs, I strongly 
suggest changing the content of the draft to make this fully anchorless i.e., 
including N3 else I am not seeing *any mobility* scenario  that is being solved 
by ILA.

As it stands - eNB/gNB mobility would be taken care by S1U/N3. Meaning both X2 
based and S1 based handovers/mobility (used 4G terminology, but I meant 
equivalent interfaces) is out of the scope for ILA.

If you were to bring in transformation concept (tunnel-free concept) or ILA-N 
it has to be on gNB not UPF (not even staging BP UPF).


Please tell me if my understanding is incorrect here. I have few more questions 
on the draft and shall wait.

--
Uma C.

From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Thursday, February 08, 2018 4:14 PM
To: Bogineni, Kalyani 
<kalyani.bogin...@verizonwireless.com<mailto:kalyani.bogin...@verizonwireless.com>>;
 Marco Liebsch <marco.lieb...@neclab.eu<mailto:marco.lieb...@neclab.eu>>; Dino 
Farinacci <farina...@gmail.com<mailto:farina...@gmail.com>>
Cc: i...@ietf.org<mailto:i...@ietf.org>; dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: Re: [Ila] [DMM] [E] Re: Fwd: New Version Notification for 
draft-herbert-ila-mobile-00.txt

HI Kalyani,


>  The adaptation from GTP to IP has to happen somewhere, either in the radio 
> node or in the UPF.

I guess when you say from "adaptation from GTP to IP", you mean to say GTP-U 
decapsulation of the user-plane IP packet for handling it by other protocols 
and for forwarding it on N9.

If N3 is untouched, then its the UPF that is doing that decapsulation a

Re: [DMM] [Ila] [E] Re: review comments on ] draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Uma Chunduri]

Hi Satoru,

Few questions in-line
--
Uma C.


-Original Message-
From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Thursday, February 08, 2018 1:00 AM
To: Bogineni, Kalyani 
Cc: i...@ietf.org; dmm 
Subject: Re: [Ila] [E] Re: review comments on ] 
draft-ietf-dmm-srv6-mobile-uplane-00.txt

[Snip..]

When it comes to service function type UPF, you name it. Following draft 
exhibits how service chain can be done by SRv6:
https://tools.ietf.org/html/draft-xuclad-spring-sr-service-chaining-00

[Uma]: I presume this is on N6 interface once de-capsulation is done at 
eventual UPF.  So can I say this is one more alternative to NSH ??
Do you see any relevance of this in any other interface?


...

> Also you show IPv6/SRv6 nodes in those slides. Are the UPFs ‘overlaid’ on 
> IPv6/SRv6 nodes?
> Are these UPFs VNFs? Or are UPFs implemented on IPv6/SRv6 nodes?
>  

When you see UPF specifically it should be controlled by SMF through N4, they 
are not the UPFs.
But you might see them as UPFs if a SMF doesn’t control them directly but the 
SMF can put the sessions to it through some other means.

[Uma]: Didn't quite understand. Are you referring southbound interface like 
PCEP here?
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] [Ila] Questions about SRv6 mobile user-plane

[Uma Chunduri]

There were several issues raised. I don't think fragmentation actually came up 
as one of them, but that is good point.
[Uma]:  Yes.
Intermediate nodes cannot fragment packets in IPv6.
…

- The proposal attempted to carve out an exception to RFC8200 for just SR and 
limited use to controlled domains. That entails many caveats an assumptions 
that would need to be MUSTs.

- Encapsulation is recommended to allow EH insertion and several people asked 
why not use it. It will work inasmuch as encapsulation within the network 
already works.

- If a host is already using extension headers and the network tries to add 
more, there is an ambiguity about which ones the.network is responsible for. 
When packet leaves the domain, the EH that the network added needs to be 
removed and it needs to be unambiguous which ones are to be removed.

- ICMP is a problem. If a host gets an ICMP error that contains extension 
headers that it did not possibly send then that will be confused. Presumably, 
ICMP errors will need to be stripped of EH before forwarding to a source node.

- PTB is interesting. For instance, EH insertion could force PMTU to drop below 
576 minimum.

- If the added extension headers are causing packet drops this is a major 
problem. The intermediate node that is inserting the EHs will never get 
feedback that its actions are doing harm. An end host might detect packet loss 
at the transport layer or might get an ICMP error (maybe something like  
draft-herbert-6man-icmp-limits-02),
 But, even if it knows that inserted EHs are causing drops, there's is no 
action a host can take to stop it. At least with encapsulation the tunnel 
ingress might get and ICMP error about what it's doing.

I suppose the primary argument against encapsulation is that it's too much 
overhead. But, I would point out that in the examples if only one sid is 
required for mobility (address of destination)  in an IP/IP encapsulation this 
would be the destination of the inner packet and SRH wouldn't be needed.
[Uma]: SRH in the proposal not only put a sort of mobility solution (encoded in 
the SID) but also use to guide the packet through non shortest path from the 
source as needed and as listed in the SRH.
   One of the assumption, I saw the discussion here, ILA and 5GIP 
seems to assume delivering the packet to the shortest path but this may not be 
necessary the case for lot of 5G slices and also tunneling in couple of cases 
is unavoidable (if you ought to overlay IPSec in few cases).
So encapsulation overhead = 40 bytes, SRH overhead = 20 bytes. I'm not sure 
that difference justifies the complexity of EH insertion.
[Uma]: If you include the above difference is not quite that. But re-encap 
seems lot safer for some of the points you raised above.

--
Uma C.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] FW: New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement"

[Uma Chunduri]

Sri,

Your summary is comprehensive as it includes DHCP & IKEv2 too though they 
didn't ask specifically.

For IKEv2 I see similar stuff needed for Config Payloads (for most of the 
attribute types), but not sure how this would be used in FMC cases (non-3GPP 
access).

--
Uma C.

-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli (sgundave)
Sent: Wednesday, January 31, 2018 1:15 PM
To: dmm@ietf.org
Subject: Re: [DMM] FW: New Liaison Statement, "LS on indicating service 
continuity usage of the additional IPv6 prefix in Router Advertisement"


Based on the feedback and some offline discussions with Danny and others, here 
is the response with some corrections. Please comment.


 




Dear 3GPP SA2 Chair:


Thank you for your LS query (Reference:
https://datatracker.ietf.org/liaison/1554/). The IETF DMM working group has 
reviewed the LS statement and below is our response.


In our view, the work-item described in the LS query has three components:



1.) The approach of coloring IPv4 and IPv6 addresses/prefixes with mobility 
properties.

This is about standardizing IP address address/prefix ³types". Each ³type"
has a certain behavior that the network is expected to provide. Section 3.1, of 
draft-ietf-dmm-ondemand-mobility-13 defines the following four address types, 
which are applicable to both IPv4 and IPv6 addresses and prefixes. 

#a. Fixed IP Address
#b. Session-lasting IP Address
#c. Non-persistent IP Address
#d. Graceful Replacement IP Address


These modes, #a, #b, #c,and #d can be mapped to the 3GPP SSC modes 1, 2 and 3.

We are happy to report that this work-item is on track to become an 
³informational standard", and will most likely will hit IESG very soon.



We kindly request 3GPP to provide any feedback that you may have on this draft.




2.) The approach of network including property meta-data in address assignment 
procedures

There are multiple mechanisms for address configuration delivery to the
end-host:

#a.) DHCPv4
#b.) DHCPv6
#c.) IPv6 ND (PIO Options, others ..etc)
#d.) IKEv2 Address Configuration Options


There are many proposals on this including:

https://www.ietf.org/id/draft-feng-dmm-ra-prefixtype-01.txt
https://www.ietf.org/id/draft-moses-dmm-dhcp-ondemand-mobility-08.txt

Also, some proposals from the previous years:

https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-ndp-support-03.txt
https://www.ietf.org/archive/id/draft-ietf-mif-mpvd-id-02.txt
https://www.ietf.org/archive/id/draft-bhandari-dhc-class-based-prefix-05.tx
...


Currently, these documents are under review in the IETF DMM WG. However, the 
DMM working group has not chosen any specific draft as WG document.
Given the interest from 3GPP for this work, we will try to accelerate the 
document selection process and will try to move this work forward. This is 
subject to finding consensus for taking up this work.

We also like to point out that, all though the LS statement explicitly refers 
to both IPv4 and IPv6 address types, however it only mentions about
(RA) (IPv6 ND implied) as the mechanism for address property delivery. It is to 
be noted that the approach of delivering coloring meta-data in RA messages will 
most likely be to limited to IPv6 address/prefix types and will not be extended 
to IPv4 addresses. If this capability is required for IPv4, we may have to 
possibly extend DHCP protocol(s).


We kindly request SA2 to clarify if the Ask is explicitly for IPv6, or if its 
for both IPv4 and IPv6 address/prefix types.




3.) The approach of indicating the coloring meta-data to the applications on 
the mobile node (UE in 3GPP terminology).

This is about extending socket interface with the property tags. This is 
covered in draft-ietf-dmm-ondemand-mobility-13,

We are happy to report that this work is on track to become an ³informational 
standard", and will most likely will hit IESG very soon.


We kindly request 3GPP to provide any feedback that you may have on this draft.





Regards
Dapeng Liu and Sri Gundavelli
(Chairs IETF DMM Working Group)


---



>
>


>
>
>On 1/16/18, 2:45 PM, "Liaison Statement Management Tool"
>
>wrote:
>
>>Title: LS on indicating service continuity usage of the additional
>>IPv6
>>prefix in Router Advertisement
>>Submission Date: 2018-01-16
>>URL of the IETF Web page: 
>>https://datatracker.ietf.org/liaison/1554/
>>
>>From: Chang hong 
>>To: Sri Gundavelli ,Dapeng Liu 
>>,Terry Manderson 
>>,Suresh
>>Krishnan ,Robert Hinden 
>>,Ole Troan 
>>Cc: Dapeng Liu ,Terry Manderson
>>,IPv6 Maintenance Discussion List 

Re: [DMM] [Ila] Questions about SRv6 mobile user-plane

[Uma Chunduri]

Comments are spot-on.

Can somebody tell 8200 update would be a possibility in future (w.r.t 6man 
consensus) i.e., EH insertion in the middle without re-encapsulating the SRH 
again.
I presume the technical aspect for the 8200 mandate is the ability to fragment 
if needed at the insertion point. Anything else?  Please enlighten..

Hence, most significant issue has to be resolved perhaps would be the first 
item.


BR,
--
Uma C.

From: ila [mailto:ila-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: Friday, January 26, 2018 9:14 AM
To: dmm@ietf.org; i...@ietf.org
Subject: [Ila] Questions about SRv6 mobile user-plane

Hello,

I am working on a comparison between ILA and SRv6 for the mobile user-plane. I 
have some questions/comments about SRv6 and particularly on the example use 
cases that were depicted in the slides that were presented in IETF100:

https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/

- It's clear from the depicted use cases that extension header insertion is 
being done by intermediate nodes, but extension header insertion is currently 
prohibited by RFC8200. There was an I-D posted on 6man to allow this for SR, 
but that was met with pushback. Is there going to be followup to resolve this?

- For the uplink use cases, this seems to be more like using SR to source route 
to an egress router. In other words, it's not strictly related to mobility. Is 
there some connection to mobility that I'm missing?

- The size or number of SR headers in the uplink cases seems to be larger than 
necessary (IMO minimizing these is important since each additional sid is ~1% 
overhead of standard MTU). In this first scenario sid[1]=A2::1 and DA=A2::1-- 
this seems to be redundant information. Also this depicts a second SR being 
inserted, but the first one should no longer be relevant. Why not just discard 
the first one and save the overhead? In the second scenario, DA is changing 
from A2::1 to A3::1, but AFAICT that was not done per the SR processing. What 
is the operation that happened here? (it's actaully looks like an ILA 
transfomation).

- Considering the points above, could this have been done in the following 
manner to minimize overhead? A1 creates one SRH with one sid and makes DA=A2. 
A2 makes DA=A3. At A3 SR is processed, DA is restored to Internet address, and 
EH is removed.

- For downlink this does see to be relevant to mobility. But I have the same 
question, wouldn't it be less overhead to only use one SRH and one sid? i.e. A3 
creates an SRH with just one sid that is the S:: (identifier in 
identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, A1 
restores original packet for delivery.

- One possible typo. In the last use case slide SA=S:: and DA=D::, I believe 
these should be swapped?

Thanks,
Tom




___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm