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

[Uma Chunduri <[e-mail]>]

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 <
[e-mail]> 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:[e-mail]]
> *Sent:* Thursday, August 19, 2021 4:29 AM
> *To:* Vasilenko Eduard <[e-mail]>
> *Cc:* Majumdar, Kausik <[e-mail]>; RTGWG <
> [e-mail]>; Dongjie (Jimmy) <[e-mail]>
> *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).
>
> IMHO: it was a bad choice to choose the UDP port as the slice ID just
> because it is buried so deep in the packet (a huge chain of heads should be
> parsed before).
>
> It would need to duplicate Slice ID in something that would be close to
> the packet head. UDP port range would be not useful anyway.
>
>
>
> [Uma]: You are asking the question differently (earlier you said with SRH,
> 128 bytes can be crossed). I responded
> https://mailarchive.ietf.org/arch/msg/rtgwg/854WAs6ZxVvgFiGdkQ5vxgaa-tU/
>
> Remember gNodeB is emitting the is't time with GTP-U (with IPv6 and if any
> other EH, other than topology related) and this can be handled and by the
> sender and the incoming PEs with other EHs (if any) for ages (nothing is
> free).
>
>
>
>
>
> You continue pointing that this decision is made by
> draft-ietf-dmm-tn-aware-mobility, you just use it as the given. It looks
> like you push this discussion to the draft that you consider as the
> “parent”.
>
> You are partially right (but Uma is the 1st in the list of authors
> draft-ietf-dmm-tn-aware-mobility).
>
> I am asking in the wrong place (should be different WG) and at the wrong
> time (should be the discussion about draft-ietf-dmm-tn-aware-mobility).
>
> [Uma]:  Yes. I don't have much to add here any more.
>
>
>
>
>
> --
>
> Uma C.
>
>
>
>