Re: [spring] Comment on SRv6-mobile-userplane

["Pablo Camarillo (pcamaril)" <[e-mail]>]

Uma,

Inline. [PC1]
(Thanks for the clear list of points to address. It does help.)

Cheers,
Pablo.

From: Uma Chunduri <[e-mail]>
Date: Wednesday, 18 July 2018 at 12:52
To: "Pablo Camarillo (pcamaril)" <[e-mail]>, Arashmid Akhavain <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Alberto Rodriguez Natal (natal)" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: RE: Comment on SRv6-mobile-userplane

Hi Pablo,

>As I already clarified in my previous email, the proposal of draft-ietf-dmm-srv6-mobile-uplane is independent from the underlay network.
Great. Thanks.
>As I already said in my previous email, we will clarify this in the next revision of the draft.
Sure.

Btw, you responded to Arash’s comments addressing me.

Some parts of the draft already maintained that independence with SRv6 features in underlay (for example Section 5.3).
In summary if you could address:


1.      Section 5.1 Traditional mode (Tom’s comment on terminology and IP-in-IP with no relation to SR?)

PC1: Tom, please read https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05#section-3
PC1: It might be IP-in-IP as long as the inner header is not Ethernet or Unstructured PDUs (3GPP PDU types).
PC1: When its IP-in-IP the destination address is an SRv6 SID and is processed differently at the destination than an interface address. See 4.8-4.12 of draft-filsfils-srv6-network-programming.


2.      Section 5.2 Enhanced mode. Here SR path steering features are used

PC1: The enhanced mode exemplifies the case where a given provider wants to leverage SR for the overlay (as in Traditional mode but with session aggregation -see next note-; but also SP wants to leverage SR for underlay control and service programming.
PC1: In such example, the gNB can steer incoming traffic into an SR policy that contains SID for these three things. The benefit of this use-case is that the provider achieves end-to-end network slicing, spanning N3, N6, N9 as well as the transport network.
PC1: Notice that there might be different cases
1.- Overlay with session aggregation
2.- Overlay with session aggregation and underlay TE
3.- Overlay with session aggregation, underlay TE and service programming
4.- Overlay with session aggregation and service programming

and not fully described what happens to TEID (as GTP is gone).
PC1: Enhanced mode uses PDU session aggregation. There is not a single TEID per PDU Session. Instead, several PDU Sessions are aggregated. The set of sessions aggregated are still identified by the SID (in 5.2.1 corresponds to SID U2::1)
PC1: Each set of aggregated sessions uses a different SRv6 SID.
PC1: This is the main difference in between traditional mode and enhanced mode.
PC1: The aggregation is similar for the other proposals discussed in draft-bogineni-dmm-optimized-mobile-user-plane


3.      And if TEID after GTP removal is encoded in each SID in the SRH or this is only specific to some PDU session as you indicated in your first email.

PC1: In the traditional mode, the TEID for each PDU Session is encoded as an SRv6 SID. This can be done by two means, either by directly encoding the TEID in the SRv6 SID, or by using a unique SRv6 SID for each TEID (one-to-one mapping in between SRv6 SID and TEID). (feedback is welcome on preferred option)
PC1: In the enhanced mode, several PDU sessions are aggregated. All the set of aggregated sessions share the same SRv6 SID. A different set of aggregated sessions uses a different SRv6 SID.

Thx!
--
Uma C.