Playing the devils advocate .... Michel, can you describe, in a real world, nuts and bolts manner, where your "site" boundary would be.
Would your site boundary positioned based on : 1) A dramatic drop in bandwidth capacity eg from typical LAN to typical WAN bandwidth drop or 2) geographic network size or 3) Logical (eg tunnel) verses physical network connectivity I'm really struggling with what a "site" is. Using the current [addrarch] definition : -- Site-local scope, for uniquely identifying interfaces within a single site only. A "site" is, by intent, not rigorously defined, but is typically expected to cover a region of topology that belongs to a single organization and is located within a single geographic location, such as an office, an office complex, or a campus. A personal residence may be treated as a site (for example, when the residence obtains Internet access via a public Internet service provider), or as a part of a site (for example, when the residence obtains Internet access via an employer's or school's site) -- which says sites are primarily geographically bounded at around the campus size (say no more than a 5 KM diameter), then GUSLs really could only be used to join two campus networks that are geographically adjacent, and when combined, still fit within the geographically defined site size that the above suggests. All other site interconnection would have to use global addressing. How often are geographically adjacent sites going to merge, and still fit within the definition of an [addrarch] site, allowing the use of GUSLs ? I wouldn't think very often. For example, presuming a "site" is no more than 5 Km in diameter, if I was to join two sites that were 10 Km apart, with the current definitions, I must use global addressing between them. I've been told before on this ML that "site" doesn't have geographic boundaries (which would then allow me define the site boundary where every I like, and not exclude me from using GUSLs over a IPsec tunnel), but until the above text changes, as much as I'd like to, I really don't think I can assume that. Thanks, Mark. On Fri, 2002-11-29 at 05:38, Michel Py wrote: > Mark / Brian, > > >>> Michel Py wrote: > >>> GUSL solves the merger thing, but not the VPN. > > >> Mark Smith wrote > >> I'm not sure I see the difference. > > > Brian Carpenter > > I agree. As longs as GUSL prefixes are unique, you can > > flat route them in a "foreign" enterprise network. Maybe > > some ad hoc static routes are needed, but that's common > > in inter-enterprise VPN setups. > > Note that what you are saying was my original thinking. But it conflicts > with the following text in [addrarch]. > > > draft-ietf-ipngwg-addr-arch-v3-11.txt [Page 12] > > 2.5.6 Local-Use IPv6 Unicast Addresses > > [..] > > Routers must not forward any packets with site-local > > source or destination addresses outside of the site. > > Although there is no normative language, this seems pretty clear to me. > And, I hear there are lots of problems associated with site-locals and > multiple sites. > > I think that inter-site communications would be better off *not* using > site-locals. This means that today they must use PA, and could use GUPI > when it is available. > > In other words: The fact that GUSL could enable inter-site > communications (because it removes ambiguity) does not mean it should: > GUSL still are site-locals and must stay confined within the site. > > Michel. -------------------------------------------------------------------- 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] --------------------------------------------------------------------