[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: review of draft-ietf-shim6-proto-03.txt, sections 1-2
Thanks for your comments. I've used them to try to make things more clear in the document. See below regarding my question about renumbering ULIDs and whether we should add some requirement to the document for that. 

Jari Arkko wrote:


Technical:


However, it
  might turn out that the shim6 protocol can be a useful component,
  e.g., for route optimization in the context of host mobility.


Not sure why the usefulness would have to be limited
to route optimization.
As I read it, the text doesn't limit where it might be useful - it just gives a concrete example.
I don't have an example where shim6 might help outside of route optimization, since the HA-type interaction for tunnel management is likely to have slightly different requirements. But the intent isn't that the text limit its possible application for mobility. 


Maybe "... can be a useful component in the context of
host mobility". Or don't say anything.


How about:
   This proposal does not attempt
   to solve the, perhaps related, problem of host mobility.  However, it
   might turn out that the shim6 protocol can be a useful component for
   future host mobility solutions, e.g., for route optimization.


  This potential source for confusion can be avoided if we require that
  any communication using a ULID must be terminated when the ULID
  becomes invalid (due to the underlying prefix becoming invalid).  If
  that behavior is desired, it can be accomplished by explicitly
  discarding the shim state when the ULID becomes invalid.  The context
  recovery mechanism will then make the peer aware that the context is
  gone, and that the ULID is no longer present at the same locator(s).

Invalid... or if you move away from the link on which you had
the ULID? The HBA draft does allow dynamic case, so it seems
that this can happen.
There is a tradeoff between the robustness of the communication when there are failures, and how the protocol reacts to ULIDs "disappearing". (Note that the text in 03 doesn't clearly say that when the locator becomes invalid it isn't a problem; 04 will make this more clear.) 

A couple of cases to consider:
1. The host remains attached to one or more interfaces, and the Router Advertisement messages (or DHCPv6, if it is used for address autoconfiguration), explicitly indicate that the prefix is now invalid.
2. The host looses its connectivity on one interface (e.g., it walked out of range of the 802.11 access point) but retains connectivity on some other interface (e.g, the GPRS interface). This means that the host wouldn't notice a sudden decrease in the valid lifetime on the 802.11 interface (it can't receive any RAs). But it the host kills communication that uses the 802.11 prefix in the ULID then we are likely to loose the shim6 robustness benefits for host multihoming.
3. Like in case #2, but while the host is detached from the 802.11 link, the valid prefix lifetime (which is 30 days by default in RFC 2461), expires.
Thus in case #1 and #3 it might make sense to force communication that uses the now invalid ULID to fail. But in #2 I think we should retain it until the prefix valid lifetime expires.
It might be that most of these tradeoffs appear when we have host multihoming, because for site multihoming one would expect the prefix advertisements to be more "consistent"; the multiple prefixes are likely to be advertised by the same routers in the same router advertisement messages (i.e., we'd have only case #1 to worry about for site multihoming.) 

So should we make a stronger recommendation in this space?


Editorial:

Introduction: I'd prefer writing this in a style that focuses
less on what the history with the WGs and approaches
was, and more on the what the protocol does. Same for
the abstract, e.g., s/The SHIM6 working group is specifying
a layer 3 shim approach/The SHIM6 protocol is a layer 3 shim/
Yep. We got that comment from Geoff as well, but I'd missed fixing the abstract. 


  15.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . .   81
  19.   Possible Protocol Extensions . . . . . . . . . . . . . . .   88

These should probably go to an appendix.


ok


  identifiers to locators, such a name space isn't necessary (and
  furthermore doesn't seem to help) to solve the multihoming problem.

I thought "is not" is better style than "isn't" (and same for
"doesn't"), but I'm this is not my native language...
Neither is it mine. But as I understand it, "isn't" is the more normal form, and "is not" can be used for emphasis. 


  and Provide Independent IP addresses.


s/Provide/Provider/


The format allows adding additional notions of
  "metrics" over time.  But this is merely a place holder; even in
  order to use this there would have to be a mechanism by which the
  host can find out what preference values to use, either statically
  (e.g., some new DHCPv6 option) or dynamically.


Is the latter part talking about the preferences in general
or just the additional notions of metrics? For the former,
even if the protocol is fully defined now, one still has to
find out the preferences locally. For the latter, presumably
the receiver just ignores the unknown metrics, if any.
In general. I'll change the text to "But the Locator Preference option is merely a place holder when it comes to providing traffic engineering, ...".
For the latter, the format might be suboptimal, since we are not requiring that the first 3 bytes of each element be understood by implementations confirming to what's in this document. Thus I think we should add this in section 5.14.3 specifying the Locator Preference option format: 
<t>This document doesn't specify the format when the Element length is more
than three, except that any such formats MUST be defined so that the first
three octets are the same as in the above case, that is,
a of a 1 octet flags field followed by a 1 octet priority field,
and a 1 octet weight field.</t>


  Context tag         Each end of the context allocates a context tag


Capitalized or not? Some of the other terms are not, and here we have
inconsistent capitalization.
The intent was to have lower case "context tag" refer to the general concept, and have capitalized names like "Initiator Context Tag" to refer to the specific instances when naming a field in a packet or option. 


  Forked Instance Identifier (FII) In order to handle context forking,


add <vspace blankLines='1'/>


ok. s/1/0/ to be consistent with the other long terms.

   Erik