Subject: RE: Bad routes update

From: Richard Draves <[email-masked]>
Date: Wed, 21 Jul 1999 21:58:07 -0700

> > There are two answers to that. The short-term answer is an 
> RFC 2260-style
> > solution. The long-term answer is to change TCP so you can 
> change endpoint
> > addresses, for survivability and renumbering.
> 
> None of this will work today.

Do you mean, they would work but they are not ready "today", or you think
both approaches are unworkable?

One nice aspect of the RFC 2260-style approach is that it's an operational
solution, it doesn't require any protocol invention or development. So it
should be possible to deploy it "today". Well I don't really know enough
about router vendor implementations to be saying that confidently, but
that's my understanding.

I was thinking of trying to dig up some data on Internet usage or
Gartner-style analysis of business internet usage, but then I realized that
facts are probably not going to change anyone's mind on this issue :-).
Suffice it to say that I agree it's a great thing for TCP connections to
survive, and it should be and IS part of the proposal presented in Oslo, but
I persist in believing that it's less important than having new TCP
connections succeed.

> Right now, people pay lots of money for diverse providers for a good
> reason. It isn't that they love wasting money. They *need* the
> reliability. You're telling us that they don't exist -- but 
> of course, 
> if they didn't exist, why would you be worried about them exploding
> the routing tables?

No, it's the opposite. I agree that they exist and I think in the future
many many more people/companies will want to be multihomed. This would
actually be a selling point for v6, if we have a better story for
multihoming than v4 does.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Jul 1999 11:35:19 +0200

In your previous mail you wrote:

=> when the RFC 2260-style approach was published I found some problems
(complex setup, ISP reluctance, link failure only solution) and I asked
to Yakov Rekhter if this was deployed and his answer was yes.
Perhaps we should ask in IDR or NANOG mailing list in order to know
if it is really used?

[email-masked]

PS: RFC 2260 doesn't need something special in router implementations,
as you've said it is an operational solution (:-).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Jul 1999 11:55:26 +0200

=> there are two (nearly solved) cases:
 - outgoing new connections: if the preferred lifetime of "bad" prefixes
   is set to zero then we should only use "good" addresses as sources.
   In order to implement this we need failure detection (ie trigger
   next actions from a routing event), router renumbering (ie multicast
   the information) and neighbor discovery (ie standard prefix management),
   only the router renumbering part is not yet available...

 - incoming new connections: if literal addresses are used we are already
   dead. If DNS is used then it returns a set of addresses, "bad" ones
   don't work then the set is tried in an uncontrolable order until a
   "good" address works. There is only *one* standard BSD application
   which tries only one address: lpr. Of course with A6 it will be easy
   to speed up this mechanism (there will be only one RR to update in
   case of a failure in place of zillions of AAAA RRs which is simpler,
   faster and can be done with short TTLs).

Then the new connection issue is solved on the paper. I agree this should
be tested and deployed asap.

Regards

[email-masked]

PS: I believe standard Windows applications are doing the same kind of
things than in BSD, ie try the list of addresses returned by the DNS
until one works?
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 22 Jul 1999 19:43:20 +0900

>   only the router renumbering part is not yet available...

	I believe you can solve this with RFC2260 in reverse direction as well.
	ingress filtering may cause some trouble, but basically it is possible
	to use RFC2260-like approach for this.

itojun

---

From: "Perry E. Metzger" <[email-masked]>
Date: 22 Jul 1999 10:10:48 -0400

> both approaches are unworkable?

I personally feel the approaches are not known to be workable, but
that's really not important here.

What I actually insist on seeing working code with some test deployment
experience before we consider relying on something. Call me old
fashioned, but I don't like the OSI "design first and see if it works
later" approach that's been infecting the IETF lately. All too often,
it turns out a great idea doesn't actually work.

(I have a lot of concrete concerns, by the way. One of the biggest
problems with various EID schemes right now, by the way, is their
reliance on IPSec for *all* TCP traffic in order to get anything like
a semblance of network security. Unfortunately, to date, I know of no
one who's tried running a network that way (and I speak a one of the
fairly early IPSec guys). However, I'm willing to be proven wrong --
by working code.)

We have a working operational model of how to do this now. When we see
a new *working* operational model, then we can consider demanding that
people give up their old model. Until then, I'm going to keep shouting
pretty loudly that people are going to have to accept punched holes in
the routing topology for multihomed sites, and that at some point
they're going to have to just accept that the only reasonable way to
handle this is economics, not technology.

> multihoming than v4 does.

But after seven years, we haven't come up with one we can show, have
we. We've had lots of smart people think about this and come up with
straw proposals, but we've yet to see one actually demonstrated to
work smoothly in the real world. Lots of smart people haven't yet come 
up with something really usable yet. When they do, we can reconsider.

Perry

---

From: [email-masked]
Date: Thu, 22 Jul 1999 23:26:30 +0900

>> > > There are two answers to that. The short-term answer is an RFC 2260-style
>> > > solution. The long-term answer is to change TCP so you can change endpoint
(snip)
>handle this is economics, not technology.

	I believe RFC2260 just work, today.  There's no extra code needed.

	When you have two upstream ISP (ISP A and ISP B), all we needs to
	do are:
	- to setup tunnel between ISP A to your exit router B, and ISP B to
	  your exit router A (ISP coordination needed)
	- Then, announce routes properly with preference coordinated between
	  two exit routers.
	This can be done by BGP if you have AS#, or by RIPng if you coordinate
	with ISPs properly.  You do not need to announce more-specific route
	toward backbone to achieve this.  I'll be testing this configuration
	in my home soon.

	One issue you may worry about is how to convince ISPs.
	We are yet to see IPv6 ISPs (there are few, but not many).
	If first dozen of ISPs support RFC2260, newcommers will.
	(am I too optimistic?)

	We are really good at setting up tunnels BTW :-)

itojun

---

From: "Perry E. Metzger" <[email-masked]>
Date: 22 Jul 1999 10:39:40 -0400

> 	I believe RFC2260 just work, today.  There's no extra code needed.

The "inject routes only during failures" idea in 2260 is okay, but the
"add engineering tunnels" idea leads to seriously bad performance
issues during failures as lots of traffic suddenly traverses
encapsulated over the net. 

Neither will cope reasonably with the issue of picking an appropriate
prefix on laptop with which to try connecting to some site -- if you
have multihomed for performance reasons, we'd still need protocols to
tell desktop machines that going out via ISP A is better by far than
going out via ISP B. In the inverse sense, and in many ways more
critically, your customers will need to figure out which of the two IP
addresses a machine is known by is "better" for it to connect to.

Maybe some of this could be solved by query protocols by which end
stations could ask "which of these N addresses is `closest'", but we
don't yet have such protocols done.

Perry

---

From: Peter Tattam <[email-masked]>
Date: Fri, 23 Jul 1999 01:03:10 +1000 (EST)

> 	We are really good at setting up tunnels BTW :-)

I have used this very technique in IPv4 to deal with a UHF radio link that
occasionally drops out.

Consider our situation...

    TSI head office  <----------- radio link ---------->  Hobart CBD backbone
        |                                                       |
        |                                                       |
        V                                                       V
    Large Telco & ISP                                      Smaller ISP & telco
        |                                                       |
        +---------------------- Greater Internet ---------------+

We have connections to two ISPs. We also have two locations for our peering
points.  One peering point is direct to our head office which is not in the
CBD.  It is provided by "Large telco", and goes direct to their IP cloud.  We
also have a not quite as large ISP, but the cost of getting traffic to TSI head
office is fairly expensive as "Large Telco" pretty much controls all data
traffic in the region.  The locations are close physically, but because of a
large water mass (deep river between two), there is quite a distance to go to
get a direct link by land, so we have opted for the time being to use radio. 
Occasionally there is an interruption to the radio service for weather reasons
or when a very large ship docks right in front of the radio path.  To make this
survive I have a tunnel operating between the two networks which uses IP
addresses from each backbone ISP to form the end points.  This is up all the
time, but has a routing cost higher than the normal link across the river. 
When the link dies, the routers at each end detect the outage and the tunnel
kicks in.  Usually the time to detect it is less than a minute, and TCP
connections usually survive unless they have a small timeout.   This is all
done with EIGRP as the IGP.

While this is a simple example, I did find it took me a while to get working
correctly and there were some bizarre interactions with BGP which needed
some tweaking to get right, but they were possibly related to poor BGP
configuration in the first place.

Anyway, just to let you know that this works now, and could be endorsed if
ISPs get more used to working with tunnels.  I remember trying to explain the
setup to a Cisco help desk when debugging it & they were a little taken aback.

The downsides are the increased size of packets and possible fragmentation that
may occur.  As such, I only see it as a solution for temporary outages.

As an aside, I also tried the same technique to redirect traffic temporarily on
our private USA-AUS link for testing purposes.  Worked quite handsomely. 

Peter

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Peter Tattam <[email-masked]>
Date: Fri, 23 Jul 1999 01:14:55 +1000 (EST)

> encapsulated over the net. 

Not so bad.  I didn't notice significant degradation in my example.  Some
network is better than no network :)  BTW, my BGP setup is stuffed up because
the cost of getting the routers upgraded sufficiently to run full BGP at both
ends does not justify the benefit of doing so at this stage.  At a pinch, I can
staticly reconfigure the network to use one provider or the other, or I can
build in a fail safe to switch over to the other provider. This is an
argument in favour of aggregation as the BGP tables would be more manageable.

> addresses a machine is known by is "better" for it to connect to.

I believe the tunnel technique would solve this as all addresses should still
be visible.  Indeed, an end user could survive by still having only one primary
address allocation from one NLA for their main use, and a secondary address
allocation from a second NLA just for getting tunnels to route in the right
direction. 

Peter

---

From: Peter Tattam <[email-masked]>
Date: Fri, 23 Jul 1999 01:28:36 +1000 (EST)

This might be jumping the gun a little, but in the "choosing the soruce
address" part of the debate, how well will autoconfiged host pick up a
topology change via RA as has been suggested.  While autoconfig works ok when a
host comes on line since the traffic is likely to be lighter, but once a host
is in full swing on a busy network, might not important RA denoting a
significant network even get lost?  One might argue that network traffic would
drop anyway, but if there was also significant local traffic, this might not be
the case.  Perhaps when a signifcant net event takes place one could step up
the frequency of RA to make sure that everyone took notice of it.  This may
seem trivial on an ethernet LAN, but RA lossage might be significant on PPP
connections.

Just curious...

Peter

---

From: [email-masked]
Date: Fri, 23 Jul 1999 00:25:14 +0900

>addresses a machine is known by is "better" for it to connect to.

	I tried to be silent but I couldn't :-P

	Again, there are policy issues in multihoming.
	100 people have 100 different reasons for multihoming.
	100 people have 100 ways to decide which route is "better".
	What does "better" means in your text?

	RFC2260 tries to route your packet as much as possible during link
	failures.  So RFC2260 can be the foundation for other multihoming
	technologies.  With RFC2260 we can control routing to prefer leased
	line over tunnels.

	Using source address/destination address pair selection heuristics
	with RFC2260, you may be able to use (possibly) shorter route, based
	on prefix-length match.  However, as nobody has the whole picture of
	the Internet I would say that src/dst addr selection is just for
	heurestics.  This is documented by Rich Draves.

	Performance-oriented multihoming has no solution today for IPv4, since:
	- query packet will change the performance metric value (schrodinger's
	  cat-in-the-box)
	- what is the preformance metric value for you?  roundtrip time?
	  bandwidth?
	(let me know if you have solution for IPv4, I love to hear that),
	I believe this is VERY^128 hard problem.

	We need a clear categorization of problem domain, and then we need
	to see if we have solution.  Just saying "we need multihoming" is
	not useful.  So, we need to be silent till minutes comes up.

itojun