Subject: Re: [5gangip] Agenda slides - more on id-locator split

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Nov 2017 06:51:51 +0100

In the agenda, and during the meeting, I noticed many concepts of
id-locator split.

For that, there is also "ILA" which was presented at the intarea WG meeting.

For all the id-locator split, including ILA, I would like to make one 
comment: please use variable-length loc's.

The reasons to consider variable-length loc's, instead of fixed-length are:

- better security properties: shorter than 64 locs (e.g. 63) allow for
longer id's (e.g. 65) which in turn have better security properties when
they are generated as public-keys.  They resist better to brute force
attacks.

- considering loc's of any length (rather than fixed 64) allows to
extend the network beyond its current  edges, when the provider limits
it by advertising only a /64.

- routing and forwarding in the Internet works with prefixes of any
length: 63, 64, 65, 66, etc.  This was called CIDR in IPv4.  For IPv6
there is BCP 198, which stands for "Best Common Practice".

Some reasons to use _only_ fixed length loc's (64) are present in some 
parts of RFC4191 "IPv6 Addressing Architecture".

There is also an RFC on "Analysis of the 64-bit Boundary in IPv6 
Addressing" with many more details.

Alex

Le 16/11/2017 à 08:45, Behcet Sarikaya a écrit :

---

From: Tom Herbert <[email-masked]>
Date: Thu, 16 Nov 2017 22:25:34 -0800

> For that, there is also "ILA" which was presented at the intarea WG meeting.
I attached slides from that.

> The reasons to consider variable-length loc's, instead of fixed-length are:
Alexandre,

As I mentioned in int-area discussion we pretty much need shorter than
64 bit locators in order to accommodate /64 host assignment. However,
in this case low order 64 bits is an IID that is set by the host, not
the device identifier in idloc-- so that is also shorter than 64 bits.

> they are generated as public-keys.  They resist better to brute force
This doesn't apply to the above case. If a 64 bit IID is being used
the best we can do for a device identifier is 64 minus network
provider prefix. This is weak security which is why am arguing on
v6ops that /128 assignment is needed for best security. In that case
the maximum identifier could be 128 minus network prefix which could
be bigger than 64 bits to satisfy your requirement.

> there is BCP 198, which stands for "Best Common Practice".
This works in principle, but I am concerned about the pragmatics of
not using a fixed length. LPM is certainly more expensive than fixed
length lookups and any way we cut it identifier-locator split entails
a huge scaling problem for edge routers (as Lorenzo pointed out these
may have 100s of millions if not billions of entries). It would be
good to limit the possible identifier lengths to one or two per site
for efficient lookup I think.

Tom

> Some reasons to use _only_ fixed length loc's (64) are present in some parts
> of RFC4191 "IPv6 Addressing Architecture".
>
> There is also an RFC on "Analysis of the 64-bit Boundary in IPv6 Addressing"
> with many more details.
>
> Alex
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip

---

From: sothy shan <[email-masked]>
Date: Fri, 17 Nov 2017 08:48:15 +0100

Hello All,
One question generally with ILA/ILNP,
I see the VM mobility via BGP (kind of control plane entity) and NAT in
Project Calico.
I dont how much difference between ILA/ILNP and Project Calico.

When we go Internet scale, cost of encapsulation and
transalation with sync mechanims might be same?

Best regards
Sothy

On Fri, Nov 17, 2017 at 7:25 AM, Tom Herbert <[email-masked]> wrote:

> parts

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 17 Nov 2017 08:16:33 +0000

Hello Sothy;

> On 17 Nov 2017, at 15:48, sothy shan <[email-masked]> wrote:
> 
> Hello All,
> I see the VM mobility via BGP (kind of control plane entity) and NAT in Project Calico.

I do think it is useful to group ILA and ILNP together in this case.

Tom would be better responding to answer your question with respect to ILA, but I can answer with respect to ILNP, below.

ILNP does not need BGP or NAT to enable VM mobility. Indeed, in ILNP, VM mobility is handled in a very similar way to host mobility, i.e. end-to-end. You can find a description of some use-cases in Section 6 of RFC6748 - please see here:

  https://tools.ietf.org/html/rfc6748#section-6

and please see more details in this paper from MILCOM2012:

  Secure & Agile Wide-area Virtual Machine Mobility.
  MILCOM 2012 - 31st IEEE Military Communications Conf. Orlando, FL, USA. Oct 2012.
  http://dx.doi.org/10.1109/MILCOM.2012.6415716
  https://saleem.host.cs.st-andrews.ac.uk/publications/2012/milcom2012/milcom2012-ba2012.pdf

> transalation with sync mechanims might be same?

When the VM image is relayed across the network, especially across a wide-area link, you would probably want to use a secure tunnel. This is not part of the ILNP specification, and indeed does not need to be. You will find a discussion about this in Section VII.A of the MILCOM2012 paper.

In terms of overhead:

- the "cost of encapsulation" is whatever you choose for the tunnel to ship your VM bytes - that is up to you (could be IPsec, MPLS, layer-2 etc) and not tied to ILNP in any way - see above.

- "translation with sync mechanisms" is the same as for a mobile host: again, more detail in the MILCOM2012 paper, but it is, essentially, a LU-Adv/LU-Ack handshake to signal the new Locator value for each correspondent node (again, please see the MILCOM2012 paper).

Cheers,
--/Saleem

> Sothy

 [ ... ]

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 17 Nov 2017 08:18:58 +0000

On 17 Nov 2017, at 16:16, Saleem Bhatti <[email-masked]<mailto:[email-masked]>> wrote:

I do think

"I do not think ..."

(sorry)

Cheers,
--/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Nov 2017 01:35:26 -0800

Since LISP uses the *entire* address for either EIDs or RLOCs, we don’t have the issue you raise Alex. Since the EID is relative opaque, you can carve out a prefix to reduce state in the mapping system. So all devices in a LISP site can be out of a <ipv6-prefix>::/48 space where the RLOCs are a couple of border routers. And the border routers’ address are in prefix blocks as advertised into the ISP they attach to and are appropriately aggregated by ISPs as they adverise such prefixes further out into the network.

And note that the EID or RLOC can be any of IPv6 or IPv4 which provide for 4 encapsulation options. And note where needed for L2-overlays and EID can be a MAC address.

I would like the ILNP and ILA authors to tell me how their address is split up when it is a ff::/8 address (i.e. a multicast group address). And how multicast in general is supported.

Dino

> On Nov 16, 2017, at 9:51 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> For all the id-locator split, including ILA, I would like to make one comment: please use variable-length loc's.
> 
> Some reasons to use _only_ fixed length loc's (64) are present in some parts of RFC4191 "IPv6 Addressing Architecture".
> 
> There is also an RFC on "Analysis of the 64-bit Boundary in IPv6 Addressing" with many more details.
> 
> Alex
>

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 17 Nov 2017 10:06:16 +0000

Dino;

On 17 Nov 2017, at 17:35, Dino Farinacci <[email-masked]<mailto:[email-masked]>> wrote:

In ILNP, there is no special handling needed for multicast - just whatever IP provides.

Cheers,
--/Saleem

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Nov 2017 11:32:31 +0100

Le 17/11/2017 à 11:06, Saleem Bhatti a écrit :
>> I would like the ILNP and ILA authors to tell me how their address
>> is split up when it is a ff::/8 address (i.e. a multicast group
>> address). And how multicast in general is supported.
> 

So, ILNP, for multicast there is no id-locator separation?

The Group ID is the identifier?

(some Group IDs are there:
https://www.iana.org/assignments/perm-mcast-groupids/perm-mcast-groupids.xhtml#perm-mcast-groupids-1)

Or maybe in ILNP multicast one could still try to id each _member_ of
the group identified by a Group ID, at which point one may be talking
about id-locator split _inside_ a typical Group ID(?)

Alex

> Cheers, --/Saleem

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 17 Nov 2017 10:52:05 +0000

Alex;

Just a quick response - I may have to do some reading and get back to you, unless
someone has an answer to my position below.

- RFC8200/STD86 makes no reference to RFC7608/BCP198.

- RFC8200/STD86 refers to RFC4291 and states at the bottom of page 4:

  The format and semantics of IPv6 addresses are specified separately in [RFC4291].

- RFC4291 is not "updated by RFC7608" and states in Section 2.5.4, top of page 10:

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1. Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

   Examples of Global Unicast addresses that start with binary 000 are
   the IPv6 address with embedded IPv4 addresses described in Section
   2.5.5.

So, overall, my position is that the ILNPv6 design decision to use a fixed length
Locator of 64 bits is consistent with RFC8200/STD86, notwithstanding your comment,
and preference for, a variable length Locator, as recommended in RFC7608/BCP198.

Is that right?

Happy to be corrected if my understanding is flawed.

Cheers,
--/Saleem

> On 17 Nov 2017, at 13:51, Alexandre Petrescu <[email-masked]> wrote:
>

---

From: Saleem Bhatti <[email-masked]>
Date: Fri, 17 Nov 2017 19:33:51 +0800

Alex;

> On 17 Nov 2017, at 18:32, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>>> On 17 Nov 2017, at 17:35, Dino Farinacci <[email-masked] <mailto:[email-masked]>> wrote:

Correct. For multicast, currently, there is no special handling in ILNPv6 - IPv6 multicast is used.

Cheers,
—/Saleem

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 17 Nov 2017 20:56:22 +0800

There is definitely special considerations for multicast. Because if a receiver joins (S,G), it doesn’t know the locator for S. And when the locator for S changes the network has to build tree state to the new locator. 

This is a lot of machinery. And no one has written down the details so all I can assume is that it’s not really supported. 

Dino

> On Nov 17, 2017, at 6:32 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Nov 2017 07:09:43 -0800

> I would like the ILNP and ILA authors to tell me how their address is split up when it is a ff::/8 address (i.e. a multicast group address). And how multicast in general is supported.
ILA supports encoding of multicast addresses. Section 4.2.5 of the draft.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Nov 2017 07:20:18 -0800

> transalation with sync mechanims might be same?
Hi,

ILA does address translation, but it's _not_ NAT. ILA translations are
stateless, don't do port translation so there's no parsing into L4,
maintain L4 checksums via checksum neutral, and translation is always
symmetric (between sender and receiver destination is translated to an
ILA addresses and then translated back to original address for
delivery).

We do have extensions in to use BGP as the control plane in ILA
(draft-lapukhov-bgp-ila-afi-02), however we found that this method
won't scale to more than a few million entries. We're anticipating
networks to have order of billions of entries. A distributed and
sharded key-value store (NoSQL database for instance) is showing to be
more scalable.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Nov 2017 07:12:45 +0800

> ILA supports encoding of multicast addresses. Section 4.2.5 of the draft.

This is not sufficient to get layer-3 multicast to work in the network. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Nov 2017 07:13:45 +0800

And ILA does not translate ports like a NAT would. A good thing. 

Dino

> On Nov 17, 2017, at 11:20 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Nov 2017 16:59:48 -0800

> This is not sufficient to get layer-3 multicast to work in the network.
Probably not. I suppose that to do this right you'd need two layers of
multicast and some mapping between the two layers of addresses. For
completeness of a solution this might be needed, but in practice are
you really seeing much of need for this? I know FB and Google don't
use it in their datacenter. Is multicast in widespread use for
customers of network providers like mobile?

Tom

---

From: Ca By <[email-masked]>
Date: Sat, 18 Nov 2017 01:20:51 +0000

> customers of network providers like mobile?

Not at all used in mobile.

There is an abomination called eMBMS, but it has never been deployed at
scale.

Customers dont want live things and network dont support it well.

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Nov 2017 09:21:36 +0800

> multicast and some mapping between the two layers of addresses. For

If you look at RFC6831, you’ll see the issues that needs to be dealt with. And since that writing, we have made multicast simpler by use of the mapping system. 

> customers of network providers like mobile?

Not sure if wide or narrow quantities anything but there is enough deployment you can’t ignore it. 

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 18 Nov 2017 09:22:41 +0800

> On Nov 18, 2017, at 9:20 AM, Ca By <[email-masked]> wrote:
> 
> There is an abomination called eMBMS, but it has never been deployed at scale. 
> 

I have talked to carriers that may want to support multicast in 5G. 

Dino

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 17 Nov 2017 21:34:56 -0800

A great percentage of communications in tactical military and emergency
services is multicast in nature.  Different 'channels' in Land Mobile
Radio are, in effect, multicast groups.  

Further, the vehicle-to-vehicle and vehicle-to-infrastructure
scenarioss have a great many multicast situations.  

The uptake on ip multicast is, as mentioned, not good.  But the
bandwidth economies were never convincing in the fiber optic portion of
the internet plumbing.  In radio, a naturally broadcast medium, they
are.

---

From: Jeff Tantsura <[email-masked]>
Date: Sat, 18 Nov 2017 18:35:01 +0800

Ca,

Let me disagree, as someone who worked on eMBMS design and implementation - I have seen rather large deployments, Vz as an example.

Regards,
Jeff

> On Nov 18, 2017, at 09:20, Ca By <[email-masked]> wrote:
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Sat, 18 Nov 2017 08:34:06 -0800

> the internet plumbing.  In radio, a naturally broadcast medium, they

Rex,

Thanks for the input. I think I should have clarified may question to
be "do any major network infrastructures support native L3 multicast
and multicast routing?" In your examples, efficient L2 multicast is
possible to use over broadcast mediums like radio. However, in the
core network infrastructure there is no equivalent broadcast domain
especially as infrastructures may be L3 switched and point to point
links are predominant. AFAIK datacenters and network providers don't
typically support native multicast routing within their
infrastructure. Simply put, it's a bear to support an alternative
routing infrastructure, the bandwidth savings to avoid replication
doesn't justify the solution and management complexities, and it's a
very narrow use case relative to unicast.

W.r.t. identifier-locator, the locator of a packet indicates the point
of attachment a device has in the network. Basically, the locator is
the addresses the first hop router. Beyond that point towards the end
node, the locator shouldn't be relevant and packet can be sent over
last hop to destination via L2. Multicast could then work the same
way. For instance, a relay might unicast an encapsulated or translated
multicast packet with a locator of an eNodeB that has connected UEs
that have joined the multicast group. At the eNodeB, the
identifier-locator information is removed and the resulting packet can
be L2 multicast to receivers. In V2V and V2I where the senders and
receivers are attached to the same point of attachment, multicast (and
unicast) packets can be sent amongst without using identifier-locator
at all.

Tom

---

From: Ca By <[email-masked]>
Date: Sat, 18 Nov 2017 16:48:14 +0000

On Sat, Nov 18, 2017 at 2:35 AM Jeff Tantsura <[email-masked]>
wrote:

> Ca,
>
> Let me disagree, as someone who worked on eMBMS design and implementation
> - I have seen rather large deployments, Vz as an example.
>
> Regards,
> Jeff
>

If you know the verizon case, you know it is incredibly niche, a very small
fraction of their customers have ever interacted with it (stadiums only? A
single app?) Apple does not support it ... so there is know way the
business case is in the black given the complexity and cost.

---

From: Rex Buddenberg <[email-masked]>
Date: Sat, 18 Nov 2017 12:15:36 -0800

In line, good response:

> very narrow use case relative to unicast.
There are a couple points here and we shouldn't conflate.  The demand
point is that spectrum is limited, we should maximize the efficiency of
its use.  Multicast _over_the_air_ is one of the unexploited rabbits
left in the hat.  I picked a couple non-IP examples (e.g. LMR) because
multicast is the norm there.  I think we're in agreement here.

> unicast) packets can be sent amongst without using identifier-locator
If the end system is at the far end of the last (and only RF) node your
logic is fine.  But IEEE 802.16 and TIA LTE are both characterized by
contention-free MACs and are therefore suitable for radio-WANs.
Envision a topology where you reach from 1) wired internet to 2) to a
radio-WAN base station to 3) a wireless LAN fanout (or even wired
ethernet -- the logic works that way too) to end system.  An
instrumented ambulance is a good use case.  In this case the radio-
linked router is not the last router.  
   V2I is also a real case here too: reach is to the _router_ in the
auto which has a LAN on the backside.  
   To get the payoff, you need multicast over the radio-WAN.  You're
right, we don't much care about the wired internet and we also don't
care much about the LAN, wired or otherwise.
   Does your identifier-locator work in this case?  

Thanks

b

---

From: Ca By <[email-masked]>
Date: Sat, 18 Nov 2017 20:35:15 +0000

On Sat, Nov 18, 2017 at 12:15 PM Rex Buddenberg <[email-masked]>
wrote:

> its use.

In 5G mmWave is this less so a spectrum scarcity story. mmWave sucks, but
that is what people think is 5G

 Multicast _over_the_air_ is one of the unexploited rabbits
> multicast is the norm there.  I think we're in agreement here.

Why has nobody yet taken the rabbit out of the hat? there is no demand.

Look at the people around you when you are on the smart phone, are they
looking at the same thing as you at the same time? Reading this same email?

No.

Multicast is in fact not a spectrum savings since it is a dedicated chanel
vs stat muxing the time slices / beams

---

From: Tom Herbert <[email-masked]>
Date: Sat, 18 Nov 2017 12:40:11 -0800

> linked router is not the last router.

It is the last router as far as identifier-locator split is concerned.
The ambulance may have several addresses or be assigned a /64 which is
common for mobile. Identifier-locator split is used to get packets
with these addresses to the eNodeB that the ambulance is currently
connected. At the eNodeB the locator-identifier information is removed
and the original packet is delivered to the ambulance. The packet can
then be routed normally in the ambulance network and in fact could
implement another layer of identifier-locator split if it wants (maybe
not so much for an ambulance, but consider a mobile datacenter replete
with VMs that are migrating between servers in a semi-truck going down
the road). But, the point is that once the packet is delivered to the
end node from the perspective of an identifier-locator domain it needs
to be out of the picture.

> auto which has a LAN on the backside.

Right, should just be simple routing (unicast or multicast) within the
automobile network.

> care much about the LAN, wired or otherwise.

Agreed.

>    Does your identifier-locator work in this case?
Yes, I believe so. All these examples put the multicast over radio at
the edge of the identifier-locator domain so identifier-locator is
terminated before transmission. Multicast within the infrastructure
seems more likely to be served by unicasting via relays than providers
bringing up multicast routing.

Tom

---

From: Rex Buddenberg <[email-masked]>
Date: Sat, 18 Nov 2017 16:21:58 -0800

On Sat, 2017-11-18 at 20:35 +0000, Ca By wrote:
> 
> Look at the people around you when you are on the smart phone, are
> they looking at the same thing as you at the same time? Reading this
> same email?
> 
> No. 

Ca,

I'd submit that you have the 'this is way we've always done it'
blinders on.  There are lots of examples where we would like to use
multicast ... if the capability existed. 

Reverse 911 is one example where a real multicast capability would pay
off.
     What we have now is a robocaller that is fed a list of telephone
numbers with a recorded message saying that the world is on fire or the
dam is overtopping (both of which have happened around here in the past
year), evacuate areas x, y, z.  Reverse 911 crams a real multicast
requirement into n unicast calls at a point where time is of the
essence.  And Reverse 911 has no reliability (as in TCP reliability or
message receipt reliability) so we supplement it with sheriff deputies
going door-to-door.  
     So yes, we need a system where everyone is, to use your words,
reading the same email.  

(There have been serious proposals to use Twitter for the purpose, but
the limited character space collides with 1) the lack of reliability
and 2) the ironclad need for digital signatures for authenticity.)

---

From: <[email-masked]>
Date: Sun, 19 Nov 2017 11:13:26 +0000

I have to say that this would be a very niche use case as would anything associated with PMR/LMR.

I have to admit that I had to do a search for "Reverse 911" as I'd never heard of it.  Disaster notification really isn't that big of a thing outside of North America (I did spend nearly 5 years living in the US and was aware of the various systems you have).  Trials have been run here in the UK, but they haven’t been useful.    If we had automatic systems starting to call us to tell us things I'm pretty sure us cynical Brits would just ignore it....!

In terms of two-way radio for the emergency services, the introduction of national/trans-national TETRA/TETRAPOL from the late 1980s caused the demise of two-way systems.   Trunked radio has been around since the 1970s and has proved far-more useful for utility companies precisely for its ability to NOT be multicast and therefore run a phone-like call with individual technicians.  

Other two-way radio systems (taxis, bus, trains) have all-but gone to be replaced by either data services on existing MNOs or standalone private cellular networks (e.g. GSM-R for the national railway network). 

The main use for most TETRA/TETRAPOL systems is not voice and certainly not multicast - most police/ambulance/fire will not use voice but data (thermal printers were introduced in ambulances in the 1990s because that provides an audit-trail and cuts the possibility for mis-interpretation of instruction).

TETRA provides the ability to associate a phone number with a handset for a full-duplex PSTN voice call as it is a cellular system.  TETRAPOL did not have this facility last time I had anything to do with it (about 10 years ago).

TETRA in the UK is being retired soon (the soon is an interesting debate) in favour of a VPN offering similar services (most importantly continuous, full land-mass coverage) on one of the MNOs.   The major issue with matching TETRA has been RF coverage, not protocol.

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Rex Buddenberg
Sent: 19 November 2017 00:22
To: Ca By <[email-masked]>
Cc: [email-masked]; Alexandre Petrescu <[email-masked]>; Behcet Sarikaya <[email-masked]>; Dino Farinacci <[email-masked]>; Tom Herbert <[email-masked]>
Subject: Re: [5gangip] Agenda slides - more on id-locator split

Ca,

I'd submit that you have the 'this is way we've always done it'
blinders on.  There are lots of examples where we would like to use multicast ... if the capability existed. 

Reverse 911 is one example where a real multicast capability would pay off.
     What we have now is a robocaller that is fed a list of telephone numbers with a recorded message saying that the world is on fire or the dam is overtopping (both of which have happened around here in the past year), evacuate areas x, y, z.  Reverse 911 crams a real multicast requirement into n unicast calls at a point where time is of the essence.  And Reverse 911 has no reliability (as in TCP reliability or message receipt reliability) so we supplement it with sheriff deputies going door-to-door.
     So yes, we need a system where everyone is, to use your words, reading the same email.  

(There have been serious proposals to use Twitter for the purpose, but the limited character space collides with 1) the lack of reliability and 2) the ironclad need for digital signatures for authenticity.)

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 19 Nov 2017 21:21:03 +0800

+1
BIER could potentially change the picture.

Regards,
Jeff

> On Nov 18, 2017, at 13:34, Rex Buddenberg <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Sun, 19 Nov 2017 08:25:46 -0800

> multicast ... if the capability existed.

Rex, the multicast capability does exist and has for many years. There
have been many examples of where we'd like to use multicast (e.g. at
Google I had done a full design to implement multicast to implement
fork part of fork/join framework). The problem is that we could never
justify the cost of supporting multicast in production. Even in the
best case this is probably < 1% of packets, but the cost of
maintaining it was probably greater than 10%. There were other
practical issues: lack of reliability, inability to use IPsec, working
through firewalls, robust HW support, etc.-- such issues might be
solvable but it would take time to get to the same level of support
that we have with unicast.

The need for multicast-like distribution is always there, and the
problem has been addressed in many ways. A hierarchy of content caches
is a popular technique. For instance, Facebook is able to stream a
live video to many millions of viewers. No single server has the
bandwidth to do that so a content forwarding hierarchy is implemented.
This is done over unicast TCP that has the advantage that it is
ubiquitous in the Internet, security is well defined, and reliability
is built in. I don't see why this same method wouldn't be done in the
reverse 911 case (or to put it another way, I would hope this feature
is being blocked by lack of multicast support).

There may be a killer app out there that moves the needle for
multicast, but personally I don't think we've seen it yet...

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 19 Nov 2017 10:41:24 -0800

> On Nov 19, 2017, at 5:21 AM, Jeff Tantsura <[email-masked]> wrote:
> 
> +1

The only benefit to Bier is running it in the core so you can replicate packets natively in the core with no state. 

If the arguments that there is not enough multicast to care or it’s hard to do over wireless (802.11), then there is no reason to provide multicast the traditional way. 

However, providing a multicast service model to hosts so applications don’t have to care about application level replication and reduce the number of open sockets they have to maintain, then an overlay that can deliver such multicast (over unicast repli-encapsulation) is really the most practical way. 

And you can’t get that with ILA or ILNP. 

Dino

---

From: Antoni Przygienda <[email-masked]>
Date: Sun, 19 Nov 2017 20:17:18 +0000

My mailbox triggered on misspelled beer ;-) 

BIER is not targeted @ large # receivers multicast problem today, that is correct. BIER is an underlay 

1) It intends to make large scale multicast overlay feasible in the core, i.e. MVPN/EVPN/PIM tunneling and basically e’thing else that would use PIM, P2MP tunneling 
2) BIER is a very efficient (i.e. provides a fabric rather than a control plane with full fledged signaling and tons state)  small-scale multicast (up to 16K receivers or so per subdomain). And that seems to find fertile ground in many places; HomeNet, IP storage networking, in future likely anycast-gathercast distributed system problems (map/reduce as one flavor) 
3) BIER seems to be applicable as possible signaling for overlay multicast scheme even without the data plane necessarily, that’s kind of less obvious but once one starts to build an “overlay multicast replication” it is not trivial to synchronize those points in terms of understanding multicast routing there. Kind of hard to explain without whiteboard. 

End of the sales brochure ;-)

How that maps to the existing mobile multicast and whether it’s beneficial is an open problem that didn’t find a serious pair of eyes yet .. 

thanks 

--- tony

    

    
    
    Dino
    _______________________________________________
    5gangip mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=maKXfKzgRTpiLitqHnJiww&m=ipiRwKO7p6hLRZ7eVhNiVeq-N90P7DnU8G3oXhrgjYc&s=ENooFlL8gSRFvfFw4tkvFeQ4F5GLpvsdUbKb9CY73z8&e=

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 19 Nov 2017 12:54:06 -0800

> My mailbox triggered on misspelled beer ;-) 

You guys mis-spelled it.  ;-)

> BIER is not targeted @ large # receivers multicast problem today, that is correct. BIER is an underlay 

And that is a good thing. Because the underlay needs to be optimized. So thanks for spending the effort on it.

> 1) It intends to make large scale multicast overlay feasible in the core, i.e. MVPN/EVPN/PIM tunneling and basically e’thing else that would use PIM, P2MP tunneling 

Right, but what if receivers are spread throughout the network. Like at a branch site that is only running PIM. At a branch site that is not running PIM. At a residential site behind a NAT, in a cloud provider running behind a NAT? On a wireless Microwave link?

> 2) BIER is a very efficient (i.e. provides a fabric rather than a control plane with full fledged signaling and tons state)  small-scale multicast (up to 16K receivers or so per subdomain). And tha…

Right.

> 3) BIER seems to be applicable as possible signaling for overlay multicast scheme even without the data plane necessarily, that’s kind of less obvious but once one starts to build an “overlay multi…

I see a possible LISP RLE list of RLOCs that would be the following {unicast-RLOC, ip-multicast-RLOC, BIER bit-string} that reach receivers connected to different islands that can be reached by those means.

> End of the sales brochure ;-)

No worries. You need to bring people up to speed.

Dino

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 10:35:20 +0900

On Sun, Nov 19, 2017 at 5:40 AM, Tom Herbert <[email-masked]> wrote:

> common for mobile.

Tom, did you get around to documenting how /64 assignments work in ILA?
IIRC you answered my question about it by saying you know how to make it
work but haven't written it in the draft yet. I'm still confused about
where you'll get the bits from - perhaps you're trading them off with more
state in the network?

---

From: Tom Herbert <[email-masked]>
Date: Sun, 19 Nov 2017 17:57:21 -0800

On Sun, Nov 19, 2017 at 5:35 PM, Lorenzo Colitti <[email-masked]> wrote:
> Tom, did you get around to documenting how /64 assignments work in ILA? IIRC
> you answered my question about it by saying you know how to make it work but
> haven't written it in the draft yet. I'm still confused about where you'll
> get the bits from - perhaps you're trading them off with more state in the
> network?

Hi Lorenzo,

Documenting in draft form is pending, however if you look at my slides
(I posted them on this thread) the concept is diagrammed in the
overflow slides (slide 16). SInce we can't touch the IID both the
locator and identifier (reference to assigned prefixe) need to be
encoded in the upper sixty four bits. The idea is that a table is
maintained per locator returns the prefix for setting on egress from
the ILA domain.

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 20 Nov 2017 11:28:30 +0900

> maintained per locator returns the prefix for setting on egress from

I see. So to summarize, it looks like:

   1. When a packet from the Internet to the device enters the mobility
   domain, NPTv6 is used to rewrite the device prefix to the locator. (What
   happens to the checksum? Is the locator picked such that it has the same
   checksum as the top 64 bits of the device prefix?)
   2. When the packet reaches the mobility anchor (eNodeB?), NPTv6 is used
   again to rewrite the top 64 bits to the device prefix.
   3. Nodes on the path from the Internet and the mobility domain (Which
   nodes are these? the operator's peering routers? Per-POP or per-region
   sharded ILA routers that each keep state for some subset of the hosts?)
   must maintain all the mappings for all the devices whose global prefixes
   they are announcing (or, whose traffic reaches them).
   4. The NPTv6 mapping is dynamic as the device moves - every time it
   attaches to a new eNodeB, it gets an NPTv6 prefix consisting of that
   eNodeB's prefix pool plus a local identifier. The size of these pools will
   presumably be determined by the maximum number of devices that the eNodeB
   can provide service to.

What happens when the device originates a packet? Does the packet just have
the device's global address? (If so, does that mean the operator cannot
deploy stateful firewalls unless those firewalls are also aware of all ILA
mappings or are colocated with the eNodeB?) Or are the top 64 bits
rewritten, to preserve symmetry? (If so, then on their way towards the
Internet they must are again rewritten be rewritten to the device's global
prefix. How do you ensure that this happens, if only a subset of the ILA
routers will have state on that particular device's prefix? Do you need to
use source routing?)

There's clearly a potential scaling limitations at step #3 - on a
commercial router that can store 1M entries in the FIB, you'll need dozens
of them in every region to provide service to a large operator.

Also it's not clear to me how services internal to the operator's network
would work. Would they see the NPTv6 address, or the global address?

I also don't see the benefit over tunneling. The hard part of mobility is
not the encapsulation overhead or the CPU to push/pop the tunnel headers,
but the scaling problem where it's not feasible to push 100M mobility
mappings to all the operator's egress routers. How does ILA help with that?
And if that problem were solved somehow, why would ILA be better than
simple tunneling?

---

From: Tom Herbert <[email-masked]>
Date: Mon, 20 Nov 2017 07:50:12 -0800

On Sun, Nov 19, 2017 at 6:28 PM, Lorenzo Colitti <[email-masked]> wrote:
> When a packet from the Internet to the device enters the mobility domain,
> NPTv6 is used to rewrite the device prefix to the locator. (What happens to
> the checksum? Is the locator picked such that it has the same checksum as
> the top 64 bits of the device prefix?)

Low order 16 bits are still used for checksum neutral. When initial
prefix is determined the low order bits can be restored by undoing the
checksum difference.

> When the packet reaches the mobility anchor (eNodeB?), NPTv6 is used again
> to rewrite the top 64 bits to the device prefix.

At an eNodeB for instance.

> Nodes on the path from the Internet and the mobility domain (Which nodes are
> these? the operator's peering routers? Per-POP or per-region sharded ILA
> routers that each keep state for some subset of the hosts?) must maintain
> all the mappings for all the devices whose global prefixes they are
> announcing (or, whose traffic reaches them).

ILA routers at the ingress points to the domain perform the
translation. They would be sharded over the prefix.

> The NPTv6 mapping is dynamic as the device moves - every time it attaches to
> a new eNodeB, it gets an NPTv6 prefix consisting of that eNodeB's prefix
> pool plus a local identifier. The size of these pools will presumably be
> determined by the maximum number of devices that the eNodeB can provide
> service to.
>
Correct.

> mappings or are colocated with the eNodeB?)

Correct, source addresses are not ILA addresses. Firewall should only
ever act on SIR addresses (e.g. global addresses). If firewall is
needed in network it can do the translation before running the packet
though filters.

> Or are the top 64 bits
Yes, ILA domain would be sharded by prefix.

> There's clearly a potential scaling limitations at step #3 - on a commercial
> router that can store 1M entries in the FIB, you'll need dozens of them in
> every region to provide service to a large operator.
>
It's probably a common problem with any identifier/locator solution.
The identifier of a node does not have sufficient topology information
to deliver the packet so there is the need to perform the locator
lookup.

> mappings to all the operator's egress routers.

It's an ingress problem more that egress, but otherwise true. The
mappings are effectively host routes. A mitigating factor is this can
be done with fixed 64 bit lookups. The size of a mapping entry is also
relevant to fit entries into memory: the key for a lookup is 64 bits
and the prefix to write is 64 bits.

> How does ILA help with that?

As I said it's a common characteristic of identifier/locator split.
However, I am not convinced that solving this is infeasible. As I
mentioned in int-area this a problem of shared and replicated database
and there are key-value stores that efficiently handle datasets larger
than this. A key factor in mobility is the rate of change, i.e. how
many mapping updates per second. Internal routers perform translation
for intra network traffic. These offload routers and eliminate the
anchor point problem and triangular routing (like in GTP). Such
devices don't need to maintain the full set of mappings, only a manged
cache.

> And if that problem were solved somehow, why would ILA be better than simple
> tunneling?

Zero wire overhead, faster processing (only operation to modify a
packet is a single 64 bit write), no validation of outer headers for
tunnel egress, avoids known issues of tunneling like MTU, ECN, DSCP
propagation, preserves extension headers, avoid middlebox DPI and
parsing buffer limitations on routers, packet parsing for tooling and
packet capture doesn't change (although to determine the logical
destination from a captured historical data would be needed), the
protocol so that TCP/IP packets are still TCP packets on wire which
preserves network optimizations, ECMP, etc.

AFAIK no high speed routers that perform tunneling are willing to set
UDP checksum (in case of UDP encapsulation and the rationalization is
RFC) which does increase chances of misdelivery and if the receiver is
an end host there's a pretty good chance that checksum offload is lost
so host processing is a lot more expensive in that case. RFC6935 and
RFC6936 allow zero UDP checksum in tunneling for IPv6, however this is
with constraints and requirements even though some vendors and
encapsulations infer this make UDP checksums optional. Some UDP
encapsulation protocols, like LISP and VXLAN, make processing of a
non-zero received UDP checksum optional in contradiction to RFC1122.

One other consideration is the trend towards providing services and
serving content directly from servers in a provider's network. This
virtues of doing this are obvious in terms of saving bandwidth and
reducing latency. In order to achieve sub 100usec latency for critical
applications in 5G (like realtime hazard warnings in V2I) this mode of
operation becomes necessity. The servers themselves look a lot more
like datacenter devices and may run tasks or VMs that need network
virtualization (i.e. identifier/locator at servers). Per packet
performance is relevant for ultra low latency.

What we have found is that ILA out performs every encapsulation
technique in this scenario including those that preserve the value of
checksum offload (GUE). ILA can run on servers (the datacenter mode)
and perform translations to avoid triangular routing to clients. This
affords some optimizations and requires no specialized HW unlike
encapsulation. The performance difference is stark, ILA is about 10%
better in both terms of pps and latency. In fact, when compared to
native IPv6 we found that the difference within ILA performance is
within the noise.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Nov 2017 10:58:25 -0800

> to deliver the packet so there is the need to perform the locator

In draft-farinacci-lisp-mobile-node, the locator is the eNodeB (used for all EIDs assigned to UEs behind it). And those locators are already allocated and assigned to those eNodeBs today.

Dino

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 Nov 2017 23:01:44 +0000

(.. General comment, less related to this thread..)

With the separation of control and user-plane, all of the mobility
management approaches are some what converging in one sense. A policy rule
that the mobility control plane pushes to a user-plane function over FPC
interface (DMM spec), is very similar to a translation rule in ILA, or a
lookup approach in some central mapping table.

A rule to anchor a prefix on a node, a encapsulation rule or a translation
rule are all policy rules constructed in the control plane and pushed down
to a user plane node. Clearly, allows us to depart from a fixed-anchor
based model and to realize an optimized user-plane.

Scale is going to be certainly the key here.

Sri

>>>commercial
>_____________________________
>5gangip mailing list
>[email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Nov 2017 15:04:22 -0800

We also have something in LISP called “preditive-RLOCs” where the control-plane does not push state during a mobility event. You can find the design in draft-ietf-lisp-predictive-rlocs. The draft is a LISP WG document.

Dino

> On Nov 20, 2017, at 3:01 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 Nov 2017 23:21:15 +0000

Very interesting. Will read it.

Similar to FMIP I am guessing, with the side-way tunnel between the access
nodes in the predicted path of handovers.

Sri

On 11/20/17, 3:04 PM, "Dino Farinacci" <[email-masked]> wrote:

>We also have something in LISP called ³preditive-RLOCs² where the
>control-plane does not push state during a mobility event. You can find
>the design in draft-ietf-lisp-predictive-rlocs. The draft is a LISP WG
>document.
>
>Dino
>

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Nov 2017 15:41:40 -0800

Nope - here is a slide to high-level describe. 

Dino

> Nov 20, 2017, at 3:21 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
>

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 Nov 2017 23:46:43 +0000

Nice pic! 

It is similar to simulcast; vaguely remember Flarion guys doing this with
Mobile IP. The home agent would tunnel the packet to all the base
stations, with a similar drop policy on MN-loss detection on the access
link.

Sri

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 20 Nov 2017 23:55:14 +0000

Its probably this. Traces of bi-casting/simul-casting for reducing packet
loss in high-handover scenarios.

https://www.ietf.org/archive/id/draft-yokota-mipshop-3gfh-02.txt

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 20 Nov 2017 16:11:14 -0800

Yep, you got it. In the slide, the ITR would replicate to RLOCs (A,B,C,D) for EID-a but for EID-b the ITR replicates to (B,C,D) because it knows the EID has left A and is in range of B and headed towards C and D. Assumes there is some directionality. But pruning of the replication-list is done locally, with no signaling, to the FIB entry only.

Dino

> On Nov 20, 2017, at 3:55 PM, Sri Gundavelli (sgundave) <[email-masked]> wrote:
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 20 Nov 2017 19:57:17 -0600

Hi Sri,

You are in id-loc world. It is different.

If you try to understand it yourself by drawing parallels with tunneling
based MIP/PMIP world, good for you.
Please keep in mind that it is different.
Regardless, welcome to the list, please contribute to it :)

Regards,
Behcet

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Tue, 21 Nov 2017 02:30:28 +0000

Ahh ..id-loc??  Ok!

Is it like, HoA-CoA??

Sri

From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 20, 2017 at 5:57 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>
Cc: Dino Farinacci <[email-masked]<mailto:[email-masked]>>, Tom Herbert <[email-masked]<mailto:[email-masked]>>, Rex Buddenberg <[email-masked]<mailto:[email-masked]>>, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Ca By <[email-masked]<mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Subject: Re: [5gangip] Agenda slides - more on id-locator split

Hi Sri,

If you try to understand it yourself by drawing parallels with tunneling based MIP/PMIP world, good for you.
Please keep in mind that it is different.
Regardless, welcome to the list, please contribute to it :)

Regards,
Behcet

On Mon, Nov 20, 2017 at 5:21 PM, Sri Gundavelli (sgundave) <[email-masked]<mailto:[email-masked]>> wrote:
Very interesting. Will read it.

Sri

On 11/20/17, 3:04 PM, "Dino Farinacci" <[email-masked]<mailto:[email-masked]>> wrote:

>> On Nov 20, 2017, at 3:01 PM, Sri Gundavelli (sgundave)
>><[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> [email-masked]<mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 21 Nov 2017 21:14:50 +0100

> Is it like, HoA-CoA??

HoA-CoA is two addresses, whereas in some id-loc schemes the id and loc 
are parts of a single address.

HoA-CoA involves a single-point of failure HA and transmission between 
two points, whereas id-loc is diffused.

HoA-CoA never got Route Optimisation whereas id-loc has it built-in.

Id-loc is more next-generation than HoA-CoA is.

Alex

> Reply-To: "[email-masked] <mailto:[email-masked]>" 
> <[email-masked] <mailto:[email-masked]>>
> To: Sri Gundavelli <[email-masked] <mailto:[email-masked]>>
> Cc: Dino Farinacci <[email-masked] <mailto:[email-masked]>>, 
> Tom Herbert <[email-masked] <mailto:[email-masked]>>, Rex 
> Buddenberg <[email-masked] <mailto:[email-masked]>>, 
> Alexandre Petrescu <[email-masked] 
> <mailto:[email-masked]>>, "[email-masked] 
> <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>, 
> Ca By <[email-masked] <mailto:[email-masked]>>, Lorenzo Colitti 
> <[email-masked] <mailto:[email-masked]>>
> On Mon, Nov 20, 2017 at 5:21 PM, Sri Gundavelli (sgundave) 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     >><[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >>> [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/5gangip>
>     >>
>     >
> 
>

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 22 Nov 2017 01:22:22 +0000

> -----邮件原件-----
> 发件人: 5gangip [mailto:[email-masked]] 代表 Alexandre Petrescu
> 发送时间: 2017年11月22日 4:15
> 收件人: Sri Gundavelli (sgundave); [email-masked]
> 抄送: Rex Buddenberg; Tom Herbert; Dino Farinacci; [email-masked]; Ca By;
> Lorenzo Colitti
> 主题: Re: [5gangip] Agenda slides - more on id-locator split
> 
> 
> 
> HoA-CoA is two addresses, whereas in some id-loc schemes the id and loc are
> parts of a single address.

HoA could be deemed as a routable ID as well which is actually much beneficial in the transition scenario. 

> HoA-CoA involves a single-point of failure HA and transmission between two
> points, whereas id-loc is diffused.

You could deploy multiple HAs for redundancy purpose.

> HoA-CoA never got Route Optimisation whereas id-loc has it built-in.

HoA-CoA never got Route Optimisation, really?

Best regards,
Xiaohu

> > <mailto:[email-masked]>" <[email-masked]
> > <mailto:[email-masked]>>, Ca By <[email-masked]
> > <mailto:[email-masked]>>, Lorenzo Colitti <[email-masked]
> > <mailto:[email-masked]>>
> > If you try to understand it yourself by drawing parallels with
> > tunneling based MIP/PMIP world, good for you.
> >     >> management approaches are some what converging in one sense. A
> policy
> >     >>rule

---

From: Ca By <[email-masked]>
Date: Wed, 22 Nov 2017 01:54:35 +0000

> Id-loc is more next-generation than HoA-CoA is.

I don’t disagree with this next-gen designation, but LOC / ID split has
been around for a long long long time (GSE, 8+8 ....) and has yet to yield
anything meaningful on the internet.  Maybe it is still early day .... or
maybe it it never had or will have a chance. TBD.

My bet is that applications, just like they did with security,  will solve
this problem on their own. I ran a simple experiment, and  web youtube can
tolerate an IPv6 address changes on the host every 30 seconds without the
user noticing. At the end of the day, http video is just a constant series
of small http downloads that dont much mind if the ipv6 address is
different across video chunks.

> >     >> rule are all policy rules constructed in the control plane and
> pushed
> >     >>down
> >     >>>>> router that can store 1M entries in the FIB, you'll need
> dozens of
> >     >>>>> them in

---

From: Tom Herbert <[email-masked]>
Date: Tue, 21 Nov 2017 18:55:33 -0800

On Tue, Nov 21, 2017 at 5:54 PM, Ca By <[email-masked]> wrote:
>
> On Tue, Nov 21, 2017 at 12:14 PM Alexandre Petrescu
> <[email-masked]> wrote:
>>
>>
>>
> I don’t disagree with this next-gen designation, but LOC / ID split has been
> around for a long long long time (GSE, 8+8 ....) and has yet to yield
> of small http downloads that dont much mind if the ipv6 address is different
> across video chunks.
>
Ca,

It might be interesting to perform that experiment with a live
interactive video, real time gaming, or some other real time
application with tight latency constraints that can't so easily be
buffered (also, I have no doubt that the MPTCP folks think they have
solution for seamless address changes).

I'm a little worried that if we only target support and requirements
of currently existing application behavior that will lead to the
conclusion that the current model is "good enough". Such an approach
may be cheaper and more convenient in the short term, but it impedes
progress in the long term (esp. w.r.t. to forward looking technologies
like 5G). Latency, for instance, is generally horrendous over the
Internet today. Privacy is another area where we need to do a lot
better. There is only so much that applications and servers can do to
paper around issue like this-- at some point, the infrastructure
itself needs to be addressed.

Tom

---

From: Ca By <[email-masked]>
Date: Wed, 22 Nov 2017 03:56:19 +0000

On Tue, Nov 21, 2017 at 6:55 PM Tom Herbert <[email-masked]> wrote:

> been

I was fond of the early mSCTP work

> like 5G).

5G is a fairly meaningless term, so i am not sure what this could mean.

Latency, for instance, is generally horrendous over the
> Internet today.

Latency to what?  The internet is a big place.  Defining the A and Z
location is very important in any discussion of latency.

How could it be improved, aside from changing the speed of light?

Privacy is another area where we need to do a lot
> better.

Again, i am not following you on privacy. Privacy is also a big place. TLS
/ AES / ChaCha seem pretty good for confidentiality. CALEA / LI laws
mandate certain telco behaviors, and then beyond that is TOR, another
overlay.

There is only so much that applications and servers can do to
> itself needs to be addressed.

Experience and the E2E principle tell us L3 is not a place for innovation.
It is the stable and narrow waste of the internet.  It moves slow too

https://www.iab.org/wp-content/IAB-uploads/2011/03/hourglass-london-ietf.pdf

---

From: Tom Herbert <[email-masked]>
Date: Tue, 21 Nov 2017 20:54:20 -0800

> location is very important in any discussion of latency.
Latency for anything coming close to real time applications on the
Internet Like I said in response to you're YT test, an application
receiving video that can buffer several seconds of data to overcome
addresses changes doesn't prove much. The real test would be a
critical low latency application delivering safety information to
vehicles with hard latency ceiling of 100usecs. Show that can be done
with secure communications and seamless handover and then we're on to
something.

> How could it be improved, aside from changing the speed of light?
For one, eliminate stateful NAT, firewalls, proxies, load balancers,
and other middleboxes that break the end to end model, security,
multihoming, protocol ossification, and otherwise slow down the world.
NAT is good example of something that requires innovation at L3 to fix
(IPv6 eliminates the need for it).

> Again, i am not following you on privacy. Privacy is also a big place. TLS /
> AES / ChaCha seem pretty good for confidentiality. CALEA / LI laws mandate
> certain telco behaviors, and then beyond that is TOR, another overlay.
>
TLS and the like do not cover the whole packet. IP addresses can
reveal a significant amount of PII if not managed properly. There are
several discussions on this in v6ops.

> It is the stable and narrow waste of the internet.  It moves slow too
Experience also tells us that reality has diverged significantly from
the E2E principle. If the E2E model were adhered, then routers and
middleboxes would be much simpler, wouldn't do DPI and are only
concerned with IP headers and HBH options. But instead they are
invasive in ad hoc ways and that has forced applications to implement
workarounds (which might seem like innovation). To me the real promise
of IPv6 is that it might move the needle back towards the E2E model.

Tom

---

From: Ca By <[email-masked]>
Date: Wed, 22 Nov 2017 05:18:14 +0000

> with secure communications and seamless handover and then we're on to

Safety info?

These usecases are not realistic, mostly  they are not economically viable
(high cost, low revenue) and likely nil real world value.

> (IPv6 eliminates the need for it).

Already removed where i work. Next?

> several discussions on this in v6ops.

Ok, so you are talking TOR. Afraid latency is bad.

> of IPv6 is that it might move the needle back towards the E2E model.

We agree on this.

---

From: <[email-masked]>
Date: Wed, 22 Nov 2017 08:15:59 +0000

<dl> In-line </dl>

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: 22 November 2017 03:56
To: Tom Herbert <[email-masked]>
Cc: Rex Buddenberg <[email-masked]>; Alexandre Petrescu <[email-masked]>; Sri Gundavelli (sgundave) <[email-masked]>; [email-masked]; Dino Farinacci <[email-masked]>; [email-masked]; Lorenzo Colitti <[email-masked]>
Subject: Re: [5gangip] Agenda slides - more on id-locator split

On Tue, Nov 21, 2017 at 6:55 PM Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, Nov 21, 2017 at 5:54 PM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>
Ca,

<dl> AFAICS, “5G” means replacement of LTE by a more efficient version of numerology on the air interface.   At least, that is the only part (other than an outline architecture) which is defined by 3GPP.   N3 appears to be S1-U.   N6 appears to be SGi.  So really 5G as envisaged by 3GPP until at least Rel.16 really is the current model.   Changing that is going to be really, really difficult.</dl>

Latency to what?  The internet is a big place.  Defining the A and Z location is very important in any discussion of latency.

<dl> Agree.  Most “Internet” communications today are NOT “over” the Internet at-all but between you and a very local cache/server.  Look at any of the large CDN providers and then run a trace on your favourite video service (mine is BBC served via Akamai – other services are available).  My video is served from no-more than 2 hops away.

Is this true in current Mobile networks? Predominantly no – you are served from a CDN near the SGi.  But there are two GOOD reasons to that:

  1.  Mobility works and the deployment is simple.  Content owners HATE having to distribute their content – ask the BBC whether they are happy having to distribute all their content globally on 3rd party servers (that is the producers, not the techies) and they’ll tell you that it is a recipe for rights leakage.
  2.  LI.  There is an absolute requirement on SPs to provide the ability for ANY communications to be monitored without the fact that monitoring is in place being able to detect.   The simplest solution is LI on SGi.

Is there a need to improve things?

Yes, but as Ca By says, only if we have use-cases to justify the investment.   I can see packet-forwarding times across the current EPC of around 40ms and that is within the 150ms for voice calls so no need to improve there.

Does video need optimising?  Well, yes, live video is a PAIN to transport on our current unicast model (multiple streams of The Same Stuff) but quite honestly, a) few people are really watching live video any more and b) we can engineer the backhaul to cope.

IoT?  Yes, we can position the application “close to the edge” but what does this MEAN?  SPs are not IoT application providers and placing a terminating application at the “edge” of the network is fraught with administrative/ownership issues.  It would seem that we have an issue with orchestration/placement of the application rather than the underlying protocol.

{A total aside on IoT.  We’ve just spent the past 30+ years optimising the ‘net for a small-number of long-lived, large-frame flows.   Now we are asking it to cope with a huge-number of very small packets.  The overhead of payload:header(s) would seem to be all wrong and an area we SHOULD consider}

I think we need some concrete emerging use-cases that DON’T include the phrase “5G.”  Otherwise we get into a circular discussion of justifying 5G on new use-cases and new use-cases on 5G….  </dl>

Again, i am not following you on privacy. Privacy is also a big place. TLS / AES / ChaCha seem pretty good for confidentiality. CALEA / LI laws mandate certain telco behaviors, and then beyond that is TOR, another overlay.

<dl> Agree.   SPs are regulated utilities and therefore have statutory obligations to enable monitoring.   That has been the case since the first “Master of the Posts” in 1516 – at that point, the King reserved the right to intercept all communications.  We have moved on… a little…. If we do not cater for this requirement, any solution we postulate will not be adopted. </dl>

Experience and the E2E principle tell us L3 is not a place for innovation. It is the stable and narrow waste of the internet.  It moves slow too

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 22 Nov 2017 00:36:33 -0800

> I don’t disagree with this next-gen designation, but LOC / ID split has been around for a long long long time (GSE, 8+8 ....) and has yet to yield anything meaningful on the internet.  Maybe it is still early day .... or maybe it it never had or will have a chance. TBD.  

GSE and 8+8 couldn’t get deployed fast enough in those days because it was relatively early in IPv6’s lifetime.

We made a mistake when moving SIP to IPv6 in the mid-90s. We had a chance to fix the pseudo-checksum at that time and would have had Locator/ID split in those days. The folks that created ILNP, HIP, and ILA are noble for trying to do so with the existing deployment constraints we have today.

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 22 Nov 2017 12:31:00 +0100

Le 22/11/2017 à 02:22, Xuxiaohu a écrit :
> 
> 
>> -----邮件原件----- 发件人: 5gangip [mailto:[email-masked]] 代表
>> Alexandre Petrescu 发送时间: 2017年11月22日 4:15 收件人: Sri Gundavelli
>> (sgundave); [email-masked] 抄送: Rex Buddenberg; Tom Herbert; Dino
>> Farinacci; [email-masked]; Ca By; Lorenzo Colitti 主题: Re:
>> [5gangip] Agenda slides - more on id-locator split
>> 
>> 
>> 
>> HoA-CoA is two addresses, whereas in some id-loc schemes the id and
>> loc are parts of a single address.
> 
>> HoA-CoA involves a single-point of failure HA and transmission
>> between two points, whereas id-loc is diffused.
> 

I mean this: the software to execute RO seems outdated.  The umip.org
was revived in 2017, but the router implementation at one important
manufacturer still lacks important Binding Cache lifetime feature.  This
hampers deployment.

The recommendation from router manufacturer seems to be to forget about
MIP altogether, and consider PMIP instead.  But I am not sure the router
manufacturer implements PMIP-RO.

That is what I meant by saying that HoA-CoA never got RO.

Alex