Re: [CCAMP] [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04

["Yemin (Amy)" <[e-mail]>]

Hi Daniele,

Thanks for comments. I agree with most of them.
Please see my response to some comments inline.

BR,
Amy

________________________________
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

From: Teas [mailto:[e-mail]] On Behalf Of Daniele Ceccarelli
Sent: Saturday, May 28, 2016 5:08 AM
To: Daniele Ceccarelli; CCAMP ([e-mail]); TEAS WG ([e-mail])
Cc: [e-mail]; [e-mail]
Subject: Re: [Teas] Joint WG last call on draft-ietf-ospf-availability-extension-04

Authors,

I did my review of the document. Please find below some comments:


-          Section 1: please put [G.827, F.1703, P.530] in a reference format [G.827] [F.1703][P.530].

-          Section 1: Could you elaborate this sentence? "The availability is a time scale that the requested bandwidth is ensured." The meaning is not fully clear to me.

                [Amy] How about this: "The availability is a time scale, which is a proportion of the operating time that the requested bandwidth is ensured."



-          Section 1: [ASTE] curious acronym choice! Is it correct to have this as a normative reference?

                [Amy] The title of the referenced draft was changed for once. I will update the acronym according to the new title, how about [ETPAI]?



-          Section 1: [RFC4202]: I would say that this is a normative reference, it is reported as informative.

-          Section 1: "   If there is a hop that cannot support the Availability sub-TLV, the Availability sub-TLV should be ignored." This is normative text. It should be written in capital letters and I'd suggest to move it from the intro to section 3. Going on with the reading I see that it is properly state in section 3.2, hence I suggest just dropping the sentence in section 1.

-          Section 1: "...is defined to support in routing signaling." There must be something missing here. What about just "...is defined."?

-          Section 2: s/should contain/should include

-          Section 2: I suggest rephrasing this sentence: " The list provides the information that how much bandwidth a link can support for a specified availability." What about "The list provides the mapping between the link nominal bandwidth and its availability level"?

-          Section 2: s/label switched path/Label Switched Path

-          Section 2: suggested rephrasing

OLD
  To setup a label switching path (LSP), a node may collect link
   information which is spread in OSPF TE LSA messages by network nodes
   to get know about the network topology, calculate out an LSP route
   based on the network topology and send the calculated LSP route to
   signaling to initiate a PATH/RESV message for setting up the LSP.

   Availability information is required to carry in the signaling

   message to better utilize the link bandwidth. The signaling

   extension for availability can be found in [ASTE].


NEW
The setup of a Label Switched Path requires this piece of information to be flooded in the network and used by the nodes or the PCE for the path computation. The computed path can then be provisioned via the signaling protocol.
Availability information also need to be carried by the signaling for a better utilization of the link bandwidth (CAN YOU EXPLAIN WHY?).
Extensions to RSVP-TE can be found in [ASTE].
[Amy] How about the following text:
The setup of a Label Switched Path requires this piece of information to be flooded in the network and used by the nodes or the PCE for the path computation. The computed path can then be provisioned via the signaling protocol.
For links with variable discrete bandwidth, Availability information is need to be carried by the signaling for a better link bandwidth utilization.
Extensions to RSVP-TE can be found in [ETPAI].


-          Section 3.1 - ISCD already expanded in section 1, you can use the acronym.

-          Section 3.1: "Type: TBA by IANA, suggested value is 0x01"

-          Section 3.1: "Length" you should state the units (bit? Bytes?). Moreover I see this is a fixed length TLV, hence I would say: "Length: A 16 bits field that expresses the length of the TLV in bytes"

-          Section 3.1: "Availability level": is there a discrete set of availability levels? E.g. 0.99, 0.999, 0.9999, or it can be filled with any number between O and 1? This needs to be explained a bit better.

[Amy] There's no concrete discrete set of  availability levels. 0.99, 0.999, 0.9999 is the most common usage, 0.995 may also be used. However numbers such as 0.996/0.997 are rarely used.

I can add one sentence to explain more: "The Availability level is usually expressed in the value of  0.99/0.999/0.9999/0.99999 ".



-          LSP bandwidth at availability level: the unit is missing.

-          3.2 Why signaling process? It would rather say "Processing Procedures" ?

-          Section 4: Please add a reference to the OSPF and GMPLS security RFCs.

-          IANA section: Please make sure that it is state which registry needs to be updated and how.

-          References: there is a number of references that is not used in the document e.g. RFC 2210, RFC 3473 and so on.

-          Header: "OSPF -- Availability extension" please remove the dashes. I also suggest to substitute with "Availability extensions to OSPF-TE".

-          Please also check the IdNits


Thanks
Daniele


From: Daniele Ceccarelli [mailto:[e-mail]]
Sent: giovedì 12 maggio 2016 10:25
To: CCAMP ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>; TEAS WG ([e-mail]<mailto:[e-mail]>) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Joint WG last call on draft-ietf-ospf-availability-extension-04

CCAMP, TEAS,

This starts a two weeks joint working group last call on draft-ietf-ccamp-ospf-availability-extension-04
The last call end on Wednesday May 26th. Please send your comments to both the CCAMP and TEAS mailing lists.

All the IPR declarations from authors and contributors have been collected and can be found in the history of the document: https://datatracker.ietf.org/doc/draft-ietf-ccamp-ospf-availability-extension/history/
Please note that no IPR was disclosed against this draft.

As usual this is also a call for shepherd. If anyone is willing to be the shepherd of the document, please volunteer.



Thanks

Daniele, Fatai, Lou, Pavan