From tom111.taylor@bell.net Tue Apr 5 09:40:08 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AA613A6960 for ; Tue, 5 Apr 2011 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.511 X-Spam-Level: X-Spam-Status: No, score=-100.511 tagged_above=-999 required=5 tests=[AWL=-1.285, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4dz-dkU2mjR for ; Tue, 5 Apr 2011 09:40:07 -0700 (PDT) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id 7BDB53A695F for ; Tue, 5 Apr 2011 09:40:07 -0700 (PDT) Received: from BLU0-SMTP38 ([65.55.111.73]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 09:41:50 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP38.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 5 Apr 2011 09:41:50 -0700 Date: Tue, 5 Apr 2011 12:41:49 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Apr 2011 16:41:50.0479 (UTC) FILETIME=[5CAC71F0:01CBF3B0] Subject: [ANCP] Multiple NAS controlling one AN partition? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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, 05 Apr 2011 16:40:08 -0000 I am in the process of copying over the RFC 3292 adjacency procedures so as to make the ANCP base protocol document independent of RFC 3292. Section 11.5 of RFC 3292 (translated to ANCP context) gives procedures for allowing multiple NAS to control one AN partition. Does ANCP need this capability? Tom Taylor From tom111.taylor@bell.net Wed Apr 6 06:08:20 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E1928C0F6 for ; Wed, 6 Apr 2011 06:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.29 X-Spam-Level: X-Spam-Status: No, score=-101.29 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ank+yFOL4WC for ; Wed, 6 Apr 2011 06:08:19 -0700 (PDT) Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by core3.amsl.com (Postfix) with ESMTP id 7690028C0EA for ; Wed, 6 Apr 2011 06:08:19 -0700 (PDT) Received: from BLU0-SMTP62 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 06:10:03 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP62.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 06:10:02 -0700 Date: Wed, 6 Apr 2011 09:10:02 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ancp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2011 13:10:02.0991 (UTC) FILETIME=[F0D567F0:01CBF45B] Subject: Re: [ANCP] Multiple NAS controlling one AN partition? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 13:08:20 -0000 Just to make the implications of this capability clear: it could be used for load balancing or hot standby. How the NASs coordinate is out of scope of RFC 3292. But if we include it, we also have to include the Adjacency Update message in our specification. That message is an Event message rather than an adjacency message, so it has the usual header including Result and Code. If no one speaks up, I will use our new bit allocation for those two fields (4 bits for Result, 12 Code instead of the 8 bits each in RFC 3292). On 05/04/2011 12:41 PM, Tom Taylor wrote: > I am in the process of copying over the RFC 3292 adjacency procedures so > as to make the ANCP base protocol document independent of RFC 3292. > Section 11.5 of RFC 3292 (translated to ANCP context) gives procedures > for allowing multiple NAS to control one AN partition. Does ANCP need > this capability? > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > From tom111.taylor@bell.net Wed Apr 6 08:51:20 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D9973A6874 for ; Wed, 6 Apr 2011 08:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.377 X-Spam-Level: X-Spam-Status: No, score=-101.377 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mpc3zb2HXCnL for ; Wed, 6 Apr 2011 08:51:19 -0700 (PDT) Received: from blu0-omc2-s36.blu0.hotmail.com (blu0-omc2-s36.blu0.hotmail.com [65.55.111.111]) by core3.amsl.com (Postfix) with ESMTP id 25BBF3A6819 for ; Wed, 6 Apr 2011 08:51:19 -0700 (PDT) Received: from BLU0-SMTP26 ([65.55.111.73]) by blu0-omc2-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 08:53:03 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP26.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 6 Apr 2011 08:53:02 -0700 Date: Wed, 6 Apr 2011 11:53:02 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: ancp@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Apr 2011 15:53:02.0396 (UTC) FILETIME=[B5D02FC0:01CBF472] Subject: Re: [ANCP] Multiple NAS controlling one AN partition? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 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, 06 Apr 2011 15:51:20 -0000 I hate to be a pest on this, but if no one has implemented the Adjacency Update message in ANCP yet, it would be nice to be able to truncate it, dropping the last 4+ words since they are unused. Here is the message format shown in RFC 3292: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type | Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port Session Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Event Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |x|S|x|x| | +-+-+-+-+ Label | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Nothing of this after Length is actually used by the Adjacency Update message. Of course, if implementations are written to expect the full Event message format for Event messages, we are stuck with the excess baggage, but until I hear otherwise, I am going to assume that the ANCP Adjacency Update message has the format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Message Type |Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ That is, it consists of the ANCP general message header alone. Tom Taylor On 06/04/2011 9:10 AM, Tom Taylor wrote: > Just to make the implications of this capability clear: it could be used > for load balancing or hot standby. How the NASs coordinate is out of > scope of RFC 3292. But if we include it, we also have to include the > Adjacency Update message in our specification. That message is an Event > message rather than an adjacency message, so it has the usual header > including Result and Code. If no one speaks up, I will use our new bit > allocation for those two fields (4 bits for Result, 12 Code instead of > the 8 bits each in RFC 3292). > > On 05/04/2011 12:41 PM, Tom Taylor wrote: >> I am in the process of copying over the RFC 3292 adjacency procedures so >> as to make the ANCP base protocol document independent of RFC 3292. >> Section 11.5 of RFC 3292 (translated to ANCP context) gives procedures >> for allowing multiple NAS to control one AN partition. Does ANCP need >> this capability? >> >> Tom Taylor >> _______________________________________________ >> 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 tom111.taylor@bell.net Tue Apr 12 15:10:37 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0D6D5E0809 for ; Tue, 12 Apr 2011 15:10:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.937 X-Spam-Level: X-Spam-Status: No, score=-99.937 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pcneHuudthz for ; Tue, 12 Apr 2011 15:10:36 -0700 (PDT) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfc.amsl.com (Postfix) with ESMTP id 4B659E079B for ; Tue, 12 Apr 2011 15:10:36 -0700 (PDT) Received: from BLU0-SMTP33 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:10:36 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP33.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 15:10:35 -0700 Date: Tue, 12 Apr 2011 18:10:37 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Apr 2011 22:10:35.0161 (UTC) FILETIME=[72645090:01CBF95E] Subject: [ANCP] A problem with the GSMPv3 state machine 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, 12 Apr 2011 22:10:37 -0000 Actually, there are a couple of problems, but I've imposed a solution for one of them. The one I'm concerned about has to do with a case where the NAS proposes a Partition ID value in a SYN message (PType=1 and Partition ID is non-zero). Section 11.3 of RFC 3292 indicates that the AN can reject this (e.g., because that partition number is already assigned) by sending an RSTACK with non-zero values of PType and Partition ID -- for example, by copying these fields from the SYN. The problem arises because, having sent the SYN, the NAS may enter SYNSENT state if it hasn't received a SYN in turn. According to the instructions for handling a packet arrival event in section 11.2, RSTACKs are ignored in SYNSENT state. I think the solution is that instead of sending an RSTACK, the AN sends a SYN of its own if it hasn't already, either denying the use of partitions (PType=0) or assigning a different partition number (PType=2). Is there ever an occasion where the NAS instead of the AN would find a particular Partition ID value unacceptable? Tom Taylor From wdec@cisco.com Tue Apr 12 23:53:19 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4446FE0674 for ; Tue, 12 Apr 2011 23:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.374 X-Spam-Level: X-Spam-Status: No, score=-109.374 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhTHEcZDTX1c for ; Tue, 12 Apr 2011 23:53:18 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 4FE64E067E for ; Tue, 12 Apr 2011 23:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1422; q=dns/txt; s=iport; t=1302677598; x=1303887198; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=6VOS5u9V3YXHsZh8sKL2UGscKtpSZHpCB2yn+5R1ewc=; b=lrFKWs75VSuJup4jqxxSP5A6DieZGbwBHvLCra8nlkMRW7GeSHB0OhXU ztlAFAMv5AWL6AAJ7t6DCAXigu7vA+7KAhyQED6w2oSKvoZ3KNR+BkSrJ Fng/x1Y3dvh8BuuN8ZQNh6NnwkyKym/WI2KX2Fw46bd6SpsLzjQAgKnb1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcLAEdHpU2Q/khLgWdsb2JhbAA+pUkUAQEWJiWIep5OnQWFbgSNbIN2 X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="25496808" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 06:53:17 +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 p3D6rHGW013601; Wed, 13 Apr 2011 06:53:17 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 08:53:17 +0200 Received: from 10.55.215.34 ([10.55.215.34]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Wed, 13 Apr 2011 06:53:17 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Tue, 12 Apr 2011 21:20:56 +0200 From: Wojciech Dec To: Tom Taylor , Message-ID: Thread-Topic: [ANCP] Multiple NAS controlling one AN partition? Thread-Index: Acv5Rr8jcb5WpNq2ukyHMUaKyAmBKg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Apr 2011 06:53:17.0455 (UTC) FILETIME=[77C699F0:01CBF9A7] Subject: Re: [ANCP] Multiple NAS controlling one AN partition? 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, 13 Apr 2011 06:53:19 -0000 FYI This was the topic of some previous WG discussions: http://www.ietf.org/mail-archive/web/ancp/current/msg00779.html -Woj. On 06/04/2011 14:10, "Tom Taylor" wrote: > Just to make the implications of this capability clear: it could be used > for load balancing or hot standby. How the NASs coordinate is out of > scope of RFC 3292. But if we include it, we also have to include the > Adjacency Update message in our specification. That message is an Event > message rather than an adjacency message, so it has the usual header > including Result and Code. If no one speaks up, I will use our new bit > allocation for those two fields (4 bits for Result, 12 Code instead of > the 8 bits each in RFC 3292). > > On 05/04/2011 12:41 PM, Tom Taylor wrote: >> I am in the process of copying over the RFC 3292 adjacency procedures so >> as to make the ANCP base protocol document independent of RFC 3292. >> Section 11.5 of RFC 3292 (translated to ANCP context) gives procedures >> for allowing multiple NAS to control one AN partition. Does ANCP need >> this capability? >> >> Tom Taylor >> _______________________________________________ >> 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 tom111.taylor@bell.net Wed Apr 13 14:01:05 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9A6C3E0897 for ; Wed, 13 Apr 2011 14:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.582 X-Spam-Level: X-Spam-Status: No, score=-99.582 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_40=-0.185, MSGID_FROM_MTA_HEADER=0.803, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbm4eRhsM-ul for ; Wed, 13 Apr 2011 14:01:05 -0700 (PDT) Received: from blu0-omc2-s16.blu0.hotmail.com (blu0-omc2-s16.blu0.hotmail.com [65.55.111.91]) by ietfc.amsl.com (Postfix) with ESMTP id 121CBE0891 for ; Wed, 13 Apr 2011 14:01:04 -0700 (PDT) Received: from BLU0-SMTP78 ([65.55.111.71]) by blu0-omc2-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 14:01:04 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP78.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 14:01:04 -0700 Date: Wed, 13 Apr 2011 17:01:06 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Apr 2011 21:01:04.0150 (UTC) FILETIME=[E6B04B60:01CBFA1D] Subject: [ANCP] "Invalid partition ID" can't happen 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, 13 Apr 2011 21:01:05 -0000 I've come to the realization that it is impossible to encounter the error "Invalid partition ID" in the context of an established adjacency, so Code value 7 is not valid. My reasoning is as follows: -- once an adjacency has been established, the only way an AN or NAS can know which partition a message is destined for is through the combination of the TCP session in which it is received and the Partition ID -- if an invalid partition ID is received, the AN or NAS will perceive it as a non-adjacency protocol message directed to an adjacency that has not been established -- in accordance with the general rules of the protocol, this message will be silently dropped. I am assuming that it is permissible to carry multiple adjacencies over one TCP session in the general case. I will delete the description of Code 7 unless someone points out an error in my understanding of the situation. Tom Taylor From tom111.taylor@bell.net Thu Apr 14 15:51:39 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C7CAE07E0 for ; Thu, 14 Apr 2011 15:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.759 X-Spam-Level: X-Spam-Status: No, score=-99.759 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_20=-0.74, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fX5+AxMPYP8m for ; Thu, 14 Apr 2011 15:51:39 -0700 (PDT) Received: from blu0-omc2-s19.blu0.hotmail.com (blu0-omc2-s19.blu0.hotmail.com [65.55.111.94]) by ietfc.amsl.com (Postfix) with ESMTP id 076E5E07DC for ; Thu, 14 Apr 2011 15:51:38 -0700 (PDT) Received: from BLU0-SMTP10 ([65.55.111.73]) by blu0-omc2-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 15:51:38 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP10.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 14 Apr 2011 15:51:38 -0700 Date: Thu, 14 Apr 2011 18:51:35 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2011 22:51:38.0097 (UTC) FILETIME=[833E0610:01CBFAF6] Subject: [ANCP] Language tags for text fields 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, 14 Apr 2011 22:51:39 -0000 One of the IESG comments when reviewing the base protocol spec was that text fields meant for human consumption need a language tag. To give you a concrete example, a UTF-8 blob of text in the China-Japan-Korea (CJK) range probably has to be tagged with a country code (zh for Chinese), possibly with an extended language subtag (zh-yue for Cantonese), and possibly with a script subtag. I'm no expert here, just trying to work up an example. The main message is that language tags are encoded with characters in the US-ASCII range x00-FF (hence fit in UTF-8), and are of variable length. My proposal to meet the IESG requirement is this: -- the leading characters of the text field consist of the language tag -- the language tag is terminated by a suitable character, say ":" -- the text itself follows -- the length of the text field (bytes) is equal to the length of the language tag, plus 1 for the delimiter, plus the length of the text to be presented. Any objections? This applies specifically to the diagnostic message in the Status-Info TLV. Tom Taylor From tom111.taylor@bell.net Fri Apr 15 06:58:44 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 574B1E071E for ; Fri, 15 Apr 2011 06:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.422 X-Spam-Level: X-Spam-Status: No, score=-99.422 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u2gxLFEB2Fum for ; Fri, 15 Apr 2011 06:58:43 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfc.amsl.com (Postfix) with ESMTP id 61F9AE0700 for ; Fri, 15 Apr 2011 06:58:43 -0700 (PDT) Received: from BLU0-SMTP4 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 06:58:43 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.15] ([64.231.151.226]) by BLU0-SMTP4.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 06:58:42 -0700 Date: Fri, 15 Apr 2011 09:58:40 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2011 13:58:42.0675 (UTC) FILETIME=[3AD19430:01CBFB75] Subject: [ANCP] Message TLV? 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, 15 Apr 2011 13:58:44 -0000 Maybe this is ovekill, but one possible alternative for the language tag issue is to create a new TLV type, the Message TLV. This would incorporate the language tag in its structure in visble fashion. It would also allow multilingual messaging, with a different Message TLV instance for each of the languages presented. I imagine this goes well beyond the requirements, but someone may want to comment. Tom Taylor From tom111.taylor@bell.net Fri Apr 15 14:30:45 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 86096E0674 for ; Fri, 15 Apr 2011 14:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=1.119, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQ1dMIj64HJS for ; Fri, 15 Apr 2011 14:30:45 -0700 (PDT) Received: from blu0-omc2-s33.blu0.hotmail.com (blu0-omc2-s33.blu0.hotmail.com [65.55.111.108]) by ietfc.amsl.com (Postfix) with ESMTP id 072C6E066A for ; Fri, 15 Apr 2011 14:30:44 -0700 (PDT) Received: from BLU0-SMTP70 ([65.55.111.73]) by blu0-omc2-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 14:30:45 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP70.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 14:30:44 -0700 Date: Fri, 15 Apr 2011 17:30:42 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2011 21:30:44.0777 (UTC) FILETIME=[60D9E990:01CBFBB4] Cc: Mykyta Yevstifeyev Subject: [ANCP] Criteria for additions to ANCP IANA registries 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, 15 Apr 2011 21:30:45 -0000 Mykyta Yevstifev quite properly pointed out off-list that we have not specified the criteria by which additions may be made to our ANCP registries, per RFC 5226. Below is the list of registries we are creating, and my proposal for criteria. A brief reminder of what those criteria imply is appended. We could also split numbering ranges and have different criteria for different pieces. ANCP Message Types: Standards Action ANCP Error Codes: Specification Required ANCP Function Codes: Standards Action ANCP Technology Types: Specification Required ANCP Command Codes: Standards Action ANCP TLV Types: Specification Required ANCP Capabilities: Standards Action GSMP/ANCP Versions: Standards Action The complete set of possible criteria listed in RFC 5226, roughly in increasing order of strictness, is: - Private Use - Experimental Use - Hierarchical Allocation - First Come First Served - Expert Review - Specification Required -- any publicly and persistently available specification will do - RFC Required -- could be individual stream, but has to be IETF - IETF Review -- has to be WG or AD-sponsored - Standards Action -- has to be Standards Track - IESG Approval -- exceptional, no document necessarily required So what I've proposed above is that any organization can define an ANCP Error Code, Technology Type, or TLV Type (subject to criteria for documentation and expert review), but the rest needs Standards-track documents. Tom Taylor From Internet-Drafts@ietf.org Mon Apr 18 18:15:03 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D51DEE0753; Mon, 18 Apr 2011 18:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.765 X-Spam-Level: X-Spam-Status: No, score=-102.765 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlrkyToJI4D3; Mon, 18 Apr 2011 18:15:02 -0700 (PDT) Received: from ietfc.amsl.com (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5E5D6E0710; Mon, 18 Apr 2011 18:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110419011502.28048.66374.idtracker@ietfc.amsl.com> Date: Mon, 18 Apr 2011 18:15:02 -0700 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-16.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: Tue, 19 Apr 2011 01:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-16.txt Pages : 83 Date : 2011-04-18 This document describes the Access Node Control Protocol (ANCP). ANCP operates 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. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ancp-protocol-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-18180528.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Mon Apr 18 18:15:52 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 058D7E06B6 for ; Mon, 18 Apr 2011 18:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.366 X-Spam-Level: X-Spam-Status: No, score=-101.366 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-dVIDHprR7Q for ; Mon, 18 Apr 2011 18:15:51 -0700 (PDT) Received: from blu0-omc2-s21.blu0.hotmail.com (blu0-omc2-s21.blu0.hotmail.com [65.55.111.96]) by ietfc.amsl.com (Postfix) with ESMTP id 77970E0692 for ; Mon, 18 Apr 2011 18:15:48 -0700 (PDT) Received: from BLU0-SMTP74 ([65.55.111.72]) by blu0-omc2-s21.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 18:15:48 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP74.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 18:15:47 -0700 Date: Mon, 18 Apr 2011 21:15:47 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2011 01:15:47.0730 (UTC) FILETIME=[507A4720:01CBFE2F] Subject: [ANCP] Fwd: New Version Notification for draft-ietf-ancp-protocol-16 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, 19 Apr 2011 01:15:52 -0000 An update to the ANCP base protocol draft has been submitted. The general outline of the changes required is on my Prague slides, at http://www.ietf.org/proceedings/80/slides/ancp-1.pdf. This covers the major part of the story, but there were a number of detailed editorial and occasionally technical changes. I'll provide a section-by-section analysis tomorrow. Apologies to the rest of the authorial team by submitting this three hours earlier than I said I would, but I need the sleep :) Tom Taylor -------- Original Message -------- Subject: New Version Notification for draft-ietf-ancp-protocol-16 Date: Mon, 18 Apr 2011 18:05:28 -0700 (PDT) From: IETF I-D Submission Tool To: tom111.taylor@bell.net CC: sanjay.wadhwa@alcatel-lucent.com,jmoisand@juniper.net,haagt@telekom.de,norbert.voigt@nsn.com A new version of I-D, draft-ietf-ancp-protocol-16.txt has been successfully submitted by Tom Taylor and posted to the IETF repository. Filename: draft-ietf-ancp-protocol Revision: 16 Title: Protocol for Access Node Control Mechanism in Broadband Networks Creation_date: 2011-04-18 WG ID: ancp Number_of_pages: 83 Abstract: This document describes the Access Node Control Protocol (ANCP). ANCP operates 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. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. The IETF Secretariat. From tom111.taylor@bell.net Tue Apr 19 10:35:27 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0E04CE07EC for ; Tue, 19 Apr 2011 10:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.096 X-Spam-Level: X-Spam-Status: No, score=-100.096 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaP3+-RBloGp for ; Tue, 19 Apr 2011 10:35:26 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfc.amsl.com (Postfix) with ESMTP id 57B2FE078B for ; Tue, 19 Apr 2011 10:35:26 -0700 (PDT) Received: from BLU0-SMTP68 ([65.55.111.73]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 10:35:25 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP68.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 10:35:26 -0700 Date: Tue, 19 Apr 2011 13:35:24 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2011 17:35:26.0200 (UTC) FILETIME=[2B2D0780:01CBFEB8] Subject: [ANCP] Fate of connection state after loss of synchronization detected 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, 19 Apr 2011 17:35:27 -0000 The current text in the ANCP protocol draft says that if loss of synchronization is detected, all connection state is immediately cleaned up. I am wondering if this just slipped in without prper consideration. Section 11.4 of RFC 3292 says just the opposite, that connection state is held until resynchronization is achieved and then is handled according to the value of PFlag. Which behaviour does the WG favour? The RFC 3292 behaviour seems to offer more flexibility and certainly a better subscriber experience, as I see it. If there are no comments I propose that we update the document to use the RFC 3292 procedure. Tom Taylor From tom111.taylor@bell.net Tue Apr 19 15:56:20 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 28E3CE06E2 for ; Tue, 19 Apr 2011 15:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.336 X-Spam-Level: X-Spam-Status: No, score=-101.336 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akhtC6KDfkEt for ; Tue, 19 Apr 2011 15:56:18 -0700 (PDT) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by ietfc.amsl.com (Postfix) with ESMTP id 6655AE0660 for ; Tue, 19 Apr 2011 15:56:18 -0700 (PDT) Received: from BLU0-SMTP54 ([65.55.111.71]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 15:56:18 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP54.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 15:56:17 -0700 Date: Tue, 19 Apr 2011 18:56:17 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Apr 2011 22:56:17.0870 (UTC) FILETIME=[FE10BEE0:01CBFEE4] Subject: [ANCP] Guided tour of changes from -15 to -16 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, 19 Apr 2011 22:56:20 -0000 Here is a section by section tour of the changes to satisfy IESG comments. Items introduced by NOTE are technical decisions that need particular review. I spotted some basically editorial changes I'd like to make before the document goes forward. These are noted as "To do" items. I'll submit a new version after the WG has had a chance to comment. Section 1 - removed GSMPv3-related text - added Section 1.1 Historical Note - removed note on version 3.1 -> 3.2. See note on Section 3.1 below. - removed note on "must", "should", "may" requirements language in old Section 1.1 Requirements Language. We agreed in Prague to use narrative descriptions for the relationship between the ANCP agent and the control application. In some spots I simply removed the text, in other places, truned it into narrative. Section 3 - removed GSMPv3-related text Section 3.1 - removed GSMPv3-related text. As agreed in Prague, we are going forward with Version only. The initial version is 50 (0x32), which means no change in the bits on the wire from what we had before. Section 3.2 - added IPsec + IKEv2 to the indicated transport stack, with a pointer forward to Security Considerations for more detail. - removed GSMPv3-related text - clarified that use of destination port 6068 on the NAS was mandatory, as agreed in Prague - added units (bytes) for Length Section 3.5 - removed GSMPv3-related text Section 3.5.1 - removed GSMPv3-related text - merged Version/Sub-version back into Version, with an indication that this is the key field for distinguishing ANCP from GSMPv3 on the wire - gave a complete description of all of the fields. Version, Timer, and Partition need ANCP-specific text. The other fields leading up to the capability-related stuff are basically copied from RFC 3292 Section 11.1. - added a description of the Adjacency Update message. NOTE: this is truncated from the format shown in Section 9 of RFC 3292, since I got no objections from the list. Please review this decision. - added a description of all of the fields - editorial: gave length of the Identifier and Lenght fields in bits. To do in this section in the next version: -- capitalize an instance of "timer" in the description of the Timer field -- add text to the description of the Partition ID indicating that it is negotiated by the adjacency protocol. The AN has the final decision, but will consider a request from the NAS. The value MUST be 0 if no partition is supported, and non-zero otherwise. Section 3.5.2 Completely rewritten, folding in the negotiation procedures we had in the old text, except for differences in negotiation of Partition ID taken from Section 11.3 of RFC 3292. - removed text talking about the dialogue between the ANCP agent and the control application Section 3.5.2.1 New text. The description of the use of Adjacency Update here corresponds to the description in Section 11.5 of RFC 3292. NOTE: this is the only description of the procedure currently in the text, since I am not sure it will actually be implemented. If it will be, a more formal description should probably be added in a later section. The description does not currently include RFC 3292's warning that controller implementations without controller entity synchronisation SHOULD NOT use multiple controllers with a single switch partition. Comments welcome. Sections 3.5.2.2 and 3.5.2.2.1 - mostly copied from RFC 3292 Sections 11.2 and 11.2.1 - replaced "Update peer identification" procedure with "Record adjacency state", which is specified in detail as part of the procedure for receiving a SYN message. Also added "Verify adjacency state" procedure. - there is a slight alteration to the text on the timer in section 3.5.2.2, raising the suggested value from 1 second to 25 seconds and noting that the use of TCP means it will usually expire only in ESTAB state. Section 3.5.2.3 and subsections New text. - 3.5.2.3.1 is basically consistent with our previous negotiation text, except that settings of PType and Partition ID are based on interpretation of Section 11.3 of RFC 3292 - 3.5.2.3.2 opening paragraph is consistent with the old version negotiation procedure and the Section 11.2/RFC 3292 state table checks. - recorded state includes peer identification (as directed by Section 11.2/RFC 3292), own identification, and values of negotiated parameters. At this point, Version, Timer, and Capabilities are fully determined, but Partition ID is not fully settled until the SYNACK because the AN could accept the NAS request regardless of the AN's initial proposed value. - NOTE the preference rule for PFlag given in 3.5.2.3.2 -- in case of conflict, the lower value wins. I guess this makes PFlag another negotiated value, fully determined once the peer's SYN or SYNACK is received. To do: add PFlag to the list of negotiated parameters in the overview and mention negotiation in the parameter description in 3.5.1. Section 3.5.2.4 and subsections New text. - 3.5.2.4.1 relies on the adjacency state recorded when the SYN was received. Reviewing the matter of Partition ID, I've realized some text is missing in 3.5.2.3.1. If the NAS receives SYN before it sends its own SYN, it currently records adjacency state including the Partition ID decided by the AN, before the AN has received any proposal from the NAS. This is a case I didn't consider properly in the existing text. There should be text saying that when the NAS sends the SYN, it MAY propose its own Partition ID value, even if the AN has proposed another in its SYN, provided partitions are supported at all. Basically the intention is that the AN sends its final decision in the SYNACK, possibly after reconsidering what it sent in the SYN. - NOTE the halt procedure described at the end of 3.5.2.4.1 if the common set of capabilities is empty - 3.5.2.4.2 is consistent with the above negotiating procedure. The Partition ID the NAS receives in a SYNACK can be different from what it sent in the SYN, so the NAS just accepts what it gets. NOTE the counterpart to the empty capability set halting procedure prescribed for the sender of the SYNACK. The text makes the sender of the SYNACK responsible for clearing the transport session. To do - add the indicated text to 3.5.2.3.1 - fix the "anothewr" typo at the end of 3.5.2.4.1 Section 3.5.2.5 and subsections - 3.5.2.5.2, NOTE the text that tries to limit the ACK exchanges to one exchange per timer period. This is based on an interpretation of the footnotes from RFC 3292 in 3.5.2.2.1, but is new text. Section 3.5.2.6 and subsections - 3.5.2.6.1 NOTE new text on how to populate the non-identifier parts of the RSTACK. RFC 3292 doesn't give any real guidance. - 3.5.2.6.2: only the sender really knows what went wrong, given the lack of space in the RSTACK for diagnostic information. Hence the contents of the RSTACK probably don't matter much. Section 3.5.2.7 - NOTE: first paragraph starts out based on Section 11.4 of RFC 3292, but the current text directly contradicts RFC 3292 on the matter of what happens to connection state. It does reflect the existing contents of the ANCP draft. I'm raising this as a separate issue in an E-mail to the list. - second paragraph was existing text except for the term "adjacency state". To do: make the section consistent with RFC 3292 if the WG so decides. Section 3.6 - dropped GSMPv3-related text - merged Version and Sub-version into a single Version field - renamed Code to Result Code to distinguish it from Code used in the adjacency protocol and Command Code. Change is carried through to the remainder of the document. Section 3.6.1 - dropped GSMPv3-related text in this and subsequent subsections - editorial: added length in bits to subsection headers naming fields - dropped unnecessary reference to Section 3.1. Section 3.6.1.1 - merged Version and Sub-version Section 3.6.1.4 - more precise descrition of what should be logged when non-zero Result Codes are received - dropped Result Code 7 (Invalid Partition ID) - expanded recommended action for Result Code value 81. To do: -- change name for Result Code value in this section ("No error") to that in IANA Section 9.2.2 ("No result") -- change values in this section to hexadecimal like those in Section 9.2.2. Now that ANCP owns the registry we are free to do so. Section 3.6.1.5 - replaced the existing procedure-oriented description (which is now thoroughly covered in the adjacency procedure description) with the statement that it contains the value negotiated for the adjacency Section 3.6.1.6 - replaced "linearly" with "by 1" in describing incrementation of the Transaction ID Section 3.6.1.7 - replaced SHOULD by MUST for the setting of the I Flag and SubMessage Number Section 3.7 - replaced GSMPv3 with ANCP in opening sentence Section 4.5 - added language tag at start of the error message, as announced on the list To do: restore the terms "Error Message" and "Error Message Length". Section 5 - added DHCP-related references Section 5.1.2 - cleaned up wording of normative requirement (second paragraph, introducing bullets) Sections 6.2.1 and 6.2.2 - dropped requirements relating to interaction with control application Section 6.3 - dropped reference to GSMPv3 - simplified description of Label field, since it is no longer explicitly related to RFC 3292 description To do: replace all of Port, Port Session Number, Event Sequence Number, and Label with a single 20 byte Unused field Section 6.4.1 - changed text of first paragraph relating to interaction with the control application to narrative form - dropped the final paragraph giving a requirement for interaction with the control application Section 6.4.2 - changed interaction to narrative description (minor rewording) Section 7.2.1 - dropped requirement on interaction between the ANCP agent and the control application Section 7.2.2 - dropped requirement on interaction between the ANCP agent and the control application - dropped GSMPv3-related text To do: merge unused fields to simplify message description Sections 8.2.1 and 8.2.2 - dropped requirements on interaction between the ANCP agent and the control application Section 8.4.1 - changed interaction to narrative description (minor rewording) Section 8.4.2 - changed interaction to narrative description (minor rewording) - changed Result Code values to hexadecimal - dropped mention of Result Code 0x3 in documentation of 0x500 Result Code Section 8.5.1 Added back description of what a timeout value of 0 means. This got lost somewhere since version -09. Section 9 and subsections - rewrote most of the IANA actions and the summary, to establish independent ANCP registries - created a joint GSMPv3/ANCP version registry to allow protocols to be distinguished based on Version - noted that TCP port 6068 is now shared between GSMPv3 and ANCP - NOTE the requirements for additions to the different registries, which have changed a bit from what I proposed on the list. To do: see if I can rebalance the columns in the Capability Type table Section 10 - noted that applicable requirements were copied from RFC 5713, to avoid a normative dependency on that Informational document - added words to make clear up front that TLS was not the chosen solution Remainder - added acknowledgements - added DHCP references and RFC 5226 (normative) regarding IANA considerations - added normative language tag reference Tom Taylor From wdec@cisco.com Thu Apr 21 06:04:55 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0FAB6E0775 for ; Thu, 21 Apr 2011 06:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.987 X-Spam-Level: X-Spam-Status: No, score=-109.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwn2jnyRgQlV for ; Thu, 21 Apr 2011 06:04:54 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 2EBDEE0752 for ; Thu, 21 Apr 2011 06:04:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1495; q=dns/txt; s=iport; t=1303391093; x=1304600693; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=HSfl7cYUGEtOj5WPgSBhpS5OEAe3UJZCCHbIsUsImwc=; b=guGZzmWHyzPtxmLOzylKVTGC3db4SXr4fSEf+K1bkYPytAdIBxqRWDfj E2coTvZmYn90RQd47WXbuTUFUpdVOpMKWXbZ3fV0zpf46YYRl//+H7zuF 06ezEubMq4y7Y/T0PUBAmReLyLLcP5G1SQVAvYvhC0nhrj2p35FCzyaPB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnoEACcqsE2Q/khLgWdsb2JhbAClSBQBARYmJYhwnmycV4V2BI4rhAw X-IronPort-AV: E=Sophos;i="4.64,251,1301875200"; d="scan'208";a="26617044" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 13:04:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3LD4rv6014486; Thu, 21 Apr 2011 13:04:53 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 15:04:53 +0200 Received: from 10.55.215.37 ([10.55.215.37]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Apr 2011 13:04:52 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 21 Apr 2011 15:04:47 +0200 From: Wojciech Dec To: Tom Taylor , "ancp@ietf.org" Message-ID: Thread-Topic: [ANCP] Fate of connection state after loss of synchronization detected Thread-Index: AcwAJLCvSQqOMUerREm+mRfk7FlLrw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Apr 2011 13:04:53.0244 (UTC) FILETIME=[B46803C0:01CC0024] Subject: Re: [ANCP] Fate of connection state after loss of synchronization detected 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, 21 Apr 2011 13:04:55 -0000 There is fundamental issue here: - Keeping state after the loss of synch, does not guarantee that the info is in any way accurate. - There is no incremental update mechanism, ie The only update mechanism currently is "send all" following a re-synch. Coincidentally, does the text actually make that clear? - Knowing via the Pflag that a connection is back up or a new connection is made, would only be useful if we also knew whether any changes occurred in the time the synch was down. I suppose keeping the state and then having a full re-send by either side could be an option. -Woj. On 19/04/2011 19:35, "Tom Taylor" wrote: > The current text in the ANCP protocol draft says that if loss of > synchronization is detected, all connection state is immediately cleaned > up. I am wondering if this just slipped in without prper consideration. > Section 11.4 of RFC 3292 says just the opposite, that connection state > is held until resynchronization is achieved and then is handled > according to the value of PFlag. > > Which behaviour does the WG favour? The RFC 3292 behaviour seems to > offer more flexibility and certainly a better subscriber experience, as > I see it. > > If there are no comments I propose that we update the document to use > the RFC 3292 procedure. > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom111.taylor@bell.net Thu Apr 21 07:05:51 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9007EE06F7 for ; Thu, 21 Apr 2011 07:05:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.436 X-Spam-Level: X-Spam-Status: No, score=-101.436 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qodf67+NqOKi for ; Thu, 21 Apr 2011 07:05:50 -0700 (PDT) Received: from blu0-omc2-s22.blu0.hotmail.com (blu0-omc2-s22.blu0.hotmail.com [65.55.111.97]) by ietfc.amsl.com (Postfix) with ESMTP id D054BE06BA for ; Thu, 21 Apr 2011 07:05:50 -0700 (PDT) Received: from BLU0-SMTP24 ([65.55.111.71]) by blu0-omc2-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 07:05:50 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP24.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 07:05:49 -0700 Date: Thu, 21 Apr 2011 10:05:28 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Wojciech Dec References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2011 14:05:50.0068 (UTC) FILETIME=[380B1340:01CC002D] Cc: "ancp@ietf.org" Subject: Re: [ANCP] Fate of connection state after loss of synchronization detected 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, 21 Apr 2011 14:05:51 -0000 What I had in mind when I suggested that holding state until contact with the peer is reestablished would be better for subscriber experience was a scenario where the NAS control application crashed. Subscribers could at least continue with their current IP-layer sessions until contact was re-established and the adjacency renegotiated. Maybe I'm unrealistic in my understanding of NAS function. On 21/04/2011 9:04 AM, Wojciech Dec wrote: > There is fundamental issue here: > > - Keeping state after the loss of synch, does not guarantee that the info is > in any way accurate. > - There is no incremental update mechanism, ie The only update mechanism > currently is "send all" following a re-synch. Coincidentally, does the text > actually make that clear? > - Knowing via the Pflag that a connection is back up or a new connection is > made, would only be useful if we also knew whether any changes occurred in > the time the synch was down. > > I suppose keeping the state and then having a full re-send by either side > could be an option. > > -Woj. > > > > On 19/04/2011 19:35, "Tom Taylor" wrote: > >> The current text in the ANCP protocol draft says that if loss of >> synchronization is detected, all connection state is immediately cleaned >> up. I am wondering if this just slipped in without prper consideration. >> Section 11.4 of RFC 3292 says just the opposite, that connection state >> is held until resynchronization is achieved and then is handled >> according to the value of PFlag. >> >> Which behaviour does the WG favour? The RFC 3292 behaviour seems to >> offer more flexibility and certainly a better subscriber experience, as >> I see it. >> >> If there are no comments I propose that we update the document to use >> the RFC 3292 procedure. >> >> Tom Taylor >> _______________________________________________ >> ANCP mailing list >> ANCP@ietf.org >> https://www.ietf.org/mailman/listinfo/ancp > > > From wdec@cisco.com Thu Apr 21 08:06:46 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E21D2E07C6 for ; Thu, 21 Apr 2011 08:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.594 X-Spam-Level: X-Spam-Status: No, score=-109.594 tagged_above=-999 required=5 tests=[AWL=-0.392, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qn01yd7Lt3AL for ; Thu, 21 Apr 2011 08:06:44 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id BCA3AE06B0 for ; Thu, 21 Apr 2011 08:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=6475; q=dns/txt; s=iport; t=1303398403; x=1304608003; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=KZme43WrVssZ8Od1OW0d99kTYMgYo+PlpbUgG737xK4=; b=KGdNjtfbhUF4lN1yK6ycY9/dLP7rIVkQ4bxcgNt/k2NZFvZmzziHaLVx 1TcOhHS5+6NF5hZADuBslVpAF3gZljhu+LndEgTykB0/m/q6KTaRSmQYT XaNcREhecinJngKkUxYw/jkaMbxXiDwFegRK9penGs5er/BaKOmqH6UyI o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwEAKFGsE2Q/khMgWdsb2JhbACCYqFmfxQBARYmJYhwnnycYoV2BI4rhAw X-IronPort-AV: E=Sophos;i="4.64,251,1301875200"; d="scan'208,217";a="84606419" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 15:06:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3LF6gUa008180; Thu, 21 Apr 2011 15:06:42 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 17:06:42 +0200 Received: from 10.55.215.37 ([10.55.215.37]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Apr 2011 15:06:42 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 21 Apr 2011 17:06:38 +0200 From: Wojciech Dec To: Tom Taylor Message-ID: Thread-Topic: [ANCP] Fate of connection state after loss of synchronization detected Thread-Index: AcwALT1+Z1eMbsR6TYCjsrKJY3Oh1gACHjiZ In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386250401_18810422" X-OriginalArrivalTime: 21 Apr 2011 15:06:42.0470 (UTC) FILETIME=[B90B6460:01CC0035] Cc: ancp@ietf.org Subject: Re: [ANCP] Fate of connection state after loss of synchronization detected 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, 21 Apr 2011 15:06:47 -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_3386250401_18810422 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 21/04/2011 16:05, "Tom Taylor" wrote: > What I had in mind when I suggested that holding state until contact > with the peer is reestablished would be better for subscriber experience > was a scenario where the NAS control application crashed. Subscribers > could at least continue with their current IP-layer sessions until > contact was re-established and the adjacency renegotiated. Maybe I'm > unrealistic in my understanding of NAS function. >=20 > Woj> Ok, I guess we need to be more precise in terms of what =B3state=B2 is b= eing > referred to. I tend to think of it in this context as ANCP-state such as > line-synch-rates & characteristics, mcast bw info, mc-forwarding states, = all > not associated with any NAS data plane state. >=20 > -Woj. >=20 > On 21/04/2011 9:04 AM, Wojciech Dec wrote: >> > There is fundamental issue here: >> > >> > - Keeping state after the loss of synch, does not guarantee that the i= nfo >> is >> > in any way accurate. >> > - There is no incremental update mechanism, ie The only update mechani= sm >> > currently is "send all" following a re-synch. Coincidentally, does the= text >> > actually make that clear? >> > - Knowing via the Pflag that a connection is back up or a new connecti= on is >> > made, would only be useful if we also knew whether any changes occurre= d in >> > the time the synch was down. >> > >> > I suppose keeping the state and then having a full re-send by either s= ide >> > could be an option. >> > >> > -Woj. >> > >> > >> > >> > On 19/04/2011 19:35, "Tom Taylor" wrote: >> > >>> >> The current text in the ANCP protocol draft says that if loss of >>> >> synchronization is detected, all connection state is immediately cle= aned >>> >> up. I am wondering if this just slipped in without prper considerati= on. >>> >> Section 11.4 of RFC 3292 says just the opposite, that connection sta= te >>> >> is held until resynchronization is achieved and then is handled >>> >> according to the value of PFlag. >>> >> >>> >> Which behaviour does the WG favour? The RFC 3292 behaviour seems to >>> >> offer more flexibility and certainly a better subscriber experience,= as >>> >> I see it. >>> >> >>> >> If there are no comments I propose that we update the document to us= e >>> >> the RFC 3292 procedure. >>> >> >>> >> Tom Taylor >>> >> _______________________________________________ >>> >> ANCP mailing list >>> >> ANCP@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/ancp >> > >> > >> > >=20 --B_3386250401_18810422 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ANCP] Fate of connection state after loss of synchronization de= tected


On 21/04/2011 16:05, "Tom Taylor" <tom111.taylor@bell.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>What I had in mind when I suggested that holding= state until contact
with the peer is reestablished would be better for subscriber experience was a scenario where the NAS control application crashed. Subscribers
could at least continue with their current IP-layer sessions until
contact was re-established and the adjacency renegotiated. Maybe I'm
unrealistic in my understanding of NAS function.

Woj> Ok, I guess we need to be more precise in terms of what “stat= e” is being referred to. I tend to think of it in this context as ANCP= -state such as line-synch-rates & characteristics, mcast bw info, mc-for= warding states, all not associated with any NAS data plane state.

-Woj.

On 21/04/2011 9:04 AM, Wojciech Dec wrote:
> There is fundamental issue here:
>
> - Keeping state after the loss of synch, does not guarantee that the i= nfo is
> in any way accurate.
> - There is no incremental update mechanism, ie The only update mechani= sm
> currently is "send all" following a re-synch. Coincidentally= , does the text
> actually make that clear?
> - Knowing via the Pflag that a connection is back up or a new connecti= on is
> made, would only be useful if we also knew whether any changes occurre= d in
> the time the synch was down.
>
> I suppose keeping the state and then having a full re-send by either s= ide
> could be an option.
>
> -Woj.
>
>
>
> On 19/04/2011 19:35, "Tom Taylor"<tom111.taylor@bell.net>  wrote:
>
>> The current text in the ANCP protocol draft says that if loss of >> synchronization is detected, all connection state is immediately c= leaned
>> up. I am wondering if this just slipped in without prper considera= tion.
>> Section 11.4 of RFC 3292 says just the opposite, that connection s= tate
>> is held until resynchronization is achieved and then is handled >> according to the value of PFlag.
>>
>> Which behaviour does the WG favour? The RFC 3292 behaviour seems t= o
>> offer more flexibility and certainly a better subscriber experienc= e, as
>> I see it.
>>
>> If there are no comments I propose that we update the document to = use
>> the RFC 3292 procedure.
>>
>> Tom Taylor
>> _______________________________________________
>> ANCP mailing list
>> ANCP@ietf.org
>> https://www.i= etf.org/mailman/listinfo/ancp
>
>
>

--B_3386250401_18810422-- From tom111.taylor@bell.net Thu Apr 21 08:59:41 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7B0F3E06AD for ; Thu, 21 Apr 2011 08:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.453 X-Spam-Level: X-Spam-Status: No, score=-101.453 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ivp43AlwaTRs for ; Thu, 21 Apr 2011 08:59:40 -0700 (PDT) Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfc.amsl.com (Postfix) with ESMTP id D6457E06A7 for ; Thu, 21 Apr 2011 08:59:40 -0700 (PDT) Received: from BLU0-SMTP83 ([65.55.111.72]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 08:59:40 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP83.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 08:59:39 -0700 Date: Thu, 21 Apr 2011 11:59:39 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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-OriginalArrivalTime: 21 Apr 2011 15:59:40.0053 (UTC) FILETIME=[1F081450:01CC003D] Cc: ancp@ietf.org Subject: Re: [ANCP] Fate of connection state after loss of synchronization detected 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, 21 Apr 2011 15:59:41 -0000 I have multicast in mind, where both the AN and the NAS participate actively. On 21/04/2011 11:06 AM, Wojciech Dec wrote: > > > > On 21/04/2011 16:05, "Tom Taylor" wrote: > >> What I had in mind when I suggested that holding state until contact >> with the peer is reestablished would be better for subscriber experience >> was a scenario where the NAS control application crashed. Subscribers >> could at least continue with their current IP-layer sessions until >> contact was re-established and the adjacency renegotiated. Maybe I'm >> unrealistic in my understanding of NAS function. >> >> Woj> Ok, I guess we need to be more precise in terms of what ³state² is being >> referred to. I tend to think of it in this context as ANCP-state such as >> line-synch-rates& characteristics, mcast bw info, mc-forwarding states, all >> not associated with any NAS data plane state. >> >> -Woj. >> >> On 21/04/2011 9:04 AM, Wojciech Dec wrote: >>>> There is fundamental issue here: >>>> >>>> - Keeping state after the loss of synch, does not guarantee that the info >>> is >>>> in any way accurate. >>>> - There is no incremental update mechanism, ie The only update mechanism >>>> currently is "send all" following a re-synch. Coincidentally, does the text >>>> actually make that clear? >>>> - Knowing via the Pflag that a connection is back up or a new connection is >>>> made, would only be useful if we also knew whether any changes occurred in >>>> the time the synch was down. >>>> >>>> I suppose keeping the state and then having a full re-send by either side >>>> could be an option. >>>> >>>> -Woj. >>>> >>>> >>>> >>>> On 19/04/2011 19:35, "Tom Taylor" wrote: >>>> >>>>>> The current text in the ANCP protocol draft says that if loss of >>>>>> synchronization is detected, all connection state is immediately cleaned >>>>>> up. I am wondering if this just slipped in without prper consideration. >>>>>> Section 11.4 of RFC 3292 says just the opposite, that connection state >>>>>> is held until resynchronization is achieved and then is handled >>>>>> according to the value of PFlag. >>>>>> >>>>>> Which behaviour does the WG favour? The RFC 3292 behaviour seems to >>>>>> offer more flexibility and certainly a better subscriber experience, as >>>>>> I see it. >>>>>> >>>>>> If there are no comments I propose that we update the document to use >>>>>> the RFC 3292 procedure. >>>>>> >>>>>> Tom Taylor >>>>>> _______________________________________________ >>>>>> ANCP mailing list >>>>>> ANCP@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ancp >>>> >>>> >>>> >> > > From wdec@cisco.com Thu Apr 21 09:03:26 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5A396E065C for ; Thu, 21 Apr 2011 09:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.463 X-Spam-Level: X-Spam-Status: No, score=-109.463 tagged_above=-999 required=5 tests=[AWL=-0.261, 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtlssuL5TTJ3 for ; Thu, 21 Apr 2011 09:03:23 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 82B70E0655 for ; Thu, 21 Apr 2011 09:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=9594; q=dns/txt; s=iport; t=1303401802; x=1304611402; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version; bh=fDyR7yuRc/WR5NoCWvEQcPsjlypTUPkbOU8nkdp2az8=; b=bL8EUNlFJ7zLEP5nlOeEFUsGm2sgbAOjZpdHiPr73wO73lkyofg3/omZ eBTyLwko9Shcf9FTaJNTsqVRDIzXxjFCaYlou3dVStmn8igoFRwepSRpZ jXdbRtJ/hH5bvHZoyVZkZfKMXQV2WQdWXlAw63N2uadvxQkZgUX21D48y Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwEAG1UsE2Q/khMgWdsb2JhbACCYqFmfxQBARYmJYhwnlicWoV2BI4rhAw X-IronPort-AV: E=Sophos;i="4.64,252,1301875200"; d="scan'208,217";a="26643797" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 21 Apr 2011 16:03:21 +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 p3LG3Lod023989; Thu, 21 Apr 2011 16:03:21 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 21 Apr 2011 18:03:21 +0200 Received: from 10.55.215.37 ([10.55.215.37]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Apr 2011 16:03:21 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Thu, 21 Apr 2011 18:03:18 +0200 From: Wojciech Dec To: Tom Taylor Message-ID: Thread-Topic: [ANCP] Fate of connection state after loss of synchronization detected Thread-Index: AcwAPSUjhe+rScrwQkONGeuiQBi3TAAAHvNs In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3386253800_19033327" X-OriginalArrivalTime: 21 Apr 2011 16:03:21.0394 (UTC) FILETIME=[A2F60920:01CC003D] Cc: ancp@ietf.org Subject: Re: [ANCP] Fate of connection state after loss of synchronization detected 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, 21 Apr 2011 16:03:26 -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_3386253800_19033327 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 21/04/2011 17:59, "Tom Taylor" wrote: > I have multicast in mind, where both the AN and the NAS participate > actively. >=20 > Woj> Ok, but ANCP derived mcast state is not data-plane related =AD that=B9s = all > still there (or not) as per IGMP/whatever other signalling. >=20 > In any case, we have a decision, in terms of which of two evils is better > following a loss of synch: > 1. keep ancp state (even though it may be stale) > 2. clean ancp state (to applications this one would show that something i= s > amiss). -Woj. >=20 > On 21/04/2011 11:06 AM, Wojciech Dec wrote: >> > >> > >> > >> > On 21/04/2011 16:05, "Tom Taylor" wrote: >> > >>> >> What I had in mind when I suggested that holding state until contact >>> >> with the peer is reestablished would be better for subscriber experi= ence >>> >> was a scenario where the NAS control application crashed. Subscriber= s >>> >> could at least continue with their current IP-layer sessions until >>> >> contact was re-established and the adjacency renegotiated. Maybe I'm >>> >> unrealistic in my understanding of NAS function. >>> >> >>> >> Woj> Ok, I guess we need to be more precise in terms of what =B3state= =B2 is >>> being >>> >> referred to. I tend to think of it in this context as ANCP-state suc= h as >>> >> line-synch-rates& characteristics, mcast bw info, mc-forwarding sta= tes, >>> all >>> >> not associated with any NAS data plane state. >>> >> >>> >> -Woj. >>> >> >>> >> On 21/04/2011 9:04 AM, Wojciech Dec wrote: >>>>> >>>> There is fundamental issue here: >>>>> >>>> >>>>> >>>> - Keeping state after the loss of synch, does not guarantee that= the info >>>> >>> is >>>>> >>>> in any way accurate. >>>>> >>>> - There is no incremental update mechanism, ie The only update >>>>> mechanism >>>>> >>>> currently is "send all" following a re-synch. Coincidentally, do= es >>>>> the text >>>>> >>>> actually make that clear? >>>>> >>>> - Knowing via the Pflag that a connection is back up or a new >>>>> connection is >>>>> >>>> made, would only be useful if we also knew whether any changes >>>>> occurred in >>>>> >>>> the time the synch was down. >>>>> >>>> >>>>> >>>> I suppose keeping the state and then having a full re-send by ei= ther side >>>>> >>>> could be an option. >>>>> >>>> >>>>> >>>> -Woj. >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> On 19/04/2011 19:35, "Tom Taylor" wrot= e: >>>>> >>>> >>>>>>> >>>>>> The current text in the ANCP protocol draft says that if los= s of >>>>>>> >>>>>> synchronization is detected, all connection state is immedia= tely >>>>>>> cleaned >>>>>>> >>>>>> up. I am wondering if this just slipped in without prper >>>>>>> consideration. >>>>>>> >>>>>> Section 11.4 of RFC 3292 says just the opposite, that connec= tion state >>>>>>> >>>>>> is held until resynchronization is achieved and then is hand= led >>>>>>> >>>>>> according to the value of PFlag. >>>>>>> >>>>>> >>>>>>> >>>>>> Which behaviour does the WG favour? The RFC 3292 behaviour s= eems to >>>>>>> >>>>>> offer more flexibility and certainly a better subscriber >>>>>>> experience, as >>>>>>> >>>>>> I see it. >>>>>>> >>>>>> >>>>>>> >>>>>> If there are no comments I propose that we update the docume= nt to use >>>>>>> >>>>>> the RFC 3292 procedure. >>>>>>> >>>>>> >>>>>>> >>>>>> Tom Taylor >>>>>>> >>>>>> _______________________________________________ >>>>>>> >>>>>> ANCP mailing list >>>>>>> >>>>>> ANCP@ietf.org >>>>>>> >>>>>> https://www.ietf.org/mailman/listinfo/ancp >>>>> >>>> >>>>> >>>> >>>>> >>>> >>> >> >> > >> > >=20 --B_3386253800_19033327 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ANCP] Fate of connection state after loss of synchronization de= tected


On 21/04/2011 17:59, "Tom Taylor" <tom111.taylor@bell.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I have multicast in mind, where both the AN and = the NAS participate
actively.

Woj> Ok, but ANCP derived mcast state is not data-plane related – = that’s all still there (or not) as per IGMP/whatever other signalling.=

In any case, we have a decision, in terms of which of two evils is better f= ollowing a loss of synch:
  1. keep ancp state (even though it may be stale)
  2. clean ancp state (to applications this one would show th= at something is amiss).

-Woj.
<= SPAN STYLE=3D'font-size:11pt'>
On 21/04/2011 11:06 AM, Wojciech Dec wrote:
>
>
>
> On 21/04/2011 16:05, "Tom Taylor"<tom111.taylor@bell.net>  wrote:
>
>> What I had in mind when I suggested that holding state until conta= ct
>> with the peer is reestablished would be better for subscriber expe= rience
>> was a scenario where the NAS control application crashed. Subscrib= ers
>> could at least continue with their current IP-layer sessions until=
>> contact was re-established and the adjacency renegotiated. Maybe I= 'm
>> unrealistic in my understanding of NAS function.
>>
>> Woj>  Ok, I guess we need to be more precise in terms of w= hat “state” is being
>> referred to. I tend to think of it in this context as ANCP-state s= uch as
>> line-synch-rates&  characteristics, mcast bw info, mc-for= warding states, all
>> not associated with any NAS data plane state.
>>
>> -Woj.
>>
>> On 21/04/2011 9:04 AM, Wojciech Dec wrote:
>>>> There is fundamental issue here:
>>>>
>>>> - Keeping state after the loss of synch, does not guarante= e that the info
>>> is
>>>> in any way accurate.
>>>> - There is no incremental update mechanism, ie The only up= date mechanism
>>>> currently is "send all" following a re-synch. Co= incidentally, does the text
>>>> actually make that clear?
>>>> - Knowing via the Pflag that a connection is back up or a = new connection is
>>>> made, would only be useful if we also knew whether any cha= nges occurred in
>>>> the time the synch was down.
>>>>
>>>> I suppose keeping the state and then having a full re-send= by either side
>>>> could be an option.
>>>>
>>>> -Woj.
>>>>
>>>>
>>>>
>>>> On 19/04/2011 19:35, "Tom Taylor"<tom111.taylor@bell.net>   wrote:
>>>>
>>>>>> The current text in the ANCP protocol draft says t= hat if loss of
>>>>>> synchronization is detected, all connection state = is immediately cleaned
>>>>>> up. I am wondering if this just slipped in without= prper consideration.
>>>>>> Section 11.4 of RFC 3292 says just the opposite, t= hat connection state
>>>>>> is held until resynchronization is achieved and th= en is handled
>>>>>> according to the value of PFlag.
>>>>>>
>>>>>> Which behaviour does the WG favour? The RFC 3292 b= ehaviour seems to
>>>>>> offer more flexibility and certainly a better subs= criber experience, as
>>>>>> I see it.
>>>>>>
>>>>>> If there are no comments I propose that we update = the document to use
>>>>>> the RFC 3292 procedure.
>>>>>>
>>>>>> Tom Taylor
>>>>>> _______________________________________________ >>>>>> ANCP mailing list
>>>>>> ANCP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ancp
>>>>
>>>>
>>>>
>>
>
>

--B_3386253800_19033327-- From wdec@cisco.com Fri Apr 22 02:30:46 2011 Return-Path: X-Original-To: ancp@ietfc.amsl.com Delivered-To: ancp@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AE049E071F for ; Fri, 22 Apr 2011 02:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.097 X-Spam-Level: X-Spam-Status: No, score=-110.097 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eicFJMeBRew4 for ; Fri, 22 Apr 2011 02:30:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id C6D7EE0661 for ; Fri, 22 Apr 2011 02:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=wdec@cisco.com; l=1498; q=dns/txt; s=iport; t=1303464645; x=1304674245; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=An/kdtuOdTkOO5MwqCVnSMhAx3giYy1N+bqVaAShMQ4=; b=L2mzuQ2yjaK6yI+Lm/nH9QJt2hMxTio9ql0B+tmOz9+ldO69wyNGYbLR LUN1f/8t4cng03kjEDZb4A7Yp0s7GmJZstq8ldAMpvVnB/8XaUTkZbLnF sX6KtOE3Rj4UudRSVkec9pWa31yR+hWmowqJ7yQ0X9qh4uirbO7QWz5NP E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcEAIhJsU2Q/khNgWdsb2JhbAClXhQBARYmJYhwnTGcX4V2BI4thA4 X-IronPort-AV: E=Sophos;i="4.64,253,1301875200"; d="scan'208";a="84709711" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 22 Apr 2011 09:30:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3M9Uj4W010059; Fri, 22 Apr 2011 09:30:45 GMT Received: from xmb-ams-111.cisco.com ([144.254.74.86]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 22 Apr 2011 11:30:44 +0200 Received: from 10.55.215.37 ([10.55.215.37]) by XMB-AMS-111.cisco.com ([144.254.74.86]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Apr 2011 09:30:44 +0000 User-Agent: Microsoft-Entourage/12.28.0.101117 Date: Fri, 22 Apr 2011 11:30:40 +0200 From: Wojciech Dec To: Tom Taylor , "ancp@ietf.org" Message-ID: Thread-Topic: [ANCP] A problem with the GSMPv3 state machine Thread-Index: AcwAz/Gw+GXMdvnRUEaCfXgiGgOd+Q== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Apr 2011 09:30:44.0819 (UTC) FILETIME=[F48FB230:01CC00CF] Subject: Re: [ANCP] A problem with the GSMPv3 state machine 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, 22 Apr 2011 09:30:46 -0000 On 13/04/2011 00:10, "Tom Taylor" wrote: > Actually, there are a couple of problems, but I've imposed a solution > for one of them. The one I'm concerned about has to do with a case where > the NAS proposes a Partition ID value in a SYN message (PType=1 and > Partition ID is non-zero). Section 11.3 of RFC 3292 indicates that the > AN can reject this (e.g., because that partition number is already > assigned) by sending an RSTACK with non-zero values of PType and > Partition ID -- for example, by copying these fields from the SYN. > > The problem arises because, having sent the SYN, the NAS may enter > SYNSENT state if it hasn't received a SYN in turn. According to the > instructions for handling a packet arrival event in section 11.2, > RSTACKs are ignored in SYNSENT state. > > I think the solution is that instead of sending an RSTACK, the AN sends > a SYN of its own if it hasn't already, either denying the use of > partitions (PType=0) or assigning a different partition number (PType=2). > > Is there ever an occasion where the NAS instead of the AN would find a > particular Partition ID value unacceptable? I suppose a case for that would be should a single AN attempt to set-up multiple ANCP adjacencies with the same NAS all using the same partition-id. -Woj. > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From Internet-Drafts@ietf.org Tue Apr 26 04:00:02 2011 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 5A0F5E0722; Tue, 26 Apr 2011 04:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFxwBwFt7XCx; Tue, 26 Apr 2011 04:00:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD71FE06CA; Tue, 26 Apr 2011 04:00:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.52 Message-ID: <20110426110001.19335.46576.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2011 04:00:01 -0700 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-17.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: Tue, 26 Apr 2011 11:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-17.txt Pages : 82 Date : 2011-04-26 This document describes the Access Node Control Protocol (ANCP). ANCP operates 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. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. For this reason, ANCP was assigned a separate version number to distinguish it. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-ancp-protocol-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-26035722.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Tue Apr 26 04:03:19 2011 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 E7269E0730 for ; Tue, 26 Apr 2011 04:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.307 X-Spam-Level: X-Spam-Status: No, score=-100.307 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPk7FCsZdvIj for ; Tue, 26 Apr 2011 04:03:19 -0700 (PDT) Received: from blu0-omc3-s28.blu0.hotmail.com (blu0-omc3-s28.blu0.hotmail.com [65.55.116.103]) by ietfa.amsl.com (Postfix) with ESMTP id 63C60E06B6 for ; Tue, 26 Apr 2011 04:03:16 -0700 (PDT) Received: from BLU0-SMTP93 ([65.55.116.74]) by blu0-omc3-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:03:15 -0700 X-Originating-IP: [64.231.151.226] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.17] ([64.231.151.226]) by BLU0-SMTP93.phx.gbl over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:03:15 -0700 Date: Tue, 26 Apr 2011 07:03:16 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "ancp@ietf.org" , Ralph Droms , Dan Romascanu , Sean Turner Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Apr 2011 11:03:15.0713 (UTC) FILETIME=[8ACDE710:01CC0401] Subject: [ANCP] draft-ietf-ancp-protocol-17 posted 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, 26 Apr 2011 11:03:20 -0000 I received a comment from Adrian Farrel, but no other comment. I have therefore posted an update with the changes that I previously noted in my guide to the -16 update. I believe this document is now ready for the next step. Hint to Dan and Sean: I think this and the previous update clear all points of discussion. Tom Taylor