Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt

On Thu, 28 Oct 2004, Eliot Lear wrote:
>> 2.3.3 Can your solution be aggregated and implemented site-wide?
>
> This is now in Section 4.1: does your solution change existing aggregation 
> methods?

Oh yes, sorry -- I missed that.

>> 2.3.4 Does your solution impact existing traffic engineering methods
>> 
>> I think these are rather important, even thought the latter is focused on
>> MPLS, when it should be focusing on BGP traffic engineering practices
>> instead.
>
> We had this in there and nobody could understand how a solution could impact 
> traffic engineering methods, other than by changing the aggregation methods. 
> Thus Section 4.1.

Yes, the text was probably focused wrong.

Maybe it should have been something like:

X.Y Does the solution solve traffic engineering requirements?

One of the significant goals of IPv4 multihoming solutions has been to 
be able to perform traffic engineering based on appropriately 
adjusting the BGP advertisements. If the prefixes used by the sites 
would be aggregatable, the sites' ability to perform traffic 
engineering would be diminished.

Does the solution offer ways for site the to manage its traffic flows? 
If so, how?  Is this controllable on a per-host basis, or on a 
per-site basis?


.... i.e., there should be some section which forces the solution 
developer to think, "gee, if the site would no longer be allowed to 
advertise more specific prefixes, or any prefixes that would get into 
the global routing table, how would it fill its traffic engineering 
needs?  Or is this left unsolved? [which seems to be the case now]"

>> 2.  On the wire behavior
>> 
>> 2.1  How will your solution solve the multihoming problem?
>> 
>>     That's why we're here.  Remember, a reference is fine.
>> 
>> ==> this seems almost like asking, in an email context, 'how does your 
>> proposal solve the spam problem?'.  This question is not good, because I 
>> don't think we have sufficiently clearly defined what "the multihoming 
>> problem" really is (and some might even argue it's multiple different 
>> problems), and its unlikely that the solutions can even solve the whole 
>> problem.
>> 
>> This will cause folks to answer, "the solution provides connection
>> survivability, solving the multihoming problem" .. BUT THAT'S NOT
>> THE (WHOLE OF) MULTIHOMING PROBLEM!
>> 
>> It's difficult to say how this should be fixed.  One way might be trying to
>> precisely define what 'the multihoming problem' refers to.  One way would 
>> be
>> rewording the question so that the responder should try to describe which
>> multihoming problem(s) the responder thinks what the solution is solving,
>> and which not.  Reference to a list of multihoming problems would also be
>> OK, but I don't think there is a good document laying these out.
>
> What I am looking for, and perhaps a clarification *is* in order, is a 
> scoping of what problem they think they're trying to solve.  This document 
> doesn't require you to solve every problem, but simply to explain how your 
> solution to the problem you think you're solving will impact the world we 
> live in now.

I agree with that.  The text needs some tuning to make it loud and 
clear that there is not a single big problem to be solved, and the 
responder should articulate which problems he's trying to solve.

>> 2.7  Can multihoming capabilities be negotiated end to end during a
>>      connection?
>> 
>>     If the proposal introduces additional overhead, can the information
>>     be somehow piggybacked on messages that are already used?  This would
>>     be useful in order to keep connection setup constant.  Please also
>>     indicate any drawbacks that might apply due to this piggybacking.
>> 
>> ==> I already proposed the following new section in March:
>> 
>> ===
>> 2.X Can multihoming setup be delayed from session setup?
>> 
>> If the proposal induces overhead (added bytes in packets, or
>> additional packets), is it possible to delay that overhead (or
>> "multihoming set-up") to happen after the session has been
>> established?
>
> This is included above based on your earlier feedback.

Piggybacking can mean multiple things.  This is not sufficient, see 
below.

>> That is, is it possible to specify that multihoming benefits would
>> only be achieved for sessions which last over XX seconds, to optimize
>> away the cost of set-up for short-lived sessions?
>
> And this may be too specific to a mechanism you have in mind.  For instance, 
> perhaps this would be handled by an IP end host option.

You seem to make the assumption that as long as no additional messages 
would be sent, it would be OK.  That's not the case: my proposed text 
was also addressing the situation where you wanted to avoid the extra 
*overhead* and processing at the start of the sessions.  The 
piggybacking text could be read to just refer to being able to bundle 
the messaging right from the start, right?

Trying to say it differently, so that it'll be clear for certain:
  - piggybacking has protocol overhead, which can be undesirable for 
many reasons (and it might not even be possible to completely 
piggyback the packets), requiring e.g., new options, and such packets 
might be dropped in the firewalls

  - if you do piggybacking from the start, you'll waste bytes and 
processing even for short, 1-2 second flows.  That seems like 
something that one might want to do away with.

Delaying the multihoming set-up from the initial signalling would do 
just that, whether it would be piggybacked ont he data packets, or 
sent separately.

Again, it's not clear whether this is a tradeoff to pick, but it 
should be on the list of things to think about :-)

>> 3.12  Are there any implications for scoped addressing?
>> 
>>     Please see RFC 3513 [1].  How does your mechanism interact with
>>     multicast?
>> 
>> ==> what does 'multicast' have to do under 'scoped addressing'.  Granted,
>> multicast addresses have a concept of scope, but maybe this calls for an
>> additional question, 'Are there any implications for multicast', where
>> multicast would include both global and non-globally scoped mcast.
>
> The question is right there.  I attempted to borrow from IPv6 nomenclature. 
> If you believe that nomenclature is failing us here, then we should change 
> it, but we should do so elsewhere as well.

I'm not sure if I understand your comment.  The grouping of the 
questions seems to be odd, because handling (global) multicast has 
probably different things to think about, than handling link-local or 
ULA unicast.  The latter has to do with scoping, the former.. well, 
there are always some problems with multicast which one might not have 
thought of :-)

>> 5.  Name service interactions
>> 
>> ==> you discuss DNS in this section, but AFAICS, these issues could be
>> generic if some other mapping function than DNS would be used.  Maybe this
>> issue could be handled by adding something like:
>> 
>>   This section assumes that DNS might be used for a mapping function.  If
>>   you are using some other method (see Section 3.8), please consider
>>   separately both the impact on DNS, and the impact on your mapping 
>> function
>>   as appropriate.
>
> I don't want to make quite so broad an assumption about the solution space, 
> since we don't quite know which problem people are working on.

That's cool.  But there are a lot of questions about DNS which should 
be asked in closely identical fashion if someone invents his or her 
own discovery service.  What would the best place to require them to 
discuss those issues?  Seems to have significant overlap here..

A possible approach might be generalizing some of the generic DNS 
questions, and keeping some of them which are related to the continued 
well-being of DNS (which might not be a problem if the solution 
invents its own for its own stuff).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings