Re: [ipv6-wg@ripe.net] Re: [lir-wg] IXP networks routing
Hi, On Tue, Mar 04, 2003 at 04:07:58PM +0100, Poul-Henning Kamp wrote:
It means re-thinking some established ways to do things - things that have caused large problems in the past, and might not have been an overly good idea to start with.
Well, but those "established ways of doing things" may also happen to be exactly why we could deploy IPv4 in the first place, and their absense have provably hampered IPv6 deployment.
Yes, of course we can stay on IPv4 with NAT and double-NAT and dynamic IPs for customers and whatever kludges are necessary... Changing over to IPv6 *is* painful. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
In message <20030304161229.G15927@Space.Net>, Gert Doering writes:
Hi,
On Tue, Mar 04, 2003 at 04:07:58PM +0100, Poul-Henning Kamp wrote:
It means re-thinking some established ways to do things - things that have caused large problems in the past, and might not have been an overly good idea to start with.
Well, but those "established ways of doing things" may also happen to be exactly why we could deploy IPv4 in the first place, and their absense have provably hampered IPv6 deployment.
Yes, of course we can stay on IPv4 with NAT and double-NAT and dynamic IPs for customers and whatever kludges are necessary...
Changing over to IPv6 *is* painful.
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
it ties directly to a fantasy that addressing and routing are not intimately and inextricably intertwined, and changing one requires serious thought about the other. randy
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite. Size of current v4 routing table: roughly 120000 entries Number of ASen visible : roughly 15000 So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things: * This makes the PI/PA distinction moot, or rather, we have PI only. Perhaps the mootness is temporary, but I hope not. It might be replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, and cannot be placed under any other AS". * The "v6 for services" problem will disappear. End of this discussion. * The routing table will shrink to 12.5% of its present size. * We will have a minor chunk of v6 space used, and all present users of v4 will be able to migrate without lack of address space. * If the number of ASen (with one /32 per AS) visible in the v6 table increase 100% compared to todays v4 figures, the table will still be only 25% of today. * Everybody will hunt me with both sharp and blunt objects for being a filthy pragmatic person with blasphemous opinions. Now, please tell me why this does not work. Purity reasons will have no effect, for I am too shortsighted. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Hi, On Wed, Mar 05, 2003 at 01:29:22PM +0100, M�ns Nilsson wrote:
So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things:
* This makes the PI/PA distinction moot, or rather, we have PI only. Perhaps the mootness is temporary, but I hope not. It might be replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, and cannot be placed under any other AS".
Unfortunately it's not that easy. It will just change the discussion from "I need IPv6 PI address space for my enterprise XYZ" to "I need an AS number for my enterprise!". I agree that "give every existing AS holder a /32" seems like a very elegant solution - but what about *new* ASes? I think it might create a "land rush" situation in the AS area ("get one while they are still easy to get"), which would be very bad. 32 bit AS numbers are possible, yes, but will not solve the core problem. [..]
* Everybody will hunt me with both sharp and blunt objects for being a filthy pragmatic person with blasphemous opinions.
It's not that this solution hasn't been proposed before. I'm just convinced that it won't work as a reliable way to scale into the future. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57021 (57147) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
--On Wednesday, March 05, 2003 14:16:09 +0100 Gert Doering <gert@Space.Net> wrote:
Unfortunately it's not that easy. It will just change the discussion from "I need IPv6 PI address space for my enterprise XYZ" to "I need an AS number for my enterprise!".
But don't they already have that? My proposal is exactly the same as the current need wrt multihoming in v4; you must have an AS number to multihome to several upstreams -- multihoming inside one provider still can be done over OSPF or similar; no need to get a separate allocation for that.
I agree that "give every existing AS holder a /32" seems like a very elegant solution - but what about *new* ASes? I think it might create a "land rush" situation in the AS area ("get one while they are still easy to get"), which would be very bad.
Yes, this is a calculated risk. But, the LIRen should of course keep their strict policies for ASN allocation -- must be visible over several paths within three months or so, and should stay so, with reevaluation applied. The cost and cumbersomeness associated with keeping an AS present in several paths, combined with a strictly enforced revocation process, should keep that landslide to thaw levels instead of avalanching.
32 bit AS numbers are possible, yes, but will not solve the core problem.
Not until Moore makes a 2^32 entries large routing table usable. My guess is that these issues are interdependent -- We will get routers that can handle these entries when there is an imminent risk that they will be necessary.
It's not that this solution hasn't been proposed before. I'm just convinced that it won't work as a reliable way to scale into the future.
I realise this. It is a calculated risk, based on studies of usage patterns during the last 10 years of v4 routing. I think that will sort itself out, if people are exposed to problems as opposed to just discussing horror scenarios. My point is, simply put, that: * Unless we get some blowtorch applied to the collective Internet posterior wrt v6, the people who state that v6 won't work will be right. I would hate that. * The hierarchical routing model used and promoted for v6 so far, seems, from the view of this naive bystander, to be designed by someone seriously opposed to practical v6 deployment, much as the Bundeswehr uniform is claimed to be designed by a pacifist, with the intent of making war unfeasible... * If it due to aggressive optimisation design choices is hard or impossible to get v6 working in an informal but live manner, nobody but a select few at the big operators will be able to play with it outside the tunnel playpen. * Thus, there is some value in sacrificing parts of the purity in the interest of gaining momentum and users, meaning more effort will be put into solving the problem. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Måns Nilsson wrote:
* If it due to aggressive optimisation design choices is hard or impossible to get v6 working in an informal but live manner, nobody but a select few at the big operators will be able to play with it outside the tunnel playpen.
Tunnels are just one of the _transitions methods_ for the endusers, that they where also used to bind together the 6bone is something else. The bigger and IPv6 aware ISP's are quickly moving out of that, read: http://ip6.de.easynet.net/ipv6-minimum-peering.txt I also am wondering how people define "multihoming". Do they define it as: - Multiple prefixes over multiple cables from multiple upstreams. - One prefix over multiple cables from multiple upstreams. - One prefix over one cable from multiple upstreams. If you are talking about the last case, where one only has one physical upstream... one shouldn't call that multihoming. I guess the second one is where people are talking about. And the first one is what I would call real multihoming, though one needs SCTP to make that work. Greets, Jeroen
--On Wednesday, March 05, 2003 17:53:00 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
Tunnels are just one of the _transitions methods_ for the endusers, that they where also used to bind together the 6bone is something else. The bigger and IPv6 aware ISP's are quickly moving out of that, read: http://ip6.de.easynet.net/ipv6-minimum-peering.txt
Of course. This is a discussion "post-tunnel". My comment was in the spirit of "going forth from the lab activity under 3FFE". Today 6bone is legacy.
I also am wondering how people define "multihoming". Do they define it as: - Multiple prefixes over multiple cables from multiple upstreams. - One prefix over multiple cables from multiple upstreams. - One prefix over one cable from multiple upstreams.
If you are talking about the last case, where one only has one physical upstream... one shouldn't call that multihoming. I guess the second one is where people are talking about. And the first one is what I would call real multihoming, though one needs SCTP to make that work.
Cases one and two. One or more prefixes advertised over multiple upstreams. Although my idea is to give people so much space in their initial allocation that only the biggest networks will need more than one prefix, thus keeping the routing table as close to "nPrefixes == nAS-numbers" as possible. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Måns Nilsson wrote:
--On Wednesday, March 05, 2003 17:53:00 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
<SNIP>
I also am wondering how people define "multihoming". Do they define it as: - Multiple prefixes over multiple cables from multiple upstreams. - One prefix over multiple cables from multiple upstreams. - One prefix over one cable from multiple upstreams.
If you are talking about the last case, where one only has one physical upstream... one shouldn't call that multihoming. I guess the second one is where people are talking about. And the first one is what I would call real multihoming, though one needs SCTP to make that work.
Cases one and two. One or more prefixes advertised over multiple upstreams.
Case one means having more than one prefixes on the cable, or in diagram style: +-----+ +-----------+ 2001:db8:11:22::/64 +------+ | the +---+ Cable ISP +------------------------+ eth0 | | N | +-----------+ | | | E | | YOU | | T | +-----------+ 3ffe:ffff:33:42::/64 | | | +---+ ADSL ISP +------------------------+ eth1 | +-----+ +-----------+ +------+ Thus YOU gets 2 different prefixes from 2 different upstreams. Ofcourse YOU could also get two /48's routed to him from these upstreams or more ofcourse. The fact is that a 'server' eg a web server will have 2 IP's; eg: www.example.com AAAA 2001:0db8:11:22::80 AAAA 3ffe:ffff:33:42::80 Ofcourse replace Cable and ADSL with the bigger lines, this is just to illustrate that the definition of 'multihoming' is quite a different thing for most people. As I said this will only work when using SCTP to 'multihome' when one of the two uplinks fail. In case two both upstreams carry "your" prefix, eg 2001:db8:11:22::/64 to the rest of the world, diagram style: +-----+ +-----------+ 2001:db8:11:22::/64 +------+ +------+ | the +---+ Cable ISP +------------------------+ R | | | | N | +-----------+ | o | | | | E | | u +----+ eth0 | | T | +-----------+ 2001:db8:11:22::/64 | t | | | | +---+ ADSL ISP +------------------------+ er | | | +-----+ +-----------+ +------+ +------+ Note that the moment you only have one physical path to the rest of the world you should not be talking about 'multihoming' any more (case 3) I always wonder why people want L3 level 'multihoming' even though their L1 and L2 path aren't.
Although my idea is to give people so much space in their initial allocation that only the biggest networks will need more than one prefix, thus keeping the routing table as close to "nPrefixes == nAS-numbers" as possible.
Every ISP that can match up to the current requirements for address space can get a /32 from all three RIRs. If you can't, you simply are not big enough and you won't have any multiple links either. If one really wants 99.9% certainty that their inet works one either needs to do it themselves and thus get multiple L1+L2 paths and the hardware along with it and then most of the times you are a big enough customer to get a /32 too. If you aren't you should just get a better upstream. Yes, I know, it all sounds quite harsh. Greets, Jeroen
--On Wednesday, March 05, 2003 22:27:51 +0100 Jeroen Massar <jeroen@unfix.org> wrote:
Case one means having more than one prefixes on the cable, or in diagram style:
+-----+ +-----------+ 2001:db8:11:22::/64 +------+ | the +---+ Cable ISP +------------------------+ eth0 | | N | +-----------+ | | | E | | YOU | | T | +-----------+ 3ffe:ffff:33:42::/64 | | | +---+ ADSL ISP +------------------------+ eth1 | +-----+ +-----------+ +------+
Thus YOU gets 2 different prefixes from 2 different upstreams. Ofcourse YOU could also get two /48's routed to him from these upstreams or more ofcourse. The fact is that a 'server' eg a web server will have 2 IP's; eg: www.example.com AAAA 2001:0db8:11:22::80 AAAA 3ffe:ffff:33:42::80
This is not what we are talking about.
Ofcourse replace Cable and ADSL with the bigger lines, this is just to illustrate that the definition of 'multihoming' is quite a different thing for most people. As I said this will only work when using SCTP to 'multihome' when one of the two uplinks fail.
In case two both upstreams carry "your" prefix, eg 2001:db8:11:22::/64 to the rest of the world, diagram style:
+-----+ +-----------+ 2001:db8:11:22::/64 +------+ +------+ | the +---+ Cable ISP +------------------------+ R | | | | N | +-----------+ | o | | | | E | | u +----+ eth0 | | T | +-----------+ 2001:db8:11:22::/64 | t | | | | +---+ ADSL ISP +------------------------+ er | | | +-----+ +-----------+ +------+ +------+
This is more to the point.
Note that the moment you only have one physical path to the rest of the world you should not be talking about 'multihoming' any more (case 3)
I always wonder why people want L3 level 'multihoming' even though their L1 and L2 path aren't.
Because even if backhoes are quite common creatures, the network engineer with fat fingers is even more common. Having said that, I agree that several redundant links are a practical prerequisite.
Although my idea is to give people so much space in their initial allocation that only the biggest networks will need more than one prefix, thus keeping the routing table as close to "nPrefixes == nAS-numbers" as possible.
Every ISP that can match up to the current requirements for address space can get a /32 from all three RIRs. If you can't, you simply are not big enough and you won't have any multiple links either.
Which is my point, sort of. But I still want the requirements slacked to fuel deployment.
If one really wants 99.9% certainty that their inet works one either needs to do it themselves and thus get multiple L1+L2 paths and the hardware along with it and then most of the times you are a big enough customer to get a /32 too. If you aren't you should just get a better upstream. Yes, I know, it all sounds quite harsh.
No disagreement there. But I do not think we talk about the same thing, or at least not in the same scale. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
If one really wants 99.9% certainty that their inet works one either needs to do it themselves and thus get multiple L1+L2 paths and the hardware along with it and then most of the times you are a big enough customer to get a /32 too. If you aren't you should just get a better upstream. Yes, I know, it all sounds quite harsh.
No disagreement there. But I do not think we talk about the same thing, or at least not in the same scale.
Most of the down time will most likely be waiting for BGP to converge. I think we need a new model, and a way to get there. A flag day is to optimistic. - kurtis -
32 bit AS numbers are possible, yes, but will not solve the core problem.
Not until Moore makes a 2^32 entries large routing table usable. My guess is that these issues are interdependent -- We will get routers that can handle these entries when there is an imminent risk that they will be necessary.
There are two sides to this. A) We need to buy time to get adoption of IPv6. Go for swamp or anything that is easy to implement. B) We need to fix IPv6. I am voting for 8+8 or 16+16. That will take time. We will need a way to migrate there that is relatively pain-free and that can cope with the swamp above. This will also make away with the Moore limitation (if such a thing exists). Who want's to write the drafts? - kurtis -
On Wed, 5 Mar 2003, M�ns Nilsson wrote:
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite.
No, (global) AS number is definitely not required, and if you really want, you could do without even a private ASn. A rather common scenario is to use private ASN to two providers, and leak more specifics from beyond your preferred ISP to the world -- and connect to the ISP as a secondary which owns the aggregate. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--On Wednesday, March 05, 2003 16:46:50 +0200 Pekka Savola <pekkas@netcore.fi> wrote:
No, (global) AS number is definitely not required, and if you really want, you could do without even a private ASn.
A rather common scenario is to use private ASN to two providers, and leak more specifics from beyond your preferred ISP to the world -- and connect to the ISP as a secondary which owns the aggregate.
Might be so, but even I am opposed to such ugliness. I have yet to see it, probably because most people doing so are ashamed of the practice... Furthermore, it might be possible to deprecate the behaviour of multihoming without public AS in v6, simply because few people will accept routes for smaller prefixes than /32.. -- Måns Nilsson Systems Specialist +46 70 681 7204 KTHNOC MN1334-RIPE We're sysadmins. To us, data is a protocol-overhead.
Check out: http://www.ietf.org/internet-drafts/draft-savola-multi6-asn-pi-00.txt the drawback seems obvious: at least I don't want to encourage anything that would hasten the move to 32-bit AS numbers, and definitely don't want to change the problem of end-site multihoming to AS-number exhaustion problem. On Wed, 5 Mar 2003, M�ns Nilsson wrote:
--On Tuesday, March 04, 2003 16:14:57 +0100 Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite.
Size of current v4 routing table: roughly 120000 entries Number of ASen visible : roughly 15000
So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things:
* This makes the PI/PA distinction moot, or rather, we have PI only. Perhaps the mootness is temporary, but I hope not. It might be replaced with AA -- AS Allocated, ie "these addresses belong to AS1653, and cannot be placed under any other AS".
* The "v6 for services" problem will disappear. End of this discussion.
* The routing table will shrink to 12.5% of its present size.
* We will have a minor chunk of v6 space used, and all present users of v4 will be able to migrate without lack of address space.
* If the number of ASen (with one /32 per AS) visible in the v6 table increase 100% compared to todays v4 figures, the table will still be only 25% of today.
* Everybody will hunt me with both sharp and blunt objects for being a filthy pragmatic person with blasphemous opinions.
Now, please tell me why this does not work. Purity reasons will have no effect, for I am too shortsighted.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0303051648430.6753-100000@netcore.fi>, Pekka Savola w rites:
Check out:
http://www.ietf.org/internet-drafts/draft-savola-multi6-asn-pi-00.txt
You're never going to carry that motion, it would make it likely that people would start to use IPv6 in practice. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
I'm mainly talking about the lack of a feasible way for end-customers to get working multi-homing. This ties directly into the "PI" space question.
Multihoming today depends on the possession of an AS number. I see no alternative to that prerequisite.
Size of current v4 routing table: roughly 120000 entries Number of ASen visible : roughly 15000
So, if we simply give every AS number holder currently present in the v4 table a /32 or so, with STRICT instructions to forget getting another prefix until half that prefix is pingable, we attain several things:
This is what Pekka Savola proposed in his draft. People will start screaming about 32-bit ASes. It's also similiar to my draft on creating IPv6 swap space. There are less than 15000 LIRs. Each LIRs /32 is more address space than most of them have today. Add the routes from all remaining AS:es. I don't see the problem. I am still waiting for the IPv6 routing table to reach 1000 routes. Call me then. - kurtis -
Gert Doering (gert@space.net) wrote:
Changing over to IPv6 *is* painful.
... but should be considered rather soon ! just my .2 cents --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
Kurt Erik Lindqvist (kurtis@kurtis.pp.se) wrote:
Changing over to IPv6 *is* painful.
... but should be considered rather soon !
just my .2 cents
First we need to get it to work.
Hi kurtis, what is _not_ working according your opinion ? (and we're not talking about hardware vendor support - i know it lacks in some cases) Side question: do a PPPoE exist for IPv6 ? --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
Changing over to IPv6 *is* painful.
... but should be considered rather soon !
just my .2 cents
First we need to get it to work.
Hi kurtis,
what is _not_ working according your opinion ?
Tools is the first that comes to mind. If you want the larger carriers to use it they need to adopt their provisioning systems, but that is not a fault of IPv6. I think we need to urgently solve multihoming, some PI like mechanism, and I think we should take out site-locals, or at least minimize their use until it's to late and we are stuck with the RFC1918 problem and applications that won't work.
(and we're not talking about hardware vendor support - i know it lacks in some cases)
That is a problem that will be solved when there is enough demand. - kurtis -
Kurt Erik Lindqvist (kurtis@kurtis.pp.se) wrote:
Changing over to IPv6 *is* painful.
... but should be considered rather soon !
just my .2 cents
First we need to get it to work.
Hi kurtis,
what is _not_ working according your opinion ?
Tools is the first that comes to mind. If you want the larger carriers to use it they need to adopt their provisioning systems, but that is not a fault of IPv6. I think we need to urgently solve multihoming, some PI like mechanism, and I think we should take out site-locals, or at least minimize their use until it's to late and we are stuck with the RFC1918 problem and applications that won't work.
Okay, so let's address this one by one: - what ideas do we have regarding multihoming, what is/should be deprecated and what preferred ?
That is a problem that will be solved when there is enough demand.
the usual chicken/egg problem :-) --jan -- Jan Ahrent Czmok - Senior Network Engineer - Access Networks Global Access Telecommunications, Inc. - Stephanstr. 3 - 60313 Frankfurt voice: +49 69 299896-35 - fax: +49 69 299896-66 - email: czmok@gatel.de
- what ideas do we have regarding multihoming, what is/should be deprecated and what preferred ?
Uh, uhm. There are quite a lot of ideas. Actually there is no problem with shortage of ideas. There is shortage on agreement to move forward though. Personally I (and many others) believe in a GSE like solution, 8+8 or 16+16 but that needs a lot more work so there is some meat on the bones. See the multi6 WG discussions in the IETF or the ipv6mh mailinglist. - kurtis -
Kurt;
- what ideas do we have regarding multihoming, what is/should be deprecated and what preferred ?
Uh, uhm. There are quite a lot of ideas. Actually there is no problem with shortage of ideas. There is shortage on agreement to move forward though. Personally I (and many others) believe in a GSE like solution, 8+8 or 16+16 but that needs a lot more work so there is some meat on the bones. See the multi6 WG discussions in the IETF or the ipv6mh mailinglist.
Multihoming is simple to just let hosts have multiple addresses, which is already done with IPv6, and let the hosts choose the destination address. The hard part is that there are a lot of works wrongly done with IPv6. It is wrong, for example, to have source address selection, router/host separation and complicated but poor mobility, all of which must be removed. The removal is technically easy but was politically difficult, as some people were insisting that IPv6 would be deployed immediately if the current specificaiton had been kept as is. Three years ago, they were insisting so for five years. Though I haven't checked activities of IPv6 WG for these three years, I hope they have finally give up now. There already is running code of of 8+8, transport over it, such as TCP, and applications over it, such as TCP multihomed telephony with no address reselection latency, that there is not much work remaning. Just choose it or something, if any, else. Masataka Ohta PS Never mention poor GSE. It is a poor idea useless for any purpose.
participants (9)
-
Gert Doering -
Jan Czmok -
Jeroen Massar -
Kurt Erik Lindqvist -
Masataka Ohta -
Måns Nilsson -
Pekka Savola -
Poul-Henning Kamp -
Randy Bush