Cell Relay Archive

[Paul Koning <pkoning@xedia.com>]

Scott Brunstrom wrote:
> 
> Unless you are using scoping, the well-known and/or anycast addresses would
> not be summarized (since their prefix is not common to a peer group).
> 
> | Scott Brunstrom            |
> | Federal Systems Engineer   |
> | FORE Systems Federal, Inc. |
> 
> Allen Robel wrote in message <6k052a$g6n$1@flotsam.uits.indiana.edu>...
> >
> >Mike Uttormark wrote in message <6jvepf$78u$1@debris.uits.indiana.edu>...
> >
> >>I say this is bad because it requires the single LECS to be visible in
> >>multiple peer groups, and is thus a single point of failure for all the
> >>elans in all the peer groups.
> >
> >Mike,
> >
> >I'm not sure this is strictly true.  Since routes are summarized to higher
> >peer groups and longest match is used to determine route,
> >wouldn't a local lecs with well-known address always be chosen over a
> >remote lecs with the same address?  One could also use route
> >filtering to limit the advertisement of the well-known lecs address to a
> >single
> >peer group, or a single switch, or whatever.  Hence, it would seem
> >possible to run multiple lecs in different peer groups, all using the same
> >address. Am I missing something?

Some comments on the last few points:

1. Having the LECS address advertised beyond the PG doesn't require
there to be just one LECS.  A group address (such as the LECS address)
is a constant well known value so everyone can use it without explicit
configuration.  But "group" address means that more than one node can
advertise the address, and from a given place more than one such 
advertising node can be visible.  The assumption (which is not and
cannot
be checked) is that each visible node advertising a particular group
address
is an equally good candidate to talk to.  In other words, if you have
more than one LECS visible, you'd better make sure they advertise 
the SAME info or you will get VERY confused.

For that matter, you can have multiple LECS in a single PG (same rule:
they must be interchangeable).

2. Re Allen's comment, summarization isn't applicable here.  (Certainly
by default group addresses aren't summarized; I don't remember if
you can configure it to do so, it doesn't make much sense.)  But you
don't need summarization for this to work.  If multiple nodes advertise
a given group address (in full, all bits, all equal length), 
then you may find yourself connected to any one
of them when you ask for a VC to that group address.  Presumably (though
the standard doesn't require this) a nearby node will be favored over
one further away, i.e., a node in the local PG over one not local.
But since one may be down or a route unavailable, you may still be
talking to the more distant node at times.

	paul
-- 
!-----------------------------------------------------------------------
! Paul Koning, NI1D, C-24183
! Xedia Corporation, 119 Russell Street, Littleton, MA 01460, USA
! phone: +1 978 952 6000 ext 115, fax: +1 978 952 6090
! email: pkoning@xedia.com
! Pgp:   27 81 A9 73 A6 0B B3 BE 18 A3 BF DD 1A 59 51 75
!-----------------------------------------------------------------------
! "The only purpose for which power can be rightfully exercised over 
!  any member of a civilized community, against his will, is to prevent
!  harm to others.  His own good, either physical or moral, is not
!  a sufficient warrant."    -- John Stuart Mill, "On Liberty" 1859