DSLAMs.<= /DIV>

=20 In this scenario, do we want to maintain a separate control session = between each=20 of the subtended DSLAMS

=20 (potentially in 100s of units) and BRAS? Won't this increase = the=20 complexity and load in the BRAS? The simple

=20 option will be remote or CO based DSLAM would exchange the parameters = with BRAS,=20 on behalf of subtended

=20 DSLAMs. But then, this requires a reliable communication mechanism = between=20 subtended DSLAMs and remote or

=20 CO based DSLAMs. Any comments?

=20 3. General

=20 Is the DSLAM intended to use Management IP address to establish the TCP = session=20 with BRAS? If so then, for

=20 the DSLAMs which don't support In-band management, need to have a = mechanism to=20 filter the packets destined

=20 with its management IP address and pass ith ANCP application. This would = be=20 applicable for Layer 2 DSLAM.

Thanks,

Rgds,

Sathiya

------_=_NextPart_001_01C6E6EE.350D89E7-- --===============0142491955== 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 --===============0142491955==-- From ancp-bounces@ietf.org Tue Oct 03 10:16:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUl44-0001Iv-0j; Tue, 03 Oct 2006 10:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUl42-0001Ho-VQ for ancp@ietf.org; Tue, 03 Oct 2006 10:16:06 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUl3z-0004hJ-Ek for ancp@ietf.org; Tue, 03 Oct 2006 10:16:06 -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 k93EG3FL011087; Tue, 3 Oct 2006 16:16:03 +0200 In-Reply-To: <0140B5C49461E34686783F667D9E4A53865D7D@blr-k1-msg.wipro.com> Subject: RE: [ANCP] Fw: 67th IETF - DRAFT Meeting Agenda To: X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Tue, 3 Oct 2006 15:15:51 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/03/2006 15:16:00 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.2 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 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 Sathiya, I have requested that potential contributors ask for a slot to present updates or issues with their drafts at the next meeting. We will also review the status of working group items. We will post a draft agenda incorporating this nearer the meeting date. Best regards, Matthew To 03/10/2006 14:15 Matthew BOCCI/GB/ALCATEL@ALCATEL cc Subject RE: [ANCP] Fw: 67th IETF - DRAFT Meeting Agenda I am newcomer to the IETF groups. Pardon me if I am asking wrong question. Will there be any agenda circulated for upcoming ANCP draft meeting? Will the meeting focus on specific topics/issues which are unresolved since the last IETF Draft meeting? If so, probably consolidating the list of issues/topics to be discussed would help for those who are going to attend the meeting. Thanks, Sathiya -----Original Message----- From: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk] Sent: Monday, October 02, 2006 2:54 PM To: ancp@ietf.org Subject: [ANCP] Fw: 67th IETF - DRAFT Meeting Agenda This is the first draft agenda. We have been given a slot on Thursday Nov 9th from 1300-1500. However, this is very likely to change. Best regards, Matthew ----- Forwarded by Matthew BOCCI/GB/ALCATEL on 02/10/2006 10:22 ----- IETF Secretariat To IETF Announcement list 02/10/2006 05:14 cc Subject 67th IETF - DRAFT Meeting Agenda The DRAFT agenda for the 67th IETF Meeting can be found at: http://www.ietf.org/meetings/67-IETF.html Please note that the agenda is in draft form and is subject to change substantially before the final agenda is published on Monday, October 16. IETF Secretariat _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Oct 17 03:43:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjbZ-0001XP-G2; Tue, 17 Oct 2006 03:43:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZYTL-0006Pi-19; Mon, 16 Oct 2006 15:50:03 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZYTJ-00055w-M2; Mon, 16 Oct 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 9F9FD32886; Mon, 16 Oct 2006 19:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZYTJ-0005rO-HP; Mon, 16 Oct 2006 15:50:01 -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, 16 Oct 2006 15:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 X-Mailman-Approved-At: Tue, 17 Oct 2006 03:43:15 -0400 Cc: ancp@ietf.org Subject: [ANCP] I-D ACTION:draft-ietf-ancp-framework-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: , 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-00.txt Pages : 32 Date : 2006-10-16 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-00.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-00.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-00.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: <2006-10-16112911.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-framework-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-framework-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-16112911.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 Oct 18 04:26:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6l4-0004UR-37; Wed, 18 Oct 2006 04:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga6gd-0002ta-MO for ancp@ietf.org; Wed, 18 Oct 2006 04:22:03 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga6gb-0005pk-UM for ancp@ietf.org; Wed, 18 Oct 2006 04:22:03 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 10:21:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 18 Oct 2006 10:21:55 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Security Requirements Draft Thread-Index: AcbyjnWCrLHPpRcVTfWyef5aJdG+Fw== From: "MOUSTAFA Hassnaa RD-CORE-ISS" To: X-OriginalArrivalTime: 18 Oct 2006 08:21:56.0885 (UTC) FILETIME=[79C4B450:01C6F28E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c X-Mailman-Approved-At: Wed, 18 Oct 2006 04:26:36 -0400 Subject: [ANCP] ANCP Security Requirements Draft 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="===============0126853668==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============0126853668== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F28E.7982F465" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F28E.7982F465 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 A new draft is submitted, discussing the ANCP security requirements. Title : Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, H. Tschofenig and S. De Cnodder Filename : draft-moustafa-ancp-security-threats-00.txt =20 The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related operations=20 between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). =20 The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS=20 in order to enable and optimize configuration. This document investigates security threats that all ANCP nodes could encounter,=20 developing a threat model for ANCP security aiming to decide which security functions are required at the ANCP level. Based on this, security requirements regarding the Access Node Control Protocol are defined. URL for this daft: http://www.ietf.org/internet-drafts/draft-moustafa-ancp-security-threats -00.txt =20 Thanks for your comments. Hassnaa Moustafa =20 =20 ------_=_NextPart_001_01C6F28E.7982F465 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

A new=20 draft is submitted, = discussing=20 the ANCP security=20 requirements.

Tit= le=20 : Security Threats and Security Requirements for the Access Node = Control=20 Protocol (ANCP)
Author(s) = =20 : H. Moustafa, H.=20 Tschofenig and S. De Cnodder

Filename = =20 : draft-moustafa-ancp-security-threats-00.txt
&= nbsp;

The Access Node Control Protocol = (ANCP) aims=20 to communicate QoS-, service- and=20 subscriber-related operations

between a Network Access = Server (NAS)=20 and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer = (DSLAM)). =20

The main goal of this = protocol is=20 to configure and manage = access=20 equipments and allow them to report information to the NAS=20

in order to = enable and=20 optimize configuration. This = document=20 investigates security threats that all ANCP nodes could encounter,=20

developing a = threat model=20 for ANCP security aiming to = decide which=20 security functions are required at the ANCP level.
Based on this, security requirements = regarding=20 the Access Node Control Protocol are defined.

URL for this=20 daft:

http://www.ietf.org/internet-drafts/draft-moustafa-ancp-s= ecurity-threats-00.txt

Thanks for your comments.

Hassnaa=20 Moustafa

------_=_NextPart_001_01C6F28E.7982F465-- --===============0126853668== 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 --===============0126853668==-- From ancp-bounces@ietf.org Wed Oct 18 05:46:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga80U-0007wC-OO; Wed, 18 Oct 2006 05:46:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga80T-0007qK-4G for ancp@ietf.org; Wed, 18 Oct 2006 05:46:37 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga80M-00089j-83 for ancp@ietf.org; Wed, 18 Oct 2006 05:46:37 -0400 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 721C611C6; Wed, 18 Oct 2006 11:42:35 +0200 (CEST) Received: from esealmw104.eemea.ericsson.se ([153.88.200.67]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 11:42:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] ANCP Security Requirements Draft Date: Wed, 18 Oct 2006 11:42:34 +0200 Message-ID: <2DEB3E4E9BC3774B8EEF2EF2BE9F745B27A64A@esealmw104.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Security Requirements Draft thread-index: AcbyjnWCrLHPpRcVTfWyef5aJdG+FwACZjGA From: "Kim Hyldgaard \(ST/LMD\)" To: "MOUSTAFA Hassnaa RD-CORE-ISS" , X-OriginalArrivalTime: 18 Oct 2006 09:42:34.0772 (UTC) FILETIME=[BD5FAD40:01C6F299] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 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="===============1629991984==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1629991984== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F299.BD2F8A08" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F299.BD2F8A08 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 Two comments: =20 1) - I think this document is very good and thorough. - Great work! =20 2) I don't understand this requirement from section 7: "The protocol solution SHOULD distinguish the control messages from the data." What is defined as a control message and what is defined as data? In section 5.7 I found "...as for example capturing control messages sent from the AN to the NAS announcing that a DSL line is up..." So if a PORT UP message from the topology discovery use case is a control message, which messages would be data? >From my point of view "control message" in this context are messages related to maintaining the protocol, and all messages related to use cases are "data". Please enlighten me if my reasoning is wrong... :-) Kind regards Kim Hyldgaard ________________________________ From: MOUSTAFA Hassnaa RD-CORE-ISS [mailto:hassnaa.moustafa@orange-ft.com]=20 Sent: 18. oktober 2006 10:22 To: ancp@ietf.org Subject: [ANCP] ANCP Security Requirements Draft Hi, =20 A new draft is submitted, discussing the ANCP security requirements. Title : Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, H. Tschofenig and S. De Cnodder Filename : draft-moustafa-ancp-security-threats-00.txt =20 The Access Node Control Protocol (ANCP) aims to communicate QoS-, service- and subscriber-related operations=20 between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). =20 The main goal of this protocol is to configure and manage access equipments and allow them to report information to the NAS=20 in order to enable and optimize configuration. This document investigates security threats that all ANCP nodes could encounter,=20 developing a threat model for ANCP security aiming to decide which security functions are required at the ANCP level. Based on this, security requirements regarding the Access Node Control Protocol are defined. URL for this daft: http://www.ietf.org/internet-drafts/draft-moustafa-ancp-security-threats -00.txt =20 Thanks for your comments. Hassnaa Moustafa =20 =20 ------_=_NextPart_001_01C6F299.BD2F8A08 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Two=20 comments:

- I=20 think this document is very good and thorough. - Great = work!

2)
I don't understand this requirement from = section=20 7:
"The = protocol solution=20 SHOULD distinguish the control messages from
the data."

What is defined as a control message = and what=20 is defined as data?

In section=20 5.7 I found
"...as for example capturing control=20 messages
sent from the AN to the NAS announcing that a DSL line is=20 up..."

So if a PORT UP message from the topology discovery = use=20 case
is a control message, which messages would be data?

From = my point=20 of view "control message" in this context are messages
related to = maintaining=20 the protocol, and all messages related to
use cases are=20 "data".

Please=20 enlighten me if my reasoning is wrong... :-)

Kind=20 regards
Kim Hyldgaard

From: MOUSTAFA Hassnaa RD-CORE-ISS=20 [mailto:hassnaa.moustafa@orange-ft.com]
Sent: 18. oktober = 2006=20 10:22
To: ancp@ietf.org
Subject: [ANCP] ANCP = Security=20 Requirements Draft

Hi,

Filename = =20 : draft-moustafa-ancp-security-threats-00.txt
&= nbsp;

The Access Node Control Protocol = (ANCP) aims=20 to communicate QoS-, service- and=20 subscriber-related operations

between a Network = Access Server=20 (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer = (DSLAM)). =20

The main goal of=20 this protocol is to configure and=20 manage access equipments and allow them to report information to the NAS=20

in=20 order to enable and optimize configuration.=20 This document investigates security threats that all ANCP nodes=20 could encounter,=20

developing a threat model for ANCP security aiming to decide which security functions are = required at=20 the ANCP level.
Based on = this, security=20 requirements regarding the Access Node Control Protocol are = defined.

URL=20 for this=20 daft:

http://www.ietf.org/internet-drafts/draft-moustafa-ancp-s= ecurity-threats-00.txt

Thanks for your=20 comments.

Hassnaa=20 Moustafa

------_=_NextPart_001_01C6F299.BD2F8A08-- --===============1629991984== 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 --===============1629991984==-- From ancp-bounces@ietf.org Thu Oct 19 03:54:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSjB-0003jU-At; Thu, 19 Oct 2006 03:54:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaSjA-0003jG-4i for ancp@ietf.org; Thu, 19 Oct 2006 03:54:08 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaSj7-0007xt-8z for ancp@ietf.org; Thu, 19 Oct 2006 03:54:08 -0400 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 09:53:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] ANCP Security Requirements Draft Date: Thu, 19 Oct 2006 09:54:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Security Requirements Draft Thread-Index: AcbyjnWCrLHPpRcVTfWyef5aJdG+FwACZjGAAC2wK8A= From: "MOUSTAFA Hassnaa RD-CORE-ISS" To: "Kim Hyldgaard \(ST/LMD\)" , X-OriginalArrivalTime: 19 Oct 2006 07:53:54.0002 (UTC) FILETIME=[B91AE320:01C6F353] X-Spam-Score: 0.0 (/) X-Scan-Signature: da41e01217ab11ad82db577473e913ae 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="===============1289075075==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1289075075== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F353.BDAFBB71" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F353.BDAFBB71 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 =20 =20 ________________________________ De : Kim Hyldgaard (ST/LMD) [mailto:kim.hyldgaard@ericsson.com]=20 Envoy=E9 : mercredi 18 octobre 2006 11:43 =C0 : MOUSTAFA Hassnaa RD-CORE-ISS; ancp@ietf.org Objet : RE: [ANCP] ANCP Security Requirements Draft Hi, =20 Two comments:=20 =20 Hi Kim, Thanks for your comments. =20 =20 1) - I think this document is very good and thorough. - Great work! =20 2) I don't understand this requirement from section 7: "The protocol solution SHOULD distinguish the control messages from the data." What is defined as a control message and what is defined as data?=20 Control messages are messages sent by a controller function (defined in = the framework draft) for either information requests or triggering = certain network element. Data concerns the information transferred by a = reporting function to a controller function containing status = information.=20 In section 5.7 I found "...as for example capturing control messages sent from the AN to the NAS announcing that a DSL line is up..."=20 Actually, what is meant here is the capturing of signaling packets = between the AN and the NAS, for this the word control was used (may be a = re-formulation is needed for clarity and non ambiguity with the above = requirement).=20 So if a PORT UP message from the topology discovery use case is a control message, which messages would be data?=20 According to the above definition, this is data. >From my point of view "control message" in this context are messages related to maintaining the protocol, and all messages related to use cases are "data".=20 All messages related to status reporting are considered data, which does = not contradict with your point of view. Please enlighten me if my reasoning is wrong... :-)=20 Regards, Hassnaa=20 Kind regards Kim Hyldgaard ________________________________ From: MOUSTAFA Hassnaa RD-CORE-ISS = [mailto:hassnaa.moustafa@orange-ft.com]=20 Sent: 18. oktober 2006 10:22 To: ancp@ietf.org Subject: [ANCP] ANCP Security Requirements Draft Hi, =20 A new draft is submitted, discussing the ANCP security requirements. Title : Security Threats and Security Requirements for = the Access Node Control Protocol (ANCP) Author(s) : H. Moustafa, H. Tschofenig and S. De Cnodder Filename : draft-moustafa-ancp-security-threats-00.txt =20 The Access Node Control Protocol (ANCP) aims to communicate QoS-, = service- and subscriber-related operations=20 between a Network Access Server (NAS) and an Access Node (e.g., a = Digital Subscriber Line Access Multiplexer (DSLAM)). =20 The main goal of this protocol is to configure and manage access = equipments and allow them to report information to the NAS=20 in order to enable and optimize configuration. This document = investigates security threats that all ANCP nodes could encounter,=20 developing a threat model for ANCP security aiming to decide which = security functions are required at the ANCP level. Based on this, security requirements regarding the Access Node Control = Protocol are defined. URL for this daft: http://www.ietf.org/internet-drafts/draft-moustafa-ancp-security-threats-= 00.txt =20 Thanks for your comments. Hassnaa Moustafa =20 =20 ------_=_NextPart_001_01C6F353.BDAFBB71 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

De : Kim Hyldgaard (ST/LMD)=20 [mailto:kim.hyldgaard@ericsson.com]
Envoy=E9 : mercredi = 18 octobre=20 2006 11:43
=C0 : MOUSTAFA Hassnaa RD-CORE-ISS;=20 ancp@ietf.org
Objet : RE: [ANCP] ANCP Security = Requirements=20 Draft

Hi,

Two comments:

Hi Kim,

Thanks for your=20 comments.

- I=20 think this document is very good and thorough. - Great = work!

<= SPAN=20 class=3D526313009-18102006>

Control messages are messages sent by a controller function = (defined in=20 the framework draft) for either information requests or triggering = certain=20 network element. Data concerns the information transferred by a = reporting=20 function to a controller function containing status=20 information.

In section 5.7 I found
"...as for example = capturing control=20 messages
sent from the AN to the NAS announcing that a DSL line is=20 up..."

Actually, what is meant here is the capturing of signaling = packets=20 between the AN and the NAS, for this the word control was used (may be a = re-formulation is needed for clarity and non ambiguity with the above=20 requirement).

= So if a=20 PORT UP message from the topology discovery use case
is a control = message,=20 which messages would be data?

<= SPAN=20 class=3D526313009-18102006>

According to the = above=20 definition, this is data.

From my point of view = "control=20 message" in this context are messages
related to maintaining the = protocol,=20 and all messages related to
use cases are "data".

All messages related to = status=20 reporting are considered data, which does not contradict with your = point of=20 view.

Please enlighten me if my reasoning is wrong... :-)

Regards,

Hassnaa

Kind=20 regards
Kim Hyldgaard

From: MOUSTAFA Hassnaa RD-CORE-ISS=20 [mailto:hassnaa.moustafa@orange-ft.com]
Sent: 18. oktober = 2006=20 10:22
To: ancp@ietf.org
Subject: [ANCP] ANCP = Security=20 Requirements Draft

Hi,

Filename = =20 : draft-moustafa-ancp-security-threats-00.txt
&= nbsp;

The Access Node Control Protocol = (ANCP) aims=20 to communicate QoS-, service- and=20 subscriber-related operations

between a Network = Access Server=20 (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer = (DSLAM)). =20

The main goal of=20 this protocol is to configure and=20 manage access equipments and allow them to report information to the NAS=20

in=20 order to enable and optimize configuration.=20 This document investigates security threats that all ANCP nodes=20 could encounter,=20

http://www.ietf.org/internet-drafts/draft-moustafa-ancp-s= ecurity-threats-00.txt

Thanks for your=20 comments.

Hassnaa=20 Moustafa

------_=_NextPart_001_01C6F353.BDAFBB71-- --===============1289075075== 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 --===============1289075075==-- From ancp-bounces@ietf.org Mon Oct 23 10:44:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc12D-0000K6-QL; Mon, 23 Oct 2006 10:44:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc126-0008H5-KP for ancp@ietf.org; Mon, 23 Oct 2006 10:44:06 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc0wm-0006cS-LH for ancp@ietf.org; Mon, 23 Oct 2006 10:38:39 -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 k9NEcWNN010191; Mon, 23 Oct 2006 16:38:36 +0200 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Mon, 23 Oct 2006 15:38:25 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/23/2006 15:38:32 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.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [ANCP] IETF 67 draft agenda 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 I have uploaded a draft agenda for the upcoming ANCP meeting in San Diego to the IETF site at the following URL: http://www3.ietf.org/proceedings/06nov/agenda/ancp.txt Please let me know if you have any comments or corrections to the agenda. The meeting is on Thursday November 9th at 1pm. Please can you send your slides to myself or Wojciech no later that 5pm PST on Wednesday 8th November so that we can upload them to the IETF server in time for the meeting. Best regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Oct 23 15:07:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc58P-0003K0-FL; Mon, 23 Oct 2006 15:06:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc58O-0003GB-OH for ancp@ietf.org; Mon, 23 Oct 2006 15:06:52 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc4xn-00033o-CE for ancp@ietf.org; Mon, 23 Oct 2006 14:56:13 -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 k9NItvHi004604 for ; Mon, 23 Oct 2006 20:55:57 +0200 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Mon, 23 Oct 2006 19:53:10 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/23/2006 19:55:53 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.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [ANCP] DSL Forum liaison 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 Folks, We've received a liaison from the DSL Forum regarding the work related to ANCP. This has been posted to the IETF liaison database at: https://datatracker.ietf.org/public/liaisons.cgi Best regards, Matthew _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Wed Oct 25 12:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gclzv-0003wn-IW; Wed, 25 Oct 2006 12:52:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gclzu-0003sm-Ts for ancp@ietf.org; Wed, 25 Oct 2006 12:52:58 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gclzr-0000PH-54 for ancp@ietf.org; Wed, 25 Oct 2006 12:52:58 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 25 Oct 2006 18:52:56 +0200 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.20060308/8.12.11) with ESMTP id k9PGqsZt010433; Wed, 25 Oct 2006 18:52:54 +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 k9PGqrmd011762; Wed, 25 Oct 2006 18:52:53 +0200 (MEST) 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); Wed, 25 Oct 2006 18:52:53 +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: Wed, 25 Oct 2006 18:52:45 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ieft-ancp-framework-00.txt Thread-Index: Acbuz8g4frAnvveKStG185QvfhdmPAH56YDQ From: "Wojciech Dec \(wdec\)" To: , X-OriginalArrivalTime: 25 Oct 2006 16:52:53.0798 (UTC) FILETIME=[039AA460:01C6F856] DKIM-Signature: a=rsa-sha1; q=dns; l=9996; t=1161795174; x=1162659174; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=22Wojciech=20Dec=20\(wdec\)=22=20 |Subject:RE=3A=20draft-ieft-ancp-framework-00.txt; X=v=3Dcisco.com=3B=20h=3DesCl3BapziSS9EgVnEoY0PZlA5g=3D; b=aof03UqZ4y73Cyz9CDOtMBiDAJnqBeTGNbrBp8gdq4EwsGItMixRIupvvg7PFs4ISF1UEym+ gqSos61NcRoQKLWovjmhHnwFU548ngLoA6HiE9N/2UrlB1r2HKFADJOY; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass (s ig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: "Haag, T" Subject: [ANCP] RE: draft-ieft-ancp-framework-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: , Errors-To: ancp-bounces@ietf.org Hi Sven and co-authors, Here are my comments regarding the current draft-ietf-ancp-framework draft. Feel free to discuss. P4 - Control channel and ANC Session definition This terminology has me rather uncomfortable. The control channel is effectively the logical path along which the IP packet flow happens between the two ANCP end-points. I don't quite see why there's a need to ascribe particular requirements to the control channel used by the protocol, beyond those that are deemed suitable for it by the end users. Just like a BGP peering could be made using a dedicated VLAN, etc, in many/most it's not and peer-peer security is still achieved using other means, and QoS is taken care of by having the BGP packet priority set to an appropriate protocol control value - yet I do not recall that any BGP spec mandates the use of any such path, etc. The ANC Session is really the ANCP adjacency between a controller and a controlled-node. Isn't the term "ANCP adjacency" sufficient? P8 - Access Node Control Mechanism Transport methods section This section doesn't use the terminology defined previously, but seemingly is referring to the control channel. Such a "control channel" shouldn't preclude the idea of using a dedicated interface on the Access-Node, and thus the definition of the transport as seemingly requiring a logical multiplexer in the form of a VLAN tag isn't quite right. One could very well have an untagged ethernet interface, if that's one's choice, and VLAN tagging done upstream.=20 Also, what is meant by "for higher-grade connections..." on P9?=20 It also seems to me that the whole sentence could be replaced by something simpler like: "Depending on network design, this can be a simple VLAN for each Access Node or, one Customer VLAN (C-VLAN) for each Access Node within a Service VLAN (S-VLAN) construct". P9 - "The control plane interactions are transactional in nature and imply a reliable communication channel to share states." Terminology: What is the "communication channel"? Do you mean the ANC session? Not all of the control plane interactions appear to require a transactional nature. It would seem that we generally want reliable communication, but not necessarily transactional state for all interactions eg knowledge of line rate changes is nice to have reliably, but doesn't require the protocol to offer a transaction which I associate with the ability to acknowledge/deny and revert to some previous state or continue with some operation. Thus, it appears to me that some of the control plane interactions have a transactional nature, and all of the communication is desired to be transmitted reliably. P9 - "Also, when using the Access Node Control Mechanism for performing a reporting action, there is a possibility to integrate this with a central Policy Management system that keeps track of the different Subscriber related parameters" The type of policy system is really secondary - it's whatever system that wants to consume the info. Suggest replacing the text by; "Also, when using the Access Node Control Mechanism for performing a reporting action, there is a possibility to integrate this with a subscriber policy system that keeps track of the different subscriber related parameters" P10 - "In deployments using an ATM aggregation network, the ATM PVC on an Access Loop connects the Subscriber to a NAS. Based on such property, in a PPP scenario, the NAS typically includes a NAS-Port-Id (or NAS-Port in some cases) attribute in RADIUS authentication & accounting packets sent to the RADIUS server(s). " The scenario doesn't necessitate PPP, it's valid for IPoA as well (or IPoEoA, etc). Also, these are two different radius attributes, and both are commonly used. P15 - "The ANCP MUST be an open protocol, either an existing protocol endorsed by an appropriate standard body (e.g. IETF) or a new protocol which will be submitted for standardization to an appropriate standard body." Seems that this requirement is rather obsolete, given that we are in the IETF trying to define it. "The ANCP MUST be transaction-oriented, allowing to reliably share states between the NAS and the Access Node, and recover from loss of synchronization (e.g. node or link failure). Transactions MUST be either fully completed, or rolled-back to the previous state." As per my comment above. It's quite clear that not all transactions need to be rolled-back. Thus ANCP MUST allow for transaction-oriented processing of selected information exchanges. Also, it seems that the immediately following requirement already captures the "recover from loss of synchronisation" characteristic, thus this is no longer needed here. Section 4.2 "The ANCP SHOULD have a "boot" sequence allowing to inform the peer about control capabilities supported by the two peers (Access Node, NAS) and negotiate a common subset. " And "The ANCP MUST provide a means for the AN and the NAS to perform capability negotiation. " These two seem to state the same thing, but yet one is a MUST while the other a SHOULD. IMO, the MUST is more appropriate. " o The ANCP SHOULD include a "request/response" transaction-oriented model for the NAS to communicate control decisions or request information from the Access Node. If the response is negative, then the state of the Access Node MUST be unchanged (roll-back)." Much has been said about the transactional requirement in the preceding paragraphs (and I added some more). Shouldn't this requirement be actually a MUST requirement and furthermore expanded to address that certain message exchanges are required to be transactional, while others don't? P17 - "The transport protocol used for the Access Node Control Messages MUST be reliable and scalable." The requirement is for ANCP to deliver it's payload info reliably. The transport protocol could be unreliable and the ANCP protocol could provide the reliability. P17 - "A loss of the Access Node Control Session MUST NOT affect user connectivity and element operation." End user? P17 - "For maintenance purpose the Access Node Control Session MUST be designed in a way that any malfunction of the session is automatically detected and reported from the Access Node or NAS to the Element Manager or Network Manager to support the network operator in troubleshooting the network." What has the ANC session design got to do reporting failures? P17 - Section 4.4 Access Node Requirements This whole section should IMO be redrafted around to reflect the protocol requirements arising due to various access-node uses, rather than actual access-node requirements. Also, the use of terms like "DSL port" would be best avoided if we still want the notion of supporting other media types. P18 - Section 4.4.2 We've defined ANCP to be an IP based control protocol between one node and a controller. IMO this whole section is superfluous, since it prescribes functionality that is attributed to the way of configuring a node and largely independent of the actual protocol requirements. Think it can be removed. P18& 19 - Section 4.4.3, 4.4.4 - .6 Here we're actually duplicating a protocol requirement as an access node requirement. Again, all of this section appears to be redundant as far as the protocol is concerned. If there any protocol requirements, as I seem to read in sect 4.4.4, then I think we should turn them into such as opposed to node requirements.=20 Also the use of the term "link" doesn't quite square up to the terminology. Eg=20 Current req: The Access Node MUST support an adjacency protocol used to synchronize states across the link, discover the identity of the entity at the other end of a link, and detect when it changes. Protocol req: The protocol MUST allow the discovery by each end point the identity of the other end point. The protocol MUST include a mechanism for synchronising protocol state information between two end-points. Etc. P19 - Section 4.4.7 Again, these are not protocol requirements, at least in their current form. What *may* be a protocol requirement is actually informing a controller which issued a command for the change of a setting that is not administratively allowed, i.e. an appropriate error message. P20 - section 4.5 Not protocol requirements in their current form - if that some of these that may have a relation be turned into protocol requirements. The only one I'm able to see as a potential protocol requirement is the one for having peer authorization. If we want a node to communicate to only "authorized nodes" then we need a mechanism for determining such authorization, or simply assume that the direct configuration of a peer is sufficient for that peer to be authorized. The above comment applies to all subsequent sub-sections of 4.5 P27 - Section 7 Again, these are node functional not protocol requirements. Hope that the above provides some useful input. Cheers, Woj. -----Original Message----- From: Sven.Ooghe@alcatel.be [mailto:Sven.Ooghe@alcatel.be]=20 Sent: 13 October 2006 15:59 To: internet-drafts@ietf.org Cc: Sanjay Wadhwa; Haag, T; michel.platnic@ecitele.com; Voigt Norbert; Matthew Bocci; Wojciech Dec (wdec) Subject: draft-ieft-ancp-framework-00.txt Please find below an I-D titled "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks". This draft is based on draft-ooghe-ancp-framework-00.txt, which was accepted by the ANCP community to be moved to a Working Group document.=20 It also reflects a few changes/additions resulting from the latest DSL Forum meeting where this topic was discussed. Best regards, Sven Ooghe _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Oct 27 02:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdLBP-0004is-Ah; Fri, 27 Oct 2006 02:27:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdL6q-0002FQ-TR for ancp@ietf.org; Fri, 27 Oct 2006 02:22:28 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdL4S-0002p2-Ja for ancp@ietf.org; Fri, 27 Oct 2006 02:20:03 -0400 Received: from bemail01.netfr.alcatel.fr (bemail01.netfr.alcatel.fr [155.132.251.32]) by smail.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id k9R6JxGj014148; Fri, 27 Oct 2006 08:19:59 +0200 Received: from [172.17.240.232] ([172.17.240.232]) by bemail01.netfr.alcatel.fr (Lotus Domino Release 5.0.13aHF163) with ESMTP id 2006102708195372:2028 ; Fri, 27 Oct 2006 08:19:53 +0200 Message-ID: <4541A50A.2010707@alcatel.be> Date: Fri, 27 Oct 2006 08:19:54 +0200 From: Sven.Ooghe@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wojciech Dec (wdec)" , ancp@ietf.org Subject: Re: [ANCP] RE: draft-ieft-ancp-framework-00.txt References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/27/2006 08:19:54, Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/27/2006 08:19:55, Serialize complete at 10/27/2006 08:19:55 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 X-Spam-Score: 0.2 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: "Haag, T" , Michel Platnic 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 Woj, Thanks for giving the document a good read. We will review the comments and provide a consolidated answer on this exploder as soon as we can. Regards, Sven Wojciech Dec (wdec) wrote: > Hi Sven and co-authors, > > Here are my comments regarding the current draft-ietf-ancp-framework > draft. Feel free to discuss. > > P4 - Control channel and ANC Session definition > > This terminology has me rather uncomfortable. The control channel is > effectively the logical path along which the IP packet flow happens > between the two ANCP end-points. I don't quite see why there's a need to > ascribe particular requirements to the control channel used by the > protocol, beyond those that are deemed suitable for it by the end users. > Just like a BGP peering could be made using a dedicated VLAN, etc, in > many/most it's not and peer-peer security is still achieved using other > means, and QoS is taken care of by having the BGP packet priority set to > an appropriate protocol control value - yet I do not recall that any BGP > spec mandates the use of any such path, etc. > > The ANC Session is really the ANCP adjacency between a controller and a > controlled-node. Isn't the term "ANCP adjacency" sufficient? > > P8 - Access Node Control Mechanism Transport methods section > This section doesn't use the terminology defined previously, but > seemingly is referring to the control channel. > Such a "control channel" shouldn't preclude the idea of using a > dedicated interface on the Access-Node, and thus the definition of the > transport as seemingly requiring a logical multiplexer in the form of a > VLAN tag isn't quite right. One could very well have an untagged > ethernet interface, if that's one's choice, and VLAN tagging done > upstream. > > Also, what is meant by "for higher-grade connections..." on P9? > It also seems to me that the whole sentence could be replaced by > something simpler like: "Depending on network design, this can be a > simple VLAN for each Access Node or, one Customer VLAN (C-VLAN) for each > Access Node within a Service VLAN (S-VLAN) construct". > > P9 - "The control plane interactions are transactional in nature and > imply a reliable communication channel to share states." > > Terminology: What is the "communication channel"? Do you mean the ANC > session? > > Not all of the control plane interactions appear to require a > transactional nature. It would seem that we generally want reliable > communication, but not necessarily transactional state for all > interactions eg knowledge of line rate changes is nice to have reliably, > but doesn't require the protocol to offer a transaction which I > associate with the ability to acknowledge/deny and revert to some > previous state or continue with some operation. > Thus, it appears to me that some of the control plane interactions have > a transactional nature, and all of the communication is desired to be > transmitted reliably. > > P9 - "Also, when using the Access Node Control Mechanism for performing > a > reporting action, there is a possibility to integrate this with a > central Policy Management system that keeps track of the different > Subscriber related parameters" > > The type of policy system is really secondary - it's whatever system > that wants to consume the info. Suggest replacing the text by; > "Also, when using the Access Node Control Mechanism for performing a > reporting action, there is a possibility to integrate this with a > subscriber policy system that keeps track of the different subscriber > related parameters" > > P10 - "In deployments using an ATM aggregation network, the ATM PVC on > an > Access Loop connects the Subscriber to a NAS. Based on such > property, in a PPP scenario, the NAS typically includes a NAS-Port-Id > (or NAS-Port in some cases) attribute in RADIUS authentication & > accounting packets sent to the RADIUS server(s). " > > The scenario doesn't necessitate PPP, it's valid for IPoA as well (or > IPoEoA, etc). Also, these are two different radius attributes, and both > are commonly used. > > P15 - "The ANCP MUST be an open protocol, either an existing protocol > endorsed by an appropriate standard body (e.g. IETF) or a new > protocol which will be submitted for standardization to an > appropriate standard body." > > Seems that this requirement is rather obsolete, given that we are in the > IETF trying to define it. > > "The ANCP MUST be transaction-oriented, allowing to reliably share > states between the NAS and the Access Node, and recover from loss > of synchronization (e.g. node or link failure). Transactions MUST > be either fully completed, or rolled-back to the previous state." > > As per my comment above. It's quite clear that not all transactions need > to be rolled-back. Thus ANCP MUST allow for transaction-oriented > processing of selected information exchanges. > Also, it seems that the immediately following requirement already > captures the "recover from loss of synchronisation" characteristic, thus > this is no longer needed here. > > Section 4.2 > > "The ANCP SHOULD have a "boot" sequence allowing to inform the peer > about control capabilities supported by the two peers (Access > Node, NAS) and negotiate a common subset. " > > And > "The ANCP MUST provide a means for the AN and the NAS to perform > capability negotiation. > " > > These two seem to state the same thing, but yet one is a MUST while the > other a SHOULD. IMO, the MUST is more appropriate. > > " o The ANCP SHOULD include a "request/response" transaction-oriented > model for the NAS to communicate control decisions or request > information from the Access Node. If the response is negative, > then the state of the Access Node MUST be unchanged (roll-back)." > > Much has been said about the transactional requirement in the preceding > paragraphs (and I added some more). Shouldn't this requirement be > actually a MUST requirement and furthermore expanded to address that > certain message exchanges are required to be transactional, while others > don't? > > P17 - "The transport protocol used for the Access Node Control Messages > MUST be reliable and scalable." > > The requirement is for ANCP to deliver it's payload info reliably. The > transport protocol could be unreliable and the ANCP protocol could > provide the reliability. > > P17 - "A loss of the Access Node Control Session MUST NOT affect user > connectivity and element operation." > > End user? > > P17 - "For maintenance purpose the Access Node Control Session MUST be > designed in a way that any malfunction of the session is > automatically detected and reported from the Access Node or NAS to > the Element Manager or Network Manager to support the network > operator in troubleshooting the network." > > What has the ANC session design got to do reporting failures? > > P17 - Section 4.4 Access Node Requirements > > This whole section should IMO be redrafted around to reflect the > protocol requirements arising due to various access-node uses, rather > than actual access-node requirements. Also, the use of terms like "DSL > port" would be best avoided if we still want the notion of supporting > other media types. > > P18 - Section 4.4.2 > > We've defined ANCP to be an IP based control protocol between one node > and a controller. IMO this whole section is superfluous, since it > prescribes functionality that is attributed to the way of configuring a > node and largely independent of the actual protocol requirements. Think > it can be removed. > > P18& 19 - Section 4.4.3, 4.4.4 - .6 > > Here we're actually duplicating a protocol requirement as an access node > requirement. Again, all of this section appears to be redundant as far > as the protocol is concerned. If there any protocol requirements, as I > seem to read in sect 4.4.4, then I think we should turn them into such > as opposed to node requirements. > Also the use of the term "link" doesn't quite square up to the > terminology. > > Eg > Current req: The Access Node MUST support an adjacency protocol used to > synchronize states across the link, discover the identity of the > entity at the other end of a link, and detect when it changes. > > Protocol req: The protocol MUST allow the discovery by each end point > the identity of the other end point. > The protocol MUST include a mechanism for synchronising protocol state > information between two end-points. > Etc. > > P19 - Section 4.4.7 > > Again, these are not protocol requirements, at least in their current > form. What *may* be a protocol requirement is actually informing a > controller which issued a command for the change of a setting that is > not administratively allowed, i.e. an appropriate error message. > > P20 - section 4.5 > > Not protocol requirements in their current form - if that some of these > that may have a relation be turned into protocol requirements. The only > one I'm able to see as a potential protocol requirement is the one for > having peer authorization. If we want a node to communicate to only > "authorized nodes" then we need a mechanism for determining such > authorization, or simply assume that the direct configuration of a peer > is sufficient for that peer to be authorized. > > The above comment applies to all subsequent sub-sections of 4.5 > > P27 - Section 7 > > Again, these are node functional not protocol requirements. > > Hope that the above provides some useful input. > > Cheers, > Woj. > > > -----Original Message----- > From: Sven.Ooghe@alcatel.be [mailto:Sven.Ooghe@alcatel.be] > Sent: 13 October 2006 15:59 > To: internet-drafts@ietf.org > Cc: Sanjay Wadhwa; Haag, T; michel.platnic@ecitele.com; Voigt Norbert; > Matthew Bocci; Wojciech Dec (wdec) > Subject: draft-ieft-ancp-framework-00.txt > > Please find below an I-D titled "Framework and Requirements for an > Access Node Control Mechanism in Broadband Multi-Service Networks". > > This draft is based on draft-ooghe-ancp-framework-00.txt, which was > accepted by the ANCP community to be moved to a Working Group document. > It also reflects a few changes/additions resulting from the latest DSL > Forum meeting where this topic was discussed. > > Best regards, > Sven Ooghe > > > > > _______________________________________________ > 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 Fri Oct 27 09:34:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRqL-0008EF-Ld; Fri, 27 Oct 2006 09:33:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRqI-00087x-HI for ancp@ietf.org; Fri, 27 Oct 2006 09:33:50 -0400 Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRq7-000432-Dd for ancp@ietf.org; Fri, 27 Oct 2006 09:33:49 -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 k9RDXfNZ009209 for ; Fri, 27 Oct 2006 15:33:41 +0200 To: ancp@ietf.org X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Matthew.Bocci@alcatel.co.uk Date: Fri, 27 Oct 2006 14:33:26 +0100 X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 10/27/2006 14:33:37 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.4 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Subject: [ANCP] Fw: note the boilerplate change 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 ID authors, please see below. Matthew ----- Forwarded by Matthew BOCCI/GB/ALCATEL on 27/10/2006 14:32 ----- Jari Arkko To int-chairs@ietf.org 27/10/2006 10:25 cc Subject note the boilerplate change -----Original Message----- From: IETF Chair [mailto:chair@ietf.org] Sent: Friday, October 27, 2006 3:20 AM To: IETF Announcement list Subject: Update to Internet-Draft and RFC Boilerplate A small update to BCP 78 was recently approved by the IESG as RFC 4748, to update the boilerplate (i.e., standard legal text) in RFCs and Internet-Drafts to recognize the IETF Trust as a rights holder, instead of ISOC. The actual boilerplate changes are given below this message. Starting as soon as reasonably possible, all authors of Internet-Drafts are requested to use the new boilerplate. The RFC Editor will in any case be inserting it in all RFCs issued from 2006-11-01. (The rights held by ISOC in older RFCs will be administratively transferred to the IETF Trust.) The public ID Nits checker already accepts I-Ds with old or new boilerplate. The Secretariat has started accepting I-Ds with old or new boilerplate XML2RFC version 1.32 will generate the new boilerplate. Users of I-D templates are requested to update them appropriately. http://www.ietf.org/ID-Checklist.html and http://www.ietf.org/ietf/1id-guidelines.html are being updated. Starting December, the public ID Nits checker will issue warnings for old boilerplate. Starting February 2007, the Secretariat will refuse the old boilerplate in Internet-Drafts. We are sorry for the inconvenience, but this change cannot be avoided. IETF Chair IETF Secretariat TOOLS Team -------- Copyright Notice (required for all IETF Documents) (Normally placed at the end of the IETF Document.) NOTE: by convention, the first line of the copyright statement is usually placed near the beginning of each document. This must also be updated. OLD "Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. NEW "Copyright (C) The IETF Trust (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer (required in all IETF Documents) (Normally placed at the end of the IETF Document after the copyright notice.) OLD "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." NEW "This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Exceptions In MIB modules, PIB modules and similar material commonly extracted from IETF Documents, except for material that is being placed under IANA maintenance, the following abbreviated notice shall be included in the body of the material that will be extracted in lieu of the notices otherwise required by Section 5: OLD "Copyright (C) The Internet Society . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." NEW "Copyright (C) The IETF Trust . This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." When the MIB or PIB module is the initial version of a module that is to be maintained by the IANA, the following abbreviated notice shall be included: OLD "Copyright (C) The Internet Society . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." NEW "Copyright (C) The IETF Trust . The initial version of this MIB module was published in RFC XXXX; for full legal notices see the RFC itself. Supplementary information may be available at: http://www.ietf.org/copyrights/ianamib.html." _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp