Re: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions

"Francois Le Faucheur (flefauch)" <flefauch@cisco.com> Wed, 04 December 2013 15:49 UTC

Return-Path: <flefauch@cisco.com>
X-Original-To: ancp@ietfa.amsl.com
Delivered-To: ancp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8A11AE2B5 for <ancp@ietfa.amsl.com>; Wed, 4 Dec 2013 07:49:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.502
X-Spam-Level:
X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_p2VouRyAdW for <ancp@ietfa.amsl.com>; Wed, 4 Dec 2013 07:49:40 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 6A20C1AE2B3 for <ancp@ietf.org>; Wed, 4 Dec 2013 07:49:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2891; q=dns/txt; s=iport; t=1386172176; x=1387381776; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9uccq03WkYJ+4OdHtcysPzIrrPKE4mIVwF97FhUTMDk=; b=B1FK23WBVYfStb6OKrt6PnWxucrBKqWmZtPVheoY0kEVbCziKmcakqd+ JQE/Oc09RdkpHRRcc8S3JSp5NmDCu6dexwQ4ewupugbKx3jXjvGRGt9b5 UpSSYnOf3/YJtVMBfxNVkcj04y4C5kW3PWSD1v2EDg5Rnt6e+IlVBlJvV U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFALVNn1KtJV2d/2dsb2JhbABagwc4U7hmgSMWdIIlAQEBAwEBAQE3NAsFCwIBCDYQIQYLJQIEDgWHcAMJBg26Qg2HExMEjG2BXjMHgyCBEwOWKYFrjFqFOYMpgio
X-IronPort-AV: E=Sophos;i="4.93,825,1378857600"; d="scan'208";a="4279994"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 04 Dec 2013 15:49:36 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rB4FnbGe014071 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 15:49:37 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.250]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 09:49:36 -0600
From: "Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>
Thread-Topic: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions
Thread-Index: AQHO70iBrme9cj45Q02spBfRECT50ppEluEA
Date: Wed, 04 Dec 2013 15:49:36 +0000
Message-ID: <9156506C-A97E-47B1-9ACC-A5A06BB556A7@cisco.com>
References: <529C5F80.2000809@gmail.com>
In-Reply-To: <529C5F80.2000809@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.55.161.199]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0518E5FBB80379439C727C78CF9CBD33@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ancp@ietf.org" <ancp@ietf.org>
Subject: Re: [ANCP] CAC vs. Admission Control in draft-ietf-ancp-mc-extensions
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ancp/>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2013 15:49:42 -0000

Hello Tom,

I think it is a good idea to provide a definition for the two concepts (policy-based admission vs resource-based admission).

With respect to the actual names for the two concepts, I am very uncomfortable in using a name that abreviates to "CAC" for the policy-based admission control because "CAC" (abbreviation of "Connection Admission Control")  has been extensively used in the industry for many years and generally implied either (i) resource-based admission or (ii) a combination of policy-based admission and resource-based admission (and never just policy-based admission).

My preference would be to just always use non-abbreviated terms. I'd probably go with "policy-based admission" and "resource-based admission", but can go with some variations of these such as "policy-based admission control" and "resource-based admission control (or "bandwidth-based admission control").


I had trouble parsing the last sentence of the definition. I'd suggest 
s/The NAS controls which procedures are performed at the Access Node and which by itself/The NAS controls which procedures are performed by the Access Node and which are performed by itself/

HTH

Francois


On 2 Dec 2013, at 11:22, Tom Taylor <tom.taylor.stds@gmail.com> wrote:

> To clear up a misunderstanding that led to an AD comment, I propose to add the following definitions to the terminology section of the document:
> 
> <quote>
> 
> Within this document, the term "conditional access control (CAC)" refers to a procedure wherein a decision is made to allow or disallow a subscriber request for a new media flow based on the subscriber profile. "Admission control" is a separate procedure wherein the admission decision is based on the availability of bandwidth to serve the request. Both procedures are applied to make the final decision. The NAS controls which procedures are performed at the Access Node and which by itself based on the capabilities both devices support and the provisioning information it sends to the Access Node.
> 
> </quote>
> 
> Based on these definitions, some of the protocol elements in the document are misnamed. So far I have identified three cases:
> 
> -- Multicast Admission Control Message (which is sent from the
>   AN to the NAS for grey-listed flows, hence is for CAC to start
>   with)
> 
> -- White-List-CAC and MRepCtl-CAC TLVs, which are actually
>   controlling whether the AN does admission control
> 
> Would it be OK to rename these, given that it doesn't affect the bits on the wire?
> 
> Of course, the first question is whether the proposed definitions are acceptable.
> 
> Tom Taylor
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www.ietf.org/mailman/listinfo/ancp