Re: [Ila] [DMM] Questions about SRv6 mobile user-plane

[Tom Herbert <[e-mail]>]

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 <[e-mail]>のメール:
> >
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmm
>
>