Re: [Fwd: I-D ACTION:draft-lear-multi6-things-to-think-about-00.txt]

[Eliot Lear <lear@cisco.com>]

Marcelo,

> - Is the multi-homing solution IPv6 only or can it also be used with IPv4?
> I know this is multi6, but it is probably interesting to know if the
> solution can be applied to IPv4

This is worth while answering, for the reasons Tony mentions.  However, 
just because a solution works for v6 but not for v4 (say making use of 
the flow label that doesn't exist in v4) does not disqualify it as a 
right proper solution to the problem at hand.  As we've discussed in 
person and on the list, v4 is a bonus if we can get it.

> - Does your solution applies to all type of sites?, for instance is your
> solution suitable for very small sites? (does it requires an expert
> administrator o very powerful equipment) is your solution siutable for very
> large sites?

I think there is a related question I also failed to ask: what sort of 
support from upstreams and the registries does your solution require (if 
any)?

> - About incremental deployment, i think that there are different ideas about
> what incremental deployment means. So perhaps we could ask more specific
> question (in addition) like:
>      - Does your solution imposes changes outside the multi-homed site?

Right- that's in there (at least in part), but see above as well.

>             - what do you need to change in the mh site? in particular if
> you plug in a non upgraded IPv6 node, does it work properly? can it
> communicate outside the mhsite? does it obtain multi-homing benefits?

This is a good question, and also was not clear in the draft.  If the 
mechanism can make use of stateless autoconfiguration or DHCP in some 
way to enable itself (at least at the conceptual level) that would be nice.

Here's a question: do nodes all know who they are?  How do they gain 
their knowledge?  Is there a change to dhcp or stateless 
autoconfiguration?  If so, describe.

>      - Does your solution requires some global infrastructure to start
> working? like a new global DNS like system, or it allows two upgraded nodes
> to communicate with each other without any additional infrastructure

that's also in there.

> - If your solution preserves established communications, does it introduces
> overhead? additional data? additional processing in the nodes? How does your
> solution distributes the overhead? does it imposes additional overhead on a
> per communication basis or a per node basis? does it imposes extra overhead
> to all communications? does it imposes additional overhead for those
> communications that don't suffer an outage along its path? does it only
> imposes overhead after the outage?

Your question was a bit more general than what I wrote.  I talked about 
packet expansion, but I did not talk about exchanges that might add 
latency, and that will need to be added in the next version (I'll put it 
out the first week in January).
> - Impact od DNS, does you solution will impose an additional significant
> stress to the DNS system? like how much more DNS queries are expected

The number of queries were not addressed; this is a good question, 
especially if the mechanism will screw up normal DNS caching semantics 
in some way, or othrewise will be screwed up by those same semantics.

Happy Holidays,

Eliot