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

[dimitri papadimitriou <[e-mail]>]

hi adrian, all,

1. concerning the comment on section 2.2 if the bits remain defined in 
this document - then as bit 7 references only TE (RFC 3630) i think 
there is a value in defining a specific bit for the support of the GMPLS 
OSPF-TE extensions support (hint: this should not mean that bit 7 is for 
MPLS-TE and the latter (the proposed new bit) for non-MPLS TE, as GMPLS 
extensions defines a superset of MPLS-TE)

2. would it be possible to clarify the following statement "For
existing OSPF capabilities, this advertisement will be used primarily 
for informational purposes." it appears both in section 1. and 2.

thanks,
- dimitri.


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