From ancp-bounces@ietf.org Sun Jul 01 15:13:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I54rn-0002ya-80; Sun, 01 Jul 2007 15:13:51 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I54rm-0002yV-Ql for ancp-confirm+ok@megatron.ietf.org; Sun, 01 Jul 2007 15:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I54rm-0002yN-H2 for ancp@ietf.org; Sun, 01 Jul 2007 15:13:50 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I54rg-00013X-SE for ancp@ietf.org; Sun, 01 Jul 2007 15:13:50 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Jul 2007 21:13:44 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAF6Zh0aQ/uCKh2dsb2JhbACPJgEBCQ4s X-IronPort-AV: i="4.16,483,1175464800"; d="scan'208"; a="146947286:sNHT26083514" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l61JDhow028563; Sun, 1 Jul 2007 21:13:43 +0200 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l61JDfTC026512; Sun, 1 Jul 2007 19:13:43 GMT Received: from lwood-wxp01.cisco.com (ams3-vpn-dhcp4600.cisco.com [10.61.81.247]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id UAA12512; Sun, 1 Jul 2007 20:13:38 +0100 (BST) Message-Id: <200707011913.UAA12512@cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 30 Jun 2007 11:24:27 +0100 To: ancp@ietf.org From: Lloyd Wood In-Reply-To: <7.1.0.9.0.20070618195315.07151df8@cisco.com> References: <7.1.0.9.0.20070618195315.07151df8@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Authentication-Results: ams-dkim-1; header.From=L.Wood@surrey.ac.uk; dkim=neutral X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [ANCP] Re: ANCP use for smart adaptive modems? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org We've now described this scenario in a draft at http://www.ietf.org/internet-drafts/draft-floreani-ancp-wireless-00.txt (Thanks for the information on the history of ANCP.) L. At Monday 18/06/2007 19:56 +0100, Lloyd Wood wrote: >We have been looking at the problem of routers talking to smart adaptive wireless modems - modems that can vary their output from say 16kbps to 512kbps, or 1-6Mbps, depending on channel conditions. These modems often have ethernet ports, because ethernet is cheap, and they're connected to a router the next hop along. (There are hundreds of custom modems, so they're not built into the router directly.) But you need to rate-limit and set QoS on the router's Ethernet interface to match the modem output - and when the modem rate varies, your static QoS config is rendered useless. You can't usefully let 100Mbps go over Ethernet to the modem. > >So, we would need a way for the modem to signal that its output/input wireless speeds have changed, so that the router dynamically updates its QoS/rate-limiting configuration to match. > >So, could ANCP communication over Ethernet between modem and router be one way to solve this? is there any wider interest in using ANCP in this way, generalising from the managed DSL space? > >thanks, > >L. > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jul 09 16:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zdp-0000hs-ID; Mon, 09 Jul 2007 16:15:29 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I7zdP-0008Ua-Ec for ancp-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 16:15:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7zdO-0008U3-HF; Mon, 09 Jul 2007 16:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I7zdO-0004xA-8a; Mon, 09 Jul 2007 16:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 2919326E92; Mon, 9 Jul 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7zdO-0002AO-1P; Mon, 09 Jul 2007 16:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 16:15:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-security-threats-02.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, et al. Filename : draft-ietf-ancp-security-threats-02.txt Pages : 17 Date : 2007-7-9 The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS in order to enable and optimize configuration. This document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-security-threats-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-security-threats-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-security-threats-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-9150829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-security-threats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-security-threats-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9150829.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Wed Jul 11 09:03:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bqx-0002lf-VR; Wed, 11 Jul 2007 09:03:35 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I8bqw-0002lV-IK for ancp-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8bqv-0002l8-2w for ancp@ietf.org; Wed, 11 Jul 2007 09:03:33 -0400 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8bqq-0007St-Cf for ancp@ietf.org; Wed, 11 Jul 2007 09:03:32 -0400 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id l6BD2x9c025573 for ; Wed, 11 Jul 2007 08:03:27 -0500 (CDT) Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 08:03:14 -0500 Received: from DEEXC1U02.de.lucent.com ([135.248.187.30]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 15:03:12 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [ANCP] ANCP MIB and Partition-ID Date: Wed, 11 Jul 2007 15:03:09 +0200 Message-ID: In-Reply-To: <4677E9C8.7070601@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP MIB and Partition-ID Thread-Index: AceyfypbX8kw37lUTT63jB4kaDSk7QRPJCgw References: <4677E9C8.7070601@alcatel-lucent.be> From: "Wijnen, Bert \(Bert\)" To: "DE CNODDER, STEFAAN \(STEFAAN\)" X-OriginalArrivalTime: 11 Jul 2007 13:03:12.0013 (UTC) FILETIME=[D60263D0:01C7C3BB] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org So, that to me implies that the sessionIDs are unique across=20 multiple/all partitionIDs. Is that a corrct interpretation? Bert Wijnen =20 > -----Original Message----- > From: Stefaan DE CNODDER=20 > [mailto:stefaan.de_cnodder@alcatel-lucent.be]=20 > Sent: Tuesday, June 19, 2007 4:36 PM > To: Wijnen, Bert (Bert) > Cc: ancp@ietf.org > Subject: Re: [ANCP] ANCP MIB and Partition-ID=20 >=20 >=20 > Hi Bert, >=20 > For this very late reply on the mail below. An ANCP session=20 > is managing all the access lines that belongs to a particular=20 > partition. Therefore partitioning is just a grouping of DSL=20 > lines and 1 SNMP agent is managing all the partitions. So=20 > there is only need to have 1 instance of the MIB in an access node. >=20 > regards, > Stefaan >=20 >=20 >=20 > To: > Subject: [ANCP] ANCP MIB and Partition-ID > From: "Wijnen, Bert \(Bert\)" > Date: Tue, 20 Mar 2007 14:43:58 +0100 > In-reply-to: <45F7B3CD.5070806@alcatel-lucent.be> > List-archive: > List-help: > List-id: Access Node Control Protocol working group mailing=20 > list > List-post: > List-subscribe: , > > List-unsubscribe: , > > References: <45F7B3CD.5070806@alcatel-lucent.be> > Thread-index: AcdmE/T2YouUQo/YQNOxQssnPj/0ZQE4S0xA > Thread-topic: ANCP MIB and Partition-ID >=20 > -------------------------------------------------------------- > ------------------ >=20 > During the ANCP session today I listened to the discussion=20 > about PartionID and the question if it is more than just a=20 > number. There was talk about that possibly they could be=20 > multiple partitions in the same device, maybe even virtual partitions? >=20 > That triggered me to wonder >=20 > - will multiple partitions on the same device be supported > (repersented) by a single SNMP agent or by multiple SNMP > agents? >=20 > - If so, do we need to consider that the particionID becomes > part of the indexing scheme, so that you implicitly support > multiple instances of this MIB module >=20 > The WG better thinks this through BEFORE the MIB module gets=20 > finalized, because if we find out later (afte rthe MIB=20 > document has been approved), then it can only be changed with=20 > incompatible changes (i.e. re-indexing), and so that means=20 > obsoleting most (if not all) of what we define today. >=20 > Bert >=20 > _______________________________________________ > ANCP mailing list > ANCP at ietf.org > https://www1.ietf.org/mailman/listinfo/ancp >=20 >=20 >=20 >=20 >=20 _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jul 12 03:07:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8sli-0007q4-ET; Thu, 12 Jul 2007 03:07:18 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I8slg-0007pM-Aw for ancp-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 03:07:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8slf-0007pC-UQ for ancp@ietf.org; Thu, 12 Jul 2007 03:07:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8slb-00017c-7F for ancp@ietf.org; Thu, 12 Jul 2007 03:07:15 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Jul 2007 09:07:11 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAPNvlUaQ/uCLh2dsb2JhbACCY4xYAQEBCA4s X-IronPort-AV: i="4.16,530,1175464800"; d="scan'208,217"; a="147852034:sNHT83293410" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6C77AVX022714; Thu, 12 Jul 2007 09:07:10 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6C770TC024261; Thu, 12 Jul 2007 07:07:10 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 09:06:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jul 2007 09:06:56 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP WG Draft Agenda - IETF69 Thread-Index: AcfDkLZlAihTUfzbT/+Vs17Ou44XVgAwjSMA From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 12 Jul 2007 07:06:59.0960 (UTC) FILETIME=[3DAFA780:01C7C453] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6659; t=1184224030; x=1185088030; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:=20ANCP=20WG=20Draft=20Agenda=20-=20IETF69 |Sender:=20; bh=XwsgdIqZblL2eaKnv3aR6fCnPuFixs401T4KWQ1FVV4=; b=im8sL57iL8+Hv7tKDBwKYEhN8OWRvKXtms3HJnTc4NebURHS1/dEvGMZgeEJvmr7ioKyYdYw QMcfq+pJsFfvVQuvn2frk1gp0Or9P9Kloot6s6Y1YhWqqrOUq9OBLOXP; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: Subject: [ANCP] ANCP WG Draft Agenda - IETF69 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0744802460==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0744802460== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C453.3D4AE63E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C453.3D4AE63E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable > Hi All, >=20 > Below's the proposed draft agenda based on the received requests & > drafts MIB update remains items still to be confirmed. Feedback is > welcome. >=20 Regards, Matthew & Woj > TUESDAY, July 24th, 2007: 15:20 - 17:20 > ------------------------------------------- > CHAIRS: Wojciech Dec & Matthew Bocci >=20 > 5 mins - Administrivia, WG Status and WG Docs Update - Chairs >=20 > 15 mins - ANCP Framework / Requirements - Matthew Bocci > (matthew.bocci@alcatel-lucent.co.uk) > http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework- > 02.txt >=20 > 15 mins - ANCP Security Threats and Requirements - Hassnaa > Moustafa (hassnaa.moustafa@orange-ftgroup.com) > http://www.ietf.org/internet-drafts/draft-ietf-ancp-security- > threats-01.txt >=20 > 15 mins - ANCP Protocol Draft - Sanjay Wadhwa=20 > (swadhwa@juniper.net) > http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol- > 01.txt >=20 > 15 mins - ANCP Access Node MIBs - TBD (Matthew Bocci?) > http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an- > 01.txt >=20 > 30 mins - ANCP Multicast Handling - Roberta Maglione ( > roberta.maglione@telecomitalia.it) > http://www.ietf.org/internet-drafts/draft-maglione-ancp-mcast > -00.txt=20 >=20 > 15 mins - Extension of ANCP for Satellite and Terrestrial=20 > Wireless Modem Networks - Lloyd Wood (lwood@cisco.com) > http://www.ietf.org/internet-drafts/draft-floreani-ancp- > wireless-00 ------_=_NextPart_001_01C7C453.3D4AE63E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ANCP WG Draft Agenda - IETF69

Hi All,

Below's the proposed draft agenda based on = the received requests & drafts MIB update remains items still = to be confirmed. Feedback is = welcome.

Regards,
Matthew & Woj

TUESDAY, July = 24th, 2007: 15:20 - 17:20
-------------------------------------------
CHAIRS: = Wojciech Dec & Matthew Bocci

5 mins - = Administrivia, WG Status and WG Docs Update - Chairs

15 mins - ANCP = Framework / Requirements - Matthew Bocci
(matthew.bocci@alcatel-lucent.co.uk)
http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework= -
02.txt

15 mins - ANCP = Security Threats and Requirements - Hassnaa
Moustafa = (hassnaa.moustafa@orange-ftgroup.com)
= http://www.ietf.org/internet-drafts/draft-ietf-ancp-security<= /U>-
threats-01.txt

15 mins - ANCP = Protocol Draft - Sanjay Wadhwa
(swadhwa@juniper.net)
= http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol<= /U>-
01.txt

15 mins - ANCP = Access Node MIBs - TBD (Matthew Bocci?)
= http://www.ietf.org/internet-drafts/draft-decnodder-ancp-mib-an-
01.txt

30 mins - ANCP = Multicast Handling - Roberta Maglione (
roberta.maglione@telecomitalia.it)
http://www.ietf.org/internet-drafts/draft-maglione-ancp-mcast=
-00.txt =

15 mins - = Extension of ANCP for Satellite and Terrestrial
Wireless Modem = Networks - Lloyd Wood (lwood@cisco.com)
<= U>http://www.ietf.org/internet-drafts/draft-floreani-ancp-
wireless-00

------_=_NextPart_001_01C7C453.3D4AE63E-- --===============0744802460== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0744802460==-- From ancp-bounces@ietf.org Thu Jul 12 12:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Km-0004dy-CO; Thu, 12 Jul 2007 12:16:04 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I91Jy-00039d-Tm for ancp-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 12:15:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I91Jx-00039P-Vr; Thu, 12 Jul 2007 12:15:14 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I91Jx-0005iM-O8; Thu, 12 Jul 2007 12:15:13 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 72EB0175F7; Thu, 12 Jul 2007 16:15:13 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I91Jw-0003GM-DN; Thu, 12 Jul 2007 12:15:12 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 12:15:12 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-framework-02.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-02.txt Pages : 34 Date : 2007-7-12 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-framework-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-framework-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12112820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-framework-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12112820.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Thu Jul 12 13:15:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92Gb-0001mI-U1; Thu, 12 Jul 2007 13:15:50 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I92GT-0001XN-CW for ancp-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 13:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I92GS-0001Uo-47; Thu, 12 Jul 2007 13:15:40 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I92GR-0003Oi-Nr; Thu, 12 Jul 2007 13:15:40 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 9F19526EAB; Thu, 12 Jul 2007 17:15:39 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I92GO-0005UM-AA; Thu, 12 Jul 2007 13:15:36 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 12 Jul 2007 13:15:36 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-protocol-01.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-01.txt Pages : 41 Date : 2007-7-12 This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for “Access Node Control” mechanism as described in [8]. The resulting protocol with the proposed extensions to GSMPv3 [4] is referred to as “Access Node Control Protocol” (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [8]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [8] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ancp-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ancp-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-12121844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-12121844.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --NextPart-- From ancp-bounces@ietf.org Thu Jul 12 23:57:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CHq-000320-Ju; Thu, 12 Jul 2007 23:57:46 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I9CHq-0002yF-2e for ancp-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 23:57:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9CHp-0002wL-Mn for ancp@ietf.org; Thu, 12 Jul 2007 23:57:45 -0400 Received: from kecgate02.progeon.com ([61.95.162.76] helo=kecgate02.infosys.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9CHo-00026X-PY for ancp@ietf.org; Thu, 12 Jul 2007 23:57:45 -0400 Received: from indhubbhs01.ad.infosys.com ([192.168.200.81]) by kecgate02.infosys.com with InterScan Message Security Suite; Fri, 13 Jul 2007 09:24:01 +0530 Received: from blrkechub01.ad.infosys.com ([10.66.236.41]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 09:24:50 +0530 Received: from [10.10.10.170] (192.168.101.134) by blrkechub01.ad.infosys.com (10.66.236.41) with Microsoft SMTP Server id 8.0.700.0; Fri, 13 Jul 2007 09:24:50 +0530 Subject: Re: [ANCP] I-D ACTION:draft-ietf-ancp-protocol-01.txt From: Bharat Joshi To: "ancp@ietf.org" In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Organization: Infosys Technologies Ltd Date: Fri, 13 Jul 2007 09:27:52 +0530 Message-ID: <1184299072.32490.4.camel@magadha> MIME-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 13 Jul 2007 03:54:50.0135 (UTC) FILETIME=[8FC9BA70:01C7C501] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi, I had some questions and suggestions on this draft and had sent them in a mail long back. I did not see a reply for that mail. Can authors please confirm if they had taken care of these comments in the new draft. Please find this mail at: http://www1.ietf.org/mail-archive/web/ancp/current/msg00109.html Thanks, Bharat On Thu, 2007-07-12 at 22:45 +0530, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Access Node Control Protocol Working Group of the IETF. > > Title : Protocol for Access Node Control Mechanism in Broadband Networks > Author(s) : S. Wadhwa, et al. > Filename : draft-ietf-ancp-protocol-01.txt > Pages : 41 > Date : 2007-7-12 > > This document describes proposed extensions to the GSMPv3 protocol to > allow its use in a broadband environment, as a control plane between > Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). > These proposed extensions are required to realize a protocol for > “Access Node Control” mechanism as described in [8]. The resulting > protocol with the proposed extensions to GSMPv3 [4] is referred to as > “Access Node Control Protocol” (ANCP). This document currently > focuses on specific use cases of access node control mechanism for > topology discovery, line configuration, and OAM as described in ANCP > framework document [8]. It is intended to be augmented by additional > protocol specification for future use cases considered in scope by > the ANCP charter. > > ANCP framework document [8] describes the ANCP use-cases in detail. > Illustrative text for the use-cases is included here to help the > protocol implementer understand the greater context of ANCP protocol > interactions. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-01.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-ietf-ancp-protocol-01.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-ancp-protocol-01.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. **************** CAUTION - Disclaimer ***************** This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the addressee(s). If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Infosys has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail or attachment. Infosys reserves the right to monitor and review the content of all messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on the Infosys e-mail system. ***INFOSYS******** End of Disclaimer ********INFOSYS*** _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jul 13 03:41:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Fmd-0002lS-KU; Fri, 13 Jul 2007 03:41:47 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1I9Fmc-0002lI-RP for ancp-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 03:41:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9FmY-0002kO-Ga for ancp@ietf.org; Fri, 13 Jul 2007 03:41:42 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9FmT-0007tK-QD for ancp@ietf.org; Fri, 13 Jul 2007 03:41:42 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6D7cvAg017358; Fri, 13 Jul 2007 09:38:57 +0200 Received: from [172.17.114.30] ([172.17.114.30]) by FRVELSBHS06.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Fri, 13 Jul 2007 09:40:47 +0200 Message-ID: <46972C7F.70501@alcatel-lucent.be> Date: Fri, 13 Jul 2007 09:40:47 +0200 From: Stefaan DE CNODDER User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert \(Bert\)" Subject: Re: [ANCP] ANCP MIB and Partition-ID References: <4677E9C8.7070601@alcatel-lucent.be> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2007 07:40:47.0423 (UTC) FILETIME=[208FB4F0:01C7C521] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi Bert, Yes, that is correct: session IDs are unique across partitions. regards, Stefaan Wijnen, Bert (Bert) wrote: > So, that to me implies that the sessionIDs are unique across > multiple/all partitionIDs. > Is that a corrct interpretation? > > Bert Wijnen > > >>-----Original Message----- >>From: Stefaan DE CNODDER >>[mailto:stefaan.de_cnodder@alcatel-lucent.be] >>Sent: Tuesday, June 19, 2007 4:36 PM >>To: Wijnen, Bert (Bert) >>Cc: ancp@ietf.org >>Subject: Re: [ANCP] ANCP MIB and Partition-ID >> >> >>Hi Bert, >> >>For this very late reply on the mail below. An ANCP session >>is managing all the access lines that belongs to a particular >>partition. Therefore partitioning is just a grouping of DSL >>lines and 1 SNMP agent is managing all the partitions. So >>there is only need to have 1 instance of the MIB in an access node. >> >>regards, >>Stefaan >> >> >> >>To: >>Subject: [ANCP] ANCP MIB and Partition-ID >>From: "Wijnen, Bert \(Bert\)" >>Date: Tue, 20 Mar 2007 14:43:58 +0100 >>In-reply-to: <45F7B3CD.5070806@alcatel-lucent.be> >>List-archive: >>List-help: >>List-id: Access Node Control Protocol working group mailing >>list >>List-post: >>List-subscribe: , >> >>List-unsubscribe: , >> >>References: <45F7B3CD.5070806@alcatel-lucent.be> >>Thread-index: AcdmE/T2YouUQo/YQNOxQssnPj/0ZQE4S0xA >>Thread-topic: ANCP MIB and Partition-ID >> >>-------------------------------------------------------------- >>------------------ >> >>During the ANCP session today I listened to the discussion >>about PartionID and the question if it is more than just a >>number. There was talk about that possibly they could be >>multiple partitions in the same device, maybe even virtual partitions? >> >>That triggered me to wonder >> >>- will multiple partitions on the same device be supported >> (repersented) by a single SNMP agent or by multiple SNMP >> agents? >> >>- If so, do we need to consider that the particionID becomes >> part of the indexing scheme, so that you implicitly support >> multiple instances of this MIB module >> >>The WG better thinks this through BEFORE the MIB module gets >>finalized, because if we find out later (afte rthe MIB >>document has been approved), then it can only be changed with >>incompatible changes (i.e. re-indexing), and so that means >>obsoleting most (if not all) of what we define today. >> >>Bert >> >>_______________________________________________ >>ANCP mailing list >>ANCP at ietf.org >>https://www1.ietf.org/mailman/listinfo/ancp >> >> >> >> > > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jul 16 06:18:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANel-0003u1-5v; Mon, 16 Jul 2007 06:18:19 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IANek-0003tw-Fo for ancp-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 06:18:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IANek-0003to-5e for ancp@ietf.org; Mon, 16 Jul 2007 06:18:18 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IANed-0004ej-HO for ancp@ietf.org; Mon, 16 Jul 2007 06:18:18 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6GAHplw027170; Mon, 16 Jul 2007 12:17:51 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 16 Jul 2007 12:18:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 16 Jul 2007 12:18:07 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-maglione-ancp-mcast-00.txt Thread-Index: AcfHkprEBhu3QqhkSUutBEbjpz8iqA== From: "OOGHE Sven" To: , , , X-OriginalArrivalTime: 16 Jul 2007 10:18:08.0731 (UTC) FILETIME=[9B423AB0:01C7C792] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.5 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: Subject: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0056051129==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0056051129== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C792.9B04A7CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C792.9B04A7CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to initiate a thread related to draft-maglione-ancp-mcast-00.txt describing how to use ANCP for multicasting. Here are my thoughts on the described use cases. Multicast Conditional Access I agree on using ANCP for the sake of provisioning conditional access information on an Access Node (AN), so that it can take autonomous decisions lateron. It seems to me that even the most complex conditional access control scenarios can be handled using relatively simple policies in the ANs, with these policies dynamically altered as needed to address the conditional aspect. For example, if a subscriber is authorized to view a particular channel only after 11PM, it seems simpler to me to push a new policy to the AN at 11PM than to force the AN to query the NAS for every attempt to join that channel. I'm therefore not convinced about using ANCP for the AN to query the NAS, that in turn will respond to the AN indicating whether the join is to be honored or denied. Multicast Admission Control The general notion of resource admission control is an important one. The draft mentions a number of aspects which are indeed of a concern when deploying a triple play network architecture with both Video on Demand and Broadcast TV flows. The draft proposes that the AN outsources a recource decision for a multicast stream to the NAS. In my view this is not the best approach. Normally, it would require signaling from the AN to the NAS at each channel zap. The draft proposes the introduction of a "Multicast Flow-Group" to reduce the signaling load; this creates a new problem: how to signal the termination of the reservation for a flow-group to the NAS? This requires some time-out mechanism on the AN that releases resources only after a flow-group has no active flows for some period of time. However, such a timer would block the startup of unicast flows for a short window following a leave of the last flow in a group. This appears a highly undesirable effect. In my view, the resource admission control aspects for the access line are instead best handled by the AN. This also calls for some synchronization mechanism between AN, NAS and policy servers, but different from what is described in this draft. These CAC concepts must be addressed in a scope that is much broader than the ANCP WG. Replication Termination Similar to the basic notion of Multicast Conditional Access, it should be possible to revoke authorization to join a channel at any time by pushing a new policy to the AN that indicates that the subscriber is no longer allowed to join the channel. Again, this is simpler than performing an ANCP admission request for each join. Based on the above, I believe that most of the flows in the draft can be simplified considerably, while still meeting the objectives set forward in the ANCP framework. Regards, Sven ------_=_NextPart_001_01C7C792.9B04A7CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-maglione-ancp-mcast-00.txt

Hi,

I would like to initiate a thread = related to draft-maglione-ancp-mcast-00.txt describing how to use ANCP = for multicasting. Here are my thoughts on the described use = cases.

Multicast Conditional = Access

I agree on using ANCP for the sake of = provisioning conditional access information on an Access Node (AN), so = that it can take autonomous decisions lateron.

It seems to me that even the most = complex conditional access control scenarios can be handled using = relatively simple policies in the ANs, with these policies dynamically = altered as needed to address the conditional aspect. For example, if a = subscriber is authorized to view a particular channel only after 11PM, = it seems simpler to me to push a new policy to the AN at 11PM than to = force the AN to query the NAS for every attempt to join that = channel.

I'm therefore not convinced about using = ANCP for the AN to query the NAS, that in turn will respond to the AN = indicating whether the join is to be honored or denied.

Multicast Admission = Control

The general notion of resource = admission control is an important one. The draft mentions a number of = aspects which are indeed of a concern when deploying a triple play = network architecture with both Video on Demand and Broadcast TV = flows.

The draft proposes that the AN = outsources a recource decision for a multicast stream to the NAS. In my = view this is not the best approach. Normally, it would require signaling = from the AN to the NAS at each channel zap. The draft proposes the = introduction of a "Multicast Flow-Group" to reduce the = signaling load; this creates a new problem: how to signal the = termination of the reservation for a flow-group to the NAS? This = requires some time-out mechanism on the AN that releases resources only = after a flow-group has no active flows for some period of time. However, = such a timer would block the startup of unicast flows for a short window = following a leave of the last flow in a group. This appears a highly = undesirable effect.

In my view, the resource admission = control aspects for the access line are instead best handled by the AN. = This also calls for some synchronization mechanism between AN, NAS and = policy servers, but different from what is described in this draft. = These CAC concepts must be addressed in a scope that is much broader = than the ANCP WG.

Replication Termination

Similar to the basic notion of = Multicast Conditional Access, it should be possible to revoke = authorization to join a channel at any time by pushing a new policy to = the AN that indicates that the subscriber is no longer allowed to join = the channel. Again, this is simpler than performing an ANCP admission = request for each join.

Based on the above, I believe that most = of the flows in the draft can be simplified considerably, while still = meeting the objectives set forward in the ANCP framework.

Regards,
Sven

------_=_NextPart_001_01C7C792.9B04A7CC-- --===============0056051129== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0056051129==-- From ancp-bounces@ietf.org Mon Jul 16 10:33:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARe6-0005rb-Df; Mon, 16 Jul 2007 10:33:54 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IARe1-0005j3-U5 for ancp-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 10:33:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IARe1-0005fl-E2 for ancp@ietf.org; Mon, 16 Jul 2007 10:33:49 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IARdm-00007I-U3 for ancp@ietf.org; Mon, 16 Jul 2007 10:33:49 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Mon, 16 Jul 2007 16:33:09 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Jul 2007 16:33:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt Date: Mon, 16 Jul 2007 16:33:08 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20279CDC5@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt Thread-Index: AcfHtwRWUYULAoOiQeiOqpHyyEuCww== From: "Haag, T" To: , , , X-OriginalArrivalTime: 16 Jul 2007 14:33:09.0308 (UTC) FILETIME=[3B1CFFC0:01C7C7B6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0665414643==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0665414643== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C7B6.3AA9A287" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C7B6.3AA9A287 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Operating Multicast in conjunction with conditional access is very useful. But it is important to design such scenario in a less complex way. I think simplifying the message flow by adding local decision control in the access node triggered by user authentication result archived by NAS/RADIUS decision when starting a session can be a way out to solve the estimated zapping performance issue, the complex maintenance issue and decouples user session from DSL Port authentication. =20 =20 Operation/Performance: >From an operational standpoint these features/message flows must be simple and less complex in operation respectively maintenance and fault location. Sending each event by joining a group an ANCP message from the AN towards the NAS and receiving the policy decision implies to me a very busy zapping scenario (section 5.2.) =20 Also with respect to operational complexity I have some concerns regarding performance and maintenance. The main concern is regarding three elements (RADIUS, NAS, AN) participating in the dynamic IGMP triggered policy decision process.=20 =20 Authentication: Running Start Accounting/ Stop Accounting can be done Port_ID related or user related (see fig.4, fig.5). Both methods require different features with respect to CPE/DSL/AN. Considering figure 6 implies to me that port based authentication is required for running multicast. If not RADIUS has to correlate between user ID and DSL Port ID. In the document the reference is missing which authentication method the use cases require. Is it user/session based or is it port based? =20 I think the draft can be reworked according the comments still meeting basics of ANCP framework. =20 Regards, Thomas =20 ------_=_NextPart_001_01C7C7B6.3AA9A287 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Operating Multicast in conjunction with = conditional access is very useful. But it is important to design such scenario in a = less complex way.

I think simplifying the message flow by = adding local decision control in the access node triggered by user authentication = result archived by NAS/RADIUS decision when starting a session can be a way out = to solve the estimated zapping performance issue, the complex maintenance = issue and decouples user session from DSL Port = authentication. 

 

Operation/Performance:

From an operational standpoint these = features/message flows must be simple and less complex in operation respectively = maintenance and fault location. Sending each event by joining a group an ANCP message = from the AN towards the NAS and receiving the policy decision implies to me a = very busy zapping scenario (section 5.2.)

 

Also with respect to operational complexity I = have some concerns regarding performance and maintenance. The main concern is regarding three elements (RADIUS, NAS, AN) participating in the dynamic = IGMP triggered policy decision process.

 

Authentication:

Running Start Accounting/ Stop Accounting can = be done Port_ID related or user related (see fig.4, fig.5). Both methods require different features with respect to CPE/DSL/AN. Considering figure 6 = implies to me that port based authentication is required for running multicast. If = not RADIUS has to correlate between user ID and DSL Port = ID.

In the document the reference is missing = which authentication method the use cases require. Is it user/session based or = is it port based?

 

I think the draft can be reworked according = the comments still meeting basics of ANCP = framework.

 

Regards,

Thomas

 

------_=_NextPart_001_01C7C7B6.3AA9A287-- --===============0665414643== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0665414643==-- From ancp-bounces@ietf.org Mon Jul 16 12:55:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATrJ-0007SD-W9; Mon, 16 Jul 2007 12:55:42 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IAToe-0004kL-0k for ancp-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 12:52:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATod-0004kB-Le for ancp@ietf.org; Mon, 16 Jul 2007 12:52:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IATod-0004zj-5S for ancp@ietf.org; Mon, 16 Jul 2007 12:52:55 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2007 09:52:46 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAEs/m0arR7O6/2dsb2JhbAA X-IronPort-AV: i="4.16,542,1175497200"; d="scan'208"; a="182919808:sNHT29074329" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6GGqkPS031516; Mon, 16 Jul 2007 09:52:46 -0700 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l6GGqj4w026438; Mon, 16 Jul 2007 16:52:46 GMT Received: (from eckert@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id JAA11842; Mon, 16 Jul 2007 09:51:53 -0700 (PDT) Date: Mon, 16 Jul 2007 09:51:53 -0700 From: Toerless Eckert To: "Haag, T" Subject: Re: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt Message-ID: <20070716095153.R11793@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2743; t=1184604766; x=1185468766; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=eckert@cisco.com; z=From:=20Toerless=20Eckert=20 |Subject:=20Re=3A=20[ANCP]=20Comments=20on=20draft-maglione-ancp-mcast-00 .txt |Sender:=20; bh=HS9l7N/a+CdpozksCqTIfx6f86Czgmn+TCJEW8EvyJ0=; b=ga+vwrYfpXR+WN8T6AzduP+S3T2Zv2yI39znEJYADcVVgmIJ7PKoFCgRHigenAVEcVbdUEbS 73SC2QP7yh7Etk0R5W6qz1uOhI3tKrwY1mCNKlJYKPUJW/X5l3STDVUE; Authentication-Results: sj-dkim-2; header.From=eckert@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 2.2 (++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Mon, 16 Jul 2007 12:55:41 -0400 Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Thomas, What you are asking for should already covered by what the draft intends to introduce into the ANCP spec/requirements documents. It is perfectly valid to only use in an ANCP deployment the profile you are implying: Provisioning on a per-subscriber basis a whitelist (permitted channels) and blacklist (denied channels). The draft just also includes requirements and functionality that goes beyond what you are asking for, because not every deployment may be able to statically split up the bandwidth to the home devices with individual static bandwidth tools. In fact, the draft tries to exactly provide the most simple signaling for each of the varying deployment models we have come to see being required. Not quite sure on the authentication piece... Cheers Toerless On Mon, Jul 16, 2007 at 04:33:08PM +0200, Haag, T wrote: > All, > > > > Operating Multicast in conjunction with conditional access is very > useful. But it is important to design such scenario in a less complex > way. > > I think simplifying the message flow by adding local decision control in > the access node triggered by user authentication result archived by > NAS/RADIUS decision when starting a session can be a way out to solve > the estimated zapping performance issue, the complex maintenance issue > and decouples user session from DSL Port authentication. > > > > Operation/Performance: > > >From an operational standpoint these features/message flows must be > simple and less complex in operation respectively maintenance and fault > location. Sending each event by joining a group an ANCP message from the > AN towards the NAS and receiving the policy decision implies to me a > very busy zapping scenario (section 5.2.) > > > > Also with respect to operational complexity I have some concerns > regarding performance and maintenance. The main concern is regarding > three elements (RADIUS, NAS, AN) participating in the dynamic IGMP > triggered policy decision process. > > > > Authentication: > > Running Start Accounting/ Stop Accounting can be done Port_ID related or > user related (see fig.4, fig.5). Both methods require different features > with respect to CPE/DSL/AN. Considering figure 6 implies to me that port > based authentication is required for running multicast. If not RADIUS > has to correlate between user ID and DSL Port ID. > > In the document the reference is missing which authentication method the > use cases require. Is it user/session based or is it port based? > > > > I think the draft can be reworked according the comments still meeting > basics of ANCP framework. > > > > Regards, > > Thomas _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jul 16 18:07:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYjQ-00010u-DP; Mon, 16 Jul 2007 18:07:52 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IAYjO-0000vR-RI for ancp-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 18:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAYjO-0000vJ-HK for ancp@ietf.org; Mon, 16 Jul 2007 18:07:50 -0400 Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAYjJ-00049I-VY for ancp@ietf.org; Mon, 16 Jul 2007 18:07:50 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 650025FC861; Mon, 16 Jul 2007 15:07:45 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04316-01; Mon, 16 Jul 2007 15:07:45 -0700 (PDT) Received: from CSHERBOTM5XP (dhcp-36-36.van.redback.com [172.19.36.36]) by prattle.redback.com (Postfix) with ESMTP id 0F5425FC860; Mon, 16 Jul 2007 15:07:45 -0700 (PDT) From: "Curtis Sherbo" To: , , , Date: Mon, 16 Jul 2007 15:07:41 -0700 Message-ID: <009801c7c7f5$bb199780$242413ac@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfH9bphkunYlpj7QZWeNixZLlrk0Q== X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Subject: [ANCP] Comments on draft-maglione X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1618398095==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1618398095== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0099_01C7C7BB.0EBABF80" This is a multi-part message in MIME format. ------=_NextPart_000_0099_01C7C7BB.0EBABF80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings, I think the flexibility of the solution proposed in draft-maglione-ancp-mcast-00.txt is necessary when you consider applications beyond simple broadcast IPTV. I think it is useful in certain scenarios in IPTV, but I also think it is useful in a few other applications as listed below: 1) Nomadicity/Roaming - whether wired or wireless it would be more effective to have a centralized policy decision as opposed to a distributed one. This is especially true in a wireless instance where a client may be moving from one access point to another, the session would need to be handed off, would you want to see a full authentication step each hop so that you can refresh policies on the access point? 2) Video Conferencing - As conferences would likely be ad-hoc, where the multicast groups may not be known in advance, it would likely be more efficient to update data centrally and query it as a participants join conferences. 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. To be noted, zap time is less of an issue with these three applications, as there is typically an accepted processing time. Obviously it is not the job of the IETF to define these services or business models, but I thought it might be helpful for us to consider services beyond the starting point of IPTV. As suggested by others on this list, the existing framework may be able to fulfill some of the requirements put forward by this draft, but I argue that there is validity in the flexibility that the draft brings for IPTV as well as support for the applications I have discussed here. I welcome your comments. Cheers, Curtis Curtis Sherbo, P.Eng Product Line Manager Redback Networks Canada Inc. Phone: (604)629-7357 Mobile: (604)250-0672 ------=_NextPart_000_0099_01C7C7BB.0EBABF80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-maglione

Greetings,

I think the flexibility of the solution = proposed in draft-maglione-ancp-mcast-00.txt is necessary when you = consider applications beyond simple broadcast IPTV.

I think it is useful in certain = scenarios in IPTV, but I also think it is useful in a few other = applications as listed below:

1) Nomadicity/Roaming - whether wired = or wireless it would be more effective to have a centralized policy = decision as opposed to a distributed one.  This is especially true = in a wireless instance where a client may be moving from one access = point to another, the session would need to be handed off, would you = want to see a full authentication step each hop so that you can refresh = policies on the access point?

2) Video Conferencing - As conferences = would likely be ad-hoc, where the multicast groups may not be known in = advance, it would likely be more efficient to update data centrally and = query it as a participants join conferences.

3) Future Over the Top Video = Partnerships - Service providers may choose to partner with internet = video providers to provide QoS and multicast capabilities through a = partnership on a per event basis.  Like the video conferencing = scenario, this would be somewhat ad-hoc where the multicast group = mappings may not be known in advance, or may be reused for different = content in succession, requiring repeated policy refresh.  Again, a = centralized approach would appear to be more scalable for this = model.

To be noted, zap time is less of an = issue with these three applications, as there is typically an accepted = processing time.

Obviously it is not the job of the IETF = to define these services or business models, but I thought it might be = helpful for us to consider services beyond the starting point of = IPTV. 

As suggested by others on this list, = the existing framework may be able to fulfill some of the requirements = put forward by this draft, but I argue that there is validity in the = flexibility that the draft brings for IPTV as well as support for the = applications I have discussed here.

I welcome your comments.

Cheers,
Curtis

Curtis Sherbo, P.Eng
Product Line Manager
Redback = Networks Canada Inc.
Phone: (604)629-7357
Mobile: (604)250-0672

------=_NextPart_000_0099_01C7C7BB.0EBABF80-- --===============1618398095== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1618398095==-- From ancp-bounces@ietf.org Tue Jul 17 09:03:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmhv-0005kk-7u; Tue, 17 Jul 2007 09:03:15 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IAmht-0005X2-1i for ancp-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 09:03:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAmhs-0005RH-Ee for ancp@ietf.org; Tue, 17 Jul 2007 09:03:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAmhr-0006aL-Cf for ancp@ietf.org; Tue, 17 Jul 2007 09:03:12 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2007 15:03:09 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAKZanEaQ/uCKh2dsb2JhbACCLDaMYwEBCQon X-IronPort-AV: i="4.16,546,1175464800"; d="scan'208,217"; a="148254964:sNHT117426216" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6HD39bg011313; Tue, 17 Jul 2007 15:03:09 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HD34kv026984; Tue, 17 Jul 2007 13:03:09 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:02:56 +0200 Received: from [10.0.0.15] ([10.61.65.250]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 15:02:55 +0200 In-Reply-To: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> References: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <4D703100-BFEA-49E1-805C-2908128A2C66@cisco.com> From: Francois Le Faucheur IMAP Date: Tue, 17 Jul 2007 14:59:58 +0200 To: OOGHE Sven X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 17 Jul 2007 13:02:55.0865 (UTC) FILETIME=[CADCE690:01C7C872] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13719; t=1184677389; x=1185541389; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Comments=20on=20draft-maglione-ancp-mcast-00.txt |Sender:=20; bh=7bgTAN4GOmLnRXwTOCDJ1P7CjTbGff+7uEATH9r2By8=; b=bkpjgDmRqANGDluRy5j6LuS+VgvEuc3mGI09nyqZQ3W7DbA0Ua8vwTY6G4abQyGiHC0mC3Lk HUysnzh5GeWDY1hh8DF22qTstqX/6FZplUc3rPqM+StObuwYVFEhRUu7; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.5 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org Subject: [ANCP] Re: Comments on draft-maglione-ancp-mcast-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0238605016==" Errors-To: ancp-bounces@ietf.org --===============0238605016== Content-Type: multipart/alternative; boundary=Apple-Mail-20-211568793 --Apple-Mail-20-211568793 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Sven, Thanks for kicking off the discussion and sharing your views. Some thoughts below: On 16 Jul 2007, at 12:18, OOGHE Sven wrote: > Hi, > > I would like to initiate a thread related to draft-maglione-ancp- > mcast-00.txt describing how to use ANCP for multicasting. Here are > my thoughts on the described use cases. > > Multicast Conditional Access > > I agree on using ANCP for the sake of provisioning conditional > access information on an Access Node (AN), so that it can take > autonomous decisions lateron. > > It seems to me that even the most complex conditional access > control scenarios can be handled using relatively simple policies > in the ANs, with these policies dynamically altered as needed to > address the conditional aspect. For example, if a subscriber is > authorized to view a particular channel only after 11PM, it seems > simpler to me to push a new policy to the AN at 11PM than to force > the AN to query the NAS for every attempt to join that channel. > > I'm therefore not convinced about using ANCP for the AN to query > the NAS, that in turn will respond to the AN indicating whether the > join is to be honored or denied. Just to be very clear, the idea is not to force that NAS be systematically queried of course. In many cases, a simple Conditional policy can be provisioned (or-reprovisioned) via ANCP into the Access Node. The proposal includes the White-List/Black-Lists for these cases. In fact, one may only use these mechanisms in a given environment. However, some applications call for more flexibility. For example some applications appear better served by querying a remote authorization server (via NAS). This may be for example because the authorized membership is not known ahead of time and changes dynamically. We feel ANCP should allow such scenarios. > Multicast Admission Control > > The general notion of resource admission control is an important > one. The draft mentions a number of aspects which are indeed of a > concern when deploying a triple play network architecture with both > Video on Demand and Broadcast TV flows. > > The draft proposes that the AN outsources a recource decision for a > multicast stream to the NAS. In my view this is not the best > approach. Normally, it would require signaling from the AN to the > NAS at each channel zap. The draft proposes the introduction of a > "Multicast Flow-Group" to reduce the signaling load; this creates a > new problem: how to signal the termination of the reservation for a > flow-group to the NAS? This requires some time-out mechanism on the > AN that releases resources only after a flow-group has no active > flows for some period of time. However, such a timer would block > the startup of unicast flows for a short window following a leave > of the last flow in a group. This appears a highly undesirable effect. > > In my view, the resource admission control aspects for the access > line are instead best handled by the AN. This also calls for some > synchronization mechanism between AN, NAS and policy servers, but > different from what is described in this draft. These CAC concepts > must be addressed in a scope that is much broader than the ANCP WG. While I agree that defining the overall CAC solution is broader than the ANCP WG, the "black-box principle" agreed in Prague suggests that ANCP needs to provide the necessary flow of information across the boxes (where some functions are done by one box but affect the other one). For Video CAC to work across the two boxes with full functionality, this includes allowing sharing of bandwidth between unicast CAC and multicast CAC. The ANCP Requirements & Framework I-D seems to be assuming this too : " Specifically, when performing multicast replication in the access/ aggregation network, the following features must remain supported by the logical NAS: ... o Connection admission control (CAC) for multicast and/or unicast services " With respect to resource admission control for the access line, I suspect that different deployment approaches will be selected for different networks. Some of these deployment approaches involve handling bandwidth allocation for unicast CAC on the NAS, some involve synchronizing to a remote server doing unicast CAC via NAS. We feel that ANCP should not preclude these important deployment models. Again, the corresponding mechanisms do not have to be used in all deployments. > Replication Termination > > Similar to the basic notion of Multicast Conditional Access, it > should be possible to revoke authorization to join a channel at any > time by pushing a new policy to the AN that indicates that the > subscriber is no longer allowed to join the channel. Again, this is > simpler than performing an ANCP admission request for each join. As you said: this is tied to the discussion on Conditional Access above. If we accept that, _for some applications_, it is more efficient to query a more centralised authorization repository than try dynamically permanently change/rechange the corresponding policy rules on every AN, then I think it is useful to have the corresponding ability to selectively revoke an earlier authorization. If we don't accept it, then the revoke mechanism is not needed. > Based on the above, I believe that most of the flows in the draft > can be simplified considerably, while still meeting the objectives > set forward in the ANCP framework. Well, I think there is agreement that the current Framework & Requirements I-D does yet not fully cover the Multicast use cases. Right? This is why the proposal suggests Multicast specific extensions for the ANCP Framework & Requirement document. Cheers Francois > Regards, > Sven > --Apple-Mail-20-211568793 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello Sven,

Thanks for kicking off the = discussion and sharing your views. Some thoughts = below:

On 16 Jul 2007, at 12:18, OOGHE Sven = wrote:

Hi,

I would = like to initiate a thread related to draft-maglione-ancp-mcast-00.txt = describing how to use ANCP for multicasting. Here are my thoughts on the = described use cases.

Multicast Conditional Access =

I agree on using ANCP for the = sake of provisioning conditional access information on an Access Node = (AN), so that it can take autonomous decisions = lateron.

It seems to me = that even the most complex conditional access control scenarios can be = handled using relatively simple policies in the ANs, with these policies = dynamically altered as needed to address the conditional aspect. For = example, if a subscriber is authorized to view a particular channel only = after 11PM, it seems simpler to me to push a new policy to the AN at = 11PM than to force the AN to query the NAS for every attempt to join = that channel.

I'm therefore = not convinced about using ANCP for the AN to query the NAS, that in turn = will respond to the AN indicating whether the join is to be honored or = denied.

Just to be very clear, the idea is = not to force that NAS be systematically queried of course. In many = cases, a simple Conditional policy can be provisioned (or-reprovisioned) = via ANCP into the Access Node. The proposal includes the = White-List/Black-Lists for these cases. In fact, one may only use these = mechanisms in a given environment.
However, some applications = call for more flexibility. For example some applications appear better = served by querying a remote authorization server (via NAS). This may be = for example because the authorized membership is not known ahead of time = and changes dynamically. We feel ANCP should allow such = scenarios.

Multicast Admission Control

The general notion of resource admission = control is an important one. The draft mentions a number of aspects = which are indeed of a concern when deploying a triple play network = architecture with both Video on Demand and Broadcast TV = flows.

The draft proposes = that the AN outsources a recource decision for a multicast stream to the = NAS. In my view this is not the best approach. Normally, it would = require signaling from the AN to the NAS at each channel zap. The draft = proposes the introduction of a "Multicast Flow-Group" to reduce the = signaling load; this creates a new problem: how to signal the = termination of the reservation for a flow-group to the NAS? This = requires some time-out mechanism on the AN that releases resources only = after a flow-group has no active flows for some period of time. However, = such a timer would block the startup of unicast flows for a short window = following a leave of the last flow in a group. This appears a highly = undesirable effect.

In my = view, the resource admission control aspects for the access line are = instead best handled by the AN. This also calls for some synchronization = mechanism between AN, NAS and policy servers, but different from what is = described in this draft. These CAC concepts must be addressed in a scope = that is much broader than the ANCP WG.

While = I agree that defining the overall CAC solution is broader than the ANCP = WG,=A0the "black-box principle" agreed in Prague suggests that ANCP = needs to provide the necessary flow of information across the boxes = (where some functions are done by one box but affect the other one). For = Video CAC to work across the two boxes=A0with full functionality, this = includes allowing sharing of bandwidth between unicast CAC and multicast = CAC.=A0

The = ANCP Requirements & Framework I-D seems to be assuming this = too=A0:
"
=A0 =A0Specifically, when performing = multicast replication in the access/aggregation network, the following = features must remain supported by
=A0=A0 the logical = NAS:
...
=A0=A0 o=A0 Connection admission control = (CAC) for multicast and/or unicast=A0services
"

With respect to resource = admission control for the access line, I suspect that different = deployment approaches will be selected for different networks. Some of = these deployment approaches involve handling bandwidth allocation for = unicast CAC on the NAS, some involve synchronizing to a remote server = doing unicast CAC via NAS. We feel that ANCP should not preclude these = important deployment models. Again, the corresponding mechanisms do not = have to be used in all deployments.

Replication = Termination

Similar to = the basic notion of Multicast Conditional Access, it should be possible = to revoke authorization to join a channel at any time by pushing a new = policy to the AN that indicates that the subscriber is no longer allowed = to join the channel. Again, this is simpler than performing an ANCP = admission request for each join.

As you = said: this is tied to the discussion on Conditional Access above. If we = accept that, _for some applications_, it is more efficient to query a = more centralised authorization repository than try dynamically = permanently change/rechange the corresponding policy rules on every AN, = then I think it is useful to have the corresponding ability to = selectively revoke an earlier authorization. If we don't accept it, then = the revoke mechanism is not needed.

Based on the above, I = believe that most of the flows in the draft can be simplified = considerably, while still meeting the objectives set forward in the ANCP = framework.

Well, I think there is agreement = that the current Framework & Requirements I-D does yet not fully = cover the Multicast use cases. Right?
This is why the proposal = suggests Multicast specific extensions for the ANCP Framework & = Requirement document.

Cheers

Francois


Regards, =
Sven

=

= --Apple-Mail-20-211568793-- --===============0238605016== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0238605016==-- From ancp-bounces@ietf.org Tue Jul 17 10:12:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAnml-0005MR-Cr; Tue, 17 Jul 2007 10:12:19 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IAnmj-0005MJ-Kv for ancp-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:12:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAnmj-0005M8-9E for ancp@ietf.org; Tue, 17 Jul 2007 10:12:17 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IAnmf-0001TR-3S for ancp@ietf.org; Tue, 17 Jul 2007 10:12:17 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6HEAHUK026171; Tue, 17 Jul 2007 16:10:17 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Jul 2007 16:12:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Tue, 17 Jul 2007 16:12:08 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <009801c7c7f5$bb199780$242413ac@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfH9bphkunYlpj7QZWeNixZLlrk0QAeX5Wg References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> From: "OOGHE Sven" To: "Curtis Sherbo" , , , , X-OriginalArrivalTime: 17 Jul 2007 14:12:09.0585 (UTC) FILETIME=[76AC4610:01C7C87C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.1 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0602322952==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0602322952== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C87C.76682570" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C87C.76682570 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Please find my comments inline. =20 Regards, Sven ________________________________ From: Curtis Sherbo [mailto:csherbo@redback.com]=20 Sent: dinsdag 17 juli 2007 0:08 To: ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it; flefauch@cisco.com Subject: [ANCP] Comments on draft-maglione Greetings,=20 I think the flexibility of the solution proposed in draft-maglione-ancp-mcast-00.txt is necessary when you consider applications beyond simple broadcast IPTV. I think it is useful in certain scenarios in IPTV, but I also think it is useful in a few other applications as listed below: 1) Nomadicity/Roaming - whether wired or wireless it would be more effective to have a centralized policy decision as opposed to a distributed one. This is especially true in a wireless instance where a client may be moving from one access point to another, the session would need to be handed off, would you want to see a full authentication step each hop so that you can refresh policies on the access point?=20 I agree that there will be some central system that holds the subscriber policy information. In the case of nomadicity, this system will be in the "home network" (I don't mean customer premises network) and will need to be contacted by the "visiting network". This could be done in a push mode - bringing the relevant policy information to the network elements in the visiting network - or in a pull mode - outsourcing the decision to the home network. In my view, in the case of multicast, the push model leads to less signaling than the pull model (unless some special tricks based on session grouping with timeouts are introduced in access platforms - but these have their own issues as I highlighted in my previous email). Hence I'm more in favor of using the push model even in nomadic/roaming cases. 2) Video Conferencing - As conferences would likely be ad-hoc, where the multicast groups may not be known in advance, it would likely be more efficient to update data centrally and query it as a participants join conferences.=20 See next point. 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. To be noted, zap time is less of an issue with these three applications, as there is typically an accepted processing time.=20 Can you clarify what you mean with this?=20 Obviously it is not the job of the IETF to define these services or business models, but I thought it might be helpful for us to consider services beyond the starting point of IPTV. =20 As suggested by others on this list, the existing framework may be able to fulfill some of the requirements put forward by this draft, but I argue that there is validity in the flexibility that the draft brings for IPTV as well as support for the applications I have discussed here. I welcome your comments.=20 Cheers,=20 Curtis=20 Curtis Sherbo, P.Eng=20 Product Line Manager=20 Redback Networks Canada Inc.=20 Phone: (604)629-7357=20 Mobile: (604)250-0672=20 ------_=_NextPart_001_01C7C87C.76682570 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-maglione
Hi,
 
Please find my comments = inline.
 
Regards,
Sven

From: Curtis Sherbo = [mailto:csherbo@redback.com]=20
Sent: dinsdag 17 juli 2007 0:08
To: ancp@ietf.org;=20 roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it;=20 flefauch@cisco.com
Subject: [ANCP] Comments on=20 draft-maglione

Greetings,

I think the flexibility of the solution = proposed in=20 draft-maglione-ancp-mcast-00.txt is necessary when you consider = applications=20 beyond simple broadcast IPTV.

I think it is useful in certain scenarios = in IPTV,=20 but I also think it is useful in a few other applications as listed=20 below:

1) Nomadicity/Roaming - whether = wired or=20 wireless it would be more effective to have a centralized policy = decision as=20 opposed to a distributed one.  This is especially true in a = wireless=20 instance where a client may be moving from one access point to another, = the=20 session would need to be handed off, would you want to see a full = authentication=20 step each hop so that you can refresh policies on the access point? 

2) Video Conferencing - As = conferences would=20 likely be ad-hoc, where the multicast groups may not be known in = advance, it=20 would likely be more efficient to update data centrally and query it as = a=20 participants join conferences. 

See next point.

3) Future Over the Top Video Partnerships = - Service=20 providers may choose to partner with internet video providers to provide = QoS and=20 multicast capabilities through a partnership on a per event basis.  = Like=20 the video conferencing scenario, this would be somewhat ad-hoc where the = multicast group mappings may not be known in advance, or may be reused = for=20 different content in succession, requiring repeated policy = refresh.  Again,=20 a centralized approach would appear to be more scalable for this=20 model.

I agree that these are channels which may not be known = to the=20 access provider in advance. There's however an easy way to solve this = case:=20 thanks to IGMPv3 SSM, it is possible to create two categories of=20 channels:

-=20 those with a known IP source address: these would include e.g. the=20 access/service provider's own IPTV offering

-=20 those with an unknown IP source address: these would include over the = top video,=20 or video conferencing

The Access Node can use the IP source address = to filter=20 IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). = Within this=20 context, it could then decide to offer the content with the required = QoS, and=20 decide whether or not to accept or reject the = channel.

To be noted, zap time is less of an = issue with=20 these three applications, as there is typically an accepted processing=20 time. 

Can you clarify what you mean with=20 this? 

Obviously it is not the job of the IETF = to define=20 these services or business models, but I thought it might be helpful for = us to=20 consider services beyond the starting point of IPTV. 

As suggested by others on this list, the = existing=20 framework may be able to fulfill some of the requirements put forward by = this=20 draft, but I argue that there is validity in the flexibility that the = draft=20 brings for IPTV as well as support for the applications I have discussed = here.

I welcome your comments.

Cheers,
Curtis

Curtis Sherbo, P.Eng
Product Line Manager
Redback Networks=20 Canada Inc.
Phone: = (604)629-7357=20
Mobile: (604)250-0672 =

------_=_NextPart_001_01C7C87C.76682570-- --===============0602322952== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0602322952==-- From ancp-bounces@ietf.org Tue Jul 17 10:53:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoQF-00085W-2z; Tue, 17 Jul 2007 10:53:07 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IAoQ8-0007rS-7g for ancp-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 10:53:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IAoQ7-0007qt-L1 for ancp@ietf.org; Tue, 17 Jul 2007 10:52:59 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IAoQ5-0002X9-8b for ancp@ietf.org; Tue, 17 Jul 2007 10:52:59 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6HEp0jL016681; Tue, 17 Jul 2007 16:51:00 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Jul 2007 16:52:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Jul 2007 16:52:52 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B16180@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4D703100-BFEA-49E1-805C-2908128A2C66@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-maglione-ancp-mcast-00.txt Thread-Index: AcfIcteEbrUmH+8qQsWNT9qrWr24uwACzNbQ References: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> <4D703100-BFEA-49E1-805C-2908128A2C66@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 17 Jul 2007 14:52:53.0123 (UTC) FILETIME=[27229530:01C7C882] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.1 (/) X-Scan-Signature: 312bb437839230b5894c6b1686dbca1d Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org Subject: [ANCP] RE: Comments on draft-maglione-ancp-mcast-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0458257151==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0458257151== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C882.26F07FB4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C882.26F07FB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, =20 Thanks for the feedback. See my comments inline. =20 ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: dinsdag 17 juli 2007 15:00 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it Subject: Re: Comments on draft-maglione-ancp-mcast-00.txt Hello Sven,=20 Thanks for kicking off the discussion and sharing your views. Some thoughts below: On 16 Jul 2007, at 12:18, OOGHE Sven wrote: Hi,=20 I would like to initiate a thread related to draft-maglione-ancp-mcast-00.txt describing how to use ANCP for multicasting. Here are my thoughts on the described use cases. Multicast Conditional Access=20 I agree on using ANCP for the sake of provisioning conditional access information on an Access Node (AN), so that it can take autonomous decisions lateron. It seems to me that even the most complex conditional access control scenarios can be handled using relatively simple policies in the ANs, with these policies dynamically altered as needed to address the conditional aspect. For example, if a subscriber is authorized to view a particular channel only after 11PM, it seems simpler to me to push a new policy to the AN at 11PM than to force the AN to query the NAS for every attempt to join that channel. I'm therefore not convinced about using ANCP for the AN to query the NAS, that in turn will respond to the AN indicating whether the join is to be honored or denied. Just to be very clear, the idea is not to force that NAS be systematically queried of course. In many cases, a simple Conditional policy can be provisioned (or-reprovisioned) via ANCP into the Access Node. The proposal includes the White-List/Black-Lists for these cases. In fact, one may only use these mechanisms in a given environment.=20 =20 Agreed. All I'm saying above is that in my view, this approach is sufficient to cover all cases mentioned in the bullet points in the ANCP Framework & Requirements draft. =20 However, some applications call for more flexibility. For example some applications appear better served by querying a remote authorization server (via NAS). This may be for example because the authorized membership is not known ahead of time and changes dynamically. We feel ANCP should allow such scenarios.=20 =20 In my view, whenever an IGMP message needs to be processed by an Access Node, aggregation switch or NAS, the policy/resource information should be readily available. That's why I am advocating the White-List/Black-List model for multicast applications. Perhaps for other applications the flexibility could be useful, but at least in the case of multicast, I remain to be convinced of what those applications are. Multicast Admission Control=20 The general notion of resource admission control is an important one. The draft mentions a number of aspects which are indeed of a concern when deploying a triple play network architecture with both Video on Demand and Broadcast TV flows. The draft proposes that the AN outsources a recource decision for a multicast stream to the NAS. In my view this is not the best approach. Normally, it would require signaling from the AN to the NAS at each channel zap. The draft proposes the introduction of a "Multicast Flow-Group" to reduce the signaling load; this creates a new problem: how to signal the termination of the reservation for a flow-group to the NAS? This requires some time-out mechanism on the AN that releases resources only after a flow-group has no active flows for some period of time. However, such a timer would block the startup of unicast flows for a short window following a leave of the last flow in a group. This appears a highly undesirable effect. In my view, the resource admission control aspects for the access line are instead best handled by the AN. This also calls for some synchronization mechanism between AN, NAS and policy servers, but different from what is described in this draft. These CAC concepts must be addressed in a scope that is much broader than the ANCP WG. While I agree that defining the overall CAC solution is broader than the ANCP WG, the "black-box principle" agreed in Prague suggests that ANCP needs to provide the necessary flow of information across the boxes (where some functions are done by one box but affect the other one).=20 =20 I agree that ANCP plays a role in making sure that the AN+NAS tandem behaves as a single black box. The framework draft was updated to reflect this principle and highlight the top-level objectives of the multicast architecture. =20 For Video CAC to work across the two boxes with full functionality, this includes allowing sharing of bandwidth between unicast CAC and multicast CAC. =20 =20 I also agree that the sharing of bandwidth amongst unicast and multicast CAC is a requirement in some network architectures. With the Access Node being aware of the access line and multicast signaling, and the policy system / NAS being aware of the aggregation network and unicast resources, this indeed calls for a synchronziation mechanisms amongst Access Node, NAS and Policy Server. This draft focuses on the Access Node and NAS components, but I think we also need to look at the Policy Server as part of the network architecture. This gives rise to other possible solutions, which are broader than the scope of the ANCP WG. For sure we need to address this, perhaps by involving other standards organizations working on this. The ANCP Requirements & Framework I-D seems to be assuming this too : " Specifically, when performing multicast replication in the access/aggregation network, the following features must remain supported by the logical NAS: ... o Connection admission control (CAC) for multicast and/or unicast services " Sure, these are the top-level requirements. The framework doesn't state how these are to be filled in. ANCP plays a role here, but nowhere is it implied what specific message flow is being used. With respect to resource admission control for the access line, I suspect that different deployment approaches will be selected for different networks. Some of these deployment approaches involve handling bandwidth allocation for unicast CAC on the NAS, some involve synchronizing to a remote server doing unicast CAC via NAS. We feel that ANCP should not preclude these important deployment models.=20 =20 I agree that we need to cover cases where unicast and multicast CAC are either done on separate or shared resources. I think there's different ways to do this, each with their pros and cons.=20 =20 Again, the corresponding mechanisms do not have to be used in all deployments. Replication Termination=20 Similar to the basic notion of Multicast Conditional Access, it should be possible to revoke authorization to join a channel at any time by pushing a new policy to the AN that indicates that the subscriber is no longer allowed to join the channel. Again, this is simpler than performing an ANCP admission request for each join. As you said: this is tied to the discussion on Conditional Access above. If we accept that, _for some applications_, it is more efficient to query a more centralised authorization repository than try dynamically permanently change/rechange the corresponding policy rules on every AN, then I think it is useful to have the corresponding ability to selectively revoke an earlier authorization. If we don't accept it, then the revoke mechanism is not needed. Based on the above, I believe that most of the flows in the draft can be simplified considerably, while still meeting the objectives set forward in the ANCP framework. Well, I think there is agreement that the current Framework & Requirements I-D does yet not fully cover the Multicast use cases. Right?=20 =20 We aimed to update the framework to stay high level, yet reflect the key requirements that the architecture needs to fulfill. I agree that this leaves the details of the architecture, message flows and protocol design open. These can be worked out while keeping the framework document at the hig level. =20 Regards, Sven =20 This is why the proposal suggests Multicast specific extensions for the ANCP Framework & Requirement document. Cheers Francois Regards,=20 Sven=20 ------_=_NextPart_001_01C7C882.26F07FB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
Thanks for the feedback. See my comments=20 inline.
 
From: Francois Le Faucheur IMAP=20 [mailto:flefauch@cisco.com]
Sent: dinsdag 17 juli 2007=20 15:00
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP;=20 ancp@ietf.org; roberta.maglione@telecomitalia.it;=20 angelo.garofalo@telecomitalia.it
Subject: Re: Comments on=20 draft-maglione-ancp-mcast-00.txt

Hello Sven,

Thanks for kicking off the discussion and sharing your views. Some = thoughts=20 below:

On 16 Jul 2007, at 12:18, OOGHE Sven wrote:

Hi,

I would like to initiate a thread = related to=20 draft-maglione-ancp-mcast-00.txt describing how to use ANCP for = multicasting.=20 Here are my thoughts on the described use cases.

Multicast Conditional = Access=20

I agree on using ANCP for the sake of = provisioning=20 conditional access information on an Access Node (AN), so that it can = take=20 autonomous decisions lateron.

It seems to me that even the most = complex=20 conditional access control scenarios can be handled using relatively = simple=20 policies in the ANs, with these policies dynamically altered as needed = to=20 address the conditional aspect. For example, if a subscriber is = authorized to=20 view a particular channel only after 11PM, it seems simpler to me to = push a=20 new policy to the AN at 11PM than to force the AN to query the NAS for = every=20 attempt to join that channel.

I'm therefore not convinced about using = ANCP for=20 the AN to query the NAS, that in turn will respond to the AN = indicating=20 whether the join is to be honored or denied.

Just to be very clear, the idea is not to force that NAS be = systematically=20 queried of course. In many cases, a simple Conditional policy can be = provisioned=20 (or-reprovisioned) via ANCP into the Access Node. The proposal includes = the=20 White-List/Black-Lists for these cases. In fact, one may only use these=20 mechanisms in a given environment. 
 
Agreed. All I'm saying above is that in my = view, this=20 approach is sufficient to cover all cases mentioned in the bullet points = in the=20 ANCP Framework & Requirements draft.
 
However, some applications call for more flexibility. For example = some=20 applications appear better served by querying a remote authorization = server (via=20 NAS). This may be for example because the authorized membership is not = known=20 ahead of time and changes dynamically. We feel ANCP should allow such=20 scenarios. 
 
In my=20 view, whenever an IGMP message needs to be processed by an Access Node,=20 aggregation switch or NAS, the policy/resource information should be = readily=20 available. That's why I am advocating the White-List/Black-List = model for=20 multicast applications. Perhaps for other applications the flexibility = could be=20 useful, but at least in the case of multicast, I remain to be convinced = of what=20 those applications are.

Multicast Admission = Control

The general notion of resource = admission control is=20 an important one. The draft mentions a number of aspects which are = indeed of a=20 concern when deploying a triple play network architecture with both = Video on=20 Demand and Broadcast TV flows.

The draft proposes that the AN = outsources a=20 recource decision for a multicast stream to the NAS. In my view this = is not=20 the best approach. Normally, it would require signaling from the AN to = the NAS=20 at each channel zap. The draft proposes the introduction of a = "Multicast=20 Flow-Group" to reduce the signaling load; this creates a new problem: = how to=20 signal the termination of the reservation for a flow-group to the NAS? = This=20 requires some time-out mechanism on the AN that releases resources = only after=20 a flow-group has no active flows for some period of time. However, = such a=20 timer would block the startup of unicast flows for a short window = following a=20 leave of the last flow in a group. This appears a highly undesirable=20 effect.

In my view, the resource admission = control aspects=20 for the access line are instead best handled by the AN. This also = calls for=20 some synchronization mechanism between AN, NAS and policy servers, but = different from what is described in this draft. These CAC concepts = must be=20 addressed in a scope that is much broader than the ANCP=20 WG.

While I agree that defining the overall CAC solution is broader = than the=20 ANCP WG, the "black-box principle" agreed in Prague suggests that = ANCP=20 needs to provide the necessary flow of information across the boxes = (where some=20 functions are done by one box but affect the other one). 
 
I=20 agree that ANCP plays a role in making sure that the AN+NAS tandem = behaves as a=20 single black box. The framework draft was updated to reflect this = principle and=20 highlight the top-level objectives of the multicast=20 architecture.
 
 For Video CAC to work = across=20 the two boxes with full functionality, this includes allowing = sharing of=20 bandwidth between unicast CAC and multicast CAC.  
 
I=20 also agree that the sharing of bandwidth amongst unicast and = multicast CAC=20 is a requirement in some network architectures. With the Access = Node being=20 aware of the access line and multicast signaling, and the policy system = / NAS=20 being aware of the aggregation network and unicast resources, this = indeed calls=20 for a synchronziation mechanisms amongst Access Node, NAS and Policy = Server.=20 This draft focuses on the Access Node and NAS components, but I think we = also=20 need to look at the Policy Server as part of the network architecture. = This=20 gives rise to other possible solutions, which are broader than the scope = of the=20 ANCP WG. For sure we need to address this, perhaps by involving other = standards=20 organizations working on this.
The ANCP Requirements & Framework I-D seems to be assuming this = too :
"
   Specifically, when performing multicast replication in = the=20 access/aggregation network, the following features must remain supported = by
   the logical NAS:
...
   o  Connection admission control (CAC) for = multicast=20 and/or unicast services
"
Sure,=20 these are the top-level requirements. The framework doesn't state how = these are=20 to be filled in. ANCP plays a role here, but nowhere is it implied what = specific=20 message flow is being used.

With respect to resource admission control for the access line, I = suspect=20 that different deployment approaches will be selected for different = networks.=20 Some of these deployment approaches involve handling bandwidth = allocation for=20 unicast CAC on the NAS, some involve synchronizing to a remote server = doing=20 unicast CAC via NAS. We feel that ANCP should not preclude these = important=20 deployment models. 
 
I=20 agree that we need to cover cases where unicast and multicast CAC are = either=20 done on separate or shared resources. I think there's different ways to = do this,=20 each with their pros and cons.
 
 Again, the = corresponding=20 mechanisms do not have to be used in all deployments.

Replication Termination =

Similar to the basic notion of = Multicast=20 Conditional Access, it should be possible to revoke authorization to = join a=20 channel at any time by pushing a new policy to the AN that indicates = that the=20 subscriber is no longer allowed to join the channel. Again, this is = simpler=20 than performing an ANCP admission request for each = join.

As you said: this is tied to the discussion on Conditional Access = above. If=20 we accept that, _for some applications_, it is more efficient to query a = more=20 centralised authorization repository than try dynamically permanently=20 change/rechange the corresponding policy rules on every AN, then I think = it is=20 useful to have the corresponding ability to selectively revoke an = earlier=20 authorization. If we don't accept it, then the revoke mechanism is not=20 needed.

Based on the above, I believe that most = of the=20 flows in the draft can be simplified considerably, while still meeting = the=20 objectives set forward in the ANCP framework.

Well, I think there is agreement that the current Framework &=20 Requirements I-D does yet not fully cover the Multicast use cases. = Right? 
 
We=20 aimed to update the framework to stay high level, yet reflect the = key=20 requirements that the architecture needs to fulfill. I agree that this = leaves=20 the details of the architecture, message flows and protocol design open. = These=20 can be worked out while keeping the framework document at the hig=20 level.
 
Regards,
Sven
 
This is why the proposal suggests Multicast specific extensions for = the=20 ANCP Framework & Requirement document.

Cheers
Francois


Regards,
Sven


------_=_NextPart_001_01C7C882.26F07FB4-- --===============0458257151== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0458257151==-- From ancp-bounces@ietf.org Tue Jul 17 12:09:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApbg-0000yt-Rj; Tue, 17 Jul 2007 12:09:00 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IApbg-0000yi-95 for ancp-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:09:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApbf-0000ya-V6 for ancp@ietf.org; Tue, 17 Jul 2007 12:08:59 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IApbf-0005X2-9H for ancp@ietf.org; Tue, 17 Jul 2007 12:08:59 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2007 18:08:57 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAMaFnEaQ/uCKh2dsb2JhbACCLTWMYgEBCQon X-IronPort-AV: i="4.16,546,1175464800"; d="scan'208,217"; a="148277782:sNHT61733602" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6HG8uge004658; Tue, 17 Jul 2007 18:08:56 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HG8nkt013383; Tue, 17 Jul 2007 16:08:49 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 18:08:49 +0200 Received: from [10.0.0.15] ([10.61.65.250]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 18:08:49 +0200 In-Reply-To: <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Comments on draft-maglione Date: Tue, 17 Jul 2007 18:05:51 +0200 To: "OOGHE Sven" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 17 Jul 2007 16:08:49.0230 (UTC) FILETIME=[C2C956E0:01C7C88C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5176; t=1184688536; x=1185552536; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Comments=20on=20draft-maglione |Sender:=20; bh=1RCX+zHS1qVeYz/M/fsmpEJ+HvyPI0wmbavzkiPvp4I=; b=rw6farm4Qsdi2Mhv89l4De6fa7ML9dMvr/2IzuCzkHOgym6dZwZ5EQoZ0HYhcuIS4n+wV/Eq GngTN9tPPddSECOvIzJ0ndIslatfrivjj7tHkPoECfC2atdk1pDXbKeT; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ancp@ietf.org, angelo.garofalo@telecomitalia.it X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2017542778==" Errors-To: ancp-bounces@ietf.org --===============2017542778== Content-Type: multipart/alternative; boundary=Apple-Mail-28-222721596 --Apple-Mail-28-222721596 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Sven, On 17 Jul 2007, at 16:12, OOGHE Sven wrote: > 3) Future Over the Top Video Partnerships - Service providers may > choose to partner with internet video providers to provide QoS and > multicast capabilities through a partnership on a per event basis. > Like the video conferencing scenario, this would be somewhat ad-hoc > where the multicast group mappings may not be known in advance, or > may be reused for different content in succession, requiring > repeated policy refresh. Again, a centralized approach would > appear to be more scalable for this model. > > I agree that these are channels which may not be known to the > access provider in advance. There's however an easy way to solve > this case: thanks to IGMPv3 SSM, it is possible to create two > categories of channels: > > - those with a known IP source address: these would include e.g. > the access/service provider's own IPTV offering > > - those with an unknown IP source address: these would include over > the top video, or video conferencing > > The Access Node can use the IP source address to filter IGMPv3's in > different replication contexts (e.g. IPTV, Internet TV). Within > this context, it could then decide to offer the content with the > required QoS, and decide whether or not to accept or reject the > channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership. For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports. Am I missing something? Thanks Francois --Apple-Mail-28-222721596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Sven,

On 17 = Jul 2007, at 16:12, OOGHE Sven wrote:

3) Future Over the Top Video Partnerships - = Service providers may choose to partner with internet video providers to = provide QoS and multicast capabilities through a partnership on a per = event basis.=A0 Like the video conferencing scenario, this would be = somewhat ad-hoc where the multicast group mappings may not be known in = advance, or may be reused for different content in succession, requiring = repeated policy refresh.=A0 Again, a centralized approach would appear = to be more scalable for this model.

I agree that these are channels which may not be known = to the access provider in advance. There's however an easy way to solve = this case: thanks to IGMPv3 SSM, it is possible to create two categories = of channels:

- those = with a known IP source address: these would include e.g. the = access/service provider's own IPTV = offering

- those = with an unknown IP source address: these would include over the top = video, or video conferencing

The Access Node can use the IP source = address to filter IGMPv3's in different replication contexts (e.g. IPTV, = Internet TV). Within this context, it could then decide to offer the = content with the required QoS, and decide whether or not to accept or = reject the channel.

I don't = quite see how that solves the core issues mentioned by Curtis:
What = you describes allow to separate out the provider's channels from = everything else (the Internet OTT services, Video Conference). But we = still have to deal with the dynamic allocation/reallocation of channels = to the "Everything else" applications with possibly large and fast = changing membership. For those, it seems more efficient to use a "more = centralized" repository than attempting to permanently = update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all = affected ANs/AN-ports.=A0
Am I missing = something?

Thanks

Francois

= --Apple-Mail-28-222721596-- --===============2017542778== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============2017542778==-- From ancp-bounces@ietf.org Tue Jul 17 12:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApqg-0002cB-D4; Tue, 17 Jul 2007 12:24:30 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IApqb-0002bj-Su for ancp-confirm+ok@megatron.ietf.org; Tue, 17 Jul 2007 12:24:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IApqb-0002bX-HS for ancp@ietf.org; Tue, 17 Jul 2007 12:24:25 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IApqZ-0006Ve-U8 for ancp@ietf.org; Tue, 17 Jul 2007 12:24:25 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Jul 2007 18:24:23 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAEqJnEaQ/uCLh2dsb2JhbACCYoxiAQEJCic X-IronPort-AV: i="4.16,546,1175464800"; d="scan'208,217"; a="148279330:sNHT118770702" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6HGOMJC028750; Tue, 17 Jul 2007 18:24:22 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6HGNxkx018977; Tue, 17 Jul 2007 16:24:22 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 18:24:21 +0200 Received: from [10.0.0.15] ([10.61.65.250]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Jul 2007 18:24:20 +0200 In-Reply-To: <8144761F31F48D43AD53D09F5350E380B16180@FRVELSMBS22.ad2.ad.alcatel.com> References: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> <4D703100-BFEA-49E1-805C-2908128A2C66@cisco.com> <8144761F31F48D43AD53D09F5350E380B16180@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Francois Le Faucheur IMAP Date: Tue, 17 Jul 2007 18:21:24 +0200 To: "OOGHE Sven" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 17 Jul 2007 16:24:20.0846 (UTC) FILETIME=[EE12A8E0:01C7C88E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3499; t=1184689462; x=1185553462; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Comments=20on=20draft-maglione-ancp-mcast-00.txt |Sender:=20; bh=mU07yubT8Q4VRZqiQbk1+gQsd4LQomIaz8+PmF2VXUo=; b=NWwx+YFE/OceS8/lq/AytBz0cWYZIr8KJ93enoo5H5op1j5mQU3A5BxPBK1CX8NNDNfYC3hr o04/ZtZBbIFD1fRED7lXtgpDgLSiI/4PVpscsd4UO4iNAuxctarsDevN; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org Subject: [ANCP] Re: Comments on draft-maglione-ancp-mcast-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1889866632==" Errors-To: ancp-bounces@ietf.org --===============1889866632== Content-Type: multipart/alternative; boundary=Apple-Mail-29-223654075 --Apple-Mail-29-223654075 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Sven and all, > Well, I think there is agreement that the current Framework & > Requirements I-D does yet not fully cover the Multicast use cases. > Right? > > We aimed to update the framework to stay high level, yet reflect > the key requirements that the architecture needs to fulfill. I > agree that this leaves the details of the architecture, message > flows and protocol design open. These can be worked out while > keeping the framework document at the hig level. My assumption is that the "Framework and Requirements" document is intended to define not just the ANCP high level requirements but also the key message flows so that the protocol can be designed based on this. This is exactly what has been done for the use cases currently covered (3.1, 3.2 and 3.3). For each of those, there is a description of what sort of primitives (query/response) are needed between AN and NAS and what are the key parameters for those. Do we not agree that the objective is exactly the same for the Multicast use case (ie identify the message flow and key parameters)? Thanks Francois --Apple-Mail-29-223654075 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Sven and all,


Well, I think there is agreement that the = current Framework & Requirements I-D does yet not fully cover the = Multicast use cases. Right?=A0
=
=A0
We aimed to update the framework=A0to stay high level, yet = reflect the key requirements that the architecture needs to fulfill. I = agree that this leaves the details of the architecture, message flows = and protocol design open. These can be worked out while keeping the = framework document at the hig level.
=

My assumption is that the = "Framework and Requirements" document is intended to define not just the = ANCP high level requirements but also the key message flows so that the = protocol can be designed based on this.
This is exactly what = has been done for the use cases currently covered (3.1, 3.2 and 3.3). = For each of those, there is a description of what sort of primitives = (query/response) are needed between AN and NAS and what are the key = parameters for those.

Do we not agree that the = objective is exactly the same for the Multicast use case (ie identify = the message flow and key parameters)?

Thanks

Francois


= --Apple-Mail-29-223654075-- --===============1889866632== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1889866632==-- From ancp-bounces@ietf.org Wed Jul 18 05:22:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5jv-0007Gk-J4; Wed, 18 Jul 2007 05:22:35 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IB5jv-0007E5-2n for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 05:22:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5jr-00070f-CH for ancp@ietf.org; Wed, 18 Jul 2007 05:22:31 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB5jn-0002vp-3S for ancp@ietf.org; Wed, 18 Jul 2007 05:22:31 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6I9M4S5026788; Wed, 18 Jul 2007 11:22:04 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Jul 2007 11:22:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Wed, 18 Jul 2007 11:22:21 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfIjMuw3Ie3lU4HRymyFsjltzrlogAjPrLg References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 18 Jul 2007 09:22:23.0336 (UTC) FILETIME=[2612F680:01C7C91D] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.1 (/) X-Scan-Signature: 93b4f10b2112e1468b61e19ea6180478 Cc: ancp@ietf.org, angelo.garofalo@telecomitalia.it X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1538452972==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1538452972== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C91D.25C9B269" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C91D.25C9B269 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: dinsdag 17 juli 2007 18:06 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; Curtis Sherbo; ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it Subject: Re: [ANCP] Comments on draft-maglione Hi Sven,=20 On 17 Jul 2007, at 16:12, OOGHE Sven wrote: 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. =20 Regards, Sven=20 Thanks Francois ------_=_NextPart_001_01C7C91D.25C9B269 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,

From: Francois Le Faucheur IMAP=20 [mailto:flefauch@cisco.com]
Sent: dinsdag 17 juli 2007=20 18:06
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP; = Curtis=20 Sherbo; ancp@ietf.org; roberta.maglione@telecomitalia.it;=20 angelo.garofalo@telecomitalia.it
Subject: Re: [ANCP] Comments = on=20 draft-maglione

Hi Sven,

On 17 Jul 2007, at 16:12, OOGHE Sven wrote:

3) Future Over the Top Video = Partnerships - Service=20 providers may choose to partner with internet video providers to = provide QoS=20 and multicast capabilities through a partnership on a per event = basis. =20 Like the video conferencing scenario, this would be somewhat ad-hoc = where the=20 multicast group mappings may not be known in advance, or may be reused = for=20 different content in succession, requiring repeated policy = refresh. =20 Again, a centralized approach would appear to be more scalable for = this=20 model.

I agree that these are channels which may not be known = to the=20 access provider in advance. There's however an easy way to solve this = case:=20 thanks to IGMPv3 SSM, it is possible to create two categories of=20 channels:

- those with a known IP source address: = these would=20 include e.g. the access/service provider's own IPTV=20 offering

- those with an unknown IP source address: = these=20 would include over the top video, or video=20 conferencing

The Access Node can use the IP source = address to=20 filter IGMPv3's in different replication contexts (e.g. IPTV, Internet = TV).=20 Within this context, it could then decide to offer the content with = the=20 required QoS, and decide whether or not to accept or reject the=20 channel.

I don't quite see how that solves the core issues mentioned by=20 Curtis:
What you describes allow to separate out the provider's channels = from=20 everything else (the Internet OTT services, Video Conference). But we = still have=20 to deal with the dynamic allocation/reallocation of channels to the = "Everything=20 else" applications with possibly large and fast changing = membership. 
 
Correct, I should have made this more explicit in my previous=20 reply. When using IGMPv3 with SSM, the information to locally = decide=20 whether or not to accept an IGMP report may or may not be present in the = replication context on the Access Node.
 
 For those, it seems = more=20 efficient to use a "more centralized" repository than attempting to = permanently=20 update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all = affected=20 ANs/AN-ports. 
Am I missing something?
 
Well,=20 perhaps we should do the math and count the amount of=20 messages...
 
. In=20 case of configuring the White-List/Black-List info, you'd configure the = info at=20 subscription time or when the IP session starts/ends. Typical example is = the=20 establishment of a PPP connection or DHCP lease. At this point, the AAA = system=20 will be contacted, which would be linked to the policy system containing = the=20 user's multicast viewing rights. Those would then be sent to the Access = Node,=20 and need to be released when the session ends. There's indeed some = updating and=20 re-updating going on. But typically, a session can last for one or = several hours=20 (or could even be always-on), and the policy information may well be = stable for=20 long periods of time within that session.
 
. In=20 case of contacting the central repository upon receiving an IGMP, you = would have=20 such an exchange at every channel zap. Whithin the session, it is likely = that a=20 subscriber will issue several IGMP messages to zap through channels. The = number=20 of message exchanges with the central respository will then be higher = than in=20 the first case.
To=20 reduce the message load, one could make use of some form of channel = grouping to send a bulk of policy information to the Access Node (cf. = what is=20 mentioned in the draft), but in my view this brings us very close to the = first=20 case again, and makes me wonder if it would not be simpler to send all = required=20 channel information to the Access Node at the start of the = session. There=20 may still be a need to do some in-session policy configuration changes = on the=20 Access Node, but even with this additional load, the resulting message = load will=20 never be higher than in the case of checking with the central policy=20 server.
 
Regards,
Sven 
Thanks

Francois

------_=_NextPart_001_01C7C91D.25C9B269-- --===============1538452972== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1538452972==-- From ancp-bounces@ietf.org Wed Jul 18 05:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5pD-00046E-T4; Wed, 18 Jul 2007 05:28:03 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IB5pD-000468-9p for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 05:28:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB5pC-00045y-W0 for ancp@ietf.org; Wed, 18 Jul 2007 05:28:02 -0400 Received: from gc-na5.alcatel.fr ([64.208.49.5] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB5pB-0002KU-Br for ancp@ietf.org; Wed, 18 Jul 2007 05:28:02 -0400 Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6I9Rd9l028818; Wed, 18 Jul 2007 11:27:39 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Jul 2007 11:27:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 11:27:57 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B164AC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-maglione-ancp-mcast-00.txt Thread-Index: AcfIjvD8keckYDVjTymfxZvnJC2LVQAjjnRw References: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> <4D703100-BFEA-49E1-805C-2908128A2C66@cisco.com> <8144761F31F48D43AD53D09F5350E380B16180@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 18 Jul 2007 09:27:58.0222 (UTC) FILETIME=[EDAE82E0:01C7C91D] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org Subject: [ANCP] RE: Comments on draft-maglione-ancp-mcast-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1499142854==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1499142854== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C91D.ED7B14DB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C91D.ED7B14DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]=20 Sent: dinsdag 17 juli 2007 18:21 To: OOGHE Sven Cc: Francois Le Faucheur IMAP; ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it Subject: Re: Comments on draft-maglione-ancp-mcast-00.txt Sven and all,=20 Well, I think there is agreement that the current Framework & Requirements I-D does yet not fully cover the Multicast use cases. Right?=20 =20 We aimed to update the framework to stay high level, yet reflect the key requirements that the architecture needs to fulfill. I agree that this leaves the details of the architecture, message flows and protocol design open. These can be worked out while keeping the framework document at the hig level. My assumption is that the "Framework and Requirements" document is intended to define not just the ANCP high level requirements but also the key message flows so that the protocol can be designed based on this. This is exactly what has been done for the use cases currently covered (3.1, 3.2 and 3.3). For each of those, there is a description of what sort of primitives (query/response) are needed between AN and NAS and what are the key parameters for those. Do we not agree that the objective is exactly the same for the Multicast use case (ie identify the message flow and key parameters)? =20 We need to work out the details of multcast, that's for sure. The framework stays at a high level, and the reason for doing that is that we tried to reflect the concensus of the last IETF meeting, cf. minutes below: =20 http://www3.ietf.org/proceedings/07mar/minutes/ancp.txt =20 "1. Framework text to be added on two boxes (NAS and AN) connected via ANCP that functionally look like one black box=20 2. For multicast section framework text needs black box level multicast use-cases that follow the principle of multicast replication on the AN but no loss of functionality. CAC is part of this, but addressing the full unicast+multicast CAC system solution is not in scope of ANCP WG. The existence of the CAC use-case is to be noted and ANCP mechanism designed to fit as best as possible.=20 3. More detailed solution proposals to be brought in as part of the ANCP protocol specification work." =20 Regards, Sven Thanks Francois ------_=_NextPart_001_01C7C91D.ED7B14DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,

From: Francois Le Faucheur IMAP=20 [mailto:flefauch@cisco.com]
Sent: dinsdag 17 juli 2007=20 18:21
To: OOGHE Sven
Cc: Francois Le Faucheur IMAP;=20 ancp@ietf.org; roberta.maglione@telecomitalia.it;=20 angelo.garofalo@telecomitalia.it
Subject: Re: Comments on=20 draft-maglione-ancp-mcast-00.txt

Sven and all,
Well, I think there is agreement that the current Framework & = Requirements I-D does yet not fully cover the Multicast use cases. = Right? 
 
We=20 aimed to update the framework to stay high level, yet reflect the = key=20 requirements that the architecture needs to fulfill. I agree that this = leaves=20 the details of the architecture, message flows and protocol design = open. These=20 can be worked out while keeping the framework document at the hig=20 level.

My assumption is that the "Framework and Requirements" document is = intended=20 to define not just the ANCP high level requirements but also the key = message=20 flows so that the protocol can be designed based on this.
This is exactly what has been done for the use cases currently = covered=20 (3.1, 3.2 and 3.3). For each of those, there is a description of what = sort of=20 primitives (query/response) are needed between AN and NAS and what are = the key=20 parameters for those.
Do we not agree that the objective is exactly the same for the = Multicast=20 use case (ie identify the message flow and key parameters)?
 
We=20 need to work out the details of multcast, that's for sure. The framework = stays=20 at a high level, and the reason for doing that is that we tried to = reflect the=20 concensus of the last IETF meeting, cf. minutes = below:
 
http://w= ww3.ietf.org/proceedings/07mar/minutes/ancp.txt
 
"1.=20 Framework text to be added on two boxes (NAS and AN) connected via ANCP = that=20 functionally look like one black box
2. For multicast section = framework text=20 needs black box level multicast use-cases that follow the principle of = multicast=20 replication on the AN but no loss of functionality. CAC is part of this, = but=20 addressing the full unicast+multicast CAC system solution is not in = scope of=20 ANCP WG. The existence of the CAC use-case is to be noted and ANCP = mechanism=20 designed to fit as best as possible.
3. More detailed solution = proposals to=20 be brought in as part of the ANCP protocol specification=20 work."
 
Regards,
Sven

Thanks

Francois


------_=_NextPart_001_01C7C91D.ED7B14DB-- --===============1499142854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1499142854==-- From ancp-bounces@ietf.org Wed Jul 18 06:52:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB792-0002Xe-Mj; Wed, 18 Jul 2007 06:52:36 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IB791-0002LH-39 for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 06:52:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB790-0002HB-1s for ancp@ietf.org; Wed, 18 Jul 2007 06:52:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB78y-0004kB-Na for ancp@ietf.org; Wed, 18 Jul 2007 06:52:34 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 12:52:31 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAALSNnUaQ/uCLh2dsb2JhbACCYoxhAQEJCic X-IronPort-AV: i="4.16,550,1175464800"; d="scan'208,217"; a="148353852:sNHT305274484" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6IAqVo3000860; Wed, 18 Jul 2007 12:52:31 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6IAqGlF008757; Wed, 18 Jul 2007 10:52:31 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:52:18 +0200 Received: from [10.0.0.15] ([10.61.65.174]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:52:17 +0200 In-Reply-To: <8144761F31F48D43AD53D09F5350E380B164AC@FRVELSMBS22.ad2.ad.alcatel.com> References: <8144761F31F48D43AD53D09F5350E380A6EE36@FRVELSMBS22.ad2.ad.alcatel.com> <4D703100-BFEA-49E1-805C-2908128A2C66@cisco.com> <8144761F31F48D43AD53D09F5350E380B16180@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380B164AC@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <729ECB4A-AE04-4160-B72D-5431A0BFBDD1@cisco.com> From: Francois Le Faucheur IMAP Date: Wed, 18 Jul 2007 12:49:20 +0200 To: "OOGHE Sven" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jul 2007 10:52:17.0884 (UTC) FILETIME=[B579A9C0:01C7C929] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11371; t=1184755951; x=1185619951; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20Comments=20on=20draft-maglione-ancp-mcast-00.txt |Sender:=20; bh=hl75131Z57kKyYVBPDZGVfjpWHOY7x32kR+DkYYxuFE=; b=eh11CG2ER9lKOsQZfzTXkiR4pXXtMZARz6W0459H2RYhbp8BrlWmGcaz1jZgDwV9mwCtK7PV un9OIyjaDKunQLYtvQ1epZSA5pwEO6fRRbZe8EM4ofotwGvPo8qx7LRH; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: ff0adf256e4dd459cc25215cfa732ac1 Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org Subject: [ANCP] Re: Comments on draft-maglione-ancp-mcast-00.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1082744164==" Errors-To: ancp-bounces@ietf.org --===============1082744164== Content-Type: multipart/alternative; boundary=Apple-Mail-32-290130628 --Apple-Mail-32-290130628 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Sven, On 18 Jul 2007, at 11:27, OOGHE Sven wrote: > Hi Francois, > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: dinsdag 17 juli 2007 18:21 > To: OOGHE Sven > Cc: Francois Le Faucheur IMAP; ancp@ietf.org; > roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it > Subject: Re: Comments on draft-maglione-ancp-mcast-00.txt > > Sven and all, > > >> Well, I think there is agreement that the current Framework & >> Requirements I-D does yet not fully cover the Multicast use cases. >> Right? >> >> We aimed to update the framework to stay high level, yet reflect >> the key requirements that the architecture needs to fulfill. I >> agree that this leaves the details of the architecture, message >> flows and protocol design open. These can be worked out while >> keeping the framework document at the hig level. > > My assumption is that the "Framework and Requirements" document is > intended to define not just the ANCP high level requirements but > also the key message flows so that the protocol can be designed > based on this. > This is exactly what has been done for the use cases currently > covered (3.1, 3.2 and 3.3). For each of those, there is a > description of what sort of primitives (query/response) are needed > between AN and NAS and what are the key parameters for those. > Do we not agree that the objective is exactly the same for the > Multicast use case (ie identify the message flow and key parameters)? > > We need to work out the details of multcast, that's for sure. The > framework stays at a high level, and the reason for doing that is > that we tried to reflect the concensus of the last IETF meeting, > cf. minutes below: I agree that the updated "Framework and Requirements" document did the right thing in only documenting the high level multicast requirements _for now_, because that is the level where there is agreement at this stage. But I don't agree that this is the end goal. In my opinion, we should aim at progressing towards agreement at the next level of details (ie key primitives + key parameters for the multicast use case + protocol requirements) and document those in the "Framework and Requirements" document. Protocol extensions can only be defined if the protocol requirements are described to that level first. To me this is a fundamental objective of the "Framework and Requirements" document. This is why it is indeed called "Framework and Requirements" and not just "Framework". This is exactly what has been done for all the other use cases. This is what should also be done for multicast. But why don't we ask for guidance from the WG chairs on this? (I'll do that right away in a separate message). Francois > > http://www3.ietf.org/proceedings/07mar/minutes/ancp.txt > > "1. Framework text to be added on two boxes (NAS and AN) connected > via ANCP that functionally look like one black box > 2. For multicast section framework text needs black box level > multicast use-cases that follow the principle of multicast > replication on the AN but no loss of functionality. CAC is part of > this, but addressing the full unicast+multicast CAC system solution > is not in scope of ANCP WG. The existence of the CAC use-case is to > be noted and ANCP mechanism designed to fit as best as possible. > 3. More detailed solution proposals to be brought in as part of the > ANCP protocol specification work." > > Regards, > Sven > > Thanks > > Francois > > --Apple-Mail-32-290130628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hello Sven,

On = 18 Jul 2007, at 11:27, OOGHE Sven wrote:

Hi = Francois,

From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] =
Sent: dinsdag 17 juli 2007 18:21
To: OOGHE = Sven
Cc: Francois Le Faucheur IMAP; ancp@ietf.org; roberta.maglione@telecom= italia.it; angelo.garofalo@telecomit= alia.it
Subject: Re: Comments on = draft-maglione-ancp-mcast-00.txt

Sven = and all,

=
Well, I think = there is agreement that the current Framework & Requirements I-D = does yet not fully cover the Multicast use cases. Right?=A0
=A0
We aimed to update the framework=A0to stay high level, yet = reflect the key requirements that the architecture needs to fulfill. I = agree that this leaves the details of the architecture, message flows = and protocol design open. These can be worked out while keeping the = framework document at the hig = level.

=
My assumption is that the "Framework and Requirements" document is = intended to define not just the ANCP high level requirements but also = the key message flows so that the protocol can be designed based on = this.
This is exactly what has been done for the use cases = currently covered (3.1, 3.2 and 3.3). For each of those, there is a = description of what sort of primitives (query/response) are needed = between AN and NAS and what are the key parameters for those.
Do we not agree that the = objective is exactly the same for the Multicast use case (ie identify = the message flow and key parameters)?
=A0
We need to work out the = details of multcast, that's for sure. The framework stays at a high = level, and the reason for doing that is that we tried to reflect the = concensus of the last IETF meeting, cf. minutes = below:

I agree that the updated = "Framework and Requirements" document did the right thing in only = documenting the high level multicast requirements _for now_, because = that is the level where there is agreement at this stage. But I don't = agree that this is the end goal.

In my opinion, we should = aim at progressing towards agreement at the next level of details (ie = key primitives + key parameters for the multicast use case + protocol = requirements) and document those in the=A0"Framework and Requirements"=A0 = document.=A0
Protocol extensions can only be defined if the = protocol requirements are described to that level first. To me this is a = fundamental objective of the=A0"Framework and Requirements"=A0document. = This is why it is indeed called=A0"Framework and Requirements"=A0 and = not just=A0"Framework". This is exactly what has been done for all the = other use cases. This is what should also be done for = multicast.

But = why don't we ask for guidance from the WG chairs on = this?=A0
(I'll do that right away in a separate = message).

Francois



=
=A0
=
=A0
"1. Framework text to be added on two boxes = (NAS and AN) connected via ANCP that functionally look like one black = box
2. For multicast section framework text needs black box level = multicast use-cases that follow the principle of multicast replication = on the AN but no loss of functionality. CAC is part of this, but = addressing the full unicast+multicast CAC system solution is not in = scope of ANCP WG. The existence of the CAC use-case is to be noted and = ANCP mechanism designed to fit as best as possible.
3. More detailed = solution proposals to be brought in as part of the ANCP protocol = specification work."
=A0
Regards,
Sven

=
Thanks

=
Francois

=


= --Apple-Mail-32-290130628-- --===============1082744164== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1082744164==-- From ancp-bounces@ietf.org Wed Jul 18 06:58:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB7EG-0008Cx-I3; Wed, 18 Jul 2007 06:58:00 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IB7EE-00087H-Jv for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 06:57:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB7EE-00085R-7v for ancp@ietf.org; Wed, 18 Jul 2007 06:57:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IB7ED-0004qV-6O for ancp@ietf.org; Wed, 18 Jul 2007 06:57:58 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 12:57:56 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAOOOnUaQ/uCLh2dsb2JhbACCLTWMYQEBCQon X-IronPort-AV: i="4.16,550,1175464800"; d="scan'208,217"; a="148354445:sNHT289346212" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6IAvu2f002448; Wed, 18 Jul 2007 12:57:56 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6IAvlkv010769; Wed, 18 Jul 2007 10:57:51 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:57:49 +0200 Received: from [10.0.0.15] ([10.61.65.174]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 12:57:48 +0200 Mime-Version: 1.0 (Apple Message framework v752.3) References: <729ECB4A-AE04-4160-B72D-5431A0BFBDD1@cisco.com> Message-Id: <98CB1888-2EC0-482D-828E-1B88283DC5B2@cisco.com> From: Francois Le Faucheur IMAP Date: Wed, 18 Jul 2007 12:54:51 +0200 To: "Wojciech Dec ((wdec))" , matthew.bocci@alcatel-lucent.co.uk X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jul 2007 10:57:48.0985 (UTC) FILETIME=[7AD3AA90:01C7C92A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7881; t=1184756276; x=1185620276; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20ANCP=20Chairs=20guidance=20sought |Sender:=20; bh=ysnKgzR9phwODU2Cy6k/98mA/s9Rd7gjFTyy5TCuMpk=; b=wmAU4yEZqlfieUqdseEyY0CbY8GoyX0GyT6x1q7oYtPyztB7toX4glqit8pe5d7htqzN6cTQ fbw5yHKr1WzdFs0smZDhDISty7PBn8irYu9M8aSkzulC3X2nagrKvOQ2; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: jari.arkko@piuha.net, ancp@ietf.org Subject: [ANCP] ANCP Chairs guidance sought X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0147355153==" Errors-To: ancp-bounces@ietf.org --===============0147355153== Content-Type: multipart/alternative; boundary=Apple-Mail-33-290461413 --Apple-Mail-33-290461413 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Woj, Matthew, Could you provide guidance on the topic below: should the "Framework & Requirements" document aim at describing ANCP protocol requirements for the multicast use case, to the same level as already done for the other use cases (e.g. discuss the key primitives, key parameters for these primitives)? Thanks Francois >> Sven and all, >> >> >>> Well, I think there is agreement that the current Framework & >>> Requirements I-D does yet not fully cover the Multicast use >>> cases. Right? >>> >>> We aimed to update the framework to stay high level, yet reflect >>> the key requirements that the architecture needs to fulfill. I >>> agree that this leaves the details of the architecture, message >>> flows and protocol design open. These can be worked out while >>> keeping the framework document at the hig level. >> >> My assumption is that the "Framework and Requirements" document is >> intended to define not just the ANCP high level requirements but >> also the key message flows so that the protocol can be designed >> based on this. >> This is exactly what has been done for the use cases currently >> covered (3.1, 3.2 and 3.3). For each of those, there is a >> description of what sort of primitives (query/response) are needed >> between AN and NAS and what are the key parameters for those. >> Do we not agree that the objective is exactly the same for the >> Multicast use case (ie identify the message flow and key parameters)? >> >> We need to work out the details of multcast, that's for sure. The >> framework stays at a high level, and the reason for doing that is >> that we tried to reflect the concensus of the last IETF meeting, >> cf. minutes below: > > I agree that the updated "Framework and Requirements" document did > the right thing in only documenting the high level multicast > requirements _for now_, because that is the level where there is > agreement at this stage. But I don't agree that this is the end goal. > > In my opinion, we should aim at progressing towards agreement at > the next level of details (ie key primitives + key parameters for > the multicast use case + protocol requirements) and document those > in the "Framework and Requirements" document. > Protocol extensions can only be defined if the protocol > requirements are described to that level first. To me this is a > fundamental objective of the "Framework and Requirements" document. > This is why it is indeed called "Framework and Requirements" and > not just "Framework". This is exactly what has been done for all > the other use cases. This is what should also be done for multicast. > > But why don't we ask for guidance from the WG chairs on this? > (I'll do that right away in a separate message). > > Francois > --Apple-Mail-33-290461413 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Woj, Matthew,

Could = you provide guidance on the topic below:
should the "Framework = & Requirements" document aim at describing ANCP protocol = requirements for the multicast use case, to the same level as already = done for the other use cases (e.g. discuss the key primitives, key = parameters for these primitives)?

Thanks

Francois


Sven and = all,


=
Well, I think = there is agreement that the current Framework & Requirements I-D = does yet not fully cover the Multicast use cases. Right?=A0
=A0
We aimed to update the framework=A0to stay high level, yet = reflect the key requirements that the architecture needs to fulfill. I = agree that this leaves the details of the architecture, message flows = and protocol design open. These can be worked out while keeping the = framework document at the hig = level.

=
My assumption is that the "Framework and Requirements" document is = intended to define not just the ANCP high level requirements but also = the key message flows so that the protocol can be designed based on = this.
This is exactly what has been done for the use cases = currently covered (3.1, 3.2 and 3.3). For each of those, there is a = description of what sort of primitives (query/response) are needed = between AN and NAS and what are the key parameters for those.
Do we not agree that the = objective is exactly the same for the Multicast use case (ie identify = the message flow and key parameters)?
=A0
We need to work out the = details of multcast, that's for sure. The framework stays at a high = level, and the reason for doing that is that we tried to reflect the = concensus of the last IETF meeting, cf. minutes = below:

I agree that the updated = "Framework and Requirements" document did the right thing in only = documenting the high level multicast requirements _for now_, because = that is the level where there is agreement at this stage. But I don't = agree that this is the end goal.

In my opinion, we should = aim at progressing towards agreement at the next level of details (ie = key primitives + key parameters for the multicast use case + protocol = requirements) and document those in the=A0"Framework and Requirements"=A0 = document.=A0
Protocol extensions can only be defined if the = protocol requirements are described to that level first. To me this is a = fundamental objective of the=A0"Framework and Requirements"=A0document. = This is why it is indeed called=A0"Framework and Requirements"=A0 and = not just=A0"Framework". This is exactly what has been done for all the = other use cases. This is what should also be done for = multicast.

But = why don't we ask for guidance from the WG chairs on = this?=A0
(I'll do that right away in a separate = message).

Francois

= --Apple-Mail-33-290461413-- --===============0147355153== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0147355153==-- From ancp-bounces@ietf.org Wed Jul 18 08:16:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB8SD-0006h5-2X; Wed, 18 Jul 2007 08:16:29 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IB8SB-0006gx-Ne for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 08:16:27 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IB8SB-0006go-83 for ancp@ietf.org; Wed, 18 Jul 2007 08:16:27 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IB8S9-0008AV-Vh for ancp@ietf.org; Wed, 18 Jul 2007 08:16:27 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 18 Jul 2007 14:16:16 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAF6hnUaQ/uCKh2dsb2JhbACCLTWMYQEBCQon X-IronPort-AV: i="4.16,550,1175464800"; d="scan'208,217"; a="148364496:sNHT3885900122" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6ICGFEN008207; Wed, 18 Jul 2007 14:16:15 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6ICGEkx014598; Wed, 18 Jul 2007 12:16:14 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:16:14 +0200 Received: from [10.0.0.15] ([10.61.65.174]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 14:16:13 +0200 In-Reply-To: <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Comments on draft-maglione Date: Wed, 18 Jul 2007 14:13:16 +0200 To: "OOGHE Sven" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Jul 2007 12:16:13.0853 (UTC) FILETIME=[6F258CD0:01C7C935] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=16530; t=1184760975; x=1185624975; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Comments=20on=20draft-maglione |Sender:=20; bh=JGkRRxm2B6E9k9L2TZpOu3XrBgbkwLdYU/YjcnZxPFs=; b=cDKna/Wi18lOIkrS7jRyvKsJTK8+Vi4XVMjc9ef8UzSBGwR/DCSEb0Rsh5u1h1TKByxX3a1L j1kKgiupTFHh01oC8gd4dKe9l8xZM6e2+SkU35OBl0wkM552Gn5Or6r3; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: ancp@ietf.org, angelo.garofalo@telecomitalia.it X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0064137709==" Errors-To: ancp-bounces@ietf.org --===============0064137709== Content-Type: multipart/alternative; boundary=Apple-Mail-34-295166219 --Apple-Mail-34-295166219 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed > >> 3) Future Over the Top Video Partnerships - Service providers may >> choose to partner with internet video providers to provide QoS and >> multicast capabilities through a partnership on a per event >> basis. Like the video conferencing scenario, this would be >> somewhat ad-hoc where the multicast group mappings may not be >> known in advance, or may be reused for different content in >> succession, requiring repeated policy refresh. Again, a >> centralized approach would appear to be more scalable for this model. >> >> I agree that these are channels which may not be known to the >> access provider in advance. There's however an easy way to solve >> this case: thanks to IGMPv3 SSM, it is possible to create two >> categories of channels: >> >> - those with a known IP source address: these would include e.g. >> the access/service provider's own IPTV offering >> >> - those with an unknown IP source address: these would include >> over the top video, or video conferencing >> >> The Access Node can use the IP source address to filter IGMPv3's >> in different replication contexts (e.g. IPTV, Internet TV). Within >> this context, it could then decide to offer the content with the >> required QoS, and decide whether or not to accept or reject the >> channel. > I don't quite see how that solves the core issues mentioned by Curtis: > What you describes allow to separate out the provider's channels > from everything else (the Internet OTT services, Video Conference). > But we still have to deal with the dynamic allocation/reallocation > of channels to the "Everything else" applications with possibly > large and fast changing membership. > > Correct, I should have made this more explicit in my previous > reply. When using IGMPv3 with SSM, the information to locally > decide whether or not to accept an IGMP report may or may not be > present in the replication context on the Access Node. > > For those, it seems more efficient to use a "more centralized" > repository than attempting to permanently update/re-update/re-re- > update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports. > Am I missing something? > > Well, perhaps we should do the math and count the amount of > messages... > > . In case of configuring the White-List/Black-List info, you'd > configure the info at subscription time or when the IP session > starts/ends. Typical example is the establishment of a PPP > connection or DHCP lease. At this point, the AAA system will be > contacted, which would be linked to the policy system containing > the user's multicast viewing rights. Those would then be sent to > the Access Node, and need to be released when the session ends. > There's indeed some updating and re-updating going on. But > typically, a session can last for one or several hours (or could > even be always-on), and the policy information may well be stable > for long periods of time within that session. > > . In case of contacting the central repository upon receiving an > IGMP, you would have such an exchange at every channel zap. Whithin > the session, it is likely that a subscriber will issue several IGMP > messages to zap through channels. The number of message exchanges > with the central respository will then be higher than in the first > case. > To reduce the message load, one could make use of some form of > channel grouping to send a bulk of policy information to the Access > Node (cf. what is mentioned in the draft), but in my view this > brings us very close to the first case again, and makes me wonder > if it would not be simpler to send all required channel information > to the Access Node at the start of the session. There may still be > a need to do some in-session policy configuration changes on the > Access Node, but even with this additional load, the resulting > message load will never be higher than in the case of checking with > the central policy server. Sven, Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). Perhaps, I should restate that the proposal is not about using Black- List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black- List/White-List for all channels/port except the channel(s) allocated to that particular application. Cheers Francois > > Regards, > Sven > Thanks > > Francois > --Apple-Mail-34-295166219 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

=

3) Future = Over the Top Video Partnerships - Service providers may choose to = partner with internet video providers to provide QoS and multicast = capabilities through a partnership on a per event basis.=A0 Like the = video conferencing scenario, this would be somewhat ad-hoc where the = multicast group mappings may not be known in advance, or may be reused = for different content in succession, requiring repeated policy = refresh.=A0 Again, a centralized approach would appear to be more = scalable for this model.

I = agree that these are channels which may not be known to the access = provider in advance. There's however an easy way to solve this case: = thanks to IGMPv3 SSM, it is possible to create two categories of = channels:

- those = with a known IP source address: these would include e.g. the = access/service provider's own IPTV = offering

- those = with an unknown IP source address: these would include over the top = video, or video conferencing

The Access Node can use the IP source = address to filter IGMPv3's in different replication contexts (e.g. = IPTV, Internet TV). Within this context, it could then decide to offer = the content with the required QoS, and decide whether or not to accept = or reject the channel.

I = don't quite see how that solves the core issues mentioned by = Curtis:
What you describes allow to separate out the = provider's channels from everything else (the Internet OTT services, = Video Conference). But we still have to deal with the dynamic = allocation/reallocation of channels to the "Everything else" = applications with possibly large and fast changing membership.=A0
=A0
Correct, I should have made this more explicit in my previous = reply.=A0When=A0using IGMPv3 with SSM, the information to locally decide = whether or not to accept an IGMP report may or may not be present in the = replication context on the Access Node.
=A0
=
=A0For those, it seems = more efficient to use a "more centralized" repository than attempting to = permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists = on all affected ANs/AN-ports.=A0
Am I missing = something?
=A0
Well, perhaps we should do = the math and count the amount of messages...
=
=A0
. In case of configuring the White-List/Black-List info, = you'd configure the info at subscription time or when the IP session = starts/ends. Typical example is the establishment of a PPP connection or = DHCP lease. At this point, the AAA system will be contacted, which would = be linked to the policy system containing the user's multicast viewing = rights. Those would then be sent to the Access Node, and need to be = released when the session ends. There's indeed some updating and = re-updating going on. But typically, a session can last for one or = several hours (or could even be always-on), and the policy information = may well be stable for long periods of time within that = session.
=A0
=
. In case of contacting the central = repository upon receiving an IGMP, you would have such an exchange at = every channel zap. Whithin the session, it is likely that a subscriber = will issue several IGMP messages to zap through channels. The number of = message exchanges with the central respository will then be higher than = in the first case.
To reduce the message load,=A0one could make use of some form = of channel grouping to send a bulk of policy information to the Access = Node (cf. what is mentioned in the draft), but in my view this brings us = very close to the first case again, and makes me wonder if it would not = be simpler to send all required channel information to the Access Node = at the start of the session.=A0There may still be a need to do some = in-session policy configuration changes on the Access Node, but even = with this additional load, the resulting message load will never be = higher than in the case of checking with the central policy = server.

Sven,

Your comparison above = assumes a "regular" scenario where the conditional access rules are = known ahead of time at session setup.
For such regular = scenarios, we agree that the Black-List/White-List mechanisms works = well. That is why those are defined in our proposal, and the expectation = is that they would be used for the regular scenarios.

But again, the interesting = question is for other scenarios, for example, as mentioned earlier, for = those involving large and fast changing membership. Just for argument = sake, let's imagine that an application is offering on-demand = multicast-based services (eg video conferencing, video-push) and want to = rely on multicast to do this and want to rely on the network to enforce = who is allowed to join which video conf. Then, it may be that there are = many "channels" created/terminated all the time, with new members coming = and going all the time. Some would allow multicast communications within = small groups (eg one for me to send my latest video to my parents and = uncle, one for you to send stuff to your brothers and sisters). Some = would allow multicast=A0communication=A0within very large groups (eg one = allowing all shareholders of company X to watch from home the company = results announcement live video). For _that_ application (and not for = each and every channel), just for that application, it appears more = efficient to allow the NAS to query a more central conditional access = repository than try to try update White-List/Black-List in every AN , = and for all affected AN-ports as their membership changes all the time. = In particular, for the groups authorizing communication within a very = large community (but perhaps where only a small number will actually = ever join).

Perhaps, I should restate = that the proposal is not about using Black-List/White-List for all = channels/port OR querying NAS for all channels/ports. The proposal is = about having the flexibility to use the most appropriate mechanism for = each channel/port. So, in case of the example on-demand application = discussed above, one may use Black-List/White-List for all channels/port = except the channel(s) allocated to that particular = application.

Cheers

Francois



=
=A0
=
Regards,
=
Sven=A0
Thanks

=
Francois


= --Apple-Mail-34-295166219-- --===============0064137709== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0064137709==-- From ancp-bounces@ietf.org Wed Jul 18 10:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAzc-0004AQ-Lo; Wed, 18 Jul 2007 10:59:08 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IBAza-00046o-Ln for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 10:59:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBAza-000459-8Q for ancp@ietf.org; Wed, 18 Jul 2007 10:59:06 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBAzV-0004VR-TG for ancp@ietf.org; Wed, 18 Jul 2007 10:59:06 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6IEv5A2001931; Wed, 18 Jul 2007 16:57:05 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Jul 2007 16:58:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Wed, 18 Jul 2007 16:58:56 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B16776@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfJNXgYhtdJfelORs+hnxmwf6lKBQAE3CCg References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 18 Jul 2007 14:58:58.0363 (UTC) FILETIME=[2B3F88B0:01C7C94C] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.1 (/) X-Scan-Signature: 90fbdaf3c139ce803b358d56775b59ed Cc: ancp@ietf.org, angelo.garofalo@telecomitalia.it X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2085830525==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2085830525== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C94C.2AC0E5A4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C94C.2AC0E5A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =09 =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. Sven, Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). =20 I think I understand your reasoning.You're saying that for things like video conferencing, over the top video or video push features you would contact the central policy system because the access node doesn't have the information to decide locally. For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access Node. =20 In this case, I would think that the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address (for IPTV) or unknown IP source address (the "Everything else" mentioned by Curtis). That would imply to me that for everything which is IPTV, you could handle things locally, and for "Everything else", you would have to query the central policy server. This is because the Access Node doesn't know whether this user is allowed to watch e.g. the company's results broadcast vs any other Internet TV stream. So each time I would try to join a non-IPTV stream, the central policy server needs to check if the stream is a known one which is authorized, or some other Internet stream. Wouldn't this lead to scaling issues? Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular application. Cheers Francois=20 =20 Regards, Sven ------_=_NextPart_001_01C7C94C.2AC0E5A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,

3) Future Over the Top Video Partnerships - Service providers = may choose=20 to partner with internet video providers to provide QoS and multicast=20 capabilities through a partnership on a per event basis.  Like the = video=20 conferencing scenario, this would be somewhat ad-hoc where the multicast = group=20 mappings may not be known in advance, or may be reused for different = content in=20 succession, requiring repeated policy refresh.  Again, a = centralized=20 approach would appear to be more scalable for this model.

I agree that these are channels which may not be = known to the=20 access provider in advance. There's however an easy way to solve = this case:=20 thanks to IGMPv3 SSM, it is possible to create two categories of=20 channels:

- those with a known IP source address: = these would=20 include e.g. the access/service provider's own IPTV=20 offering

- those with an unknown IP source = address: these=20 would include over the top video, or video=20 conferencing

The Access Node can use the IP source = address to=20 filter IGMPv3's in different replication contexts (e.g. IPTV, = Internet TV).=20 Within this context, it could then decide to offer the content with = the=20 required QoS, and decide whether or not to accept or reject the=20 channel.

I don't quite see how that solves the core issues mentioned by=20 Curtis:
What you describes allow to separate out the provider's channels = from=20 everything else (the Internet OTT services, Video Conference). But we = still=20 have to deal with the dynamic allocation/reallocation of channels to = the=20 "Everything else" applications with possibly large and fast changing=20 membership. 
 
Correct, I should have made this more explicit in my previous = reply. When using IGMPv3 with SSM, the information to = locally decide=20 whether or not to accept an IGMP report may or may not be present in = the=20 replication context on the Access Node.
 
 For those, it seems = more=20 efficient to use a "more centralized" repository than attempting to=20 permanently update/re-update/re-re-update/etc.. = White-Lists/Black-Lists on all=20 affected ANs/AN-ports. 
Am I missing something?
 
Well, perhaps we should do the math and count the amount of=20 messages...
 
. In=20 case of configuring the White-List/Black-List info, you'd configure = the info=20 at subscription time or when the IP session starts/ends. Typical = example is=20 the establishment of a PPP connection or DHCP lease. At this point, = the AAA=20 system will be contacted, which would be linked to the policy system=20 containing the user's multicast viewing rights. Those would then be = sent to=20 the Access Node, and need to be released when the session ends. = There's indeed=20 some updating and re-updating going on. But typically, a session can = last for=20 one or several hours (or could even be always-on), and the policy = information=20 may well be stable for long periods of time within that=20 session.
 
. In=20 case of contacting the central repository upon receiving an IGMP, you = would=20 have such an exchange at every channel zap. Whithin the session, it is = likely=20 that a subscriber will issue several IGMP messages to zap through = channels.=20 The number of message exchanges with the central respository will then = be=20 higher than in the first case.
To=20 reduce the message load, one could make use of some form of = channel=20 grouping to send a bulk of policy information to the Access Node (cf. = what is=20 mentioned in the draft), but in my view this brings us very close to = the first=20 case again, and makes me wonder if it would not be simpler to send all = required channel information to the Access Node at the start of the=20 session. There may still be a need to do some in-session policy=20 configuration changes on the Access Node, but even with this = additional load,=20 the resulting message load will never be higher than in the case of = checking=20 with the central policy server.
Sven,
Your comparison above assumes a "regular" scenario where the = conditional=20 access rules are known ahead of time at session setup.
For such regular scenarios, we agree that the Black-List/White-List = mechanisms works well. That is why those are defined in our proposal, = and the=20 expectation is that they would be used for the regular scenarios.

But again, the interesting question is for other scenarios, for = example, as=20 mentioned earlier, for those involving large and fast changing = membership. Just=20 for argument sake, let's imagine that an application is offering = on-demand=20 multicast-based services (eg video conferencing, video-push) and want to = rely on=20 multicast to do this and want to rely on the network to enforce who is = allowed=20 to join which video conf. Then, it may be that there are many "channels" = created/terminated all the time, with new members coming and going all = the time.=20 Some would allow multicast communications within small groups (eg one = for me to=20 send my latest video to my parents and uncle, one for you to send stuff = to your=20 brothers and sisters). Some would allow = multicast communication within=20 very large groups (eg one allowing all shareholders of company X to = watch from=20 home the company results announcement live video). For _that_ = application (and=20 not for each and every channel), just for that application, it appears = more=20 efficient to allow the NAS to query a more central conditional access = repository=20 than try to try update White-List/Black-List in every AN , and for all = affected=20 AN-ports as their membership changes all the time. In particular, for = the groups=20 authorizing communication within a very large community (but perhaps = where only=20 a small number will actually ever join).
 
I think I understand your = reasoning.You're saying that for things = like video=20 conferencing, over the top video or video push features you would = contact=20 the central policy system because the access node doesn't have the = information=20 to decide locally. For IPTV services offered by the access/service=20 provider, some Black-List/White-List info is pushed to the Access=20 Node.
 
In this case, I would think that the Access = Node could=20 e.g. use IGMPv3 SSM to distinguish between these two categories of = services,=20 based on a (or a few) known IP source address (for IPTV) or unknown IP = source=20 address (the "Everything else" mentioned by Curtis). That would imply to = me that=20 for everything which is IPTV, you could handle things locally, and for=20 "Everything else", you would have to query the central policy server. = This is=20 because the Access Node doesn't know whether this user is allowed to = watch e.g.=20 the company's results broadcast vs any other Internet TV=20 stream. So each time I would try = to join a=20 non-IPTV stream, the central policy server needs to check if the stream = is a=20 known one which is authorized, or some other Internet stream. Wouldn't = this lead=20 to scaling issues?
Perhaps, I should restate that the proposal is not about using=20 Black-List/White-List for all channels/port OR querying NAS for all=20 channels/ports. The proposal is about having the flexibility to use the = most=20 appropriate mechanism for each channel/port. So, in case of the example=20 on-demand application discussed above, one may use Black-List/White-List = for all=20 channels/port except the channel(s) allocated to that particular=20 application.

Cheers

Francois 
   
Regards,
Sven
------_=_NextPart_001_01C7C94C.2AC0E5A4-- --===============2085830525== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============2085830525==-- From ancp-bounces@ietf.org Wed Jul 18 11:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBmg-0003So-NA; Wed, 18 Jul 2007 11:49:50 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IBBmf-0003Sb-Rm for ancp-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 11:49:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBBmf-0003SP-Gz for ancp@ietf.org; Wed, 18 Jul 2007 11:49:49 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBBmd-00063X-HN for ancp@ietf.org; Wed, 18 Jul 2007 11:49:49 -0400 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6IFnQNR000640; Wed, 18 Jul 2007 17:49:26 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 18 Jul 2007 17:49:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Jul 2007 17:49:44 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B167C8@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ancp-protocol-01 Thread-Index: AcfJU0MVpf6Xh8dzROO8wqtWZWz3rg== From: "OOGHE Sven" To: , X-OriginalArrivalTime: 18 Jul 2007 15:49:46.0441 (UTC) FILETIME=[440B5390:01C7C953] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: Subject: [ANCP] Comments on draft-ietf-ancp-protocol-01 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2060389975==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2060389975== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7C953.439CCE29" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7C953.439CCE29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Upon reading the ANCP protocol draft, I noticed that section 4 contains some sections which overlap with the ANCP Framework and Requirements document. In order to avoid this overlap, and also to increase the alignment between both documents, I suggest to make the following changes: section 4: rename title to "ANCP message flows" section 4.1 should clarify that following subsections describe the message flows for the different use cases identified in the ANCP Framework & Requirements document. It should also reference this document, indicating it contains the background information on the ANCP message flows. section 4.2: rename title to "Access Topology Discovery" to be consistent with the naming in the framework section 4.2.1 is coverd by section 3.1 in the framework =3D> it should = be removed section 4.3: rename title to "Access Loop Configuration" to be consistent with the naming in the framework section 4.3.1 is coverd by section 3.2 in the framework =3D> it should = be removed I suggest to switch sections 4.4. and 4.5, to have the same sequence as in the framework document. Then we get: section 4.4 "Remote Connectivity Test" (title changed to make it consistent with the framework) The first two paragraphs before the message flows are also captured in section 3.3 in the framework =3D> they can be removed. section 4.5 "Multicast" (title changed to make it consistent with the framework) The current text is also captured in section 3.4 of the framework, so I think it should be removed. Also I believe the following sentence is losing relevance: "In ATM access networks, ANCP can be used by the NAS to setup P2MP cross-connects in the DSLAMs." As far as I know, most (if not all) of current multicast deployment scenarios in access are based on Ethernet/IP packet replication, not on ATM cell replication. Furthermore, networks are rapidly migrating for ATM to Ethernet. For these reasons I suggest removing this sentence. Regards, Sven --- Sven Ooghe Access Division, CTO Office Alcatel-Lucent Bell NV Copernicuslaan 50, 2018 Antwerp, Belgium tel.: +32 3 240 42 26 fax: +32 3 240 40 73 This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. ------_=_NextPart_001_01C7C953.439CCE29 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ancp-protocol-01

Hi,

Upon reading the ANCP protocol draft, I = noticed that section 4 contains some sections which overlap with the = ANCP Framework and Requirements document. In order to avoid this = overlap, and also to increase the alignment between both documents, I = suggest to make the following changes:

section 4: rename title to "ANCP = message flows"

section 4.1 should clarify that = following subsections describe the message flows for the different use = cases identified in the ANCP Framework & Requirements document. It = should also reference this document, indicating it contains the = background information on the ANCP message flows.

section 4.2: rename title to = "Access Topology Discovery" to be consistent with the naming = in the framework
section 4.2.1 is coverd by section 3.1 = in the framework =3D> it should be removed

section 4.3: rename title to = "Access Loop Configuration" to be consistent with the naming = in the framework
section 4.3.1 is coverd by section 3.2 = in the framework =3D> it should be removed

I suggest to switch sections 4.4. and = 4.5, to have the same sequence as in the framework document. Then we = get:

section 4.4 "Remote Connectivity = Test" (title changed to make it consistent with the = framework)
The first two paragraphs before the = message flows are also captured in section 3.3 in the framework =3D> = they can be removed.

section 4.5 "Multicast" = (title changed to make it consistent with the framework)
The current text is also captured in = section 3.4 of the framework, so I think it should be removed. Also I = believe the following sentence is losing relevance: "In ATM access = networks, ANCP can be used by the NAS to setup P2MP cross-connects in = the DSLAMs." As far as I know, most (if not all) of current = multicast deployment scenarios in access are based on Ethernet/IP packet = replication, not on ATM cell replication. Furthermore, networks are = rapidly migrating for ATM to Ethernet. For these reasons I suggest = removing this sentence.

Regards,
Sven

---

Sven Ooghe
Access Division, CTO Office
Alcatel-Lucent Bell NV
Copernicuslaan 50, 2018 Antwerp, = Belgium
tel.: +32 3 240 42 26
fax: +32 3 240 40 73

This message (including any = attachments) contains confidential information intended for a specific = individual and purpose, and is protected by law.  If you are not = the intended recipient, you should delete this message.  Any = disclosure, copying, or distribution of this message, or the taking of = any action based on it, is strictly prohibited without the prior consent = of its author.

------_=_NextPart_001_01C7C953.439CCE29-- --===============2060389975== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============2060389975==-- From ancp-bounces@ietf.org Thu Jul 19 02:59:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPzQ-0006ax-Gd; Thu, 19 Jul 2007 02:59:56 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IBPzP-0006ar-E6 for ancp-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 02:59:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBPzL-0006ac-I1 for ancp@ietf.org; Thu, 19 Jul 2007 02:59:51 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBPzJ-0004WO-Va for ancp@ietf.org; Thu, 19 Jul 2007 02:59:51 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Thu, 19 Jul 2007 08:59:46 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Jul 2007 08:59:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt Date: Thu, 19 Jul 2007 08:59:39 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED20281AE5A@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <20070716095153.R11793@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt Thread-Index: AcfHyizE1/cQvv9XRFaKAV+If7vlIACBKdRA References: <20070716095153.R11793@cisco.com> From: "Haag, T" To: X-OriginalArrivalTime: 19 Jul 2007 06:59:45.0309 (UTC) FILETIME=[63816CD0:01C7C9D2] X-Spam-Score: -1.0 (-) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Toerless, Thanks for your reply. Please see my answers inline: Regards Thomas =20 -----Urspr=FCngliche Nachricht----- Von: Toerless Eckert [mailto:eckert@cisco.com]=20 Gesendet: Montag, 16. Juli 2007 18:52 An: Haag, Thomas Cc: angelo.garofalo@telecomitalia.it; ancp@ietf.org Betreff: Re: [ANCP] Comments on draft-maglione-ancp-mcast-00.txt Thomas, What you are asking for should already covered by what the draft intends to introduce into the ANCP spec/requirements documents. It is perfectly valid to only use in an ANCP deployment the profile you are implying: Provisioning on a per-subscriber basis a whitelist (permitted channels) and blacklist (denied channels). >>TH:=20 I hoped it would cover but I think at the moment that is not the case.=20 Considering 4.1 Conditional access with local access node decision:=20 The listed requirements base on the assumption that the customer has = to be authenticated somehow and to be known by the network. There has = to be done a correlation between user credentials and DSL Port ID and = Profile ID. The message flow in section 5.1.1 shows that the push = profile command comes before DSL is in sync. So the customer cannot be = authenticated before and send a RADIUS request. In other words I cannot = push a profile to a port which the NAS does not know by a port up = message except the case that NAS does local administration and = configuration tasks for the AN. The draft just also includes requirements and functionality that goes beyond what you are asking for, because not every deployment may be able to statically split up the bandwidth to the home devices with individual static bandwidth tools. In fact, the draft tries to exactly provide the most simple signaling for each of the varying deployment models we have come to see being required. >>TH:=20 Regarding my concerns of IGMP triggered request from AN to NAS I = cannot share your view in having a simple signalling. This may be the = case considering the message itself but not in operating large scale = networks having thousands of AN per NAS having flows on a per IGMP = request base. Also for fault location I don't see features to handle = localize malfunction in that process because two network elements are = involved which are not necessarily in the same operational domain.=20 Not quite sure on the authentication piece... >>TH:=20 The draft assumes basic authentication requirements which can be read = between the lines but not mentioned explicitly... =20 Cheers Toerless On Mon, Jul 16, 2007 at 04:33:08PM +0200, Haag, T wrote: > All, >=20 > =20 >=20 > Operating Multicast in conjunction with conditional access is very > useful. But it is important to design such scenario in a less complex > way. >=20 > I think simplifying the message flow by adding local decision control = in > the access node triggered by user authentication result archived by > NAS/RADIUS decision when starting a session can be a way out to solve > the estimated zapping performance issue, the complex maintenance issue > and decouples user session from DSL Port authentication. =20 >=20 > =20 >=20 > Operation/Performance: >=20 > >From an operational standpoint these features/message flows must be > simple and less complex in operation respectively maintenance and = fault > location. Sending each event by joining a group an ANCP message from = the > AN towards the NAS and receiving the policy decision implies to me a > very busy zapping scenario (section 5.2.) >=20 > =20 >=20 > Also with respect to operational complexity I have some concerns > regarding performance and maintenance. The main concern is regarding > three elements (RADIUS, NAS, AN) participating in the dynamic IGMP > triggered policy decision process.=20 >=20 > =20 >=20 > Authentication: >=20 > Running Start Accounting/ Stop Accounting can be done Port_ID related = or > user related (see fig.4, fig.5). Both methods require different = features > with respect to CPE/DSL/AN. Considering figure 6 implies to me that = port > based authentication is required for running multicast. If not RADIUS > has to correlate between user ID and DSL Port ID. >=20 > In the document the reference is missing which authentication method = the > use cases require. Is it user/session based or is it port based? >=20 > =20 >=20 > I think the draft can be reworked according the comments still meeting > basics of ANCP framework. >=20 > =20 >=20 > Regards, >=20 > Thomas _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jul 19 12:10:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYaD-0004ZX-S6; Thu, 19 Jul 2007 12:10:29 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IBYaC-0004Y5-BV for ancp-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 12:10:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBYaB-0004Xh-Ts for ancp@ietf.org; Thu, 19 Jul 2007 12:10:27 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBYaB-0004vG-F0 for ancp@ietf.org; Thu, 19 Jul 2007 12:10:27 -0400 Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6JGARqb031790; Thu, 19 Jul 2007 18:10:27 +0200 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel-lucent.co.uk Date: Thu, 19 Jul 2007 17:10:12 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 07/19/2007 17:10:23 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [ANCP] Chicago slides X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org If you have a slot to present at the ANCP meeting at the Chicago IETF, please can you send me you slides to myself and Woj before the end of Sunday 22nd July. Regards, Matthew ----------------------------------------- Matthew Bocci IP Division, Alcatel-Lucent Telecom Limited, Registered Office: Christchurch Way, Greenwich, London SE10 0AG. Registered in England & Wales number 02650571 ----------------------------------------- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Thu Jul 19 14:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaTc-0000ph-2m; Thu, 19 Jul 2007 14:11:48 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IBaTZ-0000pU-W8 for ancp-confirm+ok@megatron.ietf.org; Thu, 19 Jul 2007 14:11:45 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBaTZ-0000pM-JM for ancp@ietf.org; Thu, 19 Jul 2007 14:11:45 -0400 Received: from prattle.redback.com ([155.53.12.9]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBaTX-0000E6-Ug for ancp@ietf.org; Thu, 19 Jul 2007 14:11:45 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id 199EEC2AE08; Thu, 19 Jul 2007 11:11:43 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24333-02; Thu, 19 Jul 2007 11:11:42 -0700 (PDT) Received: from CSHERBOTM5XP (dhcp-36-36.van.redback.com [172.19.36.36]) by prattle.redback.com (Postfix) with ESMTP id D93CAC2AE02; Thu, 19 Jul 2007 11:11:41 -0700 (PDT) From: "Curtis Sherbo" To: "'OOGHE Sven'" , , , , Subject: RE: [ANCP] Comments on draft-maglione Date: Thu, 19 Jul 2007 11:11:41 -0700 Message-ID: <002b01c7ca30$423d8f00$242413ac@ad.redback.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfH9bphkunYlpj7QZWeNixZLlrk0QAeX5WgAG6+xbA= In-Reply-To: <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 958aa603499a3de6b2b87d68741ed60e Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1835236745==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1835236745== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01C7C9F5.95DEB700" This is a multi-part message in MIME format. ------=_NextPart_000_002C_01C7C9F5.95DEB700 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Sven, comments inline. Cheers, Curtis _____ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be] Sent: Tuesday, July 17, 2007 7:12 AM To: Curtis Sherbo; ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it; flefauch@cisco.com Subject: RE: [ANCP] Comments on draft-maglione Hi, Please find my comments inline. Regards, Sven _____ From: Curtis Sherbo [mailto:csherbo@redback.com] Sent: dinsdag 17 juli 2007 0:08 To: ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it; flefauch@cisco.com Subject: [ANCP] Comments on draft-maglione Greetings, I think the flexibility of the solution proposed in draft-maglione-ancp-mcast-00.txt is necessary when you consider applications beyond simple broadcast IPTV. I think it is useful in certain scenarios in IPTV, but I also think it is useful in a few other applications as listed below: 1) Nomadicity/Roaming - whether wired or wireless it would be more effective to have a centralized policy decision as opposed to a distributed one. This is especially true in a wireless instance where a client may be moving from one access point to another, the session would need to be handed off, would you want to see a full authentication step each hop so that you can refresh policies on the access point? I agree that there will be some central system that holds the subscriber policy information. In the case of nomadicity, this system will be in the "home network" (I don't mean customer premises network) and will need to be contacted by the "visiting network". This could be done in a push mode - bringing the relevant policy information to the network elements in the visiting network - or in a pull mode - outsourcing the decision to the home network. In my view, in the case of multicast, the push model leads to less signaling than the pull model (unless some special tricks based on session grouping with timeouts are introduced in access platforms - but these have their own issues as I highlighted in my previous email). Hence I'm more in favor of using the push model even in nomadic/roaming cases. I think I can agree somewhat on the nomadic case. But I still think in the roaming case, where you have an active session that is handed off from one Access Point to another, that it isn't scalable or seamless to push a full policy down to the Access Point. 2) Video Conferencing - As conferences would likely be ad-hoc, where the multicast groups may not be known in advance, it would likely be more efficient to update data centrally and query it as a participants join conferences. See next point. 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't know if I follow you here. I think you are saying for the OTT Video, the receiver would send a Join for a group with an empty source list. I fail to see how the AN can make an appropriate policy decision with only this information. My train of thought on this was that the application would know the MC Group for the event and send the join with the Group and the Source, or even the just the group, and the AN via ANCP via the NAS would query a AAA database to see that the customer either just purchased the event or if there is open access to the group. I'm thinking a service provider may reuse a MC Group with differing sources as you mention above, and the QoS aspect could hold true as you say, but the event based authorization I believe is best handled with the centralized approach. I also believe this application requires the Termination function proposed in the draft. To be noted, zap time is less of an issue with these three applications, as there is typically an accepted processing time. Can you clarify what you mean with this? In one of the earlier arguments, I believe put forward by Thomas, he mentioned that Zap time would be lengthened with this extra authorization step. I agree that this is the case, but my point is that these applications don't have a expected rapid response time such is the case with IPTV channel change. I believe these applications will have a different application interface with an experience similar to clicking on a web link, where a user is accustomed to waiting for a page to load, they will not be surprised by the extra processing time of the authorization check. Obviously it is not the job of the IETF to define these services or business models, but I thought it might be helpful for us to consider services beyond the starting point of IPTV. As suggested by others on this list, the existing framework may be able to fulfill some of the requirements put forward by this draft, but I argue that there is validity in the flexibility that the draft brings for IPTV as well as support for the applications I have discussed here. I welcome your comments. Cheers, Curtis Curtis Sherbo, P.Eng Product Line Manager Redback Networks Canada Inc. Phone: (604)629-7357 Mobile: (604)250-0672 ------=_NextPart_000_002C_01C7C9F5.95DEB700 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-maglione
Hi Sven, comments inline.
 
Cheers,
Curtis

From: OOGHE Sven=20 [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Tuesday, July 17, = 2007=20 7:12 AM
To: Curtis Sherbo; ancp@ietf.org;=20 roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it;=20 flefauch@cisco.com
Subject: RE: [ANCP] Comments on=20 draft-maglione

Hi,
 
Please find my comments = inline.
 
Regards,
Sven

From: Curtis Sherbo = [mailto:csherbo@redback.com]=20
Sent: dinsdag 17 juli 2007 0:08
To: ancp@ietf.org;=20 roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it;=20 flefauch@cisco.com
Subject: [ANCP] Comments on=20 draft-maglione

Greetings,

I think the flexibility of the solution = proposed in=20 draft-maglione-ancp-mcast-00.txt is necessary when you consider = applications=20 beyond simple broadcast IPTV.

I think it is useful in certain scenarios = in IPTV,=20 but I also think it is useful in a few other applications as listed=20 below:

1) Nomadicity/Roaming - whether = wired or=20 wireless it would be more effective to have a centralized policy = decision as=20 opposed to a distributed one.  This is especially true in a = wireless=20 instance where a client may be moving from one access point to another, = the=20 session would need to be handed off, would you want to see a full = authentication=20 step each hop so that you can refresh policies on the access point? 

I agree that there will be some central system that holds the = subscriber=20 policy information. In the case of nomadicity, this system will be in = the "home=20 network" (I don't mean customer premises network) and will need to = be=20 contacted by the "visiting network". This could be done in a push mode - = bringing the relevant policy information to the network elements in the = visiting=20 network - or in a pull mode - outsourcing the decision to the home = network. In=20 my view, in the case of multicast, the push model leads to less = signaling than=20 the pull model (unless some special tricks based on session grouping = with=20 timeouts are introduced in access platforms - but these have their own = issues as=20 I highlighted in my previous email). Hence I'm more in favor of using = the push=20 model even in nomadic/roaming cases. 

<CS> I think I can agree = somewhat on=20 the nomadic case.  But I still think in the roaming case, where you = have an=20 active session that is handed off from one Access Point to another, that = it=20 isn't scalable or seamless to push a full policy down to the Access=20 Point.

2) Video Conferencing - As = conferences would=20 likely be ad-hoc, where the multicast groups may not be known in = advance, it=20 would likely be more efficient to update data centrally and query it as = a=20 participants join conferences. 

See next point.

3) Future Over the Top Video Partnerships = - Service=20 providers may choose to partner with internet video providers to provide = QoS and=20 multicast capabilities through a partnership on a per event basis.  = Like=20 the video conferencing scenario, this would be somewhat ad-hoc where the = multicast group mappings may not be known in advance, or may be reused = for=20 different content in succession, requiring repeated policy = refresh.  Again,=20 a centralized approach would appear to be more scalable for this=20 model.

I agree that these are channels which may not be known = to the=20 access provider in advance. There's however an easy way to solve this = case:=20 thanks to IGMPv3 SSM, it is possible to create two categories of=20 channels:

-=20 those with a known IP source address: these would include e.g. the=20 access/service provider's own IPTV offering

-=20 those with an unknown IP source address: these would include over the = top video,=20 or video conferencing

The Access Node can use the IP source address to filter = IGMPv3's in=20 different replication contexts (e.g. IPTV, Internet TV). Within this = context, it=20 could then decide to offer the content with the required QoS, and decide = whether=20 or not to accept or reject the channel. 

<CS> I don't know if I = follow you=20 here.  I think you are saying for the OTT Video, the receiver would = send a=20 Join for a group with an empty source list.  I fail to see how the = AN can=20 make an appropriate policy decision with only this information.  My = train=20 of thought on this was that the application would know the MC Group for = the=20 event and send the join with the Group and the Source, or even the just = the=20 group, and the AN via ANCP via the NAS would query a AAA database to see = that=20 the customer either just purchased the event or if there is open access = to the=20 group.  I'm thinking a service provider may reuse a MC Group with = differing=20 sources as you mention above, and the QoS aspect could hold true as you = say, but=20 the event based authorization I believe is best handled with the = centralized=20 approach. I also believe = this=20 application requires the Termination function proposed in the=20 draft.

To be noted, zap time is less of an = issue with=20 these three applications, as there is typically an accepted processing=20 time. 

Can you clarify what you mean with = this?  

<CS>In one of the = earlier arguments,=20 I believe put forward by Thomas, he mentioned that Zap time would be = lengthened=20 with this extra authorization step.  I agree that this is the case, = but my=20 point is that these applications don't have a expected rapid response = time such=20 is the case with IPTV channel change.  I believe these applications = will=20 have a different application interface with an experience similar to = clicking on=20 a web link, where a user is accustomed to waiting for a page to load, = they will=20 not be surprised by the extra processing time of the authorization=20 check.

Obviously it is not the job of the IETF = to define=20 these services or business models, but I thought it might be helpful for = us to=20 consider services beyond the starting point of IPTV. 

As suggested by others on this list, the = existing=20 framework may be able to fulfill some of the requirements put forward by = this=20 draft, but I argue that there is validity in the flexibility that the = draft=20 brings for IPTV as well as support for the applications I have discussed = here.

I welcome your comments.

Cheers,
Curtis

Curtis Sherbo, P.Eng
Product Line Manager
Redback Networks=20 Canada Inc.
Phone: = (604)629-7357=20
Mobile: (604)250-0672 =

------=_NextPart_000_002C_01C7C9F5.95DEB700-- --===============1835236745== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1835236745==-- From ancp-bounces@ietf.org Fri Jul 20 07:49:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqzE-0007v6-F0; Fri, 20 Jul 2007 07:49:32 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IBqzC-0007v0-Qy for ancp-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 07:49:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBqz8-0007uq-UQ for ancp@ietf.org; Fri, 20 Jul 2007 07:49:26 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBqz6-00053M-Vu for ancp@ietf.org; Fri, 20 Jul 2007 07:49:26 -0400 Received: from FRVELSBHS07.ad2.ad.alcatel.com (frvelsbhs07.ad2.ad.alcatel.com [155.132.6.79]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6KBnL2J019159; Fri, 20 Jul 2007 13:49:21 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS07.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 20 Jul 2007 13:49:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Fri, 20 Jul 2007 13:49:20 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380B8755D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <002b01c7ca30$423d8f00$242413ac@ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfH9bphkunYlpj7QZWeNixZLlrk0QAeX5WgAG6+xbAAJZn1cA== References: <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <002b01c7ca30$423d8f00$242413ac@ad.redback.com> From: "OOGHE Sven" To: "Curtis Sherbo" , , , , X-OriginalArrivalTime: 20 Jul 2007 11:49:21.0561 (UTC) FILETIME=[02F8D090:01C7CAC4] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3d1fcc6feccbcc611b6c309986f05f7 Cc: X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0908893940==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0908893940== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CAC4.02A34FC1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CAC4.02A34FC1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Curtis, =20 feedback inline. =20 Regards, Sven ________________________________ From: Curtis Sherbo [mailto:csherbo@redback.com]=20 Sent: donderdag 19 juli 2007 20:12 To: OOGHE Sven; ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it; flefauch@cisco.com Subject: RE: [ANCP] Comments on draft-maglione Hi Sven, comments inline. =20 Cheers, Curtis ________________________________ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Tuesday, July 17, 2007 7:12 AM To: Curtis Sherbo; ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it; flefauch@cisco.com Subject: RE: [ANCP] Comments on draft-maglione Hi, =20 Please find my comments inline. =20 Regards, Sven ________________________________ From: Curtis Sherbo [mailto:csherbo@redback.com]=20 Sent: dinsdag 17 juli 2007 0:08 To: ancp@ietf.org; roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it; flefauch@cisco.com Subject: [ANCP] Comments on draft-maglione Greetings,=20 I think the flexibility of the solution proposed in draft-maglione-ancp-mcast-00.txt is necessary when you consider applications beyond simple broadcast IPTV. I think it is useful in certain scenarios in IPTV, but I also think it is useful in a few other applications as listed below: 1) Nomadicity/Roaming - whether wired or wireless it would be more effective to have a centralized policy decision as opposed to a distributed one. This is especially true in a wireless instance where a client may be moving from one access point to another, the session would need to be handed off, would you want to see a full authentication step each hop so that you can refresh policies on the access point?=20 I agree that there will be some central system that holds the subscriber policy information. In the case of nomadicity, this system will be in the "home network" (I don't mean customer premises network) and will need to be contacted by the "visiting network". This could be done in a push mode - bringing the relevant policy information to the network elements in the visiting network - or in a pull mode - outsourcing the decision to the home network. In my view, in the case of multicast, the push model leads to less signaling than the pull model (unless some special tricks based on session grouping with timeouts are introduced in access platforms - but these have their own issues as I highlighted in my previous email). Hence I'm more in favor of using the push model even in nomadic/roaming cases.=20 I think I can agree somewhat on the nomadic case. But I still think in the roaming case, where you have an active session that is handed off from one Access Point to another, that it isn't scalable or seamless to push a full policy down to the Access Point.=20 The mobility/roaming case is one I handnt't thought of before. The amount of signaling for push mode are greater than in the nomadic case, that's clear. I think that the use of multicast applications in a wireless network (e.g. 802.11 or 802.16) is something where the folks from Mobile IP as well as from CAPWAP need to be involved. For L3 mobility (i.e. moving from one subnet to another), Mobile IP defines a number of techniques to tunnel traffic from the Foreign Agent to the Home Agent; perhaps extensions are needed for allowing pull and/or push models. Similarly, I've seen that CAPWAP defines techniques to configure MAC ACLs on wireless access points. Maybe CAPWAP would need to be extended to include pull and/or push models for mobility of multicast applications. 2) Video Conferencing - As conferences would likely be ad-hoc, where the multicast groups may not be known in advance, it would likely be more efficient to update data centrally and query it as a participants join conferences.=20 See next point. 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel.=20 I don't know if I follow you here. I think you are saying for the OTT Video, the receiver would send a Join for a group with an empty source list. I fail to see how the AN can make an appropriate policy decision with only this information. My train of thought on this was that the application would know the MC Group for the event and send the join with the Group and the Source, or even the just the group, and the AN via ANCP via the NAS would query a AAA database to see that the customer either just purchased the event or if there is open access to the group. I'm thinking a service provider may reuse a MC Group with differing sources as you mention above, and the QoS aspect could hold true as you say, but the event based authorization I believe is best handled with the centralized approach. I also believe this application requires the Termination function proposed in the draft. =20 The idea I had in mind was that the access node could hold White-List/Black-List policies for the well-known senders (e.g. the IPTV content servers, or some server in the Internet for which the service provider has some contract with the access provider). Upon receiving an IGMP join, the Access Node could first check if the source IP address was a known one (using IGMPv3 SSM). If so, then it would look at the White-List/Black-List information and decide locally. If on the other hand the source IP address would not be not known, it could be basically anything (over the top video, video conferencing, some Internet TV channel in Japan,...). In this case the Access Node could do two things - simply accept, and handle access control at some other layer (e.g. using encryption) - outsource to let a central system decide I think that there may be scaling issues with outsourcing everyting else. Instead, I think it's better to rely on SSM as a first filtering technique. Black/White lists could be used for further filtering of the known sources. To be noted, zap time is less of an issue with these three applications, as there is typically an accepted processing time.=20 Can you clarify what you mean with this? =20 In one of the earlier arguments, I believe put forward by Thomas, he mentioned that Zap time would be lengthened with this extra authorization step. I agree that this is the case, but my point is that these applications don't have a expected rapid response time such is the case with IPTV channel change. I believe these applications will have a different application interface with an experience similar to clicking on a web link, where a user is accustomed to waiting for a page to load, they will not be surprised by the extra processing time of the authorization check. ok, got it, thanks. Obviously it is not the job of the IETF to define these services or business models, but I thought it might be helpful for us to consider services beyond the starting point of IPTV. =20 As suggested by others on this list, the existing framework may be able to fulfill some of the requirements put forward by this draft, but I argue that there is validity in the flexibility that the draft brings for IPTV as well as support for the applications I have discussed here. I welcome your comments.=20 Cheers,=20 Curtis=20 Curtis Sherbo, P.Eng=20 Product Line Manager=20 Redback Networks Canada Inc.=20 Phone: (604)629-7357=20 Mobile: (604)250-0672=20 ------_=_NextPart_001_01C7CAC4.02A34FC1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-maglione
Hi Curtis,
 
feedback inline.
 
Regards,
Sven

From: Curtis Sherbo = [mailto:csherbo@redback.com]=20
Sent: donderdag 19 juli 2007 20:12
To: OOGHE Sven;=20 ancp@ietf.org; roberta.maglione@telecomitalia.it;=20 angelo.garofalo@telecomitalia.it; flefauch@cisco.com
Subject: = RE:=20 [ANCP] Comments on draft-maglione

Hi Sven, comments inline.
 
Cheers,
Curtis

From: OOGHE Sven=20 [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Tuesday, July 17, = 2007=20 7:12 AM
To: Curtis Sherbo; ancp@ietf.org;=20 roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it;=20 flefauch@cisco.com
Subject: RE: [ANCP] Comments on=20 draft-maglione

Hi,
 
Please find my comments = inline.
 
Regards,
Sven

From: Curtis Sherbo = [mailto:csherbo@redback.com]=20
Sent: dinsdag 17 juli 2007 0:08
To: ancp@ietf.org;=20 roberta.maglione@telecomitalia.it; angelo.garofalo@telecomitalia.it;=20 flefauch@cisco.com
Subject: [ANCP] Comments on=20 draft-maglione

Greetings,

I think the flexibility of the solution = proposed in=20 draft-maglione-ancp-mcast-00.txt is necessary when you consider = applications=20 beyond simple broadcast IPTV.

I think it is useful in certain scenarios = in IPTV,=20 but I also think it is useful in a few other applications as listed=20 below:

1) Nomadicity/Roaming - whether = wired or=20 wireless it would be more effective to have a centralized policy = decision as=20 opposed to a distributed one.  This is especially true in a = wireless=20 instance where a client may be moving from one access point to another, = the=20 session would need to be handed off, would you want to see a full = authentication=20 step each hop so that you can refresh policies on the access point? 

I agree that there will be some central system that holds the = subscriber=20 policy information. In the case of nomadicity, this system will be in = the "home=20 network" (I don't mean customer premises network) and will need to = be=20 contacted by the "visiting network". This could be done in a push mode - = bringing the relevant policy information to the network elements in the = visiting=20 network - or in a pull mode - outsourcing the decision to the home = network. In=20 my view, in the case of multicast, the push model leads to less = signaling than=20 the pull model (unless some special tricks based on session grouping = with=20 timeouts are introduced in access platforms - but these have their own = issues as=20 I highlighted in my previous email). Hence I'm more in favor of using = the push=20 model even in nomadic/roaming cases. 

<CS> = I think I can=20 agree somewhat on the nomadic case.  But I still think in the = roaming case,=20 where you have an active session that is handed off from one Access = Point to=20 another, that it isn't scalable or seamless to push a full policy down = to the=20 Access Point. 

<Sven> The = mobility/roaming=20 case is one I handnt't thought of before. The amount of signaling for=20 push mode are greater than in the nomadic case, that's clear. = I think=20 that the use of multicast applications in a wireless network (e.g. = 802.11=20 or 802.16) is something where the folks from Mobile IP as = well as=20 from CAPWAP need to be involved. For L3 mobility (i.e. moving from one = subnet to=20 another), Mobile IP defines a number of techniques to tunnel traffic = from the=20 Foreign Agent to the Home Agent; perhaps extensions are needed for = allowing pull=20 and/or push models. Similarly, I've seen that CAPWAP defines techniques = to=20 configure MAC ACLs on wireless access points. Maybe CAPWAP would need to = be=20 extended to include pull and/or push models for mobility of multicast=20 applications.

2) Video Conferencing - As = conferences would=20 likely be ad-hoc, where the multicast groups may not be known in = advance, it=20 would likely be more efficient to update data centrally and query it as = a=20 participants join conferences. 

See next point.

3) Future Over the Top Video Partnerships = - Service=20 providers may choose to partner with internet video providers to provide = QoS and=20 multicast capabilities through a partnership on a per event basis.  = Like=20 the video conferencing scenario, this would be somewhat ad-hoc where the = multicast group mappings may not be known in advance, or may be reused = for=20 different content in succession, requiring repeated policy = refresh.  Again,=20 a centralized approach would appear to be more scalable for this=20 model.

I agree that these are channels which may not be known = to the=20 access provider in advance. There's however an easy way to solve this = case:=20 thanks to IGMPv3 SSM, it is possible to create two categories of=20 channels:

-=20 those with a known IP source address: these would include e.g. the=20 access/service provider's own IPTV offering

-=20 those with an unknown IP source address: these would include over the = top video,=20 or video conferencing

The Access Node can use the IP source address to filter = IGMPv3's in=20 different replication contexts (e.g. IPTV, Internet TV). Within this = context, it=20 could then decide to offer the content with the required QoS, and decide = whether=20 or not to accept or reject the channel. 

<CS> I = don't know if I=20 follow you here.  I think you are saying for the OTT Video, the = receiver=20 would send a Join for a group with an empty source list.  I fail to = see how=20 the AN can make an appropriate policy decision with only this = information. =20 My train of thought on this was that the application would know the MC = Group for=20 the event and send the join with the Group and the Source, or even the = just the=20 group, and the AN via ANCP via the NAS would query a AAA database to see = that=20 the customer either just purchased the event or if there is open access = to the=20 group.  I'm thinking a service provider may reuse a MC Group with = differing=20 sources as you mention above, and the QoS aspect could hold true as you = say, but=20 the event based authorization I believe is best handled with the = centralized=20 approach. I also believe this application requires the Termination = function=20 proposed in the draft.  

<Sven> The idea I had in mind was that = the access=20 node could hold White-List/Black-List policies for the = well-known=20 senders (e.g. the IPTV content servers, or some server in the Internet = for which=20 the service provider has some contract with the access provider). Upon = receiving=20 an IGMP join, the Access Node could first check if the source IP address = was a=20 known one (using IGMPv3 SSM). If so, then it would look at the=20 White-List/Black-List information and decide locally. If on the other = hand the=20 source IP address would not be not known, it could be basically anything = (over=20 the top video, video conferencing, some Internet TV channel in = Japan,...). In=20 this case the Access Node could do two=20 things

- simply accept, and handle access control at = some=20 other layer (e.g. using=20 encryption)

- outsource to let a central system=20 decide

I think that there may be scaling issues with = outsourcing everyting else. Instead, I think it's better to rely on SSM = as a=20 first filtering technique. Black/White lists could be used for further = filtering=20 of the known = sources.

To be noted, zap time is less of an = issue with=20 these three applications, as there is typically an accepted processing=20 time. 

Can you clarify what you mean with = this?  

<CS>In one of the = earlier arguments,=20 I believe put forward by Thomas, he mentioned that Zap time would be = lengthened=20 with this extra authorization step.  I agree that this is the case, = but my=20 point is that these applications don't have a expected rapid response = time such=20 is the case with IPTV channel change.  I believe these applications = will=20 have a different application interface with an experience similar to = clicking on=20 a web link, where a user is accustomed to waiting for a page to load, = they will=20 not be surprised by the extra processing time of the authorization=20 check.

<Sven> ok, got it, = thanks.

 Obviously it is not the job of = the IETF to=20 define these services or business models, but I thought it might be = helpful for=20 us to consider services beyond the starting point of IPTV. =20

As suggested by others on this list, the = existing=20 framework may be able to fulfill some of the requirements put forward by = this=20 draft, but I argue that there is validity in the flexibility that the = draft=20 brings for IPTV as well as support for the applications I have discussed = here.

I welcome your comments.

Cheers,
Curtis

Curtis Sherbo, P.Eng
Product Line Manager
Redback Networks=20 Canada Inc.
Phone: = (604)629-7357=20
Mobile: (604)250-0672 =

------_=_NextPart_001_01C7CAC4.02A34FC1-- --===============0908893940== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0908893940==-- From ancp-bounces@ietf.org Mon Jul 23 09:22:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxsI-0008W3-9m; Mon, 23 Jul 2007 09:22:58 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ICxsH-0008Vx-4O for ancp-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 09:22:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICxsC-0008Vf-RT for ancp@ietf.org; Mon, 23 Jul 2007 09:22:52 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICxs9-0004vC-Ul for ancp@ietf.org; Mon, 23 Jul 2007 09:22:52 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE01.ecitele.com) ([172.31.244.40]) by eci-iron-out.ecitele.com with ESMTP; 23 Jul 2007 16:31:41 +0300 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 23 Jul 2007 16:22:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Mon, 23 Jul 2007 16:22:47 +0300 Message-ID: In-Reply-To: <8144761F31F48D43AD53D09F5350E380B16776@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfJNXgYhtdJfelORs+hnxmwf6lKBQAE3CCgAPd1XDA= From: "Michel Platnic" To: "OOGHE Sven" , "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 23 Jul 2007 13:22:48.0269 (UTC) FILETIME=[9011CFD0:01C7CD2C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a89bc6ca33b14646e47592488f7eaef6 Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485607901==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0485607901== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CD2C.901A8577" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CD2C.901A8577 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Francois, Sven and All, =20 Please find my comments inline in green. ________________________________ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Wednesday, July 18, 2007 5:59 PM To: Francois Le Faucheur IMAP Cc: ancp@ietf.org; angelo.garofalo@telecomitalia.it Subject: RE: [ANCP] Comments on draft-maglione Hi Francois, 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =09 =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. Sven, Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). =20 I think I understand your reasoning.You're saying that for things like video conferencing, over the top video or video push features you would contact the central policy system because the access node doesn't have the information to decide locally. For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access Node. =20 In this case, I would think that the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address (for IPTV) or unknown IP source address (the "Everything else" mentioned by Curtis). That would imply to me that for everything which is IPTV, you could handle things locally, and for "Everything else", you would have to query the central policy server. This is because the Access Node doesn't know whether this user is allowed to watch e.g. the company's results broadcast vs any other Internet TV stream. So each time I would try to join a non-IPTV stream, the central policy server needs to check if the stream is a known one which is authorized, or some other Internet stream. Wouldn't this lead to scaling issues? Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular application. =20 =20 Using access control capabilities within the access network provides the two main following benefits: - refrain from sending any content to a customer that was not paid for (mostly relevant when Encryption is not used) - provides a filter against end-user applications/hackers that may send IGMP requests with invalid IP address =20 A solution where all the IP addresses that are not part of either the Black-list or the White-List are sent to a central policy server for authorization gives me some concerns regarding the robustness of the whole system. Same concern regarding the treatment of unknown IP source addresses ('Everything else'). =20 I understand that some applications may require sophisticated policy decision making and that, as a matter of fact, some AN/central policy server synchronization mechanism should to be proposed, but the solution must be Robust and Scalable. For now I am not convinced that solution proposed is either Robust or Scalable. =20 Regards, Michel. Cheers Francois=20 =20 Regards, Sven ------_=_NextPart_001_01C7CD2C.901A8577 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi=20 Francois, Sven and All,
 
Please=20 find my comments inline in green.

From: OOGHE Sven=20 [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Wednesday, July = 18, 2007=20 5:59 PM
To: Francois Le Faucheur IMAP
Cc: = ancp@ietf.org;=20 angelo.garofalo@telecomitalia.it
Subject: RE: [ANCP] Comments = on=20 draft-maglione

Hi Francois,

3) Future Over the Top Video Partnerships - Service providers = may choose=20 to partner with internet video providers to provide QoS and multicast=20 capabilities through a partnership on a per event basis.  Like the = video=20 conferencing scenario, this would be somewhat ad-hoc where the multicast = group=20 mappings may not be known in advance, or may be reused for different = content in=20 succession, requiring repeated policy refresh.  Again, a = centralized=20 approach would appear to be more scalable for this model.

I agree that these are channels which may not be = known to the=20 access provider in advance. There's however an easy way to solve = this case:=20 thanks to IGMPv3 SSM, it is possible to create two categories of=20 channels:

- those with a known IP source address: = these would=20 include e.g. the access/service provider's own IPTV=20 offering

- those with an unknown IP source = address: these=20 would include over the top video, or video=20 conferencing

The Access Node can use the IP source = address to=20 filter IGMPv3's in different replication contexts (e.g. IPTV, = Internet TV).=20 Within this context, it could then decide to offer the content with = the=20 required QoS, and decide whether or not to accept or reject the=20 channel.

I don't quite see how that solves the core issues mentioned by=20 Curtis:
What you describes allow to separate out the provider's channels = from=20 everything else (the Internet OTT services, Video Conference). But we = still=20 have to deal with the dynamic allocation/reallocation of channels to = the=20 "Everything else" applications with possibly large and fast changing=20 membership. 
 
Correct, I should have made this more explicit in my previous = reply. When using IGMPv3 with SSM, the information to = locally decide=20 whether or not to accept an IGMP report may or may not be present in = the=20 replication context on the Access Node.
 
 For those, it seems = more=20 efficient to use a "more centralized" repository than attempting to=20 permanently update/re-update/re-re-update/etc.. = White-Lists/Black-Lists on all=20 affected ANs/AN-ports. 
Am I missing something?
 
Well, perhaps we should do the math and count the amount of=20 messages...
 
. In=20 case of configuring the White-List/Black-List info, you'd configure = the info=20 at subscription time or when the IP session starts/ends. Typical = example is=20 the establishment of a PPP connection or DHCP lease. At this point, = the AAA=20 system will be contacted, which would be linked to the policy system=20 containing the user's multicast viewing rights. Those would then be = sent to=20 the Access Node, and need to be released when the session ends. = There's indeed=20 some updating and re-updating going on. But typically, a session can = last for=20 one or several hours (or could even be always-on), and the policy = information=20 may well be stable for long periods of time within that=20 session.
 
. In=20 case of contacting the central repository upon receiving an IGMP, you = would=20 have such an exchange at every channel zap. Whithin the session, it is = likely=20 that a subscriber will issue several IGMP messages to zap through = channels.=20 The number of message exchanges with the central respository will then = be=20 higher than in the first case.
To=20 reduce the message load, one could make use of some form of = channel=20 grouping to send a bulk of policy information to the Access Node (cf. = what is=20 mentioned in the draft), but in my view this brings us very close to = the first=20 case again, and makes me wonder if it would not be simpler to send all = required channel information to the Access Node at the start of the=20 session. There may still be a need to do some in-session policy=20 configuration changes on the Access Node, but even with this = additional load,=20 the resulting message load will never be higher than in the case of = checking=20 with the central policy server.
Sven,
Your comparison above assumes a "regular" scenario where the = conditional=20 access rules are known ahead of time at session setup.
For such regular scenarios, we agree that the Black-List/White-List = mechanisms works well. That is why those are defined in our proposal, = and the=20 expectation is that they would be used for the regular scenarios.

But again, the interesting question is for other scenarios, for = example, as=20 mentioned earlier, for those involving large and fast changing = membership. Just=20 for argument sake, let's imagine that an application is offering = on-demand=20 multicast-based services (eg video conferencing, video-push) and want to = rely on=20 multicast to do this and want to rely on the network to enforce who is = allowed=20 to join which video conf. Then, it may be that there are many "channels" = created/terminated all the time, with new members coming and going all = the time.=20 Some would allow multicast communications within small groups (eg one = for me to=20 send my latest video to my parents and uncle, one for you to send stuff = to your=20 brothers and sisters). Some would allow = multicast communication within=20 very large groups (eg one allowing all shareholders of company X to = watch from=20 home the company results announcement live video). For _that_ = application (and=20 not for each and every channel), just for that application, it appears = more=20 efficient to allow the NAS to query a more central conditional access = repository=20 than try to try update White-List/Black-List in every AN , and for all = affected=20 AN-ports as their membership changes all the time. In particular, for = the groups=20 authorizing communication within a very large community (but perhaps = where only=20 a small number will actually ever join).
 
I think I understand your = reasoning.You're saying that for things = like video=20 conferencing, over the top video or video push features you would = contact=20 the central policy system because the access node doesn't have the = information=20 to decide locally. For IPTV services offered by the access/service=20 provider, some Black-List/White-List info is pushed to the Access=20 Node.
 
In this case, I would think that the Access = Node could=20 e.g. use IGMPv3 SSM to distinguish between these two categories of = services,=20 based on a (or a few) known IP source address (for IPTV) or unknown IP = source=20 address (the "Everything else" mentioned by Curtis). That would imply to = me that=20 for everything which is IPTV, you could handle things locally, and for=20 "Everything else", you would have to query the central policy server. = This is=20 because the Access Node doesn't know whether this user is allowed to = watch e.g.=20 the company's results broadcast vs any other Internet TV=20 stream. So each time I would try = to join a=20 non-IPTV stream, the central policy server needs to check if the stream = is a=20 known one which is authorized, or some other Internet stream. Wouldn't = this lead=20 to scaling issues?

Perhaps, I should restate that the proposal is not about using=20 Black-List/White-List for all channels/port OR querying NAS for all=20 channels/ports. The proposal is about having the flexibility to use the = most=20 appropriate mechanism for each channel/port. So, in case of the example=20 on-demand application discussed above, one may use Black-List/White-List = for all=20 channels/port except the channel(s) allocated to that particular=20 application.
 
 
<Michel> Using access = control=20 capabilities within the access network provides the two=20 main following benefits:
-=20 refrain from sending any content to a customer that was not = paid for=20 (mostly relevant when Encryption is not used)
-=20 provides a filter against end-user applications/hackers that may = send IGMP=20 requests with invalid IP address
 
A=20 solution where all the IP addresses that are not part of either the = Black-list or the White-List are sent to a central policy = server=20 for authorization gives me some concerns regarding the robustness of the = whole=20 system. Same concern regarding the treatment of unknown IP source = addresses=20 ('Everything else').
 
I=20 understand that some applications may require sophisticated = policy decision=20 making and that, as a matter of fact, some AN/central policy server = synchronization mechanism should to be proposed, but the solution = must be=20 Robust and Scalable.
For=20 now I am not convinced that solution proposed is either Robust or=20 Scalable.
 
Regards,
Michel.
Cheers

Francois 
   
Regards,
Sven
------_=_NextPart_001_01C7CD2C.901A8577-- --===============0485607901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0485607901==-- From ancp-bounces@ietf.org Mon Jul 23 10:44:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICz9d-0002UC-Ox; Mon, 23 Jul 2007 10:44:57 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ICz9c-0002U5-JS for ancp-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 10:44:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICz9c-0002Tx-8V for ancp@ietf.org; Mon, 23 Jul 2007 10:44:56 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICz9b-0006xv-Ru for ancp@ietf.org; Mon, 23 Jul 2007 10:44:56 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2007 16:44:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CABRcpEaQ/uCLZmdsb2JhbACCZIx4Cwok X-IronPort-AV: i="4.16,570,1175464800"; d="scan'208,217"; a="148771613:sNHT173988744" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NEisE6029199 for ; Mon, 23 Jul 2007 16:44:54 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NEiokt028265 for ; Mon, 23 Jul 2007 14:44:54 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 16:44:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 23 Jul 2007 16:44:41 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Liaison from the DSL Forum Thread-Index: AcfNOACLHH/goC5CSKeDf1YzNLOoYw== From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 23 Jul 2007 14:44:50.0543 (UTC) FILETIME=[05F937F0:01C7CD38] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1545; t=1185201894; x=1186065894; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:=20Liaison=20from=20the=20DSL=20Forum |Sender:=20; bh=RE+8Agkix+G6Ju9Gv/LjUDYsO4GYJQH64I+jKyWa718=; b=oSFvF3OsKtf7IItLY/dafaCld/K2l2dXxRIihgvWxrVXtxkLUMmsTI9Wl4DbKnkFCiXzlQzd 60EMQjDF6DL1oh9erHWJW6pBY2AGrgu1jQMsKzon4SKPrOtVqfu6qcda; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [ANCP] Liaison from the DSL Forum X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1517103204==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1517103204== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CD38.05DF0231" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CD38.05DF0231 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi All, The ANCP WG has received a liaison statement and a copy of the WT-147 document from the DSL Forum, which has now been uploaded to the liaisons page. Please feel free to review the contents at: https://datatracker.ietf.org/liaison/ Regards, Woj. ------_=_NextPart_001_01C7CD38.05DF0231 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Liaison from the DSL Forum

Hi All,

The ANCP WG has received a liaison = statement and a copy of the WT-147 document from the DSL Forum, which = has now been uploaded to the liaisons page.

Please feel free to review the contents = at:
https://datatracker.ietf.org/liaison/

Regards,
Woj.

------_=_NextPart_001_01C7CD38.05DF0231-- --===============1517103204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1517103204==-- From ancp-bounces@ietf.org Mon Jul 23 11:26:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzoJ-00089A-DO; Mon, 23 Jul 2007 11:26:59 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ICzoH-000844-Al for ancp-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 11:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICzoH-00082c-00 for ancp@ietf.org; Mon, 23 Jul 2007 11:26:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICzoF-0000u3-Ef for ancp@ietf.org; Mon, 23 Jul 2007 11:26:56 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2007 17:26:55 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAGdlpEaQ/uCLZmdsb2JhbACCZIx4Cwok X-IronPort-AV: i="4.16,570,1175464800"; d="scan'208,217"; a="148777396:sNHT52905800" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l6NFQsvd011030; Mon, 23 Jul 2007 17:26:54 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6NFQqkt016393; Mon, 23 Jul 2007 15:26:52 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:26:52 +0200 Received: from [172.28.168.154] ([10.61.66.228]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:26:51 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> From: Francois Le Faucheur IMAP Subject: Re: [ANCP] Comments on draft-maglione Date: Mon, 23 Jul 2007 10:23:52 -0500 To: "Michel Platnic" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Jul 2007 15:26:51.0202 (UTC) FILETIME=[E4674220:01C7CD3D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9277; t=1185204414; x=1186068414; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Comments=20on=20draft-maglione |Sender:=20; bh=6/YxIGKlKf8ckSMDpaF8qeZQOooWjxZ0RLTIRRzeE9M=; b=JspKZ7jTMJp8fmIIqg65nXXZ1VPMblv9hdLr0vT3b4LLse92BJpCdqeQfOt3x/JNYZv4OWRx yh1o2jKUXRsdZQQJ/o2MqAkICWrd8blrFLCuknXC/GFdLqEXWMrQkail; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: angelo.garofalo@telecomitalia.it, OOGHE Sven , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0978460605==" Errors-To: ancp-bounces@ietf.org --===============0978460605== Content-Type: multipart/alternative; boundary=Apple-Mail-20-738602239 --Apple-Mail-20-738602239 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hi Michel, > > Using access control capabilities within the access > network provides the two main following benefits: > - refrain from sending any content to a customer that was not paid > for (mostly relevant when Encryption is not used) > - provides a filter against end-user applications/hackers that may > send IGMP requests with invalid IP address > > A solution where all the IP addresses that are not part of either > the Black-list or the White-List are sent to a central policy > server for authorization gives me some concerns regarding the > robustness of the whole system. Same concern regarding the > treatment of unknown IP source addresses ('Everything else'). Agreed. We had these concerns in mind also. This is why the Black- Lists and White-Lists include the ability to define arbitrarily large ranges/masks. In particular, as an example, one can easily define a Black-List which contains a single "catch-all" entry that matches any Multicast address & Source. Then you can define a White-List with the explicit channels you want to allow. This effectively implements a policy whereby everything is blocked by AN, except the channels that have been explicitly allowed in the White-List. In other words, the Black-List can be used for explicit listing of channels, or it can easily be used as a "catch-all" (for all, or for arbitrarily large ranges of channels). This should address your concern of making sure that the "default" behavior for any non-explicitly defined channel is not to query NAS/ Central_server. See in draft-maglione: " The White List and Black List can contain entries allowing: o an exact match for a (*,G) ASM group (e.g. ) o an exact match for a (S,G) SSM channel (e.g. o a mask-based range match for a (*,G) ASM group (e.g. ) o a mask-based range match for a (S,G) SSM channel (e.g. " > > I understand that some applications may require sophisticated > policy decision making and that, as a matter of fact, some AN/ > central policy server synchronization mechanism should to be proposed, > but the solution must be Robust and Scalable. > For now I am not convinced that solution proposed is either Robust > or Scalable. Let us know if you have specific robustness/scalability concerns (beyond the one discussed above)? Then we could work together on addressing those. Thanks Francois > > Regards, > Michel. > > Cheers > > Francois > > Regards, > Sven --Apple-Mail-20-738602239 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Hi Michel,

=
=A0
=
<Michel>=A0Using access control capabilities within = the access network provides the two = main=A0following=A0benefits:
- = refrain from sending=A0any content to a customer=A0that was not paid for = (mostly relevant when Encryption is not used)
=
- provides a filter=A0against end-user = applications/hackers that may send IGMP requests with invalid IP = address
=A0
=
A solution where all the IP addresses that = are not part of either=A0the Black-list or=A0the=A0White-List are=A0sent = to a central policy server for authorization gives me some concerns = regarding the robustness of the whole system. Same concern regarding the = treatment of=A0unknown IP source addresses ('Everything = else').

Agreed. We had these = concerns in mind also. This is why the Black-Lists and White-Lists = include the ability to define arbitrarily large ranges/masks. In = particular, as an example, one can easily define a Black-List which = contains a single "catch-all" entry that matches any Multicast address = & Source. Then you can define a White-List with the explicit = channels you want to allow. This effectively implements a policy whereby = everything is blocked by AN, except=A0the channels that have = been=A0explicitly allowed in=A0the White-List.
In other words, = the Black-List can be used for explicit listing of channels, or it can = easily be used as a "catch-all" (for all, or for arbitrarily large = ranges of channels).

This should address your = concern of making sure that the "default" behavior for any = non-explicitly defined channel is not to query = NAS/Central_server.

See in = draft-maglione:
"
The White List and Black List can = contain entries allowing:
=A0 =A0o=A0 an exact match for a = (*,G) ASM group (e.g. <G=3Dg.h.i.l>)
=A0 =A0o=A0 an = exact match for a (S,G) SSM channel (e.g. <S=3Ds.t.u.v,G=3Dg.h.i.l> =
=A0 =A0o=A0 a mask-based range match for a (*,G) ASM group = (e.g.
=A0 =A0 =A0 <G=3Dg.h.i.l/Mask>)
=A0 = =A0o=A0 a mask-based range match for a (S,G) SSM channel (e.g. =
=A0 =A0 =A0 <S=3Ds.t.u.v/Mask,G=3Dg.h.i.l/Mask> =
"

=A0
I understand that some applications may = require sophisticated policy=A0decision making=A0and that, as a matter = of fact, some AN/central policy server synchronization=A0mechanism = should to be proposed,
but the solution must be Robust and = Scalable.
For now I am not convinced = that solution proposed is either Robust or = Scalable.

Let us know if you have = specific robustness/scalability concerns (beyond the one discussed = above)?
Then we could work together on addressing = those.=A0

Thanks

Francois

=A0
=
Regards,
Michel.

Cheers

=
Francois=A0
=
=A0=A0=A0
Regards,
=
Sven

= --Apple-Mail-20-738602239-- --===============0978460605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0978460605==-- From ancp-bounces@ietf.org Mon Jul 23 11:52:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Cb-0000bS-OA; Mon, 23 Jul 2007 11:52:05 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ID0Ca-0000bG-8t for ancp-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 11:52:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0CZ-0000b7-RD for ancp@ietf.org; Mon, 23 Jul 2007 11:52:03 -0400 Received: from mailf.telecomitalia.it ([156.54.233.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0CX-0000Mb-5L for ancp@ietf.org; Mon, 23 Jul 2007 11:52:03 -0400 Received: from ptpxch007ba020.idc.cww.telecomitalia.it ([156.54.240.50]) by mailf.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:51:50 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch007ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:51:49 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Mon, 23 Jul 2007 17:51:49 +0200 Message-ID: <9E577E61D0108D4F8CD482029B613F5C0181BD09@PTPEVS108BA020.idc.cww.telecomitalia.it> In-Reply-To: <8144761F31F48D43AD53D09F5350E380B16776@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione thread-index: AcfJNXgYhtdJfelORs+hnxmwf6lKBQAE3CCgAP29ldA= References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380B16776@FRVELSMBS22.ad2.ad.alcatel.com> From: "Maglione Roberta" To: "OOGHE Sven" X-OriginalArrivalTime: 23 Jul 2007 15:51:49.0734 (UTC) FILETIME=[61991860:01C7CD41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ec0f3d4960e6167ab597cf7076be2db Cc: Garofalo Angelo , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0573300442==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0573300442== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CD41.6130D031" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CD41.6130D031 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sven, Michel and All, Thanks for your comments on the draft. I agree with you that there are scenarios where a "push model" could be used (this is the reason why we introduced white and black lists concept), while there are cases where a "pull model" better fits the needs. In my opinion ANCP should be flexible enough to cover both models.=20 As far as conditional access in my opinion scenarios that could be better developed using pull model are cases where Network Service Provider and Content Service Provider are two different entities and the AN is part of NSP while authorization function needs to be performed by CP. In these scenarios AN needs to be able to query AAA Server in CP network in order to get authorization to receive the multicast flow. Prepaid Service can be one example: in particular I think it would be more efficient having the information related to the remaining credit centralized on AAA Server and leaving the authorization function centralized instead of spread it around and overloading the AN with all different policies.=20 As far as admission control thinking about triple play services where synchronization between unicast and multicast admission control is required in order to be able to efficiently share the available bandwidth on the access line in my opinion a pull approach would be more flexible than a push model, because it would allow to perform synchronized admission control on the fly having a NAS, as centralized control point, talking with a Policy Server in order to take decision about the new flow.=20 Regards, Roberta =20 ------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia -------------------------------------------------=20 ________________________________ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Wednesday, July 18, 2007 4:59 PM To: Francois Le Faucheur IMAP Cc: Curtis Sherbo; ancp@ietf.org; Maglione Roberta; Garofalo Angelo Subject: RE: [ANCP] Comments on draft-maglione =20 Hi Francois, =20 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. =20 Sven, =20 Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. =20 But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). =20 I think I understand your reasoning.You're saying that for things like video conferencing, over the top video or video push features you would contact the central policy system because the access node doesn't have the information to decide locally. For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access Node. =20 In this case, I would think that the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address (for IPTV) or unknown IP source address (the "Everything else" mentioned by Curtis). That would imply to me that for everything which is IPTV, you could handle things locally, and for "Everything else", you would have to query the central policy server. This is because the Access Node doesn't know whether this user is allowed to watch e.g. the company's results broadcast vs any other Internet TV stream. So each time I would try to join a non-IPTV stream, the central policy server needs to check if the stream is a known one which is authorized, or some other Internet stream. Wouldn't this lead to scaling issues? =20 Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular application. =20 Cheers =20 Francois=20 =20 Regards, Sven -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 ------_=_NextPart_001_01C7CD41.6130D031 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sven, Michel and = All,

   Thanks for your comments on the = draft. I agree with you that there are scenarios where a "push model" = could be used (this is the reason why we introduced white and black lists = concept), while there are cases where a "pull model" better fits the = needs. In my opinion ANCP should be flexible enough to cover both models. =

As  far as conditional access in my = opinion scenarios that could be better developed using pull model are cases = where Network Service Provider and Content Service Provider are two different entities and the AN is part of NSP while authorization function needs to = be performed by CP. In these scenarios AN needs to be able to query AAA = Server in CP network in order to get authorization to receive the multicast = flow.  Prepaid Service can be one example: in particular I think it would be more = efficient having the information related to the remaining credit centralized on = AAA Server and leaving the authorization function centralized instead of = spread it around and overloading the AN with  all different policies. =

As far as admission control thinking about = triple play services where synchronization between unicast and multicast admission = control is required in order to be able to efficiently share the available = bandwidth on the access line in my opinion a pull approach would be more flexible = than a push model, because it would allow to perform synchronized admission = control on the fly having a NAS, as centralized control point, talking with a = Policy Server in order to take decision about the new flow. =

Regards,

Roberta

 =

-------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia
-------------------------------------------------

From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Wednesday, July 18, = 2007 4:59 PM
To: Francois Le Faucheur IMAP
Cc: Curtis Sherbo; = ancp@ietf.org; Maglione Roberta; Garofalo = Angelo
Subject: RE: [ANCP] = Comments on draft-maglione

 

Hi = Francois,

 

3) Future Over the Top Video Partnerships - = Service providers may choose to partner with internet video providers to provide = QoS and multicast capabilities through a partnership on a per event = basis.  Like the video conferencing scenario, this would be somewhat ad-hoc = where the multicast group mappings may not be known in advance, or may be reused = for different content in succession, requiring repeated policy = refresh.  Again, a centralized approach would appear to be more scalable for this = model.

I agree that these are channels which may not be known = to the access provider in advance. There's however an easy way to solve this = case: thanks to IGMPv3 SSM, it is possible to create two categories of = channels:

- those with a known IP source address: these would = include e.g. the access/service provider's own IPTV = offering

- those with an unknown IP source address: these would include over the top video, or video = conferencing

The Access Node can use the IP source address to = filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). = Within this context, it could then decide to offer the content with the = required QoS, and decide whether or not to accept or reject the = channel.

I don't quite see how that solves the core issues mentioned by = Curtis:

What you describes allow to separate out the provider's channels = from everything else (the Internet OTT services, Video Conference). But we = still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast = changing membership. 

 

Correct, I should have made this = more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report = may or may not be present in the replication context on the Access = Node.

 

 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all = affected ANs/AN-ports. 

Am I missing something?

 

Well, perhaps we should do the math = and count the amount of messages...

 

. In case of configuring the White-List/Black-List info, you'd configure the info at subscription = time or when the IP session starts/ends. Typical example is the establishment of = a PPP connection or DHCP lease. At this point, the AAA system will be = contacted, which would be linked to the policy system containing the user's = multicast viewing rights. Those would then be sent to the Access Node, and need to = be released when the session ends. There's indeed some updating and re-updating = going on. But typically, a session can last for one or several hours (or could = even be always-on), and the policy information may well be stable for long = periods of time within that session.

 

. In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at = every channel zap. Whithin the session, it is likely that a subscriber will = issue several IGMP messages to zap through channels. The number of message = exchanges with the central respository will then be higher than in the first = case.

To reduce the message = load, one could make use of some form of channel grouping to send a bulk of policy = information to the Access Node (cf. what is mentioned in the draft), but in my view = this brings us very close to the first case again, and makes me wonder if it = would not be simpler to send all required channel information to the Access = Node at the start of the session. There may still be a need to do some = in-session policy configuration changes on the Access Node, but even with this = additional load, the resulting message load will never be higher than in the case = of checking with the central policy server.

 

Sven,

 

Your comparison above assumes a "regular" scenario = where the conditional access rules are known ahead of time at session = setup.

For such regular scenarios, we agree that the = Black-List/White-List mechanisms works well. That is why those are defined in our proposal, = and the expectation is that they would be used for the regular = scenarios.

 

But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast = changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, = video-push) and want to rely on multicast to do this and want to rely on the network = to enforce who is allowed to join which video conf. Then, it may be that = there are many "channels" created/terminated all the time, with new = members coming and going all the time. Some would allow multicast communications = within small groups (eg one for me to send my latest video to my parents and = uncle, one for you to send stuff to your brothers and sisters). Some would = allow multicast communication within very large groups (eg one = allowing all shareholders of company X to watch from home the company results = announcement live video). For _that_ application (and not for each and every = channel), just for that application, it appears more efficient to allow the NAS to = query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as = their membership changes all the time. In particular, for the groups authorizing = communication within a very large community (but perhaps where only a small number = will actually ever join).

 

I think I understand your = reasoning.You're saying that for things like video conferencing, over = the top video or video push features you would contact the central policy = system because the access node doesn't have the information to decide locally. = For IPTV services offered by the access/service provider, some = Black-List/White-List info is pushed to the Access Node.

 

In this case, I would think that = the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address = (for IPTV) or unknown IP source address (the "Everything else" = mentioned by Curtis). That would imply to me that for everything which is IPTV, = you could handle things locally, and for "Everything else", you would = have to query the central policy server. This is because the Access Node doesn't = know whether this user is allowed to watch e.g. the company's results = broadcast vs any other Internet TV stream. So each time I would try to join a = non-IPTV stream, the central policy server needs to check if the stream is a = known one which is authorized, or some other Internet stream. Wouldn't this lead = to scaling issues?

 

Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the = most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List = for all channels/port except the channel(s) allocated to that particular application.

 

Cheers

 

Francois 

   
= Regards,

Sven

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C7CD41.6130D031-- --===============0573300442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0573300442==-- From ancp-bounces@ietf.org Tue Jul 24 08:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJsj-00089z-VB; Tue, 24 Jul 2007 08:52:53 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IDJsi-00084n-Pz for ancp-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 08:52:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJsi-00082O-Ei for ancp@ietf.org; Tue, 24 Jul 2007 08:52:52 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDJsg-0006J3-8F for ancp@ietf.org; Tue, 24 Jul 2007 08:52:52 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 24 Jul 2007 05:52:49 -0700 X-IronPort-AV: i="4.16,574,1175497200"; d="scan'208,217"; a="42695332:sNHT178615028" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Tue, 24 Jul 2007 08:52:46 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B76297@proton.jnpr.net> In-Reply-To: <9E577E61D0108D4F8CD482029B613F5C0181BD09@PTPEVS108BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfJNXgYhtdJfelORs+hnxmwf6lKBQAE3CCgAP29ldAALE6Z4A== From: "Sanjay Wadhwa" To: "Maglione Roberta" , "OOGHE Sven" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32be8a281ad9c08293535a48dd468a26 Cc: Garofalo Angelo , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1571532349==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1571532349== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CDF1.88CE54BA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CDF1.88CE54BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Maglione et al.. At a high level the proposals in the draft are reasonable and in line with the framework and discussions in the DSLF. More specific comments from myself and Derek on the draft and responses to some of the issues raised on the mailing list included below: =20 4.2 Conditional access and admission control with NAS decision It is not clear what information is required / envisaged for the Admission Request / Response messages -=20 Multicast Flow and ACI at a minimum seems to be needed. It will be useful to clarify that the NAS is expected to know the BW information for the multicast flow (flow-group) for which admission control is being requested. This could be locally configured on the NAS, could be provided at auth time from radius/policy server, or could be dynamically auto-sensed (measured) on the NAS. =20 4.3 Multicast Accounting.=20 This section implies that accounting is triggered by Admission Response, which implies that CAC to the NAS must have been performed to trigger accounting. One would think accounting could be required also for other flows in the flow-group than the one which triggered admission request/response. There probably needs to be a separate mechanism. Or are we stipulating that another criterion (beyond bandwidth) to group flows in the flow-group is also based on the need (or lack of) for accounting. It is probably worth-while to state that grouping of flows into flow-groups is the function of the NAS and how the grouping is done is transparent to AN. =20 Also, should consider some form of mechanism for bulk accounting such that multiple accounting events can be reported in one message. =20 4.4 Conditional access and admission control... Item 12 should have an explicit reference to the ANCP capabilities negotiation, as one assumes there will be an impact there. =20 5.1.1 Provisioning AN with White/Black lists... Whether here or elsewhere, there needs to be some clarification on how are multiple users / sessions per port handled This may be: (a) Multiple subscribers - i.e. real users - e.g. multiple sessions from PCs ( PPPoE or DHCP ) and bridged DSL CPE (b) One subscriber but multiple devices - e.g. separate sessions for PC, VoIP/Voice, STB. (c) Combination of (a) and (b) =20 There seems to be an assumption of a DSL line / AN port and a subscriber as having a 1:1 mapping which is not always the case. =20 5.1.2 Provisioning AN.. How does the NAS know which ports are active on an AN and therefore require data - the push mechanism implies that the NAS would pre-provision, but consider:=20 (i) the AN has say 100 ports=20 (ii) only 17 of these have been "turned up" - i.e. activated yet =3D> Does the NAS send data for all 100 ports? =3D> If the NAS only sends for the active ports, how does it know which ones these are? =20 5.2.2 Multicast Flow with NAS decision.... The message flows indicate that the replication always starts for a given flow on reception of an "Admission Response" for that flow. This might not always be true. There are atleast two conditions here: (a) A Join for a different flow in the same flow-group is received by the AN due to a channel change, before the admission response is received for the pending request. In this case one would assume the admission response is still applicable (since it is for the flow-group) and the replication for the new flow can commence. (b) A new Join for a different flow in a different flow-group (e.g. going from an SD to a HD flow) might be received while admission response for the old join is still pending. In this case another admission request is generated and no replication happens. Message flows or text is needed to indicate these scenarios. =20 Comments on discussion points raised on the list: =20 1. Multicast Conditional Access We see the benefit in having a mechanism whereby AN can be selectively forced to query a NAS for permission, rather than a PUSH model. Based on some of the responses, it might be useful to explicitly indicate that the white and black lists also provide a mechanism to distinguish between flows that can arise and flows that are never expected to arise. =20 2. Multicast Admission Control. =20 It has been pointed out: =20 >> CAC discussion goes beyond the ANCP WG.=20 =20 This might be true. However, there are many models today whereby the NAS performs admission control for the DSL line for unicast traffic, and given the ANCP scope which is defined as: "enabling NAS and AN to functionally behave as one single black box, while replication is performed on the AN, but without any loss of functionality compared to if replication was performed on NAS", then it would seem consistent to have ANCP allow the admission control to be performed on the NAS but use replication on the AN, rather than forcing the admission control to be done on the AN. This is just as a NAS can today use an IGMP join to perform BW adjustment for multicast traffic, one should be able to use information from the AN on multicast status to perform admission control at the NAS.=20 In terms of general models the DSL Forum has always defined a QoS aware function in the NAS/BNG/ for shaping traffic towards the user so as not to flood any network between NAS and AN with traffic that is later discarded. Again, we see it as a valid goal to keep this functionality (and indeed the current QoS architecture in many providers networks ), while having the advantages of fully distributed replication. This unified admission control can be achieved using mechanisms such as IGMP forking in the CPE / AN, but this is not always applicable / available.=20 =20 Other standard bodies are defining reference architectures that call out functions and interfaces between different entities for CAC and access control. The functions themselves can be instantiated on different network elements, and the reference interfaces are between these different functions (rather than between network elements themselves). It is easy to imagine ANCP fitting the bill for one or more of these reference interfaces. If needed, ANCP WG can generate liaison statements to some of these other standard bodies. =20 Thanks -Sanjay/Derek -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: Monday, July 23, 2007 11:52 AM To: OOGHE Sven Cc: Garofalo Angelo; ancp@ietf.org Subject: RE: [ANCP] Comments on draft-maglione Hi Sven, Michel and All, Thanks for your comments on the draft. I agree with you that there are scenarios where a "push model" could be used (this is the reason why we introduced white and black lists concept), while there are cases where a "pull model" better fits the needs. In my opinion ANCP should be flexible enough to cover both models.=20 As far as conditional access in my opinion scenarios that could be better developed using pull model are cases where Network Service Provider and Content Service Provider are two different entities and the AN is part of NSP while authorization function needs to be performed by CP. In these scenarios AN needs to be able to query AAA Server in CP network in order to get authorization to receive the multicast flow. Prepaid Service can be one example: in particular I think it would be more efficient having the information related to the remaining credit centralized on AAA Server and leaving the authorization function centralized instead of spread it around and overloading the AN with all different policies.=20 As far as admission control thinking about triple play services where synchronization between unicast and multicast admission control is required in order to be able to efficiently share the available bandwidth on the access line in my opinion a pull approach would be more flexible than a push model, because it would allow to perform synchronized admission control on the fly having a NAS, as centralized control point, talking with a Policy Server in order to take decision about the new flow.=20 Regards, Roberta =20 ------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia -------------------------------------------------=20 _____ =20 From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Wednesday, July 18, 2007 4:59 PM To: Francois Le Faucheur IMAP Cc: Curtis Sherbo; ancp@ietf.org; Maglione Roberta; Garofalo Angelo Subject: RE: [ANCP] Comments on draft-maglione =20 Hi Francois, =20 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. =20 Sven, =20 Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. =20 But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). =20 I think I understand your reasoning.You're saying that for things like video conferencing, over the top video or video push features you would contact the central policy system because the access node doesn't have the information to decide locally. For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access Node. =20 In this case, I would think that the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address (for IPTV) or unknown IP source address (the "Everything else" mentioned by Curtis). That would imply to me that for everything which is IPTV, you could handle things locally, and for "Everything else", you would have to query the central policy server. This is because the Access Node doesn't know whether this user is allowed to watch e.g. the company's results broadcast vs any other Internet TV stream. So each time I would try to join a non-IPTV stream, the central policy server needs to check if the stream is a known one which is authorized, or some other Internet stream. Wouldn't this lead to scaling issues? =20 Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular application. =20 Cheers =20 Francois=20 =20 Regards, Sven -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- ------_=_NextPart_001_01C7CDF1.88CE54BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Maglione et al..
 =20 At a high level the proposals in the draft are reasonable and in line = with the=20 framework and discussions in the DSLF. More specific comments from = myself and=20 Derek on the draft and responses to some of the issues raised on the = mailing=20 list included below:
 
4.2=20 Conditional access and admission control with NAS decision
It is not = clear=20 what information is required / envisaged for the Admission Request / = Response=20 messages -
Multicast Flow and ACI at a minimum seems to be needed. = It will=20 be useful to clarify that the NAS is expected to know the BW information = for the=20 multicast flow (flow-group) for which admission control is being = requested. This=20 could be locally configured on the NAS, could be provided at auth time = from=20 radius/policy server, or could be dynamically auto-sensed (measured) on = the=20 NAS.
 
4.3=20 Multicast Accounting.
This section implies that accounting is = triggered by=20 Admission Response, which implies that CAC to the NAS must have been = performed=20 to trigger accounting. One would think accounting could be required also = for=20 other flows in the flow-group than the one which triggered admission=20 request/response. There probably needs to be a separate mechanism.
Or = are we=20 stipulating that another criterion (beyond bandwidth) to group flows in = the=20 flow-group is also based on the need (or lack of) for accounting.  = It is=20 probably worth-while to state that grouping of flows into flow-groups is = the=20 function of the NAS and how the grouping is done is transparent to=20 AN.
 
Also,=20 should consider some form of mechanism for bulk accounting such that = multiple=20 accounting events can be reported in one message.
 
4.4=20 Conditional access and admission control…
Item 12 should have = an explicit=20 reference to the ANCP capabilities negotiation, as one assumes there = will be an=20 impact there.
 
5.1.1 Provisioning AN with White/Black=20 lists…
Whether here or elsewhere, there needs to be some = clarification on how=20 are multiple users / sessions per port handled
This may be:
(a) = Multiple=20 subscribers - i.e. real users - e.g. multiple sessions from PCs ( PPPoE = or DHCP=20 ) and bridged DSL CPE
(b) One subscriber but multiple devices - e.g. = separate=20 sessions for PC, VoIP/Voice, STB.
(c) Combination of (a) and=20 (b)
 
There seems to be an assumption of a DSL line / AN port = and a=20 subscriber as having a 1:1 mapping which is not always the=20 case.
 
5.1.2=20 Provisioning AN..
How does the NAS know which ports are active on an = AN and=20 therefore require data - the push mechanism implies that the NAS would=20 pre-provision, but consider:
(i) the AN has say 100 ports
(ii) = only 17=20 of these have been "turned up" - i.e. activated yet
=3D> Does the = NAS send=20 data for all 100 ports?
=3D> If the NAS only sends for the active = ports, how=20 does it know which ones these are?
 
5.2.2=20 Multicast Flow with NAS decision….
The message flows indicate = that the=20 replication always starts for a given flow on reception of an "Admission = Response" for that flow. This might not always be true. There are = atleast two=20 conditions here:
(a) A Join for a different flow in the same = flow-group is=20 received by the AN due to a channel change, before the admission = response is=20 received for the pending request. In this case one would assume the = admission=20 response is still applicable (since it is for the flow-group) and the=20 replication for the new flow can commence.
(b) A new Join for a = different=20 flow in a different flow-group (e.g. going from an SD to a HD flow) = might be=20 received while admission response for the old join is still pending. In = this=20 case another admission request is generated and no replication=20 happens.
Message flows or text is needed to indicate = these=20 scenarios.
 
Comments on discussion points raised on the=20 list:
 
1.=20 Multicast Conditional Access
We see the benefit in having a mechanism = whereby=20 AN can be selectively forced to query a NAS for permission, rather than = a PUSH=20 model. Based on some of the responses, it might be useful to explicitly = indicate=20 that the white and black lists also provide a mechanism to distinguish = between=20 flows that can arise and flows that are never expected to=20 arise.
 
2.=20 Multicast Admission Control.
 
It has=20 been pointed out:
 
>> CAC discussion goes beyond the ANCP = WG.=20
 
This=20 might be true. However, there are many models today whereby the NAS = performs=20 admission control for the DSL line for unicast traffic, and given the = ANCP scope=20 which is defined as: "enabling NAS and AN to functionally behave as one = single=20 black box, while replication is performed on the AN, but without any = loss of=20 functionality compared to if replication was performed on NAS",  = then it=20 would seem consistent to have ANCP allow the admission control to be = performed=20 on the NAS but use replication on the AN, rather than forcing the = admission=20 control to be done on the AN. This is just as a  NAS can today use = an IGMP=20 join to perform BW adjustment for multicast traffic, one should be able = to use=20 information from the AN on multicast status to perform admission control = at the=20 NAS.
In terms of general models the DSL Forum has always defined a = QoS aware=20 function in the NAS/BNG/ for shaping traffic towards the user so as = not  to=20 flood any network between NAS and AN with traffic that is later = discarded.=20 Again, we see it as a valid goal to keep this functionality (and indeed = the=20 current QoS architecture in many providers networks ),  while = having the=20 advantages of fully distributed replication.  This unified = admission=20 control can be achieved using mechanisms such as IGMP forking in the CPE = / AN,=20 but this is not always applicable / available.
 
Other=20 standard bodies are defining reference architectures that call out = functions and=20 interfaces between different entities for CAC and access control. The = functions=20 themselves can be instantiated on different network elements, and the = reference=20 interfaces are between these different functions (rather than between = network=20 elements themselves). It is easy to imagine ANCP fitting the bill for = one or=20 more of these reference interfaces. If needed, ANCP WG can generate = liaison=20 statements to some of these other standard bodies.
 
Thanks
-Sanjay/Derek
-----Original Message-----
From: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Sent: Monday, = July 23,=20 2007 11:52 AM
To: OOGHE Sven
Cc: Garofalo Angelo;=20 ancp@ietf.org
Subject: RE: [ANCP] Comments on=20 draft-maglione

Hi Sven, Michel and = All,

   Thanks for your comments on the = draft. I=20 agree with you that there are scenarios where a "push model" could be = used=20 (this is the reason why we introduced white and black lists concept), = while=20 there are cases where a "pull model" better fits the needs. In my = opinion ANCP=20 should be flexible enough to cover both models. =

As  far as conditional access in my = opinion=20 scenarios that could be better developed using pull model are cases = where=20 Network Service Provider and Content Service Provider are two = different=20 entities and the AN is part of NSP while authorization function needs = to be=20 performed by CP. In these scenarios AN needs to be able to query AAA = Server in=20 CP network in order to get authorization to receive the multicast = flow. =20 Prepaid Service can be one example: in particular I think it would be = more=20 efficient having the information related to the remaining credit = centralized=20 on AAA Server and leaving the authorization function centralized = instead of=20 spread it around and overloading the AN with  all different = policies.=20

As far as admission control thinking about = triple play=20 services where synchronization between unicast and multicast admission = control=20 is required in order to be able to efficiently share the available = bandwidth=20 on the access line in my opinion a pull approach would be more = flexible than a=20 push model, because it would allow to perform synchronized admission = control=20 on the fly having a NAS, as centralized control point, talking with a = Policy=20 Server in order to take decision about the new flow.=20

Regards,

Roberta

 

-------------------------------------------------
Roberta=20 Maglione  - CCIE #18425
Telecom=20 = Italia
-------------------------------------------------= =

From: OOGHE Sven=20 [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Wednesday, July 18, 2007 = 4:59=20 PM
To: = Francois Le Faucheur IMAP
Cc: Curtis Sherbo; = ancp@ietf.org;=20 Maglione Roberta; Garofalo=20 Angelo
Subject: RE: [ANCP] Comments on = draft-maglione

 

Hi=20 Francois,

 

3) Future Over the Top = Video=20 Partnerships - Service providers may choose to partner with internet = video=20 providers to provide QoS and multicast capabilities through a = partnership on a=20 per event basis.  Like the video conferencing scenario, this = would be=20 somewhat ad-hoc where the multicast group mappings may not be known in = advance, or may be reused for different content in succession, = requiring=20 repeated policy refresh.  Again, a centralized approach would = appear to=20 be more scalable for this model.

I agree = that=20 these are channels which may not be known to the access provider = in=20 advance. There's however an easy way to solve this case: thanks to = IGMPv3=20 SSM, it is possible to create two categories of=20 channels:

- those = with a=20 known IP source address: these would include e.g. the = access/service=20 provider's own IPTV offering

- those = with an=20 unknown IP source address: these would include over the top video, = or=20 video conferencing

The = Access Node=20 can use the IP source address to filter IGMPv3's in different = replication=20 contexts (e.g. IPTV, Internet TV). Within this context, it could = then=20 decide to offer the content with the required QoS, and decide = whether or=20 not to accept or reject the=20 channel.

I don't quite see how that solves the core = issues=20 mentioned by Curtis:

What you describes allow to separate out = the=20 provider's channels from everything else (the Internet OTT services, = Video=20 Conference). But we still have to deal with the dynamic=20 allocation/reallocation of channels to the "Everything else" = applications=20 with possibly large and fast changing membership. 

 

Correct, = I should=20 have made this more explicit in my previous = reply. When using=20 IGMPv3 with SSM, the information to locally decide whether or not to = accept=20 an IGMP report may or may not be present in the replication context = on the=20 Access Node.

 

 For those, it seems more efficient = to use a=20 "more centralized" repository than attempting to permanently=20 update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all = affected=20 ANs/AN-ports. 

Am I missing=20 something?

 

Well, = perhaps we=20 should do the math and count the amount of=20 messages...

 

. In case = of=20 configuring the White-List/Black-List info, you'd configure the info = at=20 subscription time or when the IP session starts/ends. Typical = example is the=20 establishment of a PPP connection or DHCP lease. At this point, the = AAA=20 system will be contacted, which would be linked to the policy system = containing the user's multicast viewing rights. Those would then be = sent to=20 the Access Node, and need to be released when the session ends. = There's=20 indeed some updating and re-updating going on. But typically, a = session can=20 last for one or several hours (or could even be always-on), and the = policy=20 information may well be stable for long periods of time within that=20 session.

 

. In case = of=20 contacting the central repository upon receiving an IGMP, you would = have=20 such an exchange at every channel zap. Whithin the session, it is = likely=20 that a subscriber will issue several IGMP messages to zap through = channels.=20 The number of message exchanges with the central respository will = then be=20 higher than in the first case.

To reduce = the=20 message load, one could make use of some form of channel = grouping to=20 send a bulk of policy information to the Access Node (cf. what is = mentioned=20 in the draft), but in my view this brings us very close to the first = case=20 again, and makes me wonder if it would not be simpler to send all = required=20 channel information to the Access Node at the start of the=20 session. There may still be a need to do some in-session policy = configuration changes on the Access Node, but even with this = additional=20 load, the resulting message load will never be higher than in the = case of=20 checking with the central policy=20 server.

 

Sven,

 

Your comparison above assumes a "regular" = scenario=20 where the conditional access rules are known ahead of time at session=20 setup.

For such regular scenarios, we agree that = the=20 Black-List/White-List mechanisms works well. That is why those are = defined in=20 our proposal, and the expectation is that they would be used for the = regular=20 scenarios.

 

But again, the interesting question is for = other=20 scenarios, for example, as mentioned earlier, for those involving = large and=20 fast changing membership. Just for argument sake, let's imagine that = an=20 application is offering on-demand multicast-based services (eg video=20 conferencing, video-push) and want to rely on multicast to do this and = want to=20 rely on the network to enforce who is allowed to join which video = conf. Then,=20 it may be that there are many "channels" created/terminated all the = time, with=20 new members coming and going all the time. Some would allow multicast=20 communications within small groups (eg one for me to send my latest = video to=20 my parents and uncle, one for you to send stuff to your brothers and = sisters).=20 Some would allow multicast communication within very large = groups=20 (eg one allowing all shareholders of company X to watch from home the = company=20 results announcement live video). For _that_ application (and not for = each and=20 every channel), just for that application, it appears more efficient = to allow=20 the NAS to query a more central conditional access repository than try = to try=20 update White-List/Black-List in every AN , and for all affected = AN-ports as=20 their membership changes all the time. In particular, for the groups=20 authorizing communication within a very large community (but perhaps = where=20 only a small number will actually ever=20 join).

 

I think I = understand=20 your reasoning.You're saying that for things like video = conferencing, over the top video or video push features you would = contact=20 the central policy system because the access node doesn't have the = information=20 to decide locally. For IPTV services offered by = the access/service=20 provider, some Black-List/White-List info is pushed to the Access=20 Node.

 

In this = case, I would=20 think that the Access Node could e.g. use IGMPv3 SSM to distinguish = between=20 these two categories of services, based on a (or a few) known IP = source=20 address (for IPTV) or unknown IP source address (the "Everything else" = mentioned by Curtis). That would imply to me that for everything which = is=20 IPTV, you could handle things locally, and for "Everything else", you = would=20 have to query the central policy server. This is because the Access = Node=20 doesn't know whether this user is allowed to watch e.g. the company's = results=20 broadcast vs any other Internet TV stream. So each time I would = try to=20 join a non-IPTV stream, the central policy server needs to check if = the stream=20 is a known one which is authorized, or some other Internet stream. = Wouldn't=20 this lead to scaling issues?

 

Perhaps, I should restate that the proposal = is not=20 about using Black-List/White-List for all channels/port OR querying = NAS for=20 all channels/ports. The proposal is about having the flexibility to = use the=20 most appropriate mechanism for each channel/port. So, in case of the = example=20 on-demand application discussed above, one may use = Black-List/White-List for=20 all channels/port except the channel(s) allocated to that particular=20 application.

 

Cheers

 

Francois 

   
Regards,

Sven

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the = persons
above and may contain confidential information. If you have = received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender = and=20 delete
the message. Should you have any questions, please contact = us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 = you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C7CDF1.88CE54BA-- --===============1571532349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1571532349==-- From ancp-bounces@ietf.org Tue Jul 24 09:00:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJzh-0003FC-Bq; Tue, 24 Jul 2007 09:00:05 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IDJzf-0003Ek-Ou for ancp-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 09:00:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDJzf-0003EX-8L for ancp@ietf.org; Tue, 24 Jul 2007 09:00:03 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDJzd-0006Q6-PI for ancp@ietf.org; Tue, 24 Jul 2007 09:00:03 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 24 Jul 2007 06:00:01 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 24 Jul 2007 08:59:59 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2803B76298@proton.jnpr.net> In-Reply-To: <8144761F31F48D43AD53D09F5350E380B167C8@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ancp-protocol-01 Thread-Index: AcfJU0MVpf6Xh8dzROO8wqtWZWz3rgEnqKFg From: "Sanjay Wadhwa" To: "OOGHE Sven" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: Subject: [ANCP] RE: Comments on draft-ietf-ancp-protocol-01 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1859815652==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1859815652== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CDF2.8AC70266" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CDF2.8AC70266 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20 See inline. =20 -Sanjay =20 ----- Original Message ----- From: OOGHE Sven < Sven.Ooghe@alcatel-lucent.be> To: ancp@ietf.org < ancp@ietf.org>; Sanjay Wadhwa Sent: Wed Jul 18 11:49:44 2007 Subject: Comments on draft-ietf-ancp-protocol-01 =20 Hi,=20 =20 Upon reading the ANCP protocol draft, I noticed that section 4 contains some sections which overlap with the ANCP Framework and Requirements document. In order to avoid this overlap, and also to increase the alignment between both documents, I suggest to make the following changes: =20 [Sanjay] There is introductory text in the draft that says: =20 "ANCP framework document [8] describes the ANCP use-cases in detail. Illustrative text for=20 the use-cases is included here to help the protocol implementer understand the greater=20 context of ANCP protocol interactions." =20 I have already pruned some of the overlapping text from sections 4 and beyond. However, what is included is minimally required to provide context. It is very much inline with other IETF protocol specs, and=20 I would like to keep it in. Please see inline for other comments. =20 section 4: rename title to "ANCP message flows"=20 =20 section 4.1 should clarify that following subsections describe the message flows for the different use cases identified in the ANCP Framework & Requirements document. It should also reference this document, indicating it contains the background information on the ANCP message flows. =20 [Sanjay] See response above. =20 section 4.2: rename title to "Access Topology Discovery" to be consistent with the naming in the framework=20 =20 [Sanjay] OK. =20 section 4.2.1 is coverd by section 3.1 in the framework =3D> it should be removed=20 =20 [Sanjay] See response upfront. =20 section 4.3: rename title to "Access Loop Configuration" to be consistent with the naming in the framework=20 =20 [Sanjay] OK. =20 section 4.3.1 is coverd by section 3.2 in the framework =3D> it should be removed=20 =20 [Sanjay] See response upfront. =20 I suggest to switch sections 4.4. and 4.5, to have the same sequence as in the framework document.=20 =20 [Sanjay] OK. =20 Then we get:=20 =20 section 4.4 "Remote Connectivity Test" (title changed to make it consistent with the framework)=20 =20 [Sanjay] OK. =20 The first two paragraphs before the message flows are also captured in section 3.3 in the framework =3D> they can be removed. =20 [Sanjay] Seen response upfront. =20 section 4.5 "Multicast" (title changed to make it consistent with the framework)=20 The current text is also captured in section 3.4 of the framework, so I think it should be removed.=20 =20 [Sanjay] See response upfront. =20 Also I believe the following sentence is losing relevance: "In ATM access networks, ANCP can be used by the NAS to setup P2MP cross-connects in the DSLAMs." As far as I know, most (if not all) of current multicast deployment scenarios in access are based on Ethernet/IP packet replication, not on ATM cell replication. Furthermore, networks are rapidly migrating for ATM to Ethernet. For these reasons I suggest removing this sentence. =20 [Sanjay] Agreed. This can go when the protocol machinery for multicast use-cases is added. =20 Regards,=20 Sven=20 =20 ------_=_NextPart_001_01C7CDF2.8AC70266 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ancp-protocol-01
Hi
  See=20 inline.
 
-Sanjay
 
----- Original Message -----
From: = OOGHE Sven=20 <Sven.Ooghe@alcatel-lucent.be>
To: ancp@ietf.org=20 <ancp@ietf.org>; = Sanjay=20 Wadhwa
Sent: Wed Jul 18 11:49:44 2007
Subject: Comments on=20 draft-ietf-ancp-protocol-01
 
Hi,
 
Upon reading the ANCP protocol draft, I = noticed=20 that section 4 contains
 some sections which overlap with the = ANCP=20 Framework and Requirements
 document. In order to avoid this = overlap,=20 and also to increase the
 alignment between both documents, I = suggest to=20 make the following
 changes:
 
[Sanjay] There is = introductory text=20 in the draft that says:
 
"ANCP framework = document [8]=20 describes the ANCP use-cases in detail. Illustrative text for =
 the=20 use-cases is included here to help the protocol implementer understand = the=20 greater
 context of ANCP protocol interactions."
 
I have already pruned = some of the=20 overlapping text from sections 4 and beyond. However, what is included=20 is
minimally required to provide context. It is very much inline with = other=20 IETF protocol specs, and
I would like to keep it in. Please see = inline for=20 other comments.
 

section 4: rename = title to "ANCP=20 message flows"
 
section 4.1 should = clarify that=20 following subsections describe the
 message flows for the = different use=20 cases identified in the ANCP
 Framework
 & = Requirements=20 document. It should also reference this document,
 indicating it = contains the background information on the ANCP=20 message
 flows.
 
[Sanjay] See response = above.
 
section 4.2: rename = title to "Access=20 Topology Discovery" to be
 consistent with the naming in the = framework=20
 
[Sanjay] OK.
 
section 4.2.1 is coverd = by section=20 3.1 in the framework =3D> it should
 be  removed =
 
[Sanjay] See response = upfront.
 
section 4.3: = rename title to=20 "Access Loop Configuration" to be
 consistent with the naming in = the=20 framework
 
[Sanjay] OK.
 
section 4.3.1 is coverd = by section=20 3.2 in the framework =3D> it should
 be removed
 
[Sanjay] See response = upfront.
 
I suggest to = switch sections=20 4.4. and 4.5, to have the same sequence as
 in the framework=20 document.
 
[Sanjay] OK.
 

Then we get: =
 
section 4.4 "Remote = Connectivity=20 Test" (title changed to make it
 consistent with the framework)=20
 
[Sanjay] OK.
 
The first two = paragraphs before the=20 message flows are also captured in
 section 3.3 in the framework = =3D>=20 they can be removed.
 
[Sanjay] Seen response = upfront.
 
section 4.5 = "Multicast" (title=20 changed to make it consistent with the
 framework)
The = current text=20 is also captured in section 3.4 of the framework, so I
 think it = should=20 be removed.
 
[Sanjay] See response = upfront.
 
Also I believe the = following sentence=20 is losing relevance: "In ATM access networks, ANCP can be used by the=20 NAS
 to setup P2MP cross-connects in the DSLAMs." As far as I = know,=20 most
 (if not all) of current multicast deployment scenarios in = access=20 are based
 on Ethernet/IP packet replication, not on ATM cell=20 replication.
 Furthermore, networks are rapidly migrating for = ATM to=20 Ethernet. For
 these  reasons I suggest removing this=20 sentence.
 
[Sanjay] Agreed. This can go when the = protocol=20 machinery for multicast use-cases is added.
 

Regards, =
Sven=20
 
------_=_NextPart_001_01C7CDF2.8AC70266-- --===============1859815652== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1859815652==-- From ancp-bounces@ietf.org Tue Jul 24 10:02:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKyL-0003f4-SF; Tue, 24 Jul 2007 10:02:45 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IDKyK-0003ex-Jl for ancp-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 10:02:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKyK-0003en-9c for ancp@ietf.org; Tue, 24 Jul 2007 10:02:44 -0400 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDKyH-0007qw-UG for ancp@ietf.org; Tue, 24 Jul 2007 10:02:44 -0400 Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.ad2.ad.alcatel.com [155.132.6.77]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6OE2U1q023630; Tue, 24 Jul 2007 16:02:34 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Jul 2007 16:02:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Tue, 24 Jul 2007 16:02:33 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380C1F717@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9E577E61D0108D4F8CD482029B613F5C0181BD09@PTPEVS108BA020.idc.cww.telecomitalia.it> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfJNXgYhtdJfelORs+hnxmwf6lKBQAE3CCgAP29ldAALTLhEA== References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380B16776@FRVELSMBS22.ad2.ad.alcatel.com> <9E577E61D0108D4F8CD482029B613F5C0181BD09@PTPEVS108BA020.idc.cww.telecomitalia.it> From: "OOGHE Sven" To: "Maglione Roberta" X-OriginalArrivalTime: 24 Jul 2007 14:02:34.0478 (UTC) FILETIME=[48C628E0:01C7CDFB] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: ead0864ab73cebfc51a21b92bc9d81ca Cc: Garofalo Angelo , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2080977263==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============2080977263== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CDFB.4863794B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CDFB.4863794B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roberta, =20 See feedback inline. =20 Regards, Sven ________________________________ From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: maandag 23 juli 2007 17:52 To: OOGHE Sven Cc: Curtis Sherbo; ancp@ietf.org; Garofalo Angelo; Francois Le Faucheur IMAP Subject: RE: [ANCP] Comments on draft-maglione Hi Sven, Michel and All, Thanks for your comments on the draft. I agree with you that there are scenarios where a "push model" could be used (this is the reason why we introduced white and black lists concept), while there are cases where a "pull model" better fits the needs. In my opinion ANCP should be flexible enough to cover both models. =20 =20 I think I understand your point of view regarding the desire to keep some policy information at a central location and refer to it only when needed. In this thread, people discussed several applications (nomadicity, mobility, over the top video, video conferencing, pre-paid services, Internet TV,...). They were categorized in the "Everything Else" group, which was put next to the Broadcast TV applications, for which it appears the Black-List/White-List mechanism is adequate. Did I capture this correctly? =20 As far as conditional access in my opinion scenarios that could be better developed using pull model are cases where Network Service Provider and Content Service Provider are two different entities and the AN is part of NSP while authorization function needs to be performed by CP. In these scenarios AN needs to be able to query AAA Server in CP network in order to get authorization to receive the multicast flow. Prepaid Service can be one example: in particular I think it would be more efficient having the information related to the remaining credit centralized on AAA Server and leaving the authorization function centralized instead of spread it around and overloading the AN with all different policies. =20 =20 In my view, the Access Node could hold White-List/Black-List policies for the well-known senders (e.g. the IPTV content servers of the CSP). Upon receiving an IGMP join, the Access Node could first check if the source IP address was a known one (using IGMPv3 SSM). If so, then it would look at the White-List/Black-List information and decide locally. If the source IP address would not be not known, it could be basically anything (over the top video, video conferencing, Internet TV,...). In this case the Access Node could do two things=20 - simply accept, and handle access control at some other layer (e.g. using encryption) - outsource to let a central system decide I think that there may be scaling issues with outsourcing everything else. Instead, I think it's better to rely on SSM as a first filtering technique. Black/White lists could be used for further filtering of the known sources. BTW, Pre-paid service can also done in a push model by using a time-based policy which times out. This can then be done with a single policy configuration message to the Access Node; when the policy times out, it is automatically removed on the Access Node without any signaling. =20 As far as admission control thinking about triple play services where synchronization between unicast and multicast admission control is required in order to be able to efficiently share the available bandwidth on the access line in my opinion a pull approach would be more flexible than a push model, because it would allow to perform synchronized admission control on the fly having a NAS, as centralized control point, talking with a Policy Server in order to take decision about the new flow.=20 =20 I have some concerns on the admission control case. On one hand it is stated by some people that the pull model can be made scalable, since it only needs to be performed for applications that require it. On the other hand, it is also stated that it is important to have synchronized unicast/multicast admission control. But that implies you need to use the pull model for all applications, especially Broadcast TV (because this is where unicast and multicast resources are most likely to be shared on the first mile). The use of flow groups to reduce signaling isn't really a solution in my view, because it creates new issues on its own related to lack of synchronization between the Access Node, NAS and Policy System. =20 I do agree that the network model must support with RAC in a combined unicast/multicast model. But I think we should be looking for solutions that achieve this with minimal signaling, while avoiding any synchronization issues between the Access Node, NAS and Policy System. =20 =20 Regards, Roberta =20 ------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia -------------------------------------------------=20 ________________________________ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Wednesday, July 18, 2007 4:59 PM To: Francois Le Faucheur IMAP Cc: Curtis Sherbo; ancp@ietf.org; Maglione Roberta; Garofalo Angelo Subject: RE: [ANCP] Comments on draft-maglione =20 Hi Francois, =20 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. =20 Sven, =20 Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. =20 But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). =20 I think I understand your reasoning.You're saying that for things like video conferencing, over the top video or video push features you would contact the central policy system because the access node doesn't have the information to decide locally. For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access Node. =20 In this case, I would think that the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address (for IPTV) or unknown IP source address (the "Everything else" mentioned by Curtis). That would imply to me that for everything which is IPTV, you could handle things locally, and for "Everything else", you would have to query the central policy server. This is because the Access Node doesn't know whether this user is allowed to watch e.g. the company's results broadcast vs any other Internet TV stream. So each time I would try to join a non-IPTV stream, the central policy server needs to check if the stream is a known one which is authorized, or some other Internet stream. Wouldn't this lead to scaling issues? =20 Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular application. =20 Cheers =20 Francois=20 =20 Regards, Sven -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you www.telecomitalia.it =20 -------------------------------------------------------------------- ------_=_NextPart_001_01C7CDFB.4863794B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Roberta,
 
See feedback inline.
 
Regards,
Sven

From: Maglione Roberta=20 [mailto:roberta.maglione@telecomitalia.it]
Sent: maandag 23 = juli 2007=20 17:52
To: OOGHE Sven
Cc: Curtis Sherbo; = ancp@ietf.org;=20 Garofalo Angelo; Francois Le Faucheur IMAP
Subject: RE: [ANCP] = Comments on draft-maglione

Hi Sven, Michel and = All,

   Thanks for your comments on the = draft. I=20 agree with you that there are scenarios where a "push model" could be = used (this=20 is the reason why we introduced white and black lists concept), while = there are=20 cases where a "pull model" better fits the needs. In my opinion ANCP = should be=20 flexible enough to cover both models.  

&nbs= p;

I think I understand your point of view = regarding the=20 desire to keep some policy information at a central location and refer = to it=20 only when needed. In this thread, people discussed several applications=20 (nomadicity, mobility, over the top video, video conferencing, pre-paid=20 services, Internet TV,...). They were categorized in the "Everything = Else"=20 group, which was put next to the Broadcast TV applications, for which it = appears=20 the Black-List/White-List mechanism is adequate. Did I capture = this=20 correctly?
 

As  far as conditional access in my = opinion=20 scenarios that could be better developed using pull model are cases = where=20 Network Service Provider and Content Service Provider are two different = entities=20 and the AN is part of NSP while authorization function needs to be = performed by=20 CP. In these scenarios AN needs to be able to query AAA Server in CP = network in=20 order to get authorization to receive the multicast flow.  Prepaid = Service=20 can be one example: in particular I think it would be more efficient = having the=20 information related to the remaining credit centralized on AAA Server = and=20 leaving the authorization function centralized instead of spread it = around and=20 overloading the AN with  all different policies.  

&nbs= p;

In my view, the Access Node could hold White-List/Black-List policies for the = well-known=20 senders (e.g. the IPTV content servers of the CSP). Upon receiving an = IGMP join,=20 the Access Node could first check if the source IP address was a known = one=20 (using IGMPv3 SSM). If so, then it would look at the = White-List/Black-List=20 information and decide locally. If the source IP address would not be = not known,=20 it could be basically anything (over the top video, video conferencing, = Internet=20 TV,...). In this case the Access Node could do two=20 things

- simply accept, and handle access control at = some=20 other layer (e.g. using = encryption)

- outsource to let a central system=20 decide

I = think that=20 there may be scaling issues with outsourcing everything else. Instead, I think it's = better to rely=20 on SSM as a first filtering technique. Black/White lists could be used = for=20 further filtering of the known=20 sources.

BTW,=20 Pre-paid service can also done in a push model by using a time-based = policy=20 which times out. This can then be done with a single policy = configuration=20 message to the Access Node; when the policy times out, it is = automatically=20 removed on the Access Node without any signaling.

 

As far as admission control thinking about = triple play=20 services where synchronization between unicast and multicast admission = control=20 is required in order to be able to efficiently share the available = bandwidth on=20 the access line in my opinion a pull approach would be more flexible = than a push=20 model, because it would allow to perform synchronized admission control = on the=20 fly having a NAS, as centralized control point, talking with a Policy = Server in=20 order to take decision about the new flow.

 

I = have some=20 concerns on the admission control case. On one hand=20 it is=20 stated by some people that the pull model can be made scalable, since it = only=20 needs to be performed for applications that require it. On the other = hand, it is=20 also stated that it is important to have synchronized unicast/multicast=20 admission control. But that implies you need to use the pull model for = all=20 applications, especially Broadcast TV (because this is where unicast and = multicast resources are most likely to be shared on the first=20 mile).

The use of=20 flow groups to reduce signaling isn't really a solution in my view, = because it=20 creates new issues on its own related to lack of synchronization between = the=20 Access Node, NAS and Policy=20 System.

 

I do agree that the network = model must=20 support with RAC in a combined unicast/multicast model. But I think we = should be=20 looking for solutions that achieve this with minimal signaling, while = avoiding=20 any synchronization issues between the Access Node, NAS and Policy=20 System.

 

 

 Regards,=

Roberta

 

-------------------------------------------------
Roberta=20 Maglione  - CCIE #18425
Telecom=20 Italia
-------------------------------------------------= =

From: OOGHE Sven=20 [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Wednesday, July 18, 2007 = 4:59=20 PM
To: = Francois Le Faucheur IMAP
Cc: Curtis Sherbo; ancp@ietf.org; = Maglione=20 Roberta; Garofalo = Angelo
Subject: RE: [ANCP] Comments on=20 draft-maglione

 

Hi=20 Francois,

 

3) Future Over the Top = Video=20 Partnerships - Service providers may choose to partner with internet = video=20 providers to provide QoS and multicast capabilities through a = partnership on a=20 per event basis.  Like the video conferencing scenario, this would = be=20 somewhat ad-hoc where the multicast group mappings may not be known in = advance,=20 or may be reused for different content in succession, requiring repeated = policy=20 refresh.  Again, a centralized approach would appear to be more = scalable=20 for this model.

I agree = that these=20 are channels which may not be known to the access provider in = advance.=20 There's however an easy way to solve this case: thanks to IGMPv3 = SSM, it is=20 possible to create two categories of = channels:

- those = with a=20 known IP source address: these would include e.g. the access/service = provider's own IPTV offering

- those = with an=20 unknown IP source address: these would include over the top video, = or video=20 conferencing

The = Access Node can=20 use the IP source address to filter IGMPv3's in different = replication=20 contexts (e.g. IPTV, Internet TV). Within this context, it could = then decide=20 to offer the content with the required QoS, and decide whether or = not to=20 accept or reject the = channel.

I don't quite see how that solves the core = issues=20 mentioned by Curtis:

What you describes allow to separate out the = provider's channels from everything else (the Internet OTT services, = Video=20 Conference). But we still have to deal with the dynamic=20 allocation/reallocation of channels to the "Everything else" = applications with=20 possibly large and fast changing membership. 

 

Correct, I = should=20 have made this more explicit in my previous = reply. When using IGMPv3=20 with SSM, the information to locally decide whether or not to accept = an IGMP=20 report may or may not be present in the replication context on the = Access=20 Node.

 

 For those, it seems more efficient to = use a=20 "more centralized" repository than attempting to permanently=20 update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all = affected=20 ANs/AN-ports. 

Am I missing=20 something?

 

Well, = perhaps we=20 should do the math and count the amount of=20 messages...

 

. In case = of=20 configuring the White-List/Black-List info, you'd configure the info = at=20 subscription time or when the IP session starts/ends. Typical example = is the=20 establishment of a PPP connection or DHCP lease. At this point, the = AAA system=20 will be contacted, which would be linked to the policy system = containing the=20 user's multicast viewing rights. Those would then be sent to the = Access Node,=20 and need to be released when the session ends. There's indeed some = updating=20 and re-updating going on. But typically, a session can last for one or = several=20 hours (or could even be always-on), and the policy information may = well be=20 stable for long periods of time within that=20 session.

 

. In case = of=20 contacting the central repository upon receiving an IGMP, you would = have such=20 an exchange at every channel zap. Whithin the session, it is likely = that a=20 subscriber will issue several IGMP messages to zap through channels. = The=20 number of message exchanges with the central respository will then be = higher=20 than in the first case.

To reduce = the message=20 load, one could make use of some form of channel grouping to send = a bulk=20 of policy information to the Access Node (cf. what is mentioned in the = draft),=20 but in my view this brings us very close to the first case again, and = makes me=20 wonder if it would not be simpler to send all required channel = information to=20 the Access Node at the start of the session. There may still be a = need to=20 do some in-session policy configuration changes on the Access Node, = but even=20 with this additional load, the resulting message load will never be = higher=20 than in the case of checking with the central policy=20 server.

 

Sven,

 

Your comparison above assumes a "regular" = scenario where=20 the conditional access rules are known ahead of time at session=20 setup.

For such regular scenarios, we agree that the=20 Black-List/White-List mechanisms works well. That is why those are = defined in=20 our proposal, and the expectation is that they would be used for the = regular=20 scenarios.

 

But again, the interesting question is for = other=20 scenarios, for example, as mentioned earlier, for those involving large = and fast=20 changing membership. Just for argument sake, let's imagine that an = application=20 is offering on-demand multicast-based services (eg video conferencing,=20 video-push) and want to rely on multicast to do this and want to rely on = the=20 network to enforce who is allowed to join which video conf. Then, it may = be that=20 there are many "channels" created/terminated all the time, with new = members=20 coming and going all the time. Some would allow multicast communications = within=20 small groups (eg one for me to send my latest video to my parents and = uncle, one=20 for you to send stuff to your brothers and sisters). Some would allow=20 multicast communication within very large groups (eg one = allowing all=20 shareholders of company X to watch from home the company results = announcement=20 live video). For _that_ application (and not for each and every = channel), just=20 for that application, it appears more efficient to allow the NAS to = query a more=20 central conditional access repository than try to try update=20 White-List/Black-List in every AN , and for all affected AN-ports as = their=20 membership changes all the time. In particular, for the groups = authorizing=20 communication within a very large community (but perhaps where only a = small=20 number will actually ever = join).

 

I think I = understand=20 your reasoning.You're saying that for things like video=20 conferencing, over the top video or video push features you would = contact=20 the central policy system because the access node doesn't have the = information=20 to decide locally. For IPTV services offered by the access/service=20 provider, some Black-List/White-List info is pushed to the Access=20 Node.

 

In this case, = I would=20 think that the Access Node could e.g. use IGMPv3 SSM to distinguish = between=20 these two categories of services, based on a (or a few) known IP source = address=20 (for IPTV) or unknown IP source address (the "Everything else" mentioned = by=20 Curtis). That would imply to me that for everything which is IPTV, you = could=20 handle things locally, and for "Everything else", you would have to = query the=20 central policy server. This is because the Access Node doesn't know = whether this=20 user is allowed to watch e.g. the company's results broadcast vs any = other=20 Internet TV stream. So each time I would try to join a non-IPTV = stream, the=20 central policy server needs to check if the stream is a known one which = is=20 authorized, or some other Internet stream. Wouldn't this lead to scaling = issues?

 

Perhaps, I should restate that the proposal is = not about=20 using Black-List/White-List for all channels/port OR querying NAS for = all=20 channels/ports. The proposal is about having the flexibility to use the = most=20 appropriate mechanism for each channel/port. So, in case of the example=20 on-demand application discussed above, one may use Black-List/White-List = for all=20 channels/port except the channel(s) allocated to that particular=20 application.

 

Cheers

 

Francois 

   
Regards,

Sven

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C7CDFB.4863794B-- --===============2080977263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============2080977263==-- From ancp-bounces@ietf.org Tue Jul 24 12:23:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNAC-0002yI-ED; Tue, 24 Jul 2007 12:23:08 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IDNAB-0002yA-3g for ancp-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:23:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNAA-0002xw-BW for ancp@ietf.org; Tue, 24 Jul 2007 12:23:06 -0400 Received: from maile.telecomitalia.it ([156.54.233.31]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDNA8-0007lC-RD for ancp@ietf.org; Tue, 24 Jul 2007 12:23:06 -0400 Received: from ptpxch008ba020.idc.cww.telecomitalia.it ([156.54.240.51]) by maile.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:23:03 +0200 Received: from PTPEVS108BA020.idc.cww.telecomitalia.it ([156.54.241.228]) by ptpxch008ba020.idc.cww.telecomitalia.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 18:23:03 +0200 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2929 Content-Class: urn:content-classes:message MIME-Version: 1.0 Importance: normal Priority: normal Subject: RE: [ANCP] Comments on draft-maglione Date: Tue, 24 Jul 2007 18:23:02 +0200 Message-ID: <9E577E61D0108D4F8CD482029B613F5C0181BD0B@PTPEVS108BA020.idc.cww.telecomitalia.it> In-Reply-To: <8144761F31F48D43AD53D09F5350E380C1F717@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione thread-index: AcfJNXgYhtdJfelORs+hnxmwf6lKBQAE3CCgAP29ldAALTLhEAAEK1yA References: <009801c7c7f5$bb199780$242413ac@ad.redback.com> <8144761F31F48D43AD53D09F5350E380B16110@FRVELSMBS22.ad2.ad.alcatel.com> <937B033C-5150-4407-A717-58F7561EA07F@cisco.com> <8144761F31F48D43AD53D09F5350E380B1649B@FRVELSMBS22.ad2.ad.alcatel.com> <8144761F31F48D43AD53D09F5350E380B16776@FRVELSMBS22.ad2.ad.alcatel.com> <9E577E61D0108D4F8CD482029B613F5C0181BD09@PTPEVS108BA020.idc.cww.telecomitalia.it> <8144761F31F48D43AD53D09F5350E380C1F717@FRVELSMBS22.ad2.ad.alcatel.com> From: "Maglione Roberta" To: "OOGHE Sven" X-OriginalArrivalTime: 24 Jul 2007 16:23:03.0307 (UTC) FILETIME=[E8BF65B0:01C7CE0E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 38eb275fbc6ed0a4459fd311d2115716 Cc: Garofalo Angelo , ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1411915201==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1411915201== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE0E.E86BF19D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE0E.E86BF19D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sven, thanks for your comments, please see answers inline. Regards, Roberta ------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia -------------------------------------------------=20 ________________________________ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Tuesday, July 24, 2007 4:03 PM To: Maglione Roberta Cc: Curtis Sherbo; ancp@ietf.org; Garofalo Angelo; Francois Le Faucheur IMAP Subject: RE: [ANCP] Comments on draft-maglione =20 Hi Roberta, =20 See feedback inline. =20 Regards, Sven =20 ________________________________ From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: maandag 23 juli 2007 17:52 To: OOGHE Sven Cc: Curtis Sherbo; ancp@ietf.org; Garofalo Angelo; Francois Le Faucheur IMAP Subject: RE: [ANCP] Comments on draft-maglione Hi Sven, Michel and All, Thanks for your comments on the draft. I agree with you that there are scenarios where a "push model" could be used (this is the reason why we introduced white and black lists concept), while there are cases where a "pull model" better fits the needs. In my opinion ANCP should be flexible enough to cover both models. =20 =20 I think I understand your point of view regarding the desire to keep some policy information at a central location and refer to it only when needed. In this thread, people discussed several applications (nomadicity, mobility, over the top video, video conferencing, pre-paid services, Internet TV,...). They were categorized in the "Everything Else" group, which was put next to the Broadcast TV applications, for which it appears the Black-List/White-List mechanism is adequate. Did I capture this correctly? =20 [RM] Yes you did; my point is that ANCP framework should be flexible enough to be applied to both kind of applications: allowing a pull approach for what you called "Everything Else" (nomadicity, mobility, videoconf, etc..) while keeping a push model for applications like Broadcast TV. =20 As far as conditional access in my opinion scenarios that could be better developed using pull model are cases where Network Service Provider and Content Service Provider are two different entities and the AN is part of NSP while authorization function needs to be performed by CP. In these scenarios AN needs to be able to query AAA Server in CP network in order to get authorization to receive the multicast flow. Prepaid Service can be one example: in particular I think it would be more efficient having the information related to the remaining credit centralized on AAA Server and leaving the authorization function centralized instead of spread it around and overloading the AN with all different policies. =20 =20 In my view, the Access Node could hold White-List/Black-List policies for the well-known senders (e.g. the IPTV content servers of the CSP). Upon receiving an IGMP join, the Access Node could first check if the source IP address was a known one (using IGMPv3 SSM). If so, then it would look at the White-List/Black-List information and decide locally. If the source IP address would not be not known, it could be basically anything (over the top video, video conferencing, Internet TV,...). In this case the Access Node could do two things=20 - simply accept, and handle access control at some other layer (e.g. using encryption) - outsource to let a central system decide I think that there may be scaling issues with outsourcing everything else. Instead, I think it's better to rely on SSM as a first filtering technique. Black/White lists could be used for further filtering of the known sources. [RM] It is not very clear to me this type of approach with SSM: I understand you are proposing to use SSM to differentiate between known and unknown sources, in order to decide when decision can be taken locally on AN on when additionally info is needed. But in my opinion this model does not solve the problem mentioned by other people on list regarding how to handle dynamic allocation/reallocation of channels for applications like video conference that are characterized by frequent fast membership changes and where the multicast group mappings may not be known in advance. =20 BTW, Pre-paid service can also done in a push model by using a time-based policy which times out. This can then be done with a single policy configuration message to the Access Node; when the policy times out, it is automatically removed on the Access Node without any signaling. =20 [RM] Yes you are right you can do either with pull or push model, but I still think pull approach would be more efficient for two reasons: 1. let's consider a case where a user buys 24 hours credit and he watches a movies that lasts in 2 hours. In this case user has still 22 hours credit, but this doesn't mean he has to watch movies continuously for other 22 hours. So the AN needs to be able to track when user is watching the movie and he is using the credit and when he does not watch it in order to keep the policy updated. It seems to me that keeping remaining credit info is AAA server job; I would prefer having the AN just signaling start and stop time and having the AAA updating the remaining credit info. 2. if you extend the scenario I described in 1. to a nomadic user: this case would requires to distribute an keep up to date a distributed policy... To me a centralized works better. =20 =20 As far as admission control thinking about triple play services where synchronization between unicast and multicast admission control is required in order to be able to efficiently share the available bandwidth on the access line in my opinion a pull approach would be more flexible than a push model, because it would allow to perform synchronized admission control on the fly having a NAS, as centralized control point, talking with a Policy Server in order to take decision about the new flow.=20 =20 I have some concerns on the admission control case. On one hand it is stated by some people that the pull model can be made scalable, since it only needs to be performed for applications that require it. On the other hand, it is also stated that it is important to have synchronized unicast/multicast admission control. But that implies you need to use the pull model for all applications, especially Broadcast TV (because this is where unicast and multicast resources are most likely to be shared on the first mile). The use of flow groups to reduce signaling isn't really a solution in my view, because it creates new issues on its own related to lack of synchronization between the Access Node, NAS and Policy System. =20 [RM] I do agree with you that there are some details about Flow Group concept we still need to work on in order to have a robust solution, but I think we do need centralized synchronized unicast and muticast CAC on the access line because, as also Sanjay said, there is no point to overload to link between NAS and AN with Multicast traffic that eventually will be dropped by AN as this multicast traffic will only be stealing bandwidth to other valuable unicast traffic. I understand there can be other ways to perform CAC but I still think provided synchronized CAC is part of the ANCP objectives as stated in ANCP framework draft.=20 =20 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations =20 =20 I do agree that the network model must support with RAC in a combined unicast/multicast model. But I think we should be looking for solutions that achieve this with minimal signaling, while avoiding any synchronization issues between the Access Node, NAS and Policy System. =20 =20 =20 Regards, Roberta =20 ------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia -------------------------------------------------=20 ________________________________ From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]=20 Sent: Wednesday, July 18, 2007 4:59 PM To: Francois Le Faucheur IMAP Cc: Curtis Sherbo; ancp@ietf.org; Maglione Roberta; Garofalo Angelo Subject: RE: [ANCP] Comments on draft-maglione =20 Hi Francois, =20 3) Future Over the Top Video Partnerships - Service providers may choose to partner with internet video providers to provide QoS and multicast capabilities through a partnership on a per event basis. Like the video conferencing scenario, this would be somewhat ad-hoc where the multicast group mappings may not be known in advance, or may be reused for different content in succession, requiring repeated policy refresh. Again, a centralized approach would appear to be more scalable for this model. I agree that these are channels which may not be known to the access provider in advance. There's however an easy way to solve this case: thanks to IGMPv3 SSM, it is possible to create two categories of channels: - those with a known IP source address: these would include e.g. the access/service provider's own IPTV offering - those with an unknown IP source address: these would include over the top video, or video conferencing The Access Node can use the IP source address to filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). Within this context, it could then decide to offer the content with the required QoS, and decide whether or not to accept or reject the channel. I don't quite see how that solves the core issues mentioned by Curtis: What you describes allow to separate out the provider's channels from everything else (the Internet OTT services, Video Conference). But we still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast changing membership.=20 =20 Correct, I should have made this more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report may or may not be present in the replication context on the Access Node. =20 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all affected ANs/AN-ports.=20 Am I missing something? =20 Well, perhaps we should do the math and count the amount of messages... =20 . In case of configuring the White-List/Black-List info, you'd configure the info at subscription time or when the IP session starts/ends. Typical example is the establishment of a PPP connection or DHCP lease. At this point, the AAA system will be contacted, which would be linked to the policy system containing the user's multicast viewing rights. Those would then be sent to the Access Node, and need to be released when the session ends. There's indeed some updating and re-updating going on. But typically, a session can last for one or several hours (or could even be always-on), and the policy information may well be stable for long periods of time within that session. =20 . In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at every channel zap. Whithin the session, it is likely that a subscriber will issue several IGMP messages to zap through channels. The number of message exchanges with the central respository will then be higher than in the first case. To reduce the message load, one could make use of some form of channel grouping to send a bulk of policy information to the Access Node (cf. what is mentioned in the draft), but in my view this brings us very close to the first case again, and makes me wonder if it would not be simpler to send all required channel information to the Access Node at the start of the session. There may still be a need to do some in-session policy configuration changes on the Access Node, but even with this additional load, the resulting message load will never be higher than in the case of checking with the central policy server. =20 Sven, =20 Your comparison above assumes a "regular" scenario where the conditional access rules are known ahead of time at session setup. For such regular scenarios, we agree that the Black-List/White-List mechanisms works well. That is why those are defined in our proposal, and the expectation is that they would be used for the regular scenarios. =20 But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, video-push) and want to rely on multicast to do this and want to rely on the network to enforce who is allowed to join which video conf. Then, it may be that there are many "channels" created/terminated all the time, with new members coming and going all the time. Some would allow multicast communications within small groups (eg one for me to send my latest video to my parents and uncle, one for you to send stuff to your brothers and sisters). Some would allow multicast communication within very large groups (eg one allowing all shareholders of company X to watch from home the company results announcement live video). For _that_ application (and not for each and every channel), just for that application, it appears more efficient to allow the NAS to query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as their membership changes all the time. In particular, for the groups authorizing communication within a very large community (but perhaps where only a small number will actually ever join). =20 I think I understand your reasoning.You're saying that for things like video conferencing, over the top video or video push features you would contact the central policy system because the access node doesn't have the information to decide locally. For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access Node. =20 In this case, I would think that the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address (for IPTV) or unknown IP source address (the "Everything else" mentioned by Curtis). That would imply to me that for everything which is IPTV, you could handle things locally, and for "Everything else", you would have to query the central policy server. This is because the Access Node doesn't know whether this user is allowed to watch e.g. the company's results broadcast vs any other Internet TV stream. So each time I would try to join a non-IPTV stream, the central policy server needs to check if the stream is a known one which is authorized, or some other Internet stream. Wouldn't this lead to scaling issues? =20 Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular application. =20 Cheers =20 Francois=20 =20 Regards, Sven -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster@telecomitalia.it . Thank you www.telecomitalia.it =20 -------------------------------------------------------------------- -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons = above and may contain confidential information. If you have received the = message in error, be informed that any use of the content hereof is = prohibited. Please return it immediately to the sender and delete the = message. Should you have any questions, please contact us by replying to = webmaster@telecomitalia.it. Thank you www.telecomitalia.it -------------------------------------------------------------------- =20 ------_=_NextPart_001_01C7CE0E.E86BF19D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Sven,

   = thanks for your comments, please see answers inline.

Regards,

Roberta

-------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia
-------------------------------------------------

From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Tuesday, July 24, = 2007 4:03 PM
To: Maglione Roberta
Cc: Curtis Sherbo; = ancp@ietf.org; Garofalo Angelo; Francois Le Faucheur IMAP
Subject: RE: [ANCP] = Comments on draft-maglione

 

Hi = Roberta,

 

See feedback = inline.

 

Regards,

Sven

 

From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]
Sent: maandag 23 juli = 2007 17:52
To: OOGHE Sven
Cc: Curtis Sherbo; = ancp@ietf.org; Garofalo Angelo; Francois Le Faucheur IMAP
Subject: RE: [ANCP] = Comments on draft-maglione

Hi Sven, Michel and = All,

   Thanks for your comments on the = draft. I agree with you that there are scenarios where a "push model" = could be used (this is the reason why we introduced white and black lists = concept), while there are cases where a "pull model" better fits the = needs. In my opinion ANCP should be flexible enough to cover both = models.  

 

I think I = understand your point of view regarding the desire to keep some policy information at a = central location and refer to it only when needed. In this thread, people = discussed several applications (nomadicity, mobility, over the top video, video conferencing, pre-paid services, Internet TV,...). They were categorized = in the "Everything Else" group, which was put next to the Broadcast = TV applications, for which it appears the Black-List/White-List mechanism = is adequate. Did I capture this correctly?

 

=

[RM] Yes you = did; my point is that ANCP framework should be flexible enough to be applied to = both kind of applications: allowing a pull approach for what you called = “Everything Else” (nomadicity, mobility, videoconf, etc..)  while keeping = a push model for applications like Broadcast TV.

 =

As  far as conditional access in my = opinion scenarios that could be better developed using pull model are cases = where Network Service Provider and Content Service Provider are two different entities and the AN is part of NSP while authorization function needs to = be performed by CP. In these scenarios AN needs to be able to query AAA = Server in CP network in order to get authorization to receive the multicast = flow.  Prepaid Service can be one example: in particular I think it would be = more efficient having the information related to the remaining credit = centralized on AAA Server and leaving the authorization function centralized instead of = spread it around and overloading the AN with  all different = policies.  

 

In my view, the = Access Node could hold White-List/Black-List policies for the well-known = senders (e.g. the IPTV content servers of the CSP). Upon receiving an IGMP join, the = Access Node could first check if the source IP address was a known one (using = IGMPv3 SSM). If so, then it would look at the White-List/Black-List information = and decide locally. If the source IP address would not be not known, it = could be basically anything (over the top video, video conferencing, Internet = TV,...). In this case the Access Node could do two things

- simply accept, and handle access control = at some other layer (e.g. using encryption)

- outsource to let a central system = decide

I think that there may be scaling issues = with outsourcing everything else. Instead, I think it's better to rely on SSM = as a first filtering technique. Black/White lists could be used for further filtering of the known sources.

[RM] It is not very clear to me this type = of approach with SSM: I understand you are proposing to use SSM to = differentiate between known and unknown sources, in order to decide when decision can = be taken locally on AN on when additionally info is needed. But in my = opinion this model does not solve the problem mentioned by other people on list = regarding how to handle dynamic allocation/reallocation of channels for = applications like video conference that are characterized by frequent fast membership = changes and where the multicast group mappings may not be known in advance. =       

BTW, Pre-paid = service can also done in a push model by using a time-based policy which times out. = This can then be done with a single policy configuration message to the = Access Node; when the policy times out, it is automatically removed on the Access = Node without any signaling.

 

=

[RM] Yes you are = right you can do either with pull or push model, but I still think pull = approach would be more efficient for two reasons:

  1. let’s consider a case where a user buys 24 hours = credit and he watches a movies that lasts in 2 hours. In this case user has = still 22 hours credit, but this doesn’t mean he has to watch movies = continuously for other 22 hours. So the AN needs to be able to track when user = is watching the movie and he is using the credit and when he does not watch it = in order to keep the policy updated. It seems to me that keeping = remaining credit info is AAA server job; I would prefer having the AN just signaling = start and stop time and having the AAA updating the remaining credit = info.
  2. if you extend the scenario I described in 1. to a nomadic = user: this case would requires to distribute an keep up to date a distributed = policy… To me a centralized works better.

 

 =

As far as admission control thinking about = triple play services where synchronization between unicast and multicast admission = control is required in order to be able to efficiently share the available = bandwidth on the access line in my opinion a pull approach would be more flexible = than a push model, because it would allow to perform synchronized admission = control on the fly having a NAS, as centralized control point, talking with a = Policy Server in order to take decision about the new flow. =

 

I have some = concerns on the admission control case. On one hand it is stated by some people that = the pull model can be made scalable, since it only needs to be performed for applications that require it. On the other hand, it is also stated that = it is important to have synchronized unicast/multicast admission control. But = that implies you need to use the pull model for all applications, especially Broadcast TV (because this is where unicast and multicast resources are = most likely to be shared on the first mile).

The use of flow = groups to reduce signaling isn't really a solution in my view, because it creates = new issues on its own related to lack of synchronization between the Access = Node, NAS and Policy System.

 

=

[RM] I do agree = with you that there are some details about Flow Group concept we still need to = work on in order to have a robust solution, but I think we do need centralized = synchronized unicast and muticast CAC on the access line because, as also Sanjay = said, there is no point to overload to link between NAS and AN with Multicast = traffic that eventually will be dropped by AN as this multicast traffic will only be = stealing bandwidth to other valuable unicast = traffic.

I understand = there can be other ways to perform CAC but I still think provided synchronized CAC is = part of the ANCP objectives as stated in ANCP framework draft. =

 = 

The purpose of =
this document is to define a framework for an =
Access
   Node Control Mechanism between a =
Network Access Server (NAS) and =
an
   Access Node (e.g. a Digital =
Subscriber Line Access =
Multiplexer
   (DSLAM)) in a multi-service =
reference architecture in order =
to
   perform QoS-related, =
service-related and =
Subscriber-related
   operations

      =

 

I do agree that = the network model must support with RAC in a combined unicast/multicast = model. But I think we should be looking for solutions that achieve this with = minimal signaling, while avoiding any synchronization issues between the Access = Node, NAS and Policy System.

 

 

 

 Regards,

Roberta

 =

-------------------------------------------------
Roberta Maglione  - CCIE #18425
Telecom Italia
-------------------------------------------------

From: OOGHE Sven [mailto:Sven.Ooghe@alcatel-lucent.be]
Sent: Wednesday, July 18, = 2007 4:59 PM
To: Francois Le Faucheur IMAP
Cc: Curtis Sherbo; = ancp@ietf.org; Maglione Roberta; Garofalo = Angelo
Subject: RE: [ANCP] = Comments on draft-maglione

 

Hi = Francois,

 

3) Future Over the Top Video Partnerships - = Service providers may choose to partner with internet video providers to provide = QoS and multicast capabilities through a partnership on a per event = basis.  Like the video conferencing scenario, this would be somewhat ad-hoc = where the multicast group mappings may not be known in advance, or may be reused = for different content in succession, requiring repeated policy = refresh.  Again, a centralized approach would appear to be more scalable for this = model.

I agree that these are channels which may not be known = to the access provider in advance. There's however an easy way to solve this = case: thanks to IGMPv3 SSM, it is possible to create two categories of = channels:

- those with a known IP source address: these would = include e.g. the access/service provider's own IPTV = offering

- those with an unknown IP source address: these would include over the top video, or video = conferencing

The Access Node can use the IP source address to = filter IGMPv3's in different replication contexts (e.g. IPTV, Internet TV). = Within this context, it could then decide to offer the content with the = required QoS, and decide whether or not to accept or reject the = channel.

I don't quite see how that solves the core issues mentioned by = Curtis:

What you describes allow to separate out the provider's channels = from everything else (the Internet OTT services, Video Conference). But we = still have to deal with the dynamic allocation/reallocation of channels to the "Everything else" applications with possibly large and fast = changing membership. 

 

Correct, I should have made this = more explicit in my previous reply. When using IGMPv3 with SSM, the information to locally decide whether or not to accept an IGMP report = may or may not be present in the replication context on the Access = Node.

 

 For those, it seems more efficient to use a "more centralized" repository than attempting to permanently update/re-update/re-re-update/etc.. White-Lists/Black-Lists on all = affected ANs/AN-ports. 

Am I missing something?

 

Well, perhaps we should do the math = and count the amount of messages...

 

. In case of configuring the White-List/Black-List info, you'd configure the info at subscription = time or when the IP session starts/ends. Typical example is the establishment of = a PPP connection or DHCP lease. At this point, the AAA system will be = contacted, which would be linked to the policy system containing the user's = multicast viewing rights. Those would then be sent to the Access Node, and need to = be released when the session ends. There's indeed some updating and = re-updating going on. But typically, a session can last for one or several hours (or = could even be always-on), and the policy information may well be stable for = long periods of time within that session.

 

. In case of contacting the central repository upon receiving an IGMP, you would have such an exchange at = every channel zap. Whithin the session, it is likely that a subscriber will = issue several IGMP messages to zap through channels. The number of message = exchanges with the central respository will then be higher than in the first = case.

To reduce the message = load, one could make use of some form of channel grouping to send a bulk of policy = information to the Access Node (cf. what is mentioned in the draft), but in my view = this brings us very close to the first case again, and makes me wonder if it = would not be simpler to send all required channel information to the Access = Node at the start of the session. There may still be a need to do some = in-session policy configuration changes on the Access Node, but even with this = additional load, the resulting message load will never be higher than in the case = of checking with the central policy server.

 

Sven,

 

Your comparison above assumes a "regular" scenario = where the conditional access rules are known ahead of time at session = setup.

For such regular scenarios, we agree that the = Black-List/White-List mechanisms works well. That is why those are defined in our proposal, = and the expectation is that they would be used for the regular = scenarios.

 

But again, the interesting question is for other scenarios, for example, as mentioned earlier, for those involving large and fast = changing membership. Just for argument sake, let's imagine that an application is offering on-demand multicast-based services (eg video conferencing, = video-push) and want to rely on multicast to do this and want to rely on the network = to enforce who is allowed to join which video conf. Then, it may be that = there are many "channels" created/terminated all the time, with new = members coming and going all the time. Some would allow multicast communications = within small groups (eg one for me to send my latest video to my parents and = uncle, one for you to send stuff to your brothers and sisters). Some would = allow multicast communication within very large groups (eg one = allowing all shareholders of company X to watch from home the company results = announcement live video). For _that_ application (and not for each and every = channel), just for that application, it appears more efficient to allow the NAS to = query a more central conditional access repository than try to try update White-List/Black-List in every AN , and for all affected AN-ports as = their membership changes all the time. In particular, for the groups = authorizing communication within a very large community (but perhaps where only a = small number will actually ever join).

 

I think I understand your = reasoning.You're saying that for things like video conferencing, over = the top video or video push features you would contact the central policy = system because the access node doesn't have the information to decide locally. = For IPTV services offered by the access/service provider, some Black-List/White-List info is pushed to the Access = Node.

 

In this case, I would think that = the Access Node could e.g. use IGMPv3 SSM to distinguish between these two categories of services, based on a (or a few) known IP source address = (for IPTV) or unknown IP source address (the "Everything else" = mentioned by Curtis). That would imply to me that for everything which is IPTV, = you could handle things locally, and for "Everything else", you would = have to query the central policy server. This is because the Access Node doesn't = know whether this user is allowed to watch e.g. the company's results = broadcast vs any other Internet TV stream. So each time I would try to join a = non-IPTV stream, the central policy server needs to check if the stream is a = known one which is authorized, or some other Internet stream. Wouldn't this lead = to scaling issues?

 

Perhaps, I should restate that the proposal is not about using Black-List/White-List for all channels/port OR querying NAS for all channels/ports. The proposal is about having the flexibility to use the = most appropriate mechanism for each channel/port. So, in case of the example on-demand application discussed above, one may use Black-List/White-List for all channels/port except the channel(s) allocated to that particular = application.

 

Cheers

 

Francois 

   
= Regards,

Sven

-------------------------------------------------------------------= -
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please contact us by
replying to webmaster@telecomitalia.it.
        Thank you
            &= nbsp;           &n= bsp;           &nb= sp;   www.telecomitalia.it
-------------------------------------------------------------------= -

--------------------------------------------------------------------=
CONFIDENTIALITY=20 NOTICE
This message and its attachments are addressed solely to the=20 persons
above and may contain confidential information. If you have=20 received
the message in error, be informed that any use of the = content=20 hereof
is prohibited. Please return it immediately to the sender and=20 delete
the message. Should you have any questions, please contact us=20 by
replying to webmaster@telecomitalia.it.
        = Thank=20 you
           =             &= nbsp;           &n= bsp;   =20 www.telecomitalia.it
--------------------------------------------------------------------=
------_=_NextPart_001_01C7CE0E.E86BF19D-- --===============1411915201== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1411915201==-- From ancp-bounces@ietf.org Tue Jul 24 14:22:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDP1c-0007OQ-JO; Tue, 24 Jul 2007 14:22:24 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IDP1b-0007Cw-5D for ancp-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 14:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDP1a-00079f-Ae for ancp@ietf.org; Tue, 24 Jul 2007 14:22:22 -0400 Received: from eci-iron.ecitele.com ([147.234.242.112] helo=iron.ecitele.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDP1Y-0007iE-6P for ancp@ietf.org; Tue, 24 Jul 2007 14:22:22 -0400 Received: from ilptexfe.ecitele.com (HELO ILPTEXFE02.ecitele.com) ([147.234.245.181]) by eci-iron-out.ecitele.com with ESMTP; 24 Jul 2007 21:31:28 +0300 Received: from ILPTMAIL01.ecitele.com ([147.234.245.210]) by ILPTEXFE02.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 24 Jul 2007 21:22:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Comments on draft-maglione Date: Tue, 24 Jul 2007 21:22:18 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-maglione Thread-Index: AcfNPesp0+998lMLS6y94SJ58ITZqQA3eI51 References: <8C253CB7-CF45-431D-94B6-4AC1A1653524@cisco.com> From: "Michel Platnic" To: "Francois Le Faucheur IMAP" X-OriginalArrivalTime: 24 Jul 2007 18:22:18.0349 (UTC) FILETIME=[917C29D0:01C7CE1F] X-Spam-Score: 1.8 (+) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Cc: angelo.garofalo@telecomitalia.it, ancp@ietf.org X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0943176412==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0943176412== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CE1F.91676A0E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CE1F.91676A0E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Francois, Please see my comments inline, Regards, Michel. =20 ________________________________ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Mon 7/23/2007 6:23 PM To: Michel Platnic Cc: Francois Le Faucheur IMAP; OOGHE Sven; ancp@ietf.org; = angelo.garofalo@telecomitalia.it Subject: Re: [ANCP] Comments on draft-maglione Hi Michel,=20 =20 Using access control capabilities within the access network = provides the two main following benefits: - refrain from sending any content to a customer that was not paid for = (mostly relevant when Encryption is not used) - provides a filter against end-user applications/hackers that may send = IGMP requests with invalid IP address =20 A solution where all the IP addresses that are not part of either the = Black-list or the White-List are sent to a central policy server for = authorization gives me some concerns regarding the robustness of the = whole system. Same concern regarding the treatment of unknown IP source = addresses ('Everything else'). Agreed. We had these concerns in mind also. This is why the Black-Lists = and White-Lists include the ability to define arbitrarily large = ranges/masks. In particular, as an example, one can easily define a = Black-List which contains a single "catch-all" entry that matches any = Multicast address & Source. Then you can define a White-List with the = explicit channels you want to allow. This effectively implements a = policy whereby everything is blocked by AN, except the channels that = have been explicitly allowed in the White-List. In other words, the Black-List can be used for explicit listing of = channels, or it can easily be used as a "catch-all" (for all, or for = arbitrarily large ranges of channels). This should address your concern of making sure that the "default" = behavior for any non-explicitly defined channel is not to query = NAS/Central_server. See in draft-maglione: " The White List and Black List can contain entries allowing: o an exact match for a (*,G) ASM group (e.g. )=20 o an exact match for a (S,G) SSM channel (e.g. = =20 o a mask-based range match for a (*,G) ASM group (e.g.=20 )=20 o a mask-based range match for a (S,G) SSM channel (e.g.=20 =20 " Let me try to rephrase your proposal; there would be a default = state wherein any channel being neither part of White-list nor = Black-list would be discarded.=20 If its the case I agree with you that this solution solves the security = issue. =20 But what about when AN is not in this default state? If "Accept everything else" is used then again same problem of security = is encountered, and any hacker or application can overload the policy = server with requests.=20 To my understanding, the model proposed, where the NAS is getting the = customer request for authorization, requires this mode of operation. So we still have the same problem. Did I miss anything? =20 =20 _________________________________________________________________________= _____ I understand that some applications may require sophisticated policy = decision making and that, as a matter of fact, some AN/central policy = server synchronization mechanism should to be proposed, =09 but the solution must be Robust and Scalable. For now I am not convinced that solution proposed is either Robust or = Scalable. Let us know if you have specific robustness/scalability concerns (beyond = the one discussed above)? Then we could work together on addressing those.=20 =20 Well, there is still this scalable issue when duplicating the = messages that need to be treated in real-time by the NAS. Sven already = made some counting regarding this topic. I believe this point could lead = to scalability issues. If we had the above described potential disaster, = then we end-up getting serious Robustness issues. =20 Thanks Francois =20 Regards, Michel. ------_=_NextPart_001_01C7CE1F.91676A0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=
=0A=
Hi = Francois,
=0A=
Please see my = comments inline,
=0A=
Regards,
=0A=
Michel.
=0A=
 
=0A=

=0A=
=0A= From: Francois Le Faucheur IMAP = [mailto:flefauch@cisco.com]
Sent: Mon 7/23/2007 6:23 = PM
To: Michel Platnic
Cc: Francois Le Faucheur IMAP; = OOGHE Sven; ancp@ietf.org; = angelo.garofalo@telecomitalia.it
Subject: Re: [ANCP] Comments = on draft-maglione

=0A=
Hi Michel, =0A=

=0A=
=0A=
 
=0A=
<Michel> Using access control capabilities within the = access network provides the two = main following benefits:
=0A=
- refrain from sending any content to a = customer that was not paid for (mostly relevant when Encryption is = not used)
=0A=
- provides a filter against end-user = applications/hackers that may send IGMP requests with invalid IP = address
=0A=
 
=0A=
A solution where all the IP addresses that = are not part of either the Black-list or the White-List = are sent to a central policy server for authorization gives me some = concerns regarding the robustness of the whole system. Same concern = regarding the treatment of unknown IP source addresses ('Everything = else').
=0A=

=0A=
Agreed. We had these concerns in mind also. This is why the = Black-Lists and White-Lists include the ability to define arbitrarily = large ranges/masks. In particular, as an example, one can easily define = a Black-List which contains a single "catch-all" entry that matches any = Multicast address & Source. Then you can define a White-List with = the explicit channels you want to allow. This effectively implements a = policy whereby everything is blocked by AN, except the channels = that have been explicitly allowed in the White-List.
=0A=
In other words, the Black-List can be used for explicit listing of = channels, or it can easily be used as a "catch-all" (for all, or for = arbitrarily large ranges of channels).
=0A=

=0A=
This should address your concern of making sure that the "default" = behavior for any non-explicitly defined channel is not to query = NAS/Central_server.
=0A=

=0A=
See in draft-maglione:
=0A=
"
=0A=
The White List and Black List can contain entries allowing:
=0A=
   o  an exact match for a (*,G) ASM group (e.g. = <G=3Dg.h.i.l>)
=0A=
   o  an exact match for a (S,G) SSM channel (e.g. = <S=3Ds.t.u.v,G=3Dg.h.i.l>
=0A=
   o  a mask-based range match for a (*,G) ASM group = (e.g.
=0A=
      <G=3Dg.h.i.l/Mask>)
=0A=
   o  a mask-based range match for a (S,G) SSM = channel (e.g.
=0A=
      <S=3Ds.t.u.v/Mask,G=3Dg.h.i.l/Mask> =
=0A=
"
=0A=
=0A=
 <Michel> Let me try to rephrase your proposal; = there would be a default state wherein any channel being neither part of = White-list nor Black-list would be discarded.
=0A=
If its the = case I agree with you that this solution solves the security = issue.
=0A=
 
=0A=
But what = about when AN is not in this default state?
=0A=
If "Accept = everything else" is = used then again same problem of security is encountered, and = any hacker or application can overload the policy server with = requests.
=0A=
To my = understanding, the model proposed, where the NAS is getting the customer = request for authorization, requires this mode of operation.
=0A=
So we still = have the same problem.
=0A=
Did I miss = anything?
=0A=
 
=0A=
 
=0A=
____________________________________________________________________= __________
=0A=
=0A=
I understand that some applications may = require sophisticated policy decision making and that, as a = matter of fact, some AN/central policy server = synchronization mechanism should to be = proposed,
=0A=
=0A=
but the solution must be Robust and = Scalable.
=0A=
For now I am not convinced that solution = proposed is either Robust or Scalable.
=0A=

=0A=
Let us know if you have specific robustness/scalability concerns = (beyond the one discussed above)?
=0A=
Then we could work together on addressing those. 
=0A=
 
=0A=
 <Michel> = Well, there is still this scalable issue when duplicating the messages = that need to be treated in real-time by the NAS. Sven already made some = counting regarding this topic. I believe this point could lead to = scalability issues. If we had the above described potential disaster, = then we end-up getting serious Robustness issues.
=0A=

 
=0A=
Thanks
=0A=

=0A=
Francois
=0A=

=0A=
=0A=
 
=0A=
Regards,
=0A=
Michel.
=
------_=_NextPart_001_01C7CE1F.91676A0E-- --===============0943176412== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============0943176412==-- From ancp-bounces@ietf.org Thu Jul 26 08:53:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2qI-0000Jy-E3; Thu, 26 Jul 2007 08:53:22 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IE2qG-0000Jm-Qh for ancp-confirm+ok@megatron.ietf.org; Thu, 26 Jul 2007 08:53:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE2qG-0000JX-Gc for ancp@ietf.org; Thu, 26 Jul 2007 08:53:20 -0400 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IE2qE-0004Xp-QE for ancp@ietf.org; Thu, 26 Jul 2007 08:53:20 -0400 Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.ad2.ad.alcatel.com [155.132.6.74]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id l6QCrDb5011825; Thu, 26 Jul 2007 14:53:13 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 26 Jul 2007 14:53:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 26 Jul 2007 14:53:16 +0200 Message-ID: <8144761F31F48D43AD53D09F5350E380C2027A@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2803B76298@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-ancp-protocol-01 Thread-Index: AcfJU0MVpf6Xh8dzROO8wqtWZWz3rgEnqKFgAGRErRA= References: <8144761F31F48D43AD53D09F5350E380B167C8@FRVELSMBS22.ad2.ad.alcatel.com> <9BD5D7887235424FA97DFC223CAE3C2803B76298@proton.jnpr.net> From: "OOGHE Sven" To: "Sanjay Wadhwa" , X-OriginalArrivalTime: 26 Jul 2007 12:53:18.0205 (UTC) FILETIME=[F044BAD0:01C7CF83] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc Cc: Subject: [ANCP] RE: Comments on draft-ietf-ancp-protocol-01 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1146771864==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1146771864== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7CF83.EFC5913F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7CF83.EFC5913F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sanjay, =20 I noticed the introductory text; that's fine with me. I haven't seen other people react on my proposal, so I guess people are ok with leaving the text the way it is. In that case I'm fine to keep the text. =20 Regards, Sven ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: dinsdag 24 juli 2007 15:00 To: OOGHE Sven; ancp@ietf.org Subject: RE: Comments on draft-ietf-ancp-protocol-01 Hi=20 See inline. =20 -Sanjay =20 ----- Original Message ----- From: OOGHE Sven > To: ancp@ietf.org >; Sanjay Wadhwa Sent: Wed Jul 18 11:49:44 2007 Subject: Comments on draft-ietf-ancp-protocol-01 =20 Hi,=20 =20 Upon reading the ANCP protocol draft, I noticed that section 4 contains some sections which overlap with the ANCP Framework and Requirements document. In order to avoid this overlap, and also to increase the alignment between both documents, I suggest to make the following changes: =20 [Sanjay] There is introductory text in the draft that says: =20 "ANCP framework document [8] describes the ANCP use-cases in detail. Illustrative text for=20 the use-cases is included here to help the protocol implementer understand the greater=20 context of ANCP protocol interactions." =20 I have already pruned some of the overlapping text from sections 4 and beyond. However, what is included is minimally required to provide context. It is very much inline with other IETF protocol specs, and=20 I would like to keep it in. Please see inline for other comments. =20 section 4: rename title to "ANCP message flows"=20 =20 section 4.1 should clarify that following subsections describe the message flows for the different use cases identified in the ANCP Framework & Requirements document. It should also reference this document, indicating it contains the background information on the ANCP message flows. =20 [Sanjay] See response above. =20 section 4.2: rename title to "Access Topology Discovery" to be consistent with the naming in the framework=20 =20 [Sanjay] OK. =20 section 4.2.1 is coverd by section 3.1 in the framework =3D> it should be removed=20 =20 [Sanjay] See response upfront. =20 section 4.3: rename title to "Access Loop Configuration" to be consistent with the naming in the framework=20 =20 [Sanjay] OK. =20 section 4.3.1 is coverd by section 3.2 in the framework =3D> it should be removed=20 =20 [Sanjay] See response upfront. =20 I suggest to switch sections 4.4. and 4.5, to have the same sequence as in the framework document.=20 =20 [Sanjay] OK. =20 Then we get:=20 =20 section 4.4 "Remote Connectivity Test" (title changed to make it consistent with the framework)=20 =20 [Sanjay] OK. =20 The first two paragraphs before the message flows are also captured in section 3.3 in the framework =3D> they can be removed. =20 [Sanjay] Seen response upfront. =20 section 4.5 "Multicast" (title changed to make it consistent with the framework)=20 The current text is also captured in section 3.4 of the framework, so I think it should be removed.=20 =20 [Sanjay] See response upfront. =20 Also I believe the following sentence is losing relevance: "In ATM access networks, ANCP can be used by the NAS to setup P2MP cross-connects in the DSLAMs." As far as I know, most (if not all) of current multicast deployment scenarios in access are based on Ethernet/IP packet replication, not on ATM cell replication. Furthermore, networks are rapidly migrating for ATM to Ethernet. For these reasons I suggest removing this sentence. =20 [Sanjay] Agreed. This can go when the protocol machinery for multicast use-cases is added. =20 Regards,=20 Sven=20 =20 ------_=_NextPart_001_01C7CF83.EFC5913F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-ancp-protocol-01
Hi Sanjay,
 
I noticed the introductory text; that's fine = with me.=20 I haven't seen other people react on my proposal, so I guess = people are=20 ok with leaving the text the way it is. In that case I'm fine to keep = the=20 text.
 
Regards,
Sven
From: Sanjay Wadhwa = [mailto:swadhwa@juniper.net]=20
Sent: dinsdag 24 juli 2007 15:00
To: OOGHE Sven;=20 ancp@ietf.org
Subject: RE: Comments on=20 draft-ietf-ancp-protocol-01

Hi
  See=20 inline.
 
-Sanjay
 
----- Original Message -----
From: = OOGHE Sven=20 <Sven.Ooghe@alcatel-lucent.be>
To: ancp@ietf.org=20 <ancp@ietf.org>; = Sanjay=20 Wadhwa
Sent: Wed Jul 18 11:49:44 2007
Subject: Comments on=20 draft-ietf-ancp-protocol-01
 
Hi,
 
Upon reading the ANCP protocol draft, I = noticed=20 that section 4 contains
 some sections which overlap with the = ANCP=20 Framework and Requirements
 document. In order to avoid this = overlap,=20 and also to increase the
 alignment between both documents, I = suggest to=20 make the following
 changes:
 
[Sanjay] There is = introductory text=20 in the draft that says:
 
"ANCP framework = document [8]=20 describes the ANCP use-cases in detail. Illustrative text for =
 the=20 use-cases is included here to help the protocol implementer understand = the=20 greater
 context of ANCP protocol interactions."
 
I have already pruned = some of the=20 overlapping text from sections 4 and beyond. However, what is included=20 is
minimally required to provide context. It is very much inline with = other=20 IETF protocol specs, and
I would like to keep it in. Please see = inline for=20 other comments.
 

section 4: rename = title to "ANCP=20 message flows"
 
section 4.1 should = clarify that=20 following subsections describe the
 message flows for the = different use=20 cases identified in the ANCP
 Framework
 & = Requirements=20 document. It should also reference this document,
 indicating it = contains the background information on the ANCP=20 message
 flows.
 
[Sanjay] See response = above.
 
section 4.2: rename = title to "Access=20 Topology Discovery" to be
 consistent with the naming in the = framework=20
 
[Sanjay] OK.
 
section 4.2.1 is coverd = by section=20 3.1 in the framework =3D> it should
 be  removed =
 
[Sanjay] See response = upfront.
 
section 4.3: = rename title to=20 "Access Loop Configuration" to be
 consistent with the naming in = the=20 framework
 
[Sanjay] OK.
 
section 4.3.1 is coverd = by section=20 3.2 in the framework =3D> it should
 be removed
 
[Sanjay] See response = upfront.
 
I suggest to = switch sections=20 4.4. and 4.5, to have the same sequence as
 in the framework=20 document.
 
[Sanjay] OK.
 

Then we get: =
 
section 4.4 "Remote = Connectivity=20 Test" (title changed to make it
 consistent with the framework)=20
 
[Sanjay] OK.
 
The first two = paragraphs before the=20 message flows are also captured in
 section 3.3 in the framework = =3D>=20 they can be removed.
 
[Sanjay] Seen response = upfront.
 
section 4.5 = "Multicast" (title=20 changed to make it consistent with the
 framework)
The = current text=20 is also captured in section 3.4 of the framework, so I
 think it = should=20 be removed.
 
[Sanjay] See response = upfront.
 
Also I believe the = following sentence=20 is losing relevance: "In ATM access networks, ANCP can be used by the=20 NAS
 to setup P2MP cross-connects in the DSLAMs." As far as I = know,=20 most
 (if not all) of current multicast deployment scenarios in = access=20 are based
 on Ethernet/IP packet replication, not on ATM cell=20 replication.
 Furthermore, networks are rapidly migrating for = ATM to=20 Ethernet. For
 these  reasons I suggest removing this=20 sentence.
 
[Sanjay] Agreed. This can go when the = protocol=20 machinery for multicast use-cases is added.
 

Regards, =
Sven=20
 
------_=_NextPart_001_01C7CF83.EFC5913F-- --===============1146771864== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp --===============1146771864==-- From ancp-bounces@ietf.org Tue Jul 31 06:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpCA-0002zc-VK; Tue, 31 Jul 2007 06:43:18 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IFpC9-0002zW-J7 for ancp-confirm+ok@megatron.ietf.org; Tue, 31 Jul 2007 06:43:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFpC9-0002zO-6K for ancp@ietf.org; Tue, 31 Jul 2007 06:43:17 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFpC6-00034O-Rv for ancp@ietf.org; Tue, 31 Jul 2007 06:43:17 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 31 Jul 2007 12:43:13 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAAI6vrkaQ/uCKh2dsb2JhbACOGQIBCAonoSo X-IronPort-AV: i="4.19,203,1183327200"; d="scan'208"; a="149434302:sNHT85117200" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l6VAhDtb014141; Tue, 31 Jul 2007 12:43:13 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6VAh9kt012458; Tue, 31 Jul 2007 10:43:09 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 12:43:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 31 Jul 2007 12:42:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 69 ANCP meeting minutes Thread-Index: AcfTX4wyCjWn6UNqSv23rIL0qdJLyQ== From: "Wojciech Dec \(wdec\)" To: X-OriginalArrivalTime: 31 Jul 2007 10:43:08.0913 (UTC) FILETIME=[95A21610:01C7D35F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=20696; t=1185878593; x=1186742593; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:=20IETF=2069=20ANCP=20meeting=20minutes |Sender:=20; bh=pUpO902uGP7cDhU6BwaAtpz+zcy7wH6/w1ADrHXuIKc=; b=g2zaqfybJSK1NGd5xvKVWmvYhqPLWyQuXb8RUtZ4cUw/cMNyBeI9GO7fjxLkqjN+G4df136m i5sYT/yYD8b01nFvZCUC36dJV5nOSD9p3oFh4cIlRCx8AhmeemNRVn+J; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156 Cc: Jari Arkko Subject: [ANCP] IETF 69 ANCP meeting minutes X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ancp-bounces@ietf.org Hi All, Here are the IETF 69 ANCP WG's meeting minutes, and actions items. Thanks to all, and in particular to our scribe Jeremy. * ACTION Item Summary ACTION #1 Chairs: Update milestones ACTION #2 ANCP working group: Review WT-147 and determine deltas (if any). ACTION #3 Chairs; draft a liaison to DSLF. ACTION #4: Chairs to issue last call for security draft. ACTION #5 Sanjay: Initiate WG mailer discussion on graceful restart and line bonding. ACTION #6: Matthew - to send out mail to WG with observations about protocol draft's use for other technologies. ACTION #7: Chairs - confirm multicast direction on list. Regards, Woj & Matthew ANCP WG IETF 69meeting minutes TUESDAY, July 24th, 2007: 15:20 - 17:20 ------------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci *** 5 mins - Administrivia : Chairs We're clearly past the shown milestones. Agreed for pushing milestones out by about 6 months for all outstanding items. Mar 2007 becomes Oct 2007. Security requirements doc ready for last call. Sanjay Wadhwa - Still discussion on multicast use case. Protocol depends on Framework and Requirements. ACTION #1 Chairs: Update milestones *** 5 mins - Liaisons : Chairs Received a liaison from DSLF inviting us to refer to WT-147. Includes an invitation to DSLF in Nashville. Wojciech Dec : How many people have read the WT-147 liaison. None. Hassnaa Moustafa : Don't see the coherency between the WT-147 use cases and the wg defined use cases. Is the ANCP protocol suitable for the use-cases identified in WT-147. Decision should be made by ANCP WG. Wojciech Dec : Multicast discussions have been going on for some time in DSL Forum and are still ongoing. WT147 however contains more multicast use-case content than the WG's ANCP Framework doc. The ANCP framework doc derives from the WT-147 framework, so all uses would appear to be covered. Feedback on this from additional WT-147 reviewers would be welcome. ACTION #2 ANCP working group: Review WT-147 and determine deltas (if any). Mark Townsley - Since this is a reply from an earlier WG liaison, we might just send a courtesy reply.=20 Wojciech - It does seem like the DSL Forum?s reply was a response to our previous liaison.=20 Mark Townsley - Ping-pong courtesy replies perhaps not needed then, but we could reply saying "Thank you for the liaison. We've asked the WG to review the doc, etc". ACTION #3 Chairs; draft a liaison to DSLF. *** 15 mins - ANCP Framework / Requirements - Dong Sun (dongsun@alcatel-lucent.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework- 02.txt Presented on behalf of Sven. Main updates: Multicast section as per consensus from last meeting. Made network element requirement informative Other edits as per comments. Multicast - Resource efficient multicast increasing in importance. Requires local replication in access node. In order to maintain backward compatibility, AN and NAS to behave like black box. Implementation of multicast behavior between AN and NAS will not be specified. How to proceed? Can we consider draft complete?=20 Framework is not considered complete (from audience). Wojciech Dec : How many people have read the latest doc? Approx 5 people raise hands. Dong asks for comments about doc. Francois Le Faucheur : Multicast section requirements are woefully incomplete. Can't write a protocol from this level of detail. Either we add more detailed multicast requirements or we define multicast out of the scope of present Framework document. Believe that we need to add same level of detail as for other use-cases.=20 Dong : Wasn't there consensus at the last meeting to keep protocol details out of the framework? Wojciech Dec: Last meeting had consensus on the scope, detailed protocol work is for the protocol spec. Mark : Framework doc is a tool to let the WG come to consensus. If it's a tough issue, maybe it needs even more details than non contentious items. Ultimate output of IETF is a protocol not a framework. Fact that there is a lot of discussion on multicast indicates that more detail needs to be spelled out.=20 Matthew Bocci: There must be at least an equivalent level of detail in the multicast requirements as for other use cases. Sanjay Wadhwa: Doesn't see the detailed message flows in the framework doc. Mark: didn't hear that suggested Woj (expressing opinion): Detailed flows not in framework, but message primitives yes. Francois: Other use-cases have 2-3 main things in framework. 1. Description of use-case 2. description of message exchange. 3 Requirements for protocol. Those three also needs to be in framework document for multicast. The exact message flow should not go into framework but instead in protocol draft. Woj: Seems like we have consensus. Any comments? Jeremy Brayley : Depends how much the primitives define the protocol. Eg one might solve things differently than by having message from Access-Node to NAS. Way use-cases written so far is it describes why a message is to be sent. Woj: Does the framework and requirements doc need to contain enough detail to write the protocol for the multicast use-case. Jeremy : Yes. Separate protocol document describes the flows. Maybe even the primitives. Woj: Key point is the primitives. From what we've heard so far, primitives are to be in the framework doc. Mark : There is an out clause in the document already. It says that the primitives are examples and don't necessarily define the actual messages to be used by the protocol. If you want to do things differently, you can. *** 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-security- threats-01.txt Security and authentication/auth per subscriber is out of scope. Added a block to system diagram for aggregation network. Also added "regional network". Considers attacks against multicast use case. Vulnerability analysis covers cases when Access-node does IGMP snooping or proxying, or relays message in transactional ANCP. Multicast scenario attacks in general can be considered similar to attacks in Use-case 1 and 2. Major change: On-path attacks, and active attacks. DoS causing certain subs inability to access certain mcast streams or reduced bandwidth. Man-in the middle - forging messages between a NAS and AN. Message modification i.e. reducing bandwidth Message replay. Asking for comments. Want to move towards last call. Woj: How many people read the draft? 2 hands raised. Woj: Definitely not enough. Mark: Document goes no where without reviewers. Need 5 volunteers to read and comment.=20 Matthew: Call for volunteers. Volunteers: Curtis Sherbo Phillipe Niger Michael Busser Francios LeFaucher Raymond Zhang Mark: Can issue last-call and do review during last call. Woj: Doc covers multicast. Do you see any changes arising out of this from the multicast discussion currently on-going? Hassnaa: No. Doc considers multicast from a general perspective and so all scenarios are addressed. Matthew Bocci: We'll issue a Last-call mail. ACTION #4: Chairs to issue last call for security draft. *** 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol- 01.txt Not a lot of protocol changes. Most of the changes were in the form of adding more clarity to help implementers. Clarified that draft uses GSMPv3 over TCP. Protocol implementer just needs to look at RFC 3292 and this draft. New text for Section 5. Explicitly specified base GSMPv3 and ANCP message format. Draft uses just a small subset of RFC 3292 messages - explicitly listed in the ANCP spec. Additional messages also covered (Bulking of messages). Multicast use case will likely result in substantial protocol development. Graceful restart and DSL bonding will also require more work. To discuss on mailing list. Woj: Sanjay, will you take the action to initiate the discussions on these two items? Sanjay: yes ACTION #5 Sanjay: Initiate WG mailer discussion on graceful restart and line bonding. Because graceful restart draft has expired, Sanjay will take action to discuss graceful restart on mailing list. Woj: How many people read the draft. 3 hands raised. Matthew: Comment that we always said draft was for DSL, but it should be useful for other technologies. Would like to see a more generic name for attributes (i.e. not DSL line attributes under DSL Tech type). Sanjay: Seems like some attributes can indeed be more generic. Needs more thought. Woj: Definitely a discussion needed. Draft seems to associate functionality with tech type attribute. Sanjay: Sharing of attributes can become cumbersome. Change affects all tech types. Matthew will send comment on list. ACTION #6: Matthew - to send out mail to WG with observations about protocol draft's use for other technologies. Samita (from Azaire) : What access technologies are to be covered? Answer was PON, wireless, etc. Should be extensible beyond DSL. However we will focus on DSL as a deliverable right now. Woj: Charter of the WG makes DSL the primary focus, but intent is to be extensible to others. *** 30 mins - ANCP Multicast Handling - Roberta Maglione ( roberta.maglione@telecomitalia.it) http://www.ietf.org/internet-drafts/draft-maglione-ancp-mcast -00.txt Objectives: Behave like black box, when replication done by AN. Enable NAS to provide info to AN to allow it to make local decisions when possible or query the NAS in all other cases. 4 use cases: Multicast Conditional Access Multicast Admission Control Multicast accounting Multicast termination *Multicast Conditional Access Purpose: To provide network level access control for multicast traffic.=20 Two approaches can be taken. The approaches are also specified by MBONED in multi-aaa framework doc. (policy push and policy pull) 3 scenarios: 1) Decision taken by AN NAS uses ANCP to provision Access-node Defines white, black and neither. White list is the list for which access-node can make decision without querying NAS. Join requests for Black list entries are to be denied. All other requests result in a query to NAS. 2) Decision taken by NAS (or by AAA server) This is a pull model. Desirable to have decision done by NAS or AAA server in more complex policy decisions; video conferencing, multi-party access-control, CAC. Access node is to query to the NAS before allowing a join. 3) Coarse-grained decision by NAS and fine-grained by AN Defines multicast flow groups. Multicast flow-group entries share the same conditional access policy. This will reduce the number of queries to the NAS. *Multicast admission control Objective: Access level admission control for multicast. Same 3 scenarios as Conditional Access case 1) Admission control by AN AN pre-provisioned with AC information 2) Admission control by NAS For Triple Play we want multicast CAC to be synchronized with unicast CAC. 3) Coarse-grained by NAS and fine-grained by AN Flow-Group means same bandwidth. AN performs decisions for flows within same Flow-Group. NAS makes admission control decision for whole Flow-Group. *Multicast accounting Objective: To have capability for per line time or volume multicast accounting. * Multicast termination Objective: Provide capability to dynamically stop multicast replication NAS must be able to revoke authorization granted. AN must stop multicast flow. Roberta then explained the message flows for each case. Roberta : Proposal for WG: Incorporate use-cases and requirements in ANCP framework draft. Message flows in ANCP protocol draft. Wojciech : Consensus on list is that use cases are plausible. So are using white and black lists and provisioning. Discussion on list is whether mechanisms beyond white/black are needed (i.e. query NAS). 1st question: Resolve framework & requirements document issue, discussed earlier. Do we want the doc to contain multicast use-case requirements? Consensus is yes. 2nd question: Would we agree about the optional mechanisms to address the need for flexibility and/or specific use-cases? Add the primitives to the requirements doc? Raymond Zhang : Could white list be considered as a case of black list? Roberta : No. Need to query NAS. Need a third case. Woj: Issue often discussed is predictability. Pre-provisioned lists handle well events that are predictable. Cases where predictability is not possible or feasible, needs reaction when request is issued. Dong : Still some debates on list. Do we need to query the NAS? For TV performance requirement needs to be met. Video conferencing may require application level registration, and authentication. Is IGMP the only trigger or should there be app layer signaling as the trigger? Prefer to use single (IGMP?) mechanism for all services. The solution appears to be complicating not simplifying. Francois : Not going to be 100% agreement. Everybody agree on white/black list. A bunch of people want more. Only talking about an optional mechanism to do more. Roberta and I think we need that flexibility. Other people on the list stated so. Toerless, Sanjay and Curtis want it too. We need flexibility. Also, MBONED defines AAA multicast; explicitly describe push & pull model for multicast. Obviously there is more than enough justification. Mike Mcbride - Agrees. From PIM WG. Read the draft. It seems reasonable with what we are used to in other IETF mcast groups. Dynamic flexibility appears to be necessary, and good to have it as option. Supports proposal. Hiroshi Ohta : From MBONED. MBONED discussing AAA issues in general sense, not focusing on access method. Depending on application, but does definitely see a case for multicast AAA. It is reasonable for framework & requirement to address multicast handling issues. Yes to first question. Agrees that flexible option is useful. Yes to second question. Jeremy : Agree with the NAS making the decision, but why does it require the query/pull mechanism? Why can't all IGMP messages go up to NAS (the transparent snooping case)? If transparent snooping is used, won't there be two messages going to the NAS (query and IGMP). Roberta : There is a common assumption that the AN is acting as an IGMP proxy not transparent snooping. Jeremy : If so, we need to explicitly note that either 1) transparent snooping is not used 2) it won't work or that 3) we don't want to rely on IGMP between the AN. Mark : In one case IGMP comes up. ANCP is involved to send to the NAS. In the other case, IGMP is sent all the way to the NAS. Seem to be very similar. This kind of detail can be for later. Francois : Perhaps terminology is a problem. Key point: Is the decision entirely taken by the AN or not? We're saying that there is a case when the NAS decides. Doesn?t matter too much for the current discussion whether the NAS decides following ANCP or IGMP. Jeremy : But ANCP requires a specific message. Francois : correct. But bigger question is: Do we agree that NAS makes the decision? Sanjay: Agree. Woj: We can have the debate about IGMP trigger or not, but we don't have control over existing IGMP implementations and optimizations. Within ANCP we can introduce own optimizations. Key take away from discussion: There is agreement that ANCP needs to support scenarios where NAS takes the multicast decision. Sanjay: For CAC, the mainstream scenario is for NAS to take decision. Does it make sense to have a grey list? Francois: Initial proposal actual included Grey list. Then it was removed because wed hoped to achieve same thing with masks & ranges. But can now see a case where grey list would help. We need to think more and perhaps to add grey lists. Dong : Question on slide 8. Seems to see performance problems with query. Woj: Two proposals on the table. One says "white&black", other says "white&black + query". Are you saying that we shouldn't discuss the latter?=20 Dong: Need to understand how mechanism works. Woj: Let's take a step back. Do you agree on the CAC use-case? Some of the valid deployment options are to have CAC done by AN, some by NAS. Within the scope of ANCP WG, we deal with what happens between NAS and AN. The use-case here is about CAC done by NAS. Query makes this happen. Dong: Still not clear how query can be used to support use-case. Performance concerns. Curtis Sherbo: Draft proposes white/black lists ? these can be used where performance matters. In other cases when choosing to use conditional access, SPs would knowingly choose the mechanism and be aware of its performance.=20 Dong: Don't see the mechanism in the draft support the scenario you mention. Sanjay: In practical cases, grouping of flows do not result in query per zap. Specific case can be thought of as resulting in query per zap. Mark : Centralized and distributed databases scale in different ways. This is a classic problem. Depends on which you want to optimize. Each has tradeoffs. Centralized slower to access, easier to manage. The mechanism offers operator the choice. Ulf Borinad (Operax) : Clarification question on managing lists. If something doesn?t exist on white/black, it should result in a query. Is the list then updated? Francois: That's a possibility allowed by the proposal. Woj : We have specific proposal in this draft. Mark how do you propose handling it? Mark : As AD I see far more support for flexibility for query mechanism than not in this room. So I don't see any justification to not support that flexibility. Needs to be confirmed on mailing list. Woj: Take flexibility as key thing. Lot of support, individual opposition. ACTION #7: Chairs - confirm multicast direction on list. *** 15 mins - Extension of ANCP for Satellite and Terrestrial Wireless Modem Networks - Lloyd Wood (lwood@cisco.com) http://www.ietf.org/internet-drafts/draft-floreani-ancp- wireless-00 Been dealing with problem with which ANCP can help Smart adaptive modems need to update routers with current satellite modem speed. Similar to DSL. Looking at adding wireless class extension to ANCP. Point-multipoint and point-point cases. Eventually moving to point to point. Use ethernet between modem and router because of cost. Serial would be best option, but not going to happen. ANCP works across TCP. Given that satellite delay is an issue, doing ANCP local looks like the answer. Multicast CAC use-case also of interest to satellite. Interested in comments and whether this is something for ANCP. Francois : Seems to match what ANCP does. But isn't it overkill to use GSMP based protocol just to sync line rate? Lloyd : This may be overkill, but we have working code and it will work. Just software. However a lot of framework is not used. But in deployment scenarios the fuller framework may get used to cover other access types. Sanjay: ANCP between NAS and modem - ok. But ANCP between CPE and modem raises questions. Is CPE trusted device? ANCP is typically contained to trusted domain Discussion on managed CPE options. Are CPE and NAS operated by different companies. Lloyd: Depends on provider. 50/50 case in satellite industry; some provide router+modem, others only modem. Lloyd: Modems turning to L3 device, part of the problem. Is ANCP suitable. Woj: Do you have specific issues with the protocol spec for satellite use? Lloyd: ANCP is an overkill, but it has all we need. Fine for our use. More discussion on CPE side aspect of modem and router. In DSL case there appears to be the same problem on the home side, between router and modem. Problem seems to be applicable to DSL too. Woj: So far we focused on the service provider side, not the home. Home is an un-explored area for us. Wojciech : Broader question is how do we ensure extensibility of ANCP to other technologies? Current text protocol spec to be very DSL tech type centric. Need to decouple function from tech type so that it can be re-used by other tech types. Also need to define extensibility path for TLVs. Sanjay: For each tech type do we need enumerate the TLVs? Woj: No. Usual search for blue sheets... _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp

I agree that there will be some central system that = holds the=20 subscriber policy information. In the case of nomadicity, this system = will be in=20 the "home network" (I don't mean customer premises network) and = will need=20 to be contacted by the "visiting network". This could be done in a push = mode -=20 bringing the relevant policy information to the network elements in the = visiting=20 network - or in a pull mode - outsourcing the decision to the home = network. In=20 my view, in the case of multicast, the push model leads to less = signaling than=20 the pull model (unless some special tricks based on session grouping = with=20 timeouts are introduced in access platforms - but these have their own = issues as=20 I highlighted in my previous email). Hence I'm more in favor of using = the push=20 model even in nomadic/roaming cases.