[RRG] draft-irtf-rrg-design-goals-01
Robin Whittle <rw@firstpr.com.au> Sat, 14 July 2007 08:11 UTC
Envelope-to: rrg-data@psg.com
Delivery-date: Sat, 14 Jul 2007 08:12:19 +0000
Message-ID: <46988517.5070401@firstpr.com.au>
Date: Sat, 14 Jul 2007 18:11:03 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Routing Research Group list <rrg@psg.com>
Subject: [RRG] draft-irtf-rrg-design-goals-01
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Here are some thoughts on: http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01 I agree with what I think is the thrust of this, but have some suggestions about how it might be improved, including perhaps with a specific focus on "portability". I wasn't involved in previous discussions about this, so maybe these points have been covered before. Regarding the inter-domain routing system: > Thus, the first required goal is to provide significant > improvement to the scalability of the control plane. This could be interpreted as meaning that the BGP system itself ("the control plane") - meaning the CPUs, firmware and BGP messages, rather than the FIB part of the routers - needs to cope with more of whatever is currently challenging it: number of advertised routes, number of transit and border routers, amount of traffic or responsiveness to changed advertisements. I don't see LISP or Ivip as being part of the "control plane" of the inter-domain routing system, but if a scheme such as this was successful, then it would greatly reduce the pressure which drives most of the growth in the global BGP routing table, by making single IP addresses and ranges of IP addresses (prefixes and other sets) portable and so suitable for multihoming and moving to another ISP without involving BPG. Unless LISP or Ivip are regarded as part of "the control plane of the inter-domain routing system", they could solve the biggest problems we face without formally satisfying this requirement. I think of LISP or Ivip as rather separate from the routing system, but I guess that is just the current routing system. They don't require any direct interface to BGP, other than the behavior of routers advertising or not advertising certain prefixes. I guess that if either was adopted, it would become part of basic infrastructure for getting packets to destinations, so we would then have a broader definition of the routing system to include LISP or Ivip. The definition of traffic engineering seems rather tied to the only current way of doing it: imposing restrictions on how the BGP routers select their best paths. LISP explicitly achieves TE in a way which doesn't quite match the definition: "directing traffic along paths other than those that would be computed by normal IGP/EGP routing." because the BGP routers continue directing traffic as normal. (Ivip could do some inbound TE by allowing rapid, low-cost, remapping of individual IP addresses to different ETRs, also without burdening the BGP system.) Maybe there could be a more functional definition of TE, such as "the ability to control inbound or outbound traffic flow over multiple links for purposes such as load balancing, using the most cost-effective provider, ensuring certain levels of packet loss are not exceeded for certain streams of traffic etc. - all as traffic patterns change over seconds, minutes and hours". Then, any proposal which achieves this will pass muster even if it doesn't technically match the definition. I am being pernickety here, but for instance, BGP wouldn't normally compute any path for packets addressed to a LISP (2+) EID because there is no advertised prefix for them. (With Ivip there is, but that prefix has no single home on the Net.) I would have thought that the goal of more scalable multihoming would be "Required", since this mainly what is driving the biggest single problem - the growth in the global BGP routing table. I think the definition of mobility is good. While there is mention of existing approaches, including using a "home-agent" which is an implicitly fixed topological location and has the mobile node's actual address, and so often leads to longer paths (stretch), the final goal is completely open ended about how mobility can be made more scalable and efficient. I think the "simplified renumbering" section is basically good. However it ends with a goal which doesn't mention renumbering. I think any architectural change which makes it easy to renumber networks is desirable, but since I can't imagine any solution which will ever make it acceptably easy for every or even most substantial end-users to renumber their network, I think the more important goal is "portability". I think the goal of portability of one IP address or a range of addresses is the central goal, but it is not stated explicitly as such in this I-D. The final sentence of "Simplified renumbering" is a valid goal, which could easily be achieved with portability, rather than ease of renumbering. If it was rewritten from: It is strongly desired that a new architecture allow end-sites to change providers with significantly less disruption. to: It is strongly desired that a new architecture allow end-sites to renumber their network with significantly less disruption. then this would be a good ending for the section on renumbering. The section on "Decoupling location and identification" also implies, to me, "Portability", but without actually saying so. This section initially uses "desired" and then "required", regarding decoupling host identification and location: > it is desired that a solution separate the host location > information namespace from the identification namespace. > Solutions to both problems, i.e. (1) the decoupling of > host location and identification information and (2) a scalable > global routing system (whose solution may, or may not, depend on > the second decoupling) are required . . . The "second decoupling" is, I think the earlier mention of: > the decoupling of end-site addresses from globally routable > prefixes I could take this text: 1 - the decoupling of host location and identification information 2 - the decoupling of end-site addresses from globally routable prefixes (This is stated as one of the possible approaches to creating a "scalable global routing system".) and say that this really means portability in two scenarios: 1 - The ability to deliver packets addressed to one IP address (being used as a host identifier) to any provider or AS-end-user network, without involving the BGP system. 2 - The ability to deliver packets addressed to a range of IP address, including especially a prefix, (being used as identifiers for multiple hosts or as locators for some scheme in which host identifiers are made portable) to any provider or AS-end-user network, without involving the BGP system. I think this really means just being able to make one IP address or a bunch of them appear at any edge network, without involving or burdening BGP (or perhaps while involving BGP, but in a much more scalable way than is currently possible). So to me, this is simply "portability" of one address or a prefix of them, with the latter implying a single management structure which doesn't depend at all on the hosts which use the addresses in that prefix. Questions about portability include: 1 - A single IP address, a prefix of them or an arbitrary range of them? 2 - Does the actual host(s) on these addresses need to be involved in the management of their portability. 3 - Does it work for both IPv4 and IPv6? 4 - Can the address(es) which are portable themselves be used as locators for a scheme which makes other addresses portable? LISP and Ivip handle single IP addresses and prefixes with equal ease. Maybe Ivip might be more flexible than LISP 2+ for arbitrary, non-prefix, ranges of IP addresses. The host(s) could be involved in the management, but does not need to be, whereas with SHIM6, which gives a very limited form of portability (from wherever the host initially appears to one or more other IP addresses, without breaking ongoing sessions), the host definitely does need to be involved in the management. If the network which you need to be portable includes the addresses of ETRs, then you can't use LISP or Ivip to make this network portable - you still need to have PI space and burden the BGP system with an extra route. So all ETRs must be located in a real, physical, conventional provider or AS-end-user network with PI space directly reachable via BGP. Any host or end-user edge network (1 to any number of IP addresses, whatever the purpose) can then be made portable via LISP or Ivip provided: 1 - The address(es) are within the LISP or Ivip system (and there could be various administrative arrangements for this) in a way which is secure and lasting enough for the end-user. 2 - The address or network which is thus made portable can't be used to host ETRs (unless via some tunnel to an ordinary BGP-reachable network). I think the "portability" is the key. With fast portability, you have mobile. BGP can't do this, but LISP or Ivip could, though not necessarily fast enough for glitch-free VoIP communications. With fast or slow portability, you don't need to renumber - so you have the ability to take an IP address or a whole range or prefixes of addresses to another ETR-equipped ISP, without having to worry about renumbering. BGP can do slow to moderate speed portability, and enable the portable network to have its own ITRs and therefore have hosts or other networks which use LISP/Ivip for their portability. But this should only be used for the networks of providers or of some end-users who for some reason can't satisfy their needs with LISP/Ivip-mapped addresses. LISP/Ivip can do slow, moderate or maybe fast portability - but not if the portable network needs to have ETRs etc. With fast portability, if you have two or more links to two different ISPs then you have multihoming. As above: if the network you want to multihome needs to have its own ETRs, then you can't use LISP or Ivip - you must continue to use BGP. LISP or Ivip can probably switch traffic to the new ETR faster than BGP, and doesn't involve getting BGP expertise, a whole (probably wasteful) prefix of PI space etc. So in setting goals, I think there could be a distinction between "portability, multihoming and/or mobility" for addresses in terms of: 1 - Whether the system works with a single control construct for prefixes - which makes it suitable for managing an entire network reliably (rather than relying on each host on the addresses in question to do something). 2 - Whether the space which is made portable etc. is expected to have ETRs. 3 - The speed with which the portability can be achieved, and how much burden each change places on the new global system. 4 - Whether the portable addresses need to be used for ETRs or some critical infrastructure which shouldn't rely on LISP/Ivip. Returning to "Decoupling location and identification" and "separate the host location information namespace from the identification namespace.": Both LISP 2+ and Ivip split the existing IP address space into addresses of two classes: 1 - Prefixes of addresses for which any packet whose DA matches the prefix will always be encapsulated by an ITR and tunneled to an ETR somewhere (or dropped, if that is what the database says to do for this EID/DID (LISP/Ivip) address. Therefore, these addresses, singly, in arbitrary sets or in prefixes, are portable to any provider or AS-end-user network with an ETR which will support the end user whose addresses these are. These addresses shouldn't be used for certain items of critical infrastructure and can't be used for ETRs. (Maybe they can't be used for ITRs in LISP, but Ivip ITRs can be on Ivip-mapped addresses.) 2 - The remainder of the address space, on which all LISP ITRs and all LISP/Ivip ETRs must be located - and of course which can still be used for all other purposes. I don't regard this as "two separate namespaces". Every host on the Net can ignore the distinction and just regard them as "IP addresses". Its just the global system of ITRs - which hopefully catches every packet addressed to some address in the first class - which always needs distinguishes between these two classes of address. - Robin http://www.firstpr.com.au/ip/ivip/ -- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
- [RRG] draft-irtf-rrg-design-goals-01 Robin Whittle