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

[Acee Lindem <[e-mail]>]

Hi Adrian,

Thanks for your comments. I will post another revision for WG review. 
See responses below.

Adrian Farrel wrote:

>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.]
>  
>
I've discussed with JP and I will make some modifications here.


>
>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.
>  
>
It is not meant to do this. It is meant to allow existing capabilities 
to be advertised for informational
purposes while allowing new capabilities to make use of this LSA as the 
sole mechanism for
advertisement. I'll look into rewording.


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

I'll take a look this draft.

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

Will fix.

>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".
>  
>
Will discuss with the other authors. My take is that this is a "MUST".

>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?
>  
>
Will look at rewording - we always have wanted the flags to be added in 
increments of 4 octets.


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

Ok,

>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.
>  
>
Again, my take is that the RC TLV should be required.

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

Ok.

>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?
>  
>
AFAIK, there is no proprietary usage of these bits. They are simply 
reserved.

>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?
>  
>
The latter.

>If the latter, you need to add this information point to the IANA tracking
>in section 5.
>  
>

Ok.

>
>Scetion 5.
>The IANA section is far from complete. You can't expect IANA to trawl the
>draft for the values you have defined.
>  
>
Ok - will beef up.

>Are you asking IANA to manage the allocation of RC TLV bits?
>  
>
No.

>Do you also need to specify that the assignment of bits in the RC TLV is
>subject to OSPF WG review?
>  
>
Yes.

>
>Section 6.2
>[OPAQUE] should be normative
>  
>

Ok.

>
>Cheers,
>Adrian
>
>  
>