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

Re: I-D ACTION:draft-ietf-shim6-proto-00.txt

Erik Nordmark wrote:

Brian E Carpenter wrote:


      As a result of this exchange, both A and B will know a list of
      locators for each other.




I would add that if the exchange fails, the initiator will then know
that the other end does not support shim6, and will revert to
standard unicast behaviour for the session.



I'll add that.


Thanks




   o  At some point in time something fails.  Depending on the approach
      to reachability detection, there might be some advise from the
      ULP, or the shim (un)reachability detection might discover that
      there is a problem.




There's an alternative that I think should be noted:

    Alternatively, a Traffic Engineering function requests a change
    in locator(s). This can be treated much like a failure condition.
I'm not sure we have consensus to do that in the base protocol, as opposed to some extensions beyond the base. But we should at least be able to tell the peer "this locator is dead" which the introduction didn't mention. So I'll add something like this:
<t>In addition to failures detected based on end-to-end observations, one endpoint 
might be know for certain that one or more of its locators is not working.
For instance, the network interface might have failed or gone down (at layer 2), 
or an IPv6 address might have become invalid. In such cases the host can
signal its peer that this address is no longer recommended to try. Thus this triggers something similar to a failure handling in that a new, working locator 
pair must be found.</t>
  <vspace blankLines='1' />
  <t>The Working Group has discussed whether or not hosts can express other
forms of locator preferences. If this is the case, a change in the preferences can be signaled to the peer, which might make the peer choose to try a different 
locator pair. Thus, this can also be treated similarely to a failure.</t>


Perfect.




4.1  Context Tags and Use of Flow Label



...


   o  When the context is created, each endpoint picks an unused context
      tag based on the constraints above, which is also not used as a
      flow label for the set of locators.




Now here I have a problem, which is related to a long discussion
between Erik and me some months ago.
The Interim Meeting in Amsterdam has a recommendation in this area that will simply our lives (including that of the document editor). That is to not use the flow label or overloading of the protocol type values (for "foo over shim6"). 

I support this. I think it's the best solution. I believe we've
established that the flow label approach was in the best case very
hard to get right and quite complex.
Instead, after a failure (when locator pair is not the ULID pair), the ULP packets will have an 8 byte shim6 extension header.
The folks at the Interim Meeting believe that we can later remove this, by adding some additional end-to-end signaling (basically, the hosts can agree that certain packets can avoid this header) and that this doesn't need to use the flow label either. But details are for further study. Of course, this and other design decisions need to be verified with the shim6 mailing list. 

Consider this node on the mailing list to agree with the interim meeting's
decision. Sorry I couldn't be there, by the way.

    Brian