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

From: Tom Herbert <[email-masked]>
Date: Fri, 26 Jan 2018 09:13:44 -0800

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

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Jan 2018 17:19:49 +0000

Hi Tom:

Marco and myself are planning to publish another proposal on anchor-less mobility (leveraging SRv6). That may be of interest to you from ILA point of view. We will post the draft in one or two weeks.

Regards
Sri

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Tom Herbert <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 26, 2018 at 9:13 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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:

- 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

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 26 Jan 2018 10:36:05 -0800

Hi Sri,

My observations are very close to Tom’s.
Is new draft going to address questions asked or there will be follow up?

Thanks!

Regards,
Jeff

> On Jan 26, 2018, at 09:19, Sri Gundavelli (sgundave) <[email-masked]> wrote:
> 
> Hi Tom:
> 
> From: dmm <[email-masked]> on behalf of Tom Herbert <[email-masked]>
> To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> _______________________________________________
> ila mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ila

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Fri, 26 Jan 2018 19:27:57 +0000

Hi Jeff,

Out focus is on anchor management. W.r.t traffic steering, Satoru-san's work is the basis and we will leverage that. The below questions are specific to that work. We should discuss these points.

Regards
Sri

From: Jeff Tantsura <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 26, 2018 at 10:36 AM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Tom Herbert <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Ila] [DMM] Questions about SRv6 mobile user-plane

Hi Sri,

My observations are very close to Tom's.
Is new draft going to address questions asked or there will be follow up?

Thanks!

Regards,
Jeff

On Jan 26, 2018, at 09:19, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Tom:

Regards
Sri

Hello,

Thanks,
Tom

_______________________________________________
ila mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ila

---

From: Uma Chunduri <[email-masked]>
Date: Fri, 26 Jan 2018 19:59:52 +0000

Comments are spot-on.

Can somebody tell 8200 update would be a possibility in future (w.r.t 6man consensus) i.e., EH insertion in the middle without re-encapsulating the SRH again.
I presume the technical aspect for the 8200 mandate is the ability to fragment if needed at the insertion point. Anything else?  Please enlighten..

Hence, most significant issue has to be resolved perhaps would be the first item.

BR,
--
Uma C.

From: ila [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: Friday, January 26, 2018 9:14 AM
To: [email-masked]; [email-masked]
Subject: [Ila] Questions about SRv6 mobile user-plane

Hello,

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 26 Jan 2018 13:02:12 -0800

On Fri, Jan 26, 2018 at 11:59 AM, Uma Chunduri <[email-masked]>
wrote:

> Comments are spot-on.
>
>
>
> Can somebody tell 8200 update would be a possibility in future (w.r.t 6man
> consensus) i.e., EH insertion in the middle without re-encapsulating the
> SRH again.
>
> I presume the technical aspect for the 8200 mandate is the ability to
> fragment if needed at the insertion point. Anything else?  Please
> enlighten..
>
>
>
Uma,

There were several issues raised. I don't think fragmentation actually came
up as one of them, but that is good point. Intermediate nodes cannot
fragment packets in IPv6. Interestingly, the subject of fragmentation came
up yesterday on the 5gangIP list. There are providers that see
fragmentation happening because of GTP. Not all networks have converted to
us jumbo frames to preserve a 1500 MTU to end nodes and do encapsulation--
increasing packet size in intermediate nodes is still a problem.

Here is a summary of issues that were raised on 6man:

- 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. So encapsulation overhead = 40 bytes, SRH overhead = 20 bytes. I'm
not sure that difference justifies the complexity of EH insertion.

Tom

Hence, most significant issue has to be resolved perhaps would be the first
> item.
>
>
>
>
>
> BR,
>
> --
>
> Uma C.
>
>
>
> *From:* ila [mailto:[email-masked]] *On Behalf Of *Tom Herbert
> *Sent:* Friday, January 26, 2018 9:14 AM
> *To:* [email-masked]; [email-masked]
> *Subject:* [Ila] Questions about SRv6 mobile user-plane
>
>
>
> Hello,
>
>
>
> - It's clear from the depicted use cases that extension header insertion
> is being done by intermediate nodes, but extension header insertion is
> scenario, DA is changing from A2::1 to A3::1
> <https://maps.google.com/?q=A3::1&entry=gmail&source=g>, 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).
>
>
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 27 Jan 2018 01:35:54 +0000

Hi Tom,

> I am working on a comparison between ILA and SRv6 for the mobile user-plane.

This is a good effort. I was wondering, about the key parameters that you will use for this comparison between ILA/ILNP/LISP/HICN etc. For example, ILA router the entries at the ILA router ( ID - L OC  - SIR Prefix), vs at the LISP mapping system. How do you compare the two, a cache/MAP query cost, vs a translation cost + local memory state for keeping that entry.

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?

Sri

Hello,

Thanks,
Tom

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Sat, 27 Jan 2018 01:48:37 +0000

Typo's ... SID -> SIR

From: dmm <[email-masked]<mailto:[email-masked]>> on behalf of Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Date: Friday, January 26, 2018 at 5:35 PM
To: Tom Herbert <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [DMM] Questions about SRv6 mobile user-plane

Hi Tom,

Sri

Hello,

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 26 Jan 2018 18:27:16 -0800

On Fri, Jan 26, 2018 at 5:35 PM, Sri Gundavelli (sgundave) <
[email-masked]> wrote:

> user-plane.
> This is a good effort. I was wondering, about the key parameters that you
> will use for this comparison between ILA/ILNP/LISP/HICN etc. For example,
> ILA router the entries at the ILA router ( ID – L OC  - SIR Prefix), vs at
> the LISP mapping system. How do you compare the two, a cache/MAP query
> cost, vs a translation cost + local memory state for keeping that entry.
>
> Sri,

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.

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).

> 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.

Tom

---

From: Miya Kohno <[email-masked]>
Date: Sun, 28 Jan 2018 22:30:38 +0900

Hi Tom,

Thank you, first of all, for your interest!

Yes, SID list can be reduced in some cases. I agree it should be restricted
to the minimum necessary.

I think ILA and SRv6 share a common view, while SRv6 allows more flexible
functions.

Regarding RFC8200, attacks can be and should be prevented in another way.
If under agreement, header insertion, which could make network more
efficient, should be allowed.

I hope ILA and SRv6 converge.

Miya@a co-author of SRv6 mobile data plane

On Sat, Jan 27, 2018 at 2:13 AM, Tom Herbert <[email-masked]> wrote:

> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 29 Jan 2018 15:29:47 +0900

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-qRS5ok2IO1i0VZbmwzZJNVh0g/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.

Best regards,
--satoru

> 2018/01/27 2:13、Tom Herbert <[email-masked]>のメール:
> 
> Hello,
>

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Mon, 29 Jan 2018 14:30:40 +0000

Satoru:

There are 2 deployment scenarios for mobile core: overlay on packet transport and
integrated. Can you identify the line items applicable to the overlay architecture?

Kalyani

-----Original Message-----
From: ila [mailto:[email-masked]] On Behalf Of Satoru Matsushima
Sent: Monday, January 29, 2018 1:30 AM
To: dmm <[email-masked]>
Cc: Tom Herbert <[email-masked]>; [email-masked]
Subject: [E] Re: [Ila] [DMM] Questions about SRv6 mobile user-plane

Hello Tom,

	https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_spreadsheets_d_1Fx8ilE-5FbQPkhFBoSd-2DqRS5ok2IO1i0VZbmwzZJNVh0g_edit-3Fusp-3Dsharing&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=9LAu7dC44lPXoBoWT3q4QX5sjTPDhk1cmWlg7IQe8ks&e=

Best regards,
--satoru

> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_meeting_100_materials_slides-2D100-2Ddmm-2Dsrv6-2Dfor-2Dmobile-2Duser-2Dplane_&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=ZNHAtXtIVbyuoqhI52nadcPqREIaQSmrfuvqGd5eNs8&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dmm&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=6ufOvi6aVOB4UAgZ20C9fFetELBoi5NRATcN3cAtidY&e=

_______________________________________________
ila mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ila&d=DwIGaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=_lz35skZpHqFfzeq6RxkaHJWHMyiYtwcnWZimRwEENI&s=unue-FGp3cEFg55AqMvWox0Xn5j2Ks05OxC4LYu-kyU&e=

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 29 Jan 2018 15:25:49 +0000

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.

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

Hello,

- 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<https://maps.google.com/?q=A3::1&entry=gmail&source=g>, 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).

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 29 Jan 2018 08:34:33 -0800

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.
>
> 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,
> > - 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
> > - 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.
> >

---

From: Tom Herbert <[email-masked]>
Date: Mon, 29 Jan 2018 09:35:06 -0800

Hi Sri,

My comments are inline.

> [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.

It's a good discussion to have.

> [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.…
We separate data plane from the control plane. The ILA draft describes
the data plane, other drafts (ILAMP, BGP/ILA, ILA in the datacenter)
describe control plane aspects. We'll post a draft shortly with
details specific to the mobile user plane. There are similarities to
LISP, but also differences.

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

One SIR prefix is the simplest way. This allows 64 bit identifier
lookups instead of 128 bit. Also, there's no ambiguity in ILA to SIR
address translation since all locators may back to the same SIR.
However, there's nothing in the architecture that prevents multiple
SIR addresses as long as the mapping from ILA to SIR address is
unambiguous. Non local address identifiers do this.

> 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

---

From: Arashmid Akhavain <[email-masked]>
Date: Tue, 30 Jan 2018 16:34:43 +0000

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.
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.

Arashmid

From: dmm [mailto:[email-masked]] On Behalf Of Sri Gundavelli (sgundave)
Sent: 29 January 2018 10:26
To: [email-masked]
Subject: Re: [DMM] Questions about SRv6 mobile user-plane

HI Tom,

---

Regards
Sri

Hello,

Thanks,
Tom

---

From: Tom Herbert <[email-masked]>
Date: Tue, 30 Jan 2018 10:46:23 -0800

On Tue, Jan 30, 2018 at 8:34 AM, Arashmid Akhavain
<[email-masked]> 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

> [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.
>
>
>
>
>
>
>
> mappings. They are authoritative. Forwarding nodes are located close to user
> devices and maintain a working set  cache of entries driven by user
> [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.
>
>
>
>
>
>
>
>
>
> 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.
>
>
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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:
>
>
>
> - 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.
>
>
>