Re: [Saad] About forwarding tags

[Dave Crocker <[e-mail]>]

Folks,

>> So in the Internet architecture, IP addresses serve at least these three
>> functions:
>> 
>> 1 - Identify an end-end entity
>> 2 - Describe where its interface(s) is in the network (location)
>> 3 - Serve as a forwarding tag for packets.

PN> I think this is a very important point, and worth pursuing much more.


Normally, this sort of careful distinction sits quite well with me, too.
However in this case, I suspect it is creating a difference that is not as
real as it seems.

Here's my thought:

A reference string must balance between the needs of higher functionality and
lower functionality. (In some cases, the altitude of the functionality is not
a different layer. For example, we have quite a few different things going on
inside IP. For this discussion, I am postulating some sort of internal
hierarchy for them.)

We need to describe how the reference string is used, in relation to those
higher and lower functions.

For example, note the change in perspective for the above list. The first two
entries describe informational roles, while the third describes a functional
role. I think the reason for this disparity is that the _purpose_ of a locator
(#2 on the list) is to serve as a forwarding tag (or, at least, as part of
one.) Take that purpose away and we really do not need locators.

An identifier serves to uniquely distinguish one component from another. The
"higher" functionality for an identifier only needs the uniqueness. The
"lower" functionality needs to be able to map the identifier to another
reference, such as a locator. Any information aggregation (hierarchy) built
into an identifier is typically based on administrative relationships.

A locator enables routing. The "higher" functionality for a locator needs
unique identification. The "lower" functionality for a locator needs to
perform routing. Any information aggregation build into a locator needs to
facilitate routing table efficiencies. Given the nature of routing, this means
that aggregation needs to be based on topology, or something related to
topology. (I'm trying to leave room for geographic addresses.)

The danger in having the list of 3 labels is that it will lead to thinking
that we really do need 3 labels.

We don't.  We need two.

Making specific choices for the two labels requires looking at when, where and
how they need to be used. For example, as NOID notes, it is ok to use a public
key if its computational overhead is used only occasionally. Similarly, a
reference used in every datagram needs to be as short as feasible.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:[phone]>


_______________________________________________
Saad mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/saad