From wdec@cisco.com Thu Mar 8 01:15:36 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3590221F855F for ; Thu, 8 Mar 2012 01:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.312 X-Spam-Level: X-Spam-Status: No, score=-110.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZeYQy7j99WL for ; Thu, 8 Mar 2012 01:15:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCC621F84A2 for ; Thu, 8 Mar 2012 01:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=830; q=dns/txt; s=iport; t=1331198133; x=1332407733; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=B5Ir7mvzJX0ms3Easxo++ZIcBrGpWUPPTUziyl19VdA=; b=RVZSjvsp1DeoGw9VjOehczql/mkyzwcmUYl87MSU/kmijDHkK28Ul3ya XFQXfx2dTHgOxP5WAo0lYSJ6kjfeHCuPj/neYBDqVCrp0eJucskYi3eK1 wNp+gj2cRumIaSA+0zZXTpALZw4OmVa3PhPIqU72TROv0Ztskc9CeQQdZ M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADN4WE+Q/khL/2dsb2JhbABDtSSBB4IMAQQSASkBTgGBJgEEHBmHZguaEYEnAZ8RiiiDJIMiBIgfjSKQF4JkgVs X-IronPort-AV: E=Sophos;i="4.73,551,1325462400"; d="scan'208";a="131671573" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2012 09:15:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q289FWo0002132 for ; Thu, 8 Mar 2012 09:15:32 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:15:32 +0100 Received: from 10.61.81.197 ([10.61.81.197]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Mar 2012 09:15:31 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 08 Mar 2012 10:12:55 +0100 From: Wojciech Dec To: Message-ID: Thread-Topic: Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz9C6WAzuLFNswrREKtZbYXaFymZA== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 08 Mar 2012 09:15:32.0167 (UTC) FILETIME=[032DCD70:01CCFD0C] Subject: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 09:15:36 -0000 Hello All, The following text has been brought to my attention in: ANCP RFC 6320 under section 3.5.2.1: =20 =B3Once an adjacency has been established, if more than one NAS has established an adjacency to the same partition, then the AN sends an Adjacency Update message to each such NAS to let it know how many established adjacencies the partition currently supports." This text appears to indicate that ANCP supports a single Access Node partition that is controlled/has an adjacency with more than one NAS/controller, which would not be in line with WG conclusions on this topi= c (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), besides covering technical matters such as likely race conditions, etc. Seems like a case to jot down for fixing in an RFC "errata". Regards, Woj. From HaagT@telekom.de Fri Mar 9 00:55:56 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A535521F8606 for ; Fri, 9 Mar 2012 00:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBo7W4AhI1Ks for ; Fri, 9 Mar 2012 00:55:56 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id F272021F8603 for ; Fri, 9 Mar 2012 00:55:36 -0800 (PST) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 09 Mar 2012 09:55:35 +0100 Received: from HE113657.emea1.cds.t-internal.com (10.134.99.17) by HE113443.emea1.cds.t-internal.com (10.134.93.103) with Microsoft SMTP Server (TLS) id 8.3.83.0; Fri, 9 Mar 2012 09:55:34 +0100 Received: from HE111649.emea1.cds.t-internal.com ([169.254.3.110]) by HE113657.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 9 Mar 2012 09:55:34 +0100 From: To: , Date: Fri, 9 Mar 2012 09:55:33 +0100 Thread-Topic: Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz9C6WAzuLFNswrREKtZbYXaFymZAAxixdQ Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 08:55:56 -0000 Woj, all, it seems to me if we have here a different interpretation rather than a nee= d for an errata of RFC6320. IMHO the listed result of a working group discussion belonged to physical o= r logical partitioning. But it was not decided to exclude functionality reg= arding R-37 to R-41 of RFC5158 from protocol work. Please see RFC5158: R-41: The Access Node should be able to establish and = maintain ANCP Adjacencies to redundant controllers. A redundancy use case considers typically a single edge architecture but si= ngle edge means "one service edge" which may consist of two physical boxes = which may be redundant. So in my opinion an errata is not necessary because there is no conflict be= tween Framework and protocol specification. RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 driv= en by redundancy use case. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wo= jciech Dec Gesendet: Donnerstag, 8. M=E4rz 2012 10:13 An: ancp@ietf.org Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 Hello All, The following text has been brought to my attention in: ANCP RFC 6320 under section 3.5.2.1: =B3Once an adjacency has been established, if more than one NAS has established an adjacency to the same partition, then the AN sends an Adjacency Update message to each such NAS to let it know how many established adjacencies the partition currently supports." This text appears to indicate that ANCP supports a single Access Node partition that is controlled/has an adjacency with more than one NAS/controller, which would not be in line with WG conclusions on this topi= c (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), besides covering technical matters such as likely race conditions, etc. Seems like a case to jot down for fixing in an RFC "errata". Regards, Woj. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From wdec@cisco.com Fri Mar 9 01:32:04 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE4F521F85D9 for ; Fri, 9 Mar 2012 01:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.408 X-Spam-Level: X-Spam-Status: No, score=-110.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmFLyZQpJAVF for ; Fri, 9 Mar 2012 01:32:04 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id CF52321F85D5 for ; Fri, 9 Mar 2012 01:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=2833; q=dns/txt; s=iport; t=1331285524; x=1332495124; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=kVjxuPIbs2TRENgn1QBChTN5+L8syWaLw1Q8CLasklE=; b=GQJyKuobhVgnAGg3MTf1lSSGs6hJjkYpOS4GBJU7kgk5g7W1Y2lpF1uA gjUFjlwubQHRseJNWua3rWMqkxVJ6ubqHaMj44YJMCD+D2306HLWxZVIF 7Yy0kRiI3kIfFTm1t2xDiTKcDiWlxsaB0vIyCn9LR0w2/jLO5iXRKvPtv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMrNWU+Q/khR/2dsb2JhbABDtTuBB4IKAQEBAwEBAQEPASkBMRANAQgSLS4fAw4BAQQBEgkZh2MFC5tVAZ52iiiGLgSIII0okBqCZIFTBwE X-IronPort-AV: E=Sophos;i="4.73,557,1325462400"; d="scan'208";a="68063647" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2012 09:32:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q299W2jr023758; Fri, 9 Mar 2012 09:32:02 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 10:32:02 +0100 Received: from 10.61.96.58 ([10.61.96.58]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 09:32:02 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 10:31:59 +0100 From: Wojciech Dec To: , Message-ID: Thread-Topic: AW: Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz9C6WAzuLFNswrREKtZbYXaFymZAAxixdQAAFp+6M= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Mar 2012 09:32:02.0701 (UTC) FILETIME=[7BFF0BD0:01CCFDD7] Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 09:32:04 -0000 Hi Thomas, Ok, but how would that work? Would the ANCP Partition-id be seen as the sam= e to both NASes, and how would one NAS know that it is "the backup" (thus not allowed to say send commands)? There is nothing in the rest of the spec tha= t I can see which addresses this, so while redundancy may have been the intent, it does not appear to be specified to the extent of making it work across the suite of ANCP applications. Or am I missing something? Regards, Woj. On 09/03/2012 09:55, "HaagT@telekom.de" wrote: > Woj, all, > it seems to me if we have here a different interpretation rather than a n= eed > for an errata of RFC6320. >=20 > IMHO the listed result of a working group discussion belonged to physical= or > logical partitioning. But it was not decided to exclude functionality > regarding R-37 to R-41 of RFC5158 from protocol work. >=20 > Please see RFC5158: R-41: The Access Node should be able to establish an= d > maintain ANCP > Adjacencies to redundant controllers. >=20 > A redundancy use case considers typically a single edge architecture but > single edge means "one service edge" which may consist of two physical bo= xes > which may be redundant. >=20 > So in my opinion an errata is not necessary because there is no conflict > between Framework and protocol specification. > RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 dr= iven > by redundancy use case. >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von > Wojciech Dec > Gesendet: Donnerstag, 8. M=E4rz 2012 10:13 > An: ancp@ietf.org > Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 >=20 > Hello All, >=20 > The following text has been brought to my attention in: ANCP RFC 6320 und= er > section 3.5.2.1: >=20 > =B3Once an adjacency has been established, if more than one NAS has > established an adjacency to the same partition, then the AN sends an > Adjacency Update message to each such NAS to let it know how many > established adjacencies the partition currently supports." >=20 > This text appears to indicate that ANCP supports a single Access Node > partition that is controlled/has an adjacency with more than one > NAS/controller, which would not be in line with WG conclusions on this to= pic > (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), > besides covering technical matters such as likely race conditions, etc. >=20 > Seems like a case to jot down for fixing in an RFC "errata". >=20 > Regards, > Woj. >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom.taylor.stds@gmail.com Fri Mar 9 04:20:29 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D5F21F8623 for ; Fri, 9 Mar 2012 04:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.481 X-Spam-Level: X-Spam-Status: No, score=-3.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5eAVaGwmnvL for ; Fri, 9 Mar 2012 04:20:27 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C894B21F85FB for ; Fri, 9 Mar 2012 04:20:27 -0800 (PST) Received: by iazz13 with SMTP id z13so2414642iaz.31 for ; Fri, 09 Mar 2012 04:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=XZKK3oQ/XGxO8sOQh5eDXiy2AfsxyDFOQl2R+FDhIBo=; b=gPhQqZACrTn1imMcux8xzwqMSnwEg7mnOxNaRcyS2UYpLrJ9toTqcli4sB47cAUGqf KFDE8S21IRzvAHtQTyUfc+1wZ9Gcz6WsK9bjkXeCHxLvpsFQASgifb4GgE3ZRIKN1b1N rBq+Xgqg2WTMgG6BVup6Zvh4FxZwy3WWNBVRxQEBd96EIiNm2+Togf08UOIrSynv4CRp EBSueUgtgRaenpA+SG9Qbz8WaAgfJdzj9wkzjTeBkFzfTv5x9ZW6ufLPxIUKOtUbMa9n AXv0dAXlyypeGoHExZo0AnaUpQ+AQyDOPWUB1YOLJ7GhnrrOzojAqaeB7Jqgsn8N1aMY 0meg== Received: by 10.42.19.5 with SMTP id z5mr2531018ica.51.1331295627420; Fri, 09 Mar 2012 04:20:27 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-65-140.tor.primus.ca. [173.206.65.140]) by mx.google.com with ESMTPS id e2sm1335731igp.11.2012.03.09.04.20.25 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 04:20:26 -0800 (PST) Message-ID: <4F59F58B.6050200@gmail.com> Date: Fri, 09 Mar 2012 07:20:27 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Wojciech Dec References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120308-1, 08/03/2012), Outbound message X-Antivirus-Status: Clean Cc: ancp@ietf.org Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:20:29 -0000 I would think the distinction would be by configuration, and maybe that is underspecified.. When we did Megaco we had the concept of a primary controller of a partition and (potentially) multiple secondary controllers. We left it up to implementors to work out the details. Inter-controller communication was not in scope of our work. On 09/03/2012 4:31 AM, Wojciech Dec wrote: > Hi Thomas, > > Ok, but how would that work? Would the ANCP Partition-id be seen as the same > to both NASes, and how would one NAS know that it is "the backup" (thus not > allowed to say send commands)? There is nothing in the rest of the spec that > I can see which addresses this, so while redundancy may have been the > intent, it does not appear to be specified to the extent of making it work > across the suite of ANCP applications. Or am I missing something? > > Regards, > Woj. > > > On 09/03/2012 09:55, "HaagT@telekom.de" wrote: > >> Woj, all, >> it seems to me if we have here a different interpretation rather than a need >> for an errata of RFC6320. >> >> IMHO the listed result of a working group discussion belonged to physical or >> logical partitioning. But it was not decided to exclude functionality >> regarding R-37 to R-41 of RFC5158 from protocol work. >> >> Please see RFC5158: R-41: The Access Node should be able to establish and >> maintain ANCP >> Adjacencies to redundant controllers. >> >> A redundancy use case considers typically a single edge architecture but >> single edge means "one service edge" which may consist of two physical boxes >> which may be redundant. >> >> So in my opinion an errata is not necessary because there is no conflict >> between Framework and protocol specification. >> RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 driven >> by redundancy use case. >> >> Regards >> Thomas >> >> -----Ursprüngliche Nachricht----- >> Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von >> Wojciech Dec >> Gesendet: Donnerstag, 8. März 2012 10:13 >> An: ancp@ietf.org >> Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 >> >> Hello All, >> >> The following text has been brought to my attention in: ANCP RFC 6320 under >> section 3.5.2.1: >> >> ³Once an adjacency has been established, if more than one NAS has >> established an adjacency to the same partition, then the AN sends an >> Adjacency Update message to each such NAS to let it know how many >> established adjacencies the partition currently supports." >> >> This text appears to indicate that ANCP supports a single Access Node >> partition that is controlled/has an adjacency with more than one >> NAS/controller, which would not be in line with WG conclusions on this topic >> (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), >> besides covering technical matters such as likely race conditions, etc. >> >> Seems like a case to jot down for fixing in an RFC "errata". >> >> Regards, >> Woj. >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > From HaagT@telekom.de Fri Mar 9 04:28:52 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F364521F85D9 for ; Fri, 9 Mar 2012 04:28:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8sKqY3xFqzi for ; Fri, 9 Mar 2012 04:28:51 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id D05F921F85D7 for ; Fri, 9 Mar 2012 04:28:50 -0800 (PST) Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 09 Mar 2012 13:28:34 +0100 Received: from HE111649.emea1.cds.t-internal.com ([169.254.3.110]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Fri, 9 Mar 2012 13:28:27 +0100 From: To: , Date: Fri, 9 Mar 2012 13:28:26 +0100 Thread-Topic: AW: Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz9C6WAzuLFNswrREKtZbYXaFymZAAxixdQAAFp+6MABgTE0A== Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:28:52 -0000 Hi Woj, Yes, I guess you're missing the context to TR-147. In RFC6320 is mentioned in section 1: At various points in this document, information flows between the control applications and ANCP are described. The purpose of such descriptions is to clarify the boundary between this specification and, for example, [TR-147]. There is no intention to place limits on the degree to which the control application and the protocol implementation are integrated. If you look to BBF TR-147 in section 5.7 describes redundancy from use case= perspective and section 9.3 R-28 to R-30 provides relevant requirements. Making redundancy work can be performed in concert with TR-147. Basic proto= col features IDs, TLVs can be used. How network element treat a handower and how to organize interchasis commun= ication is out of scope of ANCP because it is implementation specific. But ANCP covers AN-BNG (NAS) communication without making an exception or l= imitation. I see your proposal in making that limitiation by creating an errata. But I= don't think tat this is a good idea by the given arguments. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Wojciech Dec [mailto:wdec@cisco.com] Gesendet: Freitag, 9. M=E4rz 2012 10:32 An: Haag, Thomas; ancp@ietf.org Betreff: Re: AW: Multiple adjacency issue in ANCP spec - RFC6320 Hi Thomas, Ok, but how would that work? Would the ANCP Partition-id be seen as the sam= e to both NASes, and how would one NAS know that it is "the backup" (thus not allowed to say send commands)? There is nothing in the rest of the spec tha= t I can see which addresses this, so while redundancy may have been the intent, it does not appear to be specified to the extent of making it work across the suite of ANCP applications. Or am I missing something? Regards, Woj. On 09/03/2012 09:55, "HaagT@telekom.de" wrote: > Woj, all, > it seems to me if we have here a different interpretation rather than a n= eed > for an errata of RFC6320. > > IMHO the listed result of a working group discussion belonged to physical= or > logical partitioning. But it was not decided to exclude functionality > regarding R-37 to R-41 of RFC5158 from protocol work. > > Please see RFC5158: R-41: The Access Node should be able to establish an= d > maintain ANCP > Adjacencies to redundant controllers. > > A redundancy use case considers typically a single edge architecture but > single edge means "one service edge" which may consist of two physical bo= xes > which may be redundant. > > So in my opinion an errata is not necessary because there is no conflict > between Framework and protocol specification. > RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 dr= iven > by redundancy use case. > > Regards > Thomas > > -----Urspr=FCngliche Nachricht----- > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von > Wojciech Dec > Gesendet: Donnerstag, 8. M=E4rz 2012 10:13 > An: ancp@ietf.org > Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 > > Hello All, > > The following text has been brought to my attention in: ANCP RFC 6320 und= er > section 3.5.2.1: > > =B3Once an adjacency has been established, if more than one NAS has > established an adjacency to the same partition, then the AN sends an > Adjacency Update message to each such NAS to let it know how many > established adjacencies the partition currently supports." > > This text appears to indicate that ANCP supports a single Access Node > partition that is controlled/has an adjacency with more than one > NAS/controller, which would not be in line with WG conclusions on this to= pic > (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), > besides covering technical matters such as likely race conditions, etc. > > Seems like a case to jot down for fixing in an RFC "errata". > > Regards, > Woj. > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From wdec@cisco.com Fri Mar 9 04:59:11 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E0221F85E6 for ; Fri, 9 Mar 2012 04:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.736 X-Spam-Level: X-Spam-Status: No, score=-109.736 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vm9t9Y9+4KYW for ; Fri, 9 Mar 2012 04:59:08 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DF93B21F853C for ; Fri, 9 Mar 2012 04:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=12676; q=dns/txt; s=iport; t=1331297935; x=1332507535; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=7bHBf8sWpeUdX40H6XtR8bj8eL0TMvcGZBu04M8GXIA=; b=UAEy7Oh04W8VM1zBcEjO+y418FkuCwrR1B/ZSePlIY2REiTXyZBKcUSM etdWdMGWXOvdEbcmxaCC7A0NyhOxAgXV5WRQlWN6rq+HTTCin0r8HZjkd 68iRmWi2OKMj5EfbGIbyjmQ+VxQu2sM2aMBaGqltWnqo2kVj2qDcGvFKA w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGD9WU+Q/khM/2dsb2JhbABEgkWxeHSBB4IKAQEBAwEBAQEPASoxCwUNAQgSBicoBh8DDgEBBA4FCRmHYwULm2YBnn2JPHCGLgSIII0piySEeIJkgVMHAQ X-IronPort-AV: E=Sophos;i="4.73,558,1325462400"; d="scan'208,217";a="131825886" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2012 12:58:52 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q29Cwq8o031173; Fri, 9 Mar 2012 12:58:52 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 13:58:52 +0100 Received: from 10.55.82.114 ([10.55.82.114]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 12:58:52 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 13:58:49 +0100 From: Wojciech Dec To: Tom Taylor Message-ID: Thread-Topic: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz97wbp19b565WTSzCD3U8dkzeHVwABVfRK In-Reply-To: <4F59F58B.6050200@gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3414146331_42650877" X-OriginalArrivalTime: 09 Mar 2012 12:58:52.0542 (UTC) FILETIME=[60D681E0:01CCFDF4] Cc: ancp@ietf.org Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 12:59:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3414146331_42650877 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Right, but given that single controllers need to be aware of whether they can act/change state, such a =B3redundant controller=B2 feature would need to be exposed in the protocol (inter controller still being out of scope). The notion of active and standby adjacency would appear to be needed, besides spec info like =B3send/don=B9t send all data for the same partition to both controllers=B2. In short, if you allow for redundant controllers in a standard protocol, it=B9s of little use to then say =B3redundant controllers are left up for specific implementation=B2 =AD this is a standards doc. If redundant controller= s are a proprietary feature, so be it, but in that case the multiple adjacencies per partition are proprietary too. In example terms, we currently appear to have the door open to: controller = A sending mcast command Z, and controller B sending mcast command Y. Each would expect the command to be acted upon, and even in the error codes that an AN could send we do not covey info like =B3sorry, you=B9re not the active controller=B2. Both controllers are following existing standard functionality= . Please let me know how you would envisage controller and access node implementations to deal with this case. -Woj. On 09/03/2012 13:20, "Tom Taylor" wrote: > I would think the distinction would be by configuration, and maybe that > is underspecified.. >=20 > When we did Megaco we had the concept of a primary controller of a > partition and (potentially) multiple secondary controllers. We left it > up to implementors to work out the details. Inter-controller > communication was not in scope of our work. >=20 > On 09/03/2012 4:31 AM, Wojciech Dec wrote: >> > Hi Thomas, >> > >> > Ok, but how would that work? Would the ANCP Partition-id be seen as th= e >> same >> > to both NASes, and how would one NAS know that it is "the backup" (thu= s not >> > allowed to say send commands)? There is nothing in the rest of the spe= c >> that >> > I can see which addresses this, so while redundancy may have been the >> > intent, it does not appear to be specified to the extent of making it = work >> > across the suite of ANCP applications. Or am I missing something? >> > >> > Regards, >> > Woj. >> > >> > >> > On 09/03/2012 09:55, "HaagT@telekom.de" wrote: >> > >>> >> Woj, all, >>> >> it seems to me if we have here a different interpretation rather tha= n a >>> need >>> >> for an errata of RFC6320. >>> >> >>> >> IMHO the listed result of a working group discussion belonged to phy= sical or >>> >> logical partitioning. But it was not decided to exclude functionalit= y >>> >> regarding R-37 to R-41 of RFC5158 from protocol work. >>> >> >>> >> Please see RFC5158: R-41: The Access Node should be able to establi= sh >>> and >>> >> maintain ANCP >>> >> Adjacencies to redundant controllers. >>> >> >>> >> A redundancy use case considers typically a single edge architecture= but >>> >> single edge means "one service edge" which may consist of two physic= al >>> boxes >>> >> which may be redundant. >>> >> >>> >> So in my opinion an errata is not necessary because there is no conf= lict >>> >> between Framework and protocol specification. >>> >> RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC58= 51 >>> driven >>> >> by redundancy use case. >>> >> >>> >> Regards >>> >> Thomas >>> >> >>> >> -----Urspr=FCngliche Nachricht----- >>> >> Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag= von >>> >> Wojciech Dec >>> >> Gesendet: Donnerstag, 8. M=E4rz 2012 10:13 >>> >> An: ancp@ietf.org >>> >> Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 >>> >> >>> >> Hello All, >>> >> >>> >> The following text has been brought to my attention in: ANCP RFC 632= 0 >>> under >>> >> section 3.5.2.1: >>> >> >>> >> =B3Once an adjacency has been established, if more than one NAS has >>> >> established an adjacency to the same partition, then the AN sends an >>> >> Adjacency Update message to each such NAS to let it know how many >>> >> established adjacencies the partition currently supports." >>> >> >>> >> This text appears to indicate that ANCP supports a single Access Nod= e >>> >> partition that is controlled/has an adjacency with more than one >>> >> NAS/controller, which would not be in line with WG conclusions on th= is >>> topic >>> >> (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html)= , >>> >> besides covering technical matters such as likely race conditions, e= tc. >>> >> >>> >> Seems like a case to jot down for fixing in an RFC "errata". >>> >> >>> >> Regards, >>> >> Woj. >>> >> >>> >> _______________________________________________ >>> >> ANCP mailing list >>> >> ANCP@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/ancp >> > >> > _______________________________________________ >> > ANCP mailing list >> > ANCP@ietf.org >> > https://www.ietf.org/mailman/listinfo/ancp >> > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >=20 --B_3414146331_42650877 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 Right, but given that single controllers need to be aware of whether they = can act/change state,  such a “redundant controller” featur= e would need to be exposed in the protocol (inter controller still being out= of scope). The notion of active and standby adjacency would appear to be ne= eded, besides spec info like “send/don’t send all data for the s= ame partition to both controllers”.
In short, if you allow for redundant controllers in a standard protocol, it= ’s of little use to then say “redundant controllers are left up = for specific implementation” – this is a standards doc. If redun= dant controllers are a proprietary feature, so be it, but in that case the m= ultiple adjacencies per partition are proprietary too.

In example terms, we currently appear to have the door open to: controller = A sending mcast command Z, and controller B sending mcast command Y. Each wo= uld expect the command to be acted upon, and even in the error codes that an= AN could send we do not covey info like “sorry, you’re not the = active controller”. Both controllers are following existing standard f= unctionality. Please let me know how you would envisage controller and acces= s node implementations to deal with this case.  

 -Woj.

On 09/03/2012 13:20, "Tom Taylor" <tom.taylor.stds@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I would think the distinction would be by config= uration, and maybe that
is underspecified..

When we did Megaco we had the concept of a primary controller of a
partition and (potentially) multiple secondary controllers. We left it
up to implementors to work out the details. Inter-controller
communication was not in scope of our work.

On 09/03/2012 4:31 AM, Wojciech Dec wrote:
> Hi Thomas,
>
> Ok, but how would that work? Would the ANCP Partition-id be seen as th= e same
> to both NASes, and how would one NAS know that it is "the backup&= quot; (thus not
> allowed to say send commands)? There is nothing in the rest of the spe= c that
> I can see which addresses this, so while redundancy may have been the<= BR> > intent, it does not appear to be specified to the extent of making it = work
> across the suite of ANCP applications. Or am I missing something?
>
> Regards,
> Woj.
>
>
> On 09/03/2012 09:55, "H= aagT@telekom.de"<HaagT@telekom.de>  wrote:
>
>> Woj, all,
>> it seems to me if we have here a different interpretation rather t= han a need
>> for an errata of RFC6320.
>>
>> IMHO the listed result of a working group discussion belonged to p= hysical or
>> logical partitioning. But it was not decided to exclude functional= ity
>> regarding R-37 to R-41 of RFC5158 from protocol work.
>>
>> Please see RFC5158: R-41:  The Access Node should be able to = establish and
>> maintain ANCP
>>            =             &nbs= p;    Adjacencies to redundant controllers.
>>
>> A redundancy use case considers typically a single edge architectu= re but
>> single edge means "one service edge" which may consist o= f two physical boxes
>> which may be redundant.
>>
>> So in my opinion an errata is not necessary because there is no co= nflict
>> between Framework and protocol specification.
>> RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC= 5851 driven
>> by redundancy use case.
>>
>> Regards
>> Thomas
>>
>> -----Ursprüngliche Nachricht-----
>> Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Au= ftrag von
>> Wojciech Dec
>> Gesendet: Donnerstag, 8. März 2012 10:13
>> An: ancp@ietf.org
>> Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 >>
>> Hello All,
>>
>> The following text has been brought to my attention in: ANCP RFC 6= 320 under
>> section 3.5.2.1:
>>
>>   “Once an adjacency has been established, if more= than one NAS has
>> established an adjacency to the same partition, then the AN sends = an
>> Adjacency Update message to each such NAS to    let= it know how many
>> established adjacencies the partition currently supports." >>
>> This text appears to indicate that ANCP supports a single Access N= ode
>> partition that is controlled/has an adjacency with more than one >> NAS/controller, which would not be in line with WG conclusions on = this topic
>> (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html<= /a>),
>> besides covering technical matters such as likely race conditions,= etc.
>>
>> Seems like a case to jot down for fixing in an RFC "errata&qu= ot;.
>>
>> Regards,
>> Woj.
>>
>> _______________________________________________
>> ANCP mailing list
>> ANCP@ietf.org
>> https://www.i= etf.org/mailman/listinfo/ancp
>
> _______________________________________________
> ANCP mailing list
> ANCP@ietf.org
> https://www.ietf.= org/mailman/listinfo/ancp
>
_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/m= ailman/listinfo/ancp

--B_3414146331_42650877-- From tom.taylor.stds@gmail.com Fri Mar 9 05:21:38 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8430921F8642 for ; Fri, 9 Mar 2012 05:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvZBqm08VTa7 for ; Fri, 9 Mar 2012 05:21:37 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62E3721F85D2 for ; Fri, 9 Mar 2012 05:21:37 -0800 (PST) Received: by iazz13 with SMTP id z13so2490026iaz.31 for ; Fri, 09 Mar 2012 05:21:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-antivirus:x-antivirus-status; bh=L+gv6Vb0uSL7QOqErCitC8aCAjsMQuJfJGLw0YXZRxE=; b=gmQG6iWeWIikhQSDO1ZYqsYvpUlgUQ5SUsvg7sj4l4MBZ48EYZqoxbo5taomRThYd2 FLQuzCV2DsHKfCFronpr8h1U+rC0D8EszbzoRXf/GdkPL+DnfDQrvNdEFn9MXn2ZrZCx wLe98dJfTmWTmZtjdt2IMAcWdN6BCe6Qtek6XYnDcOZ6Yb0fbdii0Jcttmad1KFCxK+n 3s6gc5XbP1diUZKkegPRRw0tK5ekzqr+3JI/lUCBGg/b7uQSdTQ9u9ISCO5gqzC68FfB hXWIL+pCEuo/JtGEzREhGAaqFBYhC51m/vc+RGQ3OPNaHdyjCBK+Y/220CMcxD2IWY58 MaSA== Received: by 10.50.184.200 with SMTP id ew8mr3174887igc.1.1331299297087; Fri, 09 Mar 2012 05:21:37 -0800 (PST) Received: from [127.0.0.1] (dsl-173-206-65-140.tor.primus.ca. [173.206.65.140]) by mx.google.com with ESMTPS id pr8sm1918097igb.6.2012.03.09.05.21.35 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 05:21:36 -0800 (PST) Message-ID: <4F5A03E2.5060607@gmail.com> Date: Fri, 09 Mar 2012 08:21:38 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Wojciech Dec References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120308-1, 08/03/2012), Outbound message X-Antivirus-Status: Clean Cc: ancp@ietf.org Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:21:38 -0000 Megaco partitioned per-termination. Translated into ANCP terms, each line belongs to a specific controller. That way there is no conflict. The division between primary and secondary comes with respect to commands affecting the AN as a whole. Agreed that the supporting language just isn't there. On 09/03/2012 7:58 AM, Wojciech Dec wrote: > Right, but given that single controllers need to be aware of whether > they can act/change state, such a “redundant controller” feature would > need to be exposed in the protocol (inter controller still being out of > scope). The notion of active and standby adjacency would appear to be > needed, besides spec info like “send/don’t send all data for the same > partition to both controllers”. > In short, if you allow for redundant controllers in a standard protocol, > it’s of little use to then say “redundant controllers are left up for > specific implementation” – this is a standards doc. If redundant > controllers are a proprietary feature, so be it, but in that case the > multiple adjacencies per partition are proprietary too. > > In example terms, we currently appear to have the door open to: > controller A sending mcast command Z, and controller B sending mcast > command Y. Each would expect the command to be acted upon, and even in > the error codes that an AN could send we do not covey info like “sorry, > you’re not the active controller”. Both controllers are following > existing standard functionality. Please let me know how you would > envisage controller and access node implementations to deal with this case. > > -Woj. > ... From wdec@cisco.com Fri Mar 9 07:27:59 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A3F21F8694 for ; Fri, 9 Mar 2012 07:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.67 X-Spam-Level: X-Spam-Status: No, score=-109.67 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4tsMDkmdxaI for ; Fri, 9 Mar 2012 07:27:58 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9189C21F86CA for ; Fri, 9 Mar 2012 07:27:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=5407; q=dns/txt; s=iport; t=1331306878; x=1332516478; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=w45BwmA2qcF5jp2V5LCkvO2lfO+hajZOVB36ZZJh2b0=; b=GK95RGR/lgKN6KXQR0P0JdjuSCmP7IVySleT4InCfRTJjdL8FMX7BbB2 oIyhmJKw7RKowUUyyqm8WrF1dlNJku5Rh+buEg87iCMHRXoXMN3HT1zNC xs/q5LsCJJnl4tABlGY1KhDoxqrZLeMrrXsVkpOBhAalvy3lpyGypb4kV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAEhWk+Q/khL/2dsb2JhbABDtD50gQeCCgEBAQMBAQEBDwEpATEdAQgSBicuHwMOAQEEARIJGYdjBQucJQGfAooshi4EiCCNKZAcgmSBUwcB X-IronPort-AV: E=Sophos;i="4.73,558,1325462400"; d="scan'208";a="68102034" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 09 Mar 2012 15:27:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q29FRt11028124; Fri, 9 Mar 2012 15:27:55 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 16:27:55 +0100 Received: from 10.55.82.114 ([10.55.82.114]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Fri, 9 Mar 2012 15:27:54 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Fri, 09 Mar 2012 15:01:26 +0100 From: Wojciech Dec To: , Message-ID: Thread-Topic: AW: AW: Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz9C6WAzuLFNswrREKtZbYXaFymZAAxixdQAAFp+6MABgTE0AADZE4Q In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 09 Mar 2012 15:27:55.0277 (UTC) FILETIME=[331F93D0:01CCFE09] Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:27:59 -0000 Hi Thomas, I don't think I missing the context of requirements. What is missing is how the requirements are realized in the protocol along with the specified ANCP applications.=20 At the very least the requirements are not being met by the current protoco= l specification. Feel free to illustrate how the following situation should be handled in a case of controllers A and B both having an adjacency to the same partition (and port).=20 Controller A sends mcast command Z, and controller B sends mcast command Y. Both controllers are following existing standard functionality. Each controller would expect the command to be acted upon, and obtain a response= . In the error codes that an AN could send we do not covey info like =B3sorry, you=B9re backup controller=B2, nor in the adjacency info, etc. Other similar us= e cases, also for port-up and line config apply. Regards, -Woj. On 09/03/2012 13:28, "HaagT@telekom.de" wrote: >=20 > Hi Woj, >=20 > Yes, I guess you're missing the context to TR-147. >=20 > In RFC6320 is mentioned in section 1: >=20 > At various points in this document, information flows between the > control applications and ANCP are described. The purpose of such > descriptions is to clarify the boundary between this specification > and, for example, [TR-147]. There is no intention to place limits on > the degree to which the control application and the protocol > implementation are integrated. >=20 > If you look to BBF TR-147 in section 5.7 describes redundancy from use ca= se > perspective and section 9.3 R-28 to R-30 provides relevant requirements. >=20 > Making redundancy work can be performed in concert with TR-147. Basic pro= tocol > features IDs, TLVs can be used. >=20 > How network element treat a handower and how to organize interchasis > communication is out of scope of ANCP because it is implementation specif= ic. > But ANCP covers AN-BNG (NAS) communication without making an exception or > limitation. > I see your proposal in making that limitiation by creating an errata. But= I > don't think tat this is a good idea by the given arguments. >=20 > Regards > Thomas >=20 > -----Urspr=FCngliche Nachricht----- > Von: Wojciech Dec [mailto:wdec@cisco.com] > Gesendet: Freitag, 9. M=E4rz 2012 10:32 > An: Haag, Thomas; ancp@ietf.org > Betreff: Re: AW: Multiple adjacency issue in ANCP spec - RFC6320 >=20 > Hi Thomas, >=20 > Ok, but how would that work? Would the ANCP Partition-id be seen as the s= ame > to both NASes, and how would one NAS know that it is "the backup" (thus n= ot > allowed to say send commands)? There is nothing in the rest of the spec t= hat > I can see which addresses this, so while redundancy may have been the > intent, it does not appear to be specified to the extent of making it wor= k > across the suite of ANCP applications. Or am I missing something? >=20 > Regards, > Woj. >=20 >=20 > On 09/03/2012 09:55, "HaagT@telekom.de" wrote: >=20 >> Woj, all, >> it seems to me if we have here a different interpretation rather than a = need >> for an errata of RFC6320. >>=20 >> IMHO the listed result of a working group discussion belonged to physica= l or >> logical partitioning. But it was not decided to exclude functionality >> regarding R-37 to R-41 of RFC5158 from protocol work. >>=20 >> Please see RFC5158: R-41: The Access Node should be able to establish a= nd >> maintain ANCP >> Adjacencies to redundant controllers. >>=20 >> A redundancy use case considers typically a single edge architecture but >> single edge means "one service edge" which may consist of two physical b= oxes >> which may be redundant. >>=20 >> So in my opinion an errata is not necessary because there is no conflict >> between Framework and protocol specification. >> RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 d= riven >> by redundancy use case. >>=20 >> Regards >> Thomas >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von >> Wojciech Dec >> Gesendet: Donnerstag, 8. M=E4rz 2012 10:13 >> An: ancp@ietf.org >> Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 >>=20 >> Hello All, >>=20 >> The following text has been brought to my attention in: ANCP RFC 6320 un= der >> section 3.5.2.1: >>=20 >> =B3Once an adjacency has been established, if more than one NAS has >> established an adjacency to the same partition, then the AN sends an >> Adjacency Update message to each such NAS to let it know how many >> established adjacencies the partition currently supports." >>=20 >> This text appears to indicate that ANCP supports a single Access Node >> partition that is controlled/has an adjacency with more than one >> NAS/controller, which would not be in line with WG conclusions on this t= opic >> (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), >> besides covering technical matters such as likely race conditions, etc. >>=20 >> Seems like a case to jot down for fixing in an RFC "errata". >>=20 >> Regards, >> Woj. >>=20 >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp >=20 From wdec@cisco.com Mon Mar 12 10:00:07 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EC6121F87CA for ; Mon, 12 Mar 2012 10:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.345 X-Spam-Level: X-Spam-Status: No, score=-110.345 tagged_above=-999 required=5 tests=[AWL=0.255, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMHt9WPPLq8m for ; Mon, 12 Mar 2012 10:00:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id A44B121F8851 for ; Mon, 12 Mar 2012 10:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=145; q=dns/txt; s=iport; t=1331571606; x=1332781206; h=date:subject:from:to:message-id:mime-version: content-transfer-encoding; bh=RkMLlo6UY3j3LWfvYL8rNHz5s6z1ZGpWJ7z5F8mtq6U=; b=NvJqXQ45XDNwx06lX60tNbedTy8I5W+bZ6ZAIDIrODemFqq6whBTd7J9 XTt80lmC8cA9lo9i2Wj/AEo0drZjhe1Z359Qv4laxfM+LbiQCxmiDTxZz n0xUn/UpTXZP+ibMd0eKeT/lNQKRShqgZQc+RWUnyvQ91viDkh+i7ytf8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAGcrXk+Q/khL/2dsb2JhbABBtWSBB4ILAQQSAScCAU4BgSYBBDWHaJ5YgScBlwGNX4MiBJVMkCOCZA X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="132081934" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 12 Mar 2012 16:59:53 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2CGxrR0020078 for ; Mon, 12 Mar 2012 16:59:53 GMT Received: from xmb-ams-112.cisco.com ([144.254.74.87]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Mar 2012 17:59:53 +0100 Received: from 10.61.96.70 ([10.61.96.70]) by XMB-AMS-112.cisco.com ([144.254.74.87]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Mar 2012 16:59:53 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Mon, 12 Mar 2012 17:59:49 +0100 From: Wojciech Dec To: Message-ID: Thread-Topic: Slots? Thread-Index: Ac0AcYjMj9FZ3QPprk6gqhaJBnVONQ== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2012 16:59:53.0870 (UTC) FILETIME=[8BB34AE0:01CD0071] Subject: [ANCP] Slots? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:00:07 -0000 Hi All, Just a friendly reminder to ask those interested in having any ANCP meeting slots to let Matthew and myself know. Regards, Woj. From matthew.bocci@alcatel-lucent.com Wed Mar 14 07:06:42 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924AA21F87A4 for ; Wed, 14 Mar 2012 07:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.914 X-Spam-Level: X-Spam-Status: No, score=-108.914 tagged_above=-999 required=5 tests=[AWL=1.335, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVY10TY2zOol for ; Wed, 14 Mar 2012 07:06:41 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 745DE21F8749 for ; Wed, 14 Mar 2012 07:06:41 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2EDu4JD016521 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Mar 2012 15:06:28 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 14 Mar 2012 15:05:33 +0100 From: "Bocci, Matthew (Matthew)" To: Wojciech Dec , "ancp@ietf.org" Date: Wed, 14 Mar 2012 15:05:33 +0100 Thread-Topic: [ANCP] Slots? Thread-Index: Ac0B64VnUbSB+nuiQOSt6HDAgzU5QQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [ANCP] Slots? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:06:42 -0000 Folks, Here is what we have so far: 1) WG Status Update - chairs 2) Multicast Extensions draft - draft-ietf-ancp-mc-extensions-06.txt - Tom Taylor Please let us know if there are any further requests. Thanks Matthew On 12/03/2012 16:59, "Wojciech Dec" wrote: >Hi All, > >Just a friendly reminder to ask those interested in having any ANCP >meeting >slots to let Matthew and myself know. > >Regards, >Woj. > >_______________________________________________ >ANCP mailing list >ANCP@ietf.org >https://www.ietf.org/mailman/listinfo/ancp From matthew.bocci@alcatel-lucent.com Wed Mar 14 07:22:53 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B0C21F882C; Wed, 14 Mar 2012 07:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.34 X-Spam-Level: X-Spam-Status: No, score=-106.34 tagged_above=-999 required=5 tests=[AWL=-1.355, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.263, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIm380Z519-C; Wed, 14 Mar 2012 07:22:52 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF1C21F8829; Wed, 14 Mar 2012 07:22:51 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q2EEKMMu032115 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 14 Mar 2012 15:22:46 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 14 Mar 2012 15:22:27 +0100 From: "Bocci, Matthew (Matthew)" To: The IESG Date: Wed, 14 Mar 2012 15:22:25 +0100 Thread-Topic: Request to publish draft-ietf-ancp-pon-02.txt Thread-Index: Ac0B7eH13VcyrQJuS7CabSHNQ5B6wg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CB865A212614Bmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "int-ads@tools.ietf.org" , "draft-ietf-ancp-pon@tools.ietf.org" , "ancp@ietf.org" , "ancp-chairs@tools.ietf.org" Subject: [ANCP] Request to publish draft-ietf-ancp-pon-02.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 14:22:53 -0000 --_000_CB865A212614Bmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please publish draft-ietf-ancp-pon-02.txt A copy of the proto write up is included below. Regards Matthew draft-ietf-ancp-pon-02.txt Document Shepard Write-Up (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Yes, the document has received adequate review. The document has been developed wihtin the WG and reviewed over a period of a number of IETFs. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No specific concerns. There are no IPR disclosures. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) None indicated. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Yes. (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Yes, the references are split appropriately. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? The IANA considerations section exists. There are no requests for IANA allocatons. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The purpose of this document is to provide applicability of the Access Node Control Mechanism, as described in [RFC5851], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS- related, service-related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). This document is a product of the ANCP working group. This document is Informational. Working Group Summary The ANCP working group was originally chartered only to cover DSL access technologies. It's application to PON was only added as a result of this draft being introduced. However, there were no issues with reaching cons= ensus for this change and, indeed, there was significant support within the wo= rking group. Document Quality The document describes the application of an existing technology (ANCP) = to a new access technology type (PON). ANCP is deployed for DSL access netw= orks today, but is sufficiently generic and extensible to be applicable to ot= her access technologies. I do not know of deployments of ANCP for PON. I have no other concerns about the quality of the document. --_000_CB865A212614Bmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please publish draft-iet= f-ancp-pon-02.txt

A copy of the proto write up is = included below.

Regards

M= atthew

draft-ietf-ancp-pon-02.txt
<= br>
Document Shepard Write-Up


=
    (1.a) Who is the Document Shepherd for this document? Ha= s the 
          Document Shepherd = personally reviewed this version of the 
     = ;     document and, in particular, does he or she believe this&nb= sp;
          version is ready for forwa= rding to the IESG for publication? 

   Matth= ew Bocci (matthew.bocci@alcatel-lucent.com)
      =   Yes, I have reviewed the document and I believe it is ready for = ;
        forwarding to the IESG.
<= br>

    (1.b) Has the document had adequ= ate review both from key WG members 
      &n= bsp;   and from key non-WG members? Does the Document Shepherd have&nb= sp;
          any concerns about the dep= th or breadth of the reviews that 
      &nbs= p;   have been performed? 

   =     Yes, the document has received adequate review. The document= has
        been developed wihtin the WG and= reviewed over a period of a number
        o= f IETFs. 


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

       No.

=

    (1.d) Does the Document Shepherd have any= specific concerns or 
          is= sues with this document that the Responsible Area Director 
=           and/or the IESG should be aware of? For = example, perhaps he 
          or s= he is uncomfortable with certain parts of the document, or 
=           has concerns whether there really is a n= eed for it. In any 
          event= , if the WG has discussed those issues and has indicated 
&n= bsp;         that it still wishes to advance the docume= nt, detail those 
          concern= s here. Has an IPR disclosure related to this document 
&nbs= p;         been filed? If so, please include a referenc= e to the 
          disclosure and = summarize the WG discussion and conclusion on 
   =       this issue. 

  &nb= sp;    No specific concerns.  There are no IPR disclosures.<= /div>


    (1.e) How solid is th= e WG consensus behind this document? Does it 
    =       represent the strong concurrence of a few individuals,= with 
          others being silen= t, or does the WG as a whole understand and 
    &= nbsp;     agree with it? 

  &n= bsp;   I am comfortable that the document represents WG consensus and = has
      been reviewed by a reasonable number of = active WG participants. 
    
 = ;   (1.f) Has anyone threatened an appeal or otherwise indicated extre= me 
          discontent? If so, pl= ease summarise the areas of conflict in 
     = ;     separate email messages to the Responsible Area Director. (= It 
          should be in a separa= te email because this questionnaire is 
     =     entered into the ID Tracker.) 

       None indicated.


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

       = ;Yes. 
       
    (= 1.h) Has the document split its references into normative and 
          informative? Are there normative refe= rences to documents that 
         = are not ready for advancement or are otherwise in an unclear 
          state? If such normative references e= xist, what is the 
          strate= gy for their completion? Are there normative references 
&nb= sp;         that are downward references, as described = in [RFC3967]? If 
          so, lis= t these downward references to support the Area 
  &nbs= p;       Director in the Last Call procedure for them [RFC39= 67]. 

      Yes, the reference= s are split appropriately. 


    (1.i) Has the Document Shepherd verified that th= e document IANA 
          consider= ation section exists and is consistent with the body 
 =         of the document? If the document specifies pro= tocol 
          extensions, are re= servations requested in appropriate IANA 
    &nbs= p;     registries? Are the IANA registries clearly identified? If=  
          the document creates a = new registry, does it define the 
       = ;   proposed initial contents of the registry and an allocation <= /div>
          procedure for future registrat= ions? Does it suggest a 
          = reasonable name for the new registry? See [RFC5226]. If the 
          document describes an Expert Review pro= cess has Shepherd 
          confer= red with the Responsible Area Director so that the IESG 
&nb= sp;         can appoint the needed Expert during the IE= SG Evaluation? 

      The IANA= considerations section exists. There are no requests 
 = ;     for IANA allocatons. 


    (1.j) Has the Document Shepherd verified that section= s of the 
          document that a= re written in a formal language, such as XML 
    =       code, BNF rules, MIB definitions, etc., validate corre= ctly in 
          an automated che= cker? 

      There are no sect= ions that use a formal language.


&n= bsp;   (1.k) The IESG approval announcement includes a Document <= /div>
          Announcement Write-Up. Please = provide such a Document 
          = Announcement Write-Up? Recent examples can be found in the
 =         "Action" announcements for approved documents.= The approval 
          announceme= nt contains the following sections: 

Technica= l Summary

    The purpose of this docume= nt is to provide applicability of the
     Access = Node Control Mechanism, as described in [RFC5851],
    =  to PON based broadband access. The need for an Access Node Control
     Mechanism between a Network Access Server (NAS)= and an Access Node
     Complex (a combination of= Optical Line Termination (OLT) and
     Optical N= etwork Termination (ONT) elements) is described in a
   = ;  multi-service reference architecture in order to perform QoS-
=
     related, service-related and Subscriber-related op= erations. The
     Access Node Control Mechanism i= s also extended for interaction
     between compo= nents of the Access Node Complex (OLT and ONT).

&n= bsp;  This document is a product of the ANCP working group.
=
   This document is Informational.

<= /div>
Working Group Summary

   The A= NCP working group was originally chartered only to cover DSL access
   technologies. It's application to PON was only added as a r= esult of this 
   draft being introduced. However,= there were no issues with reaching consensus
   for th= is change and, indeed, there was significant support within the working
   group.
   
Document Quali= ty

   The document describes the applica= tion of an existing technology (ANCP) to
   a new acces= s technology type (PON). ANCP is deployed for DSL access networks
   today, but is sufficiently generic and extensible to be appli= cable to other
   access technologies. I do not know of= deployments of ANCP for PON. 
   I have no other = concerns about the quality of the document.

--_000_CB865A212614Bmatthewboccialcatellucentcom_-- From iesg-secretary@ietf.org Fri Mar 16 12:10:02 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC08621F8619; Fri, 16 Mar 2012 12:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVzq7m-mmU9L; Fri, 16 Mar 2012 12:10:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF921F8618; Fri, 16 Mar 2012 12:10:01 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120316191001.2742.35926.idtracker@ietfa.amsl.com> Date: Fri, 16 Mar 2012 12:10:01 -0700 Cc: ancp@ietf.org Subject: [ANCP] Last Call: (Applicability of Access Node Control Mechanism to PON based Broadband Networks) to Informational RFC X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 19:10:03 -0000 The IESG has received a request from the Access Node Control Protocol WG (ancp) to consider the following document: - 'Applicability of Access Node Control Mechanism to PON based Broadband Networks' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-30. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The purpose of this document is to provide applicability of the Access Node Control Mechanism, as described in [RFC5851], to PON based broadband access. The need for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node Complex (a combination of Optical Line Termination (OLT) and Optical Network Termination (ONT) elements) is described in a multi-service reference architecture in order to perform QoS- related, service-related and Subscriber-related operations. The Access Node Control Mechanism is also extended for interaction between components of the Access Node Complex (OLT and ONT). The Access Node Control mechanism will ensure that the transmission of information between the NAS and Access Node Complex (ANX) and between the OLT and ONT within an ANX does not need to go through distinct element managers but rather uses a direct device-to- device communication and stays on net. This allows for performing access link related operations within those network elements to meet performance objectives. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ancp-pon/ballot/ No IPR declarations have been submitted directly on this I-D. From HaagT@telekom.de Mon Mar 19 04:29:57 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB72321F867C for ; Mon, 19 Mar 2012 04:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSaubDE6VFjs for ; Mon, 19 Mar 2012 04:29:57 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) by ietfa.amsl.com (Postfix) with ESMTP id 473EE21F865B for ; Mon, 19 Mar 2012 04:29:56 -0700 (PDT) Received: from he113443.emea1.cds.t-internal.com ([10.134.93.103]) by tcmail11.telekom.de with ESMTP/TLS/AES128-SHA; 19 Mar 2012 12:29:54 +0100 Received: from HE111649.emea1.cds.t-internal.com ([169.254.3.110]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Mon, 19 Mar 2012 12:29:54 +0100 From: To: , Date: Mon, 19 Mar 2012 12:29:53 +0100 Thread-Topic: AW: AW: Multiple adjacency issue in ANCP spec - RFC6320 Thread-Index: Acz9C6WAzuLFNswrREKtZbYXaFymZAAxixdQAAFp+6MABgTE0AADZE4QAfF+BsA= Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 11:29:57 -0000 Hi Woj, As far as I understood you a protocol may have options to signal peering st= ates and error conditions. O.k. except OAM we currently don't have that for ANCP. But how to deal with it? Do we have alternatives to operate ANCP? I see two options: Option 1: I see one option in updating RFC6320 in a way to extend appropriate error c= odes in order to meet use case requirement rather then reducing use cases. Option 2: Another option may be to let the network element control which control enti= ty is active and which standby and decide on a per adjacency / link decisio= n basis. No change in RFC 6320 necessary. Referring to your example: Controler A is defined being master; Controler B is configured being stand = by controller. In that case controller A is allowed sending a mcast command to AN only. Th= at prevents the case that two messages are sent from two sources to one sin= k. If controller A fails controler B take over controller A. Considering upstream messages e.g. topolocy discovery control B has to igno= re them if controler A is active and vice versa. If controller A and B in a single unit this is a matter of system design. If they are in different units it is assumed to have a inter chasis communi= cation or controled by platform control. But IMHO this is not a task of ANC= P. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Wojciech Dec [mailto:wdec@cisco.com] Gesendet: Freitag, 9. M=E4rz 2012 15:01 An: Haag, Thomas; ancp@ietf.org Betreff: Re: AW: AW: Multiple adjacency issue in ANCP spec - RFC6320 Hi Thomas, I don't think I missing the context of requirements. What is missing is how the requirements are realized in the protocol along with the specified ANCP applications. At the very least the requirements are not being met by the current protoco= l specification. Feel free to illustrate how the following situation should be handled in a case of controllers A and B both having an adjacency to the same partition (and port). Controller A sends mcast command Z, and controller B sends mcast command Y. Both controllers are following existing standard functionality. Each controller would expect the command to be acted upon, and obtain a response= . In the error codes that an AN could send we do not covey info like =B3sorry= , you=B9re backup controller=B2, nor in the adjacency info, etc. Other simila= r use cases, also for port-up and line config apply. Regards, -Woj. On 09/03/2012 13:28, "HaagT@telekom.de" wrote: > > Hi Woj, > > Yes, I guess you're missing the context to TR-147. > > In RFC6320 is mentioned in section 1: > > At various points in this document, information flows between the > control applications and ANCP are described. The purpose of such > descriptions is to clarify the boundary between this specification > and, for example, [TR-147]. There is no intention to place limits on > the degree to which the control application and the protocol > implementation are integrated. > > If you look to BBF TR-147 in section 5.7 describes redundancy from use ca= se > perspective and section 9.3 R-28 to R-30 provides relevant requirements. > > Making redundancy work can be performed in concert with TR-147. Basic pro= tocol > features IDs, TLVs can be used. > > How network element treat a handower and how to organize interchasis > communication is out of scope of ANCP because it is implementation specif= ic. > But ANCP covers AN-BNG (NAS) communication without making an exception or > limitation. > I see your proposal in making that limitiation by creating an errata. But= I > don't think tat this is a good idea by the given arguments. > > Regards > Thomas > > -----Urspr=FCngliche Nachricht----- > Von: Wojciech Dec [mailto:wdec@cisco.com] > Gesendet: Freitag, 9. M=E4rz 2012 10:32 > An: Haag, Thomas; ancp@ietf.org > Betreff: Re: AW: Multiple adjacency issue in ANCP spec - RFC6320 > > Hi Thomas, > > Ok, but how would that work? Would the ANCP Partition-id be seen as the s= ame > to both NASes, and how would one NAS know that it is "the backup" (thus n= ot > allowed to say send commands)? There is nothing in the rest of the spec t= hat > I can see which addresses this, so while redundancy may have been the > intent, it does not appear to be specified to the extent of making it wor= k > across the suite of ANCP applications. Or am I missing something? > > Regards, > Woj. > > > On 09/03/2012 09:55, "HaagT@telekom.de" wrote: > >> Woj, all, >> it seems to me if we have here a different interpretation rather than a = need >> for an errata of RFC6320. >> >> IMHO the listed result of a working group discussion belonged to physica= l or >> logical partitioning. But it was not decided to exclude functionality >> regarding R-37 to R-41 of RFC5158 from protocol work. >> >> Please see RFC5158: R-41: The Access Node should be able to establish a= nd >> maintain ANCP >> Adjacencies to redundant controllers. >> >> A redundancy use case considers typically a single edge architecture but >> single edge means "one service edge" which may consist of two physical b= oxes >> which may be redundant. >> >> So in my opinion an errata is not necessary because there is no conflict >> between Framework and protocol specification. >> RFC 6320 section 3.5.2.1 is fully in line with requirements in RFC5851 d= riven >> by redundancy use case. >> >> Regards >> Thomas >> >> -----Urspr=FCngliche Nachricht----- >> Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von >> Wojciech Dec >> Gesendet: Donnerstag, 8. M=E4rz 2012 10:13 >> An: ancp@ietf.org >> Betreff: [ANCP] Multiple adjacency issue in ANCP spec - RFC6320 >> >> Hello All, >> >> The following text has been brought to my attention in: ANCP RFC 6320 un= der >> section 3.5.2.1: >> >> =B3Once an adjacency has been established, if more than one NAS has >> established an adjacency to the same partition, then the AN sends an >> Adjacency Update message to each such NAS to let it know how many >> established adjacencies the partition currently supports." >> >> This text appears to indicate that ANCP supports a single Access Node >> partition that is controlled/has an adjacency with more than one >> NAS/controller, which would not be in line with WG conclusions on this t= opic >> (eg http://www.ietf.org/mail-archive/web/ancp/current/msg00033.html), >> besides covering technical matters such as likely race conditions, etc. >> >> Seems like a case to jot down for fixing in an RFC "errata". >> >> Regards, >> Woj. >> >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > From ietf-ipr@ietf.org Tue Mar 27 08:31:52 2012 Return-Path: X-Original-To: ancp@ietfa.amsl.com Delivered-To: ancp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8545121E8178; Tue, 27 Mar 2012 08:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxEDLNKH65bO; Tue, 27 Mar 2012 08:31:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB66A21E8154; Tue, 27 Mar 2012 08:31:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: nabil.n.bitar@verizon.com, sanjay.wadhwa@alcatel-lucent.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120327153151.2501.8387.idtracker@ietfa.amsl.com> Date: Tue, 27 Mar 2012 08:31:51 -0700 Cc: jari.arkko@piuha.net, ipr-announce@ietf.org, ancp@ietf.org Subject: [ANCP] IPR Disclosure: Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp-pon-02 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 15:31:52 -0000 Dear Dr. Nabil N. Bitar, Sanjay Wadhwa: An IPR disclosure that pertains to your Internet-Draft entitled "Applicabi= lity of Access Node Control Mechanism to PON based Broadband Networks" (draft-ie= tf- ancp-pon) was submitted to the IETF Secretariat on 2012-03-27 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1734/). The title of the IPR disclosure is "Deutsche Telekom AG's Statement about IPR related to draft-ietf-ancp- pon-02.""); The IETF Secretariat