Re: [rrg] Recommendation and what happens next

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

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. 

> 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