Subject: [rrg] Fwd: I-D Action:draft-irtf-rrg-design-goals-02.txt

From: Tony Li <[email-masked]>
Date: Thu, 16 Sep 2010 12:45:51 -0700

Hi all,

I've updated this draft with a few comments from various folks.  I'd like to see a bit more discussion on this.

Tony

Begin forwarded message:

> From: [email-masked]
> Date: September 16, 2010 12:15:02 PM PDT
> To: [email-masked]
> Subject: I-D Action:draft-irtf-rrg-design-goals-02.txt 
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Design Goals for Scalable Internet Routing
> 	Author(s)       : T. Li
> 	Filename        : draft-irtf-rrg-design-goals-02.txt
> 	Pages           : 8
> 	Date            : 2010-09-16
> 
> It is commonly recognized that the Internet routing and addressing
> architecture is facing challenges in scalability, mobility, multi-
> homing, and inter-domain traffic engineering.  The RRG is designing
> an alternate architecture to meet these challenges.  This document
> consists of a prioritized list of design goals for the architecture.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-irtf-rrg-design-goals-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Robin Whittle <[email-masked]>
Date: Fri, 17 Sep 2010 15:05:25 +1000

Hi Tony,

Here are my thoughts on your two changes.  I plan to write more
comprehensive comments in the next few days.

http://tools.ietf.org/html/draft-irtf-rrg-design-goals-02#section-3.5

  This section on "Simplified renumbering" previously ended with:

     It is strongly desired that a new architecture allow end-sites
     to change providers with significantly less disruption.

  This is now:

     It is strongly desired that a new architecture allow end-sites
     to renumber their network with significantly less disruption.
        ----------------------

  This is consistent with the goal of this section.  As has been
  discussed many times in the 3 years since the last revision,
  there's no practical way of renumbering substantial networks
  with today's architecture because the IP addresses of its hosts
  and of its entire networks are commonly found in config files,
  ACLs , DNS records etc. in many locations outside the network and
  which can't be reliably identified and controlled by the network.

  Even if they could all be identified and securely altered, doing so
  all at the right time, with good reliability, and without problems
  caused by cached versions of this information, seems to be an
  impossible goal.

  So it seems this goal would require all hosts, networks and
  the interdomain routing system to adopt an architecture quite
  different from what we have today.

  As I noted in July 2007:

     http://www.ietf.org/mail-archive/web/rrg/current/msg00203.html

  the above change in wording is desirable.  However, the real goal -
  what networks really want and need - is the ability to change
  providers without disruption.  With today's architecture, this means
  the goal is "portability" - the ability to use the same set of
  IP addresses via different ISPs, in a scalable manner, with the
  changes of provider being easy to achieve and free of risk and
  disruption.

  Portability is one aspect of what networks need - an occasional
  change from one ISP to another.  The next thing they need is
  multihoming - which is the same thing, but changing their
  network from one ISP to another, while both ISPs have already
  been chosen and connected to, on an ad-hoc basis, ideally within
  a few seconds.

  Mobility is the same idea, but more likely for single host
  physically mobile devices (or perhaps passenger aircraft) and
  with there being no prior arrangement with the new ISP.  If
  this is to be done in a scalable manner, with generally optimal
  path lengths, and in a way which is compatible with current host
  and routing architectures, then it seems that mobility needs
  to be done on a different basis to portability and multihoming
  of non-mobile networks.

http://tools.ietf.org/html/draft-irtf-rrg-design-goals-02#section-3.7

  The original single paragraph has been expanded to:

   In the branch of computer science that is devoted to programming
   language design, there is an explicit notion of a "first-class
   element" in the design.  These are language elements that are fully
   integrated into the language, with clear, consistent, logical and
   natural semantics and obvious interactions with all of the other
   elements in the language [FirstClass].

   For our architectural purposes, it is strongly desired that the
   primary mechanisms in an architecture all be first-class elements.
   More specifically, if a tunneling mechanism is used to provide
   network layering, connectivity virtualization, or a connection-
   oriented mode, then it is strongly desired that the tunneling
   mechanism be a first-class element in the architecture.  This
   requires that the issues of path MTU, reachability, and recursion
   be addressed.

  I think these changes are good.  However, a new architecture which
  uses tunneling doesn't necessarily involve recursion.  For instance
  Ivip doesn't involve ETRs on Ivip-mapped (LISP:EID) addresses, so
  there is never an instance of tunneling traffic packets to ETR-A
  via another tunnel to ETR-B.

  Also, some approaches to tunneling do not involve longer packets -
  such as Ivip's optional (at first) but highly desirable in the
  long-term techniques of "Modified Header Forwarding":

    draft-whittle-ivip-etr-addr-forw-01  (IPv4)
    http://www.firstpr.com.au/ip/ivip/PLF-for-IPv6/

  Likewise, some approaches to tunneling from ITR to ETR don't
  require the reachability of the ETR to be determined by the
  ITR.  This is the case for Ivip.  However, for LISP, the
  ITR decides which ETR to tunnel to, so it does need to test
  not just the reachability of the ETR, but the ability of the
  ETR to deliver packets to the destination network.

  I think the new wording is good, but I suggest changing the last
  sentence from "the issues" to "any issues":

     This requires that any issues of path MTU, reachability, and
     recursion be addressed.

  since "the issues" implies that these problems (AKA "issues")
  are invariably associated with a tunneling arrangement.

    - Robin

---

From: Toni Stoev <[email-masked]>
Date: Sun, 19 Sep 2010 05:56:06 +0300

Hi Tony, all,

The Abstract says:

... The RRG is designing an alternate architecture to meet these challenges. ...

The Introduction says:

... The Routing Research Group aims to design an alternate architecture to meet these challenges. ...

My opinion is:

The RRG is not designing an architecture. Although it is chartered to do so.

So my preference for the Abstract text is the exact sentence from the Introduction.

Regards
Toni