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 _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
