[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: architecture draft

At 11:42 PM 4/05/2004, Iljitsch van Beijnum wrote:
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.

good point - I'll add words


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

Unless someone objects to this word change I'll agree to this.

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

It was a number larger than any claim I've heard from a vendor to date,
and it was a power of 10. (I've heard numbers of the scale of 10**6, not
verified of course)



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

well, in the figure 1 model the remote host is not multi-homed, but would need to
be multi-home "aware", and I believe the "by default" comment is correct.

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

In this case the description of the practice and the use of a reference
to an approach to doing this I though was the most concise way of describing
the practice.



  "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 believe so. As I said at the Seoul meeting a "new" protocol stack element
implies a distinct synchronization across to its peer. I know that there was some
discussion in the WG on this, but I did not sense that this proposition was
not accepted by the workling group.


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


I think we are talking at cross purposes.  The words are intended to say that
you should signal a new locator to the other end if you want the other end
to recognise the locator packet as part of an active session. That does not
mean you have to sync locators at transport startup, but it does say "signal
intentions before use".




In this list:

   o  Transport Layer Triggers
   o  Routing Triggers
   o  Heartbeat Triggers

I'm missing ICMP triggers.

so I'll add these triggers to the list - thanks.

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

perhaps you could suggest some alternative words here?


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


agreed - again are there some general words you can propose to help me here?



* the implications of keeping the current socket API or ditching it


I'll propose that this is out of scope to this draft, being tactical rather than architectural,
and such issues should be in Eliot's draft, but if you believe that this is useful in this
architectural-oriented document some further explanation as to why would be
helpful.


* the application of MIPv6 mechanisms or MIPv6 lessons for multi6

hmmm - this was discussed at the meeting in Seoul, but the impression I gained from the
conversation was that the lesson was a case of maybe the MIPv6 approach was not
directly applicable. But again if you have wrds to propose here I would appreciate
your assistance.


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.


I agree with you - and indeed think that its just so critical that it needs its own document
in its own right to explore the space and do it justice. That's the pointer in the draft in the
Security Considerations section.

thanks for your careful review, and please consider the invitations to contribute
some further words to the document as noted- I'd appreciate your assistance, of course.

regards,

Geoff