architecture draft

[Iljitsch van Beijnum <iljitsch@muada.com>]

Hi,

Some comments on the architecture draft.

  "This implies that if a local multi-homed-aware host
   establishes an application session with the remote host using "Path
   a", and this path fails, the application session should be mapped
   across to "Path b" without requiring any application-visible
   re-establishment of the session."

This is only the first multihoming issue. The other is that it should 
be possible to set up new sessions.

  "RFC 3582 [RFC3582] documents some requirements that a multi-homing
   approach should attempt to address."

I think we decided against using the R-word but rather call them 
"goals".

  "Within the constraints of current routing
   and forwarding technologies it is not clearly evident that this
   approach can scale to encompass a population of multi-homed sites of
   the order of 10**7 such sites."

Why this specific number?

  "While the destination address is that of R, what
   source address should the local host use? There are two implications
   for this choice. Firstly the remote host will, by default use this
   source address as the destination address in its response, and hence
   this choice of source address will direct the reverse path from R to
   the local host."

While I agree that doing this sounds reasonable, there is no 
requirement that this should be the case.

  "Secondly, the ISPs A and B may be using reverse
   unicast address filtering on source addresses of packets passed to
   the ISP, as a means of prevention of source address spoofing."

The idea is that ISPs filter. Whether they use uRPF or some other way 
to accomplish the same result isn't all that interesting.

  "As an alternative to insertion of a new protocol stack element into
   the protocol architecture, an alternative approach is to modify an
   existing protocol stack element to include the functionality
   performed by the EIP element. This modification could be undertaken
   within the transport protocol stack element, or within the
   internetworking stack element."

Is there really a difference between having a wedge between the 
transport and network layers and implementing the functionality in the 
"upper part" of the IP protocol?

  "As a part of the EIP function is to transform the ULP PDU to include
   locator information there is an associated requirement to ensure that
   the EIP peering state remains synchronized to the exchange of ULP
   PDUs, so that the remote EIP can correctly recognize the locator to
   endpoint mapping for each active session."

Depending on the meaning of the word "synchronize", I don't agree here. 
This is very different from, say, TCP, where a three way handshake is 
essential to synchronize the state at both ends. There is no reason 
such tight synchronization is needed to provide multihoming 
functionality. If such tight state synchronization is mandated, this 
leads to delays in the actual communication because this can only start 
after the synchronization is done. I don't think this is necessary.

In this list:

   o  Transport Layer Triggers
   o  Routing Triggers
   o  Heartbeat Triggers

I'm missing ICMP triggers.

        "One confusing question about the direction of this work is why
         SCTP is being discussed as a "solution" to site multihoming,
         when a clear requirement for a site multihoming solutions is
         the ability to support existing TCP-based and UDP-based
         applications."

A cool aspect of SCTP is that it can both function in a way very 
similar to TCP and in a way very similar to UDP. It should be possible 
to create an adaption layer so that applications that expect to use TCP 
or UDP are redirected over SCTP.

Some stuff I missed in the draft:

 * multiaddressing by its ver nature means changes at both ends, which
   is far from helpful in gettting things off the ground
 * the implications of keeping the current socket API or ditching it
 * the application of MIPv6 mechanisms or MIPv6 lessons for multi6

Also, security should be considered from the start. We've already seen 
that many things that seem like good ideas can't work securely at all, 
or need so much additional security stuff that the advantages or the 
original approach are largely lost.