Re: [rrg] Recommendation and what happens next

["Templin, Fred L" <[e-mail]>]

Robin,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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
[e-mail]

> > As far as I know, there have been no
> > substantial counter-arguments to these critiques.
>
> Do the above points address your concerns?
>
> Thanks - Fred
> [e-mail]
>
> > 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
> > [e-mail]
> > http://www.irtf.org/mailman/listinfo/rrg
> _______________________________________________
> rrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/rrg