Subject: [fwd] Re: new OSPFv2 I-D

From: Paul Ferguson <[email-masked]>
Date: Fri, 07 Nov 1997 16:59:52 -0500

Of minor interest, I believe, to both the intserv
differential services effort, as well as the qosr
working group.

Apologies for any dupes.

- paul

>Date: Fri, 07 Nov 1997 15:04:13 -0500
>From: "John T. Moy" <[email-masked]>
>Reply-To: [email-masked]
>Organization: Cascade Communications Corp.
>X-Mailer: Mozilla 4.02 [en] (Win95; I)
>To: Paul Ferguson <[email-masked]>
>CC: John Moy <[email-masked]>, [email-masked],
>        [email-masked]
>Subject: Re: new OSPFv2 I-D
>
>Paul-
>
>Yes, that's right. I forgot to mention that the third
>major change in RFC 2178 was the removal of TOS support.
>It stays removed in the new OSPFv2 spec. There have been a few
>people with revived interest in OSPF TOS routing, and you
>may see a new document containing only the TOS stuff. If so,
>that document will probably be labeled "experimental", and
>will definitely be kept separate from the base OSPFv2 spec.
>
>John
>
>Paul Ferguson wrote:
>
>> John,
>>
>> Is it also the case the the TOS support has been deprecated?
>>
>> Thanks,
>>
>> - paul
>>
>> At 05:59 PM 11/6/97 -0500, John Moy wrote:
>>
>> >Hi. As you probably noticed, I just posted a new OSPFv2 Internet Draft.
>> >The reason is as follows. Six months ago we tried to advance
>> >OSPFv2 to Full Standard. However, since we had added major
>> >features (Point-to-Multipoint, cryptographic authentication),
>> >we were instead required to republish at the same level (Draft
>> >Standard) until a waiting period expired.
>> >
>> >Well, the waiting period has now expired, and I thought that
>> >we'd take one last shot at modifying the text before it goes
>> >to Full Standard. This logic resulted in
>> ><draft-ietf-ospf-vers2-00.txt>.
>> >
>> >This is a Working Group last call for that document. Unless we receive
>> >comments by Monday, 12/15 (right after IETF), we will submit
>> ><draft-ietf-ospf-vers2-00.txt> to the IESG requesting that it
>> >replace RFC2178.
>> >
>> >Two small functional changes were made in the document, both to
>> >the flooding algorithm in Section 13. The best explanation of these
>> >changes can be found in Section G.1 of the document, which is
>> >included below:
>> >
>> >    G.1        Flooding modifications
>> >
>> >       Two small changes have been made to the flooding procedure in
>> >       Section 13. First, upon receiving a MaxAge LSA that has no
>> >       database copy, requests for equal or previous instances of the
>> >       LSA should be removed from all neighbors' Link State Request
>> >       Lists, instead of just the sending neighbor's Link State Request
>> >       List (see Step 4b in Section 13). Failure to do so could cause
>> >       the Database Exchanges with the other neighbors to restart,
>> >       because of the check in step 6 of Section 13.
>> >
>> >       The second change is to step 8 in Section 13. Confusion between
>> >       routers as to which LSA instance is more recent can cause a
>> >       disastrous amount of flooding in a link-state protocol (see
>> >       [Ref26]). OSPF guards against this problem in two ways: a) the
>> >       LS age field is used like a TTL in flooding, to eventually
>> >       remove looping LSAs from the network (see Section 13.3), and b)
>> >       routers refuse to accept LSA updates more frequently than once
>> >       every MinLSArrival seconds (see Section 13).  However, there is
>> >       still one case in RFC 2178 where disagreements regarding which
>> >       LSA is more recent can cause a lot of flooding traffic:
>> >       responding to old LSAs by reflooding the database copy.  For
>> >       this reason, Step 8 of Section 13 has been amended to only
>> >       respond with the database copy when that copy has not been sent
>> >       in any Link State Update within the last MinLSArrival seconds.
>> >
>> >The other changes were all clarififications that various people
>> >have requested:
>> >
>> >o Retransmissions on point-to-point links are sent
>> >  to ALLSPFRouters, while on other links are sent to the neighbor's
>> >  IP address (Sections 8.1, 13.5, 13.6, A.3.5).
>> >
>> >o In premature aging, you leave the LS Sequence Number of the LSA
>> >  alone, just setting the LS age to MaxAge (Section 14.1).
>> >
>> >o In Dijkstra, vertex is identified by combination of type and ID
>> >  (Section 16.1).
>> >
>> >o Retransmitted Link State Request packets should be built from
>> >  scratch (Section 10.9).
>> >
>> >o While equal-costs paths may have separate Advertising Routers,
>> >  they don't have to (Section 16.8).
>> >
>> >Thanks,
>> >John
>> >
>> >
>