Robin, > -----Original Message----- > From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On Behalf Of > Templin, Fred L > Sent: Monday, March 08, 2010 8:49 AM > To: Robin Whittle; RRG > Cc: Lixia Zhang > Subject: Re: [rrg] Recommendation and what happens next > > Hi Robin, > > About IRON-RANGER below: > > > -----Original Message----- > > From: rrg-boun...@irtf.org [mailto:rrg-boun...@irtf.org] On Behalf Of Robin > > Whittle > > Sent: Sunday, March 07, 2010 6:31 PM > > To: RRG > > Cc: Lixia Zhang > > Subject: Re: [rrg] Recommendation and what happens next > > > > Hi Tony, > > > > You wrote: > > > > >> Short version: Surely we should aim to do better than assume there can > > >> be no consensus. > > > > > > That would be nice, but consensus building is a process, not an > > > instantaneous event. It begins with debate, to be sure, but generally > > > involves people compromising to come together to back fewer and fewer > > > proposals over time. We've seen none of that. > > > > OK - but where have you encouraged debate, or contributed to it by > > arguing for your own preferred position? I understand you support > > ILNP (CEE, Locator / Identity Separation) - which are only practical > > for IPv6. I am not sure what you want for IPv4. > > > > Consensus doesn't involve just compromise - at least in the sense of > > people giving up on what they really want, and going along with less > > enthusiasm for something they think would be inferior, but not as bad > > as other alternatives. It also involves people changing their minds > > about what is practical and desirable - including recognising their > > own proposal is not suitable for IETF development or for the > > long-term future of the Net. > > > > Quite a few people who contributed proposals to the RRG have > > indicated they recognise their proposal is not sufficiently developed > > to be considered for IETF development - I think this is true of the > > mapping-only proposals and the CES proposal TIDR. So they may well > > be happy to support some other proposal. > > > > > > Some previously active proposals were not submitted for this phase of > > RRG consideration: > > > > Eliot Lear (msg05274) retired NERD from active development. > > > > APT was retired because the designers couldn't see how ISPs would > > be motivated to make the initial investment. > > > > Bill Herrin didn't develop TRRP any more or submit it for RRG > > consideration. > > > > Christian Vogt dropped Six/One Router and developed Name Based > > Sockets. I don't know whether he still wants Name Based Sockets > > considered for IETF development, because he hasn't written to the > > RRG since 13 January. > > > > > > >>> What I expect will happen will look like: > > >>> > > >>> - Some initial discussion > > >>> - Presentation of the recommendation > > >>> - Feedback afterwards > > >> > > >> OK - I understand from this you have no clear idea of what will happen. > > > > > > That's as clear as I can make it. What were you hoping for? > > > > Since you are one of the co-chairs and you are urging us - indeed > > expecting us - by so-far unspecified methods, to develop and in some > > way be happy with a single-architecture Recommendation in the next 19 > > days, I was hoping you would be able to give us more guidance about > > how to debate this, including leading by example: by arguing in > > detail for your own preferred outcomes. Lixia has done this for her > > AIS (Evolution) proposal. > > > > > > >>> Yes, it will undoubtedly be discussed after the meeting, probably for > > >>> several years. ;-) > > >> > > >> OK - but do you have a plan for when you will finalise the RRG Report? > > >> Discussions after that are a different thing from those before you and > > >> Lixia finalising it. > > > > > > Hopefully, it's all editorial afterwards. > > > > You haven't yet stated when you and Lixia intend to finalise the text > > of the RRG Report, at which point you will choose what, if anything, > > goes in the Recommendation section. Nor have you explained how you > > will choose the text, or guide the mailing list or meeting discussions. > > > > Do you intend to finalise the Recommendation during the meeting, or > > afterwards? If the former, than I am concerned that those not at the > > meeting will be at a disadvantage through not being able to be > > express our arguments as directly as those who can attend. If the > > latter, do you have any plans for how long after the meeting you will > > finalise the text? > > > > > > >>> Given the lack of consensus that we have seen so far, there's not going > > >>> to > > >>> even be a call for consensus. > > >> > > >> Then how could you be sure that no consensus existed? > > > > > > The discussions that we've had (both publically and privately) have made > > > it > > > quite clear that everyone is simply going to back their own proposals. > > > > This is a statement about the past. If this continues for the next > > few weeks, then there will be no large enough subset of active RRG > > participants with a compatible opinion to form anything like > > consensus. But I doubt that everyone would hold to their own > > proposals in the context of a detailed, constructive, debate - a > > debate we are yet to have. > > > > We already know that some of the proposals are not real proposals > > which could be considered for IETF development - those which just > > concern mapping systems: > > > > Compact routing in locator identifier mapping system > > Layered mapping system (LMS) > > 2-phased mapping > > Enhanced Efficiency of Mapping Distribution Protocols in > > Map-and-Encap Schemes > > > > There are three other proposals which are neither CEE or CES: > > > > hIPv4 > > Name overlay (NOL) > > Evolution - Aggregation with Increasing Scopes (AIS) > > > > hIPv4 involve changes to hosts and DFZ routers. (I don't recall > > whether it requires changes to applications). NOL involves changes > > to some routers and to applications. There's no way these can > > compete with CES proposals which involve no host stack or application > > changes. > > > > I am yet to read the response to my critique of AIS, but I can't see > > how it could cope with the reasonable goals of portability, > > multihoming and inbound TE for 10^7 non-mobile networks, much less > > mobility for 10^9 to 10^10 MNs. > > > > There are four CEE proposals: > > > > GLI-Split > > ILNP - Identifier-Locator Network Protocol > > Name-Based Sockets > > RANGI > > > > These are only for IPv6 and are all subject to the critique that they > > burden all hosts with extra delays and packets. Also, they require > > all hosts to be changed before there are substantial benefits to > > adopters or to scalable routing. > > > > None of the proponents of these architectures have argued why their > > proposal should be accepted for development and deployment ahead of > > any or all of the CES architectures. CES works for both IPv4 and > > IPv6, involves no host stack or application changes, and (at least > > with Ivip and LISP) provides full benefits to adopters irrespective > > of the level of adoption, and scalable routing benefits in proportion > > to their level of adoption. > > > > That leaves four CES architectures: > > > > IRON-RANGER > > Ivip > > LISP > > TIDR > > > > TIDR can't solve the routing scaling problem because its "mapping" is > > almost identical to advertising individual end-user network prefixes > > in the DFZ. I have argued that IRON-RANGER is not yet sufficiently > > developed to understand its security and scaling challenges - and > > The points on security and scaling have been addressed > in my latest rebuttal; see: > > http://www.ietf.org/mail-archive/web/rrg/current/msg06158.html > > > there's no apparent method of supporting packets sent from > > non-upgraded networks. > > Non-upgraded IPv4 networks will continue to work as they > always have. Do you mean non-upgraded IPv6 networks? > > Assuming the latter, let's consider that today we have > two separate BGP instances - the IPv4 BGP instance and > the IPv6 BGP instance. The IPv6 BGP instance carries a > set of IPv6 prefixes (e.g., 2001:: derivatives) that are > routed in the IPv6 Internet in the "traditional" sense. > What IRON-RANGER is doing is essentially creating a > *third* BGP instance - one that carries a new set of > IPv6 Virtual Prefixes (VPs) that are distinct from the > prefixes carried in the traditional IPv6 BGP instance. > > Due to routing scaling issues, IRON-RANGER expects that > growth of this new third BGP instance will flourish while > growth of the traditional IPv6 BGP instance will level > off. In order to support what I think you mean by > non-upgraded networks then, it only requires that IPv6 > routers connected to the IRON also participate in the > traditional IPv6 BGP instance. For that matter, not all > IRON routers need to participate, but at least some must.
Hmm, maybe these two IPv6 BGP instances I alluded to don't even need to be kept separate - as long as Virtual Prefixes can be kept distinct from non-virtual ones. This I think is the key point, and would greatly reduce the complexity. Thanks - Fred fred.l.temp...@boeing.com > > As far as I know, there have been no > > substantial counter-arguments to these critiques. > > Do the above points address your concerns? > > Thanks - Fred > fred.l.temp...@boeing.com > > > There is a coherent argument in my msg06162 why only LISP and Ivip > > could be considered for IETF development, why the distinguishing > > architectural elements of Ivip are superior to those of LISP and why > > Ivip or similar should be preferred over all other proposals for IETF > > development. > > > > No-one, including the LISP folks or any CEE proponent, has responded > > to this yet. Any constructive debate will involve people reading > > opposing views and responding to them in detail. > > > > > > Your statement: > > > > > The discussions that we've had (both publicly and privately) have > > > made it quite clear that everyone is simply going to back their own > > > proposals. > > > > may be true of the recent past. But surely it is your task - a > > difficult and perhaps thankless one - to improve on this pattern of > > people turning their back on real debate, ignoring other people's > > proposals and simply restating their positions, without properly > > engaging in debate about why their proposal is better than all the > > others. > > > > > > > Have you seen folks volunteer to withdraw their proposals and back > > > another? > > > I can think of only one case. > > > > Sure - but I am talking about the future, between now and whenever > > you finalise the RRG's Recommendation. > > > > > > >> It seems a curious plan to me - to assume there is no consensus, to > > >> assume the meeting will somehow produce a "Recommendation" and then that > > >> the meeting will debate it, but that there will be no test of consensus > > >> on the list or in the meeting. > > > > > > As I've said before: we would like their to be consensus, but from an IRTF > > > perspective, it is not a strict requirement. > > > > OK - but if you and Lixia include text as a "Recommendation" without > > a process which tests support for it - or if there is such a test and > > it only gets minority support - then the "Recommendation" won't have > > much value or be taken particularly seriously by the IESG or anyone else. > > > > > > >> Surely there's a role for the co-chairs in trying to establish what > > >> things people agree on and disagree on, and how the opinions of the > > >> various individuals can reasonably be grouped, or at least described. > > > > > > Indeed. This is, in part, the function of the document. > > > > I don't recall you or Lixia write anything about what various groups > > of people have in common and where they differ. > > > > Classifying the proposals into groups is a way of starting this > > process. I did this in msg06162 and neither of you have commented on > > this. > > > > > > >> I think there would be little point in developing a Recommendation > > >> which simply reflected the views of a subset of people, when there were > > >> multiple subsets with different, reasonably coherent views - since > > >> there's no way of choosing which subset's views to use for the > > >> Recommendation except by quite arbitrary means. > > > > > > This is the choice we're left with. Folks are unwilling to compromise yet > > > we need to make a choice. > > > > Your statement is about the past and you seem to have no hope or plan > > for improving on this currently bleak situation. In a recent message: > > > > Why won't supporters of Loc/ID Separation (CEE) argue their case? > > http://www.ietf.org/mail-archive/web/rrg/current/msg06187.html > > > > I suggested how you, as co-chair, could lead by example in arguing in > > detail for the position you support - including arguing in detail > > against the arguments (such as msg06162) for opposing positions. > > > > > > >> Even if we are highly divided, I imagine we could reach consensus on a > > >> Recommendation that the IESG consider, for instance, the three major > > >> bodies of opinion, which are irreconcilable. > > > > > > That's a failure to make any decision, which is, itself, a failure. > > > > Sure - but if that is the best we can do, then surely it would be > > better to produce a coherent report on the various positions which > > people have adopted, with the arguments each group advances in > > support of their position, and the arguments they provide against the > > positions of others. > > > > To pretend that the situation involved more agreement than it really > > does would be a worse failure. > > > > Also, I think it would be a failure if this situation of isolated, > > disengaged, groups of people or individuals persisted due to lack of > > hope or guidance from the co-chairs about how to constructively > > debate the issues so that people might change their mind, or at least > > articulate the reasons for their positions better than they have so far. > > > > > > >> Then we could probably reach consensus that this statement was a > > >> reasonable summary of the major bodies of opinion amongst participating > > >> RRG members. The Recommendation would not be to adopt a single > > >> architecture, but that the IESG consider the three or whatever types of > > >> approach which are most prominent. I think this would be a useful > > >> thing to work on and to present to the IESG. > > > > > > We disagree. Our job is to present the IESG with a path. > > > > You seem to think the only useful thing the RRG can do is present the > > IESG with a single chosen architecture to develop. > > > > You seem to believe that it it will be impossible to get consensus > > agreement to any such single architecture recommendation. > > > > Yet you intend to produce such as single architecture recommendation > > - and expect RRG members to be happy with this. > > > > You have no apparent plan - and do not lead by example - for debating > > the issues, trying to identify commonalities and differences etc. > > > > You have even stated that you don't plan to test for consensus. > > > > I think that is an extraordinary statement to make. It hardly > > encourages people to engage in the RRG process if you are planning to > > choose some text as the RRG Recommendation which doesn't result from > > consensus and which you don't even plan to test for consensus support. > > > > - Robin > > > > _______________________________________________ > > rrg mailing list > > rrg@irtf.org > > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ > rrg mailing list > rrg@irtf.org > http://www.irtf.org/mailman/listinfo/rrg _______________________________________________ rrg mailing list rrg@irtf.org http://www.irtf.org/mailman/listinfo/rrg