Subject: Re: [Idr] [Technical Errata Reported] RFC2439 (3964)

From: "John G. Scudder" <[email-masked]>
Date: Wed, 7 May 2014 11:12:01 -0400

Hi Gunjan,

RFC 2439 isn't the easiest to read, but according to my reading this erratum is not correct. Despite its name, the "reuse list" as described in S. 4.8.7 is used for processing timer-driven events in general, including freeing up damping structures ("histories"). Quoting from S. 4.8.7, "Handling Reuse Timer Events": 

                      all of the routes in the first queue will be
   available for immediate reuse if reachable or the history entry could
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
   be disposed of if unreachable.
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If you have any doubt that "history" means "damping structure", take a look at S. 4.8.2:

   If there is no previous stability history (the damping structure
   pointer is zero), then:

I assume you're clear on why histories for unreachable routes need to be maintained to begin with.

I'm going to recommend to the AD that this erratum be rejected, unless you or someone else wants to make a case why it shouldn't be.

Thanks,

--John

On Apr 15, 2014, at 10:36 AM, RFC Errata System <[email-masked]> wrote:

> The following errata report has been submitted for RFC2439,
> "BGP Route Flap Damping".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=2439&eid=3964
> 
> --------------------------------------
> Type: Technical
> Reported by: Gunjan Bansal <[email-masked]>
> 
> Section: 4.8.2
> 
> Original Text
> -------------
> In either case then:
> 
>     1.  set t-updated = t-now
> 
>     2.  insert into a reuse list (see Section 4.8.6)
> 
> Corrected Text
> --------------
> In either case then:
> 
>     1.  set t-updated = t-now
> 
> 
> Notes
> -----
> The route which is unreachable should NOT be inserted into the reuse-list. reuse-list (as per explanation in Section 4.8.7) is used for fast evaluation of routes which have been suppressed long enough and can be potentially used again. The "unreachability/withdrawal" of route is never suppressed and never needs to be re-evaluated in future.
> 
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC2439 (no draft string recorded)
> --------------------------------------
> Title               : BGP Route Flap Damping
> Publication Date    : November 1998
> Author(s)           : C. Villamizar, R. Chandra, R. Govindan
> Category            : PROPOSED STANDARD
> Source              : Inter-Domain Routing
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 May 2014 11:49:15 -0400

John, Gunjan,

John is correct on both points.  The document lacks clarity in
general, and the reuse list is used for both reachable and unreachable
routes, disposing of all history associated with the route if it
unreachable.

Two structures could have been used but it is computationally more
efficient to have one slightly more dense data structure than two
slightly more sparse data structures.  Except for the sentence that
John pointed to the document is not clear about this.

A rewrite of RFC2439 is long overdue but would risk reigniting old
flame wars.  If the rewrite was clear about deployment experience
section were clear about the problems that have occurred, then the
flame wars might not be so intense.

Curtis

In message <[email-masked]>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 14 May 2014 13:14:11 -0400

It is excellent to push well implemented and understood RFCs to a Full Standard.

Alia

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 15 May 2014 10:25:52 -0400

> It is excellent to push well implemented and understood RFCs to a Full Standard.

I support Curtis' comments: The document is need of a re-write.  Many of the
ideas are used in various implementations, but I'm not aware of anyone that
faithfully implements the details about how flaps are counted.

If anything, we'd need to document what people did, let that sit around long
enough to be considered proposed. :-)

The motivation for moving it along the standards track are rather low since
in general (modulo Randy Bush's rfd-usable I-D that's in the RFC Editor's
queue) the feature is not recommended.

-- Jeff

> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Thu, 15 May 2014 08:01:47 -0700

> queue) the feature is not recommended.

If anything, someone should write an RFC describing all of the problems with this idea and moving the document to ‘Historical’.

Tony

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 17 May 2014 15:50:21 -0400

In message <[email-masked]>
Tony Li writes:
 
> If anything, someone should write an RFC describing all of the
> problems with this idea and moving the document to "Historical".
>  
> Tony

It is still in use.

We should document that some of the problems, perhaps most, have to do
with one major vendor not following the "per path" recommendation in
the draft and another major vendor following suit.  Memory is no
longer as tight as it was in 1995 so the excuse to keep only "per
destination" state is rather weak.

Curtis