"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 <zzhang= [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dmm >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
