Re: NSSA NP option bit clarification

[Acee Lindem <[e-mail]>]

Hi Paul,

[e-mail] wrote:
> 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)

This is correct. I checked RFC 2328 and the only requirement is that the
options carried in DD packets do not change during the database exchange.
There no checking to assure the options match the area configuration or the
options in the hello packet.

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

I agree. I set the NSSA options in both the hello and DD packets.

> but I also understand why that is not a requirement.

I'm sure I do. They both describe the same set of options
as described in appendix A.2. I think this may have been an
oversight.

Thanks,
Acee

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


--
Acee