about draft-huston-l3shim-arch-00.txt

[marcelo bagnulo braun <[e-mail]>]

Hi,
I guess that this draft will be completed later, but in any case here 
there are some comments about this initial version.

In section 2.  Summary of L3Shim
it is stated that:

          The Layer 3 shim operates as a per-host header address mapping
          function.  When the shim locator mapping function is activated
          for a remote endpoint packets passed from the IP endpoint
          sub-layer to the shim sub-layer have the packet's headers
          source and destination addresses rewritten with the currently
          selected locator pair.  Incoming packets passed from the IP
          Routing sub-layer undergo a similar lookup using the locator
          pair.

Incoming packets probably will need to use a context tag in order to 
properly do the demultiplexing. Perhaps it would be good to mention it 
here.

later on in the same section it is stated that:

          Assuming that the initial choice of a ULID corresponds to a
          viable network path, the initial state of the L3Shim is a null
          mapping, as the ULID is also a viable locator.  The use of
          alternate locators by the L3Shim is a triggered response, based
          on a network path unreachability signal.

I guess that between these two states there is an intermediate step 
that is the creation of the context. such event is not triggered by the 
outage, but probably needs to be performed earlier. Moreover, the 
exchange of alternative locators needs to be done before the outage, in 
order to be able to recover from any type of outage. So i would suggest 
to mention something about the context state creation between the two 
sentences above.

In section  4.  Functional Decomposition subsection 4.1  Establishing 
Session State it is stated that:

             Does the identity protocol element need to create a mapping
             from the upper level protocol's local and remote identity
             tokens into an identity token that identifies the session?

W.r.t. this first question, i think that the context tag for 
identifying which packets need to be demultiplexed is as it name states 
a context identifier which imho is similar to a session identifier. So 
i guess that a session identifier is needed sometimes i.e. when al 
alternative locator is used.

             If so, then is this translation performed before or after
             the initial session packet exchange handshake?

I am not sure i understand this question as it is stated... what is the 
initial session packet exchange handshake? is this the data packet 
exchange or is this reffering to the multi6/shim signaling handshake? 
 From the answer i guess is the last one but the question is not clear 
to me.

Later on, it is stated that:

                The nature of the
                communication exchange to determine the capability to use
                L3Shim support is not described in [ID.L3SHIM].

agree but some text about this was provided by Jari in

                     [ID.FUNC]  , M. and J. , "Functional Decomposition 
of the M6
                     protocol", Work in progress: Internet Drafts
                     draft-ietf-multi6-functional-dec-00.txt, 2005.

Next, it is stated that:

             How do the endpoints discover the locator set available for
             each other endpoint (locator discovery)?
                The mechanism is by explicit exchange of locator sets
                between the hosts.  The L3Shim description does not
                describe the precise mechanism.

some description about this is also contained in:

         [ID.FUNC]  , M. and J. , "Functional Decomposition of the M6
                     protocol", Work in progress: Internet Drafts
                     draft-ietf-multi6-functional-dec-00.txt, 2005.

Later on in subsection 4.2  Rehoming Triggers it is stated that:

          What triggers can be used to indicate the direction of the
          failed path in order to trigger the appropriate locator repair
          function?

             The [ID.FAIL] description does not provide a description of
             detection of the failed path.  The L3Shim approach attempts
             to treat path failure as a failure of the locator pair,
             rather than failure of a single locator, so the direction of
             the failure is not necessarily critical information in the
             search for a new functional pair.

I am not sure that i understand this part properly, but in section 5.4  
Protocol for Testing Unidirectional Reachability
  of draft-ietf-multi6-failure-detection-00 there is description of a 
failure detection protocol that supports unidirectional paths. So, i 
guess that there is mechanisms to detect which direction is broken, but 
i am not sure this is what you had in mind here....

In section      4.3  Rehoming Locator Pair Selection it is stated that:

             Selection of a specific locator
             pair is based on the successful outcome of a return
             reachability test between the two endpoints.

This is true for destiantion locators but not for the local locator, i 
mean the question being asked is:
         What parameters are used to determine the selection of a
          locator to use to reference the local endpoint?
So i guess this doesn't applies here but it does applies to the next 
question which is:

          If the remote endpoint is multi-homed, what parameters are used
          to determine the selection of a locator to use to reference the
          remote endpoint?

In section 4.4  Locator Change it is stated that:

          What are the preconditions that are necessary for a locator
          change?

             The preconditions necessary is that there has been a
             successful establishment of packets between the two hosts,
             L3Shim capabilities have been successfully negotiated and
             locator sets have been exchanged, and there is an explicit
             trigger for a locator change that has been generated by an
             active transport session.

I think this is not the case
I mean we had some discussions about whether to support the initial 
locator failure as a part of the shim protocol or simply let the 
endpoints to retry using alternative ULID/locators. The point is that 
if this is part of the shim protocol, then apps life will probably be 
easier,and some folks thought that this was a good approach. this means 
that there will be a change of locators without even exchanging 
packets.
A particular case of this situations is the usage of ULAs as ULIDs. 
becuase ULAs are by definition unreachables, so this means that when 
they are used for initaitng the session, this can be seen as a locator 
change

then it is stated that:

          How can the locator change be confirmed by both ends?

             The approach proposed here is by using a return reachability
             test, where a host searches through locator pair selections
             until it receives an explicit acknowledgement of a poll.

This is true for destiantion locators but it is not the case for source 
locators i think. I mean the reachability test is to prevent flooding, 
so a node cannot send traffic to a locator until he is certain that the 
target is willing to receive traffic. However, a node is able to use 
any source locator he wants without performing a reachability test. 
OTOH, it seems reasonable that a node will check if the locator pair is 
reachable before start using it, but this may be optional, and he could 
try using data packets. So, i would say that this is definitely 
mandatory for destiantion locators and optional for source locators.

In subsection       4.5  Removal of Session State

          How is identity / locator binding state removal synchronised
          with session closure?

             As this is a layer 3 function there is no explicit concept
             of sessions.  A L3 Shim mapping state needs to be maintained
             for as long as there is packet activity in either direction.
             The removal of state would most likely be associated with a
             removal eligibility condition associated with a packet
             activity timeout, and an eligible state removal pass being
             undertaken by the L3 Shim statement management module.

Well,  draft-ietf-multi6-functional-dec-00 considers two approaches, 
the coordinated and he uncoordinated. The one that you are describing 
is the uncoordinated, as i understand it, right? I think that there is 
still not a clear choice w.r.t. to this point.

Regards, marcelo