Re: yesterday

[Tim Chown <tjc@ecs.soton.ac.uk>]

Hi,

I think an important message we saw from the multi6 session was that we can
do a great deal now for small/medium networks, including the interesting
SOHO case, with Christian's approach.   This is well-grounded practical
technology that we can work on, trial and use now.   The more feedback we
get on this from real deployment, the better :)

I agree NAROS++ could help add to Christian's proposal for sites that may
wish to manage their host-based policy (as Craig has requested in the past).
It is perhaps a distraction though for Christian's basic proposal, which
can probably fly as it stands.

In the short term it appears we need to meet demand for multihoming in "large"
enterprises by bending the allocation rules, for /48's or /32's, such that
big enterprises may get a SubTLA or /48.   However it is not clear what sort 
of demand there is out there right now for this, and thus how big a swamp
we would create.  
[Regarding the ASN method to allocate prefixes, could we simply state that 
only networks with ASNs as of <insert date less than today> qualify?]

In the longer term the identity-location split appears most interesting.  We
have some good proposals in that area, e.g. from HIP and Pekka N's work.   

Perhaps we should think about multi6 rechartering to match whatever general
path we wish to take?   But that's the discussion for Wednesday morning :)

Thanks to Kurtis for a nicely chaired meeting.

Tim

On Tue, Jul 15, 2003 at 10:18:33AM +0200, Iljitsch van Beijnum wrote:
> Some random thoughts on the session yesterday:
> 
> I once again want to object to the idea of putting a full routing table 
> in each host, as suggested by Masataka Ohta. I see a lot of practical 
> problems with this, I'm almost certain we need to create more or less a 
> completely new protocol for this to work as the only protocol that has 
> the right information is BGP but BGP needs manual configuration and 
> that is NOT something you want to do for each host. Then there is the 
> unnecessary resource consumption (IPv4 table using Zebra costs at least 
> 60 MB, a third of which is kernel memory wich can't be swapped out). 
> But the more fundamental problem is that all the really good stuff is 
> aggregated away in the global routing table, so the info you can derive 
> from that is by far inferior to what you can get from talking to the 
> other side. I don't mean _asking_ the other side, I mean doing 
> measurements on the packets going back and forth, the same way TCP does 
> to arrive at good round trip times.
> 
> Also, the NAROS approach gives nodes access to info in the routing 
> table too without many of the drawbacks. Although I hope NAROS does 
> more than just look at BGP or it has the same problem. But that 
> shouldn't be a problem: a NAROS server could also look at the line 
> utilization for different connections and do traffic engineering. Some 
> other thoughts on NAROS:
> 
> - Timeouts are bad. They are always too long or too short. An 
> additional way to handle invalidating caches in hosts would be to send 
> out a multicast message for this. This way, the NAROS server can 
> invalidate all caches and maybe even trigger rehoming of existing 
> sessions when something significant happens to external connectivity.
> 
> - Probably controversial: why first do a name lookup and then a NAROS 
> lookup? NAROS could be a superset of DNS so a host could ask the NAROS 
> server for info on a FQDN and get everything it would normally get from 
> a DNS server and then the address preference info. This is just an 
> optimization of the lookup process, I'm not proposing any changes to 
> the the DNS here.
> 
> - Hosts could send information they discover over the course of a 
> session back to the NAROS server so that it can help other hosts. For 
> instance, if a correspondent host has two addresses and the NAROS 
> server doesn't have a strong feeling about which is better, and one 
> doesn't work, the host sends back "this address didn't work" and then 
> the server can lower the priority for this address so the next host 
> will try the other address first.
> 
> I think NAROS has the potential to be a very powerful tool, which means 
> it propably needs to be "bigger" than the author(s) originally 
> anticipated. It would be a shame to standardize this in a way that soon 
> becomes too constricting for what people actually want to do.
> 
> On the 16 bit AS == PI prefix thing: this is just plain a very bad 
> idea. In the first place, it doesn't scale. Second, it WILL create a 
> land rush as it's very easy to get an AS number (hi Michel). Third, 
> current practice is already that the people with enough money that 
> really want it can get their own prefix, so there is no need to 
> specifically address this small group.
> 
> I did like a lot of the end-to-end, host centric and so on stuff, 
> however, it seems to me that a lot of this doesn't include the latest 
> wisdom on this subject. For instance, some form of 8+8 came up but 
> there was no explanation about how this can work with 
> autoconfiguration, how badly it breaks transport protocols and so on.
> 
> Also, some mechanisms (such as SCTP) need API changes. I think this is 
> EXTREMELY dangerous as this is a huge stumbling block for IPv6 
> adoption. The latest OSes support IPv6 and getting a tunnel or 6to4 is 
> fairly trivial, but we the reason why there is very little IPv6 
> adoption is that the applications simply fail to use it when it's 
> available. This is something we absolutely can't have with multihoming, 
> in my not so humble opinion.
>