about draft-ietf-shim6-arch-00.txt

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi,

I know this draft is waiting for the solution to be more mature, but i 
would like to make some comments about some issues that may be 
interesting to address in later versions of this draft

Section 2.  Summary of Shim6

it is stated that

   The intention of this approach is to minimise the amount of change
   required to support dynamic locator agility in the protocol stack,
   and support dynamic locator agility as a negotiated endpoint-to-
   endpoint capability.  An application can initiate a session with a
   remote host by using an entirely conventional lookup of the host's
   domain name in the DNS, and open up a session with the remote
   endpoint using one of its addresses as the destination address.  The
   application can continue to exchange packets with this remote host
   for the duration of the session by continuing to use this destination
   address.  If the local host subsequently opens up a new session with
   the same remote host, the same destination address may be used, or if
   the local host passes a reference to a third party as a referral, the
   same destination address may be used.  In terms of semantics and
   functionality this represented no change to the use of addresses as
   endpoint identifiers in the IPv6 architecture.

I think that after this paragraph and before the next one, it should be 
stated somehow that the shim association is established using some form 
of signaling handshake.
I mean, in this paragraph it is stated that the communication is 
established as a regular IP communication and in the next paragraph it 
is described bow the shim processes the packets, changing the 
identifiers per locators and the other way round. I think that it would 
be clarifying to state that at some point in time, some heuristics 
(TBD) trigger the establishment of the shim association, so that the 
ongoing application session can benefit from the multihoming 
capabilities. This results in the shim handshake performance and the 
creation in each of the endpoints of the necessary shim state and so 
on.

The next paragraph states that:

   Shim6 operates as a per-host header address mapping function.

I am not sure what do you mean by per-host here...
I think that one of the issues along the document is that a per 
host-pair granularity of the shim state is assumed. I think this is not 
so, and that the shim state granularity would be per ULID-pair. IMHO 
this is a consequence of the design choice that any address can be used 
as ULID. Because of that, any application can select any of the 
available addresses to be used as ULIDs for a communication. This 
results that two communications between the same pair of endpoints can 
use different ULIDs and this would imply having two different shim 
associations and their respective shim state. The difficulty with this 
point is even more clear at the last section, so i will comment more on 
this later.

Then the paragraph continues with

   When
   the Shim6 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.

The locator pair is not enough imho and a demux tag is needed

   The packet header is rewritten with the mapped
   endpoint identifier pair is there is an active mapping entry.  This
   functionality is indicated in Figure 2.  Here the endpoint identities
   are referred to as Upper Layer Identifiers (ULIDs), and the packet
   header addresses are referred to as Locators (L).  The Shim6 element
   contains a context state, associating a ULID pair (in this case the
   pair [ULID(A),ULID(B)]

and a context tag i guess

   with a set of locators for A and a set of
   locators for B. The shim elements are synchronised such that

then in section 4.  Functional Decomposition

4.1  Establishing Session State

...
         In
         this case the selected source address, as seen by the upper
         level protocol stack element is the ULID of the stored state
         associated with the destination ULID.  Otherwise the selected
         source address is a selected IP address from the set of
         addresses associated with the particular host interface that
         will be used to send the packet, as happens in a conventional
         IPv6 protocol stack.

I would add "following the rules defined in RFC 3484"

Later on...

         The local host to performs a name-to-address
         DNS lookup to obtain a set of locators (recorded in the DNS
         using AAAA resource records).  The host then performs a
         selection from this set of locators

I would add "following the rules defined in RFC 3484"

         and uses the selected
         address as the identification of the remote host.

later on...

      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?  If so, then is
      this translation performed before or after the initial session
      packet exchange handshake?


This is an interesting question...
I think that the demux tag or context tag would serve as a name for the 
association... depending on whether the the context tag is unique or is 
unique within those two ULIDs or two nodes, it maybe part of a name for 
the session.
I mean, if the demux tag is unique, imho this is a name for the 
session, while if what is unique is the ULIDs, context tag, then it is 
part of the name of the session. In any case, imho the context tag 
plays a role in here.

later on...

         The session initiator determines the ability of the remote end
         to support the Shim6 protocol via explicit negotiation.  The
         Shim6 protocol will continue to operate in a conventional mode
         if the capability negotiation fails for Shim6 support.  The
         nature of the communication exchange to determine the
         capability to use Shim6 support is not described in [ID.SHIM6].

this is described to some detail in the ID.FUNC reference.

then...

         The initial choice of source and destination locators matches
         the initial choice of upper level identifiers, namely the
         initial addresses used as the upper level identifiers.  The
         remote address is obtained using conventional DNS lookup.

I would state that the DNS returns a list of locators and the node 
selects one of them using RFC3484 (i mean, since in the following 
phrase it is specified that RFC3484 is used for selecting the source 
address, i guess this should be here too)

         The
         local address is based on an address selection from the
         addresses associated with the outbound interface, using the
         procedure described in [RFC3484].

Then In section 4.2...

      The Shim6 documentation covers a number of options, but does not
      provide definitive answers to this question.  The [ID.FAIL] notes
      four approaches: namely positive feedback from the upper level
      sessions,

i would say "lack of positive feedback from the upper level sessions"

      negative feedback from the upper level sessions,
      explicit reachability tests

i would say "failure of explicit reachability tests"

      and ICMP error messages.
      From the discussion in this draft it appears that negative
      feedback from upper layer transport sessions in the form of ACK
      timeouts is the preferred locator change trigger mechanism.

funny how things change, but my current understanding is that people 
would prefer lack of positive feedback, rather than negative feedback 
(i guess this is why the completion of this doc should be left for when 
the work is almost finnish i guess :-)

Later on...

   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 Shim6 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 think that this changes with different failure detection mechanisms. 
I mean with FBD, the direction that failed is determined by the nature 
of the mechanism (i.e. the failure is always in the incoming direction 
of the node that detects the failure)
An issue that i think that is relevant and it is related to this is the 
relationship between which endpoint detects the failure and which 
endpoint has to do something to repair it. I mean, in FBD, a node 
detects a failure in its incoming path, so the one that needs to do 
something to repair it is the peer. So, in this case, we need in 
addition, a reliable mechanism to communicate the existence of a 
failure from the peer that has detected the failure to the peer that 
can do something to repair it.

Later on in section 4.3...

   Must a change of an egress site exit router be accompanied by a
   change in source and / or destination locators?

      This appears to be an area for further study.  The situation is
      not explicitly addressed in the Shim6 documentation.

I think that while this is an area for further study, as mentioned 
here, it is clear that for now, the design of the shim assumes that a 
change in the locator pair used implies a change in parts of the path 
used, so that changing the locator pair may result in using an 
alternative working path.
I think that it is good to note that this assumption relies in very 
different mechanisms for the source and the destination addresses. For 
destination address, this assumption is based on the usage of PA 
addresses, so changing the destination address would result in changing 
the ingress ISP to the destination. In the case of the source address, 
this assumption is based in that the ingress filtering compatibility 
must be provided somehow, which implies that a packet with a source 
address of a given ISP will be forwarded through that ISP (to guarantee 
ingress filtering compatibility), so that changing the source address 
results in changing the exit isp.
So, i agree that the actual mechanisms are not defined yet, but i would 
say that the shim is assuming that some mechanisms will be i place to 
make sure that changing the src/dst address would result in different 
exit/ingress paths


Later on in section 4.4...

      The preconditions necessary is that there has been a successful
      establishment of packets between the two hosts, Shim6 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.  IN
      addition reception of a packet where the locator par is a member
      of the locator set for this host pair implies a remotely-triggered
      locator change.

I am not sure this so straight forward. I mean, how would this 
behaviour affect the case of unidirectional path availability. I mean, 
consider the case where only two different unidirectional paths are 
available (so that packets in one direction must carry different 
locators that packets in the other direction). If this behaviour is 
used, then this communication would fail, since peers would always be 
changing of locator pair, upon the reception of a packet from the other 
end having a different locator pair

Then...

   How can the locator change be confirmed by both ends?

I think i don't understand this question...

      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.

But the reachability exchange is not used to confirm that both nodes 
can use a give locator pair, but to confirm that packets sent by one 
peer are received by the other. I mean, we are considering the 
possibility that the different endpoints use different locator pairs in 
the different directions of the communication... but perhaps i am 
missing something

In Section 5.

   It may also be useful to allow the upper level protocol to explicitly
   indicate that any form of L3 functionality should not be applied to
   this session.  The implication of this functionality is that incoming
   packets need to provide some form of positive indication that the
   incoming locator pair should be mapped to an equivalent ULID pair,
   while packets without this indication should be processed in a
   conventional fashion with any Shim6 packet header mapping.  The Shim6
   documentation suggests that some form of explicit tagging should be
   performed in the IPv6 Flow Id field, but further details have not
   been provided.

I think that there are, at least, three different issues addressed here:
- first we have the context tag issue i.e. the need for a context tag 
that allows to demux shim packets having the same locators but 
belonging to different shim contexts
- second we have "the shim bit" which is a bit to differentiate shim 
data packets from non-shim data packets. this is not clear that is 
needed (my understanding is that this is basically needed when we want 
to be able to detect context loss). The possibility for this is to use  
a virtual bit defining new extension headers values
- third, the need to have some packets or some communications not to 
use the shim or parts of the shim. For this, i think that, if we want 
that two apps use the same address pair and one uses the shim and the 
other don't, then we may need the shim bit...

But in any case, i think that these are three different issues that may 
be good to explicitly differentiate.

Later on...

   The potential use of unreachable ULIDs as the initial choice of ULIDs
   and the consequent requirement to undertake a reachable locator
   search, capability negotiation and establishment of a Shim6 mapping
   state is mentioned in the Shim6 documents, but at a relatively
   abstract level.  This requires further consideration in terms of the
   potential failures, and the appropriate signalling to be passed back
   to the ULP in such cases.

I think that an issue that is somehow related with this and that it may 
be interesting to discuss, is what happens when the initial address 
that is supposed to be used as ULID and as locator for initial packets 
is unreachable. We have so far discussed two possibilities for dealing 
with this: let the application retry, or let the shim deal with this 
(this last thing is what would be needed if we want to support ULAs as 
ULIDs)

later on...

   The issue of ambiguity of demultiplexing may require further
   consideration.  If there are multiple AAAA resource records in the
   DNS, or the resource records change over the lifetime of active
   communication, it is possible to have multiple Shim6 states set up
   for the same remote host, with distinct ULIDs for the remote host.

Well, as i understand this can happen for other reasons than changes in 
the DNS records. As i mentioned earlier, imho this can happen simply 
because the different apps running between two nodes choose different 
address pairs as ULIDs for a given communication. In this case, we 
would end up having multiple shim sessions between the same two hosts, 
each one with different ULIDs pairs.
The underlying point here imho is that the shim session granularity 
would be per ULID pair rather than per host pair.


   An incoming packet with a given locator pair will, according to the
   Shim6 documentation, need to use the locator pair as a lookup key

I guess that the locator pair is not enough in this scenario to work as 
a key. I guess that the context tag is also needed in this.

   into the Shim6 state information to establish the associated ULID
   pair.  In the case of multiple active ULIDs for the same remote host
   this lookup will result in multiple ULIDs.

   The treatment of trigger conditions for locator change also requires
   further consideration.  As noted in [ID.ARCH], different upper level
   transports may have different sensitivity requirements to locator
   triggers.  When the mapping is performed on a host-by-host basis

Imho mapping would be in a ULID pair basis, rather than in host basis. 
This won't solve this particular issue, but anyway...

In addition, perhaps a comment about possible ways for detecting the 
loss of shim state by one of the peers may be relevant here....


Editorial

Section: Notes

   The document provides am architectural description of the
   approach, using the framework described in the multi-homing
   architecture document.

s/am/an

Section 2.  Summary of Shim6

   The shim layer provider a set of associations
   between endpoint identity pairs and locator sets.

s/provider/provides

Section 2.

   The packet header is rewritten with the mapped
   endpoint identifier pair is there is an active mapping entry.
                            ^^
s/is/if

Section 2.

   At this level of the protocol stack there is no information to
   indicate wither this packet is a single datagram, or the start of an
   extended packet exchange with a remote entity.

s/wither/whether

Section 4.4.

   IN addition reception of a packet where the locator par is a member

s/IN/In

Section 5

   The signalling interface between the Shim6 and the upper layers pf
   the protocol stack requires further consideration.

s/pf/of

References

   [ID.FAIL]  Arkko, J., "", Work in progress: Internet
              Drafts draft-arkko-multi6dt-failure-detection-00.txt,
              January 2005.

The tittle is missing

Regards, marcelo