On Sun, Jan 28, 2018 at 10:29 PM, Satoru Matsushima <satoru.matsushima @gmail.com> wrote:
> Hello Tom, > > To make the overhead discussion quantitative and realistic, I’ve made a > spreadsheet of user-plane total overhead comparison by deployment scenarios. > > https://docs.google.com/spreadsheets/d/1Fx8ilE_bQPkhFBoSd-qR > S5ok2IO1i0VZbmwzZJNVh0g/edit?usp=sharing > > This includes not only for mobility, but also range of possible cases of > real deployment in operators to fulfill isolation, quality and reliability > requirements for mobile networks. Some of them seem most likely cases, but > others sound extreme. But I’d like to share all those scenarios to make us > aware of them when it comes to packet overhead in real deployments. > > The total overhead length of the scenarios which exceed 2x SIDs (58) and > 4x SIDs (90) cases are highlighted with red color to the number and the > cell respectively in the sheet. Please take a look at it. The sheet looks a > bit busy but you may find some interesting points, or errors. Any comments > and corrections from all of you are really welcome. > Hi Satoru, Thank you for the spreadsheet. A few points: - I don't understand why there aren't use cases list for SR/IPv6 over MPLS or L3VPN. Could you explain that? It seems to me that SR doesn't replace that those, and they might be complementary. - I'm missing something on how the overhead is being calculated. For instance, in deployment scenario #1 headers are 14 (ethhdr) + 40 (IPv6) + 4 (EH hdr) + 4 (SRH) + 2 * 16 (2 sids) = 94. I think you might not be including the original IPv6 header, so this shouldn't this be 54 bytes? Similarly, it seems like ILA over Ethernet should be 14 bytes. - You may want include scenarios for SR that include the overhead of encapsulation that would be needed to avoid extension header insertion. I assume this would just be IP/IP encapsulation, but as I said previously the inner destination address can serve as the final segment so that might eliminate one sid. - Not all overhead is equal cost. The effects on protocol and processing should be considered. For instance, unlike L3 encapsulations layer 2 encaspulations shouldn't affect MTU at L3. It's a bit difficult to quantify processing overhead, but generally the number of table lookups and number of calculations over packet data (like a checksum) are a good measure. Simple push/pop of headers isn't usually too bad if the headers are constant. Tom Best regards, > --satoru > > > > 2018/01/27 2:13、Tom Herbert <[email protected]>のメール: > > > > Hello, > > > > I am working on a comparison between ILA and SRv6 for the mobile > user-plane. I have some questions/comments about SRv6 and particularly on > the example use cases that were depicted in the slides that were presented > in IETF100: > > > > https://datatracker.ietf.org/meeting/100/materials/slides-10 > 0-dmm-srv6-for-mobile-user-plane/ > > > > - It's clear from the depicted use cases that extension header insertion > is being done by intermediate nodes, but extension header insertion is > currently prohibited by RFC8200. There was an I-D posted on 6man to allow > this for SR, but that was met with pushback. Is there going to be followup > to resolve this? > > > > - For the uplink use cases, this seems to be more like using SR to > source route to an egress router. In other words, it's not strictly related > to mobility. Is there some connection to mobility that I'm missing? > > > > - The size or number of SR headers in the uplink cases seems to be > larger than necessary (IMO minimizing these is important since each > additional sid is ~1% overhead of standard MTU). In this first scenario > sid[1]=A2::1 and DA=A2::1-- this seems to be redundant information. Also > this depicts a second SR being inserted, but the first one should no longer > be relevant. Why not just discard the first one and save the overhead? In > the second scenario, DA is changing from A2::1 to A3::1, but AFAICT that > was not done per the SR processing. What is the operation that happened > here? (it's actaully looks like an ILA transfomation). > > > > - Considering the points above, could this have been done in the > following manner to minimize overhead? A1 creates one SRH with one sid and > makes DA=A2. A2 makes DA=A3. At A3 SR is processed, DA is restored to > Internet address, and EH is removed. > > > > - For downlink this does see to be relevant to mobility. But I have the > same question, wouldn't it be less overhead to only use one SRH and one > sid? i.e. A3 creates an SRH with just one sid that is the S:: (identifier > in identifier/locator speak) and set DA to A2, and then A2 sets DA to A1, > A1 restores original packet for delivery. > > > > - One possible typo. In the last use case slide SA=S:: and DA=D::, I > believe these should be swapped? > > > > Thanks, > > Tom > > > > > > > > > > _______________________________________________ > > dmm mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmm > >
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
