On Fri, Feb 14, 2003 at 08:59:21PM -0500, Alan E. Beard wrote: > > > I agree that NREN networks differ from other networks, but it does not > follow that other networks should thereby be forced to discriminatory > treatment while NREN networks obtain top-quality service. (BTW, Brown v. > Board is a 1950s US Supreme Court ruling which held that, in the provision > of services - in this case, public education - separate facilities or > service models for different groups are inherently unequal. Furthermore, > the Court held that, in this context, unequal == discriminatory. This is > considered a landmark ruling in the area of civil rights law.)
Alan, I note a second reference to this... You seem to have an "issue" with publicly funded research/education networks, which I don't quite understand. There are advantages and disadvantages with being attached to an NREN. There are quite strict AUPs that (should) prevent such networks being used for commercial purposes (which would be unfair competition with commercial providers). My original point was that there is a large (but very much minority) user and system base in the educational networks, where aggregation and (site or enterprise) multihoming is very rare (one of the disadvantages :) Perhaps universities in the future will be more keen to be multi-homed, but enterprise level multihoming is rare in this context. Universities are not forced to use NREN infrastructure, although it would not generally make financial or technical sense to go elsewhere. Tim > > > the client's services to the public networks; and high availability is > > > considered an absolute requirement for survival of the business. In > > > some > > > cases there are regulatory requirements which can result in civil or > > > administrative sanctions (including, in the worst event, loss of > > > operating > > > licenses) if the services should be found unavailable for significant > > > periods of time. Yes, it is possible, at least in theory, for > > > commercial > > > service providers to sustain the required level of availability, but > > > most > > > of my clients have found, much to their distress, that the US ISPs are > > > almost uniformly incapable of doing so in practice. In almost every > > > case, > > > the administrative managers for these user networks are simply and > > > flatly > > > unwilling to put their businesses at the mercy of a single ISP. > > > > This worries me but is more a topic of Nanog, or my planned > > presentation at the Barcelona RIPE rather than IPng. > > > This should worry all of us if we are determined to require PA as the > default allocation model for IPv6. And I will suggest that this is > properly a topic for the IPv6 working group: have a look at the charter. > > > > Based on conversations with my clients, I cannot find it within the > > > scope > > > of my imagination (or, for that matter, of theirs) that these networks > > > will give up the mutilhoming requirement at any time within the > > > foreseeable future. > > > > Hmm. So if someone where to write up a draft on how to do resilient > > routing, with different alternatives and pros and cons, could you take > > this to your customers? Randy, is this something to add to the > > Barcelona topics? I think I have some slides to start this off....(now > > all we need is a logo and we have a project) > > > Yes. However, I must caution you that resilient routing alone will not > resolve the objections of most of my clients to IPv6 as presently managed; > it merely removes one item from the washing bill. > > > > Home networks may be another matter, but I would give my eyeteeth to > > > get a > > > stable, portable (and, thereby, multihome-capable) IPv6 allocation for > > > _my_ home network, as that network also supports supports my office and > > > > Notice that this comes at a price. You and me are willing to pay for > > this, but how many are? > > > > > suspect that we will find increasing use of "home" networks for > > > business > > > activity, and increasing demand for stability of network locator > > > > Sure, but are you willing to pay for it? > > > Yup. But willingness to pay is moot if the service can't be had due to > administrative fiat. (This comment is in the business-network context.) > > > > can't multihome. Based on experience with my client base, I cannot > > > agree > > > with the postulate that many networks will not find lack of multihome > > > support a barrier to implementation of v6. > > > > I agree. Your client base seems to be exactly the target group. > > However, they also seems to be willing to pay for the service, as > > otherwise they will suffer financial loss that is higher than a days > > salary (if you can't log in from your home network). > > > I suggest further that these issues extend far beyond my client base; in > fact, to most businesses that rely in whole or in part on online systems > (those accessible from the public networks) for all or a substantial part > of their revenue. The number of such busineses is growing, and I would > prefer that it continue to do so. Under the current IPv6 allocation > practices, most of my clients can't get PI space, even if they were > willing to pay unlimited fees, since most of the groups are not > multi-national is scope. (In many cases, these businesses hold state or > national charters which explicitly forbid interoperation with foreign > businesses of the same type. Please note that foreign transactions are > not prohibited, but sharing of operational facilities - including networks > - _is_ expressly forbidden. At a minimum, a Chinese wall - i.e. firewalls > and separate routing domains - is required to satisfy the audit > requirements.) > > > > The current speculation about "what the users _really_ need" (as > > > distinguished from what they _say_ they need) smacks to me of "all > > > networks are equal, but some are more equal than others" (with > > > apologies > > > to _Animal Farm_). It seems to me that we have some technical > > > problems > > > > Agreed. > > > > - kurtis - > > > > > > I hope the above has clarified (or at least disambiguated) some of my > statements in the original note. > > Regards, > > AEB > > -- > Alan E. Beard <[EMAIL PROTECTED]> > AEBeard Consulting; 4109 Chelsa Ln; Lakeland FL 33809 > 863.815.2529 > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
