From Matthew.Bocci@alcatel-lucent.com Thu Aug 6 04:41:03 2009 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 4F4063A6B37 for ; Thu, 6 Aug 2009 04:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, HELO_EQ_FR=0.35, SARE_MLH_Stock1=0.87] 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 vI5ZLd4e-2eC for ; Thu, 6 Aug 2009 04:41:01 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 09B723A6D1A for ; Thu, 6 Aug 2009 04:40:57 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n76Bexx2001681 for ; Thu, 6 Aug 2009 13:40:59 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Aug 2009 13:40:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CA168A.C48D3B5F" Date: Thu, 6 Aug 2009 13:40:58 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A043ECD07@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Stockholm ANCP Meeting notes Thread-Index: AcoOufYiwSEKyh/iQAeDY9Gk4AD6lwH0Iakw From: "BOCCI Matthew" To: X-OriginalArrivalTime: 06 Aug 2009 11:40:59.0415 (UTC) FILETIME=[C4A86A70:01CA168A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: [ANCP] Stockholm ANCP Meeting notes 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: Thu, 06 Aug 2009 11:41:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA168A.C48D3B5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Please find attached the meeting notes from Stockholm. Please send any comments to the list. =20 Many thanks to Tom for taking these. Best regards Matthew ------_=_NextPart_001_01CA168A.C48D3B5F Content-Type: text/plain; name="ANCP at IETF 75.txt" Content-Transfer-Encoding: base64 Content-Description: ANCP at IETF 75.txt Content-Disposition: inline; filename="ANCP at IETF 75.txt" TWF0dGhldyBCb2NjaSBhbmQgRGVjIFdvamNpZWNoIGNoYWlyaW5nLg0KTWF0dGhldyBwcmVzZW50 ZWQgdGhlIHN0YXR1cy4gU2xpZGVzLg0KQ2hhcnRlciBtb2RpZmljYXRpb24gb24gdGhlIHdheS4N Cg0KTmVlZCBNSUIgcmV2aWV3cyENCg0KQmFzZSBwcm90b2NvbCBkcmFmdA0KUm9iZXJ0YSBNYWds aW9uZQ0KPT09PT09PT09PT09PT09PT09PQ0KU2xpZGVzLg0KV29qIHBvaW50ZWQgb3V0IHRoYXQg d2UgYXJlIHJldXNpbmcgR1NNUCBwcm90b2NvbCB2YWx1ZXMgZS5nLiBwb3J0IG51bWJlciwgYnV0 IGRlY2xhcmluZyBvdXJzZWx2ZXMgaW5jb21wYXRpYmxlLiBIYXZlIHRvIG1ha2Ugc3VyZSB0aGVy ZSBhcmUgbm8gaXNzdWVzIHdpdGggdGhpcy4NCg0KUXVlc3Rpb24gb2Ygd2hlcmUgUE9OIGZpdHMu IFRvbSBUIGV4cHJlc3NlZCB2aWV3IHRoYXQgUE9OIGNvdWxkIGJlIGluIGEgc2VwYXJhdGUgZG9j dW1lbnQuDQoNCk9wZW4gaXNzdWU6IHJlZ2lzdHJ5IGZvciB0ZWNoIHR5cGUuIFdlIHdpbGwgY3Jl YXRlIG9uZS4NCg0KUXVlc3Rpb24gYWJvdXQgd2hldGhlciByZWFkeSBmb3IgV0dMQy4gVG9tIFQg bm90ZWQgdGhhdCBzaW5jZSBzdGF0dXMtaW5mbyBpcyBkZWZpbmVkIGluIGJhc2UgYWxvbmcgd2l0 aCB0aGUgcmVnaXN0cnkgb2Ygc3RhdHVzIGNvZGVzIGhpcyBwcmltYXJ5IGNvbmNlcm4gcmVnYXJk aW5nIHRoZSBNdWx0aWNhc3QgU3RhdHVzIG1lc3NhZ2UgaGFzIGJlZW4gc2F0aXNmaWVkLiANCg0K T24gaG93IFBPTiBmaXRzIGluOiBzZWVtcyBhcHByb3ByaWF0ZSB0byB1c2UgY2FwYWJpbGl0eSBt ZWNoYW5pc20gdG8gcmVmbGVjdCBjYXBhYmlsaXR5IHRvIG9wZXJhdGUgb24gUE9OLg0KDQpBZ2Fp biwgbmVlZCB0byBjbGVhbiB1cCB2ZXJzaW9uaW5nIGFzIHdlbGwgYXMgbmV3IHN0YXR1cyBtZXNz YWdlIChzZWUgYmVsb3cpLg0KDQpNdWx0aWNhc3QgRXh0ZW5zaW9ucw0KRnJhbmNvaXMgTGUgRmF1 Y2hldXINCj09PT09PT09PT09PT09PT09PT09DQpEaXNjdXNzaW9uIG9mIG9wZW4gaXRlbXMuIElz c3VlIG9mIHdoZXRoZXIgQU4gc2hvdWxkIGRvIGRlbGVnYXRlZCBiYW5kd2lkdGggcXVlcnkuIEZy YW5jb2lzIHNheXMgdXNlIGNhc2UgY292ZXJlZCBieSByZXNldCBwcm9jZWR1cmUuIEZvcnR1bmUg SHVhbmcgPGZxaHVhbmdAaHVhd2VpLmNvbT4gc2F5cyByZXNldCBwcm9jZWR1cmUgaXMgdG9vIGhl YXZ5LCBuZWVkIHNvbWV0aGluZyBzaW1wbGVyLiBGcmFuY29pczogc2VuZCBwcm9wb3NhbCBmb3Ig bGlnaHRlci13ZWlnaHQgcHJvY2VkdXJlIHRvIG1haWxpbmcgbGlzdC4NCg0KUmUgTXVsdGljYXN0 IFN0YXR1cyBtb3ZlbWVudCB0byBiYXNlOiBGcmFuY29pcyBhbmQgV29qIGZlZWwgaWRlYSBoYXMg bWVyaXQuIFRvbSBUYXlsb3IgaGFzIGFjdGlvbiB0byBwcm92aWRlIGFsdGVybmF0aXZlIHRleHQg dG8gbGlzdCBmb3IgYmFzZS1sZXZlbCBTdGF0dXMgbWVzc2FnZS4NCg0KQW50aWNpcGF0ZSBXR0xD IGluIHRoZSByZWxhdGl2ZWx5IG5lYXIgZnV0dXJlIGFmdGVyIGFjdGlvbiBpdGVtcyBjb21wbGV0 ZS4NCg0KV2VuaHUgTHUgKEVyaWNzc29uKTogd291bGQgbGlrZSBtdWx0aWNhc3QgdG8gY292ZXIg YnJvYWRjYXN0LiBTaW1wbGVyIG11bHRpY2FzdCBvcGVyYXRpb24uIFRvbSBUIGFuZCBXb2ogYXNr ZWQgdGhhdCBzcGVha2VyIHByb3ZpZGUgc3VnZ2VzdGlvbnMgZm9yIGNoYW5nZXMgaW4gdGV4dCBo ZSB3b3VsZCBsaWtlIHRvIHNlZSB0byB0aGUgbGlzdC4gQmFzaWMgZmVhdHVyZSBpcyBhdXRvbWF0 aWMgcmVwbGljYXRpb24gb2Ygc3RyZWFtcyBhdCB0aGUgQU4uIEludGVudGlvbiBpcyB0byBhdm9p ZCBKb2luIGFuZCBMZWF2ZS4gU3VnZ2VzdGlvbnMgdGhhdCBpdCBjYW4gYWxyZWFkeSBiZSBkb25l LiANCg0KQU5DUCBNaWdyYXRpb24NClRob21hcyBIYWFnDQo9PT09PT09PT09PT09PT09PT09PT09 DQpTbGlkZXMuDQpSZXZpZXcgb2YgQU5DUCBkZXZlbG9wbWVudCBhbmQgZGVwbG95bWVudHMuDQpE aXNjdXNzaW9uIG9mIHVzZSBvZiB2ZXJzaW9uL3N1YnZlcnNpb24gZmllbGRzIHRvIGNvdmVyIGRl cGxveWVkIHZlcnNpb25zIG9mIGNvZGUuIFByb2JsZW0gaXMgdGhhdCBvbmUgY2Fubm90IHJlZ2lz dGVyIElBTkEgY29kZXBvaW50cyBiYXNlZCBvbiBJLUQgdmVyc2lvbnMuDQpIYXZlIGRlcGxveW1l bnQgcHJvYmxlbS4NClF1ZXN0aW9uIGZvciBjbGFyaWZpY2F0aW9uOiBkb2VzIGhlIGV4cGVjdCBl eGlzdGluZyBUTFZzIHRvIGJlIG1vZGlmaWVkLiBHZW5lcmFsIGFncmVlbWVudCB0aGF0IHdlIHNo b3VsZCBuZXZlciBkbyB0aGF0Lg0KDQpEaXNjdXNzaW9uOiBjaGFpcnM6DQpUb20gVGF5bG9yOiB0 aWdodCBjb3VwbGluZyB0byBkb2N1bWVudHMuIE5ldyB2ZXJzaW9uIG9ubHkgZm9yIG5ldyB2ZXJz aW9uIG9mIGJhc2UgcHJvdG9jb2wgZG9jdW1lbnQuIENhcGFiaWxpdHkgWCBkZXNpZ25hdGVzIHN1 cHBvcnQgb2Ygc3BlY2lmaWMgUkZDIFkgb3IgZGVzaWduYXRlZCBwYXJ0IG9mIGl0Lg0KDQpDb25j ZXJuOiBuZXcgVExWcy4gSGF2ZSB0byBlbnN1cmUgdGhleSBhcmUgYXNzb2NpYXRlZCB3aXRoIHNw ZWNpZmljIG5ldyBjYXBhYmlsaXR5L3N1Yi1jYXBhYmlsaXR5Lg0KDQpCYXNlIGRvY3VtZW50IC9J QU5BIHJlZ2lzdHJ5IGZvciBjYXBhYmlsaXRpZXMgbXVzdCBzcGVjaWZ5IHRoZSBydWxlcyBjbGVh cmx5Lg0KDQpUaG9tYXM6IHByb2JsZW0gd2FzIDQgeWVhciBjeWNsZSB0byBkZXZlbG9wIHByb3Rv Y29sLiBUaW1lIHRvIG1hcmtldCBjb25zaWRlcmF0aW9ucy4NCg0KTm90ZWQgdGhhdCBwdXR0aW5n IHZlcnNpb25pbmcgb2YgdHlwZSBhc2tlZCBmb3IgaW50byBwcm90b2NvbCBtZWFucyBkZXBsb3ll ZCBjb2RlIGhhcyB0byBiZSB1cGRhdGVkIGFueXdheS4NCg0KVG8gZGlzdGluZ3Vpc2ggUkZDIHZl cnNpb24gZnJvbSBhbnkgcHJldmlvdXMgb25lIGFscmVhZHkgZGVwbG95ZWQgKHdoaWNoIGF0IGxl YXN0IGRpc3Rpbmd1aXNoZXMgY29tcGxpYW50IGZyb20gcHJpb3IgaW1wbGVtZW50YXRpb25zKSwg UkZDIHZlcnNpb24gbmVlZHMgdmVyc2lvbi9zdWItdmVyc2lvbiB0byBiZSBkaWZmZXJlbnQgZnJv bSBhbnl0aGluZyBhbHJlYWR5IGRlcGxveWVkLiBQcm9iYWJseSB2ZXJzaW9uIDMuMiBzaG91bGQg YmUgT0suIEFncmVlbWVudCBpbiByb29tIHRvIGdvIHRoaXMgd2F5LiBQcmUtUkZDIHZlcnNpb24g d2lsbCBiZSAzLjEuIFJGQyBFZGl0b3IncyBub3RlIHRvIGNoYW5nZSB2ZXJzaW9uIGZyb20gMy4x IHRvIDMuMiB1cG9uIHB1YmxpY2F0aW9uLg0KDQoNCg0K ------_=_NextPart_001_01CA168A.C48D3B5F-- From lihy@huawei.com Sun Aug 9 23:54:12 2009 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 D398E3A6C67 for ; Sun, 9 Aug 2009 23:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.194 X-Spam-Level: X-Spam-Status: No, score=-0.194 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] 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 WMfp+qJdjb9z for ; Sun, 9 Aug 2009 23:54:10 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id D28CC3A6D79 for ; Sun, 9 Aug 2009 23:53:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO50054LF20WP@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 10 Aug 2009 14:51:36 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO5009S5F1ZGV@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 10 Aug 2009 14:51:35 +0800 (CST) Received: from L26465 ([10.70.40.87]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO500FWJF1ZN5@szxml04-in.huawei.com> for ancp@ietf.org; Mon, 10 Aug 2009 14:51:35 +0800 (CST) Date: Mon, 10 Aug 2009 14:51:35 +0800 From: Hongyu Li In-reply-to: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com> To: 'Peter Arberg' , "'Wojciech Dec (wdec)'" , 'Alan Kavanagh' , 'Sanjay Wadhwa' , ancp@ietf.org Message-id: <040201ca1987$008a6670$5728460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_8t2+/0zyFE/LTzcKWq2fQg)" Thread-index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60A== Subject: Re: [ANCP] ANCP Protocol Versioning 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: Mon, 10 Aug 2009 06:54:12 -0000 This is a multi-part message in MIME format. --Boundary_(ID_8t2+/0zyFE/LTzcKWq2fQg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Peter, I guess you are afraid when a new BNG implementing ANCP per the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question that should go to operators having pre-rfc ANs. If they request so, we may have to define both 3.1 and 3.2 actions in the draft, which is really odd. Otherwise, it is only a piece of cake. Everybody just follows rfc. cheers, Hongyu _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Hi Woj, I did not realize it was last-call, I must have missed that email on the mailing list. I agree with you that also to my knowledge different implementations have been able to keep backward compatibility to earlier drafts, and if the introduction of the new version number 3.2 is because of fear of non compatible implementations then it is not valid, as it is very doable to have backwards compatible to previous drafts so far. But in my mind it still seems like a good idea to bump the version number, if for nothing else then to mark the ANCP standards first step is complete, and to move away one more step to the GSMP tie. But with the reference as you show and also all the reference we still have to GSMP in the draft document, it just seems like we are making it very difficult for any newcomers to the ANCP work to decide what to do and what not to do. I'm not very afraid that vendors who already have a pre-standard ANCP implementation can figure out what to do, but why not make it more easy for everyboby by having a little more description on this. In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. --- another place in the GSMP RFC it talks about a minimum set of messages which must be supported for a version, so by having still GSMP reference in the ANCP draft, and yet no clear statement on what protocol version we would expect to make an adjency seems wrong to me. In my mind it do not have to be a long section, it can be done in a small paragraph to describe that the ANCP version of 3.2 should be able to change it's version to a lower pre-standard 3.1 version if it supports earlier drafts of ANCP. Do we know what happens to existing ANCP implementations if the see a adjancy message with a version number different from 3.1 ? cheers, Peter _____ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Peter, so, based on the experience with the IESG review of last call drafts, one has reason to believe that pulling a trick like referring to a v3.1 in anything but non normative is not going fly (nor would it be reasonable if it happens to be exactly the same as v3.2). The time of making it to rfc of a v3.1 has very little to do with it, since the latest draft of the protocol spec is to our knowledge 100% compatible with "pre-standard" implementation except for new capabilities. Anyway, before we go off documenting all that, perhaps a step back should be taken to evaluate the situation: - the currently deployed protocol, based on some set of the current drafts, has it's core functionality intact. I.e. Given that in all new activities we've strived for backwards compatibility, with the exception of historic tlv conflict, there doesn't seem to be much of a reason for v3.2 - the tlv conflict is inherent to a stage of ANCP development and a v3.2 or its claims of backward compatibility to v3.1 (with conflicting tlv set) are not going to matter; the affected tlvs will still clash, irrespective of "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way to distinguish new protocol functions. It's here that the WG has been spending most of its time, and it's recognised as the way in which the protocol will evolve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set of compatible pre-standard implementations (thus same pre-standard versions) that they are running and the actual standard which may be in their opinion incompatible, hence v3.1 becomes to v3.2. The same operator has not expressed a need to have an rfc for v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which the protocol does not appear to require modification (this appears to be no different than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 (which appears to need a correction) Based on the above, it seems to me that if we go at a stroke to a v3.2 when the rfc gets published we could try to navigate by having a clause which states that pre-rfc eg v3.1 *may* be compatible and a hint to reflect that version number to the sender but leaving remaining behaviour un-specified (since there is no actual guarantee of compatibility). How does this sound? Cheers, Woj. _____ From: Peter Arberg [mailto:parberg@redback.com] Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj, As I see it the problem is exactly that we do not have a normative reference in a RFC simply because we have been too long to put anything together on the running code which are deployed in live networks today. We have a L2CP reference in a TR document and we have live networks. So if we decide to go for version 3.2 in the ANCP WG, it would be very beneficial to have a chapter in the RFC which describe migration from pre-standard ANCP to the standard RFC. I'm sure carriers having pre-standard ANCP running in their network will like a clear RFC statement for how we vendors should handle a incompatibility in a defacto ANCP standard and the "real" ANCP RFC standard. So instead of a normative reference i will suggest that the RFC editor of the ANCP protocol write a chapter and describe what is expected when a RFC standard ANCP ver. 3.2 implementation is getting adjancy connection request from a pre-standard ver. 3.1 ANCP endpoint. Too me this seems like a much too important question to simply ignore in a new protocol which have been in the development for more than 3 years, and have had live networks in multi-vendor deployments for a long time. thanks, Peter _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Your post bears no useful or constructive input regarding the topic. Attempting to define backwards compatibility means drawing on a normative reference to non-standard drafts and is not reasonable (a reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as to where ANCP version 3.1 is defined and can be normatively referenced in a v3.2 RFC? If v3.2 and v3.1 are 100% compatible, except for new capabilities, then there is hardly a reason for a version change. The only way to have a reference to v3.1 in an rfc re v3.2 is either as a historic note, without claims of backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be appealing. In addition, you may also want to reflect on the quality of your conclusions and comprehension of general facts... -Woj. _____ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning So what are you sugegsting will happen with current deployments....!!! Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here. By the time you agree on everything we will be onto ANCP Version 4.10 !!! We are spending far too long on getting this draft out the door. _____ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread... -Woj. _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Exactly, hence we should ahve this explicitly noted in the draft. Alan _____ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility between BNG and AN needs to be handled. -Sanjay _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Cheers Woj The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft. Alan _____ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc. -Woj. _____ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? BR Alan K _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All, During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented ( http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards, Woj. --Boundary_(ID_8t2+/0zyFE/LTzcKWq2fQg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT ANCP Protocol Versioning
Hi Peter,
 
I guess you are afraid when a new BNG implementing ANCP per the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question that should go to operators having pre-rfc ANs. If they request so, we may have to define both 3.1 and 3.2 actions in the draft, which is really odd. Otherwise, it is only a piece of cake. Everybody just follows rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol Versioning

Hi Woj,
 
I did not realize it was last-call, I must have missed that email on the mailing list.
 
I agree with you that also to my knowledge different implementations have been able to
keep backward compatibility to earlier drafts, and if the introduction of the new version
number 3.2 is because of fear of non compatible implementations then it is not valid, as
it is very doable to have backwards compatible to previous drafts so far.
 
But in my mind it still seems like a good idea to bump the version number, if for nothing
else then to mark the ANCP standards first step is complete, and to move away one more
step to the GSMP tie.
 
But with the reference as you show and also all the reference we still have to GSMP in the
draft document, it just seems like we are making it very difficult for any newcomers to the
ANCP work to decide what to do and what not to do.
 
I'm not very afraid that vendors who already have a pre-standard ANCP implementation can
figure out what to do, but why not make it more easy for everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it states:
---
   GSMP contains an adjacency protocol.  The adjacency protocol is used
      to synchronise states across the link, to negotiate which version
      of the GSMP protocol to use, to discover the identity of the
      entity at the other end of a link, and to detect when it changes.
---
 
another place in the GSMP RFC it talks about a minimum set of messages which must be
supported for a version, so by having still GSMP reference in the ANCP draft, and yet no clear
statement on what protocol version we would expect to make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long section, it can be done in a small paragraph to describe
that the ANCP version of 3.2 should be able to change it's version to a lower pre-standard 3.1
version if it supports earlier drafts of ANCP.
 
Do we know what happens to existing ANCP implementations if the see a adjancy message
with a version number different from 3.1 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: 29. juli 2009 16:41
To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

Hi Peter,
 
so, based on the experience with the IESG review of last call drafts, one has reason to believe that pulling a trick like referring to a  v3.1 in anything but non normative is not going fly (nor would it be reasonable if it happens to be exactly the same as v3.2). The time of making it to rfc of a v3.1 has very little to do with it, since the latest draft of the protocol spec is to our knowledge 100% compatible with "pre-standard" implementation except for new capabilities.
Anyway, before we go off documenting all that, perhaps a step back should be taken to evaluate the situation:
- the currently deployed protocol, based on some set of the current drafts, has it's core functionality intact. I.e. Given that in all new activities we've strived for backwards compatibility, with the exception of historic tlv conflict, there doesn't seem to be much of a reason for v3.2
- the tlv conflict is inherent to a stage of ANCP development and a v3.2 or its claims of backward compatibility to v3.1 (with conflicting tlv set) are not going to matter; the affected tlvs will still clash, irrespective of "backwards compatibility" of versions.
- Capability negotiation as offered by ANCP by itself provides a way to distinguish new protocol functions. It's here that the WG has been spending most of its time, and it's recognised as the way in which the protocol will evolve (or via sub-capabilities)
- An operator has requested that a line be drawn to distinguish a set of compatible pre-standard implementations (thus same pre-standard versions)  that they are running and the actual standard which may be in their opinion incompatible, hence v3.1 becomes to v3.2. The same operator has not expressed a need to have an rfc for v3.1
- Migrating from v3.1 to v3.2 is an operational activity for which the protocol does not appear to require modification (this appears to be no different than transitioning from L2TPv2 to v3 say).
- The current protocol draft states that the version SHOULD be 3.1 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a stroke to a v3.2 when the rfc gets published we could try to navigate by having a clause which states that pre-rfc  eg v3.1 *may* be compatible and a hint to reflect that version number to the sender but leaving remaining behaviour un-specified (since there is no actual guarantee of compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg [mailto:parberg@redback.com]
Sent: 29 July 2009 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

Hi Woj,
 
As I see it the problem is exactly that we do not have a normative reference in a RFC
simply because we have been too long to put anything together on the running code
which are deployed in live networks today.
 
We have a L2CP reference in a TR document and we have live networks.
 
So if we decide to go for version 3.2 in the ANCP WG, it would be very beneficial to have
a chapter in the RFC which describe migration from pre-standard ANCP to the standard
RFC.
 
I'm sure carriers having pre-standard ANCP running in their network will like a clear RFC
statement for how we vendors should handle a incompatibility in a defacto ANCP standard
and the "real" ANCP RFC standard.
 
So instead of a normative reference i will suggest that the RFC editor of the ANCP protocol
write a chapter and describe what is expected when a RFC standard ANCP ver. 3.2
implementation is getting adjancy connection request from a pre-standard ver. 3.1 ANCP
endpoint.
 
Too me this seems like a much too important question to simply ignore in a new protocol which
have been in the development for more than 3 years, and have had live networks in multi-vendor
deployments for a long time.
 
thanks,
Peter

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 29. juli 2009 12:22
To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol Versioning

Your post bears no useful or constructive input regarding the topic. Attempting to define backwards compatibility means drawing on a normative reference to non-standard drafts and is not reasonable (a reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as to where ANCP version 3.1 is defined and can be normatively referenced in a v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, except for new capabilities, then there is hardly a reason for a version change. The only way to have a reference to v3.1 in an rfc re v3.2 is either as a historic note, without claims of backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be appealing.
 
In addition, you may also want to reflect on the quality of your conclusions and comprehension of general facts...
 
-Woj.
 
From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]
Sent: 29 July 2009 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

So what are you sugegsting will happen with current deployments....!!! Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here.
 
By the time you agree on everything we will be onto ANCP Version 4.10 !!! We are spending far too long on getting this draft out the door.

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: July 29, 2009 10:01 AM
To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable.
The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread...
 
-Woj.

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh
Sent: 29 July 2009 15:51
To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol Versioning

Exactly, hence we should ahve this explicitly noted in the draft.
 
Alan

From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]
Sent: July 29, 2009 9:48 AM
To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis.

The draft will also need to define how the version incompatibility between BNG and AN needs to be handled.

 

-Sanjay

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh
Sent: Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec (wdec); ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol Versioning

 

Cheers Woj

 

The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft.

 

Alan

 

From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Sent: July 29, 2009 3:33 AM
To: Alan Kavanagh; ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0).

Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc.

 

-Woj.

 

From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]
Sent: 28 July 2009 19:28
To: Wojciech Dec (wdec); ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol Versioning

Hi Woj et.al

 

So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting?

 

BR

Alan K

 

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: July 28, 2009 5:30 AM
To: ancp@ietf.org
Subject: [ANCP] ANCP Protocol Versioning

Hi All,

During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion:

The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases.

We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter.

Regards,
Woj.

--Boundary_(ID_8t2+/0zyFE/LTzcKWq2fQg)-- From alan.kavanagh@ericsson.com Mon Aug 10 08:48:11 2009 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 DCBB928C15A for ; Mon, 10 Aug 2009 08:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] 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 PR0IaAQziCjk for ; Mon, 10 Aug 2009 08:48:08 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 8393828C15C for ; Mon, 10 Aug 2009 08:48:08 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n7AFlrA2000347; Mon, 10 Aug 2009 10:47:56 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 10:47:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA19D1.DBB1431F" Date: Mon, 10 Aug 2009 11:45:54 -0400 Message-ID: <35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60AADyFzwAA9NFwA= References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com> <040201ca1987$008a6670$5728460a@china.huawei.com> <1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de> From: "Alan Kavanagh" To: , , "Peter Arberg" , , , X-OriginalArrivalTime: 10 Aug 2009 15:47:26.0931 (UTC) FILETIME=[DC5B4A30:01CA19D1] Cc: HaagT@telekom.de, B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning 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: Mon, 10 Aug 2009 15:48:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA19D1.DBB1431F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All I typed up some text to include in the ancp protocol draft,based on some = discussions. So from reading the minutes it appears that the WG has = agreed on moving the sub-version number to 2, which gives us Version/Sub = 3.2. It makes sense to have this clearly noted in the ietf-ancp-protocol = draft. I suggest on adding the following text to the ancp protocol draft = to provide a clear reasoning and for the uplift and move us forward: Prior to initiation of this work, existing ANCP deployments used an ANCP = Protocol Version/Sub-Version 3.1. which differs in the TLV's from this = RFC standards track version. Therefore RFC compliant versions MAY choose = to work with such pre-RFC peers (NAS and DSLAM).=20 A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp = protocol Version/Sub-Version is set on a per peer basis and is = synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section 5.3. to agree on the protocol version to use.=20 Alan ________________________________ From: Peter.Hamacher@telekom.de [mailto:Peter.Hamacher@telekom.de]=20 Sent: August 10, 2009 11:35 AM To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kavanagh; = swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Protocol Versioning Hi all, =20 from our perspective it is essential to have a practible way to migrate = to RFC. =20 regards Peter Hamacher Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Peter Hamacher Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2864 (Tel.) +49 521 92100494 (Fax) E-Mail: Peter.Hamacher@telekom.de =20 http://www.telekom.com =20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Erleben, was verbindet. =20 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Hongyu Li Gesendet: Montag, 10. August 2009 08:52 An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay = Wadhwa'; ancp@ietf.org Betreff: Re: [ANCP] ANCP Protocol Versioning Hi Peter, =20 I guess you are afraid when a new BNG implementing ANCP per the future = RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question = that should go to operators having pre-rfc ANs. If they request so, we = may have to define both 3.1 and 3.2 actions in the draft, which is = really odd. Otherwise, it is only a piece of cake. Everybody just = follows rfc. =20 cheers, Hongyu =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Peter Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Hi Woj, =20 I did not realize it was last-call, I must have missed that email on = the mailing list. =20 I agree with you that also to my knowledge different implementations = have been able to keep backward compatibility to earlier drafts, and if the introduction = of the new version=20 number 3.2 is because of fear of non compatible implementations then it = is not valid, as it is very doable to have backwards compatible to previous drafts so = far. =20 But in my mind it still seems like a good idea to bump the version = number, if for nothing else then to mark the ANCP standards first step is complete, and to = move away one more step to the GSMP tie.=20 =20 But with the reference as you show and also all the reference we still = have to GSMP in the=20 draft document, it just seems like we are making it very difficult for = any newcomers to the=20 ANCP work to decide what to do and what not to do. =20 I'm not very afraid that vendors who already have a pre-standard ANCP = implementation can figure out what to do, but why not make it more easy for everyboby by = having a little more description on this. =20 In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. --- =20 another place in the GSMP RFC it talks about a minimum set of messages = which must be supported for a version, so by having still GSMP reference in the ANCP = draft, and yet no clear statement on what protocol version we would expect to make an adjency = seems wrong to me. =20 =20 In my mind it do not have to be a long section, it can be done in a = small paragraph to describe that the ANCP version of 3.2 should be able to change it's version to a = lower pre-standard 3.1=20 version if it supports earlier drafts of ANCP. =20 Do we know what happens to existing ANCP implementations if the see a = adjancy message with a version number different from 3.1 ? =20 cheers, Peter =20 =20 =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Hi Peter, =20 so, based on the experience with the IESG review of last call drafts, = one has reason to believe that pulling a trick like referring to a v3.1 = in anything but non normative is not going fly (nor would it be = reasonable if it happens to be exactly the same as v3.2). The time of = making it to rfc of a v3.1 has very little to do with it, since the = latest draft of the protocol spec is to our knowledge 100% compatible = with "pre-standard" implementation except for new capabilities. Anyway, before we go off documenting all that, perhaps a step back = should be taken to evaluate the situation: - the currently deployed protocol, based on some set of the current = drafts, has it's core functionality intact. I.e. Given that in all new = activities we've strived for backwards compatibility, with the exception = of historic tlv conflict, there doesn't seem to be much of a reason for = v3.2 - the tlv conflict is inherent to a stage of ANCP development and a = v3.2 or its claims of backward compatibility to v3.1 (with conflicting = tlv set) are not going to matter; the affected tlvs will still clash, = irrespective of "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way = to distinguish new protocol functions. It's here that the WG has been = spending most of its time, and it's recognised as the way in which the = protocol will evolve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set = of compatible pre-standard implementations (thus same pre-standard = versions) that they are running and the actual standard which may be in = their opinion incompatible, hence v3.1 becomes to v3.2. The same = operator has not expressed a need to have an rfc for v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which the = protocol does not appear to require modification (this appears to be no = different than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 = (which appears to need a correction) =20 Based on the above, it seems to me that if we go at a stroke to a v3.2 = when the rfc gets published we could try to navigate by having a clause = which states that pre-rfc eg v3.1 *may* be compatible and a hint to = reflect that version number to the sender but leaving remaining = behaviour un-specified (since there is no actual guarantee of = compatibility). How does this sound? =20 Cheers, Woj. ________________________________ From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Hi Woj, =20 As I see it the problem is exactly that we do not have a normative = reference in a RFC simply because we have been too long to put anything together on the = running code which are deployed in live networks today. =20 We have a L2CP reference in a TR document and we have live networks. =20 So if we decide to go for version 3.2 in the ANCP WG, it would be = very beneficial to have a chapter in the RFC which describe migration from pre-standard ANCP = to the standard RFC. =20 I'm sure carriers having pre-standard ANCP running in their network = will like a clear RFC statement for how we vendors should handle a incompatibility in a = defacto ANCP standard and the "real" ANCP RFC standard. =20 So instead of a normative reference i will suggest that the RFC = editor of the ANCP protocol=20 write a chapter and describe what is expected when a RFC standard = ANCP ver. 3.2=20 implementation is getting adjancy connection request from a = pre-standard ver. 3.1 ANCP endpoint. =20 Too me this seems like a much too important question to simply ignore = in a new protocol which have been in the development for more than 3 years, and have had live = networks in multi-vendor deployments for a long time. =20 thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Wojciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Your post bears no useful or constructive input regarding the topic. = Attempting to define backwards compatibility means drawing on a = normative reference to non-standard drafts and is not reasonable (a = reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could = be so kind as to give us advise the WG as to where ANCP version 3.1 is = defined and can be normatively referenced in a v3.2 RFC?=20 If v3.2 and v3.1 are 100% compatible, except for new capabilities, = then there is hardly a reason for a version change. The only way to have = a reference to v3.1 in an rfc re v3.2 is either as a historic note, = without claims of backwards compatibility, or publish two rfcs (a v3.1 = and then a v3.2). Neither of these proposals seem to be appealing. =20 In addition, you may also want to reflect on the quality of your = conclusions and comprehension of general facts... =20 -Woj. =20 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 So what are you sugegsting will happen with current = deployments....!!! Like it or not Woj, fact is it must be covered, if = you dont agree then thats just your single opinion here. =20 By the time you agree on everything we will be onto ANCP Version = 4.10 !!! We are spending far too long on getting this draft out the = door. ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 = which is NOT defined anywhere (in any normative reference or RFC) does = not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP = "version incompatibility" will be handled. Given that we're not out in = the WG to create version compatibility between an ANCP standard protocol = and an ANCP non-standard based one (or GSMP for that matter), it would = seem that no new definition needs to take place. Feel free to discuss = this further on this thread... =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 In order to ease migration, it will help if BNGs are able to handle = multiple peers with different versions (e.g. a 3.2 compliant BNG = implementation able to work with a 3.1 AN and a 3.2 AN). Although = implied by the protocol, we may want to explicitly state that version = compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility = between BNG and AN needs to be handled. =20 -Sanjay =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on = Monday as i did not attend) is "backward compatibility" between the = different versions of 3.1, 3.2 and future versions if/when/as needed. = this should be noted in the draft. =20 Alan =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing = new is being defined. Also strictly speaking there is no distinction = between version and sub-version, so the choice of 3.2 is purely based on = custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will = automatically be 100% incompatible with the rfc. =20 -Woj. =20 =09 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the = Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic = of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol, however an RFC Editor's note will be = introduced to change version from 3.1 to 3.2 upon publication of the = RFC. This will clearly de-lineate any pre-RFC implementations with = post-RFC ones and alleviate the operators'' problems presented = (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt = ) Going beyond the publication of the RFC, the introduction of new = capabilities or TLVs is expected to be handled by the capability = negotiation mechanism (and new capabilities) or possibly by generalizing = the notion of sub-capability currently in place for the = multicast-control use-cases. We would like to get feedback from the wider WG on the above, = especially in terms of anyone who was not able to voice their opinion at = the meeting. Based on the received feedback, we'll make a call regarding = the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA19D1.DBB1431F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANCP Protocol = Versioning

Hi All

I typed up some text to include = in the=20 ancp protocol draft,based on some = discussions.=20 So from reading the minutes it appears that the WG has = agreed on=20 moving the sub-version number to 2, which gives us Version/Sub 3.2. It = makes=20 sense to have this clearly noted in the ietf-ancp-protocol draft. I = suggest on=20 adding the following text to the ancp protocol draft to provide a clear reasoning and for the = uplift and=20 move us forward:

Prior to initiation of this work, existing ANCP deployments used an = ANCP=20 Protocol Version/Sub-Version 3.1. which differs in the TLV's from this = RFC=20 standards track version. Therefore RFC compliant versions MAY choose to = work=20 with such pre-RFC peers (NAS and DSLAM).

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp = protocol Version/Sub-Version is set on a per peer basis and is=20 synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section=20 5.3. to agree on the protocol version to use.

Alan

From: Peter.Hamacher@telekom.de=20 [mailto:Peter.Hamacher@telekom.de]
Sent: August 10, 2009 = 11:35=20 AM
To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan = Kavanagh;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: AW: [ANCP] ANCP Protocol=20 Versioning

Hi all,
 
from our perspective it is essential to have a = practible=20 way to migrate to RFC.
 

regards
Peter=20 Hamacher


Deutsche=20 Telekom Netzproduktion GmbH
Zentrum Technik Einf=FChrung
Peter=20 Hamacher
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 628 = 2864=20 (Tel.)
+49 521 92100494 (Fax)
E-Mail: Peter.Hamacher@telekom.de
http://www.telekom.com

Deutsche Telekom = Netzproduktion=20 GmbH
Aufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr.=20 Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der = Gesellschaft:=20 Bonn
USt-IdNr.: DE 814645262

Erleben, was verbindet.

 

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Hongyu=20 Li
Gesendet: Montag, 10. August 2009 08:52
An: = 'Peter=20 Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa';=20 ancp@ietf.org
Betreff: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
I guess you are afraid when a new BNG implementing = ANCP per=20 the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is = a=20 question that should go to operators having pre-rfc ANs. If they request = so, we=20 may have to define both 3.1 and 3.2 actions in the draft, which is = really odd.=20 Otherwise, it is only a piece of cake. Everybody just follows=20 rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To: = Wojciech=20 Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; = ancp@ietf.org
Subject: Re:=20 [ANCP] ANCP Protocol Versioning

Hi Woj,
 
I did not realize it was last-call, I must = have missed=20 that email on the mailing list.
 
I agree with you that also to my knowledge = different=20 implementations have been able to
keep backward compatibility to earlier = drafts, and if the=20 introduction of the new version
number 3.2 is because of fear of non = compatible=20 implementations then it is not valid, as
it is very doable to have backwards = compatible to=20 previous drafts so far.
 
But in my mind it still seems like a good = idea to bump=20 the version number, if for nothing
else then to mark the ANCP standards first = step is=20 complete, and to move away one more
step to the GSMP tie.
 
But with the reference as you show and also = all the=20 reference we still have to GSMP in the
draft document, it just seems like we are = making it very=20 difficult for any newcomers to the
ANCP work to decide what to do and what not = to=20 do.
 
I'm not very afraid that vendors who already = have a=20 pre-standard ANCP implementation can
figure out what to do, but why not make it = more easy for=20 everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it=20 states:
---
   GSMP contains an adjacency = protocol. =20 The adjacency protocol is used
      to=20 synchronise states across the link, to negotiate which=20 version
      of the GSMP protocol to use, = to=20 discover the identity of the
      entity = at the=20 other end of a link, and to detect when it = changes.
---
 
another place in the GSMP RFC it talks about = a minimum=20 set of messages which must be
supported for a version, so by having still = GSMP=20 reference in the ANCP draft, and yet no clear
statement on what protocol version we would = expect to=20 make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long = section, it can be=20 done in a small paragraph to describe
that the ANCP version of 3.2 should be able = to change=20 it's version to a lower pre-standard 3.1
version if it supports earlier drafts of=20 ANCP.
 
Do we know what happens to existing ANCP = implementations=20 if the see a adjancy message
with a version number different from 3.1=20 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: 29. juli 2009 = 16:41
To:=20 Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; = ancp@ietf.org
Subject:=20 RE: [ANCP] ANCP Protocol Versioning

Hi Peter,
 
so, based on the experience with the IESG review of = last call=20 drafts, one has reason to believe that pulling a trick = like=20 referring to a  v3.1 in anything but non normative is not = going=20 fly (nor would it be reasonable if it happens to be exactly the same = as=20 v3.2). The time of making it to rfc of a v3.1 has very little = to do=20 with it, since the latest draft of the protocol spec is to our = knowledge=20 100% compatible with "pre-standard" implementation except for new=20 capabilities.
Anyway, before we go off documenting all that, = perhaps a=20 step back should be taken to evaluate the = situation:
- the currently deployed protocol, based on some set of the = current drafts, has it's core functionality intact. I.e. Given = that in=20 all new activities we've strived for backwards compatibility, with = the=20 exception of historic tlv conflict, there doesn't seem to be much of = a=20 reason for v3.2
- the tlv conflict is inherent to a stage of ANCP = development and=20 a v3.2 or its claims of backward compatibility to v3.1 (with=20 conflicting tlv set) are not going to matter; = the affected tlvs=20 will still clash, irrespective of "backwards compatibility" of=20 versions.
- Capability negotiation as offered by ANCP by = itself provides a=20 way to distinguish new protocol functions. It's here that the WG has = been=20 spending most of its time, and it's recognised as the way in which = the=20 protocol will evolve (or via sub-capabilities)
- An operator has requested that a line be drawn to = distinguish a set=20 of compatible pre-standard implementations (thus same = pre-standard=20 versions)  that they are running and the actual standard which = may be=20 in their opinion incompatible, hence v3.1 becomes to v3.2. The = same=20 operator has not expressed a need to have an rfc for=20 v3.1
- Migrating from v3.1 to v3.2 is an operational activity = for which=20 the protocol does not appear to require modification (this = appears to=20 be no different than transitioning from L2TPv2 to v3=20 say).
- The current protocol draft states that the version SHOULD = be 3.1=20 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a = stroke to a=20 v3.2 when the rfc gets published we could try to navigate by having = a clause=20 which states that pre-rfc  eg v3.1 *may* be compatible and a = hint to=20 reflect that version number to the sender but leaving remaining = behaviour un-specified (since there is no actual guarantee of=20 compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg=20 [mailto:parberg@redback.com]
Sent: 29 July 2009=20 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay = Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
As I see it the problem is exactly that = we do not=20 have a normative reference in a RFC
simply because we have been too long to = put anything=20 together on the running code
which are deployed in live networks=20 today.
 
We have a L2CP reference in a TR document = and we have=20 live networks.
 
So if we decide to go for version 3.2 in = the ANCP WG,=20 it would be very beneficial to have
a chapter in the RFC which describe = migration from=20 pre-standard ANCP to the standard
RFC.
 
I'm sure carriers having pre-standard = ANCP running in=20 their network will like a clear RFC
statement for how we vendors should = handle a=20 incompatibility in a defacto ANCP standard
and the "real" ANCP RFC = standard.
 
So instead of a normative reference i = will suggest=20 that the RFC editor of the ANCP protocol
write a chapter and describe what is = expected when a=20 RFC standard ANCP ver. 3.2
implementation is getting adjancy = connection request=20 from a pre-standard ver. 3.1 ANCP
endpoint.
 
Too me this seems like a much too = important question=20 to simply ignore in a new protocol which
have been in the development for more = than 3 years,=20 and have had live networks = in multi-vendor
deployments for a long = time.
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 29. juli 2009 12:22
To: Alan = Kavanagh;=20 Sanjay Wadhwa; ancp@ietf.org
Subject: Re: [ANCP] ANCP = Protocol=20 Versioning

Your post bears no useful or constructive input = regarding the=20 topic. Attempting to define backwards compatibility means=20 drawing on a normative reference to non-standard = drafts=20 and is not reasonable (a reading of http://tools.ietf.org/html/rf= c4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as to = where=20 ANCP version 3.1 is defined and can be normatively referenced in = a v3.2=20 RFC? 
If v3.2 and v3.1 are 100% compatible, except for new=20 capabilities, then there is hardly a reason for a version = change. The=20 only way to have a reference to v3.1 in an rfc re v3.2 is either = as a=20 historic note, without claims of backwards compatibility, or = publish two=20 rfcs (a v3.1 and then a v3.2). Neither of these proposals seem = to be=20 appealing.
 
In addition, you may also want to reflect on the = quality of=20 your conclusions and comprehension of general=20 facts...
 
-Woj.
 
From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 29 July = 2009=20 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

So what are you = sugegsting will happen=20 with current deployments....!!! Like it or not Woj, fact is it = must be=20 covered, if you dont agree then thats just your single opinion = here.
 
By the time you agree on = everything we=20 will be onto ANCP Version 4.10 !!! We are spending far too = long on=20 getting this draft out the door.

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: July 29, 2009 10:01=20 AM
To: Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Sorry, but reference in a future ANCP = v3.2 RFC to a=20 version 3.1 which is NOT defined anywhere (in any normative = reference=20 or RFC) does not seem to be = acceptable.
The (minuted) discussion did not cover = the notion of=20 how ANCP "version incompatibility" will be handled. Given that = we're=20 not out in the WG to create version compatibility between = an ANCP=20 standard protocol and an ANCP non-standard based one (or = GSMP for=20 that matter), it would seem that no new definition needs = to take=20 place. Feel free to discuss this further on this=20 thread...
 
-Woj.

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: 29 July 2009 15:51
To: = Sanjay=20 Wadhwa; Wojciech Dec (wdec); = ancp@ietf.org
Subject: Re:=20 [ANCP] ANCP Protocol Versioning

Exactly, hence we = should ahve this=20 explicitly noted in the draft.
 
Alan

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: July 29, 2009 = 9:48=20 AM
To: Alan Kavanagh; Wojciech Dec (wdec);=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

In order to=20 ease migration, it will help if BNGs are able to handle = multiple=20 peers with different versions (e.g. a 3.2 compliant BNG=20 implementation able to work with a 3.1 AN and a 3.2 AN). = Although=20 implied by the protocol, we may want to explicitly state = that=20 version compatibility requirement is on an adjacency=20 basis.

The draft=20 will also need to define how the version incompatibility = between BNG=20 and AN needs to be handled.

 

-Sanjay

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On=20 Behalf Of Alan Kavanagh
Sent: Wednesday, July = 29, 2009=20 9:30 AM
To:=20 Wojciech Dec (wdec); ancp@ietf.org
Subject: Re: [ANCP] = ANCP=20 Protocol Versioning

 

Cheers=20 Woj

 

The only=20 point i would note (excuse if it was already raised on = Monday as i=20 did not attend) is "backward compatibility" between the = different=20 versions of 3.1, 3.2 and future versions if/when/as needed. = this=20 should be noted in the draft.

 

Alan

 

From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com] =
Sent: July 29, 2009 = 3:33=20 AM
To: = Alan=20 Kavanagh; ancp@ietf.org
Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

Not entirely. = ANCP=20 already has a versioning field, hence nothing new is being = defined.=20 Also strictly speaking there is no distinction between = version=20 and sub-version, so the choice of 3.2 is purely based = on custom=20 (it can equally well have been = 4.0).

Of course this = will mean=20 that all "pre-rfc" implementations will automatically be = 100%=20 incompatible with the rfc.

 

-Woj.

 

From: Alan = Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]=20
Sent: = 28 July=20 2009 19:28
To:=20 Wojciech Dec (wdec); ancp@ietf.org
Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

Hi Woj=20 et.al

 

So are we=20 agreeing that option 1 as noted on slide 15 in the = Thomas's=20 presentation is what was agreed on at yesterdays=20 meeting?

 

BR

Alan=20 K

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of = Wojciech Dec=20 (wdec)
Sent: July=20 28, 2009 5:30 AM
To: ancp@ietf.org
Subject: [ANCP] = ANCP Protocol=20 Versioning

Hi=20 All, =

During = yesterday's=20 ANCP WG meeting at IET75 we discussed the topic of ANCP = versioning=20 and in the room arrived at the following=20 conclusion:

The Pre-RFC = version of=20 ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol,=20 however an RFC Editor's note will be introduced to change = version=20 from 3.1 to 3.2 upon publication of the RFC. This will = clearly=20 de-lineate any pre-RFC implementations with post-RFC ones = and=20 alleviate the operators'' problems presented = (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going beyond = the=20 publication of the RFC, the introduction of new = capabilities or=20 TLVs is expected to be handled by the capability = negotiation=20 mechanism (and new capabilities) or possibly by = generalizing the=20 notion of sub-capability currently in place for the=20 multicast-control use-cases.

We would = like to get=20 feedback from the wider WG on the above, especially in = terms of=20 anyone who was not able to voice their opinion at the = meeting.=20 Based on the received feedback, we'll make a call = regarding the WG=20 consensus on this matter.

Regards,=20
Woj.=20 =

------_=_NextPart_001_01CA19D1.DBB1431F-- From Robert.Rennison@ecitele.com Mon Aug 10 08:30:33 2009 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 433CA3A6882 for ; Mon, 10 Aug 2009 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] 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 MjpGmxnbdYyI for ; Mon, 10 Aug 2009 08:30:30 -0700 (PDT) Received: from uspitiron01.ecitele.com (uspitiron01.ecitele.com [63.94.127.135]) by core3.amsl.com (Postfix) with ESMTP id 939913A67AA for ; Mon, 10 Aug 2009 08:30:29 -0700 (PDT) Received: from nat-33.laurelnetworks.com (HELO uspitexch02.ecitele.com) ([63.94.127.33]) by uspitiron01-out.ecitele.com with ESMTP; 10 Aug 2009 11:27:39 -0500 Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Mon, 10 Aug 2009 11:30:32 -0400 From: Robert Rennison To: Hongyu Li , 'Peter Arberg' , "'Wojciech Dec (wdec)'" , 'Alan Kavanagh' , 'Sanjay Wadhwa' , "ancp@ietf.org" Date: Mon, 10 Aug 2009 11:30:32 -0400 Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60AASHXhg Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE3EC@USPITMAIL01.ecitele.com> References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com> <040201ca1987$008a6670$5728460a@china.huawei.com> In-Reply-To: <040201ca1987$008a6670$5728460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE3ECUSPITMAIL01ec_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Aug 2009 09:28:42 -0700 Subject: Re: [ANCP] ANCP Protocol Versioning 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: Mon, 10 Aug 2009 15:30:33 -0000 --_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE3ECUSPITMAIL01ec_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter, Honyu Whilst a vendor may decide unilaterally to support pre-standard implement= ations of ANCP, it would be rather strange to see an RFC pointing out tha= t pre-standard versions of the RFC SHOULD, or even MAY be supported. Indeed it was agreed that no explicit mention of pre-standard versions shou= ld be made within the final RFC. Trying to come up with heuristics to allow for interoperability with all of= the pre-standard flavors of ANCP is not something that was deemed desirabl= e to put into an RFC. "At least" one can see from the version field that the RFC version is 3.2 a= nd that pre-standard versions are clearly identified, this should reduce th= e amount of logic to infer exactly what version of the draft is being imple= mented. One major operator present was OK, reluctantly but ok, with "merely" bei= ng able to differentiate the pre-standard versions as a whole from the stan= dard version, hence bumping the version number provides a way of resetting= things and then ensuring that in the future any new TLVs, do not overlap with other TLVs and that the capability negotiatio= n mechanism is used to differentiate new capabilities within the protocol w= ithout having to bump versions again. So, whilst not a perfect solution to fix all of the sins of the past, I thi= nk this is a reasonably pragmatic compromise. Cheers Rob ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Hon= gyu Li Sent: Monday, August 10, 2009 2:52 AM To: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'= ; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Hi Peter, I guess you are afraid when a new BNG implementing ANCP per the future RFC,= whether it can talk to pre-rfc version AN. IMHO, this is a question that s= hould go to operators having pre-rfc ANs. If they request so, we may have t= o define both 3.1 and 3.2 actions in the draft, which is really odd. Otherw= ise, it is only a piece of cake. Everybody just follows rfc. cheers, Hongyu ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Pet= er Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Hi Woj, I did not realize it was last-call, I must have missed that email on the ma= iling list. I agree with you that also to my knowledge different implementations have b= een able to keep backward compatibility to earlier drafts, and if the introduction of t= he new version number 3.2 is because of fear of non compatible implementations then it is = not valid, as it is very doable to have backwards compatible to previous drafts so far. But in my mind it still seems like a good idea to bump the version number, = if for nothing else then to mark the ANCP standards first step is complete, and to move aw= ay one more step to the GSMP tie. But with the reference as you show and also all the reference we still have= to GSMP in the draft document, it just seems like we are making it very difficult for any = newcomers to the ANCP work to decide what to do and what not to do. I'm not very afraid that vendors who already have a pre-standard ANCP imple= mentation can figure out what to do, but why not make it more easy for everyboby by havin= g a little more description on this. In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. --- another place in the GSMP RFC it talks about a minimum set of messages whic= h must be supported for a version, so by having still GSMP reference in the ANCP draf= t, and yet no clear statement on what protocol version we would expect to make an adjency seems= wrong to me. In my mind it do not have to be a long section, it can be done in a small p= aragraph to describe that the ANCP version of 3.2 should be able to change it's version to a low= er pre-standard 3.1 version if it supports earlier drafts of ANCP. Do we know what happens to existing ANCP implementations if the see a adjan= cy message with a version number different from 3.1 ? cheers, Peter ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Peter, so, based on the experience with the IESG review of last call drafts, one h= as reason to believe that pulling a trick like referring to a v3.1 in anyt= hing but non normative is not going fly (nor would it be reasonable if it h= appens to be exactly the same as v3.2). The time of making it to rfc of a v= 3.1 has very little to do with it, since the latest draft of the protocol s= pec is to our knowledge 100% compatible with "pre-standard" implementation = except for new capabilities. Anyway, before we go off documenting all that, perhaps a step back should b= e taken to evaluate the situation: - the currently deployed protocol, based on some set of the current drafts,= has it's core functionality intact. I.e. Given that in all new activities = we've strived for backwards compatibility, with the exception of historic t= lv conflict, there doesn't seem to be much of a reason for v3.2 - the tlv conflict is inherent to a stage of ANCP development and a v3.2 or= its claims of backward compatibility to v3.1 (with conflicting tlv set) ar= e not going to matter; the affected tlvs will still clash, irrespective of = "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way to dis= tinguish new protocol functions. It's here that the WG has been spending mo= st of its time, and it's recognised as the way in which the protocol will e= volve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set of co= mpatible pre-standard implementations (thus same pre-standard versions) th= at they are running and the actual standard which may be in their opinion i= ncompatible, hence v3.1 becomes to v3.2. The same operator has not expresse= d a need to have an rfc for v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which the prot= ocol does not appear to require modification (this appears to be no differe= nt than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 (which a= ppears to need a correction) Based on the above, it seems to me that if we go at a stroke to a v3.2 when= the rfc gets published we could try to navigate by having a clause which s= tates that pre-rfc eg v3.1 *may* be compatible and a hint to reflect that = version number to the sender but leaving remaining behaviour un-specified (= since there is no actual guarantee of compatibility). How does this sound? Cheers, Woj. ________________________________ From: Peter Arberg [mailto:parberg@redback.com] Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj, As I see it the problem is exactly that we do not have a normative referenc= e in a RFC simply because we have been too long to put anything together on the runnin= g code which are deployed in live networks today. We have a L2CP reference in a TR document and we have live networks. So if we decide to go for version 3.2 in the ANCP WG, it would be very bene= ficial to have a chapter in the RFC which describe migration from pre-standard ANCP to the= standard RFC. I'm sure carriers having pre-standard ANCP running in their network will li= ke a clear RFC statement for how we vendors should handle a incompatibility in a defacto A= NCP standard and the "real" ANCP RFC standard. So instead of a normative reference i will suggest that the RFC editor of t= he ANCP protocol write a chapter and describe what is expected when a RFC standard ANCP ver.= 3.2 implementation is getting adjancy connection request from a pre-standard ve= r. 3.1 ANCP endpoint. Too me this seems like a much too important question to simply ignore in a = new protocol which have been in the development for more than 3 years, and have had live netwo= rks in multi-vendor deployments for a long time. thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Your post bears no useful or constructive input regarding the topic. Attemp= ting to define backwards compatibility means drawing on a normative referen= ce to non-standard drafts and is not reasonable (a reading of http://tools.= ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us ad= vise the WG as to where ANCP version 3.1 is defined and can be normatively = referenced in a v3.2 RFC? If v3.2 and v3.1 are 100% compatible, except for new capabilities, then the= re is hardly a reason for a version change. The only way to have a referenc= e to v3.1 in an rfc re v3.2 is either as a historic note, without claims of= backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Nei= ther of these proposals seem to be appealing. In addition, you may also want to reflect on the quality of your conclusion= s and comprehension of general facts... -Woj. ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning So what are you sugegsting will happen with current deployments....!!! Like= it or not Woj, fact is it must be covered, if you dont agree then thats ju= st your single opinion here. By the time you agree on everything we will be onto ANCP Version 4.10 !!! W= e are spending far too long on getting this draft out the door. ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NO= T defined anywhere (in any normative reference or RFC) does not seem to be = acceptable. The (minuted) discussion did not cover the notion of how ANCP "version inco= mpatibility" will be handled. Given that we're not out in the WG to create = version compatibility between an ANCP standard protocol and an ANCP non-sta= ndard based one (or GSMP for that matter), it would seem that no new defini= tion needs to take place. Feel free to discuss this further on this thread.= .. -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ala= n Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Exactly, hence we should ahve this explicitly noted in the draft. Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning In order to ease migration, it will help if BNGs are able to handle multipl= e peers with different versions (e.g. a 3.2 compliant BNG implementation ab= le to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, w= e may want to explicitly state that version compatibility requirement is on= an adjacency basis. The draft will also need to define how the version incompatibility between = BNG and AN needs to be handled. -Sanjay ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ala= n Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Cheers Woj The only point i would note (excuse if it was already raised on Monday as i= did not attend) is "backward compatibility" between the different versions= of 3.1, 3.2 and future versions if/when/as needed. this should be noted in= the draft. Alan ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is bei= ng defined. Also strictly speaking there is no distinction between version = and sub-version, so the choice of 3.2 is purely based on custom (it can equ= ally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatica= lly be 100% incompatible with the rfc. -Woj. ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al So are we agreeing that option 1 as noted on slide 15 in the Thomas's prese= ntation is what was agreed on at yesterdays meeting? BR Alan K ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All, During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP = versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-p= rotocol, however an RFC Editor's note will be introduced to change version = from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate a= ny pre-RFC implementations with post-RFC ones and alleviate the operators''= problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt) Going beyond the publication of the RFC, the introduction of new capabiliti= es or TLVs is expected to be handled by the capability negotiation mechanis= m (and new capabilities) or possibly by generalizing the notion of sub-capa= bility currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in= terms of anyone who was not able to voice their opinion at the meeting. Ba= sed on the received feedback, we'll make a call regarding the WG consensus = on this matter. Regards, Woj. --_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE3ECUSPITMAIL01ec_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Protocol Ver= sioning
Pe= ter,=20 Honyu
 
Wh= ilst a=20 vendor may decide unilaterally  to support  pre-standard=20 implementations  of  ANCP, it would be rather strange to see an R= FC=20 pointing out that pre-standard versions of the RFC SHOULD, or even=20 MAY be supported. 
 
In= deed it was=20 agreed that no explicit mention of pre-standard versions should be made wit= hin=20 the final RFC.
 
Trying to come up with heuristics to allow for= =20 interoperability with all of the pre-standard flavors of ANCP is not someth= ing=20 that was deemed desirable to put into an RFC.
 
"A= t least"=20 one can see from the version field that the RFC version is 3.2 and that=20 pre-standard versions are clearly identified, this should reduce the amount= of=20 logic to infer exactly what version of the draft is being=20 implemented.
 
On= e major=20 operator present was OK, reluctantly  but ok,  with =20 "merely" being able to differentiate the pre-standard versions as a whole f= rom=20 the standard version, hence bumping the version number provides a  way= of=20 resetting things and then ensuring that in the future any
ne= w TLVs, do=20 not overlap with other TLVs and that the capability negotiation mechanism i= s=20 used to differentiate new capabilities within the protocol without having t= o=20 bump versions again.
 
So= , whilst=20 not a perfect solution to fix all of the sins of the past, I think this is = a=20 reasonably pragmatic compromise.
 
Cheers
 
Rob
 

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Hongyu Li
Sent:<= /B>=20 Monday, August 10, 2009 2:52 AM
To: 'Peter Arberg'; 'Wojciech D= ec=20 (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'; ancp@ietf.org
Subject:=20 Re: [ANCP] ANCP Protocol Versioning

Hi Peter,
 
I guess you are afraid when a new BNG implementing A= NCP per=20 the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is = a=20 question that should go to operators having pre-rfc ANs. If they request = so,=20 we may have to define both 3.1 and 3.2 actions in the draft, which is rea= lly=20 odd. Otherwise, it is only a piece of cake. Everybody just follows=20 rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To:=20 Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
I did not realize it was last-call, I must hav= e missed=20 that email on the mailing list.
 
I agree with you that also to my knowledge dif= ferent=20 implementations have been able to
keep backward compatibility to earlier drafts,= and if=20 the introduction of the new version
number 3.2 is because of fear of non compatibl= e=20 implementations then it is not valid, as
it is very doable to have backwards compatible= to=20 previous drafts so far.
 
But in my mind it still seems like a good idea= to bump=20 the version number, if for nothing
else then to mark the ANCP standards first ste= p is=20 complete, and to move away one more
step to the GSMP tie.
 
But with the reference as you show and also al= l the=20 reference we still have to GSMP in the
draft document, it just seems like we are maki= ng it=20 very difficult for any newcomers to the
ANCP work to decide what to do and what not to= =20 do.
 
I'm not very afraid that vendors who already h= ave a=20 pre-standard ANCP implementation can
figure out what to do, but why not make it mor= e easy=20 for everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it=20 states:
---
   GSMP contains an adjacency protoc= ol. =20 The adjacency protocol is used
      to=20 synchronise states across the link, to negotiate which=20 version
      of the GSMP protocol to use, = to=20 discover the identity of the
      entity a= t the=20 other end of a link, and to detect when it=20 changes.
---
 
another place in the GSMP RFC it talks about a= minimum=20 set of messages which must be
supported for a version, so by having still GS= MP=20 reference in the ANCP draft, and yet no clear
statement on what protocol version we would ex= pect to=20 make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long section= , it can=20 be done in a small paragraph to describe
that the ANCP version of 3.2 should be able to= change=20 it's version to a lower pre-standard 3.1
version if it supports earlier drafts of=20 ANCP.
 
Do we know what happens to existing ANCP=20 implementations if the see a adjancy message
with a version number different from 3.1=20 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: 29. juli 2009 16:41
To= :=20 Peter Arberg; Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
so, based on the experience with the IESG review of las= t call=20 drafts, one has reason to believe that pulling a trick like= =20 referring to a  v3.1 in anything but non normative is not g= oing=20 fly (nor would it be reasonable if it happens to be exactly the same = as=20 v3.2). The time of making it to rfc of a v3.1 has very little to= do=20 with it, since the latest draft of the protocol spec is to our knowle= dge=20 100% compatible with "pre-standard" implementation except for new=20 capabilities.
Anyway, before we go off documenting all that, perhaps&= nbsp;a=20 step back should be taken to evaluate the situation:
- the currently deployed protocol, based on some set of the= =20 current drafts, has it's core functionality intact. I.e. Given t= hat=20 in all new activities we've strived for backwards compatibility, with= the=20 exception of historic tlv conflict, there doesn't seem to be much of = a=20 reason for v3.2
- the tlv conflict is inherent to a stage of ANCP developmen= t and=20 a v3.2 or its claims of backward compatibility to v3.1 (with=20 conflicting tlv set) are not going to matter; the affected = tlvs=20 will still clash, irrespective of "backwards compatibility" of=20 versions.
- Capability negotiation as offered by ANCP by itself p= rovides=20 a way to distinguish new protocol functions. It's here that the WG ha= s=20 been spending most of its time, and it's recognised as the way in whi= ch=20 the protocol will evolve (or via sub-capabilities)
- An operator has requested that a line be drawn to distingu= ish a=20 set of compatible pre-standard implementations (thus same=20 pre-standard versions)  that they are running and the actual sta= ndard=20 which may be in their opinion incompatible, hence v3.1 becomes t= o=20 v3.2. The same operator has not expressed a need to have an rfc for=20 v3.1
- Migrating from v3.1 to v3.2 is an operational activity for= which=20 the protocol does not appear to require modification (this appea= rs to=20 be no different than transitioning from L2TPv2 to v3=20 say).
- The current protocol draft states that the version SHOULD = be 3.1=20 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a stroke= to a=20 v3.2 when the rfc gets published we could try to navigate by having a= =20 clause which states that pre-rfc  eg v3.1 *may* be compatible an= d a=20 hint to reflect that version number to the sender but leaving=20 remaining behaviour un-specified (since there is no actual guarantee = of=20 compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg=20 [mailto:parberg@redback.com]
Sent: 29 July 2009=20 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadh= wa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
As I see it the problem is exactly that we= do not=20 have a normative reference in a RFC
simply because we have been too long to pu= t=20 anything together on the running code
which are deployed in live networks=20 today.
 
We have a L2CP reference in a TR document = and we=20 have live networks.
 
So if we decide to go for version 3.2 in t= he ANCP=20 WG, it would be very beneficial to have
a chapter in the RFC which describe migrat= ion from=20 pre-standard ANCP to the standard
RFC.
 
I'm sure carriers having pre-standard ANCP= running=20 in their network will like a clear RFC
statement for how we vendors should handle= a=20 incompatibility in a defacto ANCP standard
and the "real" ANCP RFC=20 standard.
 
So instead of a normative reference i will= suggest=20 that the RFC editor of the ANCP protocol
write a chapter and describe what is expec= ted when=20 a RFC standard ANCP ver. 3.2
implementation is getting adjancy connecti= on=20 request from a pre-standard ver. 3.1 ANCP
endpoint.
 
Too me this seems like a much too importan= t=20 question to simply ignore in a new protocol which
have been in the development for more than= 3 years,=20 and have had live networks in multi-vendor
deployments for a long time.=
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 29. juli 2009 12:22
To: Alan=20 Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: Re: [AN= CP]=20 ANCP Protocol Versioning

Your post bears no useful or constructive i= nput=20 regarding the topic. Attempting to define backwards compatibility= =20 means drawing on a normative reference to non-standard= =20 drafts and is not reasonable (a reading of http://tools.ietf.org= /html/rfc4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as to wh= ere=20 ANCP version 3.1 is defined and can be normatively referenced in = a=20 v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, excep= t for new=20 capabilities, then there is hardly a reason for a version change.= The=20 only way to have a reference to v3.1 in an rfc re v3.2 is either = as a=20 historic note, without claims of backwards compatibility, or publ= ish=20 two rfcs (a v3.1 and then a v3.2). Neither of these proposals see= m to=20 be appealing.
 
In addition, you may also want to refl= ect on=20 the quality of your conclusions and comprehension of general=20 facts...
 
-Woj.
 
From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 29 July 20= 09=20 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

So what are you sugegstin= g will=20 happen with current deployments....!!! Like it or not Woj, fact= is=20 it must be covered, if you dont agree then thats just your sing= le=20 opinion here.
 
By the time you agree on = everything=20 we will be onto ANCP Version 4.10 !!! We are spending far too l= ong=20 on getting this draft out the door.

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: July 29, 2009 10:01=20 AM
To: Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Sorry, but reference in a future ANCP v3.= 2 RFC to=20 a version 3.1 which is NOT defined anywhere (in any normative=20 reference or RFC) does not seem to be=20 acceptable.
The (minuted) discussion did not cover th= e notion=20 of how ANCP "version incompatibility" will be handled. Given th= at=20 we're not out in the WG to create version compatibility be= tween=20 an ANCP standard protocol and an ANCP non-standard based o= ne=20 (or GSMP for that matter), it would seem that no new defin= ition=20 needs to take place. Feel free to discuss this further on this= =20 thread...
 
-Woj.

From: ancp-bounces@ietf.o= rg=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: 29 July 2009 15:51
To: San= jay=20 Wadhwa; Wojciech Dec (wdec); ancp@ietf.org
Subject:= Re:=20 [ANCP] ANCP Protocol Versioning

= Exactly, hence we shoul= d ahve this=20 explicitly noted in the draft.
=  
= Alan
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: July 29, 2009 9= :48=20 AM
To: Alan Kavanagh; Wojciech Dec (wdec);=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

In= order=20 to ease migration, it will help if BNGs are able to handle=20 multiple peers with different versions (e.g. a 3.2 compliant = BNG=20 implementation able to work with a 3.1 AN and a 3.2 AN). Alth= ough=20 implied by the protocol, we may want to explicitly state that= =20 version compatibility requirement is on an adjacency=20 basis.

Th= e draft=20 will also need to define how the version incompatibility betw= een=20 BNG and AN needs to be handled.

 

-S= anjay

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent:= =20 Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec (wdec= );=20 ancp@ietf.org
Subject: Re: [ANCP] AN= CP=20 Protocol Versioning

=  

Ch= eers=20 Woj

=  

Th= e only=20 point i would note (excuse if it was already raised on Monday= as i=20 did not attend) is "backward compatibility" between the diffe= rent=20 versions of 3.1, 3.2 and future versions if/when/as needed. t= his=20 should be noted in the draft.

=  

Al= an

=  

From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com] Sent: July 29, 2009 3:= 33=20 AM
To: Ala= n=20 Kavanagh; ancp@ietf.org
Subject: RE: [ANCP] AN= CP=20 Protocol Versioning

Not entirely. A= NCP=20 already has a versioning field, hence nothing new is being=20 defined. Also strictly speaking there is no distinction= =20 between version and sub-version, so the choice of 3.2 is= =20 purely based on custom (it can equally well have been=20 4.0).

Of course this = will=20 mean that all "pre-rfc" implementations will automatically be= 100%=20 incompatible with the rfc.

=  

-Woj.

 

From: Alan Kavana= gh=20 [mailto:alan.kavanagh@ericsson.com]=20
Sent: 2= 8 July=20 2009 19:28
To:=20 Wojciech Dec (wdec); ancp@ietf.org
= Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

= Hi Woj=20 et.al

 

= So are=20 we agreeing that option 1 as noted on slide 15 in the Thoma= s's=20 presentation is what was agreed on at yesterdays=20 meeting?

 

= BR

= Alan=20 K

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciec= h Dec=20 (wdec)
Sent:= =20 July 28, 2009 5:30 AM
To: ancp@ietf.org
= Subject: [ANCP] ANCP= =20 Protocol Versioning

Hi=20 All,

During yester= day's=20 ANCP WG meeting at IET75 we discussed the topic of ANCP=20 versioning and in the room arrived at the following=20 conclusion:

The Pre-RFC v= ersion=20 of ANC will continue to be 3.1 as per draft-ietf-ancp-proto= col,=20 however an RFC Editor's note will be introduced to change=20 version from 3.1 to 3.2 upon publication of the RFC. This w= ill=20 clearly de-lineate any pre-RFC implementations with post-RF= C=20 ones and alleviate the operators'' problems presented=20 (http://www3.i= etf.org/proceedings/75/slides/ancp-3.ppt)

Going beyond = the=20 publication of the RFC, the introduction of new capabilitie= s or=20 TLVs is expected to be handled by the capability negotiatio= n=20 mechanism (and new capabilities) or possibly by generalizin= g the=20 notion of sub-capability currently in place for the=20 multicast-control use-cases.

We would like= to get=20 feedback from the wider WG on the above, especially in term= s of=20 anyone who was not able to voice their opinion at the meeti= ng.=20 Based on the received feedback, we'll make a call regarding= the=20 WG consensus on this matter.

Regards,=20
Woj.=20

<= /HTML> --_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE3ECUSPITMAIL01ec_-- From lihy@huawei.com Mon Aug 10 18:36:29 2009 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 E1D483A6D96 for ; Mon, 10 Aug 2009 18:36:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.886 X-Spam-Level: X-Spam-Status: No, score=-0.886 tagged_above=-999 required=5 tests=[AWL=0.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6] 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 Vi5zFmqAw8fV for ; Mon, 10 Aug 2009 18:36:26 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id A598C3A6A64 for ; Mon, 10 Aug 2009 18:36:25 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO6003OEV4O3A@szxga01-in.huawei.com> for ancp@ietf.org; Tue, 11 Aug 2009 09:36:25 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KO600E1AV4OON@szxga01-in.huawei.com> for ancp@ietf.org; Tue, 11 Aug 2009 09:36:24 +0800 (CST) Received: from L26465 ([10.70.40.87]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KO6001EYV4OM4@szxml04-in.huawei.com> for ancp@ietf.org; Tue, 11 Aug 2009 09:36:24 +0800 (CST) Date: Tue, 11 Aug 2009 09:36:24 +0800 From: Hongyu Li In-reply-to: <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> To: 'Robert Rennison' , 'Alan Kavanagh' , Peter.Hamacher@telekom.de, 'Peter Arberg' , wdec@cisco.com, swadhwa@juniper.net, ancp@ietf.org Message-id: <047601ca1a24$23151710$5728460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_J2BYpOtAT1EI5iOXz6NGzQ)" Thread-index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60AADyFzwAA9NFwAAB2HpsAAM7s+Q Cc: HaagT@telekom.de, B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning 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, 11 Aug 2009 01:36:30 -0000 This is a multi-part message in MIME format. --Boundary_(ID_J2BYpOtAT1EI5iOXz6NGzQ) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable Robert, =20 I agree with most of your comments. There is only one problem I have = regarding to your proposal, actually this applies to Alan's proposal also. If we say something in the document that you may need to = talk to a device in a language with version 3.1, but we say nothing about what are the actions of this language v3.1 while we know = that they are different from actions of v3.2, such description will lose its guidance to readers. =20 If we say something of supporting v3.1, we may have to say what it = really is. Otherwise, we don't say anything about it. I personally prefer the latter, which is simple. It shall not be the = burden of this future RFC to carry all historical residue. =20 cheers, Hongyu =20 _____ =20 From: Robert Rennison [mailto:Robert.Rennison@ecitele.com]=20 Sent: Tuesday, August 11, 2009 4:04 AM To: Alan Kavanagh; Peter.Hamacher@telekom.de; lihy@huawei.com; Peter = Arberg; wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: RE: [ANCP] ANCP Protocol Versioning Alan, =20 Ok so perhaps the RFC may use a "may" but in a non normative section. =20 A lot would depend on where in the document you wished to place any such = note. As Woj pointed out in an earlier email, anything in a normative section would most likely not get past the editors. =20 Perhaps an appendix " =20 I'd be reluctant to cover how to negotiate the version. Your reference = to section 5.3 refers to capabilities negotiation not version negotiation which is covered in section 11.1 of 3292 where the = version negotiation is discussed, note however that this refers to a single version field not the version/sub version field as = used in ANCP. Once you get into mentioning the version negotiation then one would have to cover how one tell the difference = between versions of the versions i.e. between these versions using Version 3.1 draft-wadwha- vs draft-ietf-ancp-.... . =20 =20 Hence it would perhaps be better to omit anything about how to do any = version negotiation. say that the RFC compliant version may use the version/subversion field to detect a pre-standard implementation = and that this maybe done on a per peer basis such that a given NAS may support both Standards compliant 3.2 and pre-standard =20 How about. =20 -------------------------------------------------------------------------= -------------- Appendix. Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative =20 Prior to completion of this document, several pre-RFC versions of the = protocol were documented and implemented.=20 There were numerous pre-standard versions of the protocol all using a = version/subversion field set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document may, on = a peer basis, use the version and subversion field to detect a pre-RFC implementation of the protocol and choose to work = with such pre-RFC peers ( e.g NAS or DSLAM) -------------------------------------------------------------------------= ---------- =20 Note lower case "may" since I'm not sure that upper case MAY applies in = non-normative text. =20 Cheers =20 Rob _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: Monday, August 10, 2009 11:46 AM To: Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; = wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning Hi All I typed up some text to include in the ancp protocol draft,based on some = discussions. So from reading the minutes it appears that the WG has agreed on moving the sub-version number to 2, which gives us = Version/Sub 3.2. It makes sense to have this clearly noted in the ietf-ancp-protocol draft. I suggest on adding the following text = to the ancp protocol draft to provide a clear reasoning and for the uplift and move us forward: Prior to initiation of this work, existing ANCP deployments used an ANCP = Protocol Version/Sub-Version 3.1. which differs in the TLV's from this RFC standards track version. Therefore RFC compliant = versions MAY choose to work with such pre-RFC peers (NAS and DSLAM).=20 A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp = protocol Version/Sub-Version is set on a per peer basis and is synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section 5.3. to agree on the protocol version to use.=20 Alan _____ =20 From: Peter.Hamacher@telekom.de [mailto:Peter.Hamacher@telekom.de]=20 Sent: August 10, 2009 11:35 AM To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kavanagh; = swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Protocol Versioning Hi all, =20 from our perspective it is essential to have a practible way to migrate = to RFC. =20 regards Peter Hamacher Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Peter Hamacher Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2864 (Tel.) +49 521 92100494 (Fax) E-Mail: Peter.Hamacher@telekom.de http://www.telekom.com =20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Erleben, was verbindet. =20 _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Hongyu Li Gesendet: Montag, 10. August 2009 08:52 An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay = Wadhwa'; ancp@ietf.org Betreff: Re: [ANCP] ANCP Protocol Versioning Hi Peter, =20 I guess you are afraid when a new BNG implementing ANCP per the future = RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question that should go to operators having pre-rfc ANs. If they = request so, we may have to define both 3.1 and 3.2 actions in the draft, which is really odd. Otherwise, it is only a piece of cake. = Everybody just follows rfc. =20 cheers, Hongyu =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Peter Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Hi Woj, =20 I did not realize it was last-call, I must have missed that email on the = mailing list. =20 I agree with you that also to my knowledge different implementations = have been able to keep backward compatibility to earlier drafts, and if the introduction = of the new version=20 number 3.2 is because of fear of non compatible implementations then it = is not valid, as it is very doable to have backwards compatible to previous drafts so = far. =20 But in my mind it still seems like a good idea to bump the version = number, if for nothing else then to mark the ANCP standards first step is complete, and to move = away one more step to the GSMP tie.=20 =20 But with the reference as you show and also all the reference we still = have to GSMP in the=20 draft document, it just seems like we are making it very difficult for = any newcomers to the=20 ANCP work to decide what to do and what not to do. =20 I'm not very afraid that vendors who already have a pre-standard ANCP = implementation can figure out what to do, but why not make it more easy for everyboby by = having a little more description on this. =20 In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. --- =20 another place in the GSMP RFC it talks about a minimum set of messages = which must be supported for a version, so by having still GSMP reference in the ANCP = draft, and yet no clear statement on what protocol version we would expect to make an adjency = seems wrong to me. =20 =20 In my mind it do not have to be a long section, it can be done in a = small paragraph to describe that the ANCP version of 3.2 should be able to change it's version to a = lower pre-standard 3.1=20 version if it supports earlier drafts of ANCP. =20 Do we know what happens to existing ANCP implementations if the see a = adjancy message with a version number different from 3.1 ? =20 cheers, Peter =20 =20 =20 =20 _____ =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Peter, =20 so, based on the experience with the IESG review of last call drafts, = one has reason to believe that pulling a trick like referring to a v3.1 in anything but non normative is not going fly (nor would it = be reasonable if it happens to be exactly the same as v3.2). The time of making it to rfc of a v3.1 has very little to do with it, = since the latest draft of the protocol spec is to our knowledge 100% compatible with "pre-standard" implementation except for = new capabilities. Anyway, before we go off documenting all that, perhaps a step back = should be taken to evaluate the situation: - the currently deployed protocol, based on some set of the current = drafts, has it's core functionality intact. I.e. Given that in all new activities we've strived for backwards compatibility, with the = exception of historic tlv conflict, there doesn't seem to be much of a reason for v3.2 - the tlv conflict is inherent to a stage of ANCP development and a v3.2 = or its claims of backward compatibility to v3.1 (with conflicting tlv set) are not going to matter; the affected tlvs will = still clash, irrespective of "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way to = distinguish new protocol functions. It's here that the WG has been spending most of its time, and it's recognised as the way in = which the protocol will evolve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set of = compatible pre-standard implementations (thus same pre-standard versions) that they are running and the actual standard = which may be in their opinion incompatible, hence v3.1 becomes to v3.2. The same operator has not expressed a need to have an rfc for = v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which the = protocol does not appear to require modification (this appears to be no different than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 = (which appears to need a correction) =20 Based on the above, it seems to me that if we go at a stroke to a v3.2 = when the rfc gets published we could try to navigate by having a clause which states that pre-rfc eg v3.1 *may* be compatible = and a hint to reflect that version number to the sender but leaving remaining behaviour un-specified (since there is no actual = guarantee of compatibility). How does this sound? =20 Cheers, Woj. _____ =20 From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj, =20 As I see it the problem is exactly that we do not have a normative = reference in a RFC simply because we have been too long to put anything together on the = running code which are deployed in live networks today. =20 We have a L2CP reference in a TR document and we have live networks. =20 So if we decide to go for version 3.2 in the ANCP WG, it would be very = beneficial to have a chapter in the RFC which describe migration from pre-standard ANCP to = the standard RFC. =20 I'm sure carriers having pre-standard ANCP running in their network will = like a clear RFC statement for how we vendors should handle a incompatibility in a = defacto ANCP standard and the "real" ANCP RFC standard. =20 So instead of a normative reference i will suggest that the RFC editor = of the ANCP protocol=20 write a chapter and describe what is expected when a RFC standard ANCP = ver. 3.2=20 implementation is getting adjancy connection request from a pre-standard = ver. 3.1 ANCP endpoint. =20 Too me this seems like a much too important question to simply ignore in = a new protocol which have been in the development for more than 3 years, and have had live = networks in multi-vendor deployments for a long time. =20 thanks, Peter _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Your post bears no useful or constructive input regarding the topic. = Attempting to define backwards compatibility means drawing on a normative reference to non-standard drafts and is not reasonable (a = reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as to where ANCP = version 3.1 is defined and can be normatively referenced in a v3.2 RFC?=20 If v3.2 and v3.1 are 100% compatible, except for new capabilities, then = there is hardly a reason for a version change. The only way to have a reference to v3.1 in an rfc re v3.2 is either as a historic = note, without claims of backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be = appealing. =20 In addition, you may also want to reflect on the quality of your = conclusions and comprehension of general facts... =20 -Woj. =20 _____ =20 From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning So what are you sugegsting will happen with current deployments....!!! = Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here. =20 By the time you agree on everything we will be onto ANCP Version 4.10 = !!! We are spending far too long on getting this draft out the door. _____ =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is = NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP "version = incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol = and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel = free to discuss this further on this thread... =20 -Woj. _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning In order to ease migration, it will help if BNGs are able to handle = multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although = implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility = between BNG and AN needs to be handled. =20 -Sanjay _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on Monday = as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. = this should be noted in the draft. =20 Alan =20 _____ =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is = being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is = purely based on custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will = automatically be 100% incompatible with the rfc. =20 -Woj. =20 _____ =20 From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's = presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of = ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol, however an RFC Editor's note will be = introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will = clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented ( = http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt) Going beyond the publication of the RFC, the introduction of new = capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing = the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially = in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call = regarding the WG consensus on this matter. Regards,=20 Woj.=20 --Boundary_(ID_J2BYpOtAT1EI5iOXz6NGzQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable ANCP Protocol = Versioning
Robert,
 
I agree with most of your comments. There is only one = problem I=20 have regarding to your proposal, actually this applies to Alan's = proposal=20 also. If we say something in the document that you may need to talk to a = device=20 in a language with version 3.1, but we say nothing about what are the = actions of=20 this language v3.1 while we know that they are different from actions of = v3.2,=20 such description will lose its guidance to readers.
 
If we say something of supporting v3.1, we may have = to say=20 what it really is. Otherwise, we don't say anything about it. I = personally=20 prefer the latter, which is simple. It shall not be the burden of this = future=20 RFC to carry all historical residue.
 
cheers,
Hongyu
 

From: Robert Rennison=20 [mailto:Robert.Rennison@ecitele.com]
Sent: Tuesday, August = 11, 2009=20 4:04 AM
To: Alan Kavanagh; Peter.Hamacher@telekom.de;=20 lihy@huawei.com; Peter Arberg; wdec@cisco.com; swadhwa@juniper.net;=20 ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Alan,
 
Ok so=20 perhaps the RFC may use a "may" but in a non normative=20 section.
 
A lot would=20 depend on where in the document you wished to place any such note. As = Woj=20 pointed out in an earlier email, anything in a normative section would = most=20 likely not get past the editors.
 
Perhaps an=20 appendix "
 
I'd be=20 reluctant to cover how to negotiate the version.  Your reference = to=20 section 5.3 refers to capabilities negotiation not  version = negotiation=20 which is covered in  section 11.1 of 3292  where the version = negotiation is discussed, note however that this refers to a single = version=20 field not the version/sub version field as used in ANCP. Once you get = into=20 mentioning the version  negotiation then one would have to cover = how one=20 tell the difference between  versions of the versions i.e. = between these=20 versions using Version 3.1  draft-wadwha- vs=20 draft-ietf-ancp-....  .
 
 
Hence it=20 would perhaps be better to  omit anything about how to do any = version=20 negotiation. say that the RFC compliant version may use the = version/subversion=20 field to detect a pre-standard implementation and that this maybe done = on a=20 per peer basis such that a given NAS may support both Standards=20 compliant  3.2  and pre-standard
 
How=20 about.
 
---------------------------------------------------------= ------------------------------
Appendix.=20 Handling of pre-RFC deployments of the ANCP =  protocol
 
This=20 appendix is non normative
 
Prior to=20 completion of this document, several pre-RFC  versions of the = protocol=20 were documented and implemented.
There were=20 numerous pre-standard versions of the protocol all using a=20 version/subversion field set to 3.1.
 
A NAS=20 implementing the ANCP protocol as defined in this document may, on a = peer=20 basis, use the version and subversion field
to detect a=20 pre-RFC implementation of the protocol and choose to work with such = pre-RFC=20 peers ( e.g NAS or DSLAM)
---------------------------------------------------------= --------------------------
 
Note lower=20 case "may" since I'm not sure that upper case MAY applies in = non-normative=20 text.
 
Cheers
 
Rob

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: Monday, August 10, 2009 11:46 = AM
To:=20 Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; = wdec@cisco.com;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi All

I typed up some text to = include in=20 the ancp protocol draft,based on = some=20 discussions. So from reading the minutes it appears = that the=20 WG has agreed on moving the sub-version number to 2, which gives us=20 Version/Sub 3.2. It makes sense to have this clearly noted in the=20 ietf-ancp-protocol draft. I suggest on adding the following text to = the ancp=20 protocol draft to provide a clear = reasoning=20 and for the uplift and move us forward:

Prior to initiation of this work, existing ANCP deployments used = an ANCP=20 Protocol Version/Sub-Version 3.1. which differs in the TLV's from = this RFC=20 standards track version. Therefore RFC compliant versions MAY choose = to work=20 with such pre-RFC peers (NAS and DSLAM).

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The = ancp=20 protocol Version/Sub-Version is set on a per peer basis and is=20 synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section=20 5.3. to agree on the protocol version to use.

Alan

From: Peter.Hamacher@telekom.de=20 [mailto:Peter.Hamacher@telekom.de]
Sent: August 10, 2009 = 11:35=20 AM
To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan = Kavanagh; swadhwa@juniper.net; ancp@ietf.org
Cc: = HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: AW: [ANCP] ANCP Protocol=20 Versioning

Hi all,
 
from our perspective it is essential to = have a=20 practible way to migrate to = RFC.
 

regards
Peter=20 Hamacher


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik=20 Einf=FChrung
Peter Hamacher
Heinrich-Hertz-Stra=DFe 3-7, 64295 = Darmstadt
+49 6151 628 2864 (Tel.)
+49 521 92100494 = (Fax)
E-Mail:=20 Peter.Hamacher@telekom.de
http://www.telekom.com

Deutsche Telekom = Netzproduktion=20 GmbH
Aufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
Gesch=E4ftsf=FChrung:=20 Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der=20 Gesellschaft: Bonn
USt-IdNr.: DE 814645262

Erleben, was = verbindet.

 

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Hongyu=20 Li
Gesendet: Montag, 10. August 2009 08:52
An: = 'Peter=20 Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa';=20 ancp@ietf.org
Betreff: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
I guess you are afraid when a new BNG = implementing ANCP=20 per the future RFC, whether it can talk to pre-rfc version AN. IMHO, = this is=20 a question that should go to operators having pre-rfc ANs. If they = request=20 so, we may have to define both 3.1 and 3.2 actions in the draft, = which is=20 really odd. Otherwise, it is only a piece of cake. Everybody just = follows=20 rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: Thursday, July 30, 2009 8:38 = AM
To:=20 Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
I did not realize it was last-call, I = must have=20 missed that email on the mailing list.
 
I agree with you that also to my = knowledge different=20 implementations have been able to
keep backward compatibility to earlier = drafts, and if=20 the introduction of the new version
number 3.2 is because of fear of non = compatible=20 implementations then it is not valid, as
it is very doable to have backwards = compatible to=20 previous drafts so far.
 
But in my mind it still seems like a good = idea to=20 bump the version number, if for nothing
else then to mark the ANCP standards = first step is=20 complete, and to move away one more
step to the GSMP tie. =
 
But with the reference as you show and = also all the=20 reference we still have to GSMP in the
draft document, it just seems like we are = making it=20 very difficult for any newcomers to the
ANCP work to decide what to do and what = not to=20 do.
 
I'm not very afraid that vendors who = already have a=20 pre-standard ANCP implementation can
figure out what to do, but why not make = it more easy=20 for everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it=20 states:
---
   GSMP contains an adjacency=20 protocol.  The adjacency protocol is=20 used
      to synchronise states = across the=20 link, to negotiate which version
      = of the=20 GSMP protocol to use, to discover the identity of=20 the
      entity at the other end of a = link,=20 and to detect when it changes.
---
 
another place in the GSMP RFC it talks = about a=20 minimum set of messages which must be
supported for a version, so by having = still GSMP=20 reference in the ANCP draft, and yet no clear
statement on what protocol version we = would expect to=20 make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long = section, it=20 can be done in a small paragraph to describe
that the ANCP version of 3.2 should be = able to change=20 it's version to a lower pre-standard 3.1
version if it supports earlier drafts of=20 ANCP.
 
Do we know what happens to existing ANCP=20 implementations if the see a adjancy message
with a version number different from 3.1=20 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: 29. juli 2009=20 16:41
To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
so, based on the experience with the IESG review = of last=20 call drafts, one has reason to believe that pulling a = trick=20 like referring to a  v3.1 in anything but non = normative is not=20 going fly (nor would it be reasonable if it happens to be = exactly the=20 same as v3.2). The time of making it to rfc of a v3.1 has = very=20 little to do with it, since the latest draft of the protocol = spec is to=20 our knowledge 100% compatible with "pre-standard" implementation = except=20 for new capabilities.
Anyway, before we go off documenting all that,=20 perhaps a step back should be taken to evaluate the=20 situation:
- the currently deployed protocol, based on some set of = the=20 current drafts, has it's core functionality intact. I.e. = Given that=20 in all new activities we've strived for backwards compatibility, = with=20 the exception of historic tlv conflict, there doesn't seem to be = much of=20 a reason for v3.2
- the tlv conflict is inherent to a stage of ANCP = development and=20 a v3.2 or its claims of backward compatibility to v3.1 = (with=20 conflicting tlv set) are not going to matter;=20 the affected tlvs will still clash, irrespective of = "backwards=20 compatibility" of versions.
- Capability negotiation as offered by ANCP by=20 itself provides a way to distinguish new protocol = functions. It's=20 here that the WG has been spending most of its time, and it's = recognised=20 as the way in which the protocol will evolve (or via=20 sub-capabilities)
- An operator has requested that a line be drawn to = distinguish a=20 set of compatible pre-standard implementations (thus same=20 pre-standard versions)  that they are running and the = actual=20 standard which may be in their opinion incompatible, = hence v3.1=20 becomes to v3.2. The same operator has not expressed a need to = have an=20 rfc for v3.1
- Migrating from v3.1 to v3.2 is an operational = activity for=20 which the protocol does not appear to require = modification (this=20 appears to be no different than transitioning from L2TPv2 to v3=20 say).
- The current protocol draft states that the version = SHOULD be=20 3.1 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a = stroke to a=20 v3.2 when the rfc gets published we could try to navigate by = having a=20 clause which states that pre-rfc  eg v3.1 *may* be = compatible and a=20 hint to reflect that version number to the sender but = leaving=20 remaining behaviour un-specified (since there is no actual = guarantee of=20 compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg=20 [mailto:parberg@redback.com]
Sent: 29 July 2009=20 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay = Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi = Woj,
 
As I see it the problem = is exactly=20 that we do not have a normative reference in a = RFC
simply because we have = been too long=20 to put anything together on the running = code
which are deployed in = live networks=20 today.
 
We have a L2CP reference = in a TR=20 document and we have live networks.
 
So if we decide to go = for version 3.2=20 in the ANCP WG, it would be very beneficial to=20 have
a chapter in the RFC = which describe=20 migration from pre-standard ANCP to the = standard
RFC.
 
I'm sure carriers having = pre-standard=20 ANCP running in their network will like a clear=20 RFC
statement for how we = vendors should=20 handle a incompatibility in a defacto ANCP=20 standard
and the "real" ANCP RFC=20 standard.
 
So instead of a = normative reference i=20 will suggest that the RFC editor of the ANCP protocol=20
write a chapter and = describe what is=20 expected when a RFC standard ANCP ver. 3.2 =
implementation is = getting adjancy=20 connection request from a pre-standard ver. 3.1=20 ANCP
endpoint.
 
Too me this seems like a = much too=20 important question to simply ignore in a new protocol=20 which
have been in the = development for more=20 than 3 years, and have had live networks=20 in multi-vendor
deployments for a long=20 time.
 
thanks,
Peter

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech = Dec=20 (wdec)
Sent: 29. juli 2009 12:22
To: = Alan=20 Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: = Re: [ANCP]=20 ANCP Protocol Versioning

Your post bears no useful or = constructive input=20 regarding the topic. Attempting to define backwards = compatibility=20 means drawing on a normative reference to = non-standard=20 drafts and is not reasonable (a reading of http://tools.ietf.org/html/rf= c4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as = to where=20 ANCP version 3.1 is defined and can be normatively = referenced in a=20 v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, = except for=20 new capabilities, then there is hardly a reason for a = version=20 change. The only way to have a reference to v3.1 in an rfc = re v3.2=20 is either as a historic note, without claims of backwards=20 compatibility, or publish two rfcs (a v3.1 and then a v3.2). = Neither=20 of these proposals seem to be appealing.
 
In addition, you may also want to = reflect on=20 the quality of your conclusions and comprehension of general = facts...
 
-Woj.
 
From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 29 = July 2009=20 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

So what are you = sugegsting will=20 happen with current deployments....!!! Like it or not Woj, = fact is=20 it must be covered, if you dont agree then thats just your = single=20 opinion here.
 
By the time you = agree on=20 everything we will be onto ANCP Version 4.10 !!! We are = spending=20 far too long on getting this draft out the=20 door.

From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com]
Sent: July 29, 2009 = 10:01=20 AM
To: Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Sorry, but reference in a future = ANCP v3.2 RFC=20 to a version 3.1 which is NOT defined anywhere (in any = normative=20 reference or RFC) does not seem to be=20 acceptable.
The (minuted) discussion did not = cover the=20 notion of how ANCP "version incompatibility" will be = handled.=20 Given that we're not out in the WG to create version=20 compatibility between an ANCP standard protocol and an=20 ANCP non-standard based one (or GSMP for that = matter), it=20 would seem that no new definition needs to take = place. Feel=20 free to discuss this further on this = thread...
 
-Woj.

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: 29 July 2009 = 15:51
To: Sanjay=20 Wadhwa; Wojciech Dec (wdec); = ancp@ietf.org
Subject:=20 Re: [ANCP] ANCP Protocol Versioning

Exactly, hence we = should ahve=20 this explicitly noted in the draft.
 
Alan

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: July 29, = 2009 9:48=20 AM
To: Alan Kavanagh; Wojciech Dec (wdec);=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP = Protocol=20 Versioning

In=20 order to ease migration, it will help if BNGs are able = to handle=20 multiple peers with different versions (e.g. a 3.2 = compliant BNG=20 implementation able to work with a 3.1 AN and a 3.2 AN). = Although implied by the protocol, we may want to = explicitly=20 state that version compatibility requirement is on an = adjacency=20 basis.

The=20 draft will also need to define how the version = incompatibility=20 between BNG and AN needs to be=20 handled.

 

-Sanjay

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of Alan = Kavanagh
Sent:=20 Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec = (wdec);=20 ancp@ietf.org
Subject: Re: = [ANCP] ANCP=20 Protocol Versioning

 

Cheers=20 Woj

 

The=20 only point i would note (excuse if it was already raised = on=20 Monday as i did not attend) is "backward compatibility" = between=20 the different versions of 3.1, 3.2 and future versions=20 if/when/as needed. this should be noted in the=20 draft.

 

Alan

 

From: Wojciech = Dec=20 (wdec) [mailto:wdec@cisco.com]=20
Sent: July 29,=20 2009 3:33 AM
To: Alan = Kavanagh;=20 ancp@ietf.org
Subject: RE: = [ANCP] ANCP=20 Protocol Versioning

Not = entirely. ANCP=20 already has a versioning field, hence nothing new is = being=20 defined. Also strictly speaking there is no = distinction=20 between version and sub-version, so the choice of = 3.2 is=20 purely based on custom (it can equally well have been=20 4.0).

Of course = this will=20 mean that all "pre-rfc" implementations will = automatically be=20 100% incompatible with the = rfc.

 

-Woj.

 

From: Alan = Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]=20
Sent: 28=20 July 2009 19:28
To: Wojciech = Dec (wdec);=20 ancp@ietf.org
Subject: RE: = [ANCP] ANCP=20 Protocol Versioning

Hi=20 Woj et.al

 

So=20 are we agreeing that option 1 as noted on slide 15 in = the=20 Thomas's presentation is what was agreed on at = yesterdays=20 meeting?

 

BR

Alan=20 K

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of = Wojciech Dec=20 (wdec)
Sent:=20 July 28, 2009 5:30 AM
To: = ancp@ietf.org
Subject: [ANCP] = ANCP=20 Protocol Versioning

Hi=20 All, =

During = yesterday's=20 ANCP WG meeting at IET75 we discussed the topic of = ANCP=20 versioning and in the room arrived at the following=20 conclusion:

The = Pre-RFC=20 version of ANC will continue to be 3.1 as per=20 draft-ietf-ancp-protocol, however an RFC Editor's note = will be=20 introduced to change version from 3.1 to 3.2 upon = publication=20 of the RFC. This will clearly de-lineate any pre-RFC=20 implementations with post-RFC ones and alleviate the=20 operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going = beyond the=20 publication of the RFC, the introduction of new = capabilities=20 or TLVs is expected to be handled by the capability=20 negotiation mechanism (and new capabilities) or = possibly by=20 generalizing the notion of sub-capability currently in = place=20 for the multicast-control=20 use-cases.

We would = like to=20 get feedback from the wider WG on the above, = especially in=20 terms of anyone who was not able to voice their = opinion at the=20 meeting. Based on the received feedback, we'll make a = call=20 regarding the WG consensus on this=20 matter.

Regards,=20
Woj.=20 =

<= /BODY> --Boundary_(ID_J2BYpOtAT1EI5iOXz6NGzQ)-- From alan.kavanagh@ericsson.com Wed Aug 12 14:30:43 2009 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 5011628C14C for ; Wed, 12 Aug 2009 14:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.773 X-Spam-Level: X-Spam-Status: No, score=-5.773 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4] 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 nnaud3V9Qmeq for ; Wed, 12 Aug 2009 14:30:39 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id CC1ED28C11C for ; Wed, 12 Aug 2009 14:30:38 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n7CLSxu5014794; Wed, 12 Aug 2009 16:28:59 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Aug 2009 16:28:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1B93.E588698A" Date: Wed, 12 Aug 2009 17:28:55 -0400 Message-ID: <35815C929B41D2479A224FE098A2722707A629DE@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60AADyFzwAA9NFwAAB2HpsABoONnA References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de> <35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> From: "Alan Kavanagh" To: "Robert Rennison" , , , "Peter Arberg" , , , X-OriginalArrivalTime: 12 Aug 2009 21:28:56.0649 (UTC) FILETIME=[E601A390:01CA1B93] Cc: HaagT@telekom.de, B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning 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, 12 Aug 2009 21:30:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1B93.E588698A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert =20 We are prety mush saying the same here on this. I would agree on having = this outlined in an appendix though ill leave that to Sanjay et.al = editors to decide where best to fit such text. =20 My reference to the negotiation protocol is from RFC3292 in section 11.1 = (as you also note) which covers the 8-bit Version number of which we now = use the full 8-bits for the Version+Sub_version and i see nothing = preventing us from using this, though i agree with you that RFC3292 does = not cover the sub-version number, but that's something we can modify to = support the sub-vers field.=20 =20 The MAY is always set in uppercase in the RFC.=20 =20 How about: =20 Prior to completion of this RFC, several pre-RFC versions of the = protocol were documented, implemented and deployed in Service Providers = Access Network which used an ANCP protocol Version/Sub-Version set to = 3.1. =20 A NAS implementing the NAS protocol defined in this RFC, may on a per = peer basis, use the Version and Sub-Version fields to detect a pre RFC = implementation of the ANCP protocol and choose to work with such pre-RFC = peers (NAS and DSLAM). =20 Also, as Peter and Sanjay have noted on previous emails on this thread = it should be captured in the draft (small paragraph) on how to handle = adjacency connections when a RFC-standards compliant ANCP node (3.2) = receives an adjacency connection request from a version/sub-version 3.1 = ANCP node?=20 =20 Alan =20 ________________________________ From: Robert Rennison [mailto:Robert.Rennison@ecitele.com]=20 Sent: August 10, 2009 4:04 PM To: Alan Kavanagh; Peter.Hamacher@telekom.de; lihy@huawei.com; Peter = Arberg; wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: RE: [ANCP] ANCP Protocol Versioning Alan, =20 Ok so perhaps the RFC may use a "may" but in a non normative section. =20 A lot would depend on where in the document you wished to place any such = note. As Woj pointed out in an earlier email, anything in a normative = section would most likely not get past the editors. =20 Perhaps an appendix " =20 I'd be reluctant to cover how to negotiate the version. Your reference = to section 5.3 refers to capabilities negotiation not version = negotiation which is covered in section 11.1 of 3292 where the version = negotiation is discussed, note however that this refers to a single = version field not the version/sub version field as used in ANCP. Once = you get into mentioning the version negotiation then one would have to = cover how one tell the difference between versions of the versions i.e. = between these versions using Version 3.1 draft-wadwha- vs = draft-ietf-ancp-.... . =20 =20 Hence it would perhaps be better to omit anything about how to do any = version negotiation. say that the RFC compliant version may use the = version/subversion field to detect a pre-standard implementation and = that this maybe done on a per peer basis such that a given NAS may = support both Standards compliant 3.2 and pre-standard =20 How about. =20 -------------------------------------------------------------------------= -------------- Appendix. Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative =20 Prior to completion of this document, several pre-RFC versions of the = protocol were documented and implemented.=20 There were numerous pre-standard versions of the protocol all using a = version/subversion field set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document may, on = a peer basis, use the version and subversion field to detect a pre-RFC implementation of the protocol and choose to work = with such pre-RFC peers ( e.g NAS or DSLAM) -------------------------------------------------------------------------= ---------- =20 Note lower case "may" since I'm not sure that upper case MAY applies in = non-normative text. =20 Cheers =20 Rob ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: Monday, August 10, 2009 11:46 AM To: Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; = wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Hi All I typed up some text to include in the ancp protocol draft,based on = some discussions. So from reading the minutes it appears that the WG has = agreed on moving the sub-version number to 2, which gives us Version/Sub = 3.2. It makes sense to have this clearly noted in the ietf-ancp-protocol = draft. I suggest on adding the following text to the ancp protocol draft = to provide a clear reasoning and for the uplift and move us forward: Prior to initiation of this work, existing ANCP deployments used an = ANCP Protocol Version/Sub-Version 3.1. which differs in the TLV's from = this RFC standards track version. Therefore RFC compliant versions MAY = choose to work with such pre-RFC peers (NAS and DSLAM).=20 A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp = protocol Version/Sub-Version is set on a per peer basis and is = synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section 5.3. to agree on the protocol version to use.=20 Alan =09 ________________________________ From: Peter.Hamacher@telekom.de [mailto:Peter.Hamacher@telekom.de]=20 Sent: August 10, 2009 11:35 AM To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kavanagh; = swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Protocol Versioning =09 =09 Hi all, =20 from our perspective it is essential to have a practible way to migrate = to RFC. =20 regards Peter Hamacher =09 =09 Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Peter Hamacher Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2864 (Tel.) +49 521 92100494 (Fax) E-Mail: Peter.Hamacher@telekom.de =20 http://www.telekom.com =20 =09 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 =09 Erleben, was verbindet. =09 =09 =20 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag = von Hongyu Li Gesendet: Montag, 10. August 2009 08:52 An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay = Wadhwa'; ancp@ietf.org Betreff: Re: [ANCP] ANCP Protocol Versioning =09 =09 Hi Peter, =20 I guess you are afraid when a new BNG implementing ANCP per the future = RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question = that should go to operators having pre-rfc ANs. If they request so, we = may have to define both 3.1 and 3.2 actions in the draft, which is = really odd. Otherwise, it is only a piece of cake. Everybody just = follows rfc. =20 =09 =09 cheers, Hongyu =09 =20 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf = Of Peter Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Hi Woj, =20 I did not realize it was last-call, I must have missed that email on = the mailing list. =20 I agree with you that also to my knowledge different implementations = have been able to keep backward compatibility to earlier drafts, and if the introduction = of the new version=20 number 3.2 is because of fear of non compatible implementations then = it is not valid, as it is very doable to have backwards compatible to previous drafts so = far. =20 But in my mind it still seems like a good idea to bump the version = number, if for nothing else then to mark the ANCP standards first step is complete, and to = move away one more step to the GSMP tie.=20 =20 But with the reference as you show and also all the reference we still = have to GSMP in the=20 draft document, it just seems like we are making it very difficult for = any newcomers to the=20 ANCP work to decide what to do and what not to do. =20 I'm not very afraid that vendors who already have a pre-standard ANCP = implementation can figure out what to do, but why not make it more easy for everyboby by = having a little more description on this. =20 In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is = used to synchronise states across the link, to negotiate which = version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it = changes. --- =20 another place in the GSMP RFC it talks about a minimum set of messages = which must be supported for a version, so by having still GSMP reference in the ANCP = draft, and yet no clear statement on what protocol version we would expect to make an adjency = seems wrong to me. =20 =20 In my mind it do not have to be a long section, it can be done in a = small paragraph to describe that the ANCP version of 3.2 should be able to change it's version to = a lower pre-standard 3.1=20 version if it supports earlier drafts of ANCP. =20 Do we know what happens to existing ANCP implementations if the see a = adjancy message with a version number different from 3.1 ? =20 cheers, Peter =20 =20 =20 =20 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Hi Peter, =20 so, based on the experience with the IESG review of last call drafts, = one has reason to believe that pulling a trick like referring to a v3.1 = in anything but non normative is not going fly (nor would it be = reasonable if it happens to be exactly the same as v3.2). The time of = making it to rfc of a v3.1 has very little to do with it, since the = latest draft of the protocol spec is to our knowledge 100% compatible = with "pre-standard" implementation except for new capabilities. Anyway, before we go off documenting all that, perhaps a step back = should be taken to evaluate the situation: - the currently deployed protocol, based on some set of the current = drafts, has it's core functionality intact. I.e. Given that in all new = activities we've strived for backwards compatibility, with the exception = of historic tlv conflict, there doesn't seem to be much of a reason for = v3.2 - the tlv conflict is inherent to a stage of ANCP development and a = v3.2 or its claims of backward compatibility to v3.1 (with conflicting = tlv set) are not going to matter; the affected tlvs will still clash, = irrespective of "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way = to distinguish new protocol functions. It's here that the WG has been = spending most of its time, and it's recognised as the way in which the = protocol will evolve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set = of compatible pre-standard implementations (thus same pre-standard = versions) that they are running and the actual standard which may be in = their opinion incompatible, hence v3.1 becomes to v3.2. The same = operator has not expressed a need to have an rfc for v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which = the protocol does not appear to require modification (this appears to be = no different than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 = (which appears to need a correction) =20 Based on the above, it seems to me that if we go at a stroke to a = v3.2 when the rfc gets published we could try to navigate by having a = clause which states that pre-rfc eg v3.1 *may* be compatible and a hint = to reflect that version number to the sender but leaving remaining = behaviour un-specified (since there is no actual guarantee of = compatibility). How does this sound? =20 Cheers, Woj. ________________________________ From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Hi Woj, =20 As I see it the problem is exactly that we do not have a normative = reference in a RFC simply because we have been too long to put anything together on the = running code which are deployed in live networks today. =20 We have a L2CP reference in a TR document and we have live networks. =20 So if we decide to go for version 3.2 in the ANCP WG, it would be = very beneficial to have a chapter in the RFC which describe migration from pre-standard ANCP = to the standard RFC. =20 I'm sure carriers having pre-standard ANCP running in their network = will like a clear RFC statement for how we vendors should handle a incompatibility in a = defacto ANCP standard and the "real" ANCP RFC standard. =20 So instead of a normative reference i will suggest that the RFC = editor of the ANCP protocol=20 write a chapter and describe what is expected when a RFC standard = ANCP ver. 3.2=20 implementation is getting adjancy connection request from a = pre-standard ver. 3.1 ANCP endpoint. =20 Too me this seems like a much too important question to simply = ignore in a new protocol which have been in the development for more than 3 years, and have had = live networks in multi-vendor deployments for a long time. =20 thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Your post bears no useful or constructive input regarding the = topic. Attempting to define backwards compatibility means drawing on a = normative reference to non-standard drafts and is not reasonable (a = reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could = be so kind as to give us advise the WG as to where ANCP version 3.1 is = defined and can be normatively referenced in a v3.2 RFC?=20 If v3.2 and v3.1 are 100% compatible, except for new capabilities, = then there is hardly a reason for a version change. The only way to have = a reference to v3.1 in an rfc re v3.2 is either as a historic note, = without claims of backwards compatibility, or publish two rfcs (a v3.1 = and then a v3.2). Neither of these proposals seem to be appealing. =20 In addition, you may also want to reflect on the quality of your = conclusions and comprehension of general facts... =20 -Woj. =20 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 So what are you sugegsting will happen with current = deployments....!!! Like it or not Woj, fact is it must be covered, if = you dont agree then thats just your single opinion here. =20 By the time you agree on everything we will be onto ANCP Version = 4.10 !!! We are spending far too long on getting this draft out the = door. ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 = which is NOT defined anywhere (in any normative reference or RFC) does = not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP = "version incompatibility" will be handled. Given that we're not out in = the WG to create version compatibility between an ANCP standard protocol = and an ANCP non-standard based one (or GSMP for that matter), it would = seem that no new definition needs to take place. Feel free to discuss = this further on this thread... =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 In order to ease migration, it will help if BNGs are able to handle = multiple peers with different versions (e.g. a 3.2 compliant BNG = implementation able to work with a 3.1 AN and a 3.2 AN). Although = implied by the protocol, we may want to explicitly state that version = compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility = between BNG and AN needs to be handled. =20 -Sanjay =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on = Monday as i did not attend) is "backward compatibility" between the = different versions of 3.1, 3.2 and future versions if/when/as needed. = this should be noted in the draft. =20 Alan =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing = new is being defined. Also strictly speaking there is no distinction = between version and sub-version, so the choice of 3.2 is purely based on = custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will = automatically be 100% incompatible with the rfc. =20 -Woj. =20 =09 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the = Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic = of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol, however an RFC Editor's note will be = introduced to change version from 3.1 to 3.2 upon publication of the = RFC. This will clearly de-lineate any pre-RFC implementations with = post-RFC ones and alleviate the operators'' problems presented = (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt = ) Going beyond the publication of the RFC, the introduction of new = capabilities or TLVs is expected to be handled by the capability = negotiation mechanism (and new capabilities) or possibly by generalizing = the notion of sub-capability currently in place for the = multicast-control use-cases. We would like to get feedback from the wider WG on the above, = especially in terms of anyone who was not able to voice their opinion at = the meeting. Based on the received feedback, we'll make a call regarding = the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA1B93.E588698A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANCP Protocol = Versioning
Hi=20 Robert
 
We are=20 prety mush saying the same here on this. I would agree on having this = outlined=20 in an appendix though ill leave that to Sanjay et.al editors to decide = where=20 best to fit such text.
 
My=20 reference to the negotiation protocol is from RFC3292 in section 11.1 = (as you=20 also note) which covers the 8-bit Version number of which we now use the = full=20 8-bits for the Version+Sub_version and i see nothing preventing us from = using=20 this, though i agree with you that RFC3292 does not cover the = sub-version=20 number, but that's something we can modify to support the sub-vers = field.=20
 
The MAY=20 is always set in uppercase in the RFC.
 
How=20 about:
 
Prior to=20 completion of this RFC, several pre-RFC versions of the protocol were=20 documented, implemented and deployed in Service Providers Access Network = which=20 used an ANCP protocol Version/Sub-Version set to = 3.1.
 
A NAS=20 implementing the NAS protocol defined in this RFC, may on a per peer = basis, use=20 the Version and Sub-Version fields to detect a pre RFC implementation of = the=20 ANCP protocol and choose to work with such pre-RFC peers (NAS and=20 DSLAM).
 
Also, as Peter and Sanjay have noted on = previous emails=20 on this thread it should be captured in the draft (small paragraph) on = how to=20 handle adjacency connections when a RFC-standards compliant ANCP node = (3.2)=20 receives an adjacency connection request from a version/sub-version 3.1=20 ANCP node? 
 
Alan

 
From: Robert Rennison=20 [mailto:Robert.Rennison@ecitele.com]
Sent: August 10, 2009 = 4:04=20 PM
To: Alan Kavanagh; Peter.Hamacher@telekom.de; = lihy@huawei.com;=20 Peter Arberg; wdec@cisco.com; swadhwa@juniper.net; = ancp@ietf.org
Cc:=20 HaagT@telekom.de; B.Witschurke@telekom.de
Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

Alan,
 
Ok so perhaps=20 the RFC may use a "may" but in a non normative = section.
 
A lot would=20 depend on where in the document you wished to place any such note. As = Woj=20 pointed out in an earlier email, anything in a normative section would = most=20 likely not get past the editors.
 
Perhaps an=20 appendix "
 
I'd be=20 reluctant to cover how to negotiate the version.  Your reference to = section=20 5.3 refers to capabilities negotiation not  version negotiation = which is=20 covered in  section 11.1 of 3292  where the version = negotiation is=20 discussed, note however that this refers to a single version field not = the=20 version/sub version field as used in ANCP. Once you get into mentioning = the=20 version  negotiation then one would have to cover how one tell the=20 difference between  versions of the versions i.e. between these=20 versions using Version 3.1  draft-wadwha- vs=20 draft-ietf-ancp-....  .
 
 
Hence it=20 would perhaps be better to  omit anything about how to do any = version=20 negotiation. say that the RFC compliant version may use the = version/subversion=20 field to detect a pre-standard implementation and that this maybe done = on a per=20 peer basis such that a given NAS may support both Standards = compliant =20 3.2  and pre-standard
 
How=20 about.
 
---------------------------------------------------------= ------------------------------
Appendix.=20 Handling of pre-RFC deployments of the ANCP =  protocol
 
This appendix=20 is non normative
 
Prior to=20 completion of this document, several pre-RFC  versions of the = protocol were=20 documented and implemented.
There were=20 numerous pre-standard versions of the protocol all using a=20 version/subversion field set to 3.1.
 
A NAS=20 implementing the ANCP protocol as defined in this document may, on a = peer basis,=20 use the version and subversion field
to detect a=20 pre-RFC implementation of the protocol and choose to work with such = pre-RFC=20 peers ( e.g NAS or DSLAM)
---------------------------------------------------------= --------------------------
 
Note lower=20 case "may" since I'm not sure that upper case MAY applies in = non-normative=20 text.
 
Cheers
 
Rob

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: Monday, August 10, 2009 11:46 = AM
To:=20 Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; = wdec@cisco.com;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi All

I typed up some text to = include in the=20 ancp protocol draft,based on some = discussions.=20 So from reading the minutes it appears that the WG has = agreed on=20 moving the sub-version number to 2, which gives us Version/Sub 3.2. It = makes=20 sense to have this clearly noted in the ietf-ancp-protocol draft. I = suggest on=20 adding the following text to the ancp protocol draft to provide a clear reasoning and for the = uplift and=20 move us forward:

Prior to initiation of this work, existing ANCP deployments used an = ANCP=20 Protocol Version/Sub-Version 3.1. which differs in the TLV's from this = RFC=20 standards track version. Therefore RFC compliant versions MAY choose = to work=20 with such pre-RFC peers (NAS and DSLAM).

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The = ancp=20 protocol Version/Sub-Version is set on a per peer basis and is=20 synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section=20 5.3. to agree on the protocol version to use.

Alan

From: Peter.Hamacher@telekom.de=20 [mailto:Peter.Hamacher@telekom.de]
Sent: August 10, 2009 = 11:35=20 AM
To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan = Kavanagh;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: AW: [ANCP] ANCP Protocol=20 Versioning

Hi all,
 
from our perspective it is essential to have = a practible=20 way to migrate to RFC.
 

regards
Peter=20 Hamacher


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik=20 Einf=FChrung
Peter Hamacher
Heinrich-Hertz-Stra=DFe 3-7, 64295=20 Darmstadt
+49 6151 628 2864 (Tel.)
+49 521 92100494 = (Fax)
E-Mail:=20 Peter.Hamacher@telekom.de
http://www.telekom.com

Deutsche Telekom = Netzproduktion=20 GmbH
Aufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
Gesch=E4ftsf=FChrung:=20 Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der = Gesellschaft:=20 Bonn
USt-IdNr.: DE 814645262

Erleben, was verbindet.

 

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Hongyu=20 Li
Gesendet: Montag, 10. August 2009 08:52
An: = 'Peter=20 Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa';=20 ancp@ietf.org
Betreff: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
I guess you are afraid when a new BNG = implementing ANCP per=20 the future RFC, whether it can talk to pre-rfc version AN. IMHO, this = is a=20 question that should go to operators having pre-rfc ANs. If they = request so,=20 we may have to define both 3.1 and 3.2 actions in the draft, which is = really=20 odd. Otherwise, it is only a piece of cake. Everybody just follows=20 rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To: = Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
I did not realize it was last-call, I must = have missed=20 that email on the mailing list.
 
I agree with you that also to my knowledge = different=20 implementations have been able to
keep backward compatibility to earlier = drafts, and if=20 the introduction of the new version
number 3.2 is because of fear of non = compatible=20 implementations then it is not valid, as
it is very doable to have backwards = compatible to=20 previous drafts so far.
 
But in my mind it still seems like a good = idea to bump=20 the version number, if for nothing
else then to mark the ANCP standards first = step is=20 complete, and to move away one more
step to the GSMP tie.
 
But with the reference as you show and also = all the=20 reference we still have to GSMP in the
draft document, it just seems like we are = making it=20 very difficult for any newcomers to the
ANCP work to decide what to do and what not = to=20 do.
 
I'm not very afraid that vendors who = already have a=20 pre-standard ANCP implementation can
figure out what to do, but why not make it = more easy=20 for everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it=20 states:
---
   GSMP contains an adjacency = protocol. =20 The adjacency protocol is used
      to=20 synchronise states across the link, to negotiate which=20 version
      of the GSMP protocol to = use, to=20 discover the identity of the
      = entity at the=20 other end of a link, and to detect when it=20 changes.
---
 
another place in the GSMP RFC it talks = about a minimum=20 set of messages which must be
supported for a version, so by having still = GSMP=20 reference in the ANCP draft, and yet no clear
statement on what protocol version we would = expect to=20 make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long = section, it can=20 be done in a small paragraph to describe
that the ANCP version of 3.2 should be able = to change=20 it's version to a lower pre-standard 3.1
version if it supports earlier drafts of=20 ANCP.
 
Do we know what happens to existing ANCP=20 implementations if the see a adjancy message
with a version number different from 3.1=20 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: 29. juli 2009 = 16:41
To:=20 Peter Arberg; Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
so, based on the experience with the IESG review of = last call=20 drafts, one has reason to believe that pulling a trick = like=20 referring to a  v3.1 in anything but non normative is = not going=20 fly (nor would it be reasonable if it happens to be exactly the = same as=20 v3.2). The time of making it to rfc of a v3.1 has very little = to do=20 with it, since the latest draft of the protocol spec is to our = knowledge=20 100% compatible with "pre-standard" implementation except for new=20 capabilities.
Anyway, before we go off documenting all that, = perhaps a=20 step back should be taken to evaluate the = situation:
- the currently deployed protocol, based on some set of = the=20 current drafts, has it's core functionality intact. I.e. = Given that=20 in all new activities we've strived for backwards compatibility, = with the=20 exception of historic tlv conflict, there doesn't seem to be much = of a=20 reason for v3.2
- the tlv conflict is inherent to a stage of ANCP = development and=20 a v3.2 or its claims of backward compatibility to v3.1 (with=20 conflicting tlv set) are not going to matter; = the affected tlvs=20 will still clash, irrespective of "backwards compatibility" of=20 versions.
- Capability negotiation as offered by ANCP by = itself provides=20 a way to distinguish new protocol functions. It's here that the WG = has=20 been spending most of its time, and it's recognised as the way in = which=20 the protocol will evolve (or via = sub-capabilities)
- An operator has requested that a line be drawn to = distinguish a=20 set of compatible pre-standard implementations (thus same=20 pre-standard versions)  that they are running and the actual = standard=20 which may be in their opinion incompatible, hence v3.1 = becomes to=20 v3.2. The same operator has not expressed a need to have an rfc = for=20 v3.1
- Migrating from v3.1 to v3.2 is an operational activity = for which=20 the protocol does not appear to require modification (this = appears to=20 be no different than transitioning from L2TPv2 to v3=20 say).
- The current protocol draft states that the version = SHOULD be 3.1=20 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a = stroke to a=20 v3.2 when the rfc gets published we could try to navigate by = having a=20 clause which states that pre-rfc  eg v3.1 *may* be compatible = and a=20 hint to reflect that version number to the sender but leaving = remaining behaviour un-specified (since there is no actual = guarantee of=20 compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg=20 [mailto:parberg@redback.com]
Sent: 29 July 2009=20 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay = Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
As I see it the problem is exactly that = we do not=20 have a normative reference in a RFC
simply because we have been too long to = put=20 anything together on the running code
which are deployed in live networks=20 today.
 
We have a L2CP reference in a TR = document and we=20 have live networks.
 
So if we decide to go for version 3.2 = in the ANCP=20 WG, it would be very beneficial to have
a chapter in the RFC which describe = migration from=20 pre-standard ANCP to the standard
RFC.
 
I'm sure carriers having pre-standard = ANCP running=20 in their network will like a clear RFC
statement for how we vendors should = handle a=20 incompatibility in a defacto ANCP standard
and the "real" ANCP RFC=20 standard.
 
So instead of a normative reference i = will suggest=20 that the RFC editor of the ANCP protocol
write a chapter and describe what is = expected when=20 a RFC standard ANCP ver. 3.2
implementation is getting adjancy = connection=20 request from a pre-standard ver. 3.1 ANCP
endpoint.
 
Too me this seems like a much too = important=20 question to simply ignore in a new protocol = which
have been in the development for more = than 3 years,=20 and have had live networks = in multi-vendor
deployments for a long = time.
 
thanks,
Peter

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech = Dec=20 (wdec)
Sent: 29. juli 2009 12:22
To: Alan=20 Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: Re: = [ANCP]=20 ANCP Protocol Versioning

Your post bears no useful or = constructive input=20 regarding the topic. Attempting to define backwards = compatibility=20 means drawing on a normative reference to = non-standard=20 drafts and is not reasonable (a reading of http://tools.ietf.org/html/rf= c4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as to = where=20 ANCP version 3.1 is defined and can be normatively referenced = in a=20 v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, = except for new=20 capabilities, then there is hardly a reason for a version = change. The=20 only way to have a reference to v3.1 in an rfc re v3.2 is = either as a=20 historic note, without claims of backwards compatibility, or = publish=20 two rfcs (a v3.1 and then a v3.2). Neither of these proposals = seem to=20 be appealing.
 
In addition, you may also want to = reflect on=20 the quality of your conclusions and comprehension of general=20 facts...
 
-Woj.
 
From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 29 July = 2009=20 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

So what are you = sugegsting will=20 happen with current deployments....!!! Like it or not Woj, = fact is=20 it must be covered, if you dont agree then thats just your = single=20 opinion here.
 
By the time you agree = on everything=20 we will be onto ANCP Version 4.10 !!! We are spending far = too long=20 on getting this draft out the door.

From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com]
Sent: July 29, 2009 10:01 = AM
To: Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Sorry, but reference in a future ANCP = v3.2 RFC to=20 a version 3.1 which is NOT defined anywhere (in any = normative=20 reference or RFC) does not seem to be=20 acceptable.
The (minuted) discussion did not cover = the notion=20 of how ANCP "version incompatibility" will be handled. Given = that=20 we're not out in the WG to create version compatibility = between=20 an ANCP standard protocol and an ANCP non-standard = based one=20 (or GSMP for that matter), it would seem that no new = definition=20 needs to take place. Feel free to discuss this further on = this=20 thread...
 
-Woj.

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: 29 July 2009 15:51
To: = Sanjay=20 Wadhwa; Wojciech Dec (wdec); = ancp@ietf.org
Subject: Re:=20 [ANCP] ANCP Protocol Versioning

Exactly, hence we = should ahve this=20 explicitly noted in the draft.
 
Alan

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: July 29, = 2009 9:48=20 AM
To: Alan Kavanagh; Wojciech Dec (wdec);=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

In order=20 to ease migration, it will help if BNGs are able to handle = multiple peers with different versions (e.g. a 3.2 = compliant BNG=20 implementation able to work with a 3.1 AN and a 3.2 AN). = Although=20 implied by the protocol, we may want to explicitly state = that=20 version compatibility requirement is on an adjacency=20 basis.

The draft=20 will also need to define how the version incompatibility = between=20 BNG and AN needs to be = handled.

 

-Sanjay

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of Alan=20 Kavanagh
Sent:=20 Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec = (wdec);=20 ancp@ietf.org
Subject: Re: [ANCP] = ANCP=20 Protocol Versioning

 

Cheers=20 Woj

 

The only=20 point i would note (excuse if it was already raised on = Monday as i=20 did not attend) is "backward compatibility" between the = different=20 versions of 3.1, 3.2 and future versions if/when/as = needed. this=20 should be noted in the draft.

 

Alan

 

From: Wojciech = Dec (wdec)=20 [mailto:wdec@cisco.com] =
Sent: July 29, 2009 = 3:33=20 AM
To: = Alan=20 Kavanagh; ancp@ietf.org
Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

Not = entirely. ANCP=20 already has a versioning field, hence nothing new is being = defined. Also strictly speaking there is no = distinction=20 between version and sub-version, so the choice of 3.2 = is=20 purely based on custom (it can equally well have been=20 4.0).

Of course = this will=20 mean that all "pre-rfc" implementations will automatically = be 100%=20 incompatible with the rfc.

 

-Woj.

 

From: Alan = Kavanagh=20 [mailto:alan.kavanagh@ericsson.com] =
Sent: 28 July=20 2009 19:28
To:=20 Wojciech Dec (wdec); ancp@ietf.org
Subject: RE: = [ANCP] ANCP=20 Protocol Versioning

Hi Woj=20 et.al

 

So are=20 we agreeing that option 1 as noted on slide 15 in the = Thomas's=20 presentation is what was agreed on at yesterdays=20 meeting?

 

BR

Alan=20 K

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of = Wojciech Dec=20 (wdec)
Sent:=20 July 28, 2009 5:30 AM
To: = ancp@ietf.org
Subject: [ANCP] = ANCP=20 Protocol Versioning

Hi=20 All, =

During = yesterday's=20 ANCP WG meeting at IET75 we discussed the topic of ANCP=20 versioning and in the room arrived at the following=20 conclusion:

The = Pre-RFC version=20 of ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol,=20 however an RFC Editor's note will be introduced to = change=20 version from 3.1 to 3.2 upon publication of the RFC. = This will=20 clearly de-lineate any pre-RFC implementations with = post-RFC=20 ones and alleviate the operators'' problems presented=20 (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going = beyond the=20 publication of the RFC, the introduction of new = capabilities or=20 TLVs is expected to be handled by the capability = negotiation=20 mechanism (and new capabilities) or possibly by = generalizing the=20 notion of sub-capability currently in place for the=20 multicast-control = use-cases.

We would = like to get=20 feedback from the wider WG on the above, especially in = terms of=20 anyone who was not able to voice their opinion at the = meeting.=20 Based on the received feedback, we'll make a call = regarding the=20 WG consensus on this = matter.

Regards,=20
Woj.=20 =

= ------_=_NextPart_001_01CA1B93.E588698A-- From tom.taylor@rogers.com Wed Aug 12 15:44:55 2009 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 C5FFE3A6CC8 for ; Wed, 12 Aug 2009 15:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.438, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6] 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 bRcosz2706C4 for ; Wed, 12 Aug 2009 15:44:53 -0700 (PDT) Received: from smtp110.rog.mail.re2.yahoo.com (smtp110.rog.mail.re2.yahoo.com [206.190.37.120]) by core3.amsl.com (Postfix) with SMTP id 1BE9C3A6C37 for ; Wed, 12 Aug 2009 15:44:05 -0700 (PDT) Received: (qmail 40204 invoked from network); 12 Aug 2009 22:43:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=p9yHX82e6XoUB7ypYOV8b0tYKRwFly0Y5X5Jtab4ZdH6PN+l4QkvgEVm/lketX4j5mrIXQeqn6Dvga2Meq+WyOQKnnQ6F5NZyeet71gasXrWr1MDLfYc4R6z+KV8EM4wrxp0oIX/D2hMgThZzZRWuc/x7sM8XUkfRlWUngGn6C4= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp110.rog.mail.re2.yahoo.com with SMTP; 12 Aug 2009 22:43:14 -0000 X-YMail-OSG: _SX7uoQVM1kMeHXzxSlf8BWNHiuoGYXBUOkbBDDDWu2MKbUDK_NFuwzK3LprM_V4ZA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A83457F.9080202@rogers.com> Date: Wed, 12 Aug 2009 18:43:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alan Kavanagh , ancp@ietf.org References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de> <35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> <35815C929B41D2479A224FE098A2722707A629DE@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <35815C929B41D2479A224FE098A2722707A629DE@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [ANCP] ANCP Protocol Versioning 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, 12 Aug 2009 22:44:55 -0000 How about an Informational RFC after the base protocol RFC comes out, describing the negotiation process? Alan Kavanagh wrote: > Hi Robert > > We are prety mush saying the same here on this. I would agree on having this outlined in an appendix though ill leave that to Sanjay et.al editors to decide where best to fit such text. > > My reference to the negotiation protocol is from RFC3292 in section 11.1 (as you also note) which covers the 8-bit Version number of which we now use the full 8-bits for the Version+Sub_version and i see nothing preventing us from using this, though i agree with you that RFC3292 does not cover the sub-version number, but that's something we can modify to support the sub-vers field. > > The MAY is always set in uppercase in the RFC. > > How about: > > Prior to completion of this RFC, several pre-RFC versions of the protocol were documented, implemented and deployed in Service Providers Access Network which used an ANCP protocol Version/Sub-Version set to 3.1. > > A NAS implementing the NAS protocol defined in this RFC, may on a per peer basis, use the Version and Sub-Version fields to detect a pre RFC implementation of the ANCP protocol and choose to work with such pre-RFC peers (NAS and DSLAM). > > Also, as Peter and Sanjay have noted on previous emails on this thread it should be captured in the draft (small paragraph) on how to handle adjacency connections when a RFC-standards compliant ANCP node (3.2) receives an adjacency connection request from a version/sub-version 3.1 ANCP node? > > Alan > > > ________________________________ > > From: Robert Rennison [mailto:Robert.Rennison@ecitele.com] > Sent: August 10, 2009 4:04 PM > To: Alan Kavanagh; Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org > Cc: HaagT@telekom.de; B.Witschurke@telekom.de > Subject: RE: [ANCP] ANCP Protocol Versioning > > > Alan, > > Ok so perhaps the RFC may use a "may" but in a non normative section. > > A lot would depend on where in the document you wished to place any such note. As Woj pointed out in an earlier email, anything in a normative section would most likely not get past the editors. > > Perhaps an appendix " > > I'd be reluctant to cover how to negotiate the version. Your reference to section 5.3 refers to capabilities negotiation not version negotiation which is covered in section 11.1 of 3292 where the version negotiation is discussed, note however that this refers to a single version field not the version/sub version field as used in ANCP. Once you get into mentioning the version negotiation then one would have to cover how one tell the difference between versions of the versions i.e. between these versions using Version 3.1 draft-wadwha- vs draft-ietf-ancp-.... . > > > Hence it would perhaps be better to omit anything about how to do any version negotiation. say that the RFC compliant version may use the version/subversion field to detect a pre-standard implementation and that this maybe done on a per peer basis such that a given NAS may support both Standards compliant 3.2 and pre-standard > > How about. > > --------------------------------------------------------------------------------------- > Appendix. Handling of pre-RFC deployments of the ANCP protocol > > This appendix is non normative > > Prior to completion of this document, several pre-RFC versions of the protocol were documented and implemented. > There were numerous pre-standard versions of the protocol all using a version/subversion field set to 3.1. > > A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and subversion field > to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers ( e.g NAS or DSLAM) > ----------------------------------------------------------------------------------- > > Note lower case "may" since I'm not sure that upper case MAY applies in non-normative text. > > Cheers > > Rob > > > ________________________________ > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh > Sent: Monday, August 10, 2009 11:46 AM > To: Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org > Cc: HaagT@telekom.de; B.Witschurke@telekom.de > Subject: Re: [ANCP] ANCP Protocol Versioning > > > Hi All > > I typed up some text to include in the ancp protocol draft,based on some discussions. So from reading the minutes it appears that the WG has agreed on moving the sub-version number to 2, which gives us Version/Sub 3.2. It makes sense to have this clearly noted in the ietf-ancp-protocol draft. I suggest on adding the following text to the ancp protocol draft to provide a clear reasoning and for the uplift and move us forward: > > Prior to initiation of this work, existing ANCP deployments used an ANCP Protocol Version/Sub-Version 3.1. which differs in the TLV's from this RFC standards track version. Therefore RFC compliant versions MAY choose to work with such pre-RFC peers (NAS and DSLAM). > > A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp protocol Version/Sub-Version is set on a per peer basis and is synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in section 5.3. to agree on the protocol version to use. > > Alan > > > ________________________________ > > From: Peter.Hamacher@telekom.de [mailto:Peter.Hamacher@telekom.de] > Sent: August 10, 2009 11:35 AM > To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kavanagh; swadhwa@juniper.net; ancp@ietf.org > Cc: HaagT@telekom.de; B.Witschurke@telekom.de > Subject: AW: [ANCP] ANCP Protocol Versioning > > > Hi all, > > from our perspective it is essential to have a practible way to migrate to RFC. > > > > regards > Peter Hamacher > > > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einführung > Peter Hamacher > Heinrich-Hertz-Straße 3-7, 64295 Darmstadt > +49 6151 628 2864 (Tel.) > +49 521 92100494 (Fax) > E-Mail: Peter.Hamacher@telekom.de > http://www.telekom.com > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Timotheus Höttges (Vorsitzender) > Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 > > Erleben, was verbindet. > > > > > > ________________________________ > > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Hongyu Li > Gesendet: Montag, 10. August 2009 08:52 > An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'; ancp@ietf.org > Betreff: Re: [ANCP] ANCP Protocol Versioning > > > Hi Peter, > > I guess you are afraid when a new BNG implementing ANCP per the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question that should go to operators having pre-rfc ANs. If they request so, we may have to define both 3.1 and 3.2 actions in the draft, which is really odd. Otherwise, it is only a piece of cake. Everybody just follows rfc. > > > > cheers, > Hongyu > > > > ________________________________ > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg > Sent: Thursday, July 30, 2009 8:38 AM > To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org > Subject: Re: [ANCP] ANCP Protocol Versioning > > > Hi Woj, > > I did not realize it was last-call, I must have missed that email on the mailing list. > > I agree with you that also to my knowledge different implementations have been able to > keep backward compatibility to earlier drafts, and if the introduction of the new version > number 3.2 is because of fear of non compatible implementations then it is not valid, as > it is very doable to have backwards compatible to previous drafts so far. > > But in my mind it still seems like a good idea to bump the version number, if for nothing > else then to mark the ANCP standards first step is complete, and to move away one more > step to the GSMP tie. > > But with the reference as you show and also all the reference we still have to GSMP in the > draft document, it just seems like we are making it very difficult for any newcomers to the > ANCP work to decide what to do and what not to do. > > I'm not very afraid that vendors who already have a pre-standard ANCP implementation can > figure out what to do, but why not make it more easy for everyboby by having a little more > description on this. > > In the GSMP RFC which is referenced it states: > --- > GSMP contains an adjacency protocol. The adjacency protocol is used > to synchronise states across the link, to negotiate which version > of the GSMP protocol to use, to discover the identity of the > entity at the other end of a link, and to detect when it changes. > --- > > another place in the GSMP RFC it talks about a minimum set of messages which must be > supported for a version, so by having still GSMP reference in the ANCP draft, and yet no clear > statement on what protocol version we would expect to make an adjency seems wrong to me. > > > In my mind it do not have to be a long section, it can be done in a small paragraph to describe > that the ANCP version of 3.2 should be able to change it's version to a lower pre-standard 3.1 > version if it supports earlier drafts of ANCP. > > Do we know what happens to existing ANCP implementations if the see a adjancy message > with a version number different from 3.1 ? > > cheers, > Peter > > > > > > > ________________________________ > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: 29. juli 2009 16:41 > To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > Hi Peter, > > so, based on the experience with the IESG review of last call drafts, one has reason to believe that pulling a trick like referring to a v3.1 in anything but non normative is not going fly (nor would it be reasonable if it happens to be exactly the same as v3.2). The time of making it to rfc of a v3.1 has very little to do with it, since the latest draft of the protocol spec is to our knowledge 100% compatible with "pre-standard" implementation except for new capabilities. > Anyway, before we go off documenting all that, perhaps a step back should be taken to evaluate the situation: > - the currently deployed protocol, based on some set of the current drafts, has it's core functionality intact. I.e. Given that in all new activities we've strived for backwards compatibility, with the exception of historic tlv conflict, there doesn't seem to be much of a reason for v3.2 > - the tlv conflict is inherent to a stage of ANCP development and a v3.2 or its claims of backward compatibility to v3.1 (with conflicting tlv set) are not going to matter; the affected tlvs will still clash, irrespective of "backwards compatibility" of versions. > - Capability negotiation as offered by ANCP by itself provides a way to distinguish new protocol functions. It's here that the WG has been spending most of its time, and it's recognised as the way in which the protocol will evolve (or via sub-capabilities) > - An operator has requested that a line be drawn to distinguish a set of compatible pre-standard implementations (thus same pre-standard versions) that they are running and the actual standard which may be in their opinion incompatible, hence v3.1 becomes to v3.2. The same operator has not expressed a need to have an rfc for v3.1 > - Migrating from v3.1 to v3.2 is an operational activity for which the protocol does not appear to require modification (this appears to be no different than transitioning from L2TPv2 to v3 say). > - The current protocol draft states that the version SHOULD be 3.1 (which appears to need a correction) > > Based on the above, it seems to me that if we go at a stroke to a v3.2 when the rfc gets published we could try to navigate by having a clause which states that pre-rfc eg v3.1 *may* be compatible and a hint to reflect that version number to the sender but leaving remaining behaviour un-specified (since there is no actual guarantee of compatibility). How does this sound? > > Cheers, > Woj. > > > ________________________________ > > From: Peter Arberg [mailto:parberg@redback.com] > Sent: 29 July 2009 21:55 > To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > Hi Woj, > > As I see it the problem is exactly that we do not have a normative reference in a RFC > simply because we have been too long to put anything together on the running code > which are deployed in live networks today. > > We have a L2CP reference in a TR document and we have live networks. > > So if we decide to go for version 3.2 in the ANCP WG, it would be very beneficial to have > a chapter in the RFC which describe migration from pre-standard ANCP to the standard > RFC. > > I'm sure carriers having pre-standard ANCP running in their network will like a clear RFC > statement for how we vendors should handle a incompatibility in a defacto ANCP standard > and the "real" ANCP RFC standard. > > So instead of a normative reference i will suggest that the RFC editor of the ANCP protocol > write a chapter and describe what is expected when a RFC standard ANCP ver. 3.2 > implementation is getting adjancy connection request from a pre-standard ver. 3.1 ANCP > endpoint. > > Too me this seems like a much too important question to simply ignore in a new protocol which > have been in the development for more than 3 years, and have had live networks in multi-vendor > deployments for a long time. > > thanks, > Peter > > > ________________________________ > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) > Sent: 29. juli 2009 12:22 > To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org > Subject: Re: [ANCP] ANCP Protocol Versioning > > > Your post bears no useful or constructive input regarding the topic. Attempting to define backwards compatibility means drawing on a normative reference to non-standard drafts and is not reasonable (a reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as to where ANCP version 3.1 is defined and can be normatively referenced in a v3.2 RFC? > If v3.2 and v3.1 are 100% compatible, except for new capabilities, then there is hardly a reason for a version change. The only way to have a reference to v3.1 in an rfc re v3.2 is either as a historic note, without claims of backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be appealing. > > In addition, you may also want to reflect on the quality of your conclusions and comprehension of general facts... > > -Woj. > > > ________________________________ > > From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] > Sent: 29 July 2009 19:11 > To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > So what are you sugegsting will happen with current deployments....!!! Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here. > > By the time you agree on everything we will be onto ANCP Version 4.10 !!! We are spending far too long on getting this draft out the door. > > ________________________________ > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: July 29, 2009 10:01 AM > To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable. > The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread... > > -Woj. > > > ________________________________ > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh > Sent: 29 July 2009 15:51 > To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org > Subject: Re: [ANCP] ANCP Protocol Versioning > > > Exactly, hence we should ahve this explicitly noted in the draft. > > Alan > > ________________________________ > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: July 29, 2009 9:48 AM > To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > > In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis. > > The draft will also need to define how the version incompatibility between BNG and AN needs to be handled. > > > > -Sanjay > > > ________________________________ > > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh > Sent: Wednesday, July 29, 2009 9:30 AM > To: Wojciech Dec (wdec); ancp@ietf.org > Subject: Re: [ANCP] ANCP Protocol Versioning > > > > Cheers Woj > > > > The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft. > > > > Alan > > > > > ________________________________ > > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: July 29, 2009 3:33 AM > To: Alan Kavanagh; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0). > > Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc. > > > > -Woj. > > > > > ________________________________ > > > From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] > Sent: 28 July 2009 19:28 > To: Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > Hi Woj et.al > > > > So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? > > > > BR > > Alan K > > > > > ________________________________ > > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) > Sent: July 28, 2009 5:30 AM > To: ancp@ietf.org > Subject: [ANCP] ANCP Protocol Versioning > > Hi All, > > During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: > > The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt ) > > Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. > > We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. > > Regards, > Woj. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From Robert.Rennison@ecitele.com Mon Aug 10 13:04:33 2009 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 4E50B3A6F0B for ; Mon, 10 Aug 2009 13:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6] 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 BtFo6A0VIODp for ; Mon, 10 Aug 2009 13:04:29 -0700 (PDT) Received: from uspitiron01.ecitele.com (uspitiron01.ecitele.com [63.94.127.135]) by core3.amsl.com (Postfix) with ESMTP id 0D0C03A6F1C for ; Mon, 10 Aug 2009 13:03:41 -0700 (PDT) Received: from nat-33.laurelnetworks.com (HELO uspitexch02.ecitele.com) ([63.94.127.33]) by uspitiron01-out.ecitele.com with ESMTP; 10 Aug 2009 16:00:51 -0500 Received: from USPITMAIL01.ecitele.com ([10.0.0.82]) by uspitexch02.ecitele.com ([10.0.0.72]) with mapi; Mon, 10 Aug 2009 16:03:45 -0400 From: Robert Rennison To: Alan Kavanagh , "Peter.Hamacher@telekom.de" , "lihy@huawei.com" , Peter Arberg , "wdec@cisco.com" , "swadhwa@juniper.net" , "ancp@ietf.org" Date: Mon, 10 Aug 2009 16:03:44 -0400 Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60AADyFzwAA9NFwAAB2HpsA== Message-ID: <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com> <040201ca1987$008a6670$5728460a@china.huawei.com> <1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de> <35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448USPITMAIL01ec_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 17 Aug 2009 08:11:02 -0700 Cc: "HaagT@telekom.de" , "B.Witschurke@telekom.de" Subject: Re: [ANCP] ANCP Protocol Versioning 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: Mon, 10 Aug 2009 20:04:33 -0000 --_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448USPITMAIL01ec_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Alan, Ok so perhaps the RFC may use a "may" but in a non normative section. A lot would depend on where in the document you wished to place any such no= te. As Woj pointed out in an earlier email, anything in a normative section= would most likely not get past the editors. Perhaps an appendix " I'd be reluctant to cover how to negotiate the version. Your reference to = section 5.3 refers to capabilities negotiation not version negotiation whi= ch is covered in section 11.1 of 3292 where the version negotiation is di= scussed, note however that this refers to a single version field not the ve= rsion/sub version field as used in ANCP. Once you get into mentioning the v= ersion negotiation then one would have to cover how one tell the differenc= e between versions of the versions i.e. between these versions using Versi= on 3.1 draft-wadwha- vs draft-ietf-ancp-.... . Hence it would perhaps be better to omit anything about how to do any vers= ion negotiation. say that the RFC compliant version may use the version/sub= version field to detect a pre-standard implementation and that this maybe d= one on a per peer basis such that a given NAS may support both Standards co= mpliant 3.2 and pre-standard How about. ---------------------------------------------------------------------------= ------------ Appendix. Handling of pre-RFC deployments of the ANCP protocol This appendix is non normative Prior to completion of this document, several pre-RFC versions of the prot= ocol were documented and implemented. There were numerous pre-standard versions of the protocol all using a versi= on/subversion field set to 3.1. A NAS implementing the ANCP protocol as defined in this document may, on a = peer basis, use the version and subversion field to detect a pre-RFC implementation of the protocol and choose to work with = such pre-RFC peers ( e.g NAS or DSLAM) ---------------------------------------------------------------------------= -------- Note lower case "may" since I'm not sure that upper case MAY applies in non= -normative text. Cheers Rob ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ala= n Kavanagh Sent: Monday, August 10, 2009 11:46 AM To: Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; wdec@cisco.co= m; swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning Hi All I typed up some text to include in the ancp protocol draft,based on some di= scussions. So from reading the minutes it appears that the WG has agreed on= moving the sub-version number to 2, which gives us Version/Sub 3.2. It mak= es sense to have this clearly noted in the ietf-ancp-protocol draft. I sugg= est on adding the following text to the ancp protocol draft to provide a cl= ear reasoning and for the uplift and move us forward: Prior to initiation of this work, existing ANCP deployments used an ANCP Pr= otocol Version/Sub-Version 3.1. which differs in the TLV's from this RFC st= andards track version. Therefore RFC compliant versions MAY choose to work = with such pre-RFC peers (NAS and DSLAM). A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp proto= col Version/Sub-Version is set on a per peer basis and is synchronized/nego= tiated by the GSMPv3 Adjacency protocol as noted in section 5.3. to agree o= n the protocol version to use. Alan ________________________________ From: Peter.Hamacher@telekom.de [mailto:Peter.Hamacher@telekom.de] Sent: August 10, 2009 11:35 AM To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kavanagh; swadhwa@j= uniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Protocol Versioning Hi all, from our perspective it is essential to have a practible way to migrate to = RFC. regards Peter Hamacher Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Peter Hamacher Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2864 (Tel.) +49 521 92100494 (Fax) E-Mail: Peter.Hamacher@telekom.de http://www.telekom.com Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Erleben, was verbindet. ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Ho= ngyu Li Gesendet: Montag, 10. August 2009 08:52 An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'= ; ancp@ietf.org Betreff: Re: [ANCP] ANCP Protocol Versioning Hi Peter, I guess you are afraid when a new BNG implementing ANCP per the future RFC,= whether it can talk to pre-rfc version AN. IMHO, this is a question that s= hould go to operators having pre-rfc ANs. If they request so, we may have t= o define both 3.1 and 3.2 actions in the draft, which is really odd. Otherw= ise, it is only a piece of cake. Everybody just follows rfc. cheers, Hongyu ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Pet= er Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Hi Woj, I did not realize it was last-call, I must have missed that email on the ma= iling list. I agree with you that also to my knowledge different implementations have b= een able to keep backward compatibility to earlier drafts, and if the introduction of t= he new version number 3.2 is because of fear of non compatible implementations then it is = not valid, as it is very doable to have backwards compatible to previous drafts so far. But in my mind it still seems like a good idea to bump the version number, = if for nothing else then to mark the ANCP standards first step is complete, and to move aw= ay one more step to the GSMP tie. But with the reference as you show and also all the reference we still have= to GSMP in the draft document, it just seems like we are making it very difficult for any = newcomers to the ANCP work to decide what to do and what not to do. I'm not very afraid that vendors who already have a pre-standard ANCP imple= mentation can figure out what to do, but why not make it more easy for everyboby by havin= g a little more description on this. In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. --- another place in the GSMP RFC it talks about a minimum set of messages whic= h must be supported for a version, so by having still GSMP reference in the ANCP draf= t, and yet no clear statement on what protocol version we would expect to make an adjency seems= wrong to me. In my mind it do not have to be a long section, it can be done in a small p= aragraph to describe that the ANCP version of 3.2 should be able to change it's version to a low= er pre-standard 3.1 version if it supports earlier drafts of ANCP. Do we know what happens to existing ANCP implementations if the see a adjan= cy message with a version number different from 3.1 ? cheers, Peter ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Peter, so, based on the experience with the IESG review of last call drafts, one h= as reason to believe that pulling a trick like referring to a v3.1 in anyt= hing but non normative is not going fly (nor would it be reasonable if it h= appens to be exactly the same as v3.2). The time of making it to rfc of a v= 3.1 has very little to do with it, since the latest draft of the protocol s= pec is to our knowledge 100% compatible with "pre-standard" implementation = except for new capabilities. Anyway, before we go off documenting all that, perhaps a step back should b= e taken to evaluate the situation: - the currently deployed protocol, based on some set of the current drafts,= has it's core functionality intact. I.e. Given that in all new activities = we've strived for backwards compatibility, with the exception of historic t= lv conflict, there doesn't seem to be much of a reason for v3.2 - the tlv conflict is inherent to a stage of ANCP development and a v3.2 or= its claims of backward compatibility to v3.1 (with conflicting tlv set) ar= e not going to matter; the affected tlvs will still clash, irrespective of = "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way to dis= tinguish new protocol functions. It's here that the WG has been spending mo= st of its time, and it's recognised as the way in which the protocol will e= volve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set of co= mpatible pre-standard implementations (thus same pre-standard versions) th= at they are running and the actual standard which may be in their opinion i= ncompatible, hence v3.1 becomes to v3.2. The same operator has not expresse= d a need to have an rfc for v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which the prot= ocol does not appear to require modification (this appears to be no differe= nt than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 (which a= ppears to need a correction) Based on the above, it seems to me that if we go at a stroke to a v3.2 when= the rfc gets published we could try to navigate by having a clause which s= tates that pre-rfc eg v3.1 *may* be compatible and a hint to reflect that = version number to the sender but leaving remaining behaviour un-specified (= since there is no actual guarantee of compatibility). How does this sound? Cheers, Woj. ________________________________ From: Peter Arberg [mailto:parberg@redback.com] Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj, As I see it the problem is exactly that we do not have a normative referenc= e in a RFC simply because we have been too long to put anything together on the runnin= g code which are deployed in live networks today. We have a L2CP reference in a TR document and we have live networks. So if we decide to go for version 3.2 in the ANCP WG, it would be very bene= ficial to have a chapter in the RFC which describe migration from pre-standard ANCP to the= standard RFC. I'm sure carriers having pre-standard ANCP running in their network will li= ke a clear RFC statement for how we vendors should handle a incompatibility in a defacto A= NCP standard and the "real" ANCP RFC standard. So instead of a normative reference i will suggest that the RFC editor of t= he ANCP protocol write a chapter and describe what is expected when a RFC standard ANCP ver.= 3.2 implementation is getting adjancy connection request from a pre-standard ve= r. 3.1 ANCP endpoint. Too me this seems like a much too important question to simply ignore in a = new protocol which have been in the development for more than 3 years, and have had live netwo= rks in multi-vendor deployments for a long time. thanks, Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Your post bears no useful or constructive input regarding the topic. Attemp= ting to define backwards compatibility means drawing on a normative referen= ce to non-standard drafts and is not reasonable (a reading of http://tools.= ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us ad= vise the WG as to where ANCP version 3.1 is defined and can be normatively = referenced in a v3.2 RFC? If v3.2 and v3.1 are 100% compatible, except for new capabilities, then the= re is hardly a reason for a version change. The only way to have a referenc= e to v3.1 in an rfc re v3.2 is either as a historic note, without claims of= backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Nei= ther of these proposals seem to be appealing. In addition, you may also want to reflect on the quality of your conclusion= s and comprehension of general facts... -Woj. ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning So what are you sugegsting will happen with current deployments....!!! Like= it or not Woj, fact is it must be covered, if you dont agree then thats ju= st your single opinion here. By the time you agree on everything we will be onto ANCP Version 4.10 !!! W= e are spending far too long on getting this draft out the door. ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NO= T defined anywhere (in any normative reference or RFC) does not seem to be = acceptable. The (minuted) discussion did not cover the notion of how ANCP "version inco= mpatibility" will be handled. Given that we're not out in the WG to create = version compatibility between an ANCP standard protocol and an ANCP non-sta= ndard based one (or GSMP for that matter), it would seem that no new defini= tion needs to take place. Feel free to discuss this further on this thread.= .. -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ala= n Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Exactly, hence we should ahve this explicitly noted in the draft. Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning In order to ease migration, it will help if BNGs are able to handle multipl= e peers with different versions (e.g. a 3.2 compliant BNG implementation ab= le to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, w= e may want to explicitly state that version compatibility requirement is on= an adjacency basis. The draft will also need to define how the version incompatibility between = BNG and AN needs to be handled. -Sanjay ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ala= n Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Cheers Woj The only point i would note (excuse if it was already raised on Monday as i= did not attend) is "backward compatibility" between the different versions= of 3.1, 3.2 and future versions if/when/as needed. this should be noted in= the draft. Alan ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is bei= ng defined. Also strictly speaking there is no distinction between version = and sub-version, so the choice of 3.2 is purely based on custom (it can equ= ally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatica= lly be 100% incompatible with the rfc. -Woj. ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al So are we agreeing that option 1 as noted on slide 15 in the Thomas's prese= ntation is what was agreed on at yesterdays meeting? BR Alan K ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All, During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP = versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-p= rotocol, however an RFC Editor's note will be introduced to change version = from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate a= ny pre-RFC implementations with post-RFC ones and alleviate the operators''= problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt) Going beyond the publication of the RFC, the introduction of new capabiliti= es or TLVs is expected to be handled by the capability negotiation mechanis= m (and new capabilities) or possibly by generalizing the notion of sub-capa= bility currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in= terms of anyone who was not able to voice their opinion at the meeting. Ba= sed on the received feedback, we'll make a call regarding the WG consensus = on this matter. Regards, Woj. --_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448USPITMAIL01ec_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANCP Protocol Ver= sioning
Alan,
 
Ok= so perhaps=20 the RFC may use a "may" but in a non normative section.
 
A = lot would=20 depend on where in the document you wished to place any such note. As Woj=20 pointed out in an earlier email, anything in a normative section would most= =20 likely not get past the editors.
 
Pe= rhaps an=20 appendix "
 
I'= d be=20 reluctant to cover how to negotiate the version.  Your reference to se= ction=20 5.3 refers to capabilities negotiation not  version negotiation which = is=20 covered in  section 11.1 of 3292  where the version negotiation i= s=20 discussed, note however that this refers to a single version field not the= =20 version/sub version field as used in ANCP. Once you get into mentioning the= =20 version  negotiation then one would have to cover how one tell the=20 difference between  versions of the versions i.e. between these=20 versions using Version 3.1  draft-wadwha- vs=20 draft-ietf-ancp-....  .
 
 
He= nce it=20 would perhaps be better to  omit anything about how to do any version= =20 negotiation. say that the RFC compliant version may use the version/subvers= ion=20 field to detect a pre-standard implementation and that this maybe done on a= per=20 peer basis such that a given NAS may support both Standards compliant = =20 3.2  and pre-standard
 
Ho= w=20 about.
 
-----------------------------------------------------------= ----------------------------
Ap= pendix.=20 Handling of pre-RFC deployments of the ANCP  protocol
 
Th= is appendix=20 is non normative
 
Pr= ior to=20 completion of this document, several pre-RFC  versions of the protocol= were=20 documented and implemented.
Th= ere were=20 numerous pre-standard versions of the protocol all using a=20 version/subversion field set to 3.1.
 
A = NAS=20 implementing the ANCP protocol as defined in this document may, on a peer b= asis,=20 use the version and subversion field
to= detect a=20 pre-RFC implementation of the protocol and choose to work with such pre-RFC= =20 peers ( e.g NAS or DSLAM)
-----------------------------------------------------------= ------------------------
 
No= te lower=20 case "may" since I'm not sure that upper case MAY applies in non-normative= =20 text.
 
Cheers
 
Rob

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: Monday, August 10, 2009 11:46 AM
To:=20 Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; wdec@cisco.com;= =20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi All

I typed up some text to include = in the=20 ancp protocol draft,based on some discus= sions.=20 So from reading the minutes it appears that the WG has agre= ed on=20 moving the sub-version number to 2, which gives us Version/Sub 3.2. It ma= kes=20 sense to have this clearly noted in the ietf-ancp-protocol draft. I sugge= st on=20 adding the following text to the ancp protocol draft to provide a clear reasoning and for the upli= ft and=20 move us forward:

Prior to initiation of this work, existing ANCP deployments used an AN= CP=20 Protocol Version/Sub-Version 3.1. which differs in the TLV's from this RF= C=20 standards track version. Therefore RFC compliant versions MAY choose to w= ork=20 with such pre-RFC peers (NAS and DSLAM).

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp= =20 protocol Version/Sub-Version is set on a per peer basis and is=20 synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in sect= ion=20 5.3. to agree on the protocol version to use.

Alan

From: Peter.Hamacher@telekom.de=20 [mailto:Peter.Hamacher@telekom.de]
Sent: August 10, 2009 11:35= =20 AM
To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kava= nagh;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: AW: [ANCP] ANCP Protocol=20 Versioning

Hi all,
 
from our perspective it is essential to have a p= ractible=20 way to migrate to RFC.
 

regards
Peter=20 Hamacher


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik=20 Einf=FChrung
Peter Hamacher
Heinrich-Hertz-Stra=DFe 3-7, 64295=20 Darmstadt
+49 6151 628 2864 (Tel.)
+49 521 92100494 (Fax)
E-Mail= :=20 Peter.Hamacher@telekom.de<= FONT=20 face=3DArial color=3D#808080 size=3D1>
http://www.telekom.com

Deutsche Telekom Netzproduk= tion=20 GmbH
Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)
Gesch=E4ftsf= =FChrung:=20 Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellsc= haft:=20 Bonn
USt-IdNr.: DE 814645262

Erleben, was verbindet.

 

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Hongyu=20 Li
Gesendet: Montag, 10. August 2009 08:52
An: 'Peter= =20 Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa';=20 ancp@ietf.org
Betreff: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
I guess you are afraid when a new BNG implementing A= NCP per=20 the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is = a=20 question that should go to operators having pre-rfc ANs. If they request = so,=20 we may have to define both 3.1 and 3.2 actions in the draft, which is rea= lly=20 odd. Otherwise, it is only a piece of cake. Everybody just follows=20 rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To:=20 Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
I did not realize it was last-call, I must hav= e missed=20 that email on the mailing list.
 
I agree with you that also to my knowledge dif= ferent=20 implementations have been able to
keep backward compatibility to earlier drafts,= and if=20 the introduction of the new version
number 3.2 is because of fear of non compatibl= e=20 implementations then it is not valid, as
it is very doable to have backwards compatible= to=20 previous drafts so far.
 
But in my mind it still seems like a good idea= to bump=20 the version number, if for nothing
else then to mark the ANCP standards first ste= p is=20 complete, and to move away one more
step to the GSMP tie.
 
But with the reference as you show and also al= l the=20 reference we still have to GSMP in the
draft document, it just seems like we are maki= ng it=20 very difficult for any newcomers to the
ANCP work to decide what to do and what not to= =20 do.
 
I'm not very afraid that vendors who already h= ave a=20 pre-standard ANCP implementation can
figure out what to do, but why not make it mor= e easy=20 for everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it=20 states:
---
   GSMP contains an adjacency protoc= ol. =20 The adjacency protocol is used
      to=20 synchronise states across the link, to negotiate which=20 version
      of the GSMP protocol to use, = to=20 discover the identity of the
      entity a= t the=20 other end of a link, and to detect when it=20 changes.
---
 
another place in the GSMP RFC it talks about a= minimum=20 set of messages which must be
supported for a version, so by having still GS= MP=20 reference in the ANCP draft, and yet no clear
statement on what protocol version we would ex= pect to=20 make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long section= , it can=20 be done in a small paragraph to describe
that the ANCP version of 3.2 should be able to= change=20 it's version to a lower pre-standard 3.1
version if it supports earlier drafts of=20 ANCP.
 
Do we know what happens to existing ANCP=20 implementations if the see a adjancy message
with a version number different from 3.1=20 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: 29. juli 2009 16:41
To= :=20 Peter Arberg; Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
so, based on the experience with the IESG review of las= t call=20 drafts, one has reason to believe that pulling a trick like= =20 referring to a  v3.1 in anything but non normative is not g= oing=20 fly (nor would it be reasonable if it happens to be exactly the same = as=20 v3.2). The time of making it to rfc of a v3.1 has very little to= do=20 with it, since the latest draft of the protocol spec is to our knowle= dge=20 100% compatible with "pre-standard" implementation except for new=20 capabilities.
Anyway, before we go off documenting all that, perhaps&= nbsp;a=20 step back should be taken to evaluate the situation:
- the currently deployed protocol, based on some set of the= =20 current drafts, has it's core functionality intact. I.e. Given t= hat=20 in all new activities we've strived for backwards compatibility, with= the=20 exception of historic tlv conflict, there doesn't seem to be much of = a=20 reason for v3.2
- the tlv conflict is inherent to a stage of ANCP developmen= t and=20 a v3.2 or its claims of backward compatibility to v3.1 (with=20 conflicting tlv set) are not going to matter; the affected = tlvs=20 will still clash, irrespective of "backwards compatibility" of=20 versions.
- Capability negotiation as offered by ANCP by itself p= rovides=20 a way to distinguish new protocol functions. It's here that the WG ha= s=20 been spending most of its time, and it's recognised as the way in whi= ch=20 the protocol will evolve (or via sub-capabilities)
- An operator has requested that a line be drawn to distingu= ish a=20 set of compatible pre-standard implementations (thus same=20 pre-standard versions)  that they are running and the actual sta= ndard=20 which may be in their opinion incompatible, hence v3.1 becomes t= o=20 v3.2. The same operator has not expressed a need to have an rfc for=20 v3.1
- Migrating from v3.1 to v3.2 is an operational activity for= which=20 the protocol does not appear to require modification (this appea= rs to=20 be no different than transitioning from L2TPv2 to v3=20 say).
- The current protocol draft states that the version SHOULD = be 3.1=20 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a stroke= to a=20 v3.2 when the rfc gets published we could try to navigate by having a= =20 clause which states that pre-rfc  eg v3.1 *may* be compatible an= d a=20 hint to reflect that version number to the sender but leaving=20 remaining behaviour un-specified (since there is no actual guarantee = of=20 compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg=20 [mailto:parberg@redback.com]
Sent: 29 July 2009=20 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadh= wa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
As I see it the problem is exactly that we= do not=20 have a normative reference in a RFC
simply because we have been too long to pu= t=20 anything together on the running code
which are deployed in live networks=20 today.
 
We have a L2CP reference in a TR document = and we=20 have live networks.
 
So if we decide to go for version 3.2 in t= he ANCP=20 WG, it would be very beneficial to have
a chapter in the RFC which describe migrat= ion from=20 pre-standard ANCP to the standard
RFC.
 
I'm sure carriers having pre-standard ANCP= running=20 in their network will like a clear RFC
statement for how we vendors should handle= a=20 incompatibility in a defacto ANCP standard
and the "real" ANCP RFC=20 standard.
 
So instead of a normative reference i will= suggest=20 that the RFC editor of the ANCP protocol
write a chapter and describe what is expec= ted when=20 a RFC standard ANCP ver. 3.2
implementation is getting adjancy connecti= on=20 request from a pre-standard ver. 3.1 ANCP
endpoint.
 
Too me this seems like a much too importan= t=20 question to simply ignore in a new protocol which
have been in the development for more than= 3 years,=20 and have had live networks in multi-vendor
deployments for a long time.=
 
thanks,
Peter

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec=20 (wdec)
Sent: 29. juli 2009 12:22
To: Alan=20 Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: Re: [AN= CP]=20 ANCP Protocol Versioning

Your post bears no useful or constructive i= nput=20 regarding the topic. Attempting to define backwards compatibility= =20 means drawing on a normative reference to non-standard= =20 drafts and is not reasonable (a reading of http://tools.ietf.org= /html/rfc4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as to wh= ere=20 ANCP version 3.1 is defined and can be normatively referenced in = a=20 v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, excep= t for new=20 capabilities, then there is hardly a reason for a version change.= The=20 only way to have a reference to v3.1 in an rfc re v3.2 is either = as a=20 historic note, without claims of backwards compatibility, or publ= ish=20 two rfcs (a v3.1 and then a v3.2). Neither of these proposals see= m to=20 be appealing.
 
In addition, you may also want to refl= ect on=20 the quality of your conclusions and comprehension of general=20 facts...
 
-Woj.
 
From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 29 July 20= 09=20 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

So what are you sugegstin= g will=20 happen with current deployments....!!! Like it or not Woj, fact= is=20 it must be covered, if you dont agree then thats just your sing= le=20 opinion here.
 
By the time you agree on = everything=20 we will be onto ANCP Version 4.10 !!! We are spending far too l= ong=20 on getting this draft out the door.

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: July 29, 2009 10:01=20 AM
To: Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Sorry, but reference in a future ANCP v3.= 2 RFC to=20 a version 3.1 which is NOT defined anywhere (in any normative=20 reference or RFC) does not seem to be=20 acceptable.
The (minuted) discussion did not cover th= e notion=20 of how ANCP "version incompatibility" will be handled. Given th= at=20 we're not out in the WG to create version compatibility be= tween=20 an ANCP standard protocol and an ANCP non-standard based o= ne=20 (or GSMP for that matter), it would seem that no new defin= ition=20 needs to take place. Feel free to discuss this further on this= =20 thread...
 
-Woj.

From: ancp-bounces@ietf.o= rg=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: 29 July 2009 15:51
To: San= jay=20 Wadhwa; Wojciech Dec (wdec); ancp@ietf.org
Subject:= Re:=20 [ANCP] ANCP Protocol Versioning

= Exactly, hence we shoul= d ahve this=20 explicitly noted in the draft.
=  
= Alan
From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: July 29, 2009 9= :48=20 AM
To: Alan Kavanagh; Wojciech Dec (wdec);=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

In= order=20 to ease migration, it will help if BNGs are able to handle=20 multiple peers with different versions (e.g. a 3.2 compliant = BNG=20 implementation able to work with a 3.1 AN and a 3.2 AN). Alth= ough=20 implied by the protocol, we may want to explicitly state that= =20 version compatibility requirement is on an adjacency=20 basis.

Th= e draft=20 will also need to define how the version incompatibility betw= een=20 BNG and AN needs to be handled.

 

-S= anjay

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent:= =20 Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec (wdec= );=20 ancp@ietf.org
Subject: Re: [ANCP] AN= CP=20 Protocol Versioning

=  

Ch= eers=20 Woj

=  

Th= e only=20 point i would note (excuse if it was already raised on Monday= as i=20 did not attend) is "backward compatibility" between the diffe= rent=20 versions of 3.1, 3.2 and future versions if/when/as needed. t= his=20 should be noted in the draft.

=  

Al= an

=  

From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com] Sent: July 29, 2009 3:= 33=20 AM
To: Ala= n=20 Kavanagh; ancp@ietf.org
Subject: RE: [ANCP] AN= CP=20 Protocol Versioning

Not entirely. A= NCP=20 already has a versioning field, hence nothing new is being=20 defined. Also strictly speaking there is no distinction= =20 between version and sub-version, so the choice of 3.2 is= =20 purely based on custom (it can equally well have been=20 4.0).

Of course this = will=20 mean that all "pre-rfc" implementations will automatically be= 100%=20 incompatible with the rfc.

=  

-Woj.

 

From: Alan Kavana= gh=20 [mailto:alan.kavanagh@ericsson.com]=20
Sent: 2= 8 July=20 2009 19:28
To:=20 Wojciech Dec (wdec); ancp@ietf.org
= Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

= Hi Woj=20 et.al

 

= So are=20 we agreeing that option 1 as noted on slide 15 in the Thoma= s's=20 presentation is what was agreed on at yesterdays=20 meeting?

 

= BR

= Alan=20 K

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciec= h Dec=20 (wdec)
Sent:= =20 July 28, 2009 5:30 AM
To: ancp@ietf.org
= Subject: [ANCP] ANCP= =20 Protocol Versioning

Hi=20 All,

During yester= day's=20 ANCP WG meeting at IET75 we discussed the topic of ANCP=20 versioning and in the room arrived at the following=20 conclusion:

The Pre-RFC v= ersion=20 of ANC will continue to be 3.1 as per draft-ietf-ancp-proto= col,=20 however an RFC Editor's note will be introduced to change=20 version from 3.1 to 3.2 upon publication of the RFC. This w= ill=20 clearly de-lineate any pre-RFC implementations with post-RF= C=20 ones and alleviate the operators'' problems presented=20 (http://www3.i= etf.org/proceedings/75/slides/ancp-3.ppt)

Going beyond = the=20 publication of the RFC, the introduction of new capabilitie= s or=20 TLVs is expected to be handled by the capability negotiatio= n=20 mechanism (and new capabilities) or possibly by generalizin= g the=20 notion of sub-capability currently in place for the=20 multicast-control use-cases.

We would like= to get=20 feedback from the wider WG on the above, especially in term= s of=20 anyone who was not able to voice their opinion at the meeti= ng.=20 Based on the received feedback, we'll make a call regarding= the=20 WG consensus on this matter.

Regards,=20
Woj.=20

<= /HTML> --_000_786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448USPITMAIL01ec_-- From fqhuang@huawei.com Tue Aug 18 02:44:54 2009 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 4E10228C0F2 for ; Tue, 18 Aug 2009 02:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.095 X-Spam-Level: X-Spam-Status: No, score=0.095 tagged_above=-999 required=5 tests=[AWL=1.809, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] 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 SZYTjXFA73X2 for ; Tue, 18 Aug 2009 02:44:53 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 768223A6D6C for ; Tue, 18 Aug 2009 02:44:06 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK005CYG7FP6@szxga03-in.huawei.com> for ancp@ietf.org; Tue, 18 Aug 2009 17:40:27 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KOK003WJG7E7C@szxga03-in.huawei.com> for ancp@ietf.org; Tue, 18 Aug 2009 17:40:26 +0800 (CST) Received: from h36145c ([10.70.39.74]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KOK00JSQG7DM2@szxml04-in.huawei.com> for ancp@ietf.org; Tue, 18 Aug 2009 17:40:25 +0800 (CST) Date: Tue, 18 Aug 2009 17:40:25 +0800 From: Fortune HUANG To: ancp@ietf.org Message-id: <004e01ca1fe7$e9b462e0$4a27460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_/wzmnkVbFy6jdLCxGJHs8A)" Thread-index: Acof5+mejpAztfF6RLOLa8ryNZWX8Q== Subject: [ANCP] Question about Multicast Status Message in draft-ietf-ancp-mc-extensions-00 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, 18 Aug 2009 09:44:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_/wzmnkVbFy6jdLCxGJHs8A) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, I am puzzled about using Multicast Status Message for failed response in many different procedures (e.g. Delegated Bandwidth Query, Multicast Flow Query) in draft-ietf-ancp-mc-extensions-00. Take the Delegated Bandwidth Query procedure in section 4.8 for example. Three messages are involved in this procedure. 1) Delegated Bandwidth Query Request 2) Delegated Bandwidth Query Response: used as a successful response, Result field always Success (0x3) 3) Multicast Status Message: used as a failed response I am wondering why we can not allow the Result field to be set other values than Success (0x3), e.g. Failure (0x4). In fact, I think we can use Delegated Bandwidth Query Response for both the successful and failed cases if we don't force to Result field to be always Success (0x3). Then only two messages are involved in the Delegated Bandwidth Query procedure: 1) Delegated Bandwidth Query Request 2) Delegated Bandwidth Query Response: Result field Success (0x3) for successful case, Result field Failure (0x4) for failed case As far as I know, TLVs could be optional. The message sender can decide which TLVs should be included in the message in different cases. If you look at Diameter protocol, it is just like this. So I think it would be more reasonable using one message for the response no matter it is a successful or failed response. That is also why we need a Result field in the response message. Best regards, Fortune --Boundary_(ID_/wzmnkVbFy6jdLCxGJHs8A) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi all,
 
I am puzzled about using Multicast Status Message for failed response in many different procedures (e.g. Delegated Bandwidth Query, Multicast Flow Query) in draft-ietf-ancp-mc-extensions-00.
 
Take the Delegated Bandwidth Query procedure in section 4.8 for example.  Three messages are involved in this procedure.
 
1) Delegated Bandwidth Query Request
2) Delegated Bandwidth Query Response: used as a successful response, Result field always Success (0x3)
3) Multicast Status Message: used as a failed response
 
I am wondering why we can not allow the Result field to be set other values than Success (0x3), e.g.  Failure (0x4).
In fact, I think we can use Delegated Bandwidth Query Response for both the successful and failed cases if we don't force to Result field to be always Success (0x3).  Then only two messages are involved in the Delegated Bandwidth Query procedure:
 
1) Delegated Bandwidth Query Request
2) Delegated Bandwidth Query Response: Result field Success (0x3) for successful case, Result field Failure (0x4) for failed case
 
As far as I know, TLVs could be optional. The message sender can decide which TLVs should be included in the message in different cases. If you look at Diameter protocol, it is just like this. So I think it would be more reasonable using one message for the response no matter it is a successful or failed response. That is also why we need a Result field in the response message.
 
 
Best regards,
Fortune
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
--Boundary_(ID_/wzmnkVbFy6jdLCxGJHs8A)-- From tom.taylor@rogers.com Tue Aug 18 08:04:54 2009 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 93C683A6E6D for ; Tue, 18 Aug 2009 08:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] 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 NB7A6k905d3M for ; Tue, 18 Aug 2009 08:04:53 -0700 (PDT) Received: from smtp125.rog.mail.re2.yahoo.com (smtp125.rog.mail.re2.yahoo.com [206.190.53.30]) by core3.amsl.com (Postfix) with SMTP id 033D03A6E51 for ; Tue, 18 Aug 2009 08:03:56 -0700 (PDT) Received: (qmail 23802 invoked from network); 18 Aug 2009 15:03:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=htQaEnaB4BynBtq5nanp31/fPKaNdXzKO9tKRT0CbNJMCTtODetMOfIlWdOQC+9RyQduG27Fsb/okZqqzpVeTuFJiTE2ERwJI0sRFimZdRuiuXOb/RHLJol4lweOr/0Otvapt+MivWb8manlW5k9k2Jf7Ue1h+c5rqZGgPT5YKo= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp125.rog.mail.re2.yahoo.com with SMTP; 18 Aug 2009 15:03:42 -0000 X-YMail-OSG: j8SMrywVM1ku1FtJUilycD20st6ByOCvjisySjhQYjLCtqPXXBNzAn88dzocl8Lt7g-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A8AC2CD.1090501@rogers.com> Date: Tue, 18 Aug 2009 11:03:41 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fortune HUANG References: <004e01ca1fe7$e9b462e0$4a27460a@china.huawei.com> In-Reply-To: <004e01ca1fe7$e9b462e0$4a27460a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] Question about Multicast Status Message in draft-ietf-ancp-mc-extensions-00 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, 18 Aug 2009 15:04:54 -0000 I have an action item to redefine the Multicast Status message as a message (say, Status) supported by the base protocol. I'm ready to start working on that, except that you are raising a possible alternative that needs discussion. Let me generalize the question you are raising. You point out that the current text provides for two possible responses to a Delegated Bandwidth Query message: a Delegated Bandwidth Response, or a Multicast Status message. This alternative actually applies to most of the messages defined for ANCP, since the possible status codes (shorthand for Result Code within the Status-Info field) in the Multicast Status message include some very general error cases. I assume your concerns are: - having to watch for two different responses complicates the original sender's state machine; - the sender has to correlate the [Multicast] Status message with the original message. The alternative you suggest is that the response always matches the request. It seems to me this implies that in the case of failures the response has to contain a Status-Info field. This should be specified as a basic feature of the protocol (i.e. in the base protocol specification). We can define some exceptions where an independent Status message is needed, if the condition being identified is independent of a specific request. So I'll work on my text proposal for a base-level Status message. But could we have comments on the proposal to replace Status with a failed response to the original request as the normal error response?? Tom Taylor Fortune HUANG wrote: > Hi all, > > I am puzzled about using Multicast Status Message for failed response in > many different procedures (e.g. Delegated Bandwidth Query, Multicast Flow > Query) in draft-ietf-ancp-mc-extensions-00. > > Take the Delegated Bandwidth Query procedure in section 4.8 for example. > Three messages are involved in this procedure. > > 1) Delegated Bandwidth Query Request > 2) Delegated Bandwidth Query Response: used as a successful response, Result > field always Success (0x3) > 3) Multicast Status Message: used as a failed response > > I am wondering why we can not allow the Result field to be set other values > than Success (0x3), e.g. Failure (0x4). > In fact, I think we can use Delegated Bandwidth Query Response for both the > successful and failed cases if we don't force to Result field to be always > Success (0x3). Then only two messages are involved in the Delegated > Bandwidth Query procedure: > > 1) Delegated Bandwidth Query Request > 2) Delegated Bandwidth Query Response: Result field Success (0x3) for > successful case, Result field Failure (0x4) for failed case > > As far as I know, TLVs could be optional. The message sender can decide > which TLVs should be included in the message in different cases. If you look > at Diameter protocol, it is just like this. So I think it would be more > reasonable using one message for the response no matter it is a successful > or failed response. That is also why we need a Result field in the response > message. > > > Best regards, > Fortune > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom.taylor@rogers.com Mon Aug 24 20:11:20 2009 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 8D2B628C42D for ; Mon, 24 Aug 2009 20:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.981, BAYES_50=0.001] 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 sGiDH6EC-J6r for ; Mon, 24 Aug 2009 20:11:19 -0700 (PDT) Received: from smtp111.rog.mail.re2.yahoo.com (smtp111.rog.mail.re2.yahoo.com [206.190.37.1]) by core3.amsl.com (Postfix) with SMTP id 9B80628C421 for ; Mon, 24 Aug 2009 20:11:19 -0700 (PDT) Received: (qmail 18050 invoked from network); 25 Aug 2009 03:11:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=JfHXYuiZSzAS+shnaCOZ3dN3zSIjou7brHnuR8pcWkenGQTjPZzCbe3BzItYx0Ir1A59PtGnpcLoHvag0EEPWZnTtJ/8dfV2au/7aqFNRNiNWBHDO0wuz7nnQ/aotvJvqVRk867vrIYR0MOetaujVCXkOU5T5UGvuxyRlsuUjfA= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp111.rog.mail.re2.yahoo.com with SMTP; 25 Aug 2009 03:11:24 -0000 X-YMail-OSG: 3C9LYGAVM1mFCJN4_XbjRkAIbp3aLJ4_AolyHu8In4dFid.kcmnJWiDg7iFk_Ae5KA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A93565B.9080508@rogers.com> Date: Mon, 24 Aug 2009 23:11:23 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] Multicast Sub-Capability Definition 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, 25 Aug 2009 03:11:20 -0000 I would suggest that the multicast sub-capabilities be defined in terms of independent sets of messages and TLVs supported. Once we have done that, we can describe their relationships. I suggest the following sub-capabilities: a) NAS-controlled replication Implies support of the Multicast Replication Control message b) NAS-controlled admission Implies support of the Multicast Admission Control message c) Bandwidth delegation Indication of this sub-capability means that the indicating device supports the following messages and TLVs: Messages: Bandwidth Reallocation Request Bandwidth Transfer Delegated Bandwidth Query TLVs: Bandwidth-Delegation-Control Bandwidth-Allocation Bandwidth-Request Bandwidth-Status d) Shared admission Implies support of the Multicast-Service-Profile-Name and Multicast-Service-Profile TLVs. I believe a), b) and c) can be implemented independently of each other. d) requires b) as a prerequisite. We can discuss whether support of multicast automatically implies support of the Multicast Flow Query message and Multicast-Flow TLV, or whether this is another sub-capability, independent of the other four. From tom.taylor@rogers.com Tue Aug 25 06:29:55 2009 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 E9BB93A6F87 for ; Tue, 25 Aug 2009 06:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.243 X-Spam-Level: X-Spam-Status: No, score=-2.243 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599] 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 1lIyWOMpjcHx for ; Tue, 25 Aug 2009 06:29:55 -0700 (PDT) Received: from smtp117.rog.mail.re2.yahoo.com (smtp117.rog.mail.re2.yahoo.com [68.142.225.233]) by core3.amsl.com (Postfix) with SMTP id A222E3A6F7E for ; Tue, 25 Aug 2009 06:29:37 -0700 (PDT) Received: (qmail 50163 invoked from network); 25 Aug 2009 13:29:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=W0ssJK5mhCy7yqzB4kiyDjjci9++aIIRJ3Z/7430twFrczEiFeFME3TPwLLTOrSIkAZbzbfenOp/EoJL+Ux5Y38pe8Rbpjni4py38oeZXRYGt1fa9J8wb2ghJ0slKOc7iGxxIPA92MlQAieF+rI1VQ6ehQuNha9HUj1b05SWNYg= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp117.rog.mail.re2.yahoo.com with SMTP; 25 Aug 2009 13:29:40 -0000 X-YMail-OSG: xGSC2hUVM1nPxUbmOaWqnFendwKdPQMERkrKnNd_qCD1OdwXv9MuT1ounImTj2VODw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A93E743.8020003@rogers.com> Date: Tue, 25 Aug 2009 09:29:39 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org References: <4A93565B.9080508@rogers.com> In-Reply-To: <4A93565B.9080508@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ANCP] Multicast Sub-Capability Definition 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, 25 Aug 2009 13:29:56 -0000 Thinking further about this, I wonder if these are actually capabilities rather than sub-capabilities? That would imply (in my personal view of things, a position I've proposed before) that each is written up in its own document. It would also be nice to break the multicast service profile capability into two: - basic dynamic multicast service profile provisioning, which conveys black and white lists per subscriber - shared admission control, which adds the grey list capability. Tom Taylor wrote: > I would suggest that the multicast sub-capabilities be defined in terms > of independent sets of messages and TLVs supported. Once we have done > that, we can describe their relationships. > > I suggest the following sub-capabilities: > > a) NAS-controlled replication > > Implies support of the Multicast Replication Control message > > b) NAS-controlled admission > > Implies support of the Multicast Admission Control message > > c) Bandwidth delegation > > Indication of this sub-capability means that the indicating device > supports the following messages and TLVs: > > Messages: > > Bandwidth Reallocation Request > Bandwidth Transfer > Delegated Bandwidth Query > > TLVs: > > Bandwidth-Delegation-Control > Bandwidth-Allocation > Bandwidth-Request > Bandwidth-Status > > d) Shared admission > > Implies support of the Multicast-Service-Profile-Name and > Multicast-Service-Profile TLVs. > > I believe a), b) and c) can be implemented independently of each other. > d) requires b) as a prerequisite. > > We can discuss whether support of multicast automatically implies > support of the Multicast Flow Query message and Multicast-Flow TLV, or > whether this is another sub-capability, independent of the other four. > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > From tom.taylor@rogers.com Tue Aug 25 17:58:38 2009 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 956AF3A702F for ; Tue, 25 Aug 2009 17:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599] 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 g6-Clt8oYVI2 for ; Tue, 25 Aug 2009 17:58:37 -0700 (PDT) Received: from smtp132.rog.mail.re2.yahoo.com (smtp132.rog.mail.re2.yahoo.com [206.190.53.37]) by core3.amsl.com (Postfix) with SMTP id 141FE3A7008 for ; Tue, 25 Aug 2009 17:58:32 -0700 (PDT) Received: (qmail 60652 invoked from network); 26 Aug 2009 00:58:36 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=cnkPt0zQcX8V2Dqkgem1VEyZn9oiSPRuolUstBloRePRG318/wtUxmscdPVcV83zkQ206eFCPLnHC0U+5OGifI14Ywz2dxvfaTNCiCcEWlxnEVM0NY2fUiUnR9X+wwZMWtskap0k/QSHrHuZYURw3Hj5Ly9HNjSOyDoZVYogBLU= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp132.rog.mail.re2.yahoo.com with SMTP; 26 Aug 2009 00:58:36 -0000 X-YMail-OSG: .3hk_nQVM1m_HIgYyVuf3uiAX0bS058DZwdxBbphtR9QDIYh.svyeKxj0awH.Dw4VA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A9488BB.9070704@rogers.com> Date: Tue, 25 Aug 2009 20:58:35 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] Proposal for replacement of "Multicast Status" message, Part 1 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, 26 Aug 2009 00:58:38 -0000 I had an action out of last meeting to propose a base-level replacement for the Multicast Status message. Further to this topic, Fortune Huang pointed out that the use of Multicast Status as an error response to the Delegated Bandwidth Query request is an unnecessary complication. The point seems to be valid. As a general principle for our specification work, I propose the following: If a specific response type is defined for a particular message, the correct way to report a failure is to send that response with the Result field set to Failure and the Code field set to an appropriate value. In looking at the new generic response message, I also wondered why the GSMPv3 error mechanism is duplicated in the Status-Info TLV. The Result Code field in Status-Info is really the Code field in the header that has to be set to the right value when the header Result field is set to Failure. It would seem to make more sense to use the GSMPv3 mechanism, and use the Status-Info TLV just to add information that GSMPv3 lacks. In particular, to aid in correlation, Status-Info should contain the sent Message Type value. Given that that Command TLVs will be present only in a limited set of message types, and "Cmnd Nmbr" is not one of the fields defined within the Command TLV, I would also remove "Cmnd Nmbr" from Status-Info. It can always be specified as part of the failure response to a particular message type. With these preliminary considerations, here are my text proposals for moving the generic response message (AKA Multicast Status) to base. These proposals apply to the base document (draft-ietf-ancp-protocol-06) only. The changes to the multicast extensions document (draft-ietf-ancp-mc-extensions-00.txt) will be described in another message. 1. Modifications to base protocol section 5, description of Code field ====================================================================== Add the following text to the description of the Code field: ANCP implementations MAY use any of the Code values specified in the IANA registry "Global Switch Management Protocol version 3 (GSMPv3) Failure Response Message Name Space" if they appear applicable. In particular, the values: 2 Invalid request message (i.e., a properly formed message which violates the protocol through its timing or direction of transmission). 4 One or more of the specified ports does not exist. 6 One or more of the specified ports is down. 7 Invalid Partition ID. 19 Out of resources (e.g. memory exhausted, etc.). 30 The limit on the maximum number of point-to- multipoint connections that the switch can support has been reached. 31 The limit on the maximum number of branches that the specified point-to-multipoint connection can support has been reached. may unfortunately apply to ANCP usage, including the case where "port" is interpreted to mean Target as defined in section 5.4.5.1. Instead of the value: 3 The specified request is not implemented on this switch. specified by RFC 3292, this specification defines a new value: 81 Request message type not implemented. This value MAY be sent in a failure response from either the AN or the NAS. This specification also defines the additional values: 82 Transaction identifier out of sequence. 83 Malformed message. ANCP extensions defining new code values SHOULD use the range 0x0100 through 0x01ff for this purpose. 2. Modifications to base protocol section 5.4.5.1.3 Status-Info TLV ==================================================================== (a) Remove the Result Code and mark the field as "Reserved". Indicate that it MUST be set to zeroes by the sender and ignored by the receiver. (b) Change the term "command number" to "message type" and modify the field name accordingly from "Cmnd Nmbr" to "Msg Type". 3. New base protocol section 5.4.5.2 General Response Message ============================================================= Here is the proposed text. 5.4.5.2 Generic Response Message This section defines the Generic Response message. The Generic Response message may be specified as the appropriate response to a message defined in an extension to ANCP, instead of a more specific response message. As a general guideline, specification of the Generic Response message as a response is appropriate where no data needs to be returned to the peer other than a result (success or failure), plus, in the case of a failure, a code indicating the reason for failure and a limited amount of diagnostic data. Depending on the particular use case, the Generic Response message MAY be sent by either the NAS or the AN. The AN or NAS MAY send a Generic Response message indicating a failure condition independently of a specific request before closing the adjacency as a consequence of that failure condition. In this case, the sender MUST set the Transaction Identifier field in the header and the Message Type field within the Status-info TLV to zeroes. The receiver MAY record the information contained in the Status-info TLV for management use. The format of the Generic Response message is shown in Figure 17. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (0x88-0C) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers | Sub |MessageType=91 |Result | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status-info-TLV=0x12 | Status-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Msg type | Error Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Message (padded to 4) if Length > 0 | +---------------------------------------------------------------+ | sub-TLVs... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 17 - Structure of the Generic Response Message Message Type The message type value for the Generic Response message is 0x91. Result The value of the Result field for the Generic Response message MUST be either Success (0x03) or Failure (0x04). Code The Code field MUST have value zero if Result is set to Success (0x03). It MUST have an appropriate non-zero value if Result is set to Failure (0x04). As discussed in section 5, extensions to ANCP MAY define new Code values for use in failure responses for specific request message types. Partition ID As specified in section 5. Transaction Identifier The Transaction Identifier MUST be copied from the request to which the Generic Response message is responding. I, Sub-message Number, Length As specified in section 5. Status-info TLV MAY be present in a success response, to provide a warning as defined for a specific request message type. MUST be present in a failure response. The Message Type field value is copied from the header of the request message. The Error Message field contains human-readable diagnostic text. The description of the response for a particular request message type MAY specify further sub-TLVs to be included in Status-info, either generally or for specific failure Code values. 4. Modifications to base protocol IANA section ============================================== (a) Add the following text preceding the paragraph beginning: "This document reserves the range 0x500 to 0x5ff of GSMPv3 Failure Response Message Name Space registry ..." This document adds the following values to the GSMPv3 Failure Response Message Name Space registry: Value Failure Response Message Name Reference ------- ---------------------------------------------------------- --------- 81 Request message type not implemented. [This RFC] 82 Transaction identifier out of sequence. [This RFC] 83 Malformed message. [This RFC] This document reserves the values 0x100 to 0x1ff (256 to 511) within the GSMPv3 Failure Response Message Name Space registry for use by extensions to the Access Node Control Protocol (ANCP). (b) Delete the proposed ANCP Status-Info Result Code registry. Tom Taylor From HaagT@telekom.de Thu Aug 27 07:00:54 2009 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 34F5428C5A0 for ; Thu, 27 Aug 2009 07:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.512 X-Spam-Level: X-Spam-Status: No, score=-0.512 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_20=-0.74, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_LOW=-1] 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 u+MDfhiIb6XS for ; Thu, 27 Aug 2009 07:00:30 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id D1C2D3A684A for ; Thu, 27 Aug 2009 07:00:28 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 27 Aug 2009 16:00:26 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2009 16:00:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA271E.B92E8EE4" Date: Thu, 27 Aug 2009 16:00:21 +0200 Message-ID: <5661758E3E93364685B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [ANCP] ANCP Protocol Versioning thread-index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCAAAisdsAAGgIPAAALHiLACNqY60AADyFzwAA9NFwAAB2HpsAMb5New References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de><35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> From: To: , , , , , , X-OriginalArrivalTime: 27 Aug 2009 14:00:24.0976 (UTC) FILETIME=[B9987900:01CA271E] Cc: B.Witschurke@telekom.de, Peter.Hamacher@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning 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: Thu, 27 Aug 2009 14:00:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA271E.B92E8EE4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, =20 All exchanged arguments are valid. =20 I think a protocol draft describes protocol issues, values, TLV, etc. = and not network element mechanisms.=20 The challenge now would be to cover notes pointing out how to code pre = version and RFC version - that was agreed last meeting. =20 But what's missing in that game is a short description that both peers = (BRAS & AN) need to identify which SW version to choose based on sub = version value.=20 A mechnism in detail for detection and automatic SW load depending on = sub version is neccessary. =20 I'm not sure if that is in scope of a protocol draft or if it should be = described seperately. But keeping the time line of protocol draft and = avoiding delaying ANCP work it may be desirable to identify sections in = protocol draft where notes are useful to detail that issue without = changing sections and order of the document. =20 =20 >From my understanding three sections are concerned. I propose adding the = notes at that sections.=20 =20 Please see below the identified sections and added notes taken based on = protocol draft 05 for discussion: =20 Regards Thomas = -------------------------------------------------------------------------= -------- =20 Chapter 2 Introduction / page 4: ... Not all the fields in relevant GSMP messages are used by ANCP. This = draft indicates the value that ANCP should set for the fields in these = GSMP messages. =20 [T.H.:] Note: Implementations which use GSMP and ANCP conventions before = RFC publication must use sub-version 1. RFC based implementations must use sub-version 2. = For details see chapter 5. ... -------------------------------------------------------------------------= -----------=20 Chapter 5. Access Node Control Protocol (ANCP) / page 15 ... The 8-bit version field in the base GSMPv3 message header is split into two 4 bit fields for carrying the version and a sub-version of the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP protocol. An ANCP implementation SHOULD always set the version field = to 3, and the sub-version field to 1. The Result field in the message header has been modified to be 4 bits long, and the Code field to be 12 bits long. =20 Version: =20 The version number of the GSMP protocol being used in this session. ANCP uses version 3. =20 Sub-Version: =20 The sub-version number of the GSMP protocol being used in this session. ANCP must use sub-version 2 of the GSMP protocol. = [T.H]:Pre RFC=20 implemtations must use sub-version 1. =20 --------------------------------------------------------------------- =20 Chapter 5.1. ANCP/TCP connection establishment / Page 19: =20 ... =20 NAS listens for incoming connections from the access nodes. Port 6068 is used for TCP connection. Adjacency protocol messages, which are used to synchronize the NAS and access-nodes and maintain handshakes, are sent after the TCP connection is established. ANCP messages other than adjacency protocol messages may be sent only after the adjacency protocol has achieved synchronization. =20 [T.H.]:Note: NAS must detect per peer the sub version and must load and = synchronize with appropriate protocol implementation. =20 ... _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Robert Rennison Gesendet: Montag, 10. August 2009 22:04 An: Alan Kavanagh; Hamacher, Peter; lihy@huawei.com; PeterArberg; = wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org Cc: Haag, Thomas; Witschurke, Birgit Betreff: Re: [ANCP] ANCP Protocol Versioning Alan, =20 Ok so perhaps the RFC may use a "may" but in a non normative section. =20 A lot would depend on where in the document you wished to place any such = note. As Woj pointed out in an earlier email, anything in a normative = section would most likely not get past the editors. =20 Perhaps an appendix " =20 I'd be reluctant to cover how to negotiate the version. Your reference = to section 5.3 refers to capabilities negotiation not version = negotiation which is covered in section 11.1 of 3292 where the version = negotiation is discussed, note however that this refers to a single = version field not the version/sub version field as used in ANCP. Once = you get into mentioning the version negotiation then one would have to = cover how one tell the difference between versions of the versions i.e. = between these versions using Version 3.1 draft-wadwha- vs = draft-ietf-ancp-.... . =20 =20 Hence it would perhaps be better to omit anything about how to do any = version negotiation. say that the RFC compliant version may use the = version/subversion field to detect a pre-standard implementation and = that this maybe done on a per peer basis such that a given NAS may = support both Standards compliant 3.2 and pre-standard =20 How about. =20 -------------------------------------------------------------------------= -------------- Appendix. Handling of pre-RFC deployments of the ANCP protocol =20 This appendix is non normative =20 Prior to completion of this document, several pre-RFC versions of the = protocol were documented and implemented.=20 There were numerous pre-standard versions of the protocol all using a = version/subversion field set to 3.1. =20 A NAS implementing the ANCP protocol as defined in this document may, on = a peer basis, use the version and subversion field to detect a pre-RFC implementation of the protocol and choose to work = with such pre-RFC peers ( e.g NAS or DSLAM) -------------------------------------------------------------------------= ---------- =20 Note lower case "may" since I'm not sure that upper case MAY applies in = non-normative text. =20 Cheers =20 Rob _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: Monday, August 10, 2009 11:46 AM To: Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; = wdec@cisco.com; swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning Hi All I typed up some text to include in the ancp protocol draft,based on some = discussions. So from reading the minutes it appears that the WG has = agreed on moving the sub-version number to 2, which gives us Version/Sub = 3.2. It makes sense to have this clearly noted in the ietf-ancp-protocol = draft. I suggest on adding the following text to the ancp protocol draft = to provide a clear reasoning and for the uplift and move us forward: Prior to initiation of this work, existing ANCP deployments used an ANCP = Protocol Version/Sub-Version 3.1. which differs in the TLV's from this = RFC standards track version. Therefore RFC compliant versions MAY choose = to work with such pre-RFC peers (NAS and DSLAM).=20 A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp = protocol Version/Sub-Version is set on a per peer basis and is = synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section 5.3. to agree on the protocol version to use.=20 Alan _____ =20 From: Peter.Hamacher@telekom.de [mailto:Peter.Hamacher@telekom.de]=20 Sent: August 10, 2009 11:35 AM To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan Kavanagh; = swadhwa@juniper.net; ancp@ietf.org Cc: HaagT@telekom.de; B.Witschurke@telekom.de Subject: AW: [ANCP] ANCP Protocol Versioning Hi all, =20 from our perspective it is essential to have a practible way to migrate = to RFC. =20 regards Peter Hamacher Deutsche Telekom Netzproduktion GmbH Zentrum Technik Einf=FChrung Peter Hamacher Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628 2864 (Tel.) +49 521 92100494 (Fax) E-Mail: Peter.Hamacher@telekom.de http://www.telekom.com =20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 Erleben, was verbindet. =20 _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Hongyu Li Gesendet: Montag, 10. August 2009 08:52 An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay = Wadhwa'; ancp@ietf.org Betreff: Re: [ANCP] ANCP Protocol Versioning Hi Peter, =20 I guess you are afraid when a new BNG implementing ANCP per the future = RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question = that should go to operators having pre-rfc ANs. If they request so, we = may have to define both 3.1 and 3.2 actions in the draft, which is = really odd. Otherwise, it is only a piece of cake. Everybody just = follows rfc. =20 cheers, Hongyu =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Peter Arberg Sent: Thursday, July 30, 2009 8:38 AM To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Hi Woj, =20 I did not realize it was last-call, I must have missed that email on the = mailing list. =20 I agree with you that also to my knowledge different implementations = have been able to keep backward compatibility to earlier drafts, and if the introduction = of the new version=20 number 3.2 is because of fear of non compatible implementations then it = is not valid, as it is very doable to have backwards compatible to previous drafts so = far. =20 But in my mind it still seems like a good idea to bump the version = number, if for nothing else then to mark the ANCP standards first step is complete, and to move = away one more step to the GSMP tie.=20 =20 But with the reference as you show and also all the reference we still = have to GSMP in the=20 draft document, it just seems like we are making it very difficult for = any newcomers to the=20 ANCP work to decide what to do and what not to do. =20 I'm not very afraid that vendors who already have a pre-standard ANCP = implementation can figure out what to do, but why not make it more easy for everyboby by = having a little more description on this. =20 In the GSMP RFC which is referenced it states: --- GSMP contains an adjacency protocol. The adjacency protocol is used to synchronise states across the link, to negotiate which version of the GSMP protocol to use, to discover the identity of the entity at the other end of a link, and to detect when it changes. --- =20 another place in the GSMP RFC it talks about a minimum set of messages = which must be supported for a version, so by having still GSMP reference in the ANCP = draft, and yet no clear statement on what protocol version we would expect to make an adjency = seems wrong to me. =20 =20 In my mind it do not have to be a long section, it can be done in a = small paragraph to describe that the ANCP version of 3.2 should be able to change it's version to a = lower pre-standard 3.1=20 version if it supports earlier drafts of ANCP. =20 Do we know what happens to existing ANCP implementations if the see a = adjancy message with a version number different from 3.1 ? =20 cheers, Peter =20 =20 =20 =20 _____ =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: 29. juli 2009 16:41 To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Peter, =20 so, based on the experience with the IESG review of last call drafts, = one has reason to believe that pulling a trick like referring to a v3.1 = in anything but non normative is not going fly (nor would it be = reasonable if it happens to be exactly the same as v3.2). The time of = making it to rfc of a v3.1 has very little to do with it, since the = latest draft of the protocol spec is to our knowledge 100% compatible = with "pre-standard" implementation except for new capabilities. Anyway, before we go off documenting all that, perhaps a step back = should be taken to evaluate the situation: - the currently deployed protocol, based on some set of the current = drafts, has it's core functionality intact. I.e. Given that in all new = activities we've strived for backwards compatibility, with the exception = of historic tlv conflict, there doesn't seem to be much of a reason for = v3.2 - the tlv conflict is inherent to a stage of ANCP development and a v3.2 = or its claims of backward compatibility to v3.1 (with conflicting tlv = set) are not going to matter; the affected tlvs will still clash, = irrespective of "backwards compatibility" of versions. - Capability negotiation as offered by ANCP by itself provides a way to = distinguish new protocol functions. It's here that the WG has been = spending most of its time, and it's recognised as the way in which the = protocol will evolve (or via sub-capabilities) - An operator has requested that a line be drawn to distinguish a set of = compatible pre-standard implementations (thus same pre-standard = versions) that they are running and the actual standard which may be in = their opinion incompatible, hence v3.1 becomes to v3.2. The same = operator has not expressed a need to have an rfc for v3.1 - Migrating from v3.1 to v3.2 is an operational activity for which the = protocol does not appear to require modification (this appears to be no = different than transitioning from L2TPv2 to v3 say). - The current protocol draft states that the version SHOULD be 3.1 = (which appears to need a correction) =20 Based on the above, it seems to me that if we go at a stroke to a v3.2 = when the rfc gets published we could try to navigate by having a clause = which states that pre-rfc eg v3.1 *may* be compatible and a hint to = reflect that version number to the sender but leaving remaining = behaviour un-specified (since there is no actual guarantee of = compatibility). How does this sound? =20 Cheers, Woj. _____ =20 From: Peter Arberg [mailto:parberg@redback.com]=20 Sent: 29 July 2009 21:55 To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj, =20 As I see it the problem is exactly that we do not have a normative = reference in a RFC simply because we have been too long to put anything together on the = running code which are deployed in live networks today. =20 We have a L2CP reference in a TR document and we have live networks. =20 So if we decide to go for version 3.2 in the ANCP WG, it would be very = beneficial to have a chapter in the RFC which describe migration from pre-standard ANCP to = the standard RFC. =20 I'm sure carriers having pre-standard ANCP running in their network will = like a clear RFC statement for how we vendors should handle a incompatibility in a = defacto ANCP standard and the "real" ANCP RFC standard. =20 So instead of a normative reference i will suggest that the RFC editor = of the ANCP protocol=20 write a chapter and describe what is expected when a RFC standard ANCP = ver. 3.2=20 implementation is getting adjancy connection request from a pre-standard = ver. 3.1 ANCP endpoint. =20 Too me this seems like a much too important question to simply ignore in = a new protocol which have been in the development for more than 3 years, and have had live = networks in multi-vendor deployments for a long time. =20 thanks, Peter _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: 29. juli 2009 12:22 To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Your post bears no useful or constructive input regarding the topic. = Attempting to define backwards compatibility means drawing on a = normative reference to non-standard drafts and is not reasonable (a = reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could = be so kind as to give us advise the WG as to where ANCP version 3.1 is = defined and can be normatively referenced in a v3.2 RFC?=20 If v3.2 and v3.1 are 100% compatible, except for new capabilities, then = there is hardly a reason for a version change. The only way to have a = reference to v3.1 in an rfc re v3.2 is either as a historic note, = without claims of backwards compatibility, or publish two rfcs (a v3.1 = and then a v3.2). Neither of these proposals seem to be appealing. =20 In addition, you may also want to reflect on the quality of your = conclusions and comprehension of general facts... =20 -Woj. =20 _____ =20 From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning So what are you sugegsting will happen with current deployments....!!! = Like it or not Woj, fact is it must be covered, if you dont agree then = thats just your single opinion here. =20 By the time you agree on everything we will be onto ANCP Version 4.10 = !!! We are spending far too long on getting this draft out the door. _____ =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is = NOT defined anywhere (in any normative reference or RFC) does not seem = to be acceptable. The (minuted) discussion did not cover the notion of how ANCP "version = incompatibility" will be handled. Given that we're not out in the WG to = create version compatibility between an ANCP standard protocol and an = ANCP non-standard based one (or GSMP for that matter), it would seem = that no new definition needs to take place. Feel free to discuss this = further on this thread... =20 -Woj. _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning In order to ease migration, it will help if BNGs are able to handle = multiple peers with different versions (e.g. a 3.2 compliant BNG = implementation able to work with a 3.1 AN and a 3.2 AN). Although = implied by the protocol, we may want to explicitly state that version = compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility = between BNG and AN needs to be handled. =20 -Sanjay _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on Monday = as i did not attend) is "backward compatibility" between the different = versions of 3.1, 3.2 and future versions if/when/as needed. this should = be noted in the draft. =20 Alan =20 _____ =20 From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is = being defined. Also strictly speaking there is no distinction between = version and sub-version, so the choice of 3.2 is purely based on custom = (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will = automatically be 100% incompatible with the rfc. =20 -Woj. =20 _____ =20 From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's = presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 _____ =20 From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of = Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of = ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol, however an RFC Editor's note will be = introduced to change version from 3.1 to 3.2 upon publication of the = RFC. This will clearly de-lineate any pre-RFC implementations with = post-RFC ones and alleviate the operators'' problems presented ( = = http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt) Going beyond the publication of the RFC, the introduction of new = capabilities or TLVs is expected to be handled by the capability = negotiation mechanism (and new capabilities) or possibly by generalizing = the notion of sub-capability currently in place for the = multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially = in terms of anyone who was not able to voice their opinion at the = meeting. Based on the received feedback, we'll make a call regarding the = WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA271E.B92E8EE4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ANCP Protocol Versioning
All,
 
All exchanged arguments are = valid.
 
I think a protocol draft describes protocol = issues, values,=20 TLV, etc. and not network element mechanisms.
The challenge now would be to cover notes = pointing out how=20 to code pre version and RFC version - that was agreed last=20 meeting.
 
But what's missing in that game is a short = description that=20 both=20 peers (BRAS & AN) need to identify which SW version to choose = based on=20 sub version value.
A mechnism in detail for detection and = automatic SW load=20 depending on sub version is neccessary.
 
I'm not sure if that is in scope of a protocol = draft or if=20 it should be described seperately. But keeping the time line of = protocol=20 draft and avoiding delaying ANCP work it may be desirable to identify = sections=20 in protocol draft where notes are useful to detail that issue=20 without changing sections and order of the=20 document.  
 
From my understanding three sections are = concerned. I=20 propose adding the notes at that sections.
 
Please see below the = identified sections=20 and added notes taken based on protocol draft 05 for=20 discussion:
 
Regards
Thomas
 ----------------------------------------------------------------= -----------------
 
Chapter 2 Introduction / page=20 4:

…

Not all the fields in relevant GSMP = messages=20 are used by ANCP.  This = draft=20 indicates the value that ANCP should set for the fields in these GSMP=20 messages.

 

[T.H.:] Note:=20 Implementations which use GSMP and=20 ANCP conventions before RFC publication must use sub-version 1.

       &nbs= p;            = ;  RFC=20 based implementations must use sub-version 2. For details see chapter=20 5.

…

----------------------------------------------------------------= -------------------- 

Chapter 5. Access Node Control Protocol (ANCP) / = page=20 15

…

The 8-bit version field in the base = GSMPv3=20 message header is split

  =20 into two 4 bit fields for carrying the version and a sub-version=20 of

  =20 the GSMP protocol.  = ANCP uses=20 version 3 and sub-version 1 of the GSMP

  =20 protocol.  An ANCP=20 implementation SHOULD always set the version field

  =20 to 3, and the sub-version field to 1.  The Result field in=20 the

  =20 message header has been modified to be 4 bits long, and the=20 Code

  =20 field to be 12 bits long.

 

  =20 Version:

 

        = The=20 version number of the GSMP protocol being used in = this

       =20 session.  ANCP uses version=20 3.

 

  =20 Sub-Version:

 

       =20 The = sub-version=20 number of the GSMP protocol being used in this

       =20 session.  = ANCP must use sub-version = 2 of the=20 GSMP protocol. [T.H]:Pre RFC
       =   implemtations must use sub-version=20 1.

 
-----------------------------------= ----------------------------------
 
Chapter 5.1.  ANCP/TCP = connection=20 establishment / Page 19:
 
...
 
NAS listens for incoming = connections from=20 the access nodes.  Port
   6068 is used for TCP=20 connection.  Adjacency protocol messages, which
   are = used to=20 synchronize the NAS and access-nodes and maintain
   = handshakes,=20 are sent after the TCP connection is established.  = ANCP
  =20 messages other than adjacency protocol messages may be sent = only
  =20 after the adjacency protocol has achieved synchronization.
 
[T.H.]:Note: NAS must detect per peer = the sub=20 version and must load and synchronize with appropriate protocol=20 implementation.  

...
Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Robert=20 Rennison
Gesendet: Montag, 10. August 2009 22:04
An: = Alan=20 Kavanagh; Hamacher, Peter; lihy@huawei.com; PeterArberg; wdec@cisco.com; = swadhwa@juniper.net; ancp@ietf.org
Cc: Haag, Thomas; = Witschurke,=20 Birgit
Betreff: Re: [ANCP] ANCP Protocol=20 Versioning

Alan,
 
Ok so perhaps=20 the RFC may use a "may" but in a non normative = section.
 
A lot would=20 depend on where in the document you wished to place any such note. As = Woj=20 pointed out in an earlier email, anything in a normative section would = most=20 likely not get past the editors.
 
Perhaps an=20 appendix "
 
I'd be=20 reluctant to cover how to negotiate the version.  Your reference to = section=20 5.3 refers to capabilities negotiation not  version negotiation = which is=20 covered in  section 11.1 of 3292  where the version = negotiation is=20 discussed, note however that this refers to a single version field not = the=20 version/sub version field as used in ANCP. Once you get into mentioning = the=20 version  negotiation then one would have to cover how one tell the=20 difference between  versions of the versions i.e. between these=20 versions using Version 3.1  draft-wadwha- vs=20 draft-ietf-ancp-....  .
 
 
Hence it=20 would perhaps be better to  omit anything about how to do any = version=20 negotiation. say that the RFC compliant version may use the = version/subversion=20 field to detect a pre-standard implementation and that this maybe done = on a per=20 peer basis such that a given NAS may support both Standards = compliant =20 3.2  and pre-standard
 
How=20 about.
 
---------------------------------------------------------= ------------------------------
Appendix.=20 Handling of pre-RFC deployments of the ANCP =  protocol
 
This appendix=20 is non normative
 
Prior to=20 completion of this document, several pre-RFC  versions of the = protocol were=20 documented and implemented.
There were=20 numerous pre-standard versions of the protocol all using a=20 version/subversion field set to 3.1.
 
A NAS=20 implementing the ANCP protocol as defined in this document may, on a = peer basis,=20 use the version and subversion field
to detect a=20 pre-RFC implementation of the protocol and choose to work with such = pre-RFC=20 peers ( e.g NAS or DSLAM)
---------------------------------------------------------= --------------------------
 
Note lower=20 case "may" since I'm not sure that upper case MAY applies in = non-normative=20 text.
 
Cheers
 
Rob

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: Monday, August 10, 2009 11:46 = AM
To:=20 Peter.Hamacher@telekom.de; lihy@huawei.com; Peter Arberg; = wdec@cisco.com;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi All

I typed up some text to = include in the=20 ancp protocol draft,based on some = discussions.=20 So from reading the minutes it appears that the WG has = agreed on=20 moving the sub-version number to 2, which gives us Version/Sub 3.2. It = makes=20 sense to have this clearly noted in the ietf-ancp-protocol draft. I = suggest on=20 adding the following text to the ancp protocol draft to provide a clear reasoning and for the = uplift and=20 move us forward:

Prior to initiation of this work, existing ANCP deployments used an = ANCP=20 Protocol Version/Sub-Version 3.1. which differs in the TLV's from this = RFC=20 standards track version. Therefore RFC compliant versions MAY choose = to work=20 with such pre-RFC peers (NAS and DSLAM).

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The = ancp=20 protocol Version/Sub-Version is set on a per peer basis and is=20 synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in = section=20 5.3. to agree on the protocol version to use.

Alan

From: Peter.Hamacher@telekom.de=20 [mailto:Peter.Hamacher@telekom.de]
Sent: August 10, 2009 = 11:35=20 AM
To: lihy@huawei.com; Peter Arberg; wdec@cisco.com; Alan = Kavanagh;=20 swadhwa@juniper.net; ancp@ietf.org
Cc: HaagT@telekom.de;=20 B.Witschurke@telekom.de
Subject: AW: [ANCP] ANCP Protocol=20 Versioning

Hi all,
 
from our perspective it is essential to have = a practible=20 way to migrate to RFC.
 

regards
Peter=20 Hamacher


Deutsche Telekom Netzproduktion GmbH
Zentrum Technik=20 Einf=FChrung
Peter Hamacher
Heinrich-Hertz-Stra=DFe 3-7, 64295=20 Darmstadt
+49 6151 628 2864 (Tel.)
+49 521 92100494 = (Fax)
E-Mail:=20 Peter.Hamacher@telekom.de
http://www.telekom.com

Deutsche Telekom = Netzproduktion=20 GmbH
Aufsichtsrat: Timotheus H=F6ttges = (Vorsitzender)
Gesch=E4ftsf=FChrung:=20 Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus=20 Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der = Gesellschaft:=20 Bonn
USt-IdNr.: DE 814645262

Erleben, was verbindet.

 

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Hongyu=20 Li
Gesendet: Montag, 10. August 2009 08:52
An: = 'Peter=20 Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa';=20 ancp@ietf.org
Betreff: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
I guess you are afraid when a new BNG = implementing ANCP per=20 the future RFC, whether it can talk to pre-rfc version AN. IMHO, this = is a=20 question that should go to operators having pre-rfc ANs. If they = request so,=20 we may have to define both 3.1 and 3.2 actions in the draft, which is = really=20 odd. Otherwise, it is only a piece of cake. Everybody just follows=20 rfc.
 
cheers,
Hongyu

 
From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Peter=20 Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To: = Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: Re: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
I did not realize it was last-call, I must = have missed=20 that email on the mailing list.
 
I agree with you that also to my knowledge = different=20 implementations have been able to
keep backward compatibility to earlier = drafts, and if=20 the introduction of the new version
number 3.2 is because of fear of non = compatible=20 implementations then it is not valid, as
it is very doable to have backwards = compatible to=20 previous drafts so far.
 
But in my mind it still seems like a good = idea to bump=20 the version number, if for nothing
else then to mark the ANCP standards first = step is=20 complete, and to move away one more
step to the GSMP tie.
 
But with the reference as you show and also = all the=20 reference we still have to GSMP in the
draft document, it just seems like we are = making it=20 very difficult for any newcomers to the
ANCP work to decide what to do and what not = to=20 do.
 
I'm not very afraid that vendors who = already have a=20 pre-standard ANCP implementation can
figure out what to do, but why not make it = more easy=20 for everyboby by having a little more
description on this.
 
In the GSMP RFC which is referenced it=20 states:
---
   GSMP contains an adjacency = protocol. =20 The adjacency protocol is used
      to=20 synchronise states across the link, to negotiate which=20 version
      of the GSMP protocol to = use, to=20 discover the identity of the
      = entity at the=20 other end of a link, and to detect when it=20 changes.
---
 
another place in the GSMP RFC it talks = about a minimum=20 set of messages which must be
supported for a version, so by having still = GSMP=20 reference in the ANCP draft, and yet no clear
statement on what protocol version we would = expect to=20 make an adjency seems wrong to me.
 
 
In my mind it do not have to be a long = section, it can=20 be done in a small paragraph to describe
that the ANCP version of 3.2 should be able = to change=20 it's version to a lower pre-standard 3.1
version if it supports earlier drafts of=20 ANCP.
 
Do we know what happens to existing ANCP=20 implementations if the see a adjancy message
with a version number different from 3.1=20 ?
 
cheers,
Peter
 
 
 
 

From: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Sent: 29. juli 2009 = 16:41
To:=20 Peter Arberg; Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Peter,
 
so, based on the experience with the IESG review of = last call=20 drafts, one has reason to believe that pulling a trick = like=20 referring to a  v3.1 in anything but non normative is = not going=20 fly (nor would it be reasonable if it happens to be exactly the = same as=20 v3.2). The time of making it to rfc of a v3.1 has very little = to do=20 with it, since the latest draft of the protocol spec is to our = knowledge=20 100% compatible with "pre-standard" implementation except for new=20 capabilities.
Anyway, before we go off documenting all that, = perhaps a=20 step back should be taken to evaluate the = situation:
- the currently deployed protocol, based on some set of = the=20 current drafts, has it's core functionality intact. I.e. = Given that=20 in all new activities we've strived for backwards compatibility, = with the=20 exception of historic tlv conflict, there doesn't seem to be much = of a=20 reason for v3.2
- the tlv conflict is inherent to a stage of ANCP = development and=20 a v3.2 or its claims of backward compatibility to v3.1 (with=20 conflicting tlv set) are not going to matter; = the affected tlvs=20 will still clash, irrespective of "backwards compatibility" of=20 versions.
- Capability negotiation as offered by ANCP by = itself provides=20 a way to distinguish new protocol functions. It's here that the WG = has=20 been spending most of its time, and it's recognised as the way in = which=20 the protocol will evolve (or via = sub-capabilities)
- An operator has requested that a line be drawn to = distinguish a=20 set of compatible pre-standard implementations (thus same=20 pre-standard versions)  that they are running and the actual = standard=20 which may be in their opinion incompatible, hence v3.1 = becomes to=20 v3.2. The same operator has not expressed a need to have an rfc = for=20 v3.1
- Migrating from v3.1 to v3.2 is an operational activity = for which=20 the protocol does not appear to require modification (this = appears to=20 be no different than transitioning from L2TPv2 to v3=20 say).
- The current protocol draft states that the version = SHOULD be 3.1=20 (which appears to need a correction)
 
Based on the above, it seems to me that if we go at a = stroke to a=20 v3.2 when the rfc gets published we could try to navigate by = having a=20 clause which states that pre-rfc  eg v3.1 *may* be compatible = and a=20 hint to reflect that version number to the sender but leaving = remaining behaviour un-specified (since there is no actual = guarantee of=20 compatibility). How does this sound?
 
Cheers,
Woj.

From: Peter Arberg=20 [mailto:parberg@redback.com]
Sent: 29 July 2009=20 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay = Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Hi Woj,
 
As I see it the problem is exactly that = we do not=20 have a normative reference in a RFC
simply because we have been too long to = put=20 anything together on the running code
which are deployed in live networks=20 today.
 
We have a L2CP reference in a TR = document and we=20 have live networks.
 
So if we decide to go for version 3.2 = in the ANCP=20 WG, it would be very beneficial to have
a chapter in the RFC which describe = migration from=20 pre-standard ANCP to the standard
RFC.
 
I'm sure carriers having pre-standard = ANCP running=20 in their network will like a clear RFC
statement for how we vendors should = handle a=20 incompatibility in a defacto ANCP standard
and the "real" ANCP RFC=20 standard.
 
So instead of a normative reference i = will suggest=20 that the RFC editor of the ANCP protocol
write a chapter and describe what is = expected when=20 a RFC standard ANCP ver. 3.2
implementation is getting adjancy = connection=20 request from a pre-standard ver. 3.1 ANCP
endpoint.
 
Too me this seems like a much too = important=20 question to simply ignore in a new protocol = which
have been in the development for more = than 3 years,=20 and have had live networks = in multi-vendor
deployments for a long = time.
 
thanks,
Peter

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech = Dec=20 (wdec)
Sent: 29. juli 2009 12:22
To: Alan=20 Kavanagh; Sanjay Wadhwa; ancp@ietf.org
Subject: Re: = [ANCP]=20 ANCP Protocol Versioning

Your post bears no useful or = constructive input=20 regarding the topic. Attempting to define backwards = compatibility=20 means drawing on a normative reference to = non-standard=20 drafts and is not reasonable (a reading of http://tools.ietf.org/html/rf= c4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as to = where=20 ANCP version 3.1 is defined and can be normatively referenced = in a=20 v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, = except for new=20 capabilities, then there is hardly a reason for a version = change. The=20 only way to have a reference to v3.1 in an rfc re v3.2 is = either as a=20 historic note, without claims of backwards compatibility, or = publish=20 two rfcs (a v3.1 and then a v3.2). Neither of these proposals = seem to=20 be appealing.
 
In addition, you may also want to = reflect on=20 the quality of your conclusions and comprehension of general=20 facts...
 
-Woj.
 
From: Alan Kavanagh=20 [mailto:alan.kavanagh@ericsson.com]
Sent: 29 July = 2009=20 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

So what are you = sugegsting will=20 happen with current deployments....!!! Like it or not Woj, = fact is=20 it must be covered, if you dont agree then thats just your = single=20 opinion here.
 
By the time you agree = on everything=20 we will be onto ANCP Version 4.10 !!! We are spending far = too long=20 on getting this draft out the door.

From: Wojciech Dec = (wdec)=20 [mailto:wdec@cisco.com]
Sent: July 29, 2009 10:01 = AM
To: Alan Kavanagh; Sanjay Wadhwa;=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

Sorry, but reference in a future ANCP = v3.2 RFC to=20 a version 3.1 which is NOT defined anywhere (in any = normative=20 reference or RFC) does not seem to be=20 acceptable.
The (minuted) discussion did not cover = the notion=20 of how ANCP "version incompatibility" will be handled. Given = that=20 we're not out in the WG to create version compatibility = between=20 an ANCP standard protocol and an ANCP non-standard = based one=20 (or GSMP for that matter), it would seem that no new = definition=20 needs to take place. Feel free to discuss this further on = this=20 thread...
 
-Woj.

From: = ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of Alan=20 Kavanagh
Sent: 29 July 2009 15:51
To: = Sanjay=20 Wadhwa; Wojciech Dec (wdec); = ancp@ietf.org
Subject: Re:=20 [ANCP] ANCP Protocol Versioning

Exactly, hence we = should ahve this=20 explicitly noted in the draft.
 
Alan

From: Sanjay Wadhwa=20 [mailto:swadhwa@juniper.net]
Sent: July 29, = 2009 9:48=20 AM
To: Alan Kavanagh; Wojciech Dec (wdec);=20 ancp@ietf.org
Subject: RE: [ANCP] ANCP Protocol=20 Versioning

In order=20 to ease migration, it will help if BNGs are able to handle = multiple peers with different versions (e.g. a 3.2 = compliant BNG=20 implementation able to work with a 3.1 AN and a 3.2 AN). = Although=20 implied by the protocol, we may want to explicitly state = that=20 version compatibility requirement is on an adjacency=20 basis.

The draft=20 will also need to define how the version incompatibility = between=20 BNG and AN needs to be = handled.

 

-Sanjay

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of Alan=20 Kavanagh
Sent:=20 Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec = (wdec);=20 ancp@ietf.org
Subject: Re: [ANCP] = ANCP=20 Protocol Versioning

 

Cheers=20 Woj

 

The only=20 point i would note (excuse if it was already raised on = Monday as i=20 did not attend) is "backward compatibility" between the = different=20 versions of 3.1, 3.2 and future versions if/when/as = needed. this=20 should be noted in the draft.

 

Alan

 

From: Wojciech = Dec (wdec)=20 [mailto:wdec@cisco.com] =
Sent: July 29, 2009 = 3:33=20 AM
To: = Alan=20 Kavanagh; ancp@ietf.org
Subject: RE: [ANCP] = ANCP=20 Protocol Versioning

Not = entirely. ANCP=20 already has a versioning field, hence nothing new is being = defined. Also strictly speaking there is no = distinction=20 between version and sub-version, so the choice of 3.2 = is=20 purely based on custom (it can equally well have been=20 4.0).

Of course = this will=20 mean that all "pre-rfc" implementations will automatically = be 100%=20 incompatible with the rfc.

 

-Woj.

 

From: Alan = Kavanagh=20 [mailto:alan.kavanagh@ericsson.com] =
Sent: 28 July=20 2009 19:28
To:=20 Wojciech Dec (wdec); ancp@ietf.org
Subject: RE: = [ANCP] ANCP=20 Protocol Versioning

Hi Woj=20 et.al

 

So are=20 we agreeing that option 1 as noted on slide 15 in the = Thomas's=20 presentation is what was agreed on at yesterdays=20 meeting?

 

BR

Alan=20 K

 

From:=20 ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = On Behalf Of = Wojciech Dec=20 (wdec)
Sent:=20 July 28, 2009 5:30 AM
To: = ancp@ietf.org
Subject: [ANCP] = ANCP=20 Protocol Versioning

Hi=20 All, =

During = yesterday's=20 ANCP WG meeting at IET75 we discussed the topic of ANCP=20 versioning and in the room arrived at the following=20 conclusion:

The = Pre-RFC version=20 of ANC will continue to be 3.1 as per = draft-ietf-ancp-protocol,=20 however an RFC Editor's note will be introduced to = change=20 version from 3.1 to 3.2 upon publication of the RFC. = This will=20 clearly de-lineate any pre-RFC implementations with = post-RFC=20 ones and alleviate the operators'' problems presented=20 (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going = beyond the=20 publication of the RFC, the introduction of new = capabilities or=20 TLVs is expected to be handled by the capability = negotiation=20 mechanism (and new capabilities) or possibly by = generalizing the=20 notion of sub-capability currently in place for the=20 multicast-control = use-cases.

We would = like to get=20 feedback from the wider WG on the above, especially in = terms of=20 anyone who was not able to voice their opinion at the = meeting.=20 Based on the received feedback, we'll make a call = regarding the=20 WG consensus on this = matter.

Regards,=20
Woj.=20 =

= ------_=_NextPart_001_01CA271E.B92E8EE4-- From tom.taylor@rogers.com Thu Aug 27 12:21:26 2009 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 EB27628C1AD for ; Thu, 27 Aug 2009 12:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] 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 QS7mZ19cQxNC for ; Thu, 27 Aug 2009 12:21:26 -0700 (PDT) Received: from smtp125.rog.mail.re2.yahoo.com (smtp125.rog.mail.re2.yahoo.com [206.190.53.30]) by core3.amsl.com (Postfix) with SMTP id CD70728C17B for ; Thu, 27 Aug 2009 12:21:25 -0700 (PDT) Received: (qmail 38766 invoked from network); 27 Aug 2009 19:21:29 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=q4EPUIWqGcn6R4XJwLjscRq4WEWxg9b0o53SueTwnJMGV99BYUCPjP2/r30ZXFxjtfIbmTL+D/E2SJy2hEwF16V3ry+0h1GRQwgYJeDbcXZKE2hZktz9VduP7PcPaM/QZfYCOIgdIJNLoY+4e1SXB/wVioewZaPdaEs7+nR4ZD0= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp125.rog.mail.re2.yahoo.com with SMTP; 27 Aug 2009 19:21:29 -0000 X-YMail-OSG: IAalptQVM1nQV9t3FHLKqLGDEGzsdV_kLixxvhxskoFKTV1IJggDCqUPntxVsQJpBw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A96DCB7.7060303@rogers.com> Date: Thu, 27 Aug 2009 15:21:27 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: HaagT@telekom.de References: <48C276B536524E478C659685995F6AA5C8BFE27FD6@RBSJX.ad.redback.com><040201ca1987$008a6670$5728460a@china.huawei.com><1789B35CAAE7B948997F51DE0D963B92011F0283@S4DE8PSAAQC.mitte.t-com.de><35815C929B41D2479A224FE098A2722707A2C493@ecamlmw720.eamcs.ericsson.se> <786AD2EC3D80A1428B921CDC9BE9EE54012ABBE448@USPITMAIL01.ecitele.com> <5661758E3E93364685B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <5661758E3E93364685B91DD8272F287601B8E2D3@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: B.Witschurke@telekom.de, ancp@ietf.org, peter.arberg@ericsson.com, Robert.Rennison@ecitele.com, Peter.Hamacher@telekom.de Subject: Re: [ANCP] ANCP Protocol Versioning 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: Thu, 27 Aug 2009 19:21:27 -0000 Comments below, marked with [PTT]. HaagT@telekom.de wrote: > All, > > All exchanged arguments are valid. > > I think a protocol draft describes protocol issues, values, TLV, etc. and not > network element mechanisms. The challenge now would be to cover notes > pointing out how to code pre version and RFC version - that was agreed last > meeting. > > But what's missing in that game is a short description that both peers (BRAS > & AN) need to identify which SW version to choose based on sub version value. > A mechnism in detail for detection and automatic SW load depending on sub > version is neccessary. > > I'm not sure if that is in scope of a protocol draft or if it should be > described seperately. But keeping the time line of protocol draft and > avoiding delaying ANCP work it may be desirable to identify sections in > protocol draft where notes are useful to detail that issue without changing > sections and order of the document. > >> From my understanding three sections are concerned. I propose adding the >> notes at that sections. > > Please see below the identified sections and added notes taken based on > protocol draft 05 for discussion: > > Regards Thomas > --------------------------------------------------------------------------------- > > > Chapter 2 Introduction / page 4: > > ... > > Not all the fields in relevant GSMP messages are used by ANCP. This draft > indicates the value that ANCP should set for the fields in these GSMP > messages. > > > > [T.H.:] Note: Implementations which use GSMP and ANCP conventions before RFC > publication must use sub-version 1. [PTT] By definition, pre-standard versions do not conform to the standard, so this text will have no effect. > > RFC based implementations must use sub-version 2. For details see chapter 5. > > ... > > ------------------------------------------------------------------------------------ > > > Chapter 5. Access Node Control Protocol (ANCP) / page 15 > > ... > > The 8-bit version field in the base GSMPv3 message header is split > into two 4 bit fields for carrying the version and a sub-version of > the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP > protocol. An ANCP implementation SHOULD always set the version field > to 3, and the sub-version field to 1. The Result field in the > message header has been modified to be 4 bits long, and the Code > field to be 12 bits long. > > Version: > > The version number of the GSMP protocol being used in this > session. ANCP uses version 3. > > Sub-Version: > > The sub-version number of the GSMP protocol being used in this > session. ANCP must use sub-version 2 of the GSMP protocol. [T.H]:Pre RFC > implemtations must use sub-version 1. > [PTT] Same comment as above. > > --------------------------------------------------------------------- > > Chapter 5.1. ANCP/TCP connection establishment / Page 19: > > ... > > NAS listens for incoming connections from the access nodes. Port 6068 is > used for TCP connection. Adjacency protocol messages, which are used to > synchronize the NAS and access-nodes and maintain handshakes, are sent after > the TCP connection is established. ANCP messages other than adjacency > protocol messages may be sent only after the adjacency protocol has achieved > synchronization. > > [T.H.]:Note: NAS must detect per peer the sub version and must load and > synchronize with appropriate protocol implementation. > [PTT] I would add "if possible". > ... From tom.taylor@rogers.com Thu Aug 27 19:39:10 2009 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 C1E653A6858 for ; Thu, 27 Aug 2009 19:39:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599] 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 rS2bVYik7+pu for ; Thu, 27 Aug 2009 19:39:10 -0700 (PDT) Received: from smtp127.rog.mail.re2.yahoo.com (smtp127.rog.mail.re2.yahoo.com [206.190.53.32]) by core3.amsl.com (Postfix) with SMTP id AC7843A6B09 for ; Thu, 27 Aug 2009 19:39:09 -0700 (PDT) Received: (qmail 72719 invoked from network); 28 Aug 2009 02:39:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=txNjSG+b2sTqr8qfGFoo/CbAeYE5LkOXmkxZvw3Hh7sFWDldmwZDHHwiPsOm8p7+kBwZ+jV4cJGXMY14wFyI+TCKiVL1Zn6oNdckB+ppSCgrfoDS5Gk5smeuc1paoDuv4aLstqn5xsdK6X/02vDlNcekVYmXJvxQizuljobbSTQ= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp127.rog.mail.re2.yahoo.com with SMTP; 28 Aug 2009 02:39:14 -0000 X-YMail-OSG: olvYOW0VM1naZtDeN0pQm2kGpb2J4cljggYxajKbpJV_N7dPbSc4wnyU_ufVubfCCA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A97434F.9020704@rogers.com> Date: Thu, 27 Aug 2009 22:39:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] Proposal for replacement of "Multicast Status" message, Part 2 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: Fri, 28 Aug 2009 02:39:10 -0000 This message describes the changes required in draft-ietf-ancp-mc-extensions-00.txt if the Multicast Status message is replaced by the base protocol Generic Response message I described in my previous note. The actual text changes required are too extensive to put into an E-mail. This is an outline, which I will implement in detailed text in my role as co-author if the list agrees in principle. 1. Global change ================ Change "Multicast Status" to "Generic Response". Watch out for the figures, where the message appears as "Multicast-Status". 2. Section 4.1 Provisioning Message =================================== An editor's note calls for error responses to the Provisioning message to be added to base. I would suggest that the general Code value: 84 Unsupported TLV type be added to the others I proposed in my previous E-mail, and this would be used for the error cases described in the editor's note. We could also define a sub-TLV to Status-info in base that provides the TLV identifier, if we think the NAS could use that information to modify its message. Base can then define a generic failure response to the Provisioning message (if we think this won't overload the NAS). 3. Section 4.3. Multicast Replication Control Message ====================================================== Editorial note: some parts of this section should be reordered to provide a clean separation between sender behaviour and receiver behaviour. The existing text says that a Multicast Status message MUST be sent "when a response is needed". I assume the text should really read that the receiver MUST send a Generic Response message with the appropriate contents if unable to execute the complete Multicast Replication Control message successfully. If I am correct, the Result field of the Multicast Replication Control message should be set to Nack rather than Ignore. The specific error conditions described in the current text are: *** unrecognized target TLV -- Covered by existing code value 4, "One or more of the specified ports does not exist." (Note that this is the explanatory text that is shown in the IANA registry, and differs from the current text of the MC extensions document.) *** command error -- Needs a new Code value, so add 85 Command error to base, and define in base a sub-TLV of Status-info to carry the sequence number of the command within the message. This sub-TLV could also carry an additional diagnostic code with its own IANA registry if people think it might be useful. Extensions would define the actual code values and add them to the registry. Likely candidates are some of the errors listed in section 4.4: - Command not supported - Flag set but not supported - M Flag set, but no IP Source address provided - Unsupported Address Family - Unsupported address encoding - Malformed flow address - Multicast flow does not exist *** command flag error -- The NAS isn't going to debug flag values in real time, but this would be a candidate for an additional diagnostic code value to help the operating staff who will be reviewing the NAS's log of errors. See above. 4. Section 4.4 Multicast Status Message ======================================= Delete this section. 5. Section 4.5. Multicast Admission Control Message ==================================================== Replace the text at the end talking about the content of the Multicast Status message with a statement that the content of the Generic Response message follows the rules described in section 4.3 failures of the Multicast Replication Control message. I think I'll leave further changes to other notes, dealing primarily with other issues. Tom Taylor