Re: NSSA NP option bit clarification

[Sina Mirtorabi <[e-mail]>]

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
->