Re: NSSA NP option bit clarification

[[e-mail]]

Paul,

From what I understand, setting that bit in the DD after it is verified in the hello packets is optional. I remember a discussion about that a couple of years ago. I also remember a switching company that didnt carry that bit in their implementation and had incompatibility issues with another switching company (I dont want to name companies and make them look bad or good when they are all actually RFC complient)

Just remember, if the area changes from NSSA to say transit, the new hello packets will have different options carried in them, and therefore the router will not neighbor with the NSSA routers.

Personally, I think it makes more sense if the DD packets match the hello packets in the options field, but I also understand why that is not a requirement.

Hope that helps,

Farshad


-----Original Message-----
From:     Paul Jakma <[e-mail]>
Sent:     Thu, 12 Jun 2003 04:48:40 +0100
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:

- 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      [e-mail]   [e-mail]  Key ID: 64A2FF6A
        warning: do not ever send email to [e-mail]
Fortune:
/usr/news/gotcha