Hi, Robin, I've got your point, and yes, very persuasive indeed.
Well, I must be totally wrong, but I thought, in the RRG meeting discussions a while ago in Hiroshima, there were some comments that we might reconsider and look for a long-term fundamental approach. So, I thought there could be another camp of B or at least A/B. I must have been seriously mistaken. If what you describe in length was really the fundamental baseline of this group, then I shouldn't waste your time anymore, for already quite a number of smart patch solutions aimed to solve the urgent and immediate dilemmas have been developed for the last some two years. Watching which solution will be picked, however, won't be boring, so I'll be around in the back for the time being. Thank you. On Sun, Dec 6, 2009 at 5:38 PM, Robin Whittle <r...@firstpr.com.au> wrote: > Short version: Some folks can see a way of solving the routing > scaling problem via changes which would be widely > voluntarily accepted - which in part means > that the new system does not require any changes > to host stacks or applications. > > Of these, some would be happy with the outcome in > the long-term (except no-one is happy about IPv4's > limited address range) and others would see these > changes as a half-way house to something better - > involving new software for hosts, at least new > stack software and probably new stack-app > > interfaces - so new application code too. > > Other folks can only see a solution by changing > protocols to something more elegant and correct - > which means changes for host stack and app code and > changes to most or all routers. > > > Hi DY, > > You wrote: > > > So, you still don't catch the implication of my model. > > No - I have no clear understanding of what you were writing about. I > could have written a page or two about why I disagree with my > understanding of your first two points. I didn't because of my > impression that any proposal might emerge from your framework would > not be suitable for voluntary adoption. > > > > OK, I'll draft a > > description of the routing scenario that this name/address scheme would > > generate in a few days, to meet to the constraints you raised. > > OK - if it looks like it might be suitable for voluntary adoption, I > will read it and post my comments to the list. If not, I think other > people would be interested in discussing it. > > > > A question before that. > > > > Is the list of constraints already a general consensus of this RRG? > > Only the co-chairs Lixia and Tony can determine consensus. I think > this list of constraints has fared pretty well so far, because a > number of people have been commented on it and because those people > have supported it, without major criticisms. Also, the comments have > led to fruitful discussions. > > > > Does silence mean acceptance? > > Silence on a mailing list could mean either it is boring and not > worth honouring with a comment, or that it is OK. Generally, unless > something is completely ridiculous, if someone puts up a document > which anyone strongly disagrees with, at least one person will point > out what is wrong with the document. No-one has written that this > list contains things which are not real constraints - although the > last 3 are more "sliding scale" constraints compared to the absolute > nature of the first 7. > > > > You say like this is a firm consensus > > whatsoever, but I don't think I remember there's been any explicit > > statement like that. > > I have never said there is consensus on this. Only Lixia and Tony > can determine that. I have asked if there is consensus on it, hoping > to prompt people into agreeing or disagreeing and to prompt Lixia and > Tony into leading a discussion on it. > > I think that that it would be good to include a list of constraints > in the RRG recommendation. There are constraints due to other things > we can't change, but I think the list of constraints due to the need > for voluntary adoption is very important and should be given prominence. > > > If you will, would you ask the RRG chairs put your > > constraint at the beginning of the proposal lists so that it be taken as > > an absolute basis? Or have I missed something already done in that > manner? > > Yes, as I just mentioned. > > I think this question illuminates a distinction in viewpoints among > RRG members. I think there's a group of people I will call "A" who > believe something like this: > > 1 - The routing scaling problem is urgent enough that we should > fix it in the foreseeable future - which means in the IPv4 > Internet first, and with less urgency, and ideally in a similar > manner, in the IPv6 Internet. > > 2 - There is a way which we can do this within the constraints of > voluntary adoption. > > Within this group, I think opinions vary as to: > > 3 - Whether or not we can or should attempt to ensure the scalable > routing solution also achieves other goals, such as making > mobility more practical (including perhaps for IPv4) or > some other goals, such as multicast on a global basis, easier > transition to some other network such as IPv6 or something > else. > > 4 - How elegant and long-term desirable the upgraded IPv4 or > IPv6 network would be - and therefore whether the upgrade > should be a stepping stone to something different in the > not-too-distant future. > > > On the other side are the "B" people who think something like: > > 5 - We can't fix the routing scaling problem (and achieve any other > goals which should be achieved at the same time, such as making > the Internet protocols sufficiently elegant, secure, efficient > etc.) with anything which could be introduced smoothly on a > voluntary basis. > > 6 - This means we shouldn't bother trying to fix the IPv4 routing > scaling problem. We should focus on an enhanced IPv6 or some > other system. Adoption will come when IPv4 becomes unworkable, > due to address shortage and/or the routing scaling problem > (which I think are somewhat interdependent). > > I entirely disagree with these people, so its best if I don't try to > represent what their views might be. > > Some folks see sufficient benefit in a scalable routing solution to > make it worthwhile - and can see how this could be introduced > voluntarily. However, they do not regard that result as an > acceptable long-term outcome, so they envisage a transition beyond > that to something quite different - something involving new > approaches to naming, identification and addressing - something > involving major changes to host stack and application software. So > those are the "A->B" team! > > I am on the A team. If I can think of a way of making the scalable > routing solution for IPv4 also ease transition to some new network > which is scalable and has a big addressing range, then I will make > this a separate proposal and so join the A->B team. > > > > For example, your 3rd constraint says: > > > > 3 - Therefore, the solution must be compatible with > > all hosts (stacks and applications) and routers > > in non-upgraded networks. > > > > So, you're asking compatibility with all non-upgraded hosts and routers, > > don't you? > > I am not asking for it. I would prefer it if we could redesign the > Internet without these constraints. I am saying that as far as I > know, we need widespread voluntary adoption and that one of the > conditions of this is that the new scheme must work well (with little > or no degradation in performance, security, robustness etc.) with > existing hosts, routers and networks. > > > It looks to me as if you're not [word added according to DY's next > message] > > going to fix the real problem inside. Just patching on it. > > Sure - the core-edge separation schemes (LISP, APT, Ivip and TRRP) > are a patch. > > From the point of view or architectural purity and excellence, that > is a problem - because to achieve these goals you need to redesign > everything. > > From the point of view of people actually achieving a better > Internet, it is a feature that the core-edge separation schemes are a > patch - because redesign is not an option. > > > You're going to inject more drug into the > > body or an extra artificial organ beside the real problem area. > > As I wrote in a recent message, maybe it would be kinder and better > for us all in the long term if someone killed IPv4 right now and > everyone was forced to adopt IPv6, which at least has enough address > space - and then we could develop a scalable routing solution for > IPv6 which would enable widespread adoption of a new Internet without > the 3.7B address limit of IPv4. Or maybe it would be kinder to kill > IPv6 too and force us all to move to another Internet which was even > better. > > These are hypotheticals. There are immense forces at work to keep > IPv4 working as well as possible, whatever its limitations. Look how > hooked most of us are on Windows and QWERTY keyboards. > > The IPv4 Internet is far and way the world's biggest and most > entrenched IT system. It has absolutely no backwards compatible > upgrade path to any other addressing system or set of protocols. Its > utility is primarily dependent on the fact that it currently connects > every single host which anyone wants to be globally accessible. The > IPv6 Internet or any other attempt at creating a global Internet > can't interoperate with the IPv4 network and its existing hosts, so > there is no seamless upgrade path. > > The core-edge separation schemes are intended to largely eliminate or > reduce the IPv4 scaling problem - or at least to stop it getting much > worse, while enabling tens of millions to perhaps billions of > networks to have their own address space, which is portable between > ISPs, and can be used for multihoming and inbound traffic engineering. > > With the exception of the IPv4 address range limitation, I envisage > an outcome which I think will be pretty elegant. With Ivip, I have > plans for avoiding encapsulation overhead between ITR and ETR and so > for for avoiding PMTUD problems caused by that. I have a mobility > scheme which would work well for both IPv4 and IPv6 with full > connectivity to existing mobile hosts, and generally optimal paths. > > I think it is the correct approach to put a lot of workload for > routing and addressing in edge and near-edge devices such as ITRs and > ETRs (though the ITR function can often be done well in the sending > host). I am opposed to the idea of putting more workload on the > hosts, which AFAIK is a characteristic of all the "let's really fix > the Internet" proposals. > > Some people, perhaps including yourself, want to see a very simple > "network" with the hosts doing more work than they do now, to > maintain a logical address for communications to work from, which is > separate from their physical address. > > I am opposed to this and will write about this in a separate thread. > > Yes - I am modifying the patient's perhaps imperfect body, but I > think the result will be pretty good (except for the IPv4 address > range limitations) and I argue it would be better than burdening all > hosts any responsibilities regarding routing and addressing beyond > what they have now. > > > Or your wording comes to me as if you were asking to cut flesh without > > spilling a drop of blood. I'm already chocking. > > I am saying that we can't forcibly do anything to the way the great > majority of people use the Net - and we need to change this in order > to solve the routing scaling problem. No-one has yet disagreed with > this - AFAIK, everyone agrees we are bound by the need for voluntary > adoption. > > As far as I know the only way we can solve the scalable routing > problem or make any other changes to how most people use the Net is > to devise things people which people will happily adopt for their own > immediate reasons, which will also (if used very widely) achieve our > goals of solving the scalable routing problem. > > > - Robin > > > -- Regards, DY http://cnu.kr/~dykim
_______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg
