Subject: For discussion: revising RFC1264

From: Alex Zinin <[email-masked]>
Date: Wed, 12 Mar 2003 20:48:55 -0800

Folks-

 We're going to discuss this topic at the RTG area meeting next week.
 Here's the background for the discussion.

 RFC1264 defines requirements for routing protocols going to standards
 track. It was published more than 10 years ago and there are several
 reasons why we would like to revisit those.

 The biggest issue with the document is that it does not spell out the
 requirements for protocol extensions, neither does it say that the
 requirements described in it are for base protocol specifications
 exclusively.

 Here's the draft list of changes/issues that I'd like to solicit your
 comments on:

 1. Number of interoperable implementations.
 
    The doc currently says:
     PS : 1 or more
     DS : 2 or more, at least 2 independent
     STD: 3 or more, at least 2 independent

    Should we raise this req to 2 for PS for both base protocol and
    extensions?
    
    The reason being that this is the only real way to check that the
    specification gives enough information for independent
    implementations to interoperate. Plus, of course, it raises the
    quality bar.

    The downside would be that if for some reason we would like to
    encourage implementation of something by making this a proposed
    standard, we wouldn't be able to do this until we had at least
    two interoperable implementations.

 2. MIBs. The document introduces a dependency between the MIB
    and the protocol specs:
    
     PS : MIB written in an I-D
     DS : MIB is at PS level
     STD: MIB goes together with the spec

    The first thing would be to make the MIB optional for extensions
    and use common sense to make sure the charter includes the MIB
    work if needed.

    For base protocol specs, the meta question is whether we really
    want to sync these two so much. We don't have such rules written
    down for other protocols, maybe we shouldn't for routing either,
    and just use common sense too. (Data point: 2026 does not require
    this.) The downside of this would potentially be decreased thrust
    behind the MIB work.

    Another meta question is whether the MIBs have to be read/write
    or read-only, i.e., whether we should mandate that MIBs be written
    for configuration as well as for monitoring or for monitoring
    only. Recent discussions suggest that we should mandate monitoring
    and make configuration optional.

 3. Reports.

    The text currently requires two reports submitted to the IESG
    along with the specs, the reports generally summarize the protocol
    scalability characteristics, experience in deployment of it, etc.
    These usually become separate RFCs.

    The de facto practice we have now is to not require those for
    extensions. I think the text should ask for only an implementation
    report (to ensure 2 interop implementations) submitted to the ADs
    for features.

 Add the following:
   
 4. Provide guidelines about what sort of details should be described
    in a specification.

    There have been discussions recently about what sort of details
    should be described for routing protocols. i.e., only bits on the
    wire (message format only) vs including node-local decisions,
    FSMs, timing, etc.

    I fundamentally believe that node-local decisions, as well as
    timing are important for routing protocol specifications (this, in
    fact, is how currently used protocols are described), and think
    that the document should spell this out as a requirement.

 5. Spell out what routing-specific details are expected in the
    security section for new protocols, i.e., threat analysis and
    authentication; and for extensions: changes to the set of possible
    attacks and to the protocols security mechanisms.

 6. For features--the specs should also talk about backwards
    compatibility, describing how the new feature interoperates with
    routers not implementing it, if protocol dynamics are changed, how
    they affect scalability, stability, and robustness of the protocol.

 7. For features--note that if the IETF owns the base proto
    specification, the maturity level for an extension cannot exceed
    the base spec's one, per 2026 because it is a normative ref.

 Plus fix the outdated procedural facts--those come from the times
 when IAB approved RFCs.

 Opinions are welcome.

-- 
Alex

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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 01:01:52 -0500

>     two interoperable implementations.

I'm all for raising the quality bar but some work, such as the
MPLS-diffserv is very good work but has one implementation (AFAIK
there is only one complete implementation in this case).  If we do
have consensus that something is worthwhile, it's not desireable to
keep this as an internet-draft and have it expiring all the time.

Maybe downgrade it (to what?) if there are not two implementation
reported within 2-3 years.

Also requiring that protocols advance, be updated, or be downgraded
(to what?) in 2-3 years would prevent what happenned to BGP (not being
updated when it needed it for many years).

>     and make configuration optional.

Read-only!  No question on that one.  There are some things that don't
much sense to make read-write so making write optional would be best.

A lot of useful stuff gets implemented and doesn't need a MIB to be
successfully deployed, particularly protocol extensions.

A good example of an extension that will not need a MIB to be
successfully deployed is the current soft-preemption draft.  It adds 3
bits to two existing bitfields and defines the semantics.  You could
argue that later on a counter of the number of soft-preemptions vs
hard preemptions could/should be added but that shouldn't be needed to
get to PS.  For DS, yes, keep the MIB requirement.

>     report (to ensure 2 interop implementations) submitted to the ADs

Why not implementation experience?  I could be a 2 pager.  (With all
the boilerplate there is no such thing as a one pager anymore).

>     wire (message format only) vs including node-local decisions,

More than bits on the wire.

OTOH the BGP FSM exercise we just went through IMHO was excessive.

>     attacks and to the protocols security mechanisms.

Yes.

>     they affect scalability, stability, and robustness of the protocol.

Definitely.

>  Plus fix the outdated procedural facts--those come from the times

Above I've suggested that instead of making it harder to get a
document to PS, make it harder to just get a document to PS and then
do nothing for the next decade.  A three year threshhold would affect
a lot of existing PS documents and force some cleanup.  I'm not sure
what to call the downgrade.  AS - abandoned standard?

Thanks

> Alex

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 01:01:52 -0500

Yes.

Definitely.

Thanks

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 12:03:34 -0800

Curtis,

Thanks for your comments, see inline below, pls.

> keep this as an internet-draft and have it expiring all the time.

Maybe we should try to agree on what's the most common case and
optimize for it while still provide an exception mechanism for rare
cases. I.e., if we believe that raised bar would provide helpful noise
reduction in the majority of cases, we could then say that this req
can be waived if there is a strong consensus that a technology is
worth pushing to STD with a single implementation.

> updated when it needed it for many years).

Hmmm... I hear you...

My first concern would be that we don't have the notion of downgrading
other than putting things to historical, and only if believe that
practicing a standard may damage things... Even if we came up with a
mechanism of downgrading things, where would we downgrade a PS? to an
internet-draft?

Also, in many cases, it's better to have _some_ specification than
nothing.

I agree with your concern, however... We need to think how to
stimulate people to keep specifications up to date.

>>  2. MIBs. The document introduces a dependency between the MIB
...

> get to PS.  For DS, yes, keep the MIB requirement.

we seem to be in agreement then--make MIBs optional for extensions
and require read-only.

> the boilerplate there is no such thing as a one pager anymore).

I guess it's more of a question of which form to use for this.
May be an e-mail message for PS and an implementation experience
document for DS and Full STD.

> OTOH the BGP FSM exercise we just went through IMHO was excessive.

Opinions vary :)

> what to call the downgrade.  AS - abandoned standard?

BTW, do we feel that we have people who are interested AND qualified
to do the clean-up?

This will be an interesting discussion topic for SF...

Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 12:03:34 -0800

Curtis,

Hmmm... I hear you...

...

Opinions vary :)

Alex

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 16:11:19 -0500

> worth pushing to STD with a single implementation.

OK.  Raising the bar with an allowance for exceptions sounds good.

> document for DS and Full STD.

Implementation experience for PS could be as simple as: we coded <it>
and it makes <some difference> in lab testing and <it didn't blow up>
on <someone's network> when we turned it on.  Interoperability testing
was done with <fill-in> and we worked around <barf> and know how to
fix <oops> and will <hope for better luck in next interop tests>.

This would tell us a bit more than implementation experience of <the
committee (study group) voted on it> and <we think it is a sterling
example of architectural purity> and <we haven't actully tried it but
we think everyone should implement it>.

Replace blanks as appropriate.  :-)

I think an implementation experience even if it says something was
coded and lab tested can be a measure of the maturity of spec.  If it
is simple and seems extremely safe and obviously useful the bar can be
low.  For something highly complex and controversial, the bar should
be higher.  If scalability is seriously in question, limited
deployment should be required.  The IESG gets to decide how much
implementation experience a particular PS merits based on complexity,
risks, and strength of the consensus.

This will very much reduce the noise.

> BTW, do we feel that we have people who are interested AND qualified

The PS authors and WGs should move drafts forward or expect the PS to
get downgraded.  If no one cares enough to move from PS to DS, the
standard is assumed to have been abandoned.

If there was no deployment after 3 years then it makes sense to
downgrade since the spec is implemented but unused but no one wants to
voluntarily admit their PS is dormant.

A good example of an old spec that may need a good look at
implementation experience is route flap damping.  The spec says:

  4.4.3 Per Route State

   Information must be maintained per some tuple representing a route.
   At the very minimum, the NLRI (BGP prefix and length) must be
   contained in the tuple.  Different BGP attributes may be included or
   excluded depending on the specific situation.  The AS path should
   also be contained in the tuple by default.  The tuple may also
   optionally contain other BGP attributes such as
   MULTI_EXIT_DISCRIMINATOR (MED).

   The tuple representing a route for the purpose of route flap damping
   is:

      tuple entry            default      options
      -------------------------------------------
      NLRI
        prefix               required
        length               required
      AS path                included     option to exclude
      last AS set in path    excluded     option to include
      next hop               excluded     option to include
      MED                    excluded     option to include
                                          in comparisons only

   The AS path is generally included in order to identify downstream
   instability which is not being damped or not being sufficiently
   damped and is alternating between a stable and an unstable path.

The first implementation was by Cisco followed by gated.  None of the
implementations offerred "AS path" in the tuple.  Implementation
experience should include comments from Randy Bush and others along
the lines of "route flap damping considered harmful".  An examination
of the types of problems that have occurred would show that if "AS
path" was part of the tuple, the problem would not have occurred.

As a community, then do we 1) give up on route flap damping or 2) push
the issue of including AS path in the tuple.  Requiring that the PS go
to DS or be considered abandoned would prevent inaction.

> This will be an interesting discussion topic for SF...

One of the strengths of the IETF in the earlier days was the people
proposing protocols were writing the code.  If someone proposed
something seemingly elegant but massively complex, they were free to
go off and implement it and since they'd never finish it, it became a
non-issue.  Putting the strong emphasis back on implementation and
deplyment before something even gets to PS would help cut down the
noise.  It might even be worth not accepting a draft as a WG item
until either at least one implementation exists, or there is strong
consensus that the draft is within the charter and worth doing.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 16:11:19 -0500

4.4.3 Per Route State

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 17:55:39 -0800

Curtis,

I'll put the points you suggested on the slides for the meeting.

> noise.

I don't think _deployment_ experience should be required for PS,
for several reasons:

 o We should have a way to encourage deployment of protocols
   by pushing them to PS

 o IANA code-point allocations are often done after a doc is approved
   as an RFC, which means that the implementations would need to
   be deployed with temporary hacks, and then change to the ones with
   real values... not good.

Plus, even though I believe requiring 2 implementations would be
useful, I also hear people say that the bar for PS is already way too
high than it was expected to be...

> It might even be worth not accepting a draft as a WG item

This would be an over-kill, I think. Problems mentioned above apply.
Plus, we DO want vendors to come to the IETF early in the process
while they are flexible enough with their implementations for the
IETF process to be meaningful.

Besides, consensus, as well as agreement of the ADs (and often IESG)
is already a requirement for a document to become a WG item.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 13 Mar 2003 17:55:39 -0800

Curtis,

Alex

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 23:11:47 -0500

> IETF process to be meaningful.

Its fine to discuss such a draft on the WG mailing list and then make
it a WG item when one implemetation exists.  This would keep people
from coming to the IETF meetings requesting a presentation slot so
they can ask for complete vaporware to be added as a WG item.  If the
answer is already definitely "no" then they are more likely to just
submit the draft, ask the WG mailing list for comments and begin the
implementation, the way things used to be.  Then when the
implementation is done or nearly done, report on how well it works and
if there is rough consensus make it a WG item.  When the second
implemetation comes along and interoperates, go for WG last call and
pass it along to the IESG.  Only if there was strong consensus should
an individual submission be accepted as a WG item without at least one
completed or nearly complete implementation.

> is already a requirement for a document to become a WG item.

This would reduce the number of arguments about whether consensus was
too rough or sufficient by providing an additiona criteria.  There
would be far fewer internet-draft meeting the criteria that would make
such an argument at all relevant if consensus was not perfect.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Mar 2003 23:11:47 -0500

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 15 Mar 2003 10:41:39 -0500

In message <Pine.WNT.4.53.0303150716540.3732@russpc>, Russ White writes:
> 
> 
> It seems to me that we almost need/want:
> 
> -- this is something that everyone should do, or is a good idea, but it's
>    not being implemented for some reason we can't fathom (or don't want
>    to talk about)

We could call this a best future practices if it is related to
operations.

> I don't know, it seems sometimes that good ideas get tossed around, and
> then don't get implemented, so they don't get recorded except in a draft
> that finally dies. Then, perhaps a year later, we get the same idea in a
> different form, and it dies as well.
> 
> Maybe we also need a to push some things directly to historical, so we have
> an idea of all the really bad ideas that have been brought up. It just
> seems like we're not capturing all we could, sometimes, in the process.

Good ideas in principle however in practice we have a manpower
problem.  Documenting all possible good ideas would add to the load.
Documenting all possible bad idea would be too much.  They are just
too plentiful.  Besides, we might hurt someone's feelings.  :-)

[ aside: You've probably heard the statement "the Internet is growing
exponentially but the amount of clue is growing linearly at best" (a
quote often attributed to Randy Bush, but whatever the origins it
dates back to at least the early 90s).  I might also add that
participation in the IETF is growing exponentially but the amount of
clue is growing linearly at best.  Bob Braden has expressed concerns
of "increase in entropy" in the IETF.  This would make the practice of
documenting bad ideas unscalable and the IETF does its best to avoid
unscalable undertakings. :-) ]

> I actually agree--sometimes we get too caught up in over specifying things.
> We're losing some of our creativity here, and pushing things into corners,
> it feels like. For instance, if someone else comes up with an fsm for bgp
> that's _much_ simpler, and still interoperates (a bgp peer can't tell the
> new fsm from the old), then why are specifying to this point, and stifling
> new things--just so we prevent people from making mistakes on it?
> 
> Maybe things like this (the fsm) should be pulled from the standard, and
> made "informational," or "standard contingent," or something like that, so
> we have a place to say (again): "this is a really good idea, this is how
> some other people may have done it, but we won't hold to this part, as long
> as you interperate, and can prove to interoperate." In fact, no-one I know
> actually implements the bgp fsm the way it's outlined in the doc (at least
> the last one I read).

The plain fact in this case is that in a decade of practice virtually
no problems where due to the state machine except with brand spanking
new and quite naive implementations, even thought the FSM was loosely
specified and perhaps not even entirely correct.  It would have been
better to put effort into 1) very clearly specifying the route
decisions (the single area that caused the vast majority of problems),
2) documenting means to make BGP implementations work conserving (by
far the most common problem rendering independent implementations
unusable when their authors think they are done and have some lab
testing behind them), and 3) performance implications of design
decsions in view of the large number of routes and high rate of route
change that BGP implementation will be subject to.  The first item
belongs in the BGP spec.  The next two items probably belong in the
protocol experiences document.  The WG's time would have been much
better spent discussing these *relevant* issues rather than nailing
down the exact wording of the FSM.

In this case, a limited number of people have 5 or 10 years (or more)
of experience with BGP and with numerous BGP implementations and are
aware of the history of operation problems but have to think to
remember where in the spec the ambiguities or mistakes were in the
cases where the spec lead to problems.  Those relatively new to BGP
tend to concentrate on the first thing that comes up when implementing
and the one thing spec writers who haven't done enough coding seem to
concentate on, the FSM.  IDR had the manpower to nail down the FSM in
great detail and now that the exercise is done we can move on.

I do feel that due to the 3-6 months of high noise level over the FSM
on the IDR mailing list, other discussion may have been drowned out.
Now that -19 will be available after this IETF it would be worth a
final pass during the last call to make sure the more problematic
parts of the spec got the attention they deserved.  Then we can move
on to the protocol experiences document.  There was no real loss over
doing a good job on the FSM except time.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 15 Mar 2003 10:41:39 -0500

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 15 Mar 2003 11:45:18 -0500

In message <Pine.WNT.4.53.0303150733080.3732@russpc>, Russ White writes:
> > Plus, we DO want vendors to come to the IETF early in the process while
> > they are flexible enough with their implementations for the IETF process
> > to be meaningful.
> 
> In fact, what we are currently seeing is drafts coming before the ietf with
> no implementations. The primary reason for this is "tight money." A lot of
> people are now unwilling to simply code something to see if it works, then
> take it to the ietf, then recode it. The price you pay for bringing a new
> feature into a protocol is now doubled over those who just "follow along,"
> and thus new ideas in protocols are discouraged--and participation in the
> process is discouraraged.

The bigger the committee that preceeds the implementation, the less
likely implementation will be acheivable and the less likely
implementations will work.  That's why we're not running OSI.

Pushing something all the way to PS before implementing it at all is
just a bad idea.  Doing this makes the decision of the committee of
professional standards body attendees almost final.

> So, we need to somehow be sensative to this fact in an industry that is
> coming into "maturity," whether or not we like it (feeling old yet?).
> 
> The second reason I see this happen (and I've seen it several times now) is
> that someone comes up with an idea. It's not implemented, so they don't
> take it anyplace, they just sit on it, thinking about it. Then, suddenly,
> another idea is published which would compete with theirs, but they believe
> their idea is better, in some sense.

Ideas can be brought to the IETF without implementations.  An
internet-draft can be renewed as many times as it takes for the idea
to get attention.

I'm not suggesting we don't discuss unimplemented idea, just that we
don't standardize unimplemented ideas.

> So, the rush publish, with no implementation, to make certain both ideas
> that solve the same problem are considered. Again, we need some way to take
> this into consideration. Sometimes a draft will, in some way, spur your
> thinking on an alternate way of solving a problem.... Again, we need to
> have some way to take these sorts of things into account.

No implementation and incomplete consensus, no standard.  That way
there are fewer arguments.

> :-)
> Russ

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 15 Mar 2003 11:45:18 -0500

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:04:44 -0800

Russ-

Saturday, March 15, 2003, 4:26:00 AM, Russ White wrote:
...

>    not being implemented for some reason we can't fathom (or don't want

This looks like a "recommendation" type of thing.

However, if we think there's a consensus that something is a really
good idea, and we really want it to go forward, 2026 tells us we
can make it a PS. It won't go any further without an implementation,
but PS should be a good stimulus. On the other hand, if we think
it might be a good idea, but we don't really want people to implement
and/or deploy it, there must be a reason for this and hence why
give someone a false sense of quality by documenting this as a "good
idea"?...

> seems like we're not capturing all we could, sometimes, in the process.

It seems that if someone really wants the community to know that
something is a really bad idea, one can come up with a "<blah>
considered harmful" Informational doc.

> actually implements the bgp fsm the way it's outlined in the doc (at least

I believe that the quality of a protocol specification should be such
that the protocol is implementable by reading the spec (no reverse
engineering of existing implementations) and be interoperable with
others, plus implementations need to exhibit consistent behavior in
those corner cases that matter in real life.

When message processing, generation, or general behavior depends on
previously received and sent messages, FSM is the commonly accepted
and one of the most efficient ways of describing the algorithm. FSM
allows one to exhaustively describe required behavior and ensure
adequate coverage of state/event or state/message combinations in a
human readable and (more importantly) understandable way. Trying to
describe the same with just human language will inevitably lead to
underspeficiation, inconsistency in interpretations and behavior,
which, as we know, may be quite drastic for routing protocols.

> I think people would be interested, but it's a matter of time. The next rfc
> passed should specify, in the standards track, a 30 hour day, of which 6
> hours are reserved for ietf work, and the remainder are for "normal
> living."

Exactly...

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:04:44 -0800

Russ-

Exactly...

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:10:50 -0800

Russ,

> process is discouraraged.

Hey, look at this from the positive side--less extensions means more
stable routing code == more stable Internet ;)

> have some way to take these sorts of things into account.

Agreed. I think the easiest way to take these into consideration would
be NOT to require an implementation for a draft.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:10:50 -0800

Russ,

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:48:11 -0800

Curtis,

> down the exact wording of the FSM.

Agree it would be very useful to address the three topics you
mentioned above, not sure it should have been done at the expense of
the protocol specification and FSM in particular. This part of the
spec (admittedly not the only one) was commonly known to be ammm...
not quite correct... and the reason we didn't see too many problems is
because a) people knew they couldn't trust completely that part of the
spec, so they went directly to reverse engineering, and b) problems
with FSM are not globally visible. We couldn't continue living
with the spec that was widely know to have problems.

...

> on the IDR mailing list, other discussion may have been drowned out.

It wasn't _only_ about FSM, though. The discussions have touch pretty
much all parts of the spec.

> parts of the spec got the attention they deserved.

Would be really great!

> Then we can move

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:48:11 -0800

Curtis,

...

Would be really great!

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:51:09 -0800

Curtis,

...

...

...
> there are fewer arguments.

This is a little different from what you suggested about the drafts,
but we seem to be converging: PS should require implementations
(in fact it does already), but I wouldn't like us to require this
for internet-draft before they become WG items.

Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 15 Mar 2003 12:51:09 -0800

Curtis,

...

...

...

Alex

---

From: Jing Shen <[email-masked]>
Date: Sun, 16 Mar 2003 10:55:13 +0800

I'm sorry if my question is out-of-the-interest.

I want to know wether there is some guideline on making up 
a FSM of a routing algo., sometimes I find it a little difficult 
to understand FSM if text explanation is not well written.

thanks 
> > doing a good job on the FSM except time.

Regards

-- 
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************
_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jing Shen <[email-masked]>
Date: Sun, 16 Mar 2003 10:55:13 +0800

thanks 

Regards

-- 
Jing Shen

State Key Lab of CAD&CG

---

From: Russ White <[email-masked]>
Date: Sat, 15 Mar 2003 07:26:00 -0500 (Eastern Standard Time)

> Maybe we should try to agree on what's the most common case and optimize
> for it while still provide an exception mechanism for rare cases. I.e.,
> if we believe that raised bar would provide helpful noise reduction in
> the majority of cases, we could then say that this req can be waived if
> there is a strong consensus that a technology is worth pushing to STD
> with a single implementation.
>

I think we also might need a category that we don't have today--it seems to
me that we only have:

-- this is a standard
-- this is experimental (we're not really certain this will work,
   but it seems worth playing with to see)
-- this is just informational
-- this is in common use, but doesn't impact any protocol, so it's
   best common practice

Yes.

> >>     attacks and to the protocols security mechanisms.

Agreed.

:-)

Russ

--
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Sat, 15 Mar 2003 07:26:00 -0500 (Eastern Standard Time)

-- this is a standard

Yes.

Agreed.

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sat, 15 Mar 2003 07:39:37 -0500 (Eastern Standard Time)

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sat, 15 Mar 2003 07:39:37 -0500 (Eastern Standard Time)

:-)

Russ

---

From: Russ White <[email-masked]>
Date: Sun, 16 Mar 2003 23:07:37 -0500 (EST)

> This is a little different from what you suggested about the drafts, but
> we seem to be converging: PS should require implementations (in fact it
> does already), but I wouldn't like us to require this for internet-draft
> before they become WG items.

Right--but should we have something other than "standard," "best common
practice," and "experimental" to choose from on the menu?

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Sun, 16 Mar 2003 23:07:37 -0500 (EST)

:-)

Russ

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 10:54:20 -0500

In message <[email-masked]
>, Russ White writes:

I suggested "best future practice" for operational issues in which
there was a very clear consensus that something should be done but
deployment was moving slowly.  Operational guidelines for security
come to mind.  For example, no service which can change the
configuration of routers or expose information critical to security
should be unencrypted.  In the mid-90s there was widespread agreement
on this but a widely deployed router lacked encryption, so it was not
"common practice".  There have been other cases in which operators
advocate a change in their own practices and widely agree that a
particular change would be beneficial but are unable to move forward
with the change for some reason (lacking protocol support, needing
cooperation of others which has not materialized, etc).  An example
would be a any solution from the ptomaine WG (though I don't know that
one was every finalized, though the problem was stated).

I don't think we should have a "neat ideas that no one has really
tried" category.  That would overlap experimental.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 17 Mar 2003 10:54:20 -0500

Curtis

---

From: Alex Zinin <[email-masked]>
Date: Mon, 17 Mar 2003 12:58:54 -0800

Curtis,

RFC2026:

> 5.  BEST CURRENT PRACTICE (BCP) RFCs

>    ... is a vehicle by which the IETF
>    community can define and ratify the community's best current thinking
>    on a statement of principle or on what is believed to be the best way
>    to perform some operations or IETF process function.

note the "best current thinking on..."

Also note that we're using BCP to describe the IETF process,
including the changes to it, which means that what's described
doesn't necessarily have to be deployed/practiced before it
becomes a BCP, best current _thinking_ on the problem is
enough.

-- 
Alex

---

From: Alex Zinin <[email-masked]>
Date: Mon, 17 Mar 2003 12:58:54 -0800

Curtis,

-- 
Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Mar 2003 13:50:17 -0500

Curtis,

On Sat, Mar 15, 2003 at 10:41:39AM -0500, Curtis Villamizar wrote:
> specified and perhaps not even entirely correct.

[...]

> The WG's time would have been much
> cases where the spec lead to problems.

The above excerpt is somewhat out of context, but really brings up
the point I wish to make.

My original motivation for participation in the IETF was the fact
that I was now working on the BGP protocol and the specification
WAS NOT SPECIFIC.  In some cases it was outright wrong.

I realize IETF RFC's are not specifications to the same level that
ISO specifications are (thank the powers that be).  However, one should
be able to proceed from the document to an interoperable implementation
without needing to delve into necromancy much less attempting to
reverse engineer what another implmentation actually does.  This is
*especially* important when an almost-correct implementation can
break our unfortunately fragile Internet.

In some cases, it was obvious in the document that there were Things
That Should Not Be Done.  When there was inadequate explanation for it,
people would ask "why are we doing this?" proceed to do it and discover
things painfully often too late.  Hard won wisdom should be embedded
somewhere.  That wisdom should not die off with the passing of people
from the working group.

What we have found, IMO, from the FSM exercise is that it was pretty easy
to describe in a very *general* way how the FSM should look and let
most people get it pretty close to right and still interoperate.  However,
if you leave the vagaries in, you require people to do that "extra work"
to get things correct.  The sheer size of the current FSM section
shows what a lot of that "extra work" would look like in someone's 
implementation.

The fact that the implementations I'm familiar with don't actually treat
the FSM as an actual state machine in most cases, much less a deterministic
one, is beside the fact.  It lets a new implementation interoperate
without resorting to reverse engineering - or at least that is the goal.

If we could have done the same job by getting rid of the FSM and
still make the powers that be happy, that would have been good.
However, the powers that be seemed to have demanded a FSM.

I'm not going to argue that we got what we really wanted.  The BGP-4
FSM section is huge, somewhat hard to follow, but at least tries to
reflect the specifics that were glossed over for a long time.  I place
no value judgement on this or your own (well known!) opinion on it.
I will summarize my point:

Don't leave things vague in the spec.  It will confuse those who try to
implement things in the future and the cleanup is almost more trouble
than it is really worth.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 Mar 2003 13:50:17 -0500

Curtis,

[...]

-- Jeff

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 18 Mar 2003 14:13:54 -0500

> implement things in the future and the cleanup is almost more trouble

Jeff,

I agree that keeping things wrong or vague is not good.  OTOH, the
route decision is actually where you did have to do reverse
engineering to determine that the spec was wrong in subtle ways that
could lead to route loops, not the state machine.

I've never advocated leaving the spec as is, in fact I insisted that
it not go to FS as is 2-3 years ago when IDR considered it for FS.  I
pushed to get the problem areas fixed before advancing.  I just never
viewed the FSM as being as important since having dealt with a number
of independent implementations, this is not where they had trouble.

Now that the FSM is in good shape that exercise is behind us (I hope).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 18 Mar 2003 14:13:54 -0500

Jeff,

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Mar 2003 15:32:16 -0500

> to understand FSM if text explanation is not well written.

Ideally, it should represent a standard deterministic finite state
machine.  You should have states and events.

The BGP FSM is a poor example of this for complicated reasons.

The VRRP FSM is a pretty reasonable example of one well done.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 21 Mar 2003 15:32:16 -0500