Subject: Re: Some comments on RFC2740

From: Vishwas Manral <[email-masked]>
Date: Fri, 29 Oct 2004 04:16:19 -0700

Hi Acee,

One that comes to my mind is "Link-local unicast addresses are assigned
from the IPv6 address range FF80/10" should be "FE80/10".

Thanks,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[email-masked]] On Behalf Of Nic
Neate
Sent: Friday, October 29, 2004 3:46 PM
To: [email-masked]
Subject: Some comments on RFC2740

Acee and all,

We've recently been implementing RFC2740, and seeing as you've just put
a
re-spin of it on the agenda for Washington, I thought this might be a
good
time for a few comments.  Please let me know what you think, and if I've
misunderstood anything.

Unrecognized LSAs in Database Description packets
-------------------------------------------------

RFC2740 section 3.2.2 states that processing received Database
Description
packets is unchanged from RFC2328 section 10.6.

RFC2328 section 10.6 states that if a Database Description is received
that
contains an unrecognized LSA type, the adjacency is torn down:

                  For each LSA listed, the LSA's LS type is checked for
        validity.  If the LS type is unknown (e.g., not one of the LS
        types 1-5 defined by this specification), or if this is an AS-
        external-LSA (LS type = 5) and the neighbor is associated with a
        stub area, generate the neighbor event SeqNumberMismatch and
        stop processing the packet.

This does not fit with the OSPFv3 procedures for processing unrecognized
LSAs according to the U-, S1- and S2-bits in their LS type.  I think the
rules for which LSA types to accept in Database Descriptions should be
the
same as those for Link State Updates (section 3.5.1 of RFC2740).

Note that there may be a backwards compatibility issue here.  An
implementation behaving as I've described will fail database exchange
with a
strict implementation of the current RFC2740.  However, in reality I
expect
that all good implementations already allow unrecognized LSAs in
Database
Description packets, which is clearly in the spirit of RFC2740.

Receiving Link State Update packets
-----------------------------------

RFC2740 section 3.5.1 states that an LSA received in a Link State Update
should be discarded if
-  the LS type us unknown, and
-  the area has been configured as a stub area, and
-  either the LSA's flooding scope is set to "AS flooding scope" or the
U-bit of the LS type is set to 1 (flood even when unrecognized)

This is intended to generalize the IPv4 behavior, where AS-external-LSAs
are
not flooded into/throughout stub areas.  However, a strict adherence to
those rules will cause you not to discard an AS-external-LSA in a stub
area,
because the LS type is recognized.  I suggest that the rule is reworded
along the following lines.

   Discard the LSA and get the next one from the Link State
   Update packet if
   -  the area has been configured as a stub area, and
   -  the LSA has AS flooding scope, and
   -  either the LS type is recognized or the U-bit of the LS
      type is set to 1 (flood even if unrecognized).

NSSAs, the R-bit and the V6-bit
-------------------------------

It has already been noted several times on this list that the RFC isn't
entirely clear in these areas.  I think it would be well worth a re-spin
of
the RFC to create a permanent record of the clarifications proposed.

Thanks,

Nic

---

From: Acee Lindem <[email-masked]>
Date: Fri, 29 Oct 2004 08:00:55 -0400

Vishwas,
This one was brought up long enough ago that I  didn't have it
in my list (I think I sent a write to the RFC editor for rfc-errata
but I see it never got added to the errata for RFC 2740).

Thanks,
Acee
----- Original Message -----
From: "Vishwas Manral" <[email-masked]>
To: <[email-masked]>
Sent: Friday, October 29, 2004 7:16 AM
Subject: Re: Some comments on RFC2740

Hi Acee,

Thanks,
Vishwas

-----Original Message-----

Acee and all,

Thanks,

Nic