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]
--------------------------------------------------------------------
