Subject: Re: [rrg] RRG to hibernation

From: [email-masked] (Noel Chiappa)
Date: Mon, 12 Nov 2012 18:40:12 -0500 (EST)

> From: Dae Young KIM <[email-masked]>

    > This multiplicity of the locators, although the ID is single ... also
    > affects DNS entries.

Not necessarily. If the DNS only contains IDs (which is the way some designs
work), then there no DNS/locator issues.

	Noel

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 08:59:27 +0900

> work), then there no DNS/locator issues.

The description on servers in Sec. 4.1 of ILNP, p. 20, implies that.

The DNS concern is, however, a secondary thing. That a host has to be
associated with multiple PA locators inserted by multiple ISPs at ILNP
multi-homing is the real problem I'm pointing to. This is exactly the same
situation you might require with the current IP.

Where's the improvement on multi-homing? If there's no such improvement,
have we solve the table explosion problem?

-- 
DY

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Nov 2012 19:08:21 -0500

I do not see the difficulty.  We already have the IPv6 mechanisms to 
advertise the prefixes.  And we have the IPv6 mechanisms for hosts to 
combne the prefixes with teir IDs.
We also have the dynamic DNS mechanisms (with security) needed to 
advertise the results.

With ILP, these combinations can be changed during sessions, and traffic 
can change paths during sessions without impact.
With the current architecture, sessions can not change paths, and 
changes to the connectivity are hard to discover or utilize.

Thee are other multi-homing problems that are not solved.  Working out 
how to manage prefix assignments in an enterprise when external 
assignments change is one example of such issues (LISP takes a different 
tack, and thus the costs and benefits are different.)

Yours,
Joel

On 11/12/2012 6:59 PM, Dae Young KIM wrote:
> On Tue, Nov 13, 2012 at 8:40 AM, Noel Chiappa <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>          > From: Dae Young KIM <[email-masked] <mailto:[email-masked]>>
>
> multi-homing is the real problem I'm pointing to. This is exactly the
> same situation you might require with the current IP.
>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 09:12:38 +0900

Hi, Joel,

Perhaps a more direct question might serve here:

   o How has ILNP solved the problem of the DFZ routing table explosion?

On Tue, Nov 13, 2012 at 9:08 AM, Joel M. Halpern <[email-masked]>wrote:

> With the current architecture, sessions can not change paths, and changes
> to the connectivity are hard to discover or utilize.
>
> Thee are other multi-homing problems that are not solved.  Working out how
> to manage prefix assignments in an enterprise when external assignments
> change is one example of such issues (LISP takes a different tack, and thus
> the costs and benefits are different.)
>
> Yours,
> Joel
>

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Mon, 12 Nov 2012 16:28:18 -0800

>    o How has ILNP solved the problem of the DFZ routing table explosion?

Simple: one of the contributors to the explosion is the drive for PI prefixes.  This is driven by sites that choose to be multi-homed and want failover semantics that BGP can provide.

With ILNP, a site can get this semantics with multiple PA prefixes.

I hope that this is clear.  If not, this has been discussed ad nauseum in the mailing list archives.

Can we please move on?

Cheers,
Tony

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 13 Nov 2012 00:37:47 +0000

What explosion?

http://ripe63.ripe.net/archives/video/178
http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf

On , Tony Li <> wrote:

> Simple: one of the contributors to the explosion is the drive
> for PI prefixes.  This is driven by sites that choose to be
> multi-homed and want failover semantics that BGP can provide.
> 

-- 
Jakob Heitz.

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 09:52:42 +0900

On Tue, Nov 13, 2012 at 9:28 AM, Tony Li <[email-masked]> wrote:

>
> Simple: one of the contributors to the explosion is the drive for PI
> prefixes.  This is driven by sites that choose to be multi-homed and want
> failover semantics that BGP can provide.
>

Hold a second before you vomit.

Isn't the description the same with the current IP Internet? Can't the
current Internet do the same? Any change?

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 10:21:34 +0900

> http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf

OK, the explosion may not be dreadful as we thought in 2006:

  - The IPv4 growth has rounded up.
  - The growth is now with IPv6.
  - The Moor's Law is still saving us.

The RRG charter lists four focus items: scalability, mobility,
multi-homing, and inter-domain traffic engineering.

Then, according to your point, scalability is not an issue anymore...?

How then has LIS improved multi-homing than the status quo? How
significantly has LISP helped inter-domain traffic engineering?

It might help mobility a bit, but as far as connection resilience is
concerned, the same effect could have been met by a session layer; your
session does not break at transient breakage of transport connections.

I do take ILNP as one of the smartest LIS solution; no reservation.

My question is rather why we've indulged in LIS if routing scalability were
not an issue?

-- 
DY

---

From: Shane Amante <[email-masked]>
Date: Mon, 12 Nov 2012 18:54:16 -0700

Dae,

>    o How has ILNP solved the problem of the DFZ routing table explosion?

First, let me remind you that there *are* FIB aggregation techniques that may work to squelch some of the most egregious deaggregation that occurs out there.  IMHO, the following are the most promising, but there are others:
http://tools.ietf.org/html/draft-uzmi-smalta-01
More work needs to be done, specifically trials in _production_networks_ to qualify how good (or, bad) it really works.  I've asked several vendors to develop a prototype implementation of the above to test in my network, but have yet to see any takers, unfortunately.  (Someone please prove me wrong :-).

Also, more importantly, let me add that "DFZ routing table explosion" is not the only concern that operators solely care about.  Yes, it's an important factor, but it's not the _sole_ factor.  As I alluded to in a previous e-mail just recently to this list, there are additional things to care about:
- inter-domain routing protocol robustness, i.e.: one malformed UPDATE will not cause BGP session to reset
- ensuring "routing security" is a first-class design principle
- allowing for _additional_ routing metrics to be learned *and* used in terms of path selection.  Note, this is likely not a panacea, but most likely (in the end) *may* provide "hints" to end-hosts as to "path quality" so that they don't waste time hunting/exploring bad paths.
- and, yes, scalability of the RIB/FIB

So, let's not solely focus on one aspect of the problem-space, to the detriment of other useful areas that need to get solved.

-shane

> 
> On Tue, Nov 13, 2012 at 9:08 AM, Joel M. Halpern <[email-masked]> wrote:
> I do not see the difficulty.  We already have the IPv6 mechanisms to advertise the prefixes.  And we have the IPv6 mechanisms for hosts to combne the prefixes with teir IDs.
> We also have the dynamic DNS mechanisms (with security) needed to advertise the results.
> 
> With ILP, these combinations can be changed during sessions, and traffic can change paths during sessions without impact.
> With the current architecture, sessions can not change paths, and changes to the connectivity are hard to discover or utilize.
> 
> Thee are other multi-homing problems that are not solved.  Working out how to manage prefix assignments in an enterprise when external assignments change is one example of such issues (LISP takes a different tack, and thus the costs and benefits are different.)
> 
> Yours,
> Joel
> 
> -- 
> DY

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 11:11:33 +0900

On Tue, Nov 13, 2012 at 10:54 AM, Shane Amante <[email-masked]>wrote:

> First, let me remind you that there *are* FIB aggregation techniques that
> may work to squelch some of the most egregious deaggregation that occurs
> out there.  IMHO, the following are the most promising, but there are
> others:
> More work needs to be done, specifically trials in _production_networks_
> to qualify how good (or, bad) it really works.  I've asked several vendors
> to develop a prototype implementation of the above to test in my network,
> but have yet to see any takers, unfortunately.  (Someone please prove me
> wrong :-).
>

Good to know there are other ways to combat the problem.

>
> Also, more importantly, let me add that "DFZ routing table explosion" is
> not the only concern that operators solely care about.  Yes, it's an
> important factor, but it's not the _sole_ factor.  As I alluded to in a
> previous e-mail just recently to this list, there are additional things to
> care about:
> - allowing for _additional_ routing metrics to be learned *and* used in
> terms of path selection.  Note, this is likely not a panacea, but most
> likely (in the end) *may* provide "hints" to end-hosts as to "path quality"
> so that they don't waste time hunting/exploring bad paths.
> So, let's not solely focus on one aspect of the problem-space, to the
> detriment of other useful areas that need to get solved.
>
> -shane
>

Agreed.

Then why did we indulge in LIS? Was it a consensus that LIS is the way to
solve the 'other problems' that you mention above?

I was trying to echo Noel's comment like 'what routing problems has INLP
solved?'

If the 'other problems' you mention were our major problem space, weren't
there any other approaches than LIS? Any other more generic approach?

If I'm not wrong, LIS was introduced to this community through the
following arguments, out of the 2006 workshop:

 o Symptom: The DFZ routing table is exploding.
 o Primary Diagnosis: Incompetence in multihoming is the cause.
 o Secondary Diagnosis: Semantic overloading of IP address is responsible
for multihoming incompetence.
 o Prescription: Apply LIS.

So, if not for the problem of routing table explosion, why have we indulged
in LIS?

(As long as migration and mobility are degenerate cases of multihoming, the
same arguments and the question apply to them, too.)

Was LIS conceived fat beyond that quality from the beginning? An all-mighty
to solve all routing problems? Then, what routing problems has it solved?

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Mon, 12 Nov 2012 22:25:21 -0800

> http://ripe63.ripe.net/presentations/61-2011-10-31-bgp2011.pdf

a) Explosion is an inflammatory choice of words.  It's a growth rate problem.
b) This presentation that you cite is again misguided as it simply assumes that everything can grow at the rate of Moore's law with constant cost.  Moore's law does NOT apply to the data plane portion of core routers.  These are NOT commodity parts.  
c) The presentation also misses out on the fact that a more significant issue is DRAM speeds.  These don't keep up with table growth either, so growth turns into a convergence hit.

Regards,
Tony

p.s. We are reiterating the exact same discussion that we've had for the last 8 years.  Is there a point to this?

---

From: Tony Li <[email-masked]>
Date: Mon, 12 Nov 2012 22:26:40 -0800

> Isn't the description the same with the current IP Internet? Can't the current Internet do the same? Any change? 

No.  Today if you have a set of PA prefixes and your address changes from one to another, your TCP connections all break.

Tony

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 12 Nov 2012 23:49:41 -0800

> No.  Today if you have a set of PA prefixes and your address changes from
one
> to another, your TCP connections all break.

That's true, has been for quite some time, and yet nobody seems to be doing
much about it. Which makes you wonder how big of a problem that is in
practice. If applications were really hurting, you would hear complaints
from application developers. But you don't. The applications that need
reliable long duration sessions incorporate some trivial checkpoint and
restart mechanism, or some pretty elaborate consistency protocols for big
databases. They probably would do that no matter what the reliability of
TCP, as long as it is not "perfect." And PA renumbering is probably not very
high in their list of "stuff that occasionally break TCP."

-- Christian Huitema

---

From: Tony Li <[email-masked]>
Date: Tue, 13 Nov 2012 00:21:10 -0800

> high in their list of "stuff that occasionally break TCP."

They don't do PA renumbering.  They do PI instead.  Clearly checkpoint and restart are not sufficient, otherwise they could do PA easily.

Again, this has been discussed endlessly already.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 17:25:42 +0900

On Tue, Nov 13, 2012 at 3:26 PM, Tony Li <[email-masked]> wrote:

> one to another, your TCP connections all break.
>

OK, if that's all you care.

On one hand, having each hosts in a site deal with multiple PA prefixes
won't be much fun.

On the other, the same connection resilience could be achieved with some
sort of session management function on top of TCP, without resorting to LIS.

You've got good reason to believe in LIS. That's fine.

I'm still doubting whether LIS is the right answer to seamless multihoming.
It's only my problem, perhaps, not yours.

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Tue, 13 Nov 2012 00:37:19 -0800

> On one hand, having each hosts in a site deal with multiple PA prefixes won't be much fun.

Fortunately, only the network administrator HAS to deal with the multiple prefixes, setting up one per provider.  After that, everything within the network can be automated.

> On the other, the same connection resilience could be achieved with some sort of session management function on top of TCP, without resorting to LIS.

Absolutely true.  But then it might require application changes, which we'd like to avoid.  It would also not be intrinsic in the architecture.

> I'm still doubting whether LIS is the right answer to seamless multihoming. It's only my problem, perhaps, not yours.

Doubts are healthy, and we learn more by doing.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 17:45:26 +0900

On Tue, Nov 13, 2012 at 5:37 PM, Tony Li <[email-masked]> wrote:

> Fortunately, only the network administrator HAS to deal with the multiple
> prefixes, setting up one per provider.  After that, everything within the
> network can be automated.
>

Does this mean renumbering?

> Absolutely true.  But then it might require application changes, which
> we'd like to avoid.  It would also not be intrinsic in the architecture.
>

Which architecture?

And no application change with ILNP? I thought there'd be application
changes with ILNP, although none with the routers. Apps should take only
the half of the IPv6 address as host ID, not the whole.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Tue, 13 Nov 2012 17:52:51 +0900

On Tue, Nov 13, 2012 at 5:45 PM, Dae Young KIM <[email-masked]> wrote:

>> we'd like to avoid.

I'm mistaken. Perhaps, no change with ILNP; rather TCP has to be changed.

The pain would be the same if a shim session layer would be inserted on top
of TCP with having the socket interface look the same to APPs...?

-- 
DY

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 13 Nov 2012 12:06:51 +0200

> high in their list of "stuff that occasionally break TCP."
Outcome is that the networking people have to build larger L2 DC
networks so that applications don't break when a VM is moved between
locations - now the DC networks are becoming so large that we need
another layer (NVO3) to extend the VLAN range of the already very
large L2 DC networks.
Life would be so much easier to move a session from one VM to another
VM, with the help of a session identifier - instead the packets are
encaped with new headers on the "wire" and not at the hosts where the
encap/decap of the session layer should occur without changes for the
applications. Of course, some application will suffer; if all
applications are preserved as such then there is no true separation
between identifiers and locators because some of the applications make
use of the overload of Loc/ID (also transport protocol needs to evolve
in order to make multi-homing more convenient). However, it is a nice
starting point to apply the encap of a new header at the wire but it
shouldn't be the final goal, the goal should be to have a stack
containing a session layer.

Switching topic:
Danny and Shane had some thoughts about BGP, perhaps there is room for
improvement on inter-domain routing.  I agree there might some
unfinished topics for us, found an interesting paper on how BGP might
be improved.
http://www.cs.princeton.edu/~jrex/papers/multipath06.pdf

Patrick

---

From: Tony Li <[email-masked]>
Date: Tue, 13 Nov 2012 07:41:57 -0800

> Does this mean renumbering? 

Yes, for the end host, the assignment of locators can become automatic.

Tony

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 13 Nov 2012 08:30:58 -0800

>Tony

A nit: These connections will not break if HIP is being used.

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Nov 2012 07:37:22 +0900

> Yes, for the end host, the assignment of locators can become automatic.

I thought renumbering is the last thing people wanted to do....

-- 
DY

---

From: Tony Li <[email-masked]>
Date: Tue, 13 Nov 2012 14:58:02 -0800

> I thought renumbering is the last thing people wanted to do.... 

Manual renumbering is certainly the last thing that folks want to do.  This is why we're trying to automate it.

Please read the RFCs.  They will help.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Nov 2012 08:17:04 +0900

>  This is why we're trying to automate it.

I think renumbering could also be automated with the IP hosts, albeit you
might need a shim session layer not to break APP communications. This is a
non-LIS approach which you don't buy, though.

I might be interested in a non-LIS solution with no need for renumbering,
neither for a shim session layer. Since it's a non-LIS solution even
without a shim session layer, the host doesn't have to change at all.

-- 
DY

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Nov 2012 18:24:44 -0500

Shim6 does exactly what you describe.
It may even  a reasonable approach, although i has not gotten traction.
It is, effectively, a locator / identifier separation in a v ery limited 
form.

Yours,
Joel

On 11/13/2012 6:17 PM, Dae Young KIM wrote:
> On Wed, Nov 14, 2012 at 7:58 AM, Tony Li <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     Manual renumbering is certainly the last thing that folks want to
>     do.  This is why we're trying to automate it.
>
>
> I think renumbering could also be automated with the IP hosts, albeit
> you might need a shim session layer not to break APP communications.
> This is a non-LIS approach which you don't buy, though.
>
> I might be interested in a non-LIS solution with no need for
> renumbering, neither for a shim session layer. Since it's a non-LIS
> solution even without a shim session layer, the host doesn't have to
> change at all.
>
> --
> DY
>
>

---

From: Tony Li <[email-masked]>
Date: Tue, 13 Nov 2012 15:23:27 -0800

> I think renumbering could also be automated with the IP hosts, albeit you might need a shim session layer not to break APP communications. This is a non-LIS approach which you don't buy, though.

Long ago we went down the path of trying a shim.  It was not pretty.

> I might be interested in a non-LIS solution with no need for renumbering, neither for a shim session layer. Since it's a non-LIS solution even without a shim session layer, the host doesn't have to change at all. 

I too would be interested in free money.   But I'm not holding my breath.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Nov 2012 08:46:15 +0900

> It is, effectively, a locator / identifier separation in a v ery limited

Isn't it again a LIS?

Why not people trying to insert a real session layer? Then,
Transport/Network don't have to deal with two number spaces, ID and Loc.

-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Nov 2012 08:53:32 +0900

> I too would be interested in free money.   But I'm not holding my breath.

This group seems to be too much into LIS. There practically seems to be no
room for non-LIS advocates. As soon as you hint for a non-LIS, you're
almost harshly ridiculed.

Why should the routing group be so much biased toward LIS which has only
secondary/indirect implications on routing?

-- 
DY

---

From: "George, Wes" <[email-masked]>
Date: Tue, 13 Nov 2012 19:16:58 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dae Young KIM

This group seems to be too much into LIS. There practically seems to be no room for non-LIS advocates. As soon as you hint for a non-LIS, you're almost harshly ridiculed.

Why should the routing group be so much biased toward LIS which has only secondary/indirect implications on routing?
[WEG] I don't see ridicule of the idea of non-LIS. I see people trying to resurrect old arguments on the prior work of this group with points that have already been endlessly discussed with no consensus reached, and I see people responding patiently, but growing less patient as others don't get the hint that the rest of us are more than ready to move on to something new. Instead of trying to rehash the last several years, again, perhaps you can look more carefully at the problems proposed for new work in this group so that we can try to make some forward progress?
Wes George

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: William Herrin <[email-masked]>
Date: Tue, 13 Nov 2012 19:29:15 -0500

On Tue, Nov 13, 2012 at 2:49 AM, Christian Huitema <[email-masked]> wrote:
> much about it.

Actually, there's a whole IETF WG (MPTCP) dedicated to creating a TCP
Multipath option which would function appropriately with hosts holding
multiple PA addresses. There's a whole other group dedicated to
improving SCTP to a point where it's credible as a TCP replacement.
There's even a third WG (MIF) trying to work through the source
address selection implications of a host that sits on multiple
networks.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Nov 2012 09:38:40 +0900

On Wed, Nov 14, 2012 at 9:16 AM, George, Wes <[email-masked]>wrote:

>
>  *[WEG] I don’t see ridicule of the idea of non-LIS. I see people trying
> to resurrect old arguments on the prior work of this group with points that
> have already been endlessly discussed with no consensus reached, and I see
> people responding patiently, but growing less patient as others don’t get
> the hint that the rest of us are more than ready to move on to something
> new. Instead of trying to rehash the last several years, again, perhaps you
> can look more carefully at the problems proposed for new work in this group
> so that we can try to make some forward progress?*
>

OK, fine, let's move on.
-- 
DY

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 14 Nov 2012 10:17:47 +0900

>> It is, effectively, a locator / identifier separation in a v ery limited

(Not to stretch the discussion, but for clarification).

OK, Shim6 is not an LIS. But, the shim is between L3 and L4 while a session
shim would be between L4 and APP.

-- 
DY