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

Re: review of draft-ietf-shim6-proto-03.txt, sections 1-2

Hi Jari,

thanks for the feedback, see my inline comments


El 17/02/2006, a las 17:57, Jari Arkko escribió:



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.

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



I guess this is in line with what Geoff was proposing....
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.



not sure if i am following you here....
HBA does not support dynamic changes of the locator set... you mean CGA, which is also supported in the draft?
Assuming you meant CGA, we are in the somehow mobile scenario here, right? But in a mobile scenario, i guess that the ULID would be something like the HoA, right? if so, when a host leaves the home network, this does not means that you want the sessions established with this ULID to be terminated, since basically what is going on is that the ULID is unreachable as a locator (i.e the node cannot longer be reached at this locator)
In other words, in the mobile scenarios, i would say that they are about locators becoming unreachable rather than ulids becoming invalid (which is what i understand this paragraph is about) 


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/
15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 81 19. Possible Protocol Extensions . . . . . . . . . . . . . . . 88 


These should probably go to an appendix.


  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...


  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?


I think both


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.



So far the spec only defines a 1,2 or 3 byte preference for a locator.
How these byte(s) can be used to express preferences is leaved undefined. So, the first thing needed is to define the semantic for these preferences (for each of the 1,2, and 3 byte preference field) and then in each particular site/hosts the values assigned for each prefix.
I guess that the question is whether you think we should define the semantics of the three preference formats in the spec or it would be enough to leave it undefined? It is clear that in order to be useful, both peers need to agree in the semantics of the preference field, but as you mention, a host that receives a preference format that it does not understand, it can just ignore it. 

Regards, marcelo