Hi All,

Here's what the updated section 2.2 of the ospf te doc
(draft-katz-yeung-ospf-traffic-07.txt) looks like:

2.2. LSA ID

   The LSA ID of an Opaque LSA is defined as having eight bits of type
   and 24 bits of type-specific data. The Traffic Engineering LSA uses
   type 1. The remaining 24 bits are broken up into eight bits of
   reserved space (which SHOULD be zero on transmission and ignored on
   receipt) and sixteen bits of instance:

      0 1 2 3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | 1 | Reserved | Instance |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Instance field is an arbitrary value used to maintain multiple
   Traffic Engineering LSAs. A maximum of 65536 Traffic Engineering
   LSAs may be sourced by a single system. The LSA ID has no
   topological significance.

The issues are
a) what should the wording regarding the "Reserved" field be?
b) how should TE LSAs received with "illegal" values be treated?
   (for example in the wording as above, how should a TE LSA with
   a non-zero Reserved field be treated)?

One suggestion is to require the "Reserved" field to be zero, much
as John Moy requires the Opaque ID to be zero in a Grace LSA. A
TE LSA received with a non-zero Reserved field is to be treated as
an unknown Opaque LSA (how are unknown Opaque LSAs treated? Dropped?
Flooded?).

Thoughts? Other suggestions?

Kireeti.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]