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

From: Acee Lindem <[email-masked]>
Date: Fri, 7 Jan 2005 22:31:00 -0500

This the start of  the  Working Group Last Call for "Extensions to OSPF for
Advertising Optional Router" - draft-ietf-ospf-cap-05.txt.
All comments must be sent to the OSPF list by 12:00 AM EST on Monday,
January 24, 2005.

A URL for this Internet-draft is provided below:

http://www.ietf.org/internet-drafts/draft-ietf-ospf-cap-05.txt

Thanks,
Acee

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 13 Jan 2005 11:43:45 -0000

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

---

From: dimitri papadimitriou <[email-masked]>
Date: Thu, 13 Jan 2005 14:23:54 +0100

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:

> .

---

From: Acee Lindem <[email-masked]>
Date: Mon, 17 Jan 2005 23:47:35 -0500

Hi Adrian,

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

>first paragraph (and both bullets) of section 1.]
I've discussed with JP and I will make some modifications here.

>identifying unambiguously whether a router supports a specific new
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

I'll take a look this draft.

>  "The Router Information LSA will have an Opaque type of 4 and Opaque

Will fix.

>out, then it is not even as strong as "SHOULD".
Will discuss with the other authors. My take is that this is a "MUST".

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

>The figure shows a field called "Capabilities" not "Value".

Ok,

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

>In any case, please do not define a bit for PCE discovery in this I-D (see

Ok.

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

>scope flooding the TLV is valid?
The latter.

>If the latter, you need to add this information point to the IANA tracking

Ok.

>draft for the values you have defined.
Ok - will beef up.

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

>subject to OSPF WG review?
Yes.

>[OPAQUE] should be normative

Ok.

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 18 Jan 2005 13:09:35 -0000

Thanks Acee,

All of your responses look good.

Comments in line.

Adrian

> AFAIK, there is no proprietary usage of these bits. They are simply

Then shall we make them unassigned?
That is, available for IANA to assign for other uses.

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

Why not? (It was a loaded question :-)

How will you track which bits have been allocated and make sure that we
don't get two RFCs using the same bit for different purposes?