Hi Eduard,
It seems you completely misunderstood the scope of the work and what
needs to be done at gNodeB.
Also I recommend you to the conversations and suggestions from many DMM
participants in IETF105/106 to see where we are now.
I can't replay all the discussion back here. But -
- There are various operators seeking to keep transport
agnostic to mobile side of the network
- There are various network segments where GTP-U is used i.e.,
in F1U, N3, N9 and these segments can have L2, IPv4, IPv6, SRv6, MPLS etc..
You are mixing what has to be done on PE-PE on these segments (VPN+, SRv6,
MPLS etc) to what has to be done on gNodeB.
gNodeB doesn't want to know all the transport network details and slew of
possible encapsulations options available currently and/or being developed.
more in-line [Uma]
--
Uma C.
On Mon, Aug 16, 2021 at 2:20 AM Vasilenko Eduard <
[email protected]> wrote:
> Hi Uma,
>
> The mechanism itself (use UDP source port range for forwarding decision)
>
[Uma]: You misunderstood this completely. This is not for forwarding
decision. It just indicating the slice the packet belongs to from the
cellular side (any UP function); so that the PE can do the right mapping to
the transport path which can offer those characteristics.
> looks questionable,
>
> Because in the case of IPv6 data plane it would be difficult to parse IPv6
> EH headers chain up to UDP, especially if SRH 200B+ header would be in
> between
>
[Uma]: gNodeB will not get into transport network and the path information
that has to be encoded in the SRH or MPLS currently. If you really want
that, you can try bringing that to 3GPP. Today there is a separation
between these two for many reasons (some are good and some are bad but
there for backward compatibility).
> , potentially with Authentication header and Encapsulation Security
> payload header on top that is very probable in MBH environment. I do not
> know any ASIC that could parse all of this in the worst-case scenario.
>
> IMHO: this mechanism looks good only for IPv4 where UDP directly follows
> IPv4 header.
>
[Uma]: Yes, native IPv4 and IPv6.
> What you need here is some VPN+ (resources reservation in TEAS
> terminology).
>
> There is a dispute right now in 6man about the introduction of an
> additional header to show resource attachment.
>
> MPLS guys push strongly that it should be Label. SR guys insist on SID.
> Jimmy (and a few others) proposes something
> new/small/independent/just_for_this_purpose.
>
>
>
[Uma]: I agree with that. But as I said above please don't mix things on
what has to be done on PE and what has to be done on cellular endpoints.
TEAS clearly said they don't want to dictate anything on the cellular
endpoints.
In general, I see in this draft an extremely high intersection with the
> Slicing story. It looks like yet another one (UDP port-based).
>
> I have put Jimmy on the copy because he knows what is available in 3GPP on
> slicing.
>
[Uma]: Yes, Jimmy is aware of this and had multiple comments last year and
Q1 2021.
>
>
> But it does not matter: if nobody pushing a particular type of VPN+ in
> 3GPP – it would not happen anyway. gNodeB just would not label the packet
> properly.
>
[Uma]: You are right.
>
>
> Eduard
>
> *From:* Uma Chunduri [mailto:[email protected]]
> *Sent:* Saturday, August 14, 2021 5:30 AM
> *To:* Vasilenko Eduard <[email protected]>
> *Cc:* Majumdar, Kausik <[email protected]>; RTGWG <
> [email protected]>
> *Subject:* Re: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility
> draft
>
>
>
> Eduard,
>
>
>
> Very good question.
>
>
>
> Let me tell you a bit more and give context on this. For E2E desired
> traffic characteristics, where the packet is transiting through RAN,
> transport and 5G Core, there is some coordination and minimal exchange of
> information is needed. In this case, it happens to be touching 2 SDOs and
> utmost care is taken (over many individual versions) to minimise those
> changes and still acceptable to deployments (management plane). In this
> case, there are 2 3GPP delegates being co-authors enhanced carefully, but
> still it's in a grey area where we need full blessing from 3GPP or what's
> needed. For example changing UDP encap parameters were done and deployed
> (yes), in earlier instances without having to specifically mention in
> 23.401 (LTE). Further we did think about it to be part of the latest study
> item (ongoing discussion with SA2 delegates) and also some discussions
> happened in DMM to liaise further, with their official channel.
>
>
>
> It doesn't matter if I answer your question fully or partially or not at
> all, but this is what happened on this one. I would say one thing further,
> no matter this work or in a different form you need to have a mechanism to
> signal stuff from other SDO's domain to us to fully define the slicing work
> E2E. I don't see another way.
>
>
>
> --
>
> Uma C.
>
>
>
> On Thu, Aug 12, 2021 at 1:59 AM Vasilenko Eduard <
> [email protected]> wrote:
>
> Hi Uma,
>
> Yes, indeed, section 2.5 of
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility
>
> has a detailed explanation of how “port range” **may be** mapped into “Mobile
> Transport Network Context”.
>
> By the way, such abbreviation (*MTNC*) is not available in 3GPP TS 23.501.
>
>
>
> I could not imagine how else it is possible to tell about “port range”
> without “range”.
>
> I have looked at all “range” in 3GPP TS 23.501 – it is not about what we
> need here.
>
>
>
> “Indirect next hop” reference is not typical in SDOs publications.
>
> If you need some functionality from Mobile guys – you need to reference
> 3GPP directly, not through other IETF documents,
>
> especially if this other document does not have a direct reference too.
>
>
>
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility is
> written in such a style like it is a proposition.
>
> Looking at the text I come even to more suspect that this functionality is
> not requested in any 3GPP spec. Hence, may never be implemented in any
> gNodeB.
>
>
>
> Does not matter who was the first in IETF to request this functionality
> and who is just cross-reference it in “indirect next hop” style.
>
> I still have a question: Who has taken responsibility to push this
> requirement inside 3GPP?
>
>
>
> Direct reference to a particular section of any 3GPP document would
> disperse my doubts.
>
>
>
> Because if nobody is pushing this inside 3GPP then it would never happen,
> independent of how many times this functionality would be cross-referenced
> inside IETF.
>
>
>
> Eduard
>
> *From:* Uma Chunduri [mailto:[email protected]]
> *Sent:* Thursday, August 12, 2021 3:21 AM
> *To:* Vasilenko Eduard <[email protected]>
> *Cc:* Majumdar, Kausik <[email protected]>; RTGWG <
> [email protected]>
> *Subject:* Re: IETF 111 follow-up on rtgwg-extension-tn-aware-mobility
> draft
>
>
>
> Hi Eduard,
>
>
>
> in-line [Uma]:
>
>
>
> --
>
> Uma C.
>
>
>
> On Wed, Aug 11, 2021 at 12:54 AM Vasilenko Eduard <
> [email protected]> wrote:
>
> Hi Kausik,
>
> As a result of the discussion following my question, it has been
> understood that it is not just your assumption that gNodeB would use
> different source UDP port range for different application.
>
> Jeff Tantsura was even immediately taken from the thin air 3GPP TS 23.501
> that makes sense to reference as normative.
>
> What is still important to understand: is this requirement mandatory for
> gNodeB implementation?
>
>
>
> [Uma]: Yes. This is much debated and documented in
> https://datatracker.ietf.org/doc/html/draft-ietf-dmm-tn-aware-mobility
>
> The approach taken there is management plane or AF related
> changes (as opposed to any change in the 3GPP control plane). These are by
> definition deployment specific and many
>
> deployments have knobs to do this.
>
>
>
> If yes, then excellent – just reference and abuse.
>
> If not, then how many vendors implemented it? Because it is a
> pre-requisite for you.
>
>
>
> [Uma]: For many "LTE slicing" (if I may allow to be used, as it has become
> sort of abusive word) deployments today use UDP source port as those nodes
> can't be upgraded with new data planes with many bells and whistles (it's
> noble, please go ahead and use those and let gNodeBs emit those
> eventually). And also remember, it doesn't help to put that information in
> GTP overlay (IEs or extension headers), for the ingress PE to look into to
> and act accordingly. All these options were discussed many times in the DMM
> WG and was presented last year.
>
>
>
> The reference to any IETF draft would not help if functionality is needed
> from gNodeB.
>
> Eduard
>
> *From:* rtgwg [mailto:[email protected]] *On Behalf Of *Majumdar,
> Kausik
> *Sent:* Wednesday, August 11, 2021 4:07 AM
> *To:* RTGWG <[email protected]>
> *Subject:* IETF 111 follow-up on rtgwg-extension-tn-aware-mobility draft
>
>
>
>
>
> Hi All,
>
>
>
> I have presented our draft draft-mcd-rtgwg-extension-tn-aware-mobility-02
> <https://datatracker.ietf.org/doc/html/draft-mcd-rtgwg-extension-tn-aware-mobility-02>
> in the IETF 111 on behalf of other co-authors. There are some questions and
> comments in the IETF for this presentation. We felt it would be good to
> review those comments over email thread to sort those out.
>
>
>
> Here are the different comments we have captured – it was either through
> Meetecho session chat window or over direct Q&A after the presentation.
> Please feel free to add any other comments you have.
>
>
>
> *@Jeff Tantsura*
>
> 3GPP TS 23.501; System architecture for the 5G System (5GS) - a good
> reference13:39:32
>
>
>
> KM>> Thanks Jeff. We will capture this reference in the next version of
> the draft.
>
>
>
> *@Jie Dong*
>
> my understanding is this (UDP source port) may be one of the options to
> map 3GPP SSTs or slices to transport network, there is a draft about the
> network slice mapping in teas WG: draft-geng-teas-network-slice-mapping
> which analyzed several options. That said, some coordination with 3GPP may
> be needed on which field they will use to for the mapping.
>
>
>
> KM>> Yes, UDP Source Port is simply one of the option to map 3GPP SSTs or
> slices to the transport network. The existing dmm draft -
> *draft-ietf-dmm-tn-aware-mobility-00* uses UDP source port range to
> define the different SSTs (MIOT, URLLC, EMBB, etc) in the Mobile Network
> and here we are extending the same mechanism in the Data Network as part of
> the RTG draft.
>
>
>
>
>
> *@Eduard*
>
> Why only UDP Source Port is being used for the Traffic Characterization in
> the Mobility and Data Networks?
>
>
>
> KM>> The GTP Tunnel inner packet can carry any L4-L7 packet types (TCP,
> UDP, QUIC) and that can continue in the Data Network, there is no such
> restriction on that. But when comes to packet characterization we have
> tried to keep the mechanism consistent across the Mobile and Data Network.
> As in the Mobile Network the UDP Source Port range is being used for
> characterizing different SSTs we have extended the same in the Data Network
> so that end to end SLA is maintained for the UE traffic.
>
>
>
> *@Cheng*
>
> Why there are multiple mapping methods is proposed in the Data Network?
>
>
>
> KM>> We believe that multiple mapping method in the Data Network provides
> the Operators flexibility in the mapping mechanism. Based on the deployment
> model the Operators should be able to characterize the traffic belongs to
> different SSTs and map to the corresponding SLA driven path based on the SR
> driven policies.
>
>
>
> *@Acce*
>
> Two questions:
>
> 1. Same as Cheng.
> 2. Why is SDWAN with Security treated as a separate Use Case? Why not
> be Security appliable in the regular SR-TE Network?
>
>
>
> KM>> We have kept SDWAN as a separate Use Case for the Enterprise 5G. Here
> Mobile traffic ending up going through the Enterprise GW/CE device. These
> traffic mostly destined to the Cloud GW to access different SaaS
> applications. The SDWAN CE devices generally provide different Tunneling
> mechanism for taking the traffic in a secure fashion to the Cloud GW. Hence
> security is considered as important characteristics for the Mobile traffic
> to go over SDWAN network to the Cloud GW and given a priority in terms of
> choosing the appropriate SDWAN tunnels.
>
>
>
> On the other side, when the Mobile traffic comes to the Ingress PE node
> there traffic goes over provider VPN network and that’s a secure network in
> general. In that network, characterizing the different SSTs and maintaining
> the SLA specific to each SST is more important.
>
>
>
> We felt keeping it two separate use cases one for carrier SR-TE network
> and the other one for the SDWAN type of deployment scenarios, the mapping
> mechanism clarifies it better.
>
>
>
> If you have further comments/questions please let us know and we can
> discuss that further.
>
>
>
> Regards,
>
> Kausik
>
>
>
> _______________________________________________
> rtgwg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
