Subject: Re: Possible IAB workshop on routing and addressing participants?

From: [email-masked] (Noel Chiappa)
Date: Thu, 22 Jun 2006 09:35:47 -0400 (EDT)

> From: Brian E Carpenter <[email-masked]>

    > I think that the correct discussion is indeed about IP routing
    > architecture not about IP version numbers or address formats.

To the extent that the names the routing calculations care about are being
carried around in addresses, addresses are, by definition, on the table.
(If people are unhappy about that, they shouldn't have defined a packet
format where it's true.)

    > one of the reasoms shim6 came out they way it did was precisely because
    > the IP routing architecture is the way it is.

Can you expand on that? (The detail of how shim6 operates have drifted
out of my mind, alas...)

    > So if you don't like shim6, you pretty much have to change the routing
    > architecture.

I gather there was a lot of resistance in some operator forum (something to
do with NANOG, maybe?) to the whole concept of shim6. Some people were
pushing for that old canard, PI-space, as an alternative, and got a certain
amount of support for it. What's the currrent community take on shim6?

	Noel

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 22 Jun 2006 16:53:06 +0300

Hi Noel,

> Can you expand on that? (The detail of how shim6 operates have drifted

in a nutshell, the multihomed sites obtain PA blocks form their ISPs 
and each host within the multihomed site configures as many addresses 
as prefixes are available (one per prefix)
The shim6 protocol is an e2e protocol to support changing the locators 
used to exchange packet on the wire while always presenting a constant 
indetifier pair to the upper layers, in order to preserve 
communications through outages that result in prefixes/addresses being 
unreachable. The hosts select the locators to use based on an e2e 
failure detection protocol.

The shim layer located at the two endpoints then translate the received 
locator to the initial identifier pair

(note that no new namespace has be used for the identifier, just one of 
the available locators is used as identifier)

Regards, marcelo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Jun 2006 16:45:27 +0200

> Can you expand on that? (The detail of how shim6 operates have drifted

Well, we assumed that the only scaleable space was PA space and that
the site (hence the hosts in the site) has no control over which
locators are routed via a given ISP or AS, once out of the site's egress
router. So (unlike 8+8) the assumption was the standard Internet one:
a packet may or may not be delivered, and you don't know how it gets
there. Shim6 assumes that model and doesn't break it. Essentially it
synthesizes an EID by picking an arbitrary IP address and using it
as a pseudo-address for the entire session.

> amount of support for it. What's the currrent community take on shim6?

I won't comment on that - as ex Multi6 co-chair and co-chair of the Shim6
BOF, I'm definitely not neutral, and opinions vary.

    Brian

---

From: "Per Heldal" <[email-masked]>
Date: Thu, 22 Jun 2006 18:56:25 +0200

> amount of support for it. What's the currrent community take on shim6?

Opinions vary greatly. Some have little confidence with the IAB/IETF due
to the lack of progress in the last 15 years or so and do no longer
believe that a technical solution will be found before v4 reaches EOL.
Old-timers in the community are fed up and newcomers aren't exactly
encouraged to become involved either. 

Some don't realize that shim6 is only one brick in the brick-work. Many
of the pieces required by the ops community have yet to be defined. Some
examples:

* IGP routing must handle egress-selection in complex networks.

* Site-wide "routing policy controller" that interact with hosts for
dynamic prefix-management (add/remove) and influence prefix/path
selection (traffic management).

* Traffic-management hardware (load-balancers, proxies etc) need some
serious work. Possibly complete re-design.  

These things must be addressed to make shim6 useable for sites with more
than a handful of devices.

>From under my developer-hat i see potential and opportunities. Wearing
my ops-hat I see vapourware, not even an early alpha in sight. In the
real world there are business requirements which we have to create
solutions to either meet or eliminate. Independence from suppliers is
one such requirement. For IP connectivity that means PI-blocks ... in
the absence of alternatives. 

Is it really a good idea to fully deploy v6 for everybody now? Those who
need it for special purposes (mobile initiatives, various research etc)
should have little problem getting a block under the current policy.
There's no killer-app to drive v6 adoption, nor is there a real
requirement in the market. There's of course the old .gov/gosip crowd
and their army of consultants pushing their v6 ideas, but their
(in)ability in the area of product development was well documented in
the last decade. Maybe some day people in public administration will
realize that each ¢ spent on network research is probably more likely
to generate more value for the public than a $ spent on overpaid network
consultants. I'm all for a PI policy if there is no alternative, but
can't we give the research community as much time as possible and at
least wait until we either have to (no more v4 addresses) or at least
wait till v6 reaches a stage where it is supported by most devices to
the extent that it can be a drop-in replacement for v4?

//per
-- 
  Per Heldal
  http://heldal.eml.cc/

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 22 Jun 2006 20:44:20 +0200

> BOF, I'm definitely not neutral, and opinions vary.

Like Brian, I can't claim to be neutral here. With that out of the  
way, I firmly believe the shim6 architecture is the best achievable  
one based on sites having multiple PA prefixes. I don't think we need  
to go back and redo shim6, or go back and redo IPv6, because the  
tradeoffs haven't really changed. Doing the same thing again in the  
same environment but expecting different results is a very curious  
human tendency.

In the mean time, the internet has grown from 1.3 million hosts in  
1993 to about 400 million now: a factor 300 ( http://www.isc.org/ 
index.pl?/ops/ds/ ). But we're still running the same inter-domain  
routing protocol that reacts to changes in reachability between  
autonomous systems by enumerating all the prefixes affected, doesn't  
have a real inter-AS metric, suffers from convergence times that can  
on occiasion be longer than a TCP timeout, allows policies that  
prevent stable convergence altogether and lacks security.

I think this is an area where a new look at the problem may actually  
result in improvements over the current situation.

I say: let BGP4 retire at age 15 (well, 20 is more likely...) even if  
its successor can't provide multihoming for 10 billion sites or solve  
the transition to longer-than-32-bit addresses completely painlessly.