On Fri, 18 Jun 2010, RJ Atkinson wrote:
Quality of implementation matters, for any protocol. I'm glad you
agree with me about that.
Quality of implementation matters, but what is feasible to achieve by
implementation is bounded by the protocol.
First, recall that ILNP session state is generally short-lived
anyway.
Doesn't it have to be at least as long as the session state of ULPs?
Or at least, kept refreshed for that length?
For reasons like multi-homing and mobility, one would imagine that
normal ILNP implementations will have Locator lifetimes that are
quite short -- less than a minute in some cases.
Lost ILNP state will look rather like the situation where a node
moved, and the location update was dropped due to congestion
somewhere along the path. This scenario is already covered in
reasonable detail.
Ok, that's the kind of info I'm after. I know it's obvious to you,
but you could point me toward where in the drafts this is described?
The same conceptual approach can work fine for ILNP. It is
entirely an implementation-specific matter whether that particular
approach is adopted for ILNP.
You've missed my point:
The same approaches that work for TCP today also can work
for ILNP. So TCP is an existence proof that thoughtful
ILNP implementations will be fine.
Unfortunately not all of us are as brilliant at seeing how TCP SYN
state attack mitigation translates to ILNP. Hence it would be useful
to the rest of us slow-thinkers, unable to see the obvious, if this
could be explained explicitly, solely with reference to ILNP. ;)
E.g. it'd be useful in this to see the ILNP state machine described
succintly, in one place, with perhaps a diagramme. (If that already
exists, apologies, I'd appreciate a pointer). Perhaps also a fully
worked example of how the ILNP protocol works.
As an example, imagine a long-lived TCP session (e.g. SSH) from an
ILNP host to a server. Is this how it should work, if the server has
no entry in its cache?:
client Ic server
ICMP Locator Update ->
Lookup(Ic,nonce) == null
Insert(Ic,nonce -> L[])
<TCP/ILNP session establishes>
...
<due to resource concerns
expunges its ILNP session
cache entry for Ic>
<sends TCP/ILNP packet>
<what happens here?>
?
(Now, if you seek to add some specific text someplace, it really
would be simpler procedurally for you to propose adding some
specific text at some specific location in some specific I-D,
than to make me guess what text you are seeking where. My
crystal ball has been broken for years. :-)
I'm still trying to understand the exact details of ILNP, so I don't
think I can make suggestions for changes. Though, it might help
dimwits like me if:
- there was a single document which succintly and precisely described
the protocol (e.g. what's the implication of the "Valid Time" in
the session cache? How/when do entries expire?). E.g. perhaps some
of the more detailed text in the intro doc could be moved out of it
and merged together with the Nonce and Loc. Update drafts.
- there were some worked examples somewhere (if they exist and I
missed them, apologies). This could be useful in the concept/intro
draft.
regards,
--
Paul Jakma [email protected] Key ID: 64A2FF6A
Fortune:
Who goeth a-borrowing goeth a-sorrowing.
-- Thomas Tusser
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
