Would "provider independent local addressing" be a better name for site
local addressing if Tony's model is the most commonly followed ?

I would find that a more descriptive name, as it doesn't suggest that I
have to artificially place a boundary on the addressing due to physical
geography.

Mark.

On Thu, 2002-10-31 at 13:36, Brian Haberman wrote:
> Tony,
>       That is a reasonable approach and one that I could live
> with.  It allows SLs to exist and control is based on tools
> that are in wide use today.
> 
> Brian
> 
> Tony Hain wrote:
> > The whole discussion about lack of definition of site boundary is bogus,
> > and causing a large waste of energy. We don't tell people how to bound
> > areas in OSPF, yet we are expected to spell out the universal definition
> > of a site. To a first order, the concepts are exactly the same, how much
> > information is exposed across administrative borders. 
> > 
> > An organization should probably start with the assumption that a site
> > boundary is exactly congruent with an OSPF area, but they may choose to
> > restrict it further, or expand it when it makes sense for their network.
> > In any case, the site boundary should never be larger than the IGP
> > scope, so if we are going to talk about defaults, rather than assuming
> > every interface is in a different site, why not assume every EGP/IGP
> > boundary identifies a different site? If we can get past that, maybe we
> > can start talking about area boundaries as a reasonable default.
> > 
> > Tony
> > 
> > 
> > 
> >>-----Original Message-----
> >>From: [EMAIL PROTECTED] 
> >>[mailto:owner-ipng@;sunroof.eng.sun.com] On Behalf Of Brian Haberman
> >>Sent: Wednesday, October 30, 2002 10:46 AM
> >>To: [EMAIL PROTECTED]
> >>Subject: Default site-local behavior for routers
> >>
> >>
> >>So, one of the items that Margaret suggested was some text in 
> >>the node requirements doc or the scoped addr arch that states 
> >>that nodes default to being in one site.
> >>
> >>However, there has been some mention that people would prefer 
> >>different behavior in routers.  That is, the stated desire 
> >>was that, by default, each interface on a router be in its own site.
> >>
> >>This suggestion leads to the model where hosts with multiple 
> >>interfaces will assume that all its interfaces are in the 
> >>same site (e.g. have the same site-local zone id) unless 
> >>explicitly configured to have multiple sites.  While routers 
> >>will default to having a unique site-local zone id for each 
> >>interface (thus rendering SLs to link-local behavior) unless 
> >>explicitly configured to have multiple interfaces in the same site.
> >>
> >>This difference in behavior for hosts and routers leads to
> >>some interesting issues.  One big one is how the site-local 
> >>zone ids are setup and potentially changed when a host 
> >>becomes a router or vice versa.
> >>
> >>What are others' opinions on this issue?
> >>
> >>Brian
> >>
> >>--------------------------------------------------------------------
> >>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]
> > --------------------------------------------------------------------
> > 
> > 
> 
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------

Reply via email to