From ancp-bounces@ietf.org Wed Oct 03 16:00: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 1IdAOZ-0000md-Eu; Wed, 03 Oct 2007 16:00:35 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IdAOX-0000b1-QM for ancp-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 16:00:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAOX-0000Ym-E8; Wed, 03 Oct 2007 16:00:33 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IdAOW-0000fl-AA; Wed, 03 Oct 2007 16:00:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2D8BA32912; Wed, 3 Oct 2007 20:00:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IdAO1-0006ad-Vw; Wed, 03 Oct 2007 16:00: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: Wed, 03 Oct 2007 16:00:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-03.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-03.txt Pages : 38 Date : 2007-10-03 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-03.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-03.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-03.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-10-03155357.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-framework-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-03155357.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 Oct 04 03:07: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 1IdKnV-00058j-UI; Thu, 04 Oct 2007 03:07:01 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IdAID-00060G-1n for ancp-confirm+ok@megatron.ietf.org; Wed, 03 Oct 2007 15:54:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IdAIC-0005z6-N4 for ancp@ietf.org; Wed, 03 Oct 2007 15:54:00 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IdAIC-0004z4-Es for ancp@ietf.org; Wed, 03 Oct 2007 15:54:00 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 4C8912AC69; Wed, 3 Oct 2007 19:54:00 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IdAIC-0004Yw-2S; Wed, 03 Oct 2007 15:54:00 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: sven.ooghe@alcatel-lucent.be From: IETF I-D Submission Tool Message-Id: Date: Wed, 03 Oct 2007 15:54:00 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Thu, 04 Oct 2007 03:07:01 -0400 Cc: ancp@ietf.org Subject: [ANCP] New Version Notification for draft-ietf-ancp-framework-03 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 A new version of I-D, draft-ietf-ancp-framework-03.txt has been successfuly submitted by Sven Ooghe and posted to the IETF repository. Filename: draft-ietf-ancp-framework Revision: 03 Title: Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Creation_date: 2007-10-03 WG ID: ancp Number_of_pages: 38 Abstract: 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. The IETF Secretariat. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Oct 09 10:00: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 1IfFcy-0003in-4Y; Tue, 09 Oct 2007 10:00:04 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IfFcw-0003gW-UP for ancp-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 10:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFcw-0003eS-Ha; Tue, 09 Oct 2007 10:00:02 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfFcv-0000hg-DU; Tue, 09 Oct 2007 10:00:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 5D70332898; Tue, 9 Oct 2007 14:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IfFcv-0002xR-99; Tue, 09 Oct 2007 10:00: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: Tue, 09 Oct 2007 10:00:01 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-security-threats-03.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, H. Tschofenig Filename : draft-ietf-ancp-security-threats-03.txt Pages : 15 Date : 2007-10-09 The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related 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 allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present 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-03.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-03.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-03.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-10-09095257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ancp-security-threats-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ancp-security-threats-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-10-09095257.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 Tue Oct 09 10:46: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 1IfGM9-0000H3-QI; Tue, 09 Oct 2007 10:46:45 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IfFWN-0005bn-CX for ancp-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 09:53:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfFWN-0005b0-2f for ancp@ietf.org; Tue, 09 Oct 2007 09:53:15 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfFWM-0000W0-T0 for ancp@ietf.org; Tue, 09 Oct 2007 09:53:15 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id B7E5426EDE; Tue, 9 Oct 2007 13:52:59 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IfFW7-00034m-LT; Tue, 09 Oct 2007 09:52:59 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: hassnaa.moustafa@orange-ftgroup.com From: IETF I-D Submission Tool Message-Id: Date: Tue, 09 Oct 2007 09:52:59 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Tue, 09 Oct 2007 10:46:45 -0400 Cc: Hannes.Tschofenig@nsn.com, ancp@ietf.org Subject: [ANCP] New Version Notification for draft-ietf-ancp-security-threats-03 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 A new version of I-D, draft-ietf-ancp-security-threats-03.txt has been successfuly submitted by Hassnaa Moustafa and posted to the IETF repository. Filename: draft-ietf-ancp-security-threats Revision: 03 Title: Security Threats and Security Requirements for the Access Node Control Protocol (ANCP) Creation_date: 2007-10-09 WG ID: ancp Number_of_pages: 15 Abstract: The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related 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 allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present 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. The IETF Secretariat. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Tue Oct 09 11:55:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHR5-0003EW-Dk; Tue, 09 Oct 2007 11:55:55 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IfHR3-00037n-S1 for ancp-confirm+ok@megatron.ietf.org; Tue, 09 Oct 2007 11:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfHR3-00037e-IS for ancp@ietf.org; Tue, 09 Oct 2007 11:55:53 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IfHQy-0003SX-GG for ancp@ietf.org; Tue, 09 Oct 2007 11:55:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,249,1188802800"; d="scan'208";a="533020071" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 09 Oct 2007 08:55:48 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l99FtlKC026898 for ; Tue, 9 Oct 2007 08:55:47 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l99FtllD014847 for ; Tue, 9 Oct 2007 15:55:47 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Oct 2007 08:55:46 -0700 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, 9 Oct 2007 08:55:50 -0700 Message-ID: <48214755113BB04F84D958B4F0DE261C0475D0E9@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft section 4 and 5 have basically the same title Thread-Index: AcgKg0/xjgVwGtOvTrSiUWc5LA5//wAB3DAw From: "Philippe Champagne (pchamp)" To: X-OriginalArrivalTime: 09 Oct 2007 15:55:46.0895 (UTC) FILETIME=[DB2D7DF0:01C80A8C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=844; t=1191945347; x=1192809347; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pchamp@cisco.com; z=From:=20=22Philippe=20Champagne=20(pchamp)=22=20 |Subject:=20Draft=20section=204=20and=205=20have=20basically=20the=20same =20title |Sender:=20; bh=Hqv8BnpWl6XZmo2e9jvuuRkggZoEm3XLDZOpLTZw940=; b=NRbBsX6gdW3CVlWym9MezTzkeAjvr3ktyxC9GR2MGMVa6Px0uv2tiVHm9vbbHZ79GTW/hGl7 zcvGtmCkI7otz4/jzrg7nvDaEjZUCx+sBj0orqjQHb9n1F1Ch8GPao3t; Authentication-Results: sj-dkim-8; header.From=pchamp@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [ANCP] Draft section 4 and 5 have basically the same title 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 Just a quick suggestion: The ancp protocol draft section 4 & 5 have title that can barely be distinguished from one another. http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-01.txt Currently they are: 4 Access Node Control Protocol=20 and 5 Access Node Control Protocol (ANCP) I would recommend perhaps something like: 4 Access Node Control Procotol (ANCP) description and requirements And 5 ANCP implementation details Or something along those lines Another point, for quick reference, I think it is better when the title refers to the acronym so that it can be quickly referenced, or at least forms it. Access Node Control Protocol (ANCP) in Broadband Networks Not major but might as well mention it while I bring up the other point about section 4 + 5 :-) Thanks Phil Champagne _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Oct 12 04:46:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgG9w-000766-PI; Fri, 12 Oct 2007 04:46:16 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1IgG9v-0006wA-I2 for ancp-confirm+ok@megatron.ietf.org; Fri, 12 Oct 2007 04:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IgG9u-0006qU-Pm for ancp@ietf.org; Fri, 12 Oct 2007 04:46:14 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IgG9o-0002Kr-FG for ancp@ietf.org; Fri, 12 Oct 2007 04:46:14 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP for ancp@ietf.org; Fri, 12 Oct 2007 10:45:35 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 12 Oct 2007 10:45:35 +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 Date: Fri, 12 Oct 2007 10:45:34 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C0E241A@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for clarification in the ancp-protocol draft Thread-Index: AcgMrChBkkuoC2zcQtqm7TlHQuWxsQ== From: "Freudenberger, Markus" To: X-OriginalArrivalTime: 12 Oct 2007 08:45:35.0061 (UTC) FILETIME=[415D7050:01C80CAC] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: "Langhammer, Michael" , "Haag, T" , "Busser, M" Subject: [ANCP] Proposal for clarification in the ancp-protocol 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: , Errors-To: ancp-bounces@ietf.org Hello All, I suggest to add the following into section 5.4.4 "OAM Extensions" to = clarify/refine the meaning of some return codes. ****************** Original text in draft-ietf-ancp-protocol-01 - begin = ****************** 0x500 : Specified access line does not exist.=20 0x501 : Loopback test timed out.=20 0x502 : Reserved=20 0x503 : DSL line status showtime.=20 0x504 : DSL line status idle.=20 0x505 : DSL line status silent.=20 0x506 : DSL line status training.=20 0x507 : DSL line integrity error.=20 0x508 : DSLAM resource not available.=20 0x509 : Invalid test parameter. ****************** Original text in draft-ietf-ancp-protocol-01 - end = ****************** ****************** Changed text in draft-ietf-ancp-protocol-01 - begin = ****************** 0x500 : Specified access line does not exist.=20 0x501 : Loopback test timed out.=20 0x502 : Reserved=20 0x503 : DSL line status showtime (Line is synchronised, L0 = state).=20 0x504 : DSL line status idle (Line not synchronised, port = administrative "down", L3 state).=20 0x505 : DSL line status silent (Line not synchronised, port = administrative "up", no CPE connected, L3 state).=20 0x506 : DSL line status training (Line is synchronizing, = G.994.1, handshake procedure active).=20 0x507 : DSL line integrity error.=20 0x508 : DSLAM resource not available.=20 0x509 : Invalid test parameter. ****************** Changed text in draft-ietf-ancp-protocol-01 - end = ****************** Any Comments? Regards Markus Freudenberger=20 T-Systems Enterprise Services GmbH Systems Integration Telco Project & Design Line of Business Networks & Processes Technology Consultant Deutsche-Telekom-Allee 7, D-64295 Darmstadt +49 6151 937-3679 (Phone)=20 +49 6151 937-19875 (Fax)=20 +49 521 5224 5816 (PC-Fax)=20 E-Mail: mailto:markus.freudenberger@t-systems.com=20 Internet: http://t-systems.com T-Systems Enterprise Services GmbH Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, Katrin = Horstmann, Ulrich Kemp, Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 Sitz der Gesellschaft: Frankfurt am Main WEEE-Reg.-Nr. DE87523644 *Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG Notice: This transmittal and/or attachments may be privileged or = confidential. If you are not the intended recipient, you are hereby = notified that you have received this transmittal in error; any review, = dissemination, or copying is strictly prohibited. If you received this = transmittal in error, please notify us immediately by reply and = immediately delete this message and all its attachments. Thank you. T-Systems - Business flexibility _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Oct 28 20:32:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImIXw-0006v5-1o; Sun, 28 Oct 2007 20:32:00 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ImIXv-0006uw-In for ancp-confirm+ok@megatron.ietf.org; Sun, 28 Oct 2007 20:31:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImIXu-0006uN-OF for ancp@ietf.org; Sun, 28 Oct 2007 20:31:58 -0400 Received: from exprod7og102.obsmtp.com ([64.18.2.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImIXo-0002CH-7b for ancp@ietf.org; Sun, 28 Oct 2007 20:31:58 -0400 Received: from source ([66.129.224.36]) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP; Sun, 28 Oct 2007 17:31:16 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 17:30:59 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [ANCP] Proposal for clarification in the ancp-protocol draft Date: Sun, 28 Oct 2007 20:30:56 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43622@proton.jnpr.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C0E241A@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposal for clarification in the ancp-protocol draft Thread-Index: AcgMrChBkkuoC2zcQtqm7TlHQuWxsQNFIe/A From: "Sanjay Wadhwa" To: "Freudenberger, Markus" , X-OriginalArrivalTime: 29 Oct 2007 00:30:59.0240 (UTC) FILETIME=[FA384280:01C819C2] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7e267523e0685e5aa2dbbdde4b659686 Cc: "Langhammer, Michael" , "Haag, T" , "Busser, M" 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="===============1469295239==" Errors-To: ancp-bounces@ietf.org This is a multi-part message in MIME format. --===============1469295239== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C819C2.F8D3688D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C819C2.F8D3688D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Markus We can either add explicit clarification as you suggest or add = references to G.994.1, G.993.2 (Annexe D) and G.Lite for more on DSL = line states (which result in these status codes) in section 5.44. I am = fine with either approach, but would like to hear what others have to = say. Regards -Sanjay ps. Slight mods (indicated inline) to your sugggested text. >-----Original Message----- >From: Freudenberger, Markus [ = = mailto:Markus.Freudenberger@t-systems.com] >Sent: Friday, October 12, 2007 4:46 AM >To: ancp@ietf.org >Cc: Langhammer, Michael; Haag,T; Busser, M >Subject: [ANCP] Proposal for clarification in the ancp-protocol draft > > >Hello All, > >I suggest to add the following into section 5.4.4 "OAM >Extensions" to clarify/refine the meaning of some return codes. > >****************** Original text in >draft-ietf-ancp-protocol-01 - begin ****************** > > 0x500 : Specified access line does not exist. > > 0x501 : Loopback test timed out. > > 0x502 : Reserved > > 0x503 : DSL line status showtime. > > 0x504 : DSL line status idle. > > 0x505 : DSL line status silent. > > 0x506 : DSL line status training. > > 0x507 : DSL line integrity error. > > 0x508 : DSLAM resource not available. > > 0x509 : Invalid test parameter. > >****************** Original text in >draft-ietf-ancp-protocol-01 - end ****************** > > >****************** Changed text in draft-ietf-ancp-protocol-01 >- begin ****************** > > 0x500 : Specified access line does not exist. > > 0x501 : Loopback test timed out. > > 0x502 : Reserved > > 0x503 : DSL line status showtime : Line is synchronised, = Power state L0 ( full ON). > > 0x504 : DSL line status idle : Line not = synchronised, port administrative "down", Power state L3 (no transmit = signal) > > 0x505 : DSL line status silent : Line not = synchronised, port administrative "up", no CPE connected, Power state L3 = (no transmit signal). > > 0x506 : DSL line status training (Line is synchronizing, = G.994.1, handshake procedure active). > > 0x507 : DSL line integrity error. > > 0x508 : DSLAM resource not available. > > 0x509 : Invalid test parameter. > >****************** Changed text in draft-ietf-ancp-protocol-01 >- end ****************** > >Any Comments? > >Regards >Markus Freudenberger > >T-Systems Enterprise Services GmbH >Systems Integration >Telco Project & Design >Line of Business Networks & Processes >Technology Consultant >Deutsche-Telekom-Allee 7, D-64295 Darmstadt >+49 6151 937-3679 (Phone) >+49 6151 937-19875 (Fax) >+49 521 5224 5816 (PC-Fax) >E-Mail: = mailto:markus.freudenberger@t-systems.com >Internet: http://t-systems.com > >T-Systems Enterprise Services GmbH >Aufsichtsrat: Ren=E9 Obermann (Vorsitzender) >Executive Committee: Helmut Binder, Albert Henn, Olaf Heyden*, >Katrin Horstmann, Ulrich Kemp, >Wilfried Peters*, Dr. Herbert Schaaff*, Zvezdana Seeger* >Handelsregister: Amtsgericht Frankfurt am Main HRB 55933 >Sitz der Gesellschaft: Frankfurt am Main >WEEE-Reg.-Nr. DE87523644 >*Gesch=E4ftsf=FChrer gem. =A7 35 GmbHG > >Notice: This transmittal and/or attachments may be privileged >or confidential. If you are not the intended recipient, you >are hereby notified that you have received this transmittal in >error; any review, dissemination, or copying is strictly >prohibited. If you received this transmittal in error, please >notify us immediately by reply and immediately delete this >message and all its attachments. Thank you. >T-Systems - Business flexibility > > > > >_______________________________________________ >ANCP mailing list >ANCP@ietf.org > = https://www1.ietf.org/mailman/listinfo/ancp >=20 ------_=_NextPart_001_01C819C2.F8D3688D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Markus
  We can either add explicit = clarification as=20 you suggest or add references to G.994.1, G.993.2 (Annexe D) and G.Lite = for more=20 on DSL line states (which result in these status codes) in section 5.44. =  I=20 am fine with either approach, but would like to hear what others have to = say.

Regards
-Sanjay

ps. Slight mods (indicated inline) = to your=20 sugggested text.


>-----Original Message-----
>From:=20 Freudenberger, Markus [mailto:Markus.Freudenberger@t-systems.com]
>Sent: Friday, October 12, 2007 4:46 AM
>To:=20 ancp@ietf.org
>Cc: Langhammer, Michael; Haag,T; Busser, = M
>Subject:=20 [ANCP] Proposal for clarification in the ancp-protocol=20 draft
>
>
>Hello All,
>
>I suggest to add = the=20 following into section 5.4.4 "OAM
>Extensions" to clarify/refine = the=20 meaning of some return codes.
>
>****************** Original = text=20 in
>draft-ietf-ancp-protocol-01 - begin=20 ******************
>
>      &nb= sp;   =20 0x500 : Specified access line does not=20 exist.
>
>        &nb= sp; =20 0x501 : Loopback test timed=20 out.
>
>         = ; =20 0x502 :=20 Reserved
>
>        &= nbsp; =20 0x503 : DSL line status=20 showtime.
>
>        =   =20 0x504 : DSL line status=20 idle.
>
>        &nbs= p; =20 0x505 : DSL line status=20 silent.
>
>        &n= bsp; =20 0x506 : DSL line status=20 training.
>
>        =   =20 0x507 : DSL line integrity=20 error.
>
>        &nb= sp; =20 0x508 : DSLAM resource not=20 available.
>
>        = ;  =20 0x509 : Invalid test parameter.
>
>****************** = Original text=20 in
>draft-ietf-ancp-protocol-01 - end=20 ******************
>
>
>****************** Changed = text in=20 draft-ietf-ancp-protocol-01
>- begin=20 ******************
>
>      &nb= sp;   =20 0x500 : Specified access line does not=20 exist.
>
>        &nb= sp; =20 0x501 : Loopback test timed=20 out.
>
>         = ; =20 0x502 :=20 Reserved
>
>        &= nbsp; =20 0x503 : DSL line status showtime    : Line is = synchronised, Power state L0 ( full=20 ON).
>
>       &nbs= p;  =20 0x504 : DSL line status=20 idle           &nb= sp;   =20 : Line not synchronised, port administrative "down", Power=20 state L3 (no transmit=20 signal)
>
>       &= nbsp;  =20 0x505 : DSL line status=20 silent           &= nbsp; =20 : Line not synchronised, port administrative "up", no CPE connected, = Power state L3 (no transmit = signal).
>
>       =    =20 0x506 : DSL line status training    (Line is = synchronizing,=20 G.994.1, handshake procedure=20 active).
>
>        &= nbsp; =20 0x507 : DSL line integrity=20 error.
>
>        &nb= sp; =20 0x508 : DSLAM resource not=20 available.
>
>        = ;  =20 0x509 : Invalid test parameter.
>
>****************** = Changed text=20 in draft-ietf-ancp-protocol-01
>- end=20 ******************
>
>Any=20 Comments?
>
>Regards
>Markus=20 Freudenberger
>
>T-Systems Enterprise Services = GmbH
>Systems=20 Integration
>Telco Project & Design
>Line of Business = Networks=20 & Processes
>Technology = Consultant
>Deutsche-Telekom-Allee 7,=20 D-64295 Darmstadt
>+49 6151 937-3679 (Phone)
>+49 6151 = 937-19875=20 (Fax)
>+49 521 5224 5816 (PC-Fax)
>E-Mail: mailto:markus.freudenberger@t-systems.com
>Internet: http://t-systems.com
>
>T-Systems=20 Enterprise Services GmbH
>Aufsichtsrat: Ren=E9 Obermann=20 (Vorsitzender)
>Executive Committee: Helmut Binder, Albert Henn, = Olaf=20 Heyden*,
>Katrin Horstmann, Ulrich Kemp,
>Wilfried Peters*, = Dr.=20 Herbert Schaaff*, Zvezdana Seeger*
>Handelsregister: Amtsgericht = Frankfurt=20 am Main HRB 55933
>Sitz der Gesellschaft: Frankfurt am=20 Main
>WEEE-Reg.-Nr. DE87523644
>*Gesch=E4ftsf=FChrer gem. = =A7 35=20 GmbHG
>
>Notice: This transmittal and/or attachments may be=20 privileged
>or confidential. If you are not the intended = recipient,=20 you
>are hereby notified that you have received this transmittal=20 in
>error; any review, dissemination, or copying is=20 strictly
>prohibited. If you received this transmittal in error,=20 please
>notify us immediately by reply and immediately delete=20 this
>message and all its attachments. Thank you.
>T-Systems = -=20 Business=20 flexibility
>
>
>
>
>______________________= _________________________
>ANCP=20 mailing list
>ANCP@ietf.org
>https://www1.ietf.org/mailman/listinfo/ancp
>

------_=_NextPart_001_01C819C2.F8D3688D-- --===============1469295239== 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 --===============1469295239==-- From ancp-bounces@ietf.org Sun Oct 28 22:36: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 1ImKUH-00045O-9X; Sun, 28 Oct 2007 22:36:21 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ImKUF-00045H-P1 for ancp-confirm+ok@megatron.ietf.org; Sun, 28 Oct 2007 22:36:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImKUF-000451-FT for ancp@ietf.org; Sun, 28 Oct 2007 22:36:19 -0400 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ImKU7-00085Y-4y for ancp@ietf.org; Sun, 28 Oct 2007 22:36:17 -0400 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Sun, 28 Oct 2007 19:34:34 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 28 Oct 2007 19:32:56 -0700 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] Draft section 4 and 5 have basically the same title Date: Sun, 28 Oct 2007 22:32:53 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43623@proton.jnpr.net> In-Reply-To: <48214755113BB04F84D958B4F0DE261C0475D0E9@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft section 4 and 5 have basically the same title Thread-Index: AcgKg0/xjgVwGtOvTrSiUWc5LA5//wAB3DAwA9HKa4A= From: "Sanjay Wadhwa" To: "Philippe Champagne (pchamp)" , X-OriginalArrivalTime: 29 Oct 2007 02:32:56.0565 (UTC) FILETIME=[03AF7250:01C819D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: ancp-bounces@ietf.org Hi Philipe Good catch :). I will change the titles for section 4 and 5 in the next rev on lines of your suggested text (section 5 should probably say "GSMPv3 extensions for ANCP", which is what it covers).=20 Thanks -Sanjay >-----Original Message----- >From: Philippe Champagne (pchamp) [mailto:pchamp@cisco.com] >Sent: Tuesday, October 09, 2007 11:56 AM >To: ancp@ietf.org >Subject: [ANCP] Draft section 4 and 5 have basically the same title > > > >Just a quick suggestion: > >The ancp protocol draft section 4 & 5 have title that can barely be >distinguished from one another. > > http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-01.txt > >Currently they are: >4 Access Node Control Protocol=20 >and >5 Access Node Control Protocol (ANCP) > > >I would recommend perhaps something like: > > >4 Access Node Control Procotol (ANCP) description and requirements >And >5 ANCP implementation details > >Or something along those lines > > >Another point, for quick reference, I think it is better when the title >refers to the acronym so that it can be quickly referenced, or at least >forms it. >Access Node Control Protocol (ANCP) in Broadband Networks >Not major but might as well mention it while I bring up the other point >about section 4 + 5 :-) > > >Thanks >Phil Champagne > > >_______________________________________________ >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 Sun Oct 28 23:06:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImKxF-00087f-Om; Sun, 28 Oct 2007 23:06:17 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ImKxD-0007fh-Rg for ancp-confirm+ok@megatron.ietf.org; Sun, 28 Oct 2007 23:06:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImKxD-00037f-80 for ancp@ietf.org; Sun, 28 Oct 2007 23:06:15 -0400 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImKwX-0005jd-AE for ancp@ietf.org; Sun, 28 Oct 2007 23:05:33 -0400 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sun, 28 Oct 2007 20:05:17 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 20:04:19 -0700 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 Date: Sun, 28 Oct 2007 23:04:16 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43624@proton.jnpr.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1C21E202@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Link bonding Thread-Index: Acf67i11ZVg9/1twSYWI90SdyP9OFAAhFvEQB5hv9CA= From: "Sanjay Wadhwa" To: "Haag, T" , X-OriginalArrivalTime: 29 Oct 2007 03:04:19.0608 (UTC) FILETIME=[66110180:01C819D8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [ANCP] RE: Link bonding 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 Thomas Thanks for the feedback. You are correct in that there is no explicit = dependency in ANCP on DHCP opt-82 or PPPoE tags inserted by the = intermediate agent. However, the BNG has to correlate ACI present in = ANCP to the subscriber (e.g. to adjust its QoS to the learnt DSL sync = rate). The ACI could be statically configured on the BNG for the = subscriber, or could be learnt from DHCP opt-82 or PPPoE tag inserted by = the AN (intermediate agent). In either case, BNG transparently does an = "exact match" with the ACI received in ANCP, for subscriber correlation = (without the need for interpreting it). This should be true for bonded = or un-bonded links.=20 The mention in my original mail below was simply to emphasize the need = for AN to use "logical addressing" (for ACI) in case of bonded links, = both in ANCP and in DHCP opt-82 or PPPoE tag.=20 As mentioned in the last IETF meeting, I intend to add a sub-section on = link bonding in the next rev of the draft (based on my original mail in = this thread below). Other than your feedback, I haven't received any = other comments, and assume we are ok with it. Regards -Sanjay =20 =20 >-----Original Message----- >From: Haag, T [mailto:Thomas.Haag@t-systems.com] >Sent: Thursday, September 20, 2007 6:46 AM >To: ancp@ietf.org >Cc: norbert.voigt@nsn.com; Sanjay Wadhwa >Subject: AW: Link bonding > > >All, > >considering link bonding (ITU-T G.998.2 (EFM bonding) and ANCP=20 >is very welcome but I would like to recommend not combine DHCP=20 >Option 82 or PPPoE intermediate function issues with that use case.=20 > >I think these are two separate issues which may be combined=20 >but not necessarily needed to be combined. From an operator's=20 >standpoint ANCP protocol issues should be considered stand=20 >alone for link bonding without PPPoE or DHCP because for=20 >products using bonded links PPP or DHCP is not mandatory.=20 > >Regards > >Thomas > >-----Urspr=FCngliche Nachricht----- >Von: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 >Gesendet: Mittwoch, 19. September 2007 20:53 >An: ancp@ietf.org >Cc: Haag, Thomas; norbert.voigt@nsn.com >Betreff: Link bonding > >All =20 > I would like to get some feedback on requirements for ANCP=20 >to support link bonding e.g.as defined in ITU-T G.998.2 (EFM=20 >bonding). At a high level it seems the AN should report the=20 >aggregate rate for the bonded links to the BNG. If an existing=20 >link in the bundle goes down or a new link in the bundle is=20 >added, the AN should report this to the BNG as a change in the=20 >downstream and upstream rate. In case of regular un-bonded=20 >link, the ACI that is used for addressing a local-loop has a=20 >default syntax that carries=20 >AN-name/slot/port/vpi.vci or vlan. In case of link bonding, I=20 >suppose the AN should use "logical addressing" for the bonded=20 >link when constructing the ACI (inserted in DHCP opt82/pppoe=20 >IA tags, and ANCP). BNG would transparently correlate the rate=20 >received in ANCP messages to subscriber's interface based on=20 >ACI and adjust its traffic-shaping accordingly. The overhead=20 >due to (variable sized) fragmentation on the bonded link=20 >somehow needs to be accounted for on the BNG to calculate the=20 >effective rate of the local-loop. This is dependent on the=20 >packet sizes, and the framgentation scheme used on the AN. A=20 >very simplistic solution could be for the AN to report a fixed=20 >overhead to the BNG for fragmentation. > >Do we see other implications of bonding on the=20 >topology-discovery/adaptive-rate use case ? > >Thanks >-Sanjay > =20 > _______________________________________________ ANCP mailing list ANCP@ietf.org https://www1.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Oct 29 03:00:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImObO-000514-Gq; Mon, 29 Oct 2007 02:59:58 -0400 Received: from ancp by megatron.ietf.org with local (Exim 4.43) id 1ImObM-0004zC-Tv for ancp-confirm+ok@megatron.ietf.org; Mon, 29 Oct 2007 02:59:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ImObI-0004uM-4o for ancp@ietf.org; Mon, 29 Oct 2007 02:59:52 -0400 Received: from exprod7og107.obsmtp.com ([64.18.2.167]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ImObC-0004NV-Qq for ancp@ietf.org; Mon, 29 Oct 2007 02:59:47 -0400 Received: from source ([66.129.224.36]) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP; Sun, 28 Oct 2007 23:59:41 PDT Received: from proton.jnpr.net ([10.10.2.37]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Oct 2007 23:59:27 -0700 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] comments on draft-ietf-ancp-protocol-01 Date: Mon, 29 Oct 2007 02:59:25 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C280AB43627@proton.jnpr.net> In-Reply-To: <46D27B70.3060201@alcatel-lucent.be> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] comments on draft-ietf-ancp-protocol-01 Thread-Index: Acfoeu8V8SDP+3uHQMWX8DpFFQJYxAxe17Cw From: "Sanjay Wadhwa" To: "Stefaan DE CNODDER" , X-OriginalArrivalTime: 29 Oct 2007 06:59:27.0832 (UTC) FILETIME=[3F392580:01C819F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff 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: , Errors-To: ancp-bounces@ietf.org Hi Stefaan Thanks for the comments. I think this fell through and most likely didn't get a response earlier. Picking it now (responses inline).=20 Regards -Sanjay >-----Original Message----- >From: Stefaan DE CNODDER [mailto:stefaan.de_cnodder@alcatel-lucent.be] >Sent: Monday, August 27, 2007 3:21 AM >To: ancp@ietf.org >Subject: [ANCP] comments on draft-ietf-ancp-protocol-01 > > > >Hi, > >I have a number of comments on draft-ietf-ancp-protocol-01: > >1) There are some inconsistencies in terminology with the framework >document: The framework talks about CPE and HGW while the protocol >draft uses the terms DSL modem, RG, and subscriber devices (see fig.1). > Best to allign with the framework document. Also in section 4.5, >second paragraph the term CPE is used while this is called the HGW in >the framework document and in the framework, CPE means something else. Agreed, we will allign with the framework draft. >2) although the draft is not anymore based on >draft-ietf-gsmp-v3-base-spec but on RFC 3292 instead, it is still using >a number of extensions defined in that draft, which do not make sense >anymore: Far as I can see, nothing below impacts existing protocol operation. However, some of the changes/additions will make the spec better. Where ever it makes sense, we will consider changing/clarifying in the next rev. >2a) Tech type in section 5.4.1.1: tech type 1-4 were defined in >draft-ietf-gsmp but not in RFC 3292 so it makes no sense in saying that >these are already in use by other technologies. Just make them >reserved. Also tech type 0xff is not in use by the base spec (which is >RFC 3292). We know for a fact that type 1-4 have been reserved for use by other technologies (such as L2 switching). I don't see a drawback in explicitly calling it out. >2b) Message format on page 24: The "block length" field was defined in >draft-ietf-gsmp but not in RFC 3292. Since this field is only 1 byte >and not sufficient for ANCP, the ANCP protocol draft defines a new >length field of 2 bytes. Since the GSMP draft does not exist anymore, >it makes no sense in keeping the original 1-byte "block length" field. >Better to call this 1-byte field now "Reserved" This shouldn't have any impact on existing implementations. If there are no objections, we can change the field to be called "reserved" in the next rev. >2c) The X-Function field on page 32 is not used by ANCP and is also not >defined by RFC 3292. It looks better to me to use the original GSMP >message format in this case by using a 2 byte Function field. This could be of use in the future to pass any "function" specific data. 1 byte for the main function field seems sufficient. We would prefer to leave this alone. >2d) Like the message on page 24, also the message format on page 32 has >a 1-byte Block length field that is better renamed to "Reserved". Same comment as 2b. >3) Section 5.2 says that the pType field should be set to 0. Is this >also the case when partitions are used? The framework mentions >partitions and I believe the protocols spec should support=20 >partitions as >well. We need to allow setting the pType appropriately (including non-zero) to control partition-ID assignment as specified in the GSMPv3 RFC. =20 >4) Section 5.3: ANCP should be extensible to support multiple >technologies but I do not see how the capability message can=20 >be extended >with multiple technologies because it looks that only 1 techtype can be >put in the message. Is it the intention that when there is a second >technogoly, then there are 2 independent capability=20 >negotiations (with 2 >different messages? This comment does not apply to other messages >because for instance in a PORT UP, there will always only be 1=20 >technology. Not sure this is an issue. Capability TLVs are carried in the adjacency message. Adjacency is between BNG and AN (or a partition on an AN). We are stipulating an AN (or partition on AN) to pertain to a particular technology type, which seems reasonable (and is typical). >5) Related to bulk transaction messages: > >5a) For the bulk transaction message, what should be the result if 1=20 >message fails? I guess the whole bulk message would fail but=20 >is there a=20 >specific code for it? Each message specific response in the bulk transaction message would contain individual code and result field to signify success or failure for that message (same as what would have been sent for each message if there was no bulking). Individual failure is not construed as a failure of the bulk transaction message.=20 > >5b) can PORT UP or DOWN messages also be part of a bulk transaction?=20 >And what about OAM? I believe the bulk transaction is only for Line=20 >configuration messages? Port up or down messages can also be part of bulk transaction. >6) For line configuration, an unknown TLV is to be ignored. Would it=20 >not be better for these TLVs to have a result field per TLV such that=20 >the NAS knows which configuration is done, and which not? For PORT UP=20 >it is not relevant because the AN does not have to know what=20 >the NAS is=20 >doing with the information but for line configuration this=20 >looks different. Ideally whatever has been successfully set should be exposed via the MIB (and made visible to the EMS).=20 However, the port-mgmt messages can request a response. For an unknown TLV (which is silently ignored on the AN), we can set an appropriate error code, and the response message can contain the unknown TLV (reflected back). If there is agreement, this can be added. >7) action 0x8 defined in section 5.4.3 is already in use by RFC 3292 Good catch. We will need to change this in the draft. >8) The IANA considerations section looks incomplete to me: > >8a) Besides of defining new numbers for Tech-type, ..., also a=20 >complete=20 >new name space has to be defined and maintained by IANA. Yes. A value ("DSL") and type (number =3D 0x05) needs to be reserved. >8b) the name spaces for result field and code field should be modified=20 >because ANCP is changing the length of these fields, and hence=20 >also the=20 >numbers that can be assigned for it. The name spaces "failure=20 >response=20 >message" and "Result type" have to be redefined. Yes, the result and code values need to be reserved with IANA. Whatever is defined in the RFC fits the size for the result field as defined in the darft, and we will attempt to retain those values. Same for the code. >8c) 0x81 failure code to be assigned by IANA, also the OAM codes. Yes, these need to be added to IANA consideration section explicitly (section 5.4.4 does call out for reserving the OAM codes with IANA).=20 > >regards, >Stefaan > > > >_______________________________________________ >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