Subject: Re: [DMM] SRv6 for Mobile User-Plane

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 1 Mar 2018 19:13:52 +0000

Thank you Tom.  

I do not know, if this is a consideration that will go into security
section, or if an alternative exists. But, we will track this issue in the
issue tracker. We will ask 6man chairs and the AD to comment on this.

All - Please comment on these technical issues. We cannot ignore these
comments.

Sri

On 2/26/18, 12:24 PM, "dmm on behalf of Tom Herbert" <[email-masked]
on behalf of [email-masked]> wrote:

>That draft received substantial pushback on 6man list. EH insertion is
>not allowed by RFC8200 and a host of points were raised why it
>shouldn't be allowed. The authors have not responded to this feedback
>yet. Also, IMO, the argument that it's okay to do this within a
>controlled domain is weak, such an argument could be used to pretty
>much justify anything one might do with protocols.
>

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 2 Mar 2018 14:39:09 -0500

Hi Pablo,

Let me focus on one point.

> [...snip...]

>    
>     >  
>     > Uplink
>     > Note: S1, S2 represent service functions and C1 represents a node for TE purposes
>     > UE sends its packet (A, Z) on a specific wireless bearer to its gNB
>     > gNB’s CP associates the session from the UE (A) with IPv6 address B and TEID T (N2 interface unchanged)
>     > gNB_out: (gNB, B) (GTP: TEID T) (A, Z)                       ;; Interface N3 is unchanged
>     > SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z)       ;; new End.GTP.UP
>     > S1_out: (SRGW, C1) (U2::1, C1; SL=1)(A, Z)
>     > C1_out: (SRGW, U2::1) (A, Z)                                      ;; assuming PSP
>     > UPF2_out:  (A, Z)                                                        ;; End.DT
>     >  
>     
>     Don’t you need to care about TEID at SRGW in aggregate mode?
>     I think it is okay for uplink in basic mode since it allocates SID per tunnel.
> [PC]: For the basic mode, yes it is ok. For the aggregate mode, we can ignore the TEID since we don’t have scaling issues on the BSID. A BSID is an indirecton to an SR policy, and hence we can have many BSIDs pointing to the same SR policy. Hence I would not expect any scalability issue here.

That’s interesting. But using T.Encap would be also one of your intent to support IPv4 PDU case, right?
If it’s right, U2::1 doesn’t indicate specific one single session in this case so that it won’t work for IPv4 PDU case IMO.

And there’s also an interesting point in the packet flow that the SRGW uses S1 as the first SID but it doesn’t exist in SRH while the SL=2 points S1.
It sounds a good solution to save overhead size. Is it acceptable SRH handling in terms of SRv6 spec?

Cheers,
--satoru