Subject: Re: [rrg] Consensus check: terminology

From: [email-masked] (Noel Chiappa)
Date: Thu, 9 Apr 2009 20:18:13 -0400 (EDT)

> From: William Herrin <[email-masked]>

    > If its practical for anycast to be an integral part of unicast routing
    > then it's likely to be suboptimal or even destructive to architect it
    > as a peer to unicast routing.

Anycast 'addresses' are service names. What we are doing, then, is using the
routing to route to service names.

This might be seen as good in the short term, but this kind of mixing of
fundamentally different functions in one mechanism is exactly the kind of
thing that, in the long run, can be a problem. 

For one thing, it's a truism of system architecture that as a system gets
larger, mechanisms that are used to do two different things don't scale well.
For another, it makes the resulting system more rigid, less adaptable, etc,
etc.

	Noel

---

From: Scott Brim <[email-masked]>
Date: Thu, 09 Apr 2009 21:23:10 -0400

> routing to route to service names.

Assuming you are right that anycast addresses are service names (see
below) you are using service names as forwarding selectors.  We do that
with deep packet inspection too for example.

> thing that, in the long run, can be a problem. 

It is not mixing different functions.  There is a big difference between
what forwarding uses and point of attachment names.  Forwarding can use
anything, and does (not all of it in the packets).  Granted it is
placing the service name in a field where one traditionally finds
addresses, but no actual functions are mixed.  Forwarding does what it
always does.  The service names cleverly look like addresses.

But all that assumes anycast addresses are "service names".  I want to
get back to the question of whether anycast addresses are locators.
Joel and I had a short phone call, and here's the example I used:

- Suppose I have a little network and I advertise a route to it on the
  Internet.  Are the names for points of attachment of the nodes on my
  network locators?  Yes (I hope you say).

- Now suppose Joel accidentally misconfigures a few things and ends up
  configuring exactly the same prefix for his little network, and
  advertising a route to it.  I haven't changed anything.  Are the names
  for the points of attachment on my network still locators, or are they
  just "service names"?

Joel suggested that the architecture shouldn't have to handle
misconfigurations, but it's deeper than that.  Someone making a mistake
does not change the essential nature of things in the architecture.  A
suggestion for a fundamental principle: If an architectural component is
fundamental, what someone does with it doesn't change what it is.

So I ask you: if I had locators to start with, why wouldn't I still have
locators after someone else claims to have them as well?  If the answer
is that I still do, how is that different from anycast?

Scott

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 09 Apr 2009 21:43:34 -0400

Considered as an architectural locator, in your example of accidental 
misconfiguration,
the locator is still a locator.
In fact, it is still your locator, locating your interfaces.
However, due to misconfiguration, the system no longer knows that in all 
places.

That is very different from something which is actually located in 
multiple places.

Joel

Scott Brim wrote:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Tony Li <[email-masked]>
Date: Sat, 11 Apr 2009 16:36:18 -0700

[Catching up...]

> always does.  The service names cleverly look like addresses.

I don't much care how cleverly it's dressed up, it's still an 
overloading of the token space.  That's not an unthinkable direction, 
but it should be done consciously, with care and forethought.

And regardless of much lipstick is applied, it still doesn't make the 
'anycast group name' into a locator.  It is simply an identifier for a 
group, with 'one of this set' semantics.  We also use it as a forwarding 
selector.

Similarly, the token that we use for a 'multicast group name' is an 
identifier for a group, with 'all of this set' semantics.

Perhaps one clear way of distinguishing these is to look at the embedded 
topological semantics embedded in these independently of the routing 
protocols.  For a locator, there is a specific, assigned location in the 
topology.  For these group identifiers, _all_ of the location semantics 
is necessarily embedded in the routing protocol.

> If an architectural component is

I like that, sort of, but it's missing something.  After all, all tokens 
are simply bit strings.  It's only in doing something with them that we 
assign semantics.  Perhaps another way of saying this is that if you 
overload semantics on an object, you don't obviate the original 
semantics of the object.

> is that I still do, how is that different from anycast?

A locator points to one assigned spot in the topology.  If through 
misconfiguration or maliciousness it is abused, then yes, it will be 
mapped to the wrong place, but the fact that we can say 'right' and 
'wrong' makes it clear that it has a semantic assignment to a given 
point.  Not so with anycast...

Tony

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Apr 2009 12:43:56 +0200

Not really relevant to your main point, but...

> but it should be done consciously, with care and forethought.

Just a historical note on this point.  When the NSRG considered 
architectural separation of identifier and locator, Steve Deering made 
the point that, particularly at layer 4, there are at least weak 
security benefits from having the transport use the IP address as part 
of the pseudo-checksum.

What he was really saying, I think, with the benefit of some eight years 
of hindsight, was that there are indeed risks we must consider should we 
decouple things TOO much.

Eliot