Subject: A little rant over draft-fenner-zinin-rtg-standard-reqts-01

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 10 Nov 2005 18:48:00 -0000

Hi,

In the Routing Area meeting I raised the fact that I have concerns
Internet Routing Protocol Standardization Criteria
(draft-fenner-zinin-rtg-standard-reqts-01).

The previous version of this I-D was discussed in Paris. The minutes are
not on-line (not submitted?) but the write-up from Alia was posted to the
routing-discussion list by Alex on 3rd August.

Re-reading that write-up, I see that some concern was expressed about the
requirement for 2 independent implementations for PS. Much of this
discussion was focussed on the definition of "independent" and this has
been clarified in the latest revision.

This now frees us up to examine the requirement for *two* independent
implementations.

There was a little discussion on the list immediately after (or actually
during) Paris. These discussions also opened the question of how many
implementations should be needed for PS.

>From my perspective this debate reflects a change to the way that a PS is
cast within the industry. I think that at the moment it is hard to build
significant operational experience until publication as PS. That this may
or not be desirable is not the issue - the problem is that this is the
case.

Thus, if we make this change we need to find a way of persuading the
industry to implement and deploy something that is not on the standards
track and might change radically.

A solution to this, is to introduce a new category between WG last call
and PS. Let's call it PPS (proposed proposed standard). We would then
advance I-Ds to PPS, allow implementation and operational experience
before advancing to PS.

I hope there is no confusion that a PS is actually a standard. This seems
to show up a little in the email thread, but clearly it is not the case.

So I'm concerned that all we are doing is introducing a new label with the
effect that in three years time (say) we will need to introduce yet
another category because we are concerned that PPS is subject to the same
concerns as PS is subject to today.

Perhaps we should try to understand these concerns (personally, I think
the Motivation section is fine, but I don't see the text there being
mapped to concrete concerns, and I don't see a description of how the
proposed solution will address the text in the Motivation section).

1. "The Internet is being built from PSs"
I've heard this concern raised, but I don't think that it is an issue per
se. What is the underlying concern?
Is it that the PS is not advanced to DS in a timely manner?
Is it that a PS is assumed to be insufficiently stable? (or at least might
be unstable).
I would point out that failure to advance to DS does not mean that the RFC
doesn't meet the quality requirements, but rather it simply says that the
PS has not been advanced to DS.
Also, you have clearly decided that you cannot legislate against the wide
deployment of PS.

2. "There is insufficient operational experience of protocols that are
being deployed in the Internet"
Where do you propose that we gain such operational experience?
Will you legislate against deploying pre-PS protocols? Unlikely because
you are not willing/able to legislate against the wide deployment of PS.
So if you prevent progression to PS, will you end up with exactly the same
issue (insufficient operational experience of protocols being deployed),
because folk simply deploy mature I-Ds. if this happens you have all of
the same concerns PLUS, you have deployed protocols that have not even had
the benefit of IESG review before deployment?

Maybe some more work on the problem statement is required, and some
explanation of how the solutions solve the problems.

Thanks,
Adrian

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 10 Nov 2005 15:01:12 -0500

In message <058d01c5e628$c7c194c0$cf6d34d1@Puppy>
> explanation of how the solutions solve the problems.

The community that built the Internet believes in having running code
before a spec and in simple and useful specs which tend to produce
interoperable implementations.  The telco mentality has always favored
standards bodies which first debate, then specify, then vote and
ratify, then implement.

The great part about favoring running code and interoperable code
before standardization is you get simple standards that do the job
with a minimum of unnecessary complexity, and you get much better
interoperability.

The latter approach tends to support large bodies of professional
standards body attendees who do nothing else.  Enormous grandious and
unworkable specification can come out of this process (and have)
because it is essentially a political process with inadequate feedback
from the real world.  Makes for great spec writing careers though.

AFAIK the IETF is not ready to abandon running code and
interoperability in order to support spec writers who can't get their
ideas implemented and deployed.

If its simple and does something useful, write it down.  If its simple
and does something useful, someone will implement it because it
shouldn't take too much effort and someone will use it because it is
useful.  If its written down, simple, and useful, someone else will
implement it and if the internet-draft is clear and the protocol well
thought out the implementations will interoperate.

If the "new innovation" is either not simple or not useful, then this
won't happen as easily.  If it has excessive bells and whistles and
implementation options it will likely be difficult to get a second
implementation (let alone a first one) and the implementations will
have interoperability problems.  These are all good reasons not to
advance something to PS.

Curtis

---

From: Jon Crowcroft <[email-masked]>
Date: Thu, 10 Nov 2005 20:39:58 +0000

specifications are for communication between implementors
implentations are for use, 
having multiple implementations (more that 1) is more effective than meetings
for communicationing between implementors - so its an +early stage+ requirement, 
not a late one.
if you dont have at least two independent ones why do you want a spec anyway?
carts and horses really. i see the timing as residing in the need to have
ietf work _because someone wants their protocol "blessed" and the only blessing 
they are gonna get is if they want
to be able to talk to other implemeations of their protocol.

not that i know anything about routing  or the ietf, and i am probably old fashioned.
once upon a time, we'd have said 3 interworking implemenatons at least 1 and preferably 2
opensource. and things were demonstrably better for it. (go on, argue that one:)
as far as i recall, the rule of thumb in the 1980s was that it took about 3 months to implement a "correct" routing
protocol (e.g. of the complexity of OSPF, PIM or EGP) and then about 10 times that time to debug it agains a 2nd
implementation  (this is way harder than e2e protocols or application layer ones, where tesdtdevelopet aint so bad)

so the implementations are going to last a _long_ time ,throughout the documentation lifecycle, and therefore
the sequence described seems right to me...

 >>explanation of how the solutions solve the problems.

 cheers

   jon

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Nov 2005 23:37:25 +0200 (EET)

> This now frees us up to examine the requirement for *two* independent

This may be a good idea.  We may want to avoid publishing (as proposed 
standards) specs that are not useful enough for multiple vendors to 
implement.  But on the other hand, having the protocol documented 
should not hurt (maybe we need to apply 'Experimental' in these 
cases).

A more acute problem may be that some vendors do not see value in 
participating in the interop report process evne if they in fact DO 
implemnet the protocol.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings