Satoru, Thanks for the responses. In the Enhanced mode - section 5.2, it is still not clear (if or) how multiple UPFs on path would be programmed. 23.501, 5.6.4 discusses about a single PDU session with multiple PDU Session anchors. What would the SR path look like: gNB --> UPF1 --> UPF2 (2 segments), or would UPF1 fns (ULCL/branching point) be somehow programmed at the source (gNB/UPF2): - how would filters at ULCL UPF be programmed to steer traffic to local DN. - similarly branching point UPF for traffic measurement, charging, LI, multi-homing.
Would be good to address it in the draft. John -----Original Message----- From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert Sent: Tuesday, March 13, 2018 10:09 AM To: Satoru Matsushima <satoru.matsush...@gmail.com> Cc: dmm <dmm@ietf.org> Subject: Re: [DMM] Fwd: I-D Action: draft-ietf-dmm-srv6-mobile-uplane-01.txt On Mon, Mar 12, 2018 at 10:57 PM, Satoru Matsushima <satoru.matsush...@gmail.com> wrote: > Dear Sridhar, > > It’s nice to see you in DMM list as well. :-) > >> [...snip...] > > >> 1. Section 5.2.2 of the draft says, >> >> UPF2_in : (Z,A) -> UPF2 maps the flow w/ >> SID list <C1,S1, gNB> >> >> When the packet arrives to the UPF2, the UPF2 will map that >> particular flow into a UE session. >> >> Does this mean the UPF2 is aware of the gNB the UE is latched on and hence >> after each mobility, the information regarding current gNB is signaled / >> programmed till the UPF2 (which could be the PDU session anchor UPF)? > > Right. It’s equivalent with GTP-U case where there’s no N9 along the path. > One significant difference between GTP-U and enhanced mode is that the > packets of PDU sessions which belong to a same SR policy will use same set of > SIDs in the header. > > >> >> 2. For traditional mode (basic mode), could you please elaborate on the MTU >> overhead being less than GTPU? GTPU encap MTU overhead = 20 octets outer >> IPv4 header + 8 octets UDP header + 12 octets GTPU header + Extension header >> for QFI. SRv6 encap MTU overhead = 40 octets IPv6 header + EH for carrying >> QFI (this part is not clear - see my next question). In your blog >> https://blog.apnic.net/2018/03/07/reducing-complexity-5g-networks-using-segment-routing-ipv6/ >> I noticed in Fig.1 the MPLS / TE headers included in calculation. So does >> the MTU overhead saving talked about for SRv6 assume that underlay TE >> technologies are replaced? It is not clear from the draft. If there are any >> other drafts that provide a clear calculation on the MTU savings, could you >> please point to them? > > I hope that the following spreadsheet helps for that purpose. I’ve updated it > align to the latest draft after I shared it in last month. > > https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qRS5ok2IO1i0 > VZbmwzZJNVh0g/edit?usp=sharing > > As the draft says that traditional mode is as same as existing user plane > protocol, it is also equivalent in terms of overhead size. > You can find that both GTP-U and traditional mode of SRv6 cost 58 bytes as > the overhead. > Satoru, This spreadsheet is really confusing and way too much information. For instance, there's a 135 variants of GTP-U! I sincerely doubt all of those variants are equally relevant and used. Similarly, I don't understand why there's 67 variants of ILA that would be needed. IMO, this is making those protocols look much more complicated than they actually are. It would be nice to have a good summary and fair comparison of the overheads of these various protocols. Here are some suggestions to clean this up: - Pick a handful of representative formats, maybe something like five, and do an an equivalent comparison. For instance, it should be easy to deduce the equivalent packet formats for traditional mode in SR that are needed for GTP and ILA. - Don't count the outer Ethernet header as overhead. It's always there and not counted against MTU. - Don't use colors to highlight differences. The use of 'red' in the spreadsheet is subjective and also confusing in itself. For instance, I don't understand why 'No SRH' (line 1) is black but basic GTP over IPv4 (line 5) is red when they are both reported to have 58 bytes of overhead. - Is the math is off? For instance, in line 1 the overhead is an IPv6 header and and Ethernet header, shouldn't that be 40+14=54 instead of 58? Tom > >> >> 3. How to encode QFI, RQI in SRv6 (both traditional mode and enhanced >> mode)? In GTPU the QFI/RQI markings are carried in a GTPU extension >> header, defined as a container. Please refer the following documents >> for details > > Thank you for those latest references! Actually I was seeking them > from last CT4 meeting folder. ;-) > > And yes, we still leave it at this time since defining 3GPP specific > extension headers and messages should be up to 3GPP decision. > We don’t want to violate that responsibility. Nevertheless, in case that > those GTP-U extension header and messages are carried as its encoding, TLV in > SRH would work to do that with just one or few code points to 3GPP which > looks not big deal. If you are interested, it would be nice if we can write a > draft with that idea with you and John. > > Cheers, > --satoru > >> >> Incoming LS from RAN3 to CT4: >> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Mont >> real/Docs/C4-182214.zip >> >> Corresponding agreed CR in CT4: >> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Mont >> real/Docs/C4-182246.zip >> >> LS out from CT4 to RAN3: >> http://www.3gpp.org/ftp/tsg_ct/WG4_protocollars_ex-CN4/TSGCT4_83_Mont >> real/Docs/C4-182247.zip >> >> Thanks >> Sridhar >> >> -----Original Message----- >> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru >> Matsushima >> Sent: Tuesday, March 13, 2018 6:55 AM >> To: John Kaippallimalil <john.kaippallima...@huawei.com> >> Cc: dmm <dmm@ietf.org> >> Subject: Re: [DMM] Fwd: I-D Action: >> draft-ietf-dmm-srv6-mobile-uplane-01.txt >> >> John, >> >>> 2018/03/13 7:37、John Kaippallimalil <john.kaippallima...@huawei.com>のメール: >>> >>> A few questions for clarification: >>> 1. Section 5.1.1, "..Since there is only one SID, there is no need to push >>> an SRH..." >>> In this case the outer IPv6 address representing a SID would contain a TEID. >>> So for 1000 PDU sessions - would there be as many IPv6 addresses >>> (representing SIDs/TEID in the outer header) >> >> Right. It is not limited but in a typical case given that a /64 per node for >> the SID space which allows each node allocate a SID per session basis. >> >> >>> >>> 2. Section 5.2 (& Figure 3), suppose there were more than 1 UPF on >>> path (gNB --> UPF1 --> UPF2 as in the example in 5.1 but now with other fns >>> - S1, C1) Would the SR path at gNB (uplink) be (a) the list of SIDs to >>> chain functions along the path to UPF1, >>> or, would it be (b) the list of SIDs to chain functions, plus UPF1, .. >>> upto the anchor UPF2. >> >> Please see the section 5.2.1 of packet flow on uplink. >> We assume that there’s no UPF1 along the path in the diagram. >> >> >>> >>> 3. Section 5.2, "The SR policy MAY include SIDs for traffic engineering >>> and service chaining ..." >>> 3GPP service chaining is at N6 interface, but in this case, is the policy >>> for traffic steering implemented at the N3 interface. >>> Would PCF/SMF provision this at gNB. >> >> When it comes to enhanced mode for control-plane side, it may literally be >> enhanced. >> But at this revision of the draft, it is assumed that gNB is capable to >> resolve SR policy from remote endpoint address of tunnel to SIDs list while >> N2 is unchanged and kept as it is. >> >> Cheers, >> --satoru >> >> >>> >>> Thanks, >>> John >>> >>> >>> >>> -----Original Message----- >>> From: Satoru Matsushima [mailto:satoru.matsush...@gmail.com] >>> Sent: Mittwoch, 7. März 2018 12:23 >>> To: Marco Liebsch >>> Cc: dmm >>> Subject: Re: [DMM] Fwd: I-D Action: >>> draft-ietf-dmm-srv6-mobile-uplane-01.txt >>> >>> Marco, >>> >>>> 2018/03/07 18:41、Marco Liebsch <marco.lieb...@neclab.eu>のメール: >>>> >>>> Satoru, >>>> >>>> since I read this at different places, let me ask one clarifying question >>>> about the stateless motivation: >>>> >>>> I see that for SRv6 you may not need a state at the egress (at >>>> least not for traffic forwarding) but for Uplink/Downlink (UL/DL) >>>> you need a state at both edges of the communication since the DL egress >>>> serves as uplink ingress, correct? >>> >>> 2x unidirectional tunnels to form bidirectional paths require 4 states in >>> total at both the ingress and egress. >>> In SR case it requires just 2 states at the ingresses for both directions. >>> >>> Cheers, >>> --satoru >>> >>> >>> >>>> >>>> marco >>>> >>>> >>>> -----Original Message----- >>>> From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Satoru >>>> Matsushima >>>> Sent: Dienstag, 6. März 2018 17:23 >>>> To: Tom Herbert >>>> Cc: dmm >>>> Subject: Re: [DMM] Fwd: I-D Action: >>>> draft-ietf-dmm-srv6-mobile-uplane-01.txt >>>> >>>> Hello Tom, >>>> >>>>>> A Big progress is that the draft supports interworking with GTP >>>>>> over >>>>>> IPv6 in addition to GTP over IPv4. >>>>>> And we have made change SRv6 function to IPv6 encapsulation with >>>>>> SRH instead of SRH insertion by default. >>>>>> >>>>> >>>>> Hi Satoru, >>>>> >>>>> If there are no intermediate hops od SIDs being set when >>>>> encapsulating would a SR header still be needed or could this just >>>>> be simple IP in IP encpasulation? If is no SR header then it's >>>>> possible that ILA might then be used to completely eliminate the >>>>> encapsulation overhead. >>>> >>>> I think you’re right. You would find that case in the draft as >>>> ‘Traditional Mode’ which is equivalent with traditional GTP-U case. You >>>> seem you say ILA is also equivalent with that mode. In addition, this >>>> draft introduces ‘Enhance Mode’ to cover more advanced cases. >>>> >>>> IMO SR is designed not to maintain path states except at an ingress node. >>>> So the packet need to preserve original DA in the header that keep the >>>> egress node in stateless. It would be great if ILA is designed in the >>>> similar concept as well. >>>> >>>> If it’s not, it looks a kind of tradeoff, between reducing the overhead >>>> and keeping the statelessness. It’s not apple-to-apple comparison. To >>>> decide to choose which one need to be prioritized would depend on each >>>> deployment case in operators IMO. >>>> >>>> Cheers, >>>> --satoru >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>> >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
