On Wed, Jul 18, 2018 at 1:44 PM, Pablo Camarillo (pcamaril) <pcama...@cisco.com> wrote: > Uma, > > > > Inline. [PC1] > > (Thanks for the clear list of points to address. It does help.) > > > > Cheers, > > Pablo. > > > > From: Uma Chunduri <uma.chund...@huawei.com> > Date: Wednesday, 18 July 2018 at 12:52 > To: "Pablo Camarillo (pcamaril)" <pcama...@cisco.com>, Arashmid Akhavain > <arashmid.akhav...@huawei.com> > Cc: "dmm@ietf.org" <dmm@ietf.org>, "Alberto Rodriguez Natal (natal)" > <na...@cisco.com>, "spr...@ietf.org" <spr...@ietf.org> > 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 > Pablo,
I'm not sure that's relevant to discussion on an encapsulation dataplane. SIDs are 128 bit values that are in the IPv6 address space, and if a SID is place in a destination IPv6 address then it must be routable to a node in the network. Wrt encapsulation, if it's any more complex than that, then I'm missing something fundamental about segment routing. > PC1: It might be IP-in-IP as long as the inner header is not Ethernet or > Unstructured PDUs (3GPP PDU types). > If it's not IP-IP, then what is it? The draft states that in traditional mode: "gNB only adds an outer IPv6 header with IPv6 DA U1::1." This implies that foo over IP can be used if there is a protocol number for it (e.g. IPv[46]/IPv6, GRE/IPv6, MPLS/IPv6, etc.). But what does this mean in the case of unstructured PDUs? How are those encapsulated? Please clarify, or provide the reference to the exact format of encapsulation protocols being used with SR. > 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. > Okay, but I don't see how the protocol is processed changes the fact (at least that I think is a fact) that the solution is using IP-IP, or maybe foo-over-IP in some cases as above, as the encapsulation and that is the on-the-wire protocol in use. Tom > > > 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. _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
