Re: architecture draft

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



>   "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".

I think that "should attempt" covers that concern.

>   "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.

I can't think of a scenario where the same would not be true, even if 
this was not a requirement. You need the src address to map to the 
communication stream in one way or the other. Unless I am to tried.

>   "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?

I would agree that there is a difference. It will affect what ULP(s) 
you will have to adopt, and in what way.

>         "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.

But then you have inserted an adoption layer. Does that really buys us 
anything?

> 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.

Security was decided to be covered in "some other way". Which we assume 
will be in one or more drafts. But yes, that is also one of the 
deliverables.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQJevg6arNKXTPFCVEQKKtwCfae5OdE8XCHRHaUWCRDjqA9YMup8An1rn
popj3+91PuKifz1l8K+NbQtH
=IUpW
-----END PGP SIGNATURE-----