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 _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
