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

Hi Pekka, Elliot,

El 28/10/2004, a las 19:39, Pekka Savola escribió:
> 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?
>

Yes, imho this is relevant.
Perhaps we could also consider the differences between incoming and 
outgoing traffic...

Regards, marcelo

>
> .... 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
>
>
------------------------------------------
Please note that my former email address
[email protected] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------