[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
about draft-huston-l3shim-arch-00.txt
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