Subject: [rrg] draft-irtf-rrg-recommendation-00

From: Scott Brim <[email-masked]>
Date: Sun, 15 Feb 2009 17:58:10 -0500

A few thoughts on this quick draft:

Pure higher-layer approaches aren't acceptable:

  - We knew that already, for operational reasons other than
    renumbering, for example the shim6 argument.  

  - But that doesn't mean those technologies aren't essential, because
    even if an endpoint only has a single locator within a domain,
    both endpoints and networks will be multihomed and/or mobile, so
    they will at least appear to have multiple locators in global
    routing.  Shim6, HIP, SCTP, Multipath ... all are potentially very
    useful.  It's probably outside of the scope of RRG since they do
    nothing to solve routing scaling, but it is an extremely important
    area for the future of the Internet.

The question is translation versus encapsulation.

  - That's being hotly discussed outside of RRG, for example AI6.  I'm
    wondering: will RRG's role only be as a forum where people can
    compare the results of the discussions and experiments being done
    elsewhere?

Thanks ... Scott

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 16 Feb 2009 08:47:52 +0100

Hi Scott,

>     renumbering, for example the shim6 argument.  

what is the shim6 argument?

>     nothing to solve routing scaling, 

what do you mean they do nothing to solve the routing scalability?
If every site and host uses only PA addresses, the routing system would 
scale in the order of ISPs, reducing the contribution by the multihomed 
sites.

Regards, marcelo

> but it is an extremely important
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>
>

---

From: Scott Brim <[email-masked]>
Date: Mon, 16 Feb 2009 11:17:34 -0500

> what is the shim6 argument?

The argument that took place between the IETF and network operators when
shim6 was recommended.

> scale in the order of ISPs, reducing the contribution by the multihomed

But that won't happen, because it requires site renumbering, multiple
locators per host within a domain, extra policy management and so on --
the things we discovered were operational showstoppers.  The host-based
mechanisms are vitally important but not as solutions to routing problems.

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 16 Feb 2009 11:27:51 -0500

I would say that the shim6 "argument" you are referencing has several 
difficulties in trying to apply it.
1) It was based on a faulty understanding of shim6.
2) It was based on the premise that operators should have total and 
absolute control over traffic engineering.

As I understood the argument, the claim was that shim6 "prevented" 
operator traffic engineering.  It didn't it restricted the scope to 
engineering traffic that was explicitly addressed to given access points.
More importantly in our context, the exact same argument can be made 
against CPE based LSIP, or any CPE based map-and-encaps.
In fact, given that the operator traffic engineering is typically based 
on incoming traffic engineering (outbound traffic is much easier to 
handle), the same "shim6 operator concern" can be applied even to PE 
based LISP or map-and-encapss solutions.

Hence, if that argument is valid against host based solutions, then we 
are completely out of luck.

Yours,
Joel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Feb 2009 14:51:35 +1300

> The argument that took place between the IETF and network operators when

SHIM6 is in development, so I don't think it's ever been recommended yet,
and anyway it's not the RRG's job to decide. So can we just
say that solutions above the network layer (including shim6, sctp
and multipath transport) are simply out of scope: the RRG has decided
not to work on them. Anything else is speculation.

> mechanisms are vitally important but not as solutions to routing problems.

Actually, they are things we opined are currently viewed as operational
showstoppers. I believe the telcos used to view TCP/IP as an operational
showstopper. It just isn't worth the argument; just say that the RRG decided
not to consider these as in scope.

    Brian

---

From: "Tony Li" <[email-masked]>
Date: Mon, 16 Feb 2009 21:51:38 -0800

Hi Brian,

|> The argument that took place between the IETF and network 
|operators when
|> shim6 was recommended.
|
|SHIM6 is in development, so I don't think it's ever been 
|recommended yet,
|and anyway it's not the RRG's job to decide. 

I distinctly recall it being recommended at a NANOG long ago and the ensuing
broohaha.

|So can we just
|say that solutions above the network layer (including shim6, sctp
|and multipath transport) are simply out of scope: the RRG has decided
|not to work on them. Anything else is speculation.

Except that that's not exactly true.  The RRG has not exactly declared them
out of scope.  So far, solutions that are above the networking layer require
per-host renumbering, and we have consensus that those solutions are not
acceptable.  If someone figured out an architecture (possibly combining
automated renumbering technology) that fixed things above the network layer
in an acceptable fashion, we would definitely consider it.

Tony

---

From: David Meyer <[email-masked]>
Date: Tue, 17 Feb 2009 07:35:05 -0800

> I distinctly recall it being recommended at a NANOG long ago and the ensuing

	Do you mean shim6 was recommended at a NANOG? I don't
	remember that, so can you be more specific? I don't
	remember what "broohaha" you're talking about either, so
	more specificity on that would be helpful as well.

	That said, there was a flurry of activity in various
	operator fora (RIPE, NANOG, APRICOT) in the 2006-2007
	timeframe (for what should be obvious reasons). See 
	http://www.nanog.org/meetings/nanog35/agenda.php or 
	http://www.nanog.org/meetings/nanog37/agenda.php for
	example. 

	In addition, for those interested in understanding why
	operators have been/are concerned, I highly recommend

	 http://www.nanog.org/meetings/nanog35/presentations/schiller.pdf

	as a place to start.

	Dave

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Feb 2009 09:09:35 +1300

> I distinctly recall it being recommended at a NANOG long ago and the ensuing

Advocated, certainly. Brouhaha, certainly. But every still shim6 document still
contains the words "valid for a maximum of six months" and it isn't even
aimed at ISPs anyway.

> in an acceptable fashion, we would definitely consider it.

Right. So the wording needs to be more subtle.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 Feb 2009 09:13:50 +1300

> 	 http://www.nanog.org/meetings/nanog35/presentations/schiller.pdf

That was a good talk, but 3 years ago, and I think Marcelo will tell you
that shim6 has evolved since then.

   Brian

---

From: David Meyer <[email-masked]>
Date: Tue, 17 Feb 2009 14:44:38 -0800

> that shim6 has evolved since then.

	And?

	Dave