Hi Scott, Bill,
On Fri, Apr 3, 2009 at 11:21 AM, Scott Brim <[email protected]>
wrote:
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.
Your version sets the scope at the network layer boundary. The
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.
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.
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.
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"?
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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
