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

From: Uma Chunduri <[email-masked]>
Date: Fri, 2 Feb 2018 19:38:41 +0000

> So, in your mind how many SIR prefixes will be used in a typical T1 operator domain?

Sri, very good question and I don't think anybody figured this yet for 5G..

                > Also, how can we quantify the state that ILA introduces in different parts of the network?

                Please look at topology of section 2 in

                https://tools.ietf.org/html/draft-herbert-ila-ilamp-00. ILA routers collectively contain the all the mappings for the domain. The mappings can be sharded on the routers serving a shard can be replicated. There are two cases where ILA transformation is needed: at netwrok ingress (e.g. from Internet) and intra domain traffic. The first case                 is served by edge routers which as I mentioned would have considerable load. For intra domain communications routers would be used aslo, but they can be augment by the use of mapping caches in forwarding nodes.

                Forwarding nodes perform ILA to SIR transformation before delivery-- this does not need a lot of state.

                Presumably every mobile node in the network has an identifier to locator mapping. So the number of mappings in the domain equals the number of  mobile nodes. This number is expected to reach into the the billions, a scale a single device won't have the memory for the full mapping table so it would be sharded. Each shard also would   be replicated N ways. So number of routers needed is num_shards * num_replicas.

                Another major consideration for scaling is changes to the mapping system. It's a little harder to quantify since the load on the system depends on the rate at which mobile nodes are moving. I'm not sure what the rate of device moving in cellular network is (someone might have good insights on that), but for scaling estimates I'm using 1              % (that is at an given time 1% of devices are moving to different eNb).

Tom, 1% seems to be incorrect assumption even for 4G and also regardless of how you partition shreds I see potential for massive state introduced in the core (in various nodes); and I am not even sure how "making anchorless"  solution is  the most important/pressing goal.

--

Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Fri, 2 Feb 2018 12:17:06 -0800

Hi Uma,

> [Uma]: SRH in the proposal not only put a sort of mobility solution (encoded
> in the SID) but also use to guide the packet through non shortest path from
> the source as needed and as listed in the SRH.
>
It would be nice to have a concrete example of how this would be used
and how SR uniquely solves the problem.

>                One of the assumption, I saw the discussion here, ILA and
> 5GIP seems to assume delivering the packet to the shortest path but this may
> not be necessary the case for lot of 5G slices and also tunneling in couple
> of cases is unavoidable (if you ought to overlay IPSec in few cases).
>
I believe you could get the same effect for either ILA or
encapsulation by doing hop-by-hop routing over a network overlay. As I
mentioned, the operation in slide "Basic Mode User-Plane Flows
(Uplink)" where A3::1 is written into the destination seems to be
doing just that.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 2 Feb 2018 19:23:41 +0000

There were several issues raised. I don't think fragmentation actually came up as one of them, but that is good point.
[Uma]:  Yes.
Intermediate nodes cannot fragment packets in IPv6.
…

- The proposal attempted to carve out an exception to RFC8200 for just SR and limited use to controlled domains. That entails many caveats an assumptions that would need to be MUSTs.

- Encapsulation is recommended to allow EH insertion and several people asked why not use it. It will work inasmuch as encapsulation within the network already works.

- If a host is already using extension headers and the network tries to add more, there is an ambiguity about which ones the.network is responsible for. When packet leaves the domain, the EH that the network added needs to be removed and it needs to be unambiguous which ones are to be removed.

- ICMP is a problem. If a host gets an ICMP error that contains extension headers that it did not possibly send then that will be confused. Presumably, ICMP errors will need to be stripped of EH before forwarding to a source node.

- PTB is interesting. For instance, EH insertion could force PMTU to drop below 576 minimum.

- If the added extension headers are causing packet drops this is a major problem. The intermediate node that is inserting the EHs will never get feedback that its actions are doing harm. An end host might detect packet loss at the transport layer or might get an ICMP error (maybe something like  draft-herbert-6man-icmp-limits-02<https://tools.ietf.org/html/draft-herbert-6man-icmp-limits-02>), But, even if it knows that inserted EHs are causing drops, there's is no action a host can take to stop it. At least with encapsulation the tunnel ingress might get and ICMP error about what it's doing.

I suppose the primary argument against encapsulation is that it's too much overhead. But, I would point out that in the examples if only one sid is required for mobility (address of destination)  in an IP/IP encapsulation this would be the destination of the inner packet and SRH wouldn't be needed.
[Uma]: SRH in the proposal not only put a sort of mobility solution (encoded in the SID) but also use to guide the packet through non shortest path from the source as needed and as listed in the SRH.
               One of the assumption, I saw the discussion here, ILA and 5GIP seems to assume delivering the packet to the shortest path but this may not be necessary the case for lot of 5G slices and also tunneling in couple of cases is unavoidable (if you ought to overlay IPSec in few cases).
So encapsulation overhead = 40 bytes, SRH overhead = 20 bytes. I'm not sure that difference justifies the complexity of EH insertion.
[Uma]: If you include the above difference is not quite that. But re-encap seems lot safer for some of the points you raised above.

--
Uma C.