Subject: [rrg] Relativity & generality and Terminology, 3rd pass

From: Tony Li <[email-masked]>
Date: Thu, 02 Apr 2009 12:38:52 -0700

Hi all,

Thank you all for the highly spirited debate and my apologies for being 
unable to contribute.  Other high priority matters have been in the 
foreground.

I've read the entire debate so far and am struck by the fact that we 
made a change in the 2nd pass and early in the thread and I don't think 
everyone picked up on the importance of the distinction.  Specifically, 
it's vital to understand that a locator and identifier have semantics 
that are only relevant at a particular layer.  Furthermore, talking 
about identifiers and locators in absolute terms is not constructive; 
they are necessarily relative terms.

Remember that both identifiers and locators start off as simply tokens. 
  Names that we assign to things.  We assign them semantic values that 
happen to matter at a particular layer.  When regarded outside of that 
layer, those names then are simply opaque.

For a better example, let's stop arguing about Ethernet.  We have to 
operate with many link layers and our terminology must reasonably apply 
to all of them.  Let's look at what happens with IP over X.25.  An X.25 
address is a long string of bits and within the X.25 network, if 
administered in a sane fashion, the address is hierarchically assigned 
and nicely structured.  However, from the perspective of layer 3, it is 
wholly opaque.  Just a token, nothing more.  It has no semantics _at 
layer 3_.  Similarly, from the perspective of layer 2, the IP address is 
neither locator nor identifier.  It's just payload bits.

The key point here is that the semantics of a namespace is only relative 
to the layer where it is applicable.  The rest of the time, it's just 
opaque bits.

As another example, let's look at the FQDN.  At the application layer, 
it's clear that it's a practical identifier.  We map it through DNS to 
get an IP address that gives us a network layer identifier and locator. 
  However, at the network layer, the FQDN itself is nothing but a string.

So, it's all relative.

Putting this all together, here's pass 3.  Again, if I missed something 
or have misunderstood, please feel free to bring it up.  The goal here 
is to reach rough consensus on these definitions and we're definitely close.

Regards,
Tony

---------------------------------------------------------------------------

locator    A locator is a name that has topological sensitivity at a
	   given layer and changes if the point of attachment at that
	   layer changes.  By default, a locator refers to layer 3.
	   It is also possible to have locators at other layers.
	   Locators may have other properties, such as their scope
	   (local or global (default)) and their lifetime (ephemeral
	   or permanent (default)).

identifier An identifier is the name of an object at a given layer;
	   identifiers have no topological sensitivity, and do not
	   have to change, even if the object changes its point(s) of
	   attachment within the network topology.  Identifiers may
	   have other properties, such as the scope of their
	   uniqueness (local or global (default)), the probability of
	   their uniqueness (statistical or absolute (default)), and
	   their lifetime (ephemeral or permanent (default)).

address    An address is a name that is used as both an interface
	   locator and an endpoint identifier.

---

From: Dow Street <[email-masked]>
Date: Thu, 2 Apr 2009 19:43:41 -0700

On Apr 2, 2009, at 12:38 PM, Tony Li wrote:

> 	
> Hi all,
>
> Thank you all for the highly spirited debate and my apologies for  
> being unable to contribute.  Other high priority matters have been  
> in the foreground.
>
> made a change in the 2nd pass and early in the thread and I don't  
> think everyone picked up on the importance of the distinction.   
> Specifically, it's vital to understand that a locator and identifier  
> have semantics that are only relevant at a particular layer.   
> Furthermore, talking about identifiers and locators in absolute  
> terms is not constructive; they are necessarily relative terms.

Agree the definitions are relative.  I don't think "layer" alone is  
quite the right way to frame scope, though it is one way to frame it.

> Remember that both identifiers and locators start off as simply  
> tokens.  Names that we assign to things.  We assign them semantic  
> values that happen to matter at a particular layer.  When regarded  
> outside of that layer, those names then are simply opaque.

Mostly agree - I would say outside of a particular scope, where being  
of a different "layer" is an example.

> operate with many link layers and our terminology must reasonably  
> apply to all of them.  Let's look at what happens with IP over X. 
> 25.  An X.25 address is a long string of bits and within the X.25  
> network, if administered in a sane fashion, the address is  
> hierarchically assigned and nicely structured.  However, from the  
> perspective of layer 3, it is wholly opaque.  Just a token, nothing  
> more.  It has no semantics _at layer 3_.  Similarly, from the  
> perspective of layer 2, the IP address is neither locator nor  
> identifier.  It's just payload bits.

I think some of us want these definitions to make sense in a general  
and consistent manner across the various parts of the overall  
architecture.  Agree that if we call certain things out of bounds for  
this discussion, and that may make it easier.

> The key point here is that the semantics of a namespace is only  
> relative to the layer where it is applicable.  The rest of the time,  
> it's just opaque bits.

Mostly agree - same note as above.

> As another example, let's look at the FQDN.  At the application  
> layer, it's clear that it's a practical identifier.  We map it  
> through DNS to get an IP address that gives us a network layer  
> identifier and locator.  However, at the network layer, the FQDN  
> itself is nothing but a string.
>
> So, it's all relative.
>
> Putting this all together, here's pass 3.  Again, if I missed  
> something or have misunderstood, please feel free to bring it up.   
> The goal here is to reach rough consensus on these definitions and  
> we're definitely close.
>
> Regards,
> Tony
>

It is this "point of attachment at that layer" phrase that is still  
problematic.  If a host disconnects from one place on an ethernet  
segment and connects to another, it can still be reachable without  
changing it's IP address.  Are you defining this as not changing the  
point of attachment (in terms of layer 3)?

Also, to say that that a locator changes when the point of attachment  
changes depends on the nature of the routing system.  The locator  
could stay the same, and there could be a change to the routing state  
instead.  So there are some "relative topological scope" types of  
considerations in "this locator-ness" check, but the definition above  
does not capture those.

R,
Dow

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Apr 2009 00:55:04 -0700

Hi Dow,

> point of attachment (in terms of layer 3)?

_Exactly_.  If you change ports on your local Ethernet switch, then 
you've only changed the L2 topology, and done nothing at all at layer 3.

> changes depends on the nature of the routing system.  The locator could 
> stay the same, and there could be a change to the routing state 

I'd claim that by definition, that token then isn't a locator.  It 
sounds again like a forwarding system that's doing flat routing on an 
identifier.

I think that this is mostly a matter of semantics.  Since our concern is 
scalability, I don't think that flat routing is really all that 
interesting of a case anyway.

Tony

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 3 Apr 2009 09:56:44 +0200

Hi,

I am pretty happy with the definition of locator and identifier, yet..

> 	   locator and an endpoint identifier.

May be I missed something, but what is an "interface locator"?

Wouldn't be better to simplify the definition? We have defined what an  
"identifier" is and what a "locator" is, so IMHO an address is just a  
name  that can be used as locator or identifier.

Luigi

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

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Apr 2009 01:07:08 -0700

Hi Luigi,

> May be I missed something, but what is an "interface locator"?

Just what it sounds like: a locator for a specific interface.  This 
would be distinct from, for example, a system locator, endpoint locator, 
  or stack locator.

See the discussion that I had with Noel, as he's the one who proposed this.

Tony

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 3 Apr 2009 10:38:17 +0200

On Apr 3, 2009, at 10:07 , Tony Li wrote:

> would be distinct from, for example, a system locator, endpoint  
> locator,  or stack locator.
>

IMHO sounds a bit strange that we define identifiers and  locators and  
then we use the latter to locate interfaces....
I was thinking that a "locator" locates "identifier", if an identifier  
is associated to an interface, then it is correct, but I feel that  
somehow current definition introduces a constrain.

> See the discussion that I had with Noel, as he's the one who  

Thanks, I will get a closer look to that discussion.

Luigi

---

From: Xiaoliang Zhao <[email-masked]>
Date: Fri, 3 Apr 2009 10:23:45 -0400

Hi All,

Given historically "address" refers to both locator and identifier,
which may cause some confusion in this new context. How about call
"address" as "a binary implementation of a locator or an identifier"?

thanks,
x.zhao

On Fri, Apr 3, 2009 at 4:07 AM, Tony Li <[email-masked]> wrote:
> Just what it sounds like: a locator for a specific interface.  This would be
> distinct from, for example, a system locator, endpoint locator,  or stack
> locator.
>

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 11:21:55 -0400

Excerpts from Tony Li on Thu, Apr 02, 2009 12:38:52PM -0700:
> relative  to the layer where it is applicable.  The rest of the
> time, it's just  opaque bits.

Yes and also, even within the scope of a namespace a particular name
might not be usable at a particular time or place, and it will be
"just opaque bits" there.

> 	   layer changes.  

I see how "at that layer" neatly takes care of the "might not change"
problem.

Now that we have the ideas worked out, this first sentence could
actually be reduced to

  A locator names a point of attachment at a given layer.  

"names a point of attachment" implies that the name changes if the
point of attachment changes, and that in turn implies that the name is
topology-sensitive.  We could make those statements explicit but we
don't need to.

If we make them explicit, "topological sensitivity" needs tightening
up.  A locator itself is not topologically-sensitive.  It does not
change.  Rather, an endpoint's association with a point of attachment
changes, so the association between the endpoint and point of
attachment name ("locator") changes.  A locator does not have
topological sensitivity, the endpoint+locator association is.  

So I wouldn't mind keeping things explicit but I suggest something
like:

  A locator names a point of attachment at a given layer.  If an
  endpoint changes its points of attachment at that layer,
  associations between the endpoint and locators will change.

>          By default, a locator refers to layer 3.

Good

> 	   their lifetime (ephemeral or permanent (default)).

Good

> 	   locator and an endpoint identifier.

Hmm ... this brings in "interface" and "endpoint".  I suggest:

  An address is a name that is used both as an IP-layer locator and an
  IP-layer endpoint identifier.

---

From: Luigi Iannone <[email-masked]>
Date: Fri, 3 Apr 2009 17:33:51 +0200

>  IP-layer endpoint identifier.

Sounds much better to me.

Luigi

---

From: William Herrin <[email-masked]>
Date: Fri, 3 Apr 2009 13:04:26 -0400

>  associations between the endpoint and locators will change.

Hi Scott,

I like this a lot better.

It's still missing something though. LISP's LOC is definately a kind
of locator but it doesn't change when I move one of my servers from
one internal LAN to another internal LAN and assign it an address from
a different subnet. I've changed my layer-3 attachment but the
locator, which is also layer-3, doesn't change.

Maybe something more like:

A locator names a point of attachment within the scope of the network
topology for which the locator is used. If an endpoint changes its
points of attachment within that scope,  associations between the
endpoint and locators will change.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Dow Street <[email-masked]>
Date: Fri, 3 Apr 2009 10:51:40 -0700

On Apr 3, 2009, at 12:55 AM, Tony Li wrote:

>> changing it's IP address.  Are you defining this as not changing  
>> the point of attachment (in terms of layer 3)?
>
>

I am ok defining things this way.  To ensure we're on the same page,  
this means that only the network part of an IP address (from the  
perspective of the host) can ever be considered a locator, right?

Also, since the mask that is in effect (for forwarding) at various  
points in the topology differs, then the part of the IP address that  
we can call a locator also differs at various points in the topology.

>
>> Also, to say that that a locator changes when the point of  
>> attachment changes depends on the nature of the routing system.   
>> The locator could stay the same, and there could be a change to the  
>> routing state instead.  So there are some "relative topological  
>> scope" types of considerations in "this locator-ness" check, but  
>> the definition above does not capture those.
>
>
> sounds again like a forwarding system that's doing flat routing on  
> an identifier.

I think I agree - this is related to the comment above.

> I think that this is mostly a matter of semantics.  Since our  
> concern is scalability, I don't think that flat routing is really  
> all that interesting of a case anyway.

I am trying to get at this property of "relative flatness" of various  
names and/or parts of the IP address at different points of the  
topology, even if we are only talking about familiar, aggregation  
based approaches to scalability.

In other words, if we say that:

(a) on an ethernet segment (that maps to only a single prefix in the  
IP routing system), only the network part of the IP address of  
connected hosts is considered to be a (L3?) locator, then
(b) a similar property exists closer to the "middle" of the topology/ 
routing system if aggregation is used.

In (b), more specific prefixes "hidden behind" the aggregate are  
topologically flat from the perspective of processes that are only  
aware of the less-specific, aggregate mask.

I think maybe you are accounting for all of this relative-ness with  
the phrase "attachment point at that layer"?

R,
Dow

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 14:04:22 -0400

Excerpts from William Herrin on Fri, Apr 03, 2009 01:04:26PM -0400:
> one internal LAN to another internal LAN and assign it an address
> from a different subnet. I've changed my layer-3 attachment but the
> A locator names a point of attachment within the scope of the
> network topology for which the locator is used. If an endpoint
> changes its points of attachment within that scope,  associations
> between the endpoint and locators will change.

I'm having trouble deciding what that means, and I'm enthusiastically
trying, so I'm sure others will have even more trouble. :-p

A LISP RLOC names a point of attachment point for an ETR, and IP
forwarding in the core uses it as a locator to determine how to
forward the packet to that PoA.  Once the packet is delivered, the ETR
strips off the LISP header, exposes the header underneath, and uses
the destination address in that as a locator (which names an interface
on the destination).  

That all fits within the definition at the top.  There are two
"endpoints" in the sense of the definition: the ETR and the ultimate
destination.  LISP says: "Routing Locator (RLOC): the IPv4 or IPv6
address of an egress tunnel router (ETR).  It is the output of a
EID-to-RLOC mapping lookup.  An EID maps to one or more RLOCs."  It
doesn't say that an RLOC names a point of attachment for the ultimate
endpoint, just for delivery of the LISP-encapsulated packet.  IMHO the
association between an RLOC and an ultimate delivery point of
attachment is in the LISP encaps/decaps functions, and doesn't have to
be covered by the definition.

OK?

Scott

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 14:31:30 -0400

Excerpts from Dow Street on Fri, Apr 03, 2009 10:51:40AM -0700:
> points in the topology differs, then the part of the IP address that we 
> can call a locator also differs at various points in the topology.

Ok now we get into the sticky business of locators versus forwarding
directives, which we haven't explored and don't have to yet.  IMHO a
locator names a point of attachment ... but more or less information
can be used for forwarding a packet at various points along a path.

> I am trying to get at this property of "relative flatness" of
> various  names and/or parts of the IP address at different points of
> the  topology, even if we are only talking about familiar,
> aggregation based approaches to scalability.
>
> connected hosts is considered to be a (L3?) locator, then (b) a
> similar property exists closer to the "middle" of the topology/

The relative flatness thing is cool, but you're both right IMHO.  At a
particular "layer" (whatever that is), points of attachment have
unique names, but that's independent of routing and topology, which
can impose various degrees of hierarchy on the PoAs.  

Scott

---

From: William Herrin <[email-masked]>
Date: Fri, 3 Apr 2009 14:46:55 -0400

On Fri, Apr 3, 2009 at 2:04 PM, Scott Brim <[email-masked]> wrote:
> trying, so I'm sure others will have even more trouble. :-p'

Hi Scott,

Your version sets the scope at the network layer boundary. The locator
changes with my attachment at the layer boundary.

But that's not right. The scope is arbitrary. Protocol and design-dependent.

For example, I send a packet to 1.2.3.4 using a loose source route via
5.6.7.8. 5.6.7.8 is a locator. 5.6.7.8 serves as 1.2.3.4's point of
attachment to the larger network.

Once my packet gets to one of the routers which accepts packets to
5.6.7.8, the 5.6.7.8 locator loses scope and delivery proceeds based
on the 1.2.3.4 address. But there's no layer change.

Regards,
Bill Herrin

---

From: Christian Vogt <[email-masked]>
Date: Fri, 3 Apr 2009 15:59:00 -0700

On Apr 2, 2009, Tony Li wrote:

> 	   layer changes.  [...]
> 	   attachment within the network topology.  [...]

Hi Folks -

Since "topological sensitivity" is key to distinguishing identifiers and
locators in these definition, I believe we should be more specific with
respect to what we mean by it.  Much of the previous discussion was,
IMHO, due to people having different understandings, as exemplified by
the discussion on whether MAC addresses are identifiers or locators.

In particular, "topological sensitivity" could be defined as either or
both of the following:

(1) as the property of being used in path selection.

(2) as the property of encoding a path, strictly or loosely.

If we use definition (1), the categorization of a name as identifier or
locator depends on the use of the name.  Overloading, e.g., can turn an
identifier into a locator.  On the other hand, if we use definition (2),
the categorization of a name is independent of the use of the name.

The earlier discussion between Tony and Dino on whether MAC addresses
are identifiers or locators exemplifies the need for more specificity of
what we mean by topologial sensitivity.  Dino argued that a MAC address
has topological sensitivity, and hence is a locator, because MAC
addresses are used for path selection in switches. He is absolutely
correct if we define topolocial sensitivity as in (1) and consider
switched Ethernet.  Tony argued that MAC addresses should be considered
identifiers because they were originally not used for path selection. He
is absolutely correct if we use definition (2), or if we use definition
(1) and consider traditional, non-switched Ethernet.

To avoid misunderstandings, I would hence suggest defining "topological
sensitivity" -- either as a separate definition, or by making existing
definitions more specific.  Personally, I am in favor of definition (2)
because it provides terminology that remains stable independent of usage
and overloading.  Obviously, other folks' mileage may vary.

- Christian

---

From: Scott Brim <[email-masked]>
Date: Fri, 3 Apr 2009 21:46:20 -0400

> Hi Scott,
> 
> Your version sets the scope at the network layer boundary. The
> locator changes with my attachment at the layer boundary.
> 
> For example, I send a packet to 1.2.3.4 using a loose source route
> via 5.6.7.8. 5.6.7.8 is a locator. 5.6.7.8 serves as 1.2.3.4's point
> of attachment to the larger network.
> 

There are three things that may need naming.  In order of increasing
generality:

  1.  A point of attachment, aka "PoA", for the ultimate destination
      (at a given layer).

  2.  A "waypoint" which is on the path to the ultimate destination.
      This may be considered by some to include #1.  

  3.  Anything that is used to make a next_hop forwarding decision,
      including other parts of packet headers, policy, whatever.  This
      may be considered by some to include #2.

We're stuck with "locator" as naming one of these.  I was trying to
apply it to #1.  I think that Bill is applying it to #2.  Bill?

I would include "logical" PoAs such as anycast addresses in #2.
Because LISP is an encapsulation, I would include LISP RLOCs in #1,
not #2.

I don't know what to call #3 except "input to forwarding functions".

"Forwarding directive" came out of NewArch -- see
<http://www.isi.edu/newarch/DOCUMENTS/falk.FARADS.ppt>.  It seems to
overlap our concepts of stackID and locator -- that's something to
think about.

But the big question is: which of these three do you think is the best
match for the way the rest of the I* is using "locator"?  

Scott

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Apr 2009 09:07:38 -0700

Hi Luigi,

> somehow current definition introduces a constrain.

Actually tying locator to identifier directly in that way would be a 
constraint.  And we already have cases where the locator is associated 
with a subnet and the identifier is a stack.  Obviously, there needs to 
be some mechanism between the two, but if that exists, who are we to 
complain?

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Apr 2009 10:50:24 -0700

Hi Scott,

> topology-sensitive.  We could make those statements explicit but we

I think we need to be more explicit as I don't think everyone will make 
that same implication, so I lean towards what you have below.

>   associations between the endpoint and locators will change.

Ok, I morphed it slightly:

	   A locator is a name for a point of attachment within the
	   topology at a given layer.  Objects that change their point
	   of attachment(s) will need to change their associated
	   locator(s).

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Apr 2009 21:49:49 -0700

Hi Scott, Bill,

>> locator changes with my attachment at the layer boundary.

Disagree.  It's only one point on the topology.  And it's not 
necessarily the network layer.  And there's not even necessarily one 
'network' layer even.

>> on the 1.2.3.4 address. But there's no layer change.

That depends entirely on whether you have one namespace or two.  Note 
that you can do either.  If it truly is a loose source route, then you 
have a single namespace.  One test is whether or not you can send data 
directly to 1.2.3.4.  If so, then it is also within your layer.

If, instead, 1.2.3.4 is at another layer, then it's another namespace 
entirely.

If we take this back to LISP, the implication here is that RLOCs and 
EIDs are two entirely separate namespaces.  Each of them is arguably an 
address.

> match for the way the rest of the I* is using "locator"?  

I don't think that's the real question.  Our job isn't to articulate 
common usage; it's to define what the terminology should be.

I've got a real problem with including #3 because that can be just about 
anything.  You want to forward based on port numbers?  No problem.  You 
want to forward on ToS bits?  Doable.  In that context _EVERYTHING_ is a 
locator.  Some of this is even shipping code.  (Cisco PBR, my apologies) 
  As such, this is a pretty useless definition.  Every field in a packet 
and every bit anywhere on the network qualifies.

I'm not seeing any distinction between #1 and #2 either.  Both are 
effectively points in the topology.  Differentiating between 
destinations and waypoints seems to me to be more about the forwarding 
mechanism than about the namespace itself.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 03 Apr 2009 22:09:54 -0700

Hi Dow,

> perspective of the host) can ever be considered a locator, right?

I think we're aligned, but there are some nits that happen here because 
the IP address again this overloaded use of both locator and identifier.

To demonstrate a nit: what's the network part of the IPv4 address?  I 
have a prefix 192.168.1/24 that points to a particular Ethernet.  I also 
have a host 192.168.1.100 that is NOT on that Ethernet.  I establish 
host routes everywhere I need access to this host.  I'd claim that 
192.168.1.100/32 is both a locator and identifier.

Such is the way of semantic confusion.

> can call a locator also differs at various points in the topology.

Similarly, I'd make the slightly different distinction that you simply 
can't say what part of an IPv4 address is a locator without full 
information about the particular point of attachment.  Note that 
whatever bits are relevant to the locator do NOT change over time or the 
point where they are examined.  The fact that the observer has 
incomplete and insufficient information doesn't change the real 
semantics of the bits.

Note that this is more clear in other proposals (e.g., GSE) where the 
locator is a fixed number of bits.

> (a) on an ethernet segment (that maps to only a single prefix in the IP 
> routing system), only the network part of the IP address of connected 
> hosts is considered to be a (L3?) locator, then
> (b) a similar property exists closer to the "middle" of the 
> topology/routing system if aggregation is used.
> 
> topologically flat from the perspective of processes that are only aware 
> of the less-specific, aggregate mask.

Thus, I disagree with this, as with the above.  Aggregation in the 
routing system is (and should always be) independent of the semantics of 
the namespace.  I think we want to be very careful here, because we 
don't want to define a locator namespace and accidentally have prefixes 
ending up in packet headers.

> I think maybe you are accounting for all of this relative-ness with the 
> phrase "attachment point at that layer"?

Some, but not as much as you're thinking.  I'm really trying to use the 
simplest definition of PoA, such that you have to transition to another 
layer to make forwarding progress.

Tony

---

From: Dow Street <[email-masked]>
Date: Sat, 4 Apr 2009 00:30:48 -0700

On Apr 3, 2009, at 10:09 PM, Tony Li wrote:

>
> Hi Dow,
>
>> I am ok defining things this way.  To ensure we're on the same  
>> page, this means that only the network part of an IP address (from  
>> the perspective of the host) can ever be considered a locator, right?
>
>
> I think we're aligned, but there are some nits that happen here  
> because the IP address again this overloaded use of both locator and  
> identifier.
>
> To demonstrate a nit: what's the network part of the IPv4 address?   
> I have a prefix 192.168.1/24 that points to a particular Ethernet.   
> I also have a host 192.168.1.100 that is NOT on that Ethernet.  I  
> establish host routes everywhere I need access to this host.  I'd  
> claim that 192.168.1.100/32 is both a locator and identifier.
>

Agree (I think).  I would claim that all 24 bits of 192.168.1.100  
could be considered to contain location information, but other hosts  
attached on the 192.168.1/24 segment would only have 24 "locator  
bits".  However, I think this means that it is the combination of the  
(physical) point of attachment, and how that point is described in the  
routing system, that fully define location.

If the topology were a perfect binary tree, and nodes were addressed  
in a manner that perfectly matched this tree, then you wouldn't need  
additional information in the routing system.  Since the topology is  
not a tree, the address semantics (even in the best case of address  
allocation) can only approximately describe topological location - it  
takes the information in the routing system to complete the mapping of  
address to topology.

>> points in the topology differs, then the part of the IP address  
>> that we can call a locator also differs at various points in the  
>> topology.
>
>
> Similarly, I'd make the slightly different distinction that you  
> simply can't say what part of an IPv4 address is a locator without  
> full information about the particular point of attachment.  Note  
> that whatever bits are relevant to the locator do NOT change over  
> time or the point where they are examined.  The fact that the  
> observer has incomplete and insufficient information doesn't change  
> the real semantics of the bits.

I am ok with this, but would you then say that the semantics of LPM  
are an integral part of encoding location information in the IP  
address?  (and subsequently, IP addresses were not locators prior to  
CIDR?)

>
> Note that this is more clear in other proposals (e.g., GSE) where  
> the locator is a fixed number of bits.
>
>
>> (a) on an ethernet segment (that maps to only a single prefix in  
>> the IP routing system), only the network part of the IP address of  
> routing system is (and should always be) independent of the  
> semantics of the namespace.

I think I agree from a definition perspective - that is - we can make  
use of proximity semantics in the address space even if there is no  
aggregation in the routing system.  However, from an engineering  
perspective, the only reason to employ such semantics in the address  
is if you plan to aggregate (somewhere/somehow), right?

R,
Dow

---

From: Tony Li <[email-masked]>
Date: Sat, 04 Apr 2009 01:15:52 -0700

> I am ok with this, but would you then say that the semantics of LPM are 
> an integral part of encoding location information in the IP address?  
> (and subsequently, IP addresses were not locators prior to CIDR?)

Well, strictly speaking, LPM predates CIDR.  Yes, for an IP address LPM 
(and the full routing table) is definitely part of what encodes location.

> perspective, the only reason to employ such semantics in the address is 
> if you plan to aggregate (somewhere/somehow), right?

The clear purpose of hierarchy is to achieve scalability through 
abstraction.

Tony