Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks
RFC 6601

[Ballot comment]
Agree with Robert's points in his discuss. I also found this document in general difficult to read, and hard to convince myself that it actually works as expected.

[Ballot comment]
The document calls out VOIP as an example of traffic that might be used
as an input to this algorithm, but the current language implies it's the
ONLY traffic that's expected, and that the only things generating that
traffic will be IP/PBXs and SIP/RTP end devices. Please make it clear
that this traffic is only a motivational example.

The interoperability issue exposed at the top of page 11 deserves more
discussion. What goes wrong when different administrative domains use
different constraint models? Are there symptoms that can be observed
to know that somethings going wrong? Can the document make a stronger
statement about the appropriate configuration of a experimental test bed?

This sentence needs clarification: "Let DBWi be the additional bandwidth
capacity needed to carry the flow with aggregate bandwidth DBWi." As written
it defines a term in terms of itself.

I'm skeptical of the brevity of the security consideration section, but yield
to the shepherd to double-check that there is nothing beyond the marking of
emergency traffic to discuss.

[Ballot discuss]
(Updated to add point 3 below)

The document says that the algorithm might have negative effects on live
deployments (by implication, up to and including failing to complete an
emergenc call) but then says experimentation in production networks needs
to be treated with caution. Was "experimentation in production networks
is NOT RECOMMENDED", or even "expereiments MUST NOT be performed on production
networks" considered and rejected? If so, can the document explain why?
(Related - can the document explain what experimenting "in a controlled
manner" means?)

The security consideration section's discussion of the risks of using
possibly unprotected marks to identify emergency traffic should
incorporate or reference the related discussion from ECRIT and (if I
remember correctly) the RSVP document suite. This is much harder
problem than the current text signals.

Example A.2 needs to be updated to reflect that NSIS has concluded.

[Ballot comment]
The document calls out VOIP as an example of traffic that might be used
as an input to this algorithm, but the current language implies it's the
ONLY traffic that's expected, and that the only things generating that
traffic will be IP/PBXs and SIP/RTP end devices. Please make it clear
that this traffic is only a motivational example.

The interoperability issue exposed at the top of page 11 deserves more
discussion. What goes wrong when different administrative domains use
different constraint models? Are there symptoms that can be observed
to know that somethings going wrong? Can the document make a stronger
statement about the appropriate configuration of a experimental test bed?

This sentence needs clarification: "Let DBWi be the additional bandwidth
capacity needed to carry the flow with aggregate bandwidth DBWi." As written
it defines a term in terms of itself.

I'm skeptical of the brevity of the security consideration section, but yield
to the shepherd to double-check that there is nothing beyond the marking of
emergency traffic to discuss.

[Ballot discuss]
The document says that the algorithm might have negative effects on live
deployments (by implication, up to and including failing to complete an
emergenc call) but then says experimentation in production networks needs
to be treated with caution. Was "experimentation in production networks
is NOT RECOMMENDED", or even "expereiments MUST NOT be performed on production
networks" considered and rejected? If so, can the document explain why?
(Related - can the document explain what experimenting "in a controlled
manner" means?)

The security consideration section's discussion of the risks of using
possibly unprotected marks to identify emergency traffic should
incorporate or reference the related discussion from ECRIT and (if I
remember correctly) the RSVP document suite. This is much harder
problem than the current text signals.

[Ballot comment]
1) VARk = BWMck**2/VFck could be mis-read, suggest adding
parenthesis or using another couple of lines like eq(2).

2) Surely there's a DoS vector here too - couldn't someone in
principle provide bad inputs so that the algorithm denies service?
Not sure how best to note that, but I'd say its worth a mention in
the security considerations.

[Ballot comment]
As with all Experimental specifications, it would be nice to define some parameters for the experiment (success criteria, guidelines for those who implement and deploy the technology, etc.).

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Subject: Last Call:  (Generic Connection Admission Control (GCAC) Algorithm Specification for IP/MPLS Networks) to Experimental RFC


The IESG has received a request from an individual submitter to consider
the following document:
- 'Generic Connection Admission Control (GCAC) Algorithm Specification
  for IP/MPLS Networks'
  as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-01-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document presents a generic connection admission control (GCAC)
  reference model and algorithm for IP/MPLS-based networks.  Service
  provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for
  example, to reject voice over Internet Protocol (VoIP) calls when
  additional calls would adversely affect calls already in progress.
  Without MPLS GCAC, connections on congested links will suffer
  degraded quality.  The MPLS GCAC algorithm can be optionally
  implemented in vendor equipment and deployed by service providers.
  MPLS GCAC interoperates between vendor equipment and across multiple
  service provider domains.  The MPLS GCAC algorithm uses available
  standard mechanisms for MPLS based networks, such as RSVP, DSTE, PCE,
  NSIS, DiffServ, and OSPF.  The MPLS GCAC algorithm does not include
  aspects of CAC that might be considered vendor proprietary
  implementations, such as detailed path selection mechanisms.  MPLS
  GCAC functions are implemented in a distributed manner to deliver the
  objective QoS for specified QoS constraints.  The objective is that
  the source is able to compute a source route with high likelihood
  that MPLS GCAC via elements along the selected path will in fact
  admit the request.  In some cases (e.g., multiple AS) this objective
  cannot always be met, but the document summarizes methods that
  partially meet this objective.  MPLS GCAC is applicable to any
  service or flow that must meet an objective QoS (delay, jitter,
  packet loss rate) for a specified
  quantity of traffic.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ash-gcac-algorithm-spec/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ash-gcac-algorithm-spec/


No IPR declarations have been submitted directly on this I-D.

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
Here are my comments on your draft. It is well written and clear and my comments are relatively small. The most important is more of a geopolitical issue than a technical one, but I think it has to be addressed.

I will put the I-D into "revised I-D needed" state. When you post a new revision I will get kicked automagically and will start the IETF last call.

Cheers,
Adrian

---

I am missing some discussion of why this is Experimental, how the
experiment may be conducted (and constrained), and how we will judge
the experiment. This would belong at the bottom of Section 1. I suggest
something like the following (although you may munge the text as you
like).

  This document is Experimental. It is intended that service providers
  and venders experiment with the GCAC concept and the algorithm
  described in this document in a controlled manner to determine the
  benefits of such a mechanism. The results of such experiments may
  be fed back to the IETF community to refine this document and to
  move it to the Standards Track (probably within the MPLS working
  group) if the experimental results are positive.

  It should be noted that the algorithm might have negative effects on
  live deployments if the experiment is a failure. Effects might include
  blocking traffic that would normally be handled, or by allowing
  excessive traffic on a link. For these reasons, experimentation in
  production networks needs to be treated with caution.

---

There are a number of terms in the Legend to Figure 1 that don't appear
in the figure. Is this correct?

  BW: bandwidth
  COS: class of service
  GCF: GCAC core function
  I/F: interface
  MAR: maximum allocation with reservation

---

Section 2.1 omits the context that some of the parameters apply to the
specific flow/LSP being calculated, and some apply to the calculation
method.

---

Section 2 says:

  Figure 1 illustrates the GEF to GEF MPLS GCAC algorithm to determine
  whether there is sufficient bandwidth to complete a connection.

I think that figure 1 is a reference model for MPLS GCAC

---

Section 2.2

  2. Use [BGP-TE] to advertise ULBCck parameters via BGP to the
  originating GEF for the full topology of adjacent domains/areas/AS's.
  In this manner the originating GEF can implement the MPLS GCAC
  algorithm described in Section 3 across multiple domains/areas/AS's.
  However, network providers may be reluctant to divulge full topology
  and capacity usage information to other providers.

I don't think that [BGP-TE] was ever intended to provide full TE
topology distribution across ASBRs. Such a mechanism would neither be
stable nor scalable. The referenced I-D has been superseded by
draft-gredler-idr-ls-distribution which has a narrower scope.

I would suggest to keep this option in your list, but to add to the
reasons for rejecting it.

But you might also usefully add the fourth option of using a PCE to
solve the problem. While you say later in the section that "path
computation is not part of the GCAC algorithm" it seems to me that the
topic (viz. "there are several options to enable MPLS GCAC to be
implemented in") is precisely a computation problem where you are not
selecting a precise path, but are determining which high-level path can
supply the requested bandwidth.

---

Section 2.2

"DiffServ based on EXP bits"

These are now called the TC bits per RFC 5462

---

Section 3.1

"RBT typically = .05 * MRBk"

Is that RBTk ?

---

Section 3.2

I struggled for a while to parse the notation in some of the equations                                         
such as (3). It might be clearer to write pseudocode such as

  if (ULBCck >= DBWi) then include link k; else exclude link k      (3)

---

Section 3.2

The RFC Editor will prefer you to use round braces in place of square
ones if you can. I think that in these equations it is pretty much OK

---

Section 4

  - Only some user groups (e.g., the police are authorized to set the

Missing close parenthesis

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the document
and, in particular, does he or she believe this version is ready
for forwarding to the IESG for publication?

Young Lee. I think this document is ready for forwarding to the IESG for
publication.

(1.b) Has the document had adequate review both from key members of
the interested community and others? Does the Document Shepherd
have any concerns about the depth or breadth of the reviews that
have been performed?

I believe this draft has been circulated in MPLS and Routing Area WGs.

But I have not seen any reviews or comments for this draft.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective, e.g.,
security, operational complexity, someone familiar with AAA,
internationalization or XML?

Not identified.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he or
she is uncomfortable with certain parts of the document, or has
concerns whether there really is a need for it. In any event, if
the interested community has discussed those issues and has
indicated that it still wishes to advance the document, detail
those concerns here.

There seems to be no major issues with this document.

(1.e) How solid is the consensus of the interested community behind
this document? Does it represent the strong concurrence of a few
individuals, with others being silent, or does the interested
community as a whole understand and agree with it?

I don't have enough data to be able to judge the consensus of the interested
community behind this document. Based on my limited source of contact with
carrier experts on MPLS, the MPLS GCAC mechanism specified in this document
might be helpful for certain applications where high-priority traffic needs
to receive preferential treatment.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

I am not aware of such.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not
enough; this check needs to be thorough. Has the document met all
formal review criteria it needs to, such as the MIB Doctor, media
type and URI type reviews?

Yes. There is no error reported by the idnits tool.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are
not ready for advancement or are otherwise in an unclear state?
If such normative references exist, what is the strategy for their
completion? Are there normative references that are downward
references, as described in [RFC3967]? If so, list these downward
references to support the Area Director in the Last Call procedure
for them [RFC3967].

Yes. There is no issue here.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of
the document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the
IANA registries clearly identified? If the document creates a new
registry, does it define the proposed initial contents of the
registry and an allocation procedure for future registrations?
Does it suggested a reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with the
Responsible Area Director so that the IESG can appoint the needed
Expert during the IESG Evaluation?

This is an experimental draft, so there is no need for the IANA consideration.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML code,
BNF rules, MIB definitions, etc., validate correctly in an
automated checker?

The document has no issues with this area.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document presents a generic connection admission control (GCAC)
reference model and algorithm for IP/MPLS-based networks. Service
provider (SP) IP/MPLS networks need an MPLS GCAC mechanism, for
example, to reject voice over Internet Protocol (VoIP) calls when
additional calls would adversely affect calls already in progress.

Working Group Summary

This document did not go through a normal WG process. This is an
individual submission to the IESG for publication. So this section
does not apply for this document.

Document Quality

I am not aware of any information on the implementation of the algorithm
mentioned in this document.