Hi Pablo, We might need to add some clarification w.r.t state reduction as well and explain this in the context of different modes.
Cheers, Arashmid From: dmm [mailto:[email protected]] On Behalf Of Pablo Camarillo (pcamaril) Sent: 10 April 2018 03:27 To: Kentaro Ebisawa <[email protected]>; dmm <[email protected]> Subject: Re: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01) Hi Kentaro, You are right. For each PDU session type you will have a different instance of an End.M.GTP6.D SID. We can add a note in the next revision of the draft in case this is not clear. Thank you. Cheers, Pablo. From: dmm <[email protected]<mailto:[email protected]>> on behalf of Kentaro Ebisawa <[email protected]<mailto:[email protected]>> Date: Wednesday, 4 April 2018 at 11:08 To: dmm <[email protected]<mailto:[email protected]>> Subject: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01) Hi, In "6.2. End.M.GTP6.D", how would SR Gateway know if user packet inside GTP is IPv4 or IPv6? I think this info is required to set newly added SRH.NextHeader field in step 3~5. My understanding is that information would be provided by the control plane, and if that's correct, should SR Gateway have 2 (or more) SIDs corresponding to the type of user packet and also inform gNB to use different SIDs (dstAddr) based on user packet type? One could also have SID per TEID, but I'm not sure if that's a good design choice considering the effort to reduce state in network nodes. Thanks, -- Kentaro Ebisawa <[email protected]><mailto:[email protected]>
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
