Skip to main content

OSPF Refresh and Flooding Reduction in Stable Topologies
draft-pillay-esnault-ospf-flooding-07

Revision differences

Document history

Date Rev. By Action
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for Harald Alvestrand
2012-08-22
07 (System) post-migration administrative database adjustment to the No Objection position for David Kessens
2005-07-18
07 Bill Fenner Note field has been cleared by Bill Fenner
2005-07-18
07 Bill Fenner
In authors' 48 hours:

From: RFC Editor
Subject: authors 48 hours: RFC 4136
          NOW AVAILABLE
Date: Wed, 13 Jul 2005 …
In authors' 48 hours:

From: RFC Editor
Subject: authors 48 hours: RFC 4136
          NOW AVAILABLE
Date: Wed, 13 Jul 2005 17:20:03 -0700
To: padma0528@gmail.com
2004-09-21
07 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-09-20
07 Amy Vezza IESG state changed to Approved-announcement sent
2004-09-20
07 Amy Vezza IESG has approved the document
2004-09-20
07 Amy Vezza Closed "Approve" ballot
2004-09-17
07 (System) Removed from agenda for telechat - 2004-09-16
2004-09-16
07 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza
2004-09-16
07 David Kessens [Ballot Position Update] Position for David Kessens has been changed to No Objection from Discuss by David Kessens
2004-09-16
07 Harald Alvestrand
[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

Given the history of this document, it is not enough to hold the document.

His review:

This draft …
[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

Given the history of this document, it is not enough to hold the document.

His review:

This draft is on the right track but has open issues, described in the review.

1) There is no description of what kind of information is "stable", how a
router would decide what is "stable", or even for a human being what
kinds of criteria ought to be applied to select information to be
flooded in accordance with this draft.  (I realize that there are
skilled practitioners who believe that there is no need for refreshes
of unchanged material.  But if the goal is to change the base behavior
of OSPF, rather more explanation for the existing behavior and why it
is reasonable to change it would be required.  The draft states that
it applies only to "stable" information.)

2) The document is inconsistent about whether this is a router behavior
or an interface behavior.  Most of the description indicates that an
originating router decides to flood some information with the "do not
age" bit set.  However, there are multiple references to
"flood-reduction interfaces.  Since a router may not send different
versions of the same LSA on different interfaces, and since the
description of forwarding of LSAs must be insensitive to the DNA bit
(and is correctly described as such), it is not clear what the
interface setting is intended to accomplish.

3) As a minor point, the description of "forced flooding" leaves the
reader to guess what is intended (probably, refresh even when there is
no change at an interval larger than the normal refresh interface.)
This should be explicitly described.
2004-09-16
07 Harald Alvestrand [Ballot Position Update] Position for Harald Alvestrand has been changed to No Objection from Discuss by Harald Alvestrand
2004-09-16
07 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-09-16
07 Harald Alvestrand
[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His review:

This draft is on the right track but has open issues, described in the review.

1) …
[Ballot comment]
Reviewed by Joel Halpern, Gen-ART

His review:

This draft is on the right track but has open issues, described in the review.

1) There is no description of what kind of information is "stable", how a
router would decide what is "stable", or even for a human being what
kinds of criteria ought to be applied to select information to be
flooded in accordance with this draft.  (I realize that there are
skilled practitioners who believe that there is no need for refreshes
of unchanged material.  But if the goal is to change the base behavior
of OSPF, rather more explanation for the existing behavior and why it
is reasonable to change it would be required.  The draft states that
it applies only to "stable" information.)

2) The document is inconsistent about whether this is a router behavior
or an interface behavior.  Most of the description indicates that an
originating router decides to flood some information with the "do not
age" bit set.  However, there are multiple references to
"flood-reduction interfaces.  Since a router may not send different
versions of the same LSA on different interfaces, and since the
description of forwarding of LSAs must be insensitive to the DNA bit
(and is correctly described as such), it is not clear what the
interface setting is intended to accomplish.

3) As a minor point, the description of "forced flooding" leaves the
reader to guess what is intended (probably, refresh even when there is
no change at an interval larger than the normal refresh interface.)
This should be explicitly described.
2004-09-16
07 Harald Alvestrand
[Ballot discuss]
I am willing to be talked out of this because it's a "late surprise" - ie I missed this on the previous round. …
[Ballot discuss]
I am willing to be talked out of this because it's a "late surprise" - ie I missed this on the previous round.
But the review I got (see comment) worries me - in particular the part about no guidelines for deciding what kinds of info it's reasonable to declare "static".
Feedback, please...
2004-09-16
07 Harald Alvestrand [Ballot Position Update] New position, Discuss, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-09-15
07 David Kessens
[Ballot discuss]
Anyways, I still would really like to see some more wording on
applicability of this feature.

1) when to turn it on (how …
[Ballot discuss]
Anyways, I still would really like to see some more wording on
applicability of this feature.

1) when to turn it on (how big does a network need to be that this
  start to make sense?)/when to turn it off,
  is my network really designed properly if I need this ?
2) reason why it is initially turned off by default

This doesn't need to be a lengthy paragraph, however some wording should be
there to address the issues above.
2004-09-15
07 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-09-09
07 Bill Fenner Placed on agenda for telechat - 2004-09-16 by Bill Fenner
2004-09-09
07 Bill Fenner [Note]: 'Back to try to talk to David about his DISCUSS' added by Bill Fenner
2004-06-24
07 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-06-24
07 David Kessens [Ballot Position Update] Position for David Kessens has been changed to Discuss from Undefined by David Kessens
2004-06-24
07 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2004-06-23
07 David Kessens
[Ballot comment]
From the ops directorate (Pekka Savola):

- abstract has been numbered
- specific IPR notices are not allowed in the documents
- non-updated …
[Ballot comment]
From the ops directorate (Pekka Savola):

- abstract has been numbered
- specific IPR notices are not allowed in the documents
- non-updated boilerplates
2004-06-23
07 David Kessens [Ballot Position Update] New position, Undefined, has been recorded for David Kessens by David Kessens
2004-06-23
07 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded for Ted Hardie by Ted Hardie
2004-06-21
07 Steven Bellovin [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin
2004-06-10
07 Bill Fenner
[Note]: 'Already reviewed in 6/2003; please don''t re-review unless showstoppers - want to clear ops-dir comment (see document log, there''s no ballot).  IESG RED TEAM' …
[Note]: 'Already reviewed in 6/2003; please don''t re-review unless showstoppers - want to clear ops-dir comment (see document log, there''s no ballot).  IESG RED TEAM' added by Bill Fenner
2004-06-10
07 Bill Fenner [Ballot Position Update] New position, Yes, has been recorded for Bill Fenner
2004-06-10
07 Bill Fenner Ballot has been issued by Bill Fenner
2004-06-10
07 Bill Fenner Created "Approve" ballot
2004-06-10
07 (System) Ballot writeup text was added
2004-06-10
07 (System) Last call text was added
2004-06-10
07 (System) Ballot approval text was added
2004-06-10
07 Bill Fenner Placed on agenda for telechat - 2004-06-24 by Bill Fenner
2004-06-10
07 Bill Fenner State Changes to IESG Evaluation from AD Evaluation by Bill Fenner
2004-06-10
07 Bill Fenner
[Note]: 'Already reviewed in 6/2003; please don''t re-review unless showstoppers - want to clear ops-dir comment (see document log, there''s no ballot).' added by Bill …
[Note]: 'Already reviewed in 6/2003; please don''t re-review unless showstoppers - want to clear ops-dir comment (see document log, there''s no ballot).' added by Bill Fenner
2004-06-10
07 Bill Fenner State Changes to AD Evaluation from Publication Requested by Bill Fenner
2003-07-03
07 Natalia Syracuse State Changes to Publication Requested from AD is watching by Syracuse, Natalia
2003-06-17
07 Bill Fenner WG has a new version that they would like to Last Call
2003-06-17
07 Bill Fenner State Changes to AD is watching from IESG Evaluation by Fenner, Bill
2003-06-17
07 (System) New version available: draft-pillay-esnault-ospf-flooding-07.txt
2003-06-11
07 Bill Fenner

----- Begin forwarded message:

From: Randy Bush
Subject: draft-pillay-esnault-ospf-flooding-05.txt
Date: Thu, 12 Jun 2003 05:20:46 +0900
To: iesg

ops-dir comment

>    3.1 WG Submissions …

----- Begin forwarded message:

From: Randy Bush
Subject: draft-pillay-esnault-ospf-flooding-05.txt
Date: Thu, 12 Jun 2003 05:20:46 +0900
To: iesg

ops-dir comment

>    3.1 WG Submissions
>      3.1.1 New Item
> ******    o OSPF Refresh and Flooding Reduction in Stable Topologies
>              (Informational)
>             
>              Token: Fenner, Bill

whew.. when I first read this, I thought this was for PS..

==> from an operational point of view, this seems like a totally useless
idea warranting editing or an IESG note, due to:

  * DC circuits spec is from 1995; they are practically dead/useless today,
who cares about the feature?  They're junk in the spec.

  * Now, this spec creates a dependency on DC circuit spec; this is useless
if DC circuit spec is not implemented in all OSPF routers

  * The bandwidth required for flooding a few LSA's every 30 minutes is
minimal.  Why bother with something like this which could lead to a lot of
issues?  OSPF is not BGP; it carries only minimal amount of information,
not the full Internet routing table, and flooding it once in a while is a
very good idea if it gains you even a piece or robustness.

1. Abstract

==> abstract is numbered

3. Changes in the existing implementation.

==> s/.//

6. Security Considerations

    This memo does not create any new security issues for the OSPF
    protocol. Security considerations for the base OSPF protocol are
    covered in [1].

==> uhh, no.  what if you flood LSA's with noage bit, they stick around
forever and are never purged?  I'd guess that changes the OSPF protocol
assumptions quite a bit.  I didn't bother to check how well they were
documented in the OSPF DC circuits doc, but I wouldn't count on it.




----- End forwarded message:
2003-06-11
06 (System) New version available: draft-pillay-esnault-ospf-flooding-06.txt
2003-05-23
07 Bill Fenner Er, that wasn't what I *tried* to do =)
2003-05-23
07 Bill Fenner State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Fenner, Bill
2003-05-23
07 Bill Fenner State Changes to Waiting for AD Go-Ahead from AD Evaluation by Fenner, Bill
2003-03-28
05 (System) New version available: draft-pillay-esnault-ospf-flooding-05.txt
2003-02-14
(System) Posted related IPR disclosure: Cisco's Patent Statement pertaining to OSPF Refresh and Flooding Reduction in Stable Topologies (draft-pillay-esnault-ospf-flooding-nn.txt)
2003-02-04
07 Bill Fenner Bill to review updated draft.
2003-02-04
07 Bill Fenner State Changes to AD Evaluation  :: AD Followup from AD Evaluation  :: Revised ID Needed by Fenner, Bill
2003-01-31
04 (System) New version available: draft-pillay-esnault-ospf-flooding-04.txt
2002-11-04
07 Bill Fenner State Changes to AD Evaluation  :: Revised ID Needed from AD Evaluation  :: External Party by Fenner, Bill
2002-04-17
07 (System) Intended Status has been changed to Informational from Request
2002-03-12
07 (System) See https://irg.attlabs.net/bugzilla/show_bug.cgi?id=13 for detailed comments
2002-03-12
07 (System)
State Changes to New Version Needed (WG/Author)                    from AD Evaluation              …
State Changes to New Version Needed (WG/Author)                    from AD Evaluation                                    by IESG Member
2002-03-12
07 (System)
State Changes to AD Evaluation                                    from Pre AD …
State Changes to AD Evaluation                                    from Pre AD Evaluation                                by IESG Member
2002-02-28
07 (System) Draft Added by IESG Member
2001-03-06
03 (System) New version available: draft-pillay-esnault-ospf-flooding-03.txt
2000-11-30
02 (System) New version available: draft-pillay-esnault-ospf-flooding-02.txt
2000-05-15
01 (System) New version available: draft-pillay-esnault-ospf-flooding-01.txt
1999-11-29
00 (System) New version available: draft-pillay-esnault-ospf-flooding-00.txt