Subject: Re: PI/metro/geo [Re: The state of IPv6 multihoming development]

From: Brian E Carpenter <[email-masked]>
Date: Fri, 01 Nov 2002 14:44:08 +0100

Iljitsch van Beijnum wrote:
> 
> On Wed, 30 Oct 2002, RJ Atkinson wrote:
> 
> > > Very few non-ISP organizations do this, as it requires them to move
> > > traffic over their internal network which costs money, while receiving
> > > the traffic where it eventually needs to be usually doesn't cost more
> > > than receiving it at any other location.
> 
> > Our samples spaces must be different.  I think that many non-ISP
> > organisations
> > multi-home via different providers on either sides of North America.
> 
> It is certainly possible we're seeing different things from the places
> we're sitting. But the real question isn't whether they _connect_ on
> opposite ends of a continent or ocean, but whether they need to announce
> a globally visible route in both locations. This is only absolutely
> necessary if they prefer traffic to flow over their internal network
> rather than over an ISP network. It is also desireable for backup
> purposes but I feel this isn't an important enough reason to allow it.

Sorry, but that's not acceptable. Failover/backup is exactly why
such enterprises need this. As somebody else said, there aren't that many
multicontinental megacompanies that giving them unique prefixes is going to
significantly inflate the default table. The case we need to worry about
is hundreds of thousands of smaller, more local enterprises that
nevertheless need failover; we can't afford each of them to add a prefix.
But at current course and speed, that's where we're headed.

   Brian

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 1 Nov 2002 11:22:58 -0500

> From: "Tony Hain" <[email-masked]>

    >> We need to decide which is more important: the scalability and
    >> durability of the routing subsystem or the convenience of
    >> non-connection based addressing. When we have consensus on this point,
    >> then all else will follow.

    > The answer to the question depends on which side of the table you are
    > sitting on.

Really? How much use will someone's non-connection based addresses be when
the routing is no longer working, which means that nobody's packets are
getting anywhere?

	Noel

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Fri, 1 Nov 2002 18:39:51 +0100

> meeting the fact that the exchange couldn't get provider independent
> IPv6 address space was debated at length, RIPE has similar problems and
>

As an exchange operator in the RIPE region - just to be clear, the 
exchanges can get provider independent space for the actual exchanges, 
but not for the services. I have had this discussion and been convinced 
that that is not a problem.  What might be a problem is certain 
services that might be hosted at the exchanges such as TLD slave 
servers. But that is an issue with services, not with exchanges.

- kurtis -

---

From: "Michel Py" <[email-masked]>
Date: Fri, 1 Nov 2002 20:28:22 -0800

Tony,

> Tony Hain wrote:
> I don't expect to solve it, but if we are talking about a
> system to distribute mapping tables to align with current
> topology at the ingress and restore the original values at
> the egress, we should make sure the process does not make
> it easy to quietly influence which provider carries the
> traffic. The obvious method to prevent this would be for
> the site being mapped to sign its preferences, but that
> brings along its own operational and scaling issues. 

In other words, let's say that when the two CPE routers negotiate the
best path and use, say, RTT, your concern is that the carrier might try
to slam by traffic-shapping so RTT has high priority, thus making its
own link more appealing to the decision process. And this would be a lot
more difficult to detect than someone that prepends or manipulates the
AS-PATH.

Did I get this part right?

Would you have these concerns if the choice among the multiple addresses
was based on the AS-PATH instead of some glorified RTT thing?

Michel.

---

From: "Tony Li" <[email-masked]>
Date: Sat, 2 Nov 2002 23:53:22 -0800

|   You raise a point here that I think gets lost in the 
|   mapping proposals. 
|   'As far as your own hosts, the DNS and remote hosts are 
|   concerned, hosts
|   in your network have a single address.' 
|   If the upper 48 bits are constant in DNS, but continually 
|   changing in
|   the routing system, there needs to be a way to pass the 
|   possible set of
|   topologically appropriate replacement values between the 
|   CPE routers.
|   Since this protocol would inherently have to be run between
|   organizations that have no trust relationship, how that be 
|   deployable?

You have no trust relationship today with anyone that provides
you a locator.  [BTW, for multihomed sites, I would expect that
the locators would be advertised in DNS as well. Mobile hosts
would require a different mechanism.]

Hosts that frequently need to change their locator would need
to pass the new locator back to the CN.  This could be done
reasonably as part of the transport protocol.

Tony

---

From: "Tony Li" <[email-masked]>
Date: Mon, 4 Nov 2002 17:03:51 -0800

|   > My point is that when the external locators are configured in
|   > a very small number of places and internal addressing is 
|   independent
|   > of external addressing, renumbering is very simple.  In 16+16,
|   > I'd propose that the external locator be only in the 
|   border router.
|   
|   I have looked, but can't find a reference to the 16+16 draft, please
|   send a pointer so I can get into the context.

You've been reading all that there is of it.  We've been poking holes
in GSE, so when Ran proposed a 16B identifier, I went with it.

So no, there is no ID yet.  I'm trying to do this the old fashioned
way: get consensus and THEN write it down.  Yes, this makes for
less argument, so this might be less fun, but it might cause us to
converge more quickly.

|   > |   Well, for the general case that one 'system' needs to 
|   > |   include the border
|   > |   router, dns, firewall, ids, partner access lists, etc...
|   > 
|   > 
|   > Hmmm...  why?  The only thing that the border router does is
|   > to add or remove the locators from the L3 header.  Access 
|   > lists should be operating on the identifier, not the locator,
|   > correct?
|   
|   Once we figure out how to verify that the indetifier is 
|   really unique.

I have problems with crypto for that level of security.  But 
shouldn't that be something like the IPSEC AH header to authenticate
the identifier?  [Like others here, I don't know anything about security
and don't claim to.]

|   > |   In fact we have an existence proof in both DNS & IEEE EUI that
|   > |   inadvertent & intentional duplication happens. So those 
|   > |   mechanisms can't
|   > |   be used as 'globally unique' identifiers as they are. If 
|   > we add some
|   > |   cryptographic properties, we can probably improve that.
|   > 
|   > 
|   > Ok, but do we need actual perfect uniqueness?  Or just 
|   'pretty close'?
|   > Operationally, 'pretty close' is a whole lot easier.
|   
|   For RFC3041 addresses, the argument is that they are 'very close' to
|   unique, but we still require backing that up with DAD to minimize
|   confusion when collisions do occur.

Ok, I have no issues for doing this for part of the 16B identifier.  
Could you deal with some high order bits being internal to site routing?

|   > |   > I submit to you that if folks are unwilling to change to an
|   > |   > architecture that scales, then IPv6 is already doomed.
|   > |   
|   > |   If the changes are contained to the routers, the timeframe 
|   > |   is reduced
|   > |   from 7 years to 3. In any case a drastic change will take 
|   > |   two years to
|   > |   get vendor shipments and another year for service providers 
|   > |   to deploy. 
|   > 
|   > 
|   > Well, if the changes are confined to the routers, then that
|   > pretty much precludes transport changes and DNS changes.
|   > 
|   > I guess we're done.
|   
|   If a 5-10 year solution is what we really need, now is the time to
|   start. At the same time, I suspect we are a couple years 
|   from an IRTF
|   result that will take a few more to work through the IETF, so the
|   dev/deployment cycle can start. While that is working its 
|   way through
|   the system though, we need to find a way to fit an expanded set of
|   multihome sites into the existing mechanisms. 

An IRTF result from whom?  The routing research group?

|   My approach has been that we draw a line between those that 
|   need to be
|   in the global table for business/policy reasons, and those that are
|   looking for local alternate service. We aggregate the latter group
|   through exchanges, and simply eat the pain of the first group. This
|   becomes a self correcting situation when financial feedback 
|   is applied
|   to the number of prefixes that get injected into the global table. 

Ok, for a temporary hack, that's a fine start.  However, we've seen 
that there is no way to get financial feedback applied to the DFZ table.
Otherwise we would have long ago in IPv4.

Tony

---

From: "Michel Py" <[email-masked]>
Date: Mon, 4 Nov 2002 20:17:15 -0800

Aldrin,

> sorry i was referring to IP.  currently, higher-layer
> protocols add reliability and all the other good stuff.
> current multihoming practices (announcing prefixes to
> the internet) try to provide recovery at the IP-layer,
> the time-to-recovery of which widely varies depending
> on the nature of the outage and it's relationship to
> one's site. what should one consider an acceptable
> time-to-recover?  This varies greatly on the kind of
> application one is working with. This is what i meant
> when i said, there really are no layer-3 guarantees
> on the internet today.

We are saying exactly the same thing. Today, a link down will lead to a
BGP reconvergence that will often be longer than a typical TCP
connection will survive. Tomorrow, there is stuff on the table that can
make this delay a lot shorter. If the network guaranteed that the packet
loss would not last more than two seconds, would you say that there is a
layer-3 guarantee on the network?

The point we disagree on is that it's not because it does not exist
today that it means it won't exist tomorrow. If you want more details
email me privately.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Mon, 11 Nov 2002 19:14:45 -0800

Tony,

>>> [was originally "slamming" turned to manipulating the
>>> ASPATH or similar techniques to bend the customer's
>>> traffic to flow (or not) to a specific ISP]

>> Michel Py wrote:
>> Both of these are practiced today with IPv4. I'm not
>> saying it's a good practice, and one better have a
>> good explanation if caught, but it does happen. Are
>> we looking at a solution that *also* solves this
>> problem?

> brings along its own operational and scaling issues. 

Could you develop this a little bit?

The way I was seing this issue is that the "metric" or whatever one
calls the number that will make the choice of the host should to be
stealthy modifiable by the transit providers. In other words, if that
metric was based on RTT, transit providers could alter the RTT of
protocol datagrams without much detection, when if the metric was the
ASPATH this is much easier to detect.

Michel.