Re: WG Last Call for "Extensions to OSPF for Advertising Optional Router"

[Adrian Farrel <[e-mail]>]

Hi,

I have some comments about this draft (which I support).

Section 1.
It is premature to cite this technique as a method for PCS discovery (by
the way, the term is now PCE not PCS). The need for *any* discovery
technique is still an item for the PCE working group. Assuming a need is
derived, the mechanism would still be up to the PCE working group.
While the PCE WG may choose to use the mechanism defined in this draft to
discover PCEs, this draft MUST NOT prejudge this item.
Therefore, please remove all reference to PCS from the first bullet of
section 1.

[Actually, I would suggest streamlining the draft by striking the whole
first paragraph (and both bullets) of section 1.]


Section 2.
   "If a
    router does not advertise this LSA, it does not imply that the router
    does not support one or more of the defined capabilities."
Surely this is an issue for the RFC/I-D that defines each option TLV, and
in the case of the OSPF Router Capabilities TLV it is an issue for the
RFC/I-D that defines each option bit?
What your current text does is prevent future uses of this LSA from
identifying unambiguously whether a router supports a specific new
function.

[See draft-ietf-mpls-rsvpte-attributes for handling of this issue in
RSVP-TE signaling.]


Section 2.
  "The Router Information LSA will have an Opaque type of 4 and Opaque
   ID of 0."
Present tense, please.

Section 2.1
  "The first defined TLV in the body of an RI opaque LSA is the Router
   Capabilities TLV."
I suspect this means exactly what it says, but it will be misinterpretted!
It will be assumed to mean that the first TLV in the LSA MUST be the
Router Capabilities TLV.
Is it relevant that this is the first TLV to be defined?
OTOH, you should state clearly if there are any oredering rules about
TLVs.

You go on to say...
  "A router advertising an RI opaque LSA SHOULD
   include the Router Capabilities TLV..."
Why is this "SHOULD" not "MUST"? If there are valid reasons to leave it
out, then it is not even as strong as "SHOULD".

Section 2.1
  "   Length   A 16 bit field that indicates the length of the value
               portion in bytes.  Its set to N x 4 octets.  N starts
               from 1 and can be increased when there is a need.  Each 4
               octets are referred to as a capability flag."
This text is confused!
- Either talk about bytes or octets
- s/Its/It's/
- "N x 4 octets" is open to easy misinterpretation. Should we fill in the
value N?
   Don't you mean that the length field must be a multiple of four?
- "N starts from 1" means that the minimum valid length is four. Why not
say this?
- Why is it relevant that "N can be increased where there is a need"?
- It is unusual to refer to a collection of 32 bits as a single flag.
Surely each bit is a flag?
  I don't think it is helpful to consider these blocks of flags. Don't you
just have an
  endless stream of defined capabilities bits encoded in a value that is
rounded up to
  32 bits by the insertion of undefined bits?

Section 2.1
  "   Value    This comprises one or more capability flags.  For each 4"
The figure shows a field called "Capabilities" not "Value".

Section 2.1
  "The Router Capabilities TLV MAY be followed by optional TLV's that
   further specify a capability."
Now, *this* seems to say that the RC TLV might be expected to be first.

Section 2.2
You should not list the bits defined in other documents.
I assume that you would like this I-D to become an RFC sometime soon!
I think that what you are trying to do is provide a pre-IANA registry. Get
the WG chairs to put this on the Routing Area web pages or the OSPF WG
pages.

In any case, please do not define a bit for PCE discovery in this I-D (see
my first point).

I am also worried by the definition of four reserved bits. I assume that
these are reserved because of some proprietary or old usage. Why is it
necessary to have reserved bits in the first version of an RFC?

Section 2.3
   type 11 (AS-scoped) opaque LSA may be flooded.  If a type 11 opaque
   LSA is chosen, the originating router should also advertise type 10
   LSA(s) into any attached NSSA/stub area(s).  An OSPF router MAY
s/should/SHOULD/


Section 2.3
  "TLV flooding
   scope rules will be specified on a per-TLV basis."
What does this actually mean?
I don't find a per-TLV flooding scope definition for the RC TLV.
Are you saying that the definition of a TLV in a separate document MUST
specifiy how the TLV will be flooded and that the flooding of a particular
TLV may vary despite the flooding scope of the LSA in which it is carried?
Or are you saying that the definition of each TLV must state for which LSA
scope flooding the TLV is valid?
If the latter, you need to add this information point to the IANA tracking
in section 5.


Scetion 5.
The IANA section is far from complete. You can't expect IANA to trawl the
draft for the values you have defined.
Are you asking IANA to manage the allocation of RC TLV bits?
Do you also need to specify that the assignment of bits in the RC TLV is
subject to OSPF WG review?


Section 6.2
[OPAQUE] should be normative


Cheers,
Adrian