Subject: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01)

From: Kentaro Ebisawa <[email-masked]>
Date: Wed, 4 Apr 2018 16:07:59 +0900

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-masked]> <[email-masked]>

---

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Tue, 10 Apr 2018 07:27:01 +0000

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-masked]> on behalf of Kentaro Ebisawa <[email-masked]>
Date: Wednesday, 4 April 2018 at 11:08
To: dmm <[email-masked]>
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 <ebiken.g@gmail..com><mailto:[email-masked]>

---

From: Arashmid Akhavain <[email-masked]>
Date: Tue, 10 Apr 2018 15:45:02 +0000

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-masked]] On Behalf Of Pablo Camarillo (pcamaril)
Sent: 10 April 2018 03:27
To: Kentaro Ebisawa <[email-masked]>; dmm <[email-masked]>
Subject: Re: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01)

Hi Kentaro,

Thank you.

Cheers,
Pablo.

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Kentaro Ebisawa <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 4 April 2018 at 11:08
To: dmm <[email-masked]<mailto:[email-masked]>>
Subject: [DMM] Next Header in End.M.GTP6.D (draft-ietf-dmm-srv6-mobile-uplane-01)

Hi,

Thanks,

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 11 Apr 2018 16:25:49 +0200

Hi Arashmid, 

Yes, it needs to be clarified. Here I think that in terms of GTP-U over IPv6 case, gNB could be signaled a remote IPv6 endpoint address to which the SRGW binds a SID with appropriate payload type, such as IPv4/IPv6/Ethernet. In enhanced mode the SID doesn’t need to be allocated per session basis.

Wrt supporting unstructured PDU type, we may need to clarify which NH type to be used to carry over IPv6.

Cheers,
--satoru

> 2018/04/10 17:45、Arashmid Akhavain <[email-masked]>のメール:
> 
> Hi Pablo,
>  
> Kentaro Ebisawa <ebiken.g@gmail..com>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm