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

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

<I'll package up a couple of replies together here, and drop the CC to the
IAB because these are specific technical issues...>

    > From: Iljitsch van Beijnum <[email-masked]>

    > I see two things that can get a new routing paradigm or protocol
    > adopted: if it can run on existing routers where the existing way of
    > doing things would require investing in new hardware

That's certainly an interesting point to take into account, although I'd
be interested in hearing from people exactly how critical it is.

    > But only if the new thing can do IPv4 and IPv6 more or less as it
    > exists today, I don't think radically new addressing will fly with
    > operators any time soon.

By "radically new addressing [won't] fly", do you mean that you don't think
any other *packet format* would be supported, or that they would not support
deployment of a new namespace intended for use in path computations (i.e.
migrating some of the functionality of the exisiting "IP address space"
namespace to a new namespace, just as HIP does, albeit at the other end).

    > From: Lloyd Wood <[email-masked]>

    >> IPv4 made the choice to make the router<->router packet format be
    >> identical to the host<->router packet format - a congruency a new
    >> routing architecture wouldn't necessarily have to retain.

    > The ATM NNI and UNI interfaces didn't teach any lessons?

Did ATM have specific experiences with separate packet formats in the two
contexts that's has something useful to teach us? (BTW, the fact that NNI and
PNI as complete ensembles differ isn't that remarkable; in IP, the *overall*
host-router interface is different from the router-router interface -
e.g. hosts get redirects, routers don't; routers talk routing protocols to
each other, but they don't do that to hosts; etc, etc, etc.)

I'm not sure if this is what you were meaning, but I don't think you can read
much about the correctness of any particular engineering decision (e.g.
NNI/UNI differences) from the fact that ATM didn't succeed. I used to have
this line for reporters about ATM that everyone you talked to who felt that
ATM was a bad idea had something they would point to as a fatal flaw - and
they were all different! So there's not necessarily any connection between
the failure of ATM as a system, and any particular engineering point.

	Noel

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

---

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

> be interested in hearing from people exactly how critical it is.

Opinions differ, of course. Current routing table size related pain  
seems to be lower than at other points since about 1993. And it also  
makes sense that if routing could more easily handle more prefixes,  
more would show up.

> namespace to a new namespace, just as HIP does, albeit at the other  

Yes, for the most part, it's a packet format thing, but new semantics  
for existing address fields may also cause discomfort, see the  
reception of unique site locals with the NANOG crowd.

And let's not forget that there are operators of different kinds.  
ISPs will care greatly about packet formats, since they need silicon  
that understands those packet formats. But people who "operate"  
applications care more about the structure of the addresses, the  
exact packet formats are handled elsewhere. I think it's important to  
view Tony's assessment that operators are open to alternatives in  
that light: many people are very comfortable changing important parts  
of the architecture, just not the ones that they care most about.

The way I see it, the endless debates with multi6 and now shim6 show  
that few people are willing to accept a reduction in functionality or  
comfort within the area of their purview for the greater good. Not  
the best environment for architecture changes.