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. 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. 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. 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. 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:[email protected]] Sent: Thursday, August 19, 2021 4:29 AM To: Vasilenko Eduard <[email protected]> Cc: Majumdar, Kausik <[email protected]>; RTGWG <[email protected]>; Dongjie (Jimmy) <[email protected]> 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.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
