protocols that don't meet the need...

Wed Feb 15 16:40:34 UTC 2006

	Daniel,
	
On Wed, Feb 15, 2006 at 11:51:12AM +0100, Daniel Roesen wrote:
> 
> On Tue, Feb 14, 2006 at 01:47:31PM -0800, David Meyer wrote:
> > 	IETF). Now, while many in the IETF argue that there is no
> > 	such thing as an "operator community", I personally see
> > 	it differently, and there are many of us who think that
> > 	operator input is sorely missing from the IETF process.
> 
> The problem with IETF and IPv6 is from my perspective, that operator
> input is being rejected as unreasonable or just ignored (shim6). I've
> stopped wasting time trying to bring operator's views/points across.
> It's not welcome if it doesn't fit already existing views within IETF
> regarding IPv6. I know that a lot of active IPv6 folks think the same
> but hesitate to communicate that openly.

	I understand your point, and hey, you're not the only one
	who sees it this way (and IPv6 isn't the only area where
	this problem is perceived to exist).

	Suppose we stipulate that your perspective (which is
	shared by many), namely that operator input is being
	rejected/ignored, is true. Then if we agree that IPv6 is
	here (for some value of "here", and as you mention
	below), then we need to find a way to solve the problems
	that we've been talking about here. My sense is that the
	likely place to do that is in the IETF (being the SDO
	that does this kind of work).

	So if you agree with what I've said above, how do we
	break the impasse and move forward? Like you, I'm
	interested in forwarding our common set of goals, and it
	seems pretty obvious that we need to find (or revive) a
	scalable routing architecture for IPv6. So lets find a
	way to do that (BTW, if I had the answer, I'd be the
	first to provide it. This is pretty thorney, as you've
	pointed out).

	
> > 	That is one of the reasons we did the NANOG 35 IPv6
> > 	multihoming BOF (and are doing the same at the upcoming
> > 	apricot meeting).  
> 
> Which is a good thing. But still, many IETF folks deny the fact that
> they constantly hear that things like shim6 is NOT what the ops folks
> (the folks that have to actually work with the stuff IETF brings
> forward) are looking for. And we know that it doesn't. It can't.
> There is no way to do traffic engineering with any shim6-like system
> like one can do with BGP as shim6 is a completely host-centric solution.
> It has no clue about upstream/downstream/peering, ASses etc. Those
> things that actually make topology and economics. That's aside all the
> other administrative nightmares associated.

	So I started writing up a I-D (the IETF coin of the
	realm) on this topic, but got sidetracked making slides
	for Apricot. I'd welcome anyone who wants to help me with
	that document (my approach was to outline the issues as a
	basis for bringing this discussion into the IETF). I
	could use the help. BTW, the doc is called 

                Issues In Traffic Engineering with SHIM6
                    draft-meyer-shim6-and-te-00.txt

	but I haven't published it yet. Again, anyone who wants
	to contribute/write/whatever, insight/thoughts greatly
	appreciated.


> > 	So (and again, not speaking for the IAB), my perspective
> > 	is that we really need your insight and perspectives,
> > 	more generally, your help in solving some of the
> > 	difficult problems before us (a viable routing and
> > 	addressing architecture for IPv6 comes to mind). 
> 
> I firmly believe that this train for IPv6 is long gone. We should go
> forward with IPv6 using the legacy routing architecture and start NOW
> working on a complete real re-vamp with a PROPER locator/identifier
> split - not an ugly hack ontop of the traditional IPv4/IPv6 like shim6
> which doesn't deliver what ops folks need.
> 
> Nevertheless, I really welcome IAB's efforts in the matter.

	Thanks, that is much appreciated.

	So on the theory that the best way to finish a task is
	to start it, let's start working on the document I
	mentioned above (if folks want to). If folks have other
	ideas, lets get those on the table too.

	Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20060215/9e9ee575/attachment.sig>