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.


From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Pablo Camarillo (pcamaril)
Sent: 10 April 2018 03:27
To: Kentaro Ebisawa <ebike...@gmail.com>; dmm <dmm@ietf.org>
Subject: Re: [DMM] Next Header in End.M.GTP6.D 

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.


From: dmm <dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org>> on behalf of 
Kentaro Ebisawa <ebike...@gmail.com<mailto:ebike...@gmail.com>>
Date: Wednesday, 4 April 2018 at 11:08
To: dmm <dmm@ietf.org<mailto:dmm@ietf.org>>
Subject: [DMM] Next Header in End.M.GTP6.D 


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 

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.

Kentaro Ebisawa <ebike...@gmail..com><mailto:ebike...@gmail.com>
dmm mailing list

Reply via email to