[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt
- To: Pekka Savola <firstname.lastname@example.org>
- Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to-think-about-00.txt
- From: Eliot Lear <email@example.com>
- Date: Thu, 28 Oct 2004 14:09:09 +0200
- Cc: Brian E Carpenter <firstname.lastname@example.org>, Multi6 <email@example.com>
- Iim-sig: v:"1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1098965444.940596"; x:"432200"; a:"rsa-sha1"; b:"nofws:5543"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2pXIw" "eAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRU" "tW+c43sl9jC50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"rx/uAFxsTRy2pZhLtD8z5QiHZ+32GxXbcLkrWpnemeB6ijeppxSA8cmfKyHsE" "XNgSIj4m0qkcFV4ztJWjHZfOkK7qUpzvz941MDNqoq6l70hEQm2i0jWigAKb5" "4BNb62tTGx0DQjqNViqLcVWTmG59Qhg9ViDK30mrjO2UUGmcs="; c:"Date: Thu, 28 Oct 2004 14:09:09 +0200"; c:"From: Eliot Lear <firstname.lastname@example.org>"; c:"Subject: Re: Multi6 WG Last Call (2 of 3) draft-ietf-multi6-things-to" "-think-about-00.txt"
- Iim-verify: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; "
- In-reply-to: <Pine.LNX.email@example.com>
- References: <4176E3B7.firstname.lastname@example.org> <Pine.LNX.email@example.com>
- User-agent: Mozilla Thunderbird 0.8 (Macintosh/20041027)
2.3.3 Can your solution be aggregated and implemented site-wide?
This is now in Section 4.1: does your solution change existing
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
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.
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
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
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.
2.7 Can multihoming capabilities be negotiated end to end during a
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
This is included above based on your earlier feedback.
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.
Whether that should be a section of its own, or a couple of questions
e.g., in 2.7 is your call.
3.4 How is the binding updated?
Will transport connections remain up when new paths become available
or when old ones become unavailable? How does the end node discover
==> You should probably also ask:
How long does it take to notice new paths? How long does it take to
notice paths which are already used which have become unavailable?
That's a good question.
3.12 Are there any implications for scoped addressing?
Please see RFC 3513 . How does your mechanism interact with
==> 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.
4.3 Are there any changes to ICMP error semantics?
Do you create new codes? If so, why and what do they mean? Will a
host that is not aware of your scheme see them?
==> add 'What would happen if such ICMP messages would end up being
e.g. in a firewall?'..
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
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.
Will modify as appropriate.