ietf
[Top] [All Lists]

Gen-ART review of draft-ash-gcac-algorithm-spec-03.txt

2012-01-05 10:51:41
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ash-gcac-algorithm-spec-03.txt
Reviewer: Kathleen M. Moriarty
Review Date: 1/4/12
IETF LC End Date: 1/11/12
IESG Telechat date: 1/19/12

Summary:  The draft is essentially ready with nits.  The last nit could be a 
minor issue, but has a simple resolution.  The security considerations section 
points out possible attacks and should also require logging of events tied to 
the users/groups responsible for those actions.

Major issues:

Minor issues:

Nits/editorial comments:
The last line of the abstract should be on the previous line.

On the second to last paragraph of page 8, the following acronym is listed: 
emergency traffic (ETS), should there be something for the "S"?
The second to last sentence of the same paragraph:
Consider changing from:
"Several
   assured forwarding (AF) queues may be used for various data traffic,
   for example, premium private data traffic, premium public data
   traffic, and a separate best-effort queue is used for the best-effort
   traffic."
To: "Several
   assured forwarding (AF) queues may be used for various data traffic,
   for example, premium private data traffic, premium public data
   traffic, and a separate best-effort queue for the best-effort
   traffic."

First paragraph of section 3: Consider removing "however", it doesn't add 
anything:
Change from: "Requiring nodes to expose detailed and
   up-to-date CAC information, however, may result in unacceptably high
   rate of routing updates."
To: "Requiring nodes to expose detailed and
   up-to-date CAC information may result in unacceptably high
   rate of routing updates."

Second paragraph of Section 3: Consider removing "and cannot" - it is 
unnecessary:
Change from: "This common
   interpretation is in the form of an MPLS GCAC algorithm to be
   performed during MPLS LSP path selection to determine if a link or
   node can or cannot be included for consideration."
To: "This common
   interpretation is in the form of an MPLS GCAC algorithm to be
   performed during MPLS LSP path selection to determine if a link or
   node can be included for consideration."

Section 3.2: Consider breaking the first sentence into two:
"The assumption behind the MPLS GCAC is that the ratio between BWMck,
   which represents the safety margin the node is putting above the
   SBWck, and the standard deviation of the SBWck defined below does not
   change significantly as one new aggregate flow is added on the link."

Security Considerations:
I think a requirement for logging should be specified here as well.  If an 
attack were to occur, you will want the user/group and actions taken to be 
logged to trace the attack.  Without this, the other enforcement mechanisms are 
inadequate.

Sentence that spans page 17-18 should be broken into multiple sentences 
(readable, but long - as is the following sentence):
"For
   example, if aggregate flow requests are made for CT LSP bandwidth
   that exceeds the current DSTE tunnel bandwidth allocation, the GEF
   initiates a bandwidth modification request on the appropriate LSP(s),
   which may entail increasing the current LSP bandwidth allocation by a
   discrete increment of bandwidth denoted here as DBW, where DBW is the
   additional amount needed by the current aggregate flow request."

There is an extra line in the second line of A.1.



Thanks,
Kathleen

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>