> > in other words, just because a set of default rules might > > work for some apps is not a justification for requiring all apps to > > implement address selection code that often cannot work well. > > One address per interface doesn't solve all known problems either.
I didn't say it did, nor did I advocate that. (and there are so many things implied by "one address per interface" that it would take weeks to hammer out all of the details about which things you were trying to imply by that and which things you weren't. since it's not what either of us are advocating, let's just not go there) > > its not as easy as you make it out to be because there are > > industries that involve hundreds or thousands of suppliers > > (hundreds or thousands of separate sites) that want to make > > extensive use of private interconnects. it's easier to use > > non-routable globals than to make coordination of SLs > > scale to that degree. > > Careful, you are arguing that 38 bits is inadequate space for an > industry specific registry... Also, this argument amounts to a claim > that the industry can't manage an internal registry, but would be glad > to impose its needs on the public registries. no, I'm arguing that there aren't well-defined bounds on "the industry" (for any industry), so there are always potential collisions when you want to hook up some business that hasn't previously coordinated its use of SLs. and once you have the burden of getting an address block from such a registry you might as well use a global address space registry that prevents any potential collisions. > > another difference is that non-routable globals are > > unambiguous, so that apps that operate across site boundaries > > aren't required to deal with > > ambiguous addresses. > > Didn't you notice the phrase: 'coordinate the SL space when they > connect'? If the space is coordinated, it is unambiguous. you're assuming that IP connection boundaries are the same as app connection boundaries. they aren't. even if there are networks that coordinate use of SL space, there will still be apps that are expected to communicate across distinct 'sites'. (actually I prefer 'addressing realms' - 'sites' sounds too tied to geography. maybe we could call it realm-local addressing?) > > another difference is that with > > non-routable globals the app can allow the network to do all > > of the routing and enforce policy > > about who can connect to whom - with SLs the app will often > > have to do routing as site boundaries will not always > > coincide with boundaries of the application, and therefore > > any policy about who can talk to whom can > > only be implemented in the app. > > This is more an argument for PI than it is against SL. First, routing > across a site boundary can't happen if the address space is ambiguous, > because the routing protocols don't know how to deal with that. no, it just means that with SLs the apps have to do the routing between realms (and define their own addressing, and implement their own policy for where traffic can be routed) instead of having the network do that for them. > So you > are either talking about nat, or a coordinated address space with a > boundary router keeping the IGPs separated (a layer 3 area if you will). neither of the above. > > the ability of the network > > to provide > > security in depth is decreased with SLs. > > Let's stick to technical arguments... I just gave you one. > > ... > > I've already explained why that 'threat' isn't a problem. > > Yet most enterprise network managers still believe it is. beliefs and reality are different, it's true. but it's best to think of them separately. 'beliefs' can often be changed through education. > > ... > > we agree that a PI space is needed. now if we could just > > discourage use of SLs so that such apps would be able to run > > in most networks... > > Shipping code will do more to change behavior than a few lines of text > in an RFC. we could certainly ship code in both hosts and routers to discourage use of SLs, but somehow I don't think that's what you're suggesting... however host and router code implementors do read RFCs and sometimes they even do what they say. so having text in an RFC about how to deal with SLs really might have a useful effect. > > > As I said, this is the basis of a BCP. I know you don't > > like the idea > > > that it is the best we can do today in practice, but that > > is reality > > > so let's move on. > > > > no, it's not even the best we can do in practice assuming > > we're stuck with SLs. > > > > as it is obvious that SLs present many difficulties on many > > levels of the stack, we really should declare consensus that > > they should be discouraged except in cases where we know they > > won't cause problems - like isolated networks - and move on. > > This refuses to accept the fact that Rich says they are using them on a > connected network without problems. a network that only has one site and that primarily runs only one vendor's software doesn't exactly strike me as a good test case. > > ... > > nobody is trying to 'prevent' the network manager from doing > > anything - but we would do well to provide such managers with > > the benefit of our understanding that SLs are not as good an > > idea as was originaly thought. > > > > and yes, let's get a workable PI space established. we seem to agree > > that this is a better alternative. > > For the kinds of apps you are interested in, yes PI is where we need to > be headed. I doubt we will ever convince people that it is better for > some things that SL will get used for. well there are probably 'some' things for which SL really is a good idea. so far I haven't found many. and it would be really unfortunate if through misunderstanding SLs were given wider deployment than they deserve. Keith -------------------------------------------------------------------- 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] --------------------------------------------------------------------
