On 1/26/2015 8:04 AM, Dearlove, Christopher (UK) wrote:
Joe Touch
On 1/26/2015 5:33 AM, Dearlove, Christopher (UK) wrote:
Joe Touch
Regarding anthropomorphisms to avoid, they include: detect
reaches hears
The term you should be using is "can transfer an IP datagram
to".
Not the same. If A can hear/detect B, that does not tell you that
you can transfer an IP datagram to. Opposite directions.
OK, to be more precise, "can receive an IP datagram from"
Even that may be saying too much, that may be a necessary but not
sufficient condition for routing.
It's a necessary and sufficient condition to define a unidirectional
link capable of being used by IP as L3.
Routing is the transitive closure of unidirectional reachability.
See for exampleNHDP (RFC 6130), which uses one of those terms.
That doc is defining a routing protocol. You're trying to define a
L2 network, AFAICT.
I'm not sure of the context of the latter sentence above, but it is
not so in any context I can see. The whole point of RFC 6130 (and RFC
7181) is to be L2 agnostic, and even able to run over a heterogeneous
collection of L2 links.
Routing protocols that run over IP (as RFC6130 does) are L2 agnostic,
yes. Thus that doc is defining (more specifically) a L3 routing protocol.
In the case of NHDP, "HEARS" is a routing protocol event when an
IP packet is received. See section 10.1.1 which explains that
HELLO messages occur in IP datagraph. Take that description and use
it to understand the meaning of HEARS, LINK, and SYMMETRIC LINK and
you will end up with the definitions I gave - despite the fact
that unidirectional link and bidirectional link are the common
terms for what that document redefines.
I actually understand that RFC quite well.
Note also that, strictly interpreted, NHDP creates a topology that
might never forward data packets. HEARS is defined in terms of
receiving a specific kind of IP datagram, rather than IP datagrams
in general.
Precisely. That's why hears is not the same as can receive an IP
datagram from.
Well, in *that* RFC, if you can't hear an IP datagram, you can't get a
HELLO, so you don't HEAR any endpoints.
Yes, there could be an odd situation where IP HELLO datagrams can
transit a link where other IP datagrams cannot, but in that case RFC6130
would determine forwarding entries that wouldn't do much good.
That RFC does imply that control message reachability implies IP
reachability.
Yes, you could have an L2 where that's not the case - where L2
reachability is determined by a mechanism that doesn't transfer an IP
datagram. But L3 doesn't care HOW that information is obtained; all it
cares about is what is L3-reachable.
IMO, that's not useful. Even though that doc describes a routing
protocol, it could - and should - have used widely-used terms for
it's particulars.
I'm not sure what you are saying is not useful. Assuming you just
mean the terminology, the terms had prior art in the MANET community.
RFC 3626 for a start.
The MANET community didn't create networking; it existed for decades
before they got started. The fact that they redefined well-known terms
from a community with decades of history isn't helpful to either them or
those they're trying to communicate with.
If you want to repeat that mistake, please take your work to the MANET WG.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
