Re: NSSA NP option bit clarification

[Acee Lindem <[e-mail]>]

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.



Sina Mirtorabi wrote:
> Paul,
>
> ->-----Original Message-----
> ->From: Mailing List [mailto:[e-mail]] On
> ->Behalf Of Paul Jakma
> ->Sent: Wednesday, June 11, 2003 8:49 PM
> ->To: [e-mail]
> ->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      [e-mail]   [e-mail]  Key ID: 64A2FF6A
> ->        warning: do not ever send email to [e-mail]
> ->Fortune:
> ->/usr/news/gotcha
> ->
>


--
Acee