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

[Vasilenko Eduard <[e-mail]>]

Hi Uma,
“Slice ID” is like “DSCP” – should be in the basic header or very close to.
Maybe you are right: “unified Slice ID” is a too big challenge to push inside IETF, even more challenge to add 3GPP on the list. Because IETF is fragmented on different WGs, “unified slice ID” should be pushed in many that is “mission impossible”.
Then everybody would develop his own “Slice ID”: MPLS, SRv6, UDP port range, VLAN. Every box should support all types of “Slice ID” encoding for the gateway function.
And then would be slow slicing adoption on the market. Slicing would need a much bigger business case to develop, test, and support all these permutations.
IMHO: Slicing is dead under such circumstances.
Eduard
From: Uma Chunduri [mailto:[e-mail]]
Sent: Tuesday, August 24, 2021 6:10 AM
To: Vasilenko Eduard <[e-mail]>
Cc: [e-mail]; Majumdar, Kausik <[e-mail]>; RTGWG <[e-mail]>; Dongjie (Jimmy) <[e-mail]>
Subject: Re: What is the slice ID in MBH?

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]<mailto:[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]<mailto:[e-mail]>]
Sent: Thursday, August 19, 2021 4:29 AM
To: Vasilenko Eduard <[e-mail]<mailto:[e-mail]>>
Cc: Majumdar, Kausik <[e-mail]<mailto:[e-mail]>>; RTGWG <[e-mail]<mailto:[e-mail]>>; Dongjie (Jimmy) <[e-mail]<mailto:[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.