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

[Tom Herbert <[e-mail]>]

On Tue, Jan 30, 2018 at 8:34 AM, Arashmid Akhavain
<[e-mail]> wrote:
> Hi Tom and Sri,
>
>
>
> One of the possible options is perhaps to use something along the line of
> what public clouds or OTT folks provide/use.
>

Hi Arashmid,

That's a good approach. There's been a lot of innovation over the past
few years so that using a key-value store as routing protocol is now
feasible. The Open/R project from Facebook applies KV-STORE with
modifications to get features of link-state protocols.
(https://code.facebook.com/posts/1142111519143652/introducing-open-r-a-new-modular-routing-platform/)

> A form of DHT (with some wild carding capability) can perhaps fit the bill.
> We ran some tests with Google and Azure Pub/Sub and got about 120ms response
> time. These public cloud services though and as such are designed for moving
> large amount of data around and therefore need to do some buffering to be
> efficient. A custom version of these types of database and messaging for
> ID-LOC mapping distribution could perhaps be much faster.
>

I like DHT for its database lookup properties which would work very
well with nodes that are populating mapping caches. One consideration
is that for scaling to really large networks we assume that there are
both forwarding nodes that maintain a mapping cache (ILA-Ns), and
nodes that have a full set of mappings (ILA-Rs). Internet edge routers
for a big network would likely want to be ILA-Rs. The mapping database
is sharded among ILA-Rs. A shard is identified by some bits in the
identifier part of the address. If these are the high order bits of
the identifier then routing packets to the right shard is simple
prefix routing. So, if a SIR prefix were 2000::/64 and 16 bits are
used for a shard index, then a route of 2000:0:0:0:2::/80 routes
packets to a node that has the mapping for shard 2. The shard index
has no other semantics and this can be DHT where the hash function
simply returns the shard index from an address key. Queries by ILA-Ns
then are done based on this hash (and hence shard).

Tom

>
>
> Arashmid
>
>
>
>
>
> From: dmm [mailto:[e-mail]] On Behalf Of Sri Gundavelli
> (sgundave)
> Sent: 29 January 2018 10:26
> To: [e-mail]
> Subject: Re: [DMM] Questions about SRv6 mobile user-plane
>
>
>
> HI Tom,
>
>
>
> Thanks for your response. Please see inline.
>
>
>
>
>
>
>
> ---
>
>
>
> https://tools.ietf.org/html/draft-herbert-ila-motivation-00 provides some
> comparisons between ILA and ILNP, encapsulations, SR, and transport layer
> mechanisms that can achieve some effects in mobility.
>
>
>
> The choice of mapping system is critical. The mapping of identifier, or
> equivalently virtual to physical address mapping, seems to be a common
> problem in mobility and networking virtualization. As you mentioned, LISP
> defines a query method to populate a mapping cache. I assume this problem
> needs to be tackled in SR for mobile user-plane but I'm not sure what
> solution is preferred after reading the draft.
>
>
>
> [Sri] There are multiple approaches on how we manage this mapping state.
> Obviously, ILA is one approach, but there are few other approaches as well
> that we need to review.
>
>
>
>
>
>
>
> ILA partitions the problem into a two level hierarchy: ILA routers and IL
> forwarding nodes. This is somewhat analogous to core IP routers and nodes
> running neighbor discovery.  ILA routers contain all the (possibly sharded)
> mappings. They are authoritative. Forwarding nodes are located close to user
> devices and maintain a working set  cache of entries driven by user
> activity. If a packet doesn't hit the cache it's forwarded to a router that
> will do the ILA transformation. If the cache is hit, the packet can be
> transformed at the forwarding node to eliminate triangular routing. Caches
> can be populated by pull or push models. ILAMP (the ILA mapping protocol)
> supports both of these, but my current preference for scalability and
> mitigating DOS attacks on the cache is to use secure redirects sent by ILA
> routers  (analogous to ICMP redirects).
>
>
>
>
>
> [Sri] When I last reviewed the ILA I-D, I do not seem to remember reading
> about the cache state, ILMP. or about how the mapping gets to the ILA
> routers. Looks like the spec is evolving as we speak. With ILAMP type
> control protocol for cache management, I see more similarities to LISP.
>
>
>
>
>
>
>
>
>
> On a different note, just curious if SID prefix can ever have topological
> relevance and can be used for routing. In other words, can you ever route a
> packet without translating  the SIR prefix of the destination address with
> the locator? Can SID prefix be used as a locator in some special cases?
>
>
>
> Yes, the SIR prefix is routable to forward to an ILA router. This is
> necessary for the redirect mechanism I describe above. I suppose this could
> be contorted to make the SIR address be a home address like in MobileIP and
> locators are COAs (if my use of MobileIP terminology is correct). There also
> might be nodes in the network, as well as external nodes that don't do go
> through a cache to their packets need to hit an ILA router to get forwarded
> to the location of mobile nodes. An upshot of that is that edge routers
> might need to perform transformations (SIR to ILA) at high rates so the
> mechanism needs to be very efficient and amenable to HW implementation.
>
>
>
>
>
> [Sri] This is precisely what I was thinking.
>
>
>
> I get that SIR prefix takes the packet awards the ILA domain and some ILA
> router in the path can apply the mapping. I was thinking there may not be a
> good reason to have more than one or two SIR prefixes for each ILA domain.
> As long as the SIR prefix can take the packet from a non-ILA domain
> (internet) to ILA domain, then the edge router can apply the mapping. But,
> that also implies the edge routers will have to have too much of mapping
> state. Now, if we have many SIR prefixes and associate a SIR prefix for each
> PGW/UPF, that state can be distributed and keep the edge routers stateless,
> but it also brings anchoring back into the picture. In one simplest mode, as
> you say, HNP (home network prefix) can be a SIR and the PGW/SGW or
> (LMA/MAG) can do the translation of SIR - ILA, without the need for
> tunneling.
>
>
>
> So, in your mind how many SIR prefixes will be used in a typical T1 operator
> domain? Also, how can we quantify the state that ILA introduces in different
> parts of the network?
>
>
>
>
>
> Regards
>
> Sri
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: dmm <[e-mail]> on behalf of Tom Herbert
> <[e-mail]>
> Date: Friday, January 26, 2018 at 9:13 AM
> To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: [DMM] Questions about SRv6 mobile user-plane
>
>
>
> 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-100-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
>