Subject: NSSA NP option bit clarification

From: Paul Jakma <[email-masked]>
Date: Thu, 12 Jun 2003 04:48:40 +0100

hi,

I have a question regarding the use of the NP bit in the options
field, specifically with respect to its use in the Database
Description header.

From RFC3101, Appendix A, The NP bit is used in:

options field in Hello, DD and Type-7 LSAs. Its use is described as:

- Hello header, to indicate whether router is Type7 capable. (N bit
semantics)

- Type-7 LSA, to indicate whether the LSA should or should not be
translated to Type-5, default is clear. (P bit semantics)

The usage in the DD header options field is not specified. Hence one
presumes OSPFv2 semantics hold, DD options must match Hello options
(ie current neighbour state wrt to options, but change in options
usually results in neighour state going back to at least ExStart,
iirc).

However, we have noticed in testing that there is an OSPF
NSSA implementation from a major vendor which does /not/ set the P
bit in the DD header, even though N bit in Hello and in neighbour
state is set, and it is sending Type-7 LSAs.

Is there an explanation for this? Or is this implementation wrong?

(at the moment we have hacked the implementation we have tested,
zebra ospfd, against this vendor's implementation to simply set the
NP bit in the DD header if N bit is set in neighbour-state to allow
the DD to be processed, as zebra ospfd will otherwise drop DD packets
where DD options do not match current neighbour state.)

thanks in advance.

regards,
--
Paul Jakma      [email-masked]   [email-masked]  Key ID: 64A2FF6A
        warning: do not ever send email to [email-masked]
Fortune:
/usr/news/gotcha

---

From: Sina Mirtorabi <[email-masked]>
Date: Thu, 12 Jun 2003 09:25:36 -0700

Paul,

->-----Original Message-----
->From: Mailing List [mailto:[email-masked]] On
->Behalf Of Paul Jakma
->Sent: Wednesday, June 11, 2003 8:49 PM
->To: [email-masked]
->Subject: NSSA NP option bit clarification
->
->
->hi,
->
->I have a question regarding the use of the NP bit in the
->options field, specifically with respect to its use in the
->Database Description header.
->
->>From RFC3101, Appendix A, The NP bit is used in:
->
->options field in Hello, DD and Type-7 LSAs. Its use is described as:

Could you indicate where it says so?
Actually it says that the "option fields" is present in Hello, DD and
LSA

->
->- Hello header, to indicate whether router is Type7 capable. (N bit
->semantics)
->
->- Type-7 LSA, to indicate whether the LSA should or should
->not be translated to Type-5, default is clear. (P bit semantics)
->
->The usage in the DD header options field is not specified.

Appendix A, RFC 3101
-----
N-bit:        The N-bit describes the router's NSSA capability.  The N-
              bit is ##used only in Hello packets## and ensures that all
              members of an NSSA agree on that area's configuration.
              When the N-bit is set in the Hello packet that is sent out
              a particular interface, it means that the router will send
              and receive Type-7 LSAs on that interface.  Two routers
              will not form an adjacency unless they agree on the state
              of the N-bit.  If the N-bit is set in the options field,
              the E-bit must be clear.

P-bit:        The P-bit is ##used only in the Type-7 LSA header##.  It
flags
              the NSSA border router to translate the Type-7 LSA into a
              Type-5 LSA.  The default setting for the P-bit is clear.
-----

Above implies that N/P bit is not used in DD packet

->Hence one presumes OSPFv2 semantics hold, DD options must
->match Hello options

The above presumption is not correct

->(ie current neighbour state wrt to
->options, but change in options usually results in neighour
->state going back to at least ExStart, iirc).

Change in the option _during_ DD exchange result to going back to
Exstart and not if there is a mismatch between Hello and DD Option

->
->However, we have noticed in testing that there is an OSPF
->NSSA implementation from a major vendor which does /not/ set
->the P bit in the DD header, even though N bit in Hello and in
->neighbour state is set, and it is sending Type-7 LSAs.

As mentioned before and according to RFC 3101, N/P bit is Not used for
DD packet so the presence / absence of this bit in DD option packet
should be ignored

Sina

->
->Is there an explanation for this? Or is this implementation wrong?
->
->(at the moment we have hacked the implementation we have
->tested, zebra ospfd, against this vendor's implementation to
->simply set the NP bit in the DD header if N bit is set in
->neighbour-state to allow the DD to be processed, as zebra
->ospfd will otherwise drop DD packets where DD options do not
->match current neighbour state.)
->
->thanks in advance.
->
->regards,
->--
->Paul Jakma      [email-masked]   [email-masked]  Key ID: 64A2FF6A
->        warning: do not ever send email to [email-masked]
->Fortune:
->/usr/news/gotcha
->

---

From: Acee Lindem <[email-masked]>
Date: Thu, 12 Jun 2003 17:09:13 -0400

I'm not sure why this N bit/Hello text was introduced for NSSA. It seems
rather odd since one would want a neighbor exchange to start over if
the area type changes to/from NSSA. RFC 2328 does say the analogous
E bit should be set in the DD description options (from section 10.8):

         The router's optional OSPF capabilities (see Section 4.5) are
         transmitted to the neighbor in the Options field of the Database
         Description packet.  The router should maintain the same set of
         optional capabilities throughout the Database Exchange and
         flooding procedures.  If for some reason the router's optional
         capabilities change, the Database Exchange procedure should be
         restarted by reverting to neighbor state ExStart.  One optional
         capability is defined in this specification (see Sections 4.5
         and A.2). The E-bit should be set if and only if the attached
         network belongs to a non-stub area. Unrecognized bits in the
         Options field should be set to zero.

 From a position of hindsight, there should be three separate options
definitions: one for LSA options, one for hello options, and one for
DD options. Or, better yet, the options should be stored in the neighbor
structure during hello processing and not even included in the DD packet.

--
Acee

---

From: Paul Jakma <[email-masked]>
Date: Thu, 19 Jun 2003 01:09:49 +0100

Hi Sina,

> P-bit:        The P-bit is ##used only in the Type-7 LSA header##.  It

ok. that makes it quite clear -> N bit works similarly to E in Hello
packets. What was confusing me was that state of E is usually also
held in DD options.

thank you for clearing up my misunderstanding, and thank you to the
others who also replied with informative comment!

regards,
--
Paul Jakma      [email-masked]   [email-masked]  Key ID: 64A2FF6A
        warning: do not ever send email to [email-masked]
Fortune:
Before Xerox, five carbons were the maximum extension of anybody's ego.