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
