From ancp-bounces@ietf.org Fri Jan 2 08:56:33 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E94E3A6825; Fri, 2 Jan 2009 08:56:33 -0800 (PST) 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 0C1F03A6825 for ; Fri, 2 Jan 2009 08:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.093 X-Spam-Level: X-Spam-Status: No, score=-3.093 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156] 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 FkLqMGD9N2+V for ; Fri, 2 Jan 2009 08:56:31 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id C057E3A67D6 for ; Fri, 2 Jan 2009 08:56:29 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 02 Jan 2009 17:56:14 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jan 2009 17:56:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Jan 2009 17:56:03 +0100 Message-ID: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Partition ID thread-index: AclhxzHPRVPuEywfSU2ks5axwepmUwJYgWhgAHNmzyA= References: From: To: , X-OriginalArrivalTime: 02 Jan 2009 16:56:14.0239 (UTC) FILETIME=[058B82F0:01C96CFB] Subject: Re: [ANCP] Partition ID 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Using partitioning is not a real use case but an operational extension in o= peration ANCP with multiple AN and BRAS devices. In practice a single edge = network does not consist of a single BRAS. Furthermore a single BRAS locati= on may have multiple BRAS devices. I like to point out the operational back= ground and the partitioning ID negotiation. Operational background: >From an nework developing point of view a BRAS may be fully loaded by conti= nuous increasing number of configured DSL ports. From traffic engineering p= oint of view the BRAS can not handle additional new ports. In order not to = reconfigure the whole network the AN opens a new partition and the next BRA= S device (same location!) terminates this new partition coming from the sam= e AN taking the new traffic. Partition ID negotiation: 3rd of November 2008 on the mailing list the use of partiton ID was discuss= ed too. The reason was the missmatch of an partiton ID if a BRAS receives a= message with a partition ID the BRAS have not known before. In order not t= o tear down the connection the BRAS should learn this partiton ID. This option was agreed to be described in the protocol draft. = So I think the reason for using of the partiton ID field is described indep= endent on a particular use case because this feature is a fundamental opera= tional configuration which is used by already defined use cases and has no = need to be a use case itself. Also backward compatibility is an issue here = to be studied carefully because of the the impact on using partition ID fil= ed for new functionality. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wo= jciech Dec (wdec) Gesendet: Mittwoch, 31. Dezember 2008 10:31 An: Shridhar Rao (shrirao); ancp@ietf.org Betreff: Re: [ANCP] Partition ID You raise a very good point. The partition "concept" is/was derived from GSMP where presumably a single controller could be managing multiple partitions on a single client. In the current set of ANCP use-cases this does not seem to be required and the partition-id field may be yet another field that could be marked as "obsolete" or simply ignored by the NAS. Could anyone in the WG indicate whether they see a case where a single NAS would be handling multiple partitioned ANCP sessions from a single AN, and what would that case be? Thanks, Woj. > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = > Behalf Of Shridhar Rao (shrirao) > Sent: 19 December 2008 11:48 > To: ancp@ietf.org > Subject: [ANCP] Partition ID > = > Hello, > We like to understand the real use for Partition ID in case = > of NAS. If AN wants to use Partition ID for dividing itself = > into multiple logical partitions with each controlling = > certain access ports on it, it can be done by some local = > configuration on AN. Is there a real need for NAS to be aware of it? = > = > If Partition ID field has no use in NAS, it can be reused = > instead as first byte of a 4 byte Transaction Id field (Tr ID = > is now a 3 byte quantity starting at a odd byte location), = > and NAS need not worry about partition ID at all eliminating = > the need for exchange of adjacency messages for convergence = > of Partition ID. > = > Thanks, > Shridhara rao > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > = _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Fri Jan 2 19:20:52 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61FE73A6810; Fri, 2 Jan 2009 19:20:52 -0800 (PST) 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 731793A6810 for ; Fri, 2 Jan 2009 19:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.007 X-Spam-Level: X-Spam-Status: No, score=0.007 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, SUBJECT_FUZZY_TION=0.156] 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 Zgb3CCbqcpKu for ; Fri, 2 Jan 2009 19:20:49 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6D4D53A67D8 for ; Fri, 2 Jan 2009 19:20:49 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KCV00JOWLABUX@szxga04-in.huawei.com> for ancp@ietf.org; Sat, 03 Jan 2009 11:20:35 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KCV003ZFLAB0F@szxga04-in.huawei.com> for ancp@ietf.org; Sat, 03 Jan 2009 11:20:35 +0800 (CST) Received: from [192.168.1.12] (183.39.17.218.broad.sz.gd.dynamic.163data.com.cn [218.17.39.183]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KCV00491LABNG@szxml01-in.huawei.com>; Sat, 03 Jan 2009 11:20:35 +0800 (CST) Date: Sat, 03 Jan 2009 11:20:34 +0800 From: Tina Tsou In-reply-to: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> To: "HaagT@telekom.de" Message-id: MIME-version: 1.0 X-Mailer: iPod Mail (5G77a) References: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> Cc: "ancp@ietf.org" Subject: Re: [ANCP] Partition ID 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: , Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="gb2312"; Format="flowed"; DelSp="yes" Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org SXQgbWFrZXMgc2Vuc2UgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiBvcGVyYXRpb25hbCBjb25m aWd1cmF0aW8uICAKV2hlbiBkb2VzIE5BUyBnZXQgdGhpcyBwYXJ0aXRpb24gSUQgZnJvbSBBTj8K ClRpbmEKCrei19TO0rXEIGlQb2QKCtTaIDIwMDktMS0zo6wwOjU2o6xIYWFnVEB0ZWxla29tLmRl INC0tb2jugoKPiBVc2luZyBwYXJ0aXRpb25pbmcgaXMgbm90IGEgcmVhbCB1c2UgY2FzZSBidXQg YW4gb3BlcmF0aW9uYWwgIAo+IGV4dGVuc2lvbiBpbiBvcGVyYXRpb24gQU5DUCB3aXRoIG11bHRp cGxlIEFOIGFuZCBCUkFTIGRldmljZXMuIEluICAKPiBwcmFjdGljZSBhIHNpbmdsZSBlZGdlIG5l dHdvcmsgZG9lcyBub3QgY29uc2lzdCBvZiBhIHNpbmdsZSBCUkFTLiAgCj4gRnVydGhlcm1vcmUg YSBzaW5nbGUgQlJBUyBsb2NhdGlvbiBtYXkgaGF2ZSBtdWx0aXBsZSBCUkFTIGRldmljZXMuIEkg IAo+IGxpa2UgdG8gcG9pbnQgb3V0IHRoZSBvcGVyYXRpb25hbCBiYWNrZ3JvdW5kIGFuZCB0aGUg cGFydGl0aW9uaW5nIElEICAKPiBuZWdvdGlhdGlvbi4KPgo+IE9wZXJhdGlvbmFsIGJhY2tncm91 bmQ6Cj4gRnJvbSBhbiBuZXdvcmsgZGV2ZWxvcGluZyBwb2ludCBvZiB2aWV3IGEgQlJBUyBtYXkg YmUgZnVsbHkgbG9hZGVkICAKPiBieSBjb250aW51b3VzIGluY3JlYXNpbmcgbnVtYmVyIG9mIGNv bmZpZ3VyZWQgRFNMIHBvcnRzLiBGcm9tICAKPiB0cmFmZmljIGVuZ2luZWVyaW5nIHBvaW50IG9m IHZpZXcgdGhlIEJSQVMgY2FuIG5vdCBoYW5kbGUgYWRkaXRpb25hbCAgCj4gbmV3IHBvcnRzLiBJ biBvcmRlciBub3QgdG8gcmVjb25maWd1cmUgdGhlIHdob2xlIG5ldHdvcmsgdGhlIEFOICAKPiBv cGVucyBhIG5ldyBwYXJ0aXRpb24gYW5kIHRoZSBuZXh0IEJSQVMgZGV2aWNlIChzYW1lIGxvY2F0 aW9uISkgIAo+IHRlcm1pbmF0ZXMgdGhpcyBuZXcgcGFydGl0aW9uIGNvbWluZyBmcm9tIHRoZSBz YW1lIEFOIHRha2luZyB0aGUgbmV3ICAKPiB0cmFmZmljLgo+Cj4gUGFydGl0aW9uIElEIG5lZ290 aWF0aW9uOgo+IDNyZCBvZiBOb3ZlbWJlciAyMDA4IG9uIHRoZSBtYWlsaW5nIGxpc3QgdGhlIHVz ZSBvZiBwYXJ0aXRvbiBJRCB3YXMgIAo+IGRpc2N1c3NlZCB0b28uIFRoZSByZWFzb24gd2FzIHRo ZSBtaXNzbWF0Y2ggb2YgYW4gcGFydGl0b24gSUQgaWYgYSAgCj4gQlJBUyByZWNlaXZlcyBhIG1l c3NhZ2Ugd2l0aCBhIHBhcnRpdGlvbiBJRCB0aGUgQlJBUyBoYXZlIG5vdCBrbm93biAgCj4gYmVm b3JlLiBJbiBvcmRlciBub3QgdG8gdGVhciBkb3duIHRoZSBjb25uZWN0aW9uIHRoZSBCUkFTIHNo b3VsZCAgCj4gbGVhcm4gdGhpcyBwYXJ0aXRvbiBJRC4KPiBUaGlzIG9wdGlvbiB3YXMgYWdyZWVk IHRvIGJlIGRlc2NyaWJlZCBpbiB0aGUgcHJvdG9jb2wgZHJhZnQuCj4KPiBTbyBJIHRoaW5rIHRo ZSByZWFzb24gZm9yIHVzaW5nIG9mIHRoZSBwYXJ0aXRvbiBJRCBmaWVsZCBpcyAgCj4gZGVzY3Jp YmVkIGluZGVwZW5kZW50IG9uIGEgcGFydGljdWxhciB1c2UgY2FzZSBiZWNhdXNlIHRoaXMgZmVh dHVyZSAgCj4gaXMgYSBmdW5kYW1lbnRhbCBvcGVyYXRpb25hbCBjb25maWd1cmF0aW9uIHdoaWNo IGlzIHVzZWQgYnkgYWxyZWFkeSAgCj4gZGVmaW5lZCB1c2UgY2FzZXMgYW5kIGhhcyBubyBuZWVk IHRvIGJlIGEgdXNlIGNhc2UgaXRzZWxmLiBBbHNvICAKPiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IGlzIGFuIGlzc3VlIGhlcmUgdG8gYmUgc3R1ZGllZCBjYXJlZnVsbHkgIAo+IGJlY2F1c2Ugb2Yg dGhlIHRoZSBpbXBhY3Qgb24gdXNpbmcgcGFydGl0aW9uIElEIGZpbGVkIGZvciBuZXcgIAo+IGZ1 bmN0aW9uYWxpdHkuCj4KPiBSZWdhcmRzCj4gVGhvbWFzCj4KPiAtLS0tLVVyc3ByqLluZ2xpY2hl IE5hY2hyaWNodC0tLS0tCj4gVm9uOiBhbmNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphbmNw LWJvdW5jZXNAaWV0Zi5vcmddIEltIEF1ZnRyYWcgIAo+IHZvbiBXb2pjaWVjaCBEZWMgKHdkZWMp Cj4gR2VzZW5kZXQ6IE1pdHR3b2NoLCAzMS4gRGV6ZW1iZXIgMjAwOCAxMDozMQo+IEFuOiBTaHJp ZGhhciBSYW8gKHNocmlyYW8pOyBhbmNwQGlldGYub3JnCj4gQmV0cmVmZjogUmU6IFtBTkNQXSBQ YXJ0aXRpb24gSUQKPgo+IFlvdSByYWlzZSBhIHZlcnkgZ29vZCBwb2ludC4gVGhlIHBhcnRpdGlv biAiY29uY2VwdCIgaXMvd2FzIGRlcml2ZWQgIAo+IGZyb20KPiBHU01QIHdoZXJlIHByZXN1bWFi bHkgYSBzaW5nbGUgY29udHJvbGxlciBjb3VsZCBiZSBtYW5hZ2luZyBtdWx0aXBsZQo+IHBhcnRp dGlvbnMgb24gYSBzaW5nbGUgY2xpZW50LiBJbiB0aGUgY3VycmVudCBzZXQgb2YgQU5DUCB1c2Ut Y2FzZXMgIAo+IHRoaXMKPiBkb2VzIG5vdCBzZWVtIHRvIGJlIHJlcXVpcmVkIGFuZCB0aGUgcGFy dGl0aW9uLWlkIGZpZWxkIG1heSBiZSB5ZXQKPiBhbm90aGVyIGZpZWxkIHRoYXQgY291bGQgYmUg bWFya2VkIGFzICJvYnNvbGV0ZSIgb3Igc2ltcGx5IGlnbm9yZWQgYnkKPiB0aGUgTkFTLiBDb3Vs ZCBhbnlvbmUgaW4gdGhlIFdHIGluZGljYXRlIHdoZXRoZXIgdGhleSBzZWUgYSBjYXNlICAKPiB3 aGVyZSBhCj4gc2luZ2xlIE5BUyB3b3VsZCBiZSBoYW5kbGluZyBtdWx0aXBsZSBwYXJ0aXRpb25l ZCBBTkNQIHNlc3Npb25zIGZyb20gYQo+IHNpbmdsZSBBTiwgYW5kIHdoYXQgd291bGQgdGhhdCBj YXNlIGJlPwo+Cj4gVGhhbmtzLAo+IFdvai4KPgo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQo+PiBGcm9tOiBhbmNwLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphbmNwLWJvdW5jZXNAaWV0 Zi5vcmddIE9uCj4+IEJlaGFsZiBPZiBTaHJpZGhhciBSYW8gKHNocmlyYW8pCj4+IFNlbnQ6IDE5 IERlY2VtYmVyIDIwMDggMTE6NDgKPj4gVG86IGFuY3BAaWV0Zi5vcmcKPj4gU3ViamVjdDogW0FO Q1BdIFBhcnRpdGlvbiBJRAo+Pgo+PiBIZWxsbywKPj4gV2UgbGlrZSB0byB1bmRlcnN0YW5kIHRo ZSByZWFsIHVzZSBmb3IgUGFydGl0aW9uIElEIGluIGNhc2UKPj4gb2YgTkFTLiBJZiBBTiB3YW50 cyB0byB1c2UgUGFydGl0aW9uIElEIGZvciBkaXZpZGluZyBpdHNlbGYKPj4gaW50byBtdWx0aXBs ZSBsb2dpY2FsIHBhcnRpdGlvbnMgd2l0aCBlYWNoIGNvbnRyb2xsaW5nCj4+IGNlcnRhaW4gYWNj ZXNzIHBvcnRzIG9uIGl0LCBpdCBjYW4gYmUgZG9uZSBieSBzb21lIGxvY2FsCj4+IGNvbmZpZ3Vy YXRpb24gb24gQU4uIElzIHRoZXJlIGEgcmVhbCBuZWVkIGZvciBOQVMgdG8gYmUgYXdhcmUgb2Yg aXQ/Cj4+Cj4+IElmIFBhcnRpdGlvbiBJRCBmaWVsZCBoYXMgbm8gdXNlIGluIE5BUywgaXQgY2Fu IGJlIHJldXNlZAo+PiBpbnN0ZWFkIGFzIGZpcnN0IGJ5dGUgb2YgYSA0IGJ5dGUgVHJhbnNhY3Rp b24gSWQgZmllbGQgKFRyIElECj4+IGlzIG5vdyBhIDMgYnl0ZSBxdWFudGl0eSBzdGFydGluZyBh dCBhIG9kZCBieXRlIGxvY2F0aW9uKSwKPj4gYW5kIE5BUyBuZWVkIG5vdCB3b3JyeSBhYm91dCBw YXJ0aXRpb24gSUQgYXQgYWxsIGVsaW1pbmF0aW5nCj4+IHRoZSBuZWVkIGZvciBleGNoYW5nZSBv ZiBhZGphY2VuY3kgbWVzc2FnZXMgZm9yIGNvbnZlcmdlbmNlCj4+IG9mIFBhcnRpdGlvbiBJRC4K Pj4KPj4gVGhhbmtzLAo+PiBTaHJpZGhhcmEgcmFvCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCj4+IEFOQ1AgbWFpbGluZyBsaXN0Cj4+IEFOQ1BAaWV0 Zi5vcmcKPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hbmNwCj4+Cj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBBTkNQIG1h aWxpbmcgbGlzdAo+IEFOQ1BAaWV0Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FuY3AKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXwo+IEFOQ1AgbWFpbGluZyBsaXN0Cj4gQU5DUEBpZXRmLm9yZwo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcApfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpBTkNQIG1haWxpbmcgbGlzdApBTkNQQGlldGYub3JnCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYW5jcAo= From ancp-bounces@ietf.org Sat Jan 3 00:34:22 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281A43A68B8; Sat, 3 Jan 2009 00:34:22 -0800 (PST) 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 4529A3A68B8 for ; Sat, 3 Jan 2009 00:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.482 X-Spam-Level: X-Spam-Status: No, score=-10.482 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] 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 uVSG-QRNwmLR for ; Sat, 3 Jan 2009 00:34:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 57E5F3A677D for ; Sat, 3 Jan 2009 00:34:19 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,322,1228089600"; d="scan'208";a="29961855" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Jan 2009 08:34:05 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n038Y5Yj017083; Sat, 3 Jan 2009 09:34:05 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n038Y5Px007535; Sat, 3 Jan 2009 08:34:05 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Jan 2009 09:34:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 3 Jan 2009 09:33:56 +0100 Message-ID: In-Reply-To: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Partition ID Thread-Index: AclhxzHPRVPuEywfSU2ks5axwepmUwJYgWhgAHNmzyAAIWpP8A== References: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: , X-OriginalArrivalTime: 03 Jan 2009 08:34:05.0714 (UTC) FILETIME=[09F52F20:01C96D7E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4781; t=1230971645; x=1231835645; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Partition=20ID |Sender:=20; bh=JyJzcuD4aJXYJ2H3qoBMT72HL9Nl2FLG82zrA9qcupM=; b=G+VuAGT0cWLen9cwZqsBcArO/bXYcRXxsw6A4LlID83mghR5wWNKq8LTbS rT5p+K8RBV07dXivkRjFPqemV8ewrnqsgDSnFO9GUPj1IxLsMgObgDBTHflH BiuMJuD4Ri; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] Partition ID 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org = > -----Original Message----- > From: HaagT@telekom.de [mailto:HaagT@telekom.de] = > Sent: 02 January 2009 17:56 > To: ancp@ietf.org; Wojciech Dec (wdec) > Cc: Shridhar Rao (shrirao) > Subject: AW: [ANCP] Partition ID > = > Using partitioning is not a real use case but an operational = > extension in operation ANCP with multiple AN and BRAS = > devices. In practice a single edge network does not consist = > of a single BRAS. Furthermore a single BRAS location may have = > multiple BRAS devices. I like to point out the operational = > background and the partitioning ID negotiation. > = > Operational background: > From an nework developing point of view a BRAS may be fully = > loaded by continuous increasing number of configured DSL = > ports. From traffic engineering point of view the BRAS can = > not handle additional new ports. In order not to reconfigure = > the whole network the AN opens a new partition and the next = > BRAS device (same location!) terminates this new partition = > coming from the same AN taking the new traffic. You seem to be describing the case of *one* AN having two or more partition= s each associated with a *different* BRAS/NAS ANCP controller through an AN= CP adjacency. Is there any use for *one* such an AN with the same type of m= ulti partition and multi-ANCP adjacency relationship with *a single* logica= l BRAS/NAS ANCP controller? What would that case be? > = > Partition ID negotiation: > 3rd of November 2008 on the mailing list the use of partiton = > ID was discussed too. The reason was the missmatch of an = > partiton ID if a BRAS receives a message with a partition ID = > the BRAS have not known before. In order not to tear down the = > connection the BRAS should learn this partiton ID. > This option was agreed to be described in the protocol draft. = As Shridhar indicated, the partition id appears to be of no consequence to = the ANCP controller except if it is expected to handle multiple ANCP adjace= ncies from one AN. = Regards, Woj. > = > So I think the reason for using of the partiton ID field is = > described independent on a particular use case because this = > feature is a fundamental operational configuration which is = > used by already defined use cases and has no need to be a use = > case itself. Also backward compatibility is an issue here to = > be studied carefully because of the the impact on using = > partition ID filed for new functionality. > = > Regards > Thomas > = > -----Urspr=FCngliche Nachricht----- > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = > Auftrag von Wojciech Dec (wdec) > Gesendet: Mittwoch, 31. Dezember 2008 10:31 > An: Shridhar Rao (shrirao); ancp@ietf.org > Betreff: Re: [ANCP] Partition ID > = > You raise a very good point. The partition "concept" is/was = > derived from GSMP where presumably a single controller could = > be managing multiple partitions on a single client. In the = > current set of ANCP use-cases this does not seem to be = > required and the partition-id field may be yet another field = > that could be marked as "obsolete" or simply ignored by the = > NAS. Could anyone in the WG indicate whether they see a case = > where a single NAS would be handling multiple partitioned = > ANCP sessions from a single AN, and what would that case be? > = > Thanks, > Woj. > = > > -----Original Message----- > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = > On Behalf = > > Of Shridhar Rao (shrirao) > > Sent: 19 December 2008 11:48 > > To: ancp@ietf.org > > Subject: [ANCP] Partition ID > > = > > Hello, > > We like to understand the real use for Partition ID in case = > of NAS. If = > > AN wants to use Partition ID for dividing itself into = > multiple logical = > > partitions with each controlling certain access ports on = > it, it can be = > > done by some local configuration on AN. Is there a real = > need for NAS = > > to be aware of it? > > = > > If Partition ID field has no use in NAS, it can be reused = > instead as = > > first byte of a 4 byte Transaction Id field (Tr ID is now a 3 byte = > > quantity starting at a odd byte location), and NAS need not worry = > > about partition ID at all eliminating the need for exchange of = > > adjacency messages for convergence of Partition ID. > > = > > Thanks, > > Shridhara rao > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www.ietf.org/mailman/listinfo/ancp > > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > = _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sat Jan 3 22:04:42 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A433A690B; Sat, 3 Jan 2009 22:04:42 -0800 (PST) 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 D66A63A690B for ; Sat, 3 Jan 2009 22:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.443 X-Spam-Level: X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156] 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 q3mbYkmA0o15 for ; Sat, 3 Jan 2009 22:04:39 -0800 (PST) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6CCF03A63EB for ; Sat, 3 Jan 2009 22:04:36 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKSWBRW0OHlWw4ilV5fWfktrGg84unTHqk@postini.com; Sat, 03 Jan 2009 22:04:27 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.336.0; Sat, 3 Jan 2009 22:04:08 -0800 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Jan 2009 22:04:07 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Jan 2009 22:04:07 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Sun, 4 Jan 2009 01:04:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jan 2009 01:04:04 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C2818CC3A8E@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Partition ID Thread-Index: AclhxzHPRVPuEywfSU2ks5axwepmUwJYgWhgAHNmzyAAIWpP8AAq8AeA References: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> From: Sanjay Wadhwa To: "Wojciech Dec (wdec)" , , X-OriginalArrivalTime: 04 Jan 2009 06:04:06.0792 (UTC) FILETIME=[40986880:01C96E32] Subject: Re: [ANCP] Partition ID 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org If each partition on an AN is always controlled via a different NAS (or sam= e NAS but different peer IP address), then we can get away without NAS havi= ng to reflect the partition-ID in the ANCP messages, as partition-ID is imp= licit on the AN from peer IP address. A L3 or L2 wholesale service provided= on the NAS (say via L2TP based backhaul to retail ISP's router OR via virt= ual routing domains on the NAS per retail-ISP) might seem like a driver for= this on the surface...but then I don't believe these require partitioning = on AN in the first place, and therefore not relevant to the discussion. However, one can imagine a scenario where AN partitioning is based on a cri= terion other than the NAS (i.e. ANCP controller) controlling it. ....e.g. o= ne might want to partition AN based on the type of service being delivered = to the local-loop (e.g. business DSL line with VoIP service might be partit= ioned from HSI only DSL line). Both partitions might be controlled via the = same NAS, and the AN could have a single adjacency with the NAS for both pa= rtitions. The NAS can potentially put the DSL subscriber in a different VRF= for isolation (based on type of service). = If we don't want to rule out such a scenario, then it makes sense for NAS t= o reflect the partition-ID in the ANCP messages (and the NAS and AN need to= have a consistent mapping of DSL line to partition-ID). Regards -Sanjay -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Woj= ciech Dec (wdec) Sent: Saturday, January 03, 2009 3:34 AM To: HaagT@telekom.de; ancp@ietf.org Subject: Re: [ANCP] Partition ID = > -----Original Message----- > From: HaagT@telekom.de [mailto:HaagT@telekom.de] = > Sent: 02 January 2009 17:56 > To: ancp@ietf.org; Wojciech Dec (wdec) > Cc: Shridhar Rao (shrirao) > Subject: AW: [ANCP] Partition ID > = > Using partitioning is not a real use case but an operational = > extension in operation ANCP with multiple AN and BRAS = > devices. In practice a single edge network does not consist = > of a single BRAS. Furthermore a single BRAS location may have = > multiple BRAS devices. I like to point out the operational = > background and the partitioning ID negotiation. > = > Operational background: > From an nework developing point of view a BRAS may be fully = > loaded by continuous increasing number of configured DSL = > ports. From traffic engineering point of view the BRAS can = > not handle additional new ports. In order not to reconfigure = > the whole network the AN opens a new partition and the next = > BRAS device (same location!) terminates this new partition = > coming from the same AN taking the new traffic. You seem to be describing the case of *one* AN having two or more partition= s each associated with a *different* BRAS/NAS ANCP controller through an AN= CP adjacency. Is there any use for *one* such an AN with the same type of m= ulti partition and multi-ANCP adjacency relationship with *a single* logica= l BRAS/NAS ANCP controller? What would that case be? > = > Partition ID negotiation: > 3rd of November 2008 on the mailing list the use of partiton = > ID was discussed too. The reason was the missmatch of an = > partiton ID if a BRAS receives a message with a partition ID = > the BRAS have not known before. In order not to tear down the = > connection the BRAS should learn this partiton ID. > This option was agreed to be described in the protocol draft. = As Shridhar indicated, the partition id appears to be of no consequence to = the ANCP controller except if it is expected to handle multiple ANCP adjace= ncies from one AN. = Regards, Woj. > = > So I think the reason for using of the partiton ID field is = > described independent on a particular use case because this = > feature is a fundamental operational configuration which is = > used by already defined use cases and has no need to be a use = > case itself. Also backward compatibility is an issue here to = > be studied carefully because of the the impact on using = > partition ID filed for new functionality. > = > Regards > Thomas > = > -----Urspr=FCngliche Nachricht----- > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im = > Auftrag von Wojciech Dec (wdec) > Gesendet: Mittwoch, 31. Dezember 2008 10:31 > An: Shridhar Rao (shrirao); ancp@ietf.org > Betreff: Re: [ANCP] Partition ID > = > You raise a very good point. The partition "concept" is/was = > derived from GSMP where presumably a single controller could = > be managing multiple partitions on a single client. In the = > current set of ANCP use-cases this does not seem to be = > required and the partition-id field may be yet another field = > that could be marked as "obsolete" or simply ignored by the = > NAS. Could anyone in the WG indicate whether they see a case = > where a single NAS would be handling multiple partitioned = > ANCP sessions from a single AN, and what would that case be? > = > Thanks, > Woj. > = > > -----Original Message----- > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = > On Behalf = > > Of Shridhar Rao (shrirao) > > Sent: 19 December 2008 11:48 > > To: ancp@ietf.org > > Subject: [ANCP] Partition ID > > = > > Hello, > > We like to understand the real use for Partition ID in case = > of NAS. If = > > AN wants to use Partition ID for dividing itself into = > multiple logical = > > partitions with each controlling certain access ports on = > it, it can be = > > done by some local configuration on AN. Is there a real = > need for NAS = > > to be aware of it? > > = > > If Partition ID field has no use in NAS, it can be reused = > instead as = > > first byte of a 4 byte Transaction Id field (Tr ID is now a 3 byte = > > quantity starting at a odd byte location), and NAS need not worry = > > about partition ID at all eliminating the need for exchange of = > > adjacency messages for convergence of Partition ID. > > = > > Thanks, > > Shridhara rao > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www.ietf.org/mailman/listinfo/ancp > > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > = _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Jan 4 04:27:37 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C70533A6A7A; Sun, 4 Jan 2009 04:27:37 -0800 (PST) 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 189E73A6A7A for ; Sun, 4 Jan 2009 04:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SUBJECT_FUZZY_TION=0.156] 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 SikSbyRA3dVv for ; Sun, 4 Jan 2009 04:27:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 42E9C3A6A78 for ; Sun, 4 Jan 2009 04:27:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.36,327,1228089600"; d="scan'208";a="29991159" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 04 Jan 2009 12:27:21 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n04CRLwj017646; Sun, 4 Jan 2009 13:27:21 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n04CRLUx024894; Sun, 4 Jan 2009 12:27:21 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Jan 2009 13:27:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 4 Jan 2009 13:27:13 +0100 Message-ID: In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C2818CC3A8E@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Partition ID Thread-Index: AclhxzHPRVPuEywfSU2ks5axwepmUwJYgWhgAHNmzyAAIWpP8AAq8AeAAA83MiA= References: <5661758E3E93364685B91DD8272F28768CA4FD@S4DE8PSAAQC.mitte.t-com.de> <9BD5D7887235424FA97DFC223CAE3C2818CC3A8E@proton.jnpr.net> From: "Wojciech Dec (wdec)" To: "Sanjay Wadhwa" , , X-OriginalArrivalTime: 04 Jan 2009 12:27:21.0661 (UTC) FILETIME=[CA9AF6D0:01C96E67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8356; t=1231072041; x=1231936041; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20Partition=20ID |Sender:=20; bh=klC/tGMhFdvTDcedC+mvVsnICtZAUMKCNKyNG7QXFNE=; b=SrxzRPr/I5TjSYgc96zGmoxalQ+Qtdy+/rNxbm5RzqF1ITVjjhoYYPPgFB e7cx9S4DV3vCJ9Zd6UYAhSTdLrQNnIDLJTHNSsb5BoRK3XCPqZADaE4YQcar jMKqtC1S/6; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] Partition ID 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: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org = > -----Original Message----- > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] = > Sent: 04 January 2009 07:04 > To: Wojciech Dec (wdec); HaagT@telekom.de; ancp@ietf.org > Subject: RE: [ANCP] Partition ID > = > If each partition on an AN is always controlled via a = > different NAS (or same NAS but different peer IP address), = > then we can get away without NAS having to reflect the = > partition-ID in the ANCP messages, as partition-ID is = > implicit on the AN from peer IP address. A L3 or L2 wholesale = > service provided on the NAS (say via L2TP based backhaul to = > retail ISP's router OR via virtual routing domains on the NAS = > per retail-ISP) might seem like a driver for this on the = > surface...but then I don't believe these require partitioning = > on AN in the first place, and therefore not relevant to the = > discussion. > = > However, one can imagine a scenario where AN partitioning is = > based on a criterion other than the NAS (i.e. ANCP = > controller) controlling it. ....e.g. one might want to = > partition AN based on the type of service being delivered to = > the local-loop (e.g. business DSL line with VoIP service = > might be partitioned from HSI only DSL line). Both partitions = > might be controlled via the same NAS, and the AN could have a = > single adjacency with the NAS for both partitions. The NAS = > can potentially put the DSL subscriber in a different VRF for = > isolation (based on type of service). = This case, which I agree with, is by an large the "functional partitioning"= concept that was discussed some time ago (http://tools.ietf.org/wg/ancp/mi= nutes?item=3Dminutes66.html). = However support for it in the WG did not come through and the framework dra= ft refers to physical port partitioning only in Section 4.7.1: "One partition is grouped of several Access Ports. Each Access Port on an Access Node must be assigned uniquely to one partition" Going from the above to functional partitioning will likely require a fair = bit of work. Thus the interest of clarifying the protocol spec and if neede= d removing items that have no clear purpose and are likely to cause protoco= l incompatibility I'd encourage anyone who sees a clear need for either log= ical partitioning or some other purpose that requires the partition-id to b= e significant to the NAS to submit their case/proposal for discussion. = As things stand now, it seems that physical port partitioning can very well= be a local AN function that does not require a partition id field in ANCP. Regards, Woj. > If we don't want to rule out such a scenario, then it makes = > sense for NAS to reflect the partition-ID in the ANCP = > messages (and the NAS and AN need to have a consistent = > mapping of DSL line to partition-ID). > = > Regards > -Sanjay > = > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On = > Behalf Of Wojciech Dec (wdec) > Sent: Saturday, January 03, 2009 3:34 AM > To: HaagT@telekom.de; ancp@ietf.org > Subject: Re: [ANCP] Partition ID > = > = > = > = > > -----Original Message----- > > From: HaagT@telekom.de [mailto:HaagT@telekom.de] > > Sent: 02 January 2009 17:56 > > To: ancp@ietf.org; Wojciech Dec (wdec) > > Cc: Shridhar Rao (shrirao) > > Subject: AW: [ANCP] Partition ID > > = > > Using partitioning is not a real use case but an = > operational extension = > > in operation ANCP with multiple AN and BRAS devices. In practice a = > > single edge network does not consist of a single BRAS. = > Furthermore a = > > single BRAS location may have multiple BRAS devices. I like = > to point = > > out the operational background and the partitioning ID negotiation. > > = > > Operational background: > > From an nework developing point of view a BRAS may be fully = > loaded by = > > continuous increasing number of configured DSL ports. From traffic = > > engineering point of view the BRAS can not handle additional new = > > ports. In order not to reconfigure the whole network the AN opens a = > > new partition and the next BRAS device (same location!) terminates = > > this new partition coming from the same AN taking the new traffic. > = > You seem to be describing the case of *one* AN having two or = > more partitions each associated with a *different* BRAS/NAS = > ANCP controller through an ANCP adjacency. Is there any use = > for *one* such an AN with the same type of multi partition = > and multi-ANCP adjacency relationship with *a single* logical = > BRAS/NAS ANCP controller? What would that case be? > = > = > = > > = > > Partition ID negotiation: > > 3rd of November 2008 on the mailing list the use of partiton ID was = > > discussed too. The reason was the missmatch of an partiton ID if a = > > BRAS receives a message with a partition ID the BRAS have not known = > > before. In order not to tear down the connection the BRAS = > should learn = > > this partiton ID. > > This option was agreed to be described in the protocol draft. = > = > As Shridhar indicated, the partition id appears to be of no = > consequence to the ANCP controller except if it is expected = > to handle multiple ANCP adjacencies from one AN. = > = > Regards, > Woj. > = > > = > > So I think the reason for using of the partiton ID field is = > described = > > independent on a particular use case because this feature is a = > > fundamental operational configuration which is used by = > already defined = > > use cases and has no need to be a use case itself. Also backward = > > compatibility is an issue here to be studied carefully = > because of the = > > the impact on using partition ID filed for new functionality. > > = > > Regards > > Thomas > > = > > -----Urspr=FCngliche Nachricht----- > > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] = > Im Auftrag = > > von Wojciech Dec (wdec) > > Gesendet: Mittwoch, 31. Dezember 2008 10:31 > > An: Shridhar Rao (shrirao); ancp@ietf.org > > Betreff: Re: [ANCP] Partition ID > > = > > You raise a very good point. The partition "concept" is/was derived = > > from GSMP where presumably a single controller could be managing = > > multiple partitions on a single client. In the current set of ANCP = > > use-cases this does not seem to be required and the = > partition-id field = > > may be yet another field that could be marked as "obsolete" = > or simply = > > ignored by the NAS. Could anyone in the WG indicate whether = > they see a = > > case where a single NAS would be handling multiple partitioned ANCP = > > sessions from a single AN, and what would that case be? > > = > > Thanks, > > Woj. > > = > > > -----Original Message----- > > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] > > On Behalf > > > Of Shridhar Rao (shrirao) > > > Sent: 19 December 2008 11:48 > > > To: ancp@ietf.org > > > Subject: [ANCP] Partition ID > > > = > > > Hello, > > > We like to understand the real use for Partition ID in case > > of NAS. If > > > AN wants to use Partition ID for dividing itself into > > multiple logical > > > partitions with each controlling certain access ports on > > it, it can be > > > done by some local configuration on AN. Is there a real > > need for NAS > > > to be aware of it? > > > = > > > If Partition ID field has no use in NAS, it can be reused > > instead as > > > first byte of a 4 byte Transaction Id field (Tr ID is now = > a 3 byte = > > > quantity starting at a odd byte location), and NAS need not worry = > > > about partition ID at all eliminating the need for exchange of = > > > adjacency messages for convergence of Partition ID. > > > = > > > Thanks, > > > Shridhara rao > > > _______________________________________________ > > > ANCP mailing list > > > ANCP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ancp > > > = > > _______________________________________________ > > ANCP mailing list > > ANCP@ietf.org > > https://www.ietf.org/mailman/listinfo/ancp > > = > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > = _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 5 02:30:33 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1953A6887; Mon, 5 Jan 2009 02:30:33 -0800 (PST) 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 6CD013A6887 for ; Mon, 5 Jan 2009 02:30:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 3fZnPySDgI3b for ; Mon, 5 Jan 2009 02:30:25 -0800 (PST) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id B31F83A63CB for ; Mon, 5 Jan 2009 02:30:24 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n05AU8H9004288; Mon, 5 Jan 2009 11:30:08 +0100 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 5 Jan 2009 11:30:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 5 Jan 2009 11:30:04 +0100 Message-ID: <7168964CAC5C144685272595141B6DBA019F1442@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call for draft-ietf-ancp-framework-07.txt Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAGO3PVA References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> From: "OOGHE Sven" To: X-OriginalArrivalTime: 05 Jan 2009 10:30:08.0089 (UTC) FILETIME=[94AECC90:01C96F20] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org All, With a bit of delay, here are my last call comments on the famework. * Section 4.5 Change the requirements as follows: "- The ANCP MUST support an adjacency protocol in order to automatically synchronize its operational state between its peers, to agree on which version of the protocol to use, to discover the identity of its peers, and detect when they change. - The ANCP MUST include a mechanism to automatically detect adjacency loss. - A loss of the Access Node Control Adjacency MUST NOT affect subscriber connectivity. - If the Access Node Control Adjacency is lost, it MUST result in deterministic behavior on all network elements involved. - The ANCP MUST support a mechanism to synchronize access port configuration and status information between ANCP peers as part of establishing or recovering the Access Node Control Adjacency." * Section 4.7.1 Change o Each AN partition must have a separate Access Node Control Adjacency to a NAS and should be able to enforce access control on the controllers to only designated partitions being bound to one controller. To "- Each AN partition must have a separate Access Node Control Adjacency to a NAS - Each AN partition must be able to enforce access of the controllers to their designated partitions." Remove the following requirements: o For security purposes, the Access Node Control Protocol messages sent over the channel MUST NOT be sent towards the customer premises. o The Access Node must not support the capability to configure sending Access Node Control Protocol messages towards the customer premises. Add the following requirement to Section 7: "- The Access Node MUST NOT allow the sending of Access Node Control Messages towards the customer premises." * Section 4.7.2 Change o If ATM interfaces are used, VPI as well as VCI value must be configurable in the full range. o If Ethernet interfaces are used, C-Tag as well as S-Tag must be configurable in the full range. To "- If ATM interfaces are used then any VPI and VCI value must be able to be used for the purpose of supporting the Access Node Control Channel. - If Ethernet interfaces are used then any C-VID and S-VID must be able to be used for the purpose of supporting the Access Node Control Channel." * Section 4.8.1 Change o The NAS should support a reduction or disabling of such shaping limit, derived from Policy/Radius per-subscriber authorization data. To "- The NAS should support reducing or disabling the shaping limit used in the Hierarchical Scheduling process, according to per-subscriber authorization data retrieved from a AAA or Policy Server." Regards, Sven -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it] Sent: vrijdag 12 december 2008 10:26 To: OOGHE Sven; ancp@ietf.org Cc: BOCCI Matthew Subject: RE: WG last call for draft-ietf-ancp-framework-07.txt Hello, I did a comparison between draft draft-ietf-ancp-framework-07.txt and latest version of BBF WT-147 in order to identify the differences between the two documents introduced with recent changes in WT-147. Please find my comments for draft draft-ietf-ancp-framework-07.txt below. Thanks, Best Regards, Roberta Section 1.2 page 5 I suggest the following changes in order to reflect BBF WT-147 definitions: "Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the portion of the total data rate that can be used to transmit user information (e.g. ATM cells or Ethernet frames). It excludes overhead that pertains to the physical transmission mechanism (e.g. trellis coding in case of DSL)." Add: "It includes TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation; this is zero for ATM encapsulation, and non-zero for 64/65 encapsulation. " Replace: Line Rate: the total data rate including overhead. By: Line Rate: defined by ITU-T G.993.2. It contains the complete overhead including RS and trellis coding. Section 2.1 Page 8. To be consistent with latest changes in BBF WT-147 I propose to split reporting and enforcement functions in two separate bullets Section 2.2.2 Page 9 line 466: for each technology there is a reference to RFC I would suggest adding: IPoE defined in RFC 894 Section 2.4 page 12 line 630: Replace: "Also, there is a possibility to integrate this with a Policy Server (e.g. RADIUS server) that keeps track of the different Subscriber related parameters." By: "Also, there is a possibility to integrate this with a Policy Server or an AAA/RADIUS server that keeps track of the different Subscriber related parameters." Section 3.2 page 15 line 818: Replace "the NAS could query a Policy Server (e.g. RADIUS server) to retrieve Access Loop configuration data." by "the NAS could query a Policy Server or an AAA/RADIUS server to retrieve Access Loop configuration data." Section 3.4.2 Page 22 line 1209: Replace: "perform CAC for unicast and multicast flows and perform video bandwidth accounting." By "perform CAC for unicast and multicast flows and perform video bandwidth management" Section 3.4.3 Page 26 line 1424 I would suggest rephrasing this sentence as ANCP Bulk message has been removed from the protocol draft. "In case of very fast channel changes, the amount of Information Report messages to be sent to the NAS could become high. In order to reduce the number of messages, the AN may bundle several Information Reports together in a single "bulk transaction"." Section 4.1 Page 28 line 1555 To be consistent with recent changes in BBF WT-147 replace: " In large scale networks, Access Nodes are provisioned but not always fully populated. Therefore the ANCP MUST be scalable enough to allow a given NAS to control thousands of Access Nodes (e.g. typically 5000 to 10000)." By " The protocol must be scalable enough to allow a given NAS to control at least 5000 Access Nodes." The following requirement has been removed from WT-147: " The ANCP SHOULD minimize sources of configuration mismatch, help automation of the overall operation of the systems involved (Access Nodes and NAS) and be easy to troubleshoot. Page 29 line 1578: "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently (e.g. using "message bundling")." I suggest removing "(e.g. using "message bundling")." Do we really need three different sections (4.3, 4.7.9 and 4.8.9) for security (plus section 7 "Security considerations") all of them pointing to the draft draft-ietf-ancp-security-threats? Would not be possible to remove sections 4.3, 4.7.9 and 4.8.9 as the text contained in these sections is already in section 7? Section 4.8.1 Line 2045: As per BBF comments replace: " The NAS must only communicate to authorized Access Node Control peers." By: " The NAS must establish ANCP Adjacencies only with authorized ANCP peers. " Section 5. " This document does not consider the specific details of the communication with a Policy Server (e.g. using RADIUS)." I would remove "(e.g. using RADIUS)." Missing References to the following RFCs mentioned in the text: RFC2684, RFC2516, RFC2225, RFC 894 - editorial: replace everywhere in the document "DSL Forum" with "Broadband Forum" Thanks, Regards, Roberta ----------------------------------------------------- Roberta Maglione - CCIE #18425 Telecom Italia Broadband Network Services Innovation ----------------------------------------------------- ________________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Monday, December 08, 2008 1:42 PM To: ancp@ietf.org Subject: [ANCP] WG last call for draft-ietf-ancp-framework-07.txt This email is to start a two week working group last call for draft-ietf-ancp-framework-07.txt Please review and provide comments to the list by Monday 22nd December. The following have also kindly offered to review the document: - Roberta Maglione - Alan Kavanagh - John Zhao - Tom Taylor - Sven Ooghe - Francois LeFaucher Best regards Matthew Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. Rispetta l'ambiente. Non stampare questa mail se non e' necessario. www.avoicomunicare.it Ogni giorno, il tuo luogo di dialogo. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Jan 11 07:22:31 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C88B23A690B; Sun, 11 Jan 2009 07:22:31 -0800 (PST) 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 CDC7428C1D7 for ; Sun, 11 Jan 2009 07:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, 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 u7rHRQPRmGC5 for ; Sun, 11 Jan 2009 07:22:30 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 32E6C3A6833 for ; Sun, 11 Jan 2009 07:22:28 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,248,1231113600"; d="scan'208";a="38320895" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 11 Jan 2009 15:22:12 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0BFMBs0012788 for ; Sun, 11 Jan 2009 20:52:11 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0BFMB5f002768 for ; Sun, 11 Jan 2009 15:22:11 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jan 2009 20:52:10 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 Jan 2009 20:52:14 +0530 Message-ID: In-Reply-To: <7168964CAC5C144685272595141B6DBA019F1442@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Proposing that keep-alives be sent only from client Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAGO3PVABIdutYA= References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA019F1442@FRVELSMBS22.ad2.ad.alcatel.com> From: "Shridhar Rao (shrirao)" To: X-OriginalArrivalTime: 11 Jan 2009 15:22:10.0939 (UTC) FILETIME=[5F9804B0:01C97400] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=852; t=1231687331; x=1232551331; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shrirao@cisco.com; z=From:=20=22Shridhar=20Rao=20(shrirao)=22=20 |Subject:=20=20[ANCP]=20Proposing=20that=20keep-alives=20be =20sent=20only=20from=20client |Sender:=20; bh=iROCIqCEAmrhzIHZj/Yl+G0U5jGtRk44E6CeNGvogno=; b=VyrH0tKSnAvJblXPKSE6hDD2ORFmdIvywWzYVPKacggcTuu6gXb0muNBqI EH0skxI5AXA4CtYc7sogx4PsQ/GgXfKrWNCt4lkQuLlReTRh5/A8wIlK1FxL x9mYDcviKp; Authentication-Results: ind-dkim-2; header.From=shrirao@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Subject: [ANCP] Proposing that keep-alives be sent only from client 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi, Based on section 5.2 of ANCP protocol draft, both server and client have to send keep-alives. To help reduce the unnecessary message exchange between server and client and for a better utilization of bandwidth we are proposing that only client send the keep-alives and server just ack it. The client side can assume that server is dead when it doesn't receive acknowledgements for 3 successive keep-alives and similarly server can assume client is not alive when it doesn't get 3 consecutive keep-alives on time. The code changes required for this from the current scheme of both ends sending keep-alives is very minimal (runs to few lines and is easy to implement). But if someone feels that we need to still retain the older scheme, then we can make this negotiable by introducing one more capability. regards, -shridhar- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Sun Jan 11 07:34:17 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D80D628C153; Sun, 11 Jan 2009 07:34:17 -0800 (PST) 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 E7CC428C153 for ; Sun, 11 Jan 2009 07:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.172 X-Spam-Level: X-Spam-Status: No, score=-6.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, 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 i4Tj6q9wrCr7 for ; Sun, 11 Jan 2009 07:34:16 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 58E063A6359 for ; Sun, 11 Jan 2009 07:34:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,248,1231113600"; d="scan'208";a="38321034" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 11 Jan 2009 15:33:59 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n0BFXwgN026681 for ; Sun, 11 Jan 2009 21:03:58 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0BFXuqk003162 for ; Sun, 11 Jan 2009 15:33:56 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Jan 2009 21:03:57 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 11 Jan 2009 21:04:00 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposing that keep-alives be sent only from client Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAGO3PVABIdutYAAAJYi8A== References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com> <7168964CAC5C144685272595141B6DBA019F1442@FRVELSMBS22.ad2.ad.alcatel.com> From: "Shridhar Rao (shrirao)" To: X-OriginalArrivalTime: 11 Jan 2009 15:33:57.0427 (UTC) FILETIME=[04B18830:01C97402] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=855; t=1231688038; x=1232552038; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shrirao@cisco.com; z=From:=20=22Shridhar=20Rao=20(shrirao)=22=20 |Subject:=20=20Proposing=20that=20keep-alives=20be=20sent=2 0only=20from=20client |Sender:=20; bh=3wD07dhI8CAa6qL2OB5e30/Ij8MvZyF2LuXrrCFN8Wc=; b=Oz42y/KCLLMQAKkoIwETcMtazBDSjht5pTePI54WLgZzkP3CwLnZNs6rAQ 2mxWysgDszlmdZxey9IvPQQvUNEQDhvI0gcXRfVqk+t2Oz9xYZEUnpUSDfG2 SwoCRgOsuz; Authentication-Results: ind-dkim-1; header.From=shrirao@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Subject: [ANCP] Proposing that keep-alives be sent only from client 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi all, Based on section 5.2 of ANCP protocol draft, both server and client have to send keep-alives. To help reduce the unnecessary message exchange between server and client and for a better utilization of bandwidth we are proposing that only client send the keep-alives and server just ack it. The client side can assume that server is dead when it doesn't receive acknowledgements for 3 successive keep-alives and similarly server can assume client is not alive when it doesn't get 3 consecutive keep-alives on time. The code changes required for this from the current scheme of both ends sending keep-alives is very minimal (runs to few lines and is easy to implement). But if someone feels that we need to still retain the older scheme, then we can make this negotiable by introducing one more capability. regards, -shridhar- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From ancp-bounces@ietf.org Mon Jan 12 09:47:06 2009 Return-Path: X-Original-To: ancp-archive@optimus.ietf.org Delivered-To: ietfarch-ancp-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D2D028C328; Mon, 12 Jan 2009 09:47:06 -0800 (PST) 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 2B4913A6358 for ; Mon, 12 Jan 2009 09:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=1.991, BAYES_00=-2.599, 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 YzJiT1-MhFik for ; Mon, 12 Jan 2009 09:47:04 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 6F67F28C387 for ; Mon, 12 Jan 2009 09:46:38 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,253,1231113600"; d="scan'208";a="38402602" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 12 Jan 2009 17:46:19 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n0CHkJRd018643 for ; Mon, 12 Jan 2009 23:16:19 +0530 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n0CHkJwi027117 for ; Mon, 12 Jan 2009 17:46:19 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jan 2009 23:16:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 12 Jan 2009 23:16:14 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP messages for Multicast query and report Thread-Index: Acl03aoXUeqKXaQARgaXa0fvaISgPw== From: "Aniruddha A (anira)" To: X-OriginalArrivalTime: 12 Jan 2009 17:46:18.0962 (UTC) FILETIME=[ACA15B20:01C974DD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7213; t=1231782379; x=1232646379; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anira@cisco.com; z=From:=20=22Aniruddha=20A=20(anira)=22=20 |Subject:=20ANCP=20messages=20for=20Multicast=20query=20and =20report |Sender:=20; bh=2zBu+nR1qi4wUJdyuaiYw5EJqsWHpTExwCzkKTO95yQ=; b=ByQYrKlOPV5NDgUuA9SzlfXhHFhyGcdr6MWsbEQfNvDIfzQLXc9Zg/EMjN Zj6yj7tEZULwyVNbYd2y3mbi3L+5ZpzRklFzqsUHp2fF7x0Vb4A5phcmcklT tRvoaiUJbY; Authentication-Results: ind-dkim-2; header.From=anira@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Subject: [ANCP] ANCP messages for Multicast query and report 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ancp-bounces@ietf.org Errors-To: ancp-bounces@ietf.org Hi all, In the ANCP multicast extensions, there has to be a way For the NAS to query the AN for the state of active multicast flows on it. We propose the following 2 new messages for this purpose: - Active-Flow Request - Active-Flow Report The query from the NAS can be for all flows on the AN or flows active on a single port. Message Type 0x92 is used. Description and message formats: Active-Flow Request Message The Active Flow Request message is sent by the NAS to the AN to request multicast flow status on the AN. The payload contains the following TLVs: o The Active-Flow-Req TLV (0x103) A Mandatory TLV. o The Target Type TLV. Optional TLV, if present, request is for a single port. On receiving the Active Flow Request message, the AN MUST respond with the Active Flow Report containing the requested information if the Multicast capability has been negotiated. The format of the message is shown below: 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 |MsgType=0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowReq TLV =0x103 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Active-Flow Report Message The Active Flow Report message is sent from the AN to the NAS in response to the Active Flow Request message. Active Flow Report message contains information on the requested multicast flows. The report can be for a single port, or all ports depending on the Target Type in the request. o Single Port Report If the Active Flow Request had a specific port (the presence of a Target Type TLV), the response has the following format: 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 |MsgType=0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowPortEntryTLV =0x105 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Followed by the Multicast Flow ID TLVs (0x107), one for each flow on the port. The format of the Flow ID TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 S is the source flag, if set, multicast source address MUST be present (SSM). o Report for all ports If the Active Flow Request did not specify a specific port (no Target Type TLV), the response will have the following format: 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 |MsgType=0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ActiveFlowMcastEntryTLV =0x104 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV = 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Followed by the Target Type TLV. A Multicast Entry TLV (0x104) determines the (flow, port), therefore it will have a Flow ID TLV and a Target-Type TLV as its sub TLVs, and there will be as many Multicast Entry TLVs as the number of flows on the AN. We have an implementation running with these message types. -- Regards, Aniruddha. A _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From root@core3.amsl.com Wed Feb 4 02:45:02 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3619728C1E4; Wed, 4 Feb 2009 02:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090204104502.3619728C1E4@core3.amsl.com> Date: Wed, 4 Feb 2009 02:45:02 -0800 (PST) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-08.txt 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, 04 Feb 2009 10:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-08.txt Pages : 51 Date : 2009-02-04 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing OSS systems. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-framework-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-02-04023734.I-D@ietf.org> --NextPart-- From roberta.maglione@telecomitalia.it Thu Feb 5 07:49:09 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 296C428C1C1 for ; Thu, 5 Feb 2009 07:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 xE9gOeyKEifV for ; Thu, 5 Feb 2009 07:49:08 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by core3.amsl.com (Postfix) with ESMTP id 953713A67E6 for ; Thu, 5 Feb 2009 07:49:07 -0800 (PST) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.1.336.0; Thu, 5 Feb 2009 16:47:12 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.20]) by grfhub702rm001.griffon.local ([10.19.9.235]) with mapi; Thu, 5 Feb 2009 16:48:46 +0100 From: Maglione Roberta To: "'Aniruddha A (anira)'" , "ancp@ietf.org" Date: Thu, 5 Feb 2009 16:48:45 +0100 Thread-Topic: ANCP messages for Multicast query and report Thread-Index: Acl03aoXUeqKXaQARgaXa0fvaISgPwSydzVA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ANCP] ANCP messages for Multicast query and report 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, 05 Feb 2009 15:49:09 -0000 Hi Aniruddha, your proposal seems interesting to me, but I have a comment: section 3.4.3 of the ancp-framework draft defines 3 different types of repo= rting function: - report for one Access Port; - report for one multicast flow; - a global report for one Access Node. If my understanding is correct, your proposal addresses 1 and 3, do you pla= n to extend it to cover also case 2? Thanks and best regards. Roberta -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ani= ruddha A (anira) Sent: Monday, January 12, 2009 6:46 PM To: ancp@ietf.org Subject: [ANCP] ANCP messages for Multicast query and report Hi all, In the ANCP multicast extensions, there has to be a way For the NAS to query the AN for the state of active multicast flows on it. We propose the following 2 new messages for this purpose: - Active-Flow Request - Active-Flow Report The query from the NAS can be for all flows on the AN or flows active on a single port. Message Type 0x92 is used. Description and message formats: Active-Flow Request Message The Active Flow Request message is sent by the NAS to the AN to request multicast flow status on the AN. The payload contains the following TLVs: o The Active-Flow-Req TLV (0x103) A Mandatory TLV. o The Target Type TLV. Optional TLV, if present, request is for a single port. On receiving the Active Flow Request message, the AN MUST respond with the Active Flow Report containing the requested information if the Multicast capability has been negotiated. The format of the message is shown below: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=3D0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Active-Flow Report Message The Active Flow Report message is sent from the AN to the NAS in response to the Active Flow Request message. Active Flow Report message contains information on the requested multicast flows. The report can be for a single port, or all ports depending on the Target Type in the request. o Single Port Report If the Active Flow Request had a specific port (the presence of a Target Type TLV), the response has the following format: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowPortEntryTLV =3D0x105 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=3D0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Followed by the Multicast Flow ID TLVs (0x107), one for each flow on the port. The format of the Flow ID TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 S is the source flag, if set, multicast source address MUST be present (SSM). o Report for all ports If the Active Flow Request did not specify a specific port (no Target Type TLV), the response will have the following format: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ActiveFlowMcastEntryTLV =3D0x104 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Followed by the Target Type TLV. A Multicast Entry TLV (0x104) determines the (flow, port), therefore it will have a Flow ID TLV and a Target-Type TLV as its sub TLVs, and there will be as many Multicast Entry TLVs as the number of flows on the AN. We have an implementation running with these message types. -- Regards, Aniruddha. A _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From anira@cisco.com Mon Feb 9 02:49: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 BD54C3A6B68 for ; Mon, 9 Feb 2009 02:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.995, BAYES_00=-2.599, 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 D4v3Q26JD1gy for ; Mon, 9 Feb 2009 02:49:09 -0800 (PST) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 94F273A6B16 for ; Mon, 9 Feb 2009 02:49:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.37,404,1231113600"; d="scan'208";a="42848739" Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 09 Feb 2009 10:49:11 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n19AnBhV032694; Mon, 9 Feb 2009 16:19:11 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n19AnAlf029463; Mon, 9 Feb 2009 10:49:10 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Feb 2009 16:18:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Feb 2009 16:18:56 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP messages for Multicast query and report Thread-Index: Acl03aoXUeqKXaQARgaXa0fvaISgPwSydzVAAL7DRzA= References: From: "Aniruddha A (anira)" To: "Maglione Roberta" X-OriginalArrivalTime: 09 Feb 2009 10:48:56.0437 (UTC) FILETIME=[01B04A50:01C98AA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9141; t=1234176551; x=1235040551; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anira@cisco.com; z=From:=20=22Aniruddha=20A=20(anira)=22=20 |Subject:=20RE=3A=20ANCP=20messages=20for=20Multicast=20que ry=20and=20report |Sender:=20; bh=kD7tunZEEXihp8Jz/ODn4mB3ftVewpfnF/ZXxtvJvf8=; b=Dba5leKgLcZhpGyt23du9MEDUDFO0zp5En48YV2iFNuFQpRbLobQ7TMcYR WepEQVfUgDpr8ZtKDRNPl2Mfl4Tg0EQQSBfEza689oEGF/o3UWef+OaalKd9 KRivGvBW9r; Authentication-Results: ind-dkim-2; header.From=anira@cisco.com; dkim=pass ( sig from cisco.com/inddkim2002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP messages for Multicast query and report 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, 09 Feb 2009 10:49:10 -0000 Hi Roberta, =20 Yes, the current proposal addresses only case 1 and 3.=20 I plan to cover case 2 also, I'm working on it. -- Regards, Aniruddha. A -----Original Message----- From: Maglione Roberta [mailto:roberta.maglione@telecomitalia.it]=20 Sent: Thursday, February 05, 2009 9:19 PM To: Aniruddha A (anira); ancp@ietf.org Subject: RE: ANCP messages for Multicast query and report Hi Aniruddha, your proposal seems interesting to me, but I have a comment: section 3.4.3 of the ancp-framework draft defines 3 different types of reporting function: - report for one Access Port; - report for one multicast flow; - a global report for one Access Node. If my understanding is correct, your proposal addresses 1 and 3, do you plan to extend it to cover also case 2? Thanks and best regards. Roberta -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Aniruddha A (anira) Sent: Monday, January 12, 2009 6:46 PM To: ancp@ietf.org Subject: [ANCP] ANCP messages for Multicast query and report Hi all, In the ANCP multicast extensions, there has to be a way For the NAS to query the AN for the state of active multicast flows on it. We propose the following 2 new messages for this purpose: - Active-Flow Request - Active-Flow Report The query from the NAS can be for all flows on the AN or flows active on a single port. Message Type 0x92 is used. Description and message formats: Active-Flow Request Message The Active Flow Request message is sent by the NAS to the AN to request multicast flow status on the AN. The payload contains the following TLVs: o The Active-Flow-Req TLV (0x103) A Mandatory TLV. o The Target Type TLV. Optional TLV, if present, request is for a single port. On receiving the Active Flow Request message, the AN MUST respond with the Active Flow Report containing the requested information if the Multicast capability has been negotiated. The format of the message is shown below: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=3D0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Active-Flow Report Message The Active Flow Report message is sent from the AN to the NAS in response to the Active Flow Request message. Active Flow Report message contains information on the requested multicast flows. The report can be for a single port, or all ports depending on the Target Type in the request. o Single Port Report If the Active Flow Request had a specific port (the presence of a Target Type TLV), the response has the following format: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowPortEntryTLV =3D0x105 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=3D0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Followed by the Multicast Flow ID TLVs (0x107), one for each flow on the port. The format of the Flow ID TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 S is the source flag, if set, multicast source address MUST be present (SSM). o Report for all ports If the Active Flow Request did not specify a specific port (no Target Type TLV), the response will have the following format: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ActiveFlowMcastEntryTLV =3D0x104 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Followed by the Target Type TLV. A Multicast Entry TLV (0x104) determines the (flow, port), therefore it will have a Flow ID TLV and a Target-Type TLV as its sub TLVs, and there will be as many Multicast Entry TLVs as the number of flows on the AN. We have an implementation running with these message types. -- Regards, Aniruddha. A _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. From acassen@freebox.fr Tue Feb 17 04:46: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 EE01C3A6C03 for ; Tue, 17 Feb 2009 04:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.902 X-Spam-Level: * X-Spam-Status: No, score=1.902 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_SBL=1.551] 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 I-uqetqMUE-s for ; Tue, 17 Feb 2009 04:46:54 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id F3A5E3A697F for ; Tue, 17 Feb 2009 04:46:51 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 034AED481A0 for ; Tue, 17 Feb 2009 13:46:59 +0100 (CET) Received: from mail.lnxos.net (lnxos.staff.proxad.net [213.228.1.83]) by smtp5-g21.free.fr (Postfix) with ESMTP id E92C2D48180 for ; Tue, 17 Feb 2009 13:46:56 +0100 (CET) Received: from [192.168.200.150] (lnxos-dev [192.168.200.150]) by mail.lnxos.net (Postfix) with ESMTP id B784C87EA for ; Tue, 17 Feb 2009 13:46:56 +0100 (CET) From: Alexandre Cassen To: ancp@ietf.org Content-Type: text/plain Organization: Freebox S.A. Date: Tue, 17 Feb 2009 13:53:04 +0100 Message-Id: <1234875184.24092.676.camel@lnxos-dev> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Content-Transfer-Encoding: 7bit Subject: [ANCP] Fallback adjacency 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, 17 Feb 2009 12:46:55 -0000 Hello, Maybe this is a topic for graceful restart, purpose here is to speed up adj synchronization recover after NAS IP takes over to another NAS in a redundant env. Due to spec rfc3292.11.4, loss of synchronization defines a non-correlation between TCP and ANCP lost, ANCP keeps track of states until three time the value of 'Timer' field even if TCP connection has been reset. If considering replication control message, this lead to disabling replication control channel until ANCP Timer fire at AN side. If we are considering an env with 2 NAS runing VRRP to expose a VIP to remote Access Nodes (master on NAS 1) : +-------------+ | Access Node | +-------------+ | v VRRP_VIP o..... / . (m)/ .(b) +-------+ +-------+ | NAS 1 | | NAS 2 | +-------+ +-------+ If NAS 1 crash down then NAS 2 will take over VIP but AN will recover operational adjacency until loss of synchronization timer has fired at AN side. If we could define kind of fallback adjacency at AN side then we could eliminate impact of takeover: +-------------+ | Access Node | +-------------+ (adj_m)/ \(adj_fb) v v VIP1 VIP2 o.............o / . . \ (m1)/ .(b2) .(b1) \(m2) +-------+ +-------+ | NAS 1 | | NAS 2 | +-------+ +-------+ AN could maintains 2 adjacencies, one to each NAS. If NAS 1 crash, NAS 2 will takeover, which will transparently takeover NAS 1 role (replication control for instance) to remote AN but via ANCP ESTAB channel => adj_fb. When NAS 1 comes back it may defer its operations until remote AN is reachable by adj_m. This processing only defines operations rules on NAS side, impact on AN side is only having 2 adj up and running at a time. best regs, Alexandre From Matthew.Bocci@alcatel-lucent.com Tue Feb 17 06: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 EE6FE3A6A01 for ; Tue, 17 Feb 2009 06:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.759 X-Spam-Level: X-Spam-Status: No, score=-4.759 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 N+WYhES7L-HP for ; Tue, 17 Feb 2009 06:30:33 -0800 (PST) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id F1A7F3A6998 for ; Tue, 17 Feb 2009 06:30:32 -0800 (PST) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1HEUfMK019432 for ; Tue, 17 Feb 2009 15:30:41 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Feb 2009 15:30:41 +0100 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_01C9910C.4F79764D" Date: Tue, 17 Feb 2009 15:30:40 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A0358B9C8@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Time slots for San Francisco Thread-Index: AcmRDE7gjGZw4SS3Q9Sm/AVEgZ1R/Q== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 17 Feb 2009 14:30:41.0444 (UTC) FILETIME=[4F653E40:01C9910C] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [ANCP] Time slots for San Francisco 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, 17 Feb 2009 14:30:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9910C.4F79764D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Please can you let me know if you would like a time slot for the ANCP meeting in San Francisco.. Please let me know the subject you would like to discuss and a pointer to the draft, if any. Thanks. Matthew ------_=_NextPart_001_01C9910C.4F79764D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Time slots for San Francisco

Folks,

Please can you let me know if you would = like a time slot for the ANCP meeting in San Francisco.. Please let me = know the subject you would like to discuss and a pointer to the draft, = if any.

Thanks.

Matthew

------_=_NextPart_001_01C9910C.4F79764D-- From Matthew.Bocci@alcatel-lucent.com Tue Feb 17 07:15: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 2F5A028B56A for ; Tue, 17 Feb 2009 07:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 JnWuK2ObM4mw for ; Tue, 17 Feb 2009 07:15:31 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id D28533A6833 for ; Tue, 17 Feb 2009 07:15:30 -0800 (PST) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1HFFPHu031904 for ; Tue, 17 Feb 2009 16:15:40 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 17 Feb 2009 16:15:25 +0100 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_01C99112.8F0EE891" Date: Tue, 17 Feb 2009 16:15:24 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A0358BA21@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updates to ANCP charter Thread-Index: AcmREo5t4H8T/WTBRKWpimYr6A7gcg== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 17 Feb 2009 15:15:25.0433 (UTC) FILETIME=[8F2D7690:01C99112] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [ANCP] Updates to ANCP charter 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, 17 Feb 2009 15:15:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99112.8F0EE891 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All There has been some interest shown in expanding the scope of ANCP to include PON. However, our charter up until now has been pretty specific about focussing on DSL.=20 We would therefore like to propose some updates to the charter to allow ANCP to develop extensions for other technologies apart from DSL. We also need to revise our goals and milestones to reflect the latest status of the multicast work. Please find attached a draft revised charter. Please can you post any comments to the list by the end of the February to give us time to make any updates before the next IETF. Best regards Matthew & Woj Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP based Access Node=20 Control Protocol (ANCP) for use in service provider broadband access and aggregation=20 networks e.g. Digital Subscriber Line (DSL) and Passive Optical Network (PON). ANCP operates between an=20 Access Node (AN) and Network Access Server (NAS).=20 Necessary Terminology: Access Node (AN) - Network device, usually located at a service=20 provider central office or street cabinet, that terminates access loop=20 connections from Subscribers. In DSL, this is often referred to as a=20 Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates=20 multiplexedSubscriber traffic from a number of Access Nodes. The NAS=20 plays a central role in per-subsciber policy enforcement and QoS.=20 Often referred to as a Broadband Network Gateway (BNG) or Broadband=20 Remote Access Server (BRAS). A detailed definition of the NAS is given=20 in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e.,=20 Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an=20 ANCP message exchange is to convey status and control information=20 between one or more ANs and one or more NASs without going through=20 intermediate element managers.=20 The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks=20 to avoid congestion while dealing with multiple flows and distinct QoS=20 profiles. Communicating the access-loop status, attributes and current=20 DSL synchronization rate between the AN and Subscriber up to the NAS=20 is desirable, particularly when the NAS is providing QoS for=20 individual flows and subscribers. ANCP will provide a mechanism to=20 communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to=20 the NAS, ANCP will allow a NAS to send loop-specific configuration=20 information to an AN based on the results of subscriber authentication=20 and authorization (e.g., after AAA responses have been received at the=20 NAS).=20 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point=20 ATM circuits between the AN and NAS for each subscriber, allowing=20 troubleshooting of the local loop from the NAS via ATM OAM tools. With=20 the increasing deployment of Ethernet in the access and aggregation=20 network, operators require consistent methods to test and troubleshoot=20 connectivity for mixed Ethernet and ATM access networks (including the=20 local loop). ANCP will allow a remote procedure for a local loop=20 connectivity test to be triggered from the NAS with results=20 communicated back to the NAS.=20 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow=20 the AN to perform subscriber bound multicast group replication in line=20 with the subscriber's policy and configuration, and also allow the NAS=20 to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS,=20 over a broadband access and aggregation network. It will not address setup=20 or configuration of circuits or connections in the access and=20 aggregation network itself. The focus of this WG is on one very specific application space. While=20 the design of the protocol must be general as to not preclude other=20 uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of broadband access and aggregation=20 networks.=20 Security: The ANCP working group will provide a threat analysis and address the=20 associated security aspects of the control protocol.=20 Resiliency and Scalability:=20 A graceful restart mechanism will be defined to enable the protocol to=20 be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating=20 traffic from a large number of ANs, which in turn may be serving a=20 large number of Subscribers. ANCP traffic should not become a denial=20 of service attack on the NAS control plane. Format of messages,=20 pacing, transport over UDP or TCP, etc. will be considered with this=20 in mind. For reasons of aggregation network scalability, some use cases require=20 that aspects of NAS or AN functionality may be distributed in nodes in=20 the aggregation network. In these cases, ANCP can run between these=20 nodes. Deliverables: The working group will define a basic framework and requirements=20 document intended for Informational publication, focusing on the four=20 use-cases outlined in this charter. This document will include a=20 security threat analysis and associated requirements. The WG will then=20 investigate and define a solution for an IP based control protocol=20 meeting these requirements.=20 There are early interoperable implementations of an ANCP-like protocol=20 which are based on an extended subset of the GSMPv3 protocol. This=20 running code will be the starting point for the working group=20 solution, and will be abandoned only if the WG determines it is not=20 adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so=20 the management framework and MIB modules are consistent for DSL=20 access environments. The working group will re-use, as far as=20 possible, standard MIB modules that have already been defined. The working group will coordinate with the Broadband Forum to ensure that=20 ANCP meets the requirements of broadband access networks. The remote connectivity test use case may require coordination with=20 ITU-T Ethernet OAM work, and with IEEE 802.1ag. Goals and Milestones: Done Accept WG I-D for ANCP Framework and Requirements=20 Done Accept WG I-D for Access Node Control Protocol (ANCP)=20 Done Accept WG ID for Security Threats analysis=20 Done Accept WG I-D for ANCP MIB=20 Done Security Threats Analysis last call=20 Mar 2008 ANCP MIB Last Call=20 Done Framework and Requirements last call=20 Mar 2009 Accept WG I-D for Additional Multicast Extensions Mar 2009 Accept WG I-D for ANCP applicability to PON Aug 2009 Access Node Control Protocol (ANCP) Last Call=20 Dec 2009 Additional Multicast Extensions Last Call Dec 2009 Re-charter or conclude Working Group=20 ------_=_NextPart_001_01C99112.8F0EE891 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Updates to ANCP charter

All

There has been some interest shown in = expanding the scope of ANCP to include PON. However, our charter up = until now has been pretty specific about focussing on DSL.

We would therefore like to propose some = updates to the charter to allow ANCP to develop extensions for other = technologies apart from DSL. We also need to revise our goals and = milestones to reflect the latest status of the multicast = work.

Please find attached a draft revised = charter. Please can you post any comments to the list by the end of the = February to give us time to make any updates before the next = IETF.

Best regards

Matthew & Woj

Description of Working = Group:

Purpose:

The purpose of the ANCP WG is to = standardize an IP based Access Node
Control Protocol (ANCP) for use = in service provider broadband access and aggregation
networks e.g. Digital Subscriber = Line (DSL) and Passive Optical Network (PON). ANCP operates between an =
Access Node (AN) and Network = Access Server (NAS).

Necessary Terminology:

Access Node (AN) - Network = device, usually located at a service
provider central office or = street cabinet, that terminates access loop
connections from Subscribers. In = DSL, this is often referred to as a
Digital Subscriber Line Access = Multiplexer (DSLAM). In PON, this is usually comprised of an Optical = Network Termination (ONT) and an Optical Line Termination = (OLT).

Network Access Server (NAS) - = Network device which aggregates
multiplexedSubscriber traffic = from a number of Access Nodes. The NAS
plays a central role in = per-subsciber policy enforcement and QoS.
Often referred to as a Broadband = Network Gateway (BNG) or Broadband
Remote Access Server (BRAS). A = detailed definition of the NAS is given
in RFC2881.

Goals:

ANCP is intended to address the = requirement for a bidirectional, IP-
based, control protocol that = operates across multiple types (i.e.,
Ethernet, ATM) of DSL and PON = access and aggregation networks. The goal of an
ANCP message exchange is to = convey status and control information
between one or more ANs and one = or more NASs without going through
intermediate element managers. =

The ANCP WG will address the = following four use-cases:

1. Dynamic Access Loop = Attributes
Various queuing and scheduling = mechanisms are used in access networks
to avoid congestion while = dealing with multiple flows and distinct QoS
profiles. Communicating the = access-loop status, attributes and current
DSL synchronization rate between = the AN and Subscriber up to the NAS
is desirable, particularly when = the NAS is providing QoS for
individual flows and = subscribers. ANCP will provide a mechanism to
communicate dynamic access-loop = attributes from the AN to the NAS.

2. Access Loop = Configuration
In additional to reporting = Access Loop characteristics from the AN to
the NAS, ANCP will allow a NAS = to send loop-specific configuration
information to an AN based on = the results of subscriber authentication
and authorization (e.g., after = AAA responses have been received at the
NAS).

3. Remote Connectivity = Test
Traditional DSL access and = aggregation networks employ point-to-point
ATM circuits between the AN and = NAS for each subscriber, allowing
troubleshooting of the local = loop from the NAS via ATM OAM tools. With
the increasing deployment of = Ethernet in the access and aggregation
network, operators require = consistent methods to test and troubleshoot
connectivity for mixed Ethernet = and ATM access networks (including the
local loop). ANCP will allow a = remote procedure for a local loop
connectivity test to be = triggered from the NAS with results
communicated back to the NAS. =

4. Multicast
When multicast replication for = subscriber-bound traffic is performed at
the AN, it offloads the network = between the AN and NAS. However, a
subscriber's policy and = configuration for multicast traffic may only be
known at the NAS. ANCP will = provide a mechanism to communicate the
necessary information exchange = between the AN and NAS so as to allow
the AN to perform subscriber = bound multicast group replication in line
with the subscriber's policy and = configuration, and also allow the NAS
to follow each subscriber's = multicast group membership.

Non-Goals:

ANCP is an IP-based protocol that = operates between the AN and NAS,
over a broadband access and = aggregation network. It will not address setup
or configuration of circuits or = connections in the access and
aggregation network = itself.

The focus of this WG is on one = very specific application space. While
the design of the protocol must = be general as to not preclude other
uses in the future should a need = arise, it is not a goal of this WG
to address specific requirements = outside of broadband access and aggregation
networks.

Security:

The ANCP working group will = provide a threat analysis and address the
associated security aspects of = the control protocol.

Resiliency and Scalability: =

A graceful restart mechanism will = be defined to enable the protocol to
be resilient to network failures = between the AN and NAS.

Scalability at the NAS is of = primary concern, as it may be aggregating
traffic from a large number of = ANs, which in turn may be serving a
large number of Subscribers. = ANCP traffic should not become a denial
of service attack on the NAS = control plane. Format of messages,
pacing, transport over UDP or = TCP, etc. will be considered with this
in mind.

For reasons of aggregation = network scalability, some use cases require
that aspects of NAS or AN = functionality may be distributed in nodes in
the aggregation network. In = these cases, ANCP can run between these
nodes.

Deliverables:

The working group will define a = basic framework and requirements
document intended for = Informational publication, focusing on the four
use-cases outlined in this = charter. This document will include a
security threat analysis and = associated requirements. The WG will then
investigate and define a = solution for an IP based control protocol
meeting these requirements. =

There are early interoperable = implementations of an ANCP-like protocol
which are based on an extended = subset of the GSMPv3 protocol. This
running code will be the = starting point for the working group
solution, and will be abandoned = only if the WG determines it is not
adequate to meet requirements = going forward.

Coordination with other Working = Groups or Organizations:

The working group will coordinate = with the ADSL MIB working group so
the management framework and MIB = modules are consistent for DSL
access environments. The working = group will re-use, as far as
possible, standard MIB modules = that have already been defined.

The working group will coordinate = with the Broadband Forum to ensure that
ANCP meets the requirements of = broadband access networks.

The remote connectivity test use = case may require coordination with
ITU-T Ethernet OAM work, and = with IEEE 802.1ag.
Goals and Milestones:
Done      =       Accept WG I-D for ANCP Framework and = Requirements
Done      =       Accept WG I-D for Access Node Control = Protocol (ANCP)
Done      =       Accept WG ID for Security Threats = analysis
Done      =       Accept WG I-D for ANCP MIB
Done      =       Security Threats Analysis last call =
Mar 2008  =       ANCP MIB Last Call
Done    Framework and = Requirements last call
Mar = 2009        Accept WG I-D for = Additional Multicast Extensions
Mar = 2009        Accept WG I-D for ANCP = applicability to PON
Aug 2009   =      Access Node Control Protocol (ANCP) Last Call =
Dec = 2009        Additional Multicast = Extensions Last Call
Dec 2009  =       Re-charter or conclude Working Group =

------_=_NextPart_001_01C99112.8F0EE891-- From flefauch@cisco.com Tue Feb 17 08:37: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 1BB7F3A6A69 for ; Tue, 17 Feb 2009 08:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 EEdb3a0UboGY for ; Tue, 17 Feb 2009 08:37:25 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C38A73A69E9 for ; Tue, 17 Feb 2009 08:37:24 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,224,1233532800"; d="scan'208,217";a="34050570" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Feb 2009 16:37:26 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n1HGbNBN012097; Tue, 17 Feb 2009 17:37:23 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1HGbN93021903; Tue, 17 Feb 2009 16:37:23 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 17:37:23 +0100 Received: from [144.254.53.136] ([144.254.53.136]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 17:37:22 +0100 Message-Id: <6CBF6935-E835-40D6-8DF7-2EAB743840F2@cisco.com> From: Francois Le Faucheur IMAP To: BOCCI Matthew In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0358B9C8@FRVELSMBS11.ad2.ad.alcatel.com> Content-Type: multipart/alternative; boundary=Apple-Mail-36-1030886964 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 17 Feb 2009 17:37:20 +0100 References: <0458D2EE0C36744BABB36BE37805C29A0358B9C8@FRVELSMBS11.ad2.ad.alcatel.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 17 Feb 2009 16:37:22.0800 (UTC) FILETIME=[02281F00:01C9911E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2152; t=1234888643; x=1235752643; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20Time=20slots=20for=20San=20Fra ncisco |Sender:=20; bh=/xw1DdJ6q6DC9JBaUWBXHWgTh7C+hHAOeArNunLyNDM=; b=V/7k+6rZJ2Edhd/j2Xj9P7kHQOo7qrmKsndzo2I0yiiOtZgw5fukgupZlI sJdxk5x1ngZbtpeIKE9BMB2nqEQM3JeGuroDn/azzOw5GQIqFX7TvlyoM6zN /elp4K0kUr; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] Time slots for San Francisco 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, 17 Feb 2009 16:37:26 -0000 --Apple-Mail-36-1030886964 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Matthew, Can we have a slot for : * draft-lefaucheur-ancp-mc-extensions-01.txt The draft will be published before deadline. Thanks Francois On 17 Feb 2009, at 15:30, BOCCI Matthew wrote: > Folks, > > Please can you let me know if you would like a time slot for the > ANCP meeting in San Francisco.. Please let me know the subject you > would like to discuss and a pointer to the draft, if any. > > Thanks. > > Matthew > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --Apple-Mail-36-1030886964 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Matthew,

Can we have a slot for :
= * draft-lefaucheur-ancp-mc-extensions-01.txt

The draft will be published before = deadline.

Thanks

Francoi= s

On 17 Feb 2009, at 15:30, BOCCI Matthew = wrote:

Folks,

Please can you let me know if you would like a time slot = for the ANCP meeting in San Francisco.. Please let me know the subject = you would like to discuss and a pointer to the draft, if = any.

Thanks. =

Matthew

= _______________________________________________
ANCP mailing = list
ANCP@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ancp

= --Apple-Mail-36-1030886964-- From shrirao@cisco.com Wed Feb 18 22:28:09 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 3ED893A6951 for ; Wed, 18 Feb 2009 22:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 5eKG62tXrcyS for ; Wed, 18 Feb 2009 22:28:07 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B7FF53A67F6 for ; Wed, 18 Feb 2009 22:28:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,233,1233532800"; d="scan'208";a="252486407" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Feb 2009 06:28:20 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n1J6SKbf000960 for ; Wed, 18 Feb 2009 22:28:21 -0800 Received: from xbh-blr-411.apac.cisco.com (xbh-blr-411.cisco.com [64.104.140.150]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n1J6RsMx006984 for ; Thu, 19 Feb 2009 06:28:20 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Feb 2009 11:58:18 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Feb 2009 11:58:14 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Proposing that keep-alives be sent only from client Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAGO3PVABIdutYAAAJYi8AZxjWBAASTRWiA= References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com><7168964CAC5C144685272595141B6DBA019F1442@FRVELSMBS22.ad2.ad.alcatel.com> From: "Shridhar Rao (shrirao)" To: X-OriginalArrivalTime: 19 Feb 2009 06:28:18.0033 (UTC) FILETIME=[409AB610:01C9925B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2830; t=1235024901; x=1235888901; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shrirao@cisco.com; z=From:=20=22Shridhar=20Rao=20(shrirao)=22=20 |Subject:=20RE=3A=20[ANCP]=20Proposing=20that=20keep-alives =20be=20sent=20only=20from=20client |Sender:=20; bh=8PxLy01CNliI4Mnbt5XTcKRpMKptxK4Avi6x5LSMKdc=; b=d4aNfEyu42ay1yge8x53CPXsnl0pPh9ON4lIUTwcMqybQuUfIthLm7zKgh k7VJfFDvIzzyOG0+ytReAZpUkFjr8ZbZ0BlIJq9PZXqAprvUl43NvJ3Cem4K sLxG1OH2oF; Authentication-Results: sj-dkim-3; header.From=shrirao@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [ANCP] Proposing that keep-alives be sent only from client 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, 19 Feb 2009 06:28:09 -0000 Hi all, To make this proposal backwards compatible with older client/server implementations, I propose to add a new capability for exchanging the keep-alives.=20 Capability Type : Keep-alive-exchange-scheme =3D 0x06=20 Length (in bytes) : 4 Capability Data : =20 =09 0x01 : Only client sends Keep-alives 0x02 : No Keep alives are to be exchanged If this capability is not negotiated, then the default option is both ends send keep alives. Any end may send the above capability in it's adjacency message and if it is not acknowledged, then implementation that sent the capability will fall back to the default option. If stations are unable to agree on this capability, they will again fall back to the default method. If this option is negotiated as "0x02 =3D> No Keep alives are to be exchanged", then there is no need for any end to send Keep-alives and each station is free to choose any method to determine if the other end is down. One possible option is to use idle timer.=20 I also propose to change the timer granularity to seconds instead of 100 msec. To help scale even better, I propose to have a Hello-multiplier TLV. The TLV can be 8 bit integer that need not be negotiated but any end sends it to other end along with it's Hello interval time. We have seen very significant problems in maintaining ANCP adjacencies under high bandwidth conditions because Hellos are not delivered on time. We have also used the above schemes and discovered that it eliminates this problem. Thanks, -regards- =20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Shridhar Rao (shrirao) Sent: Sunday, January 11, 2009 9:04 PM To: ancp@ietf.org Subject: [ANCP] Proposing that keep-alives be sent only from client Hi all, Based on section 5.2 of ANCP protocol draft, both server and client have to send keep-alives. To help reduce the unnecessary message exchange between server and client and for a better utilization of bandwidth we are proposing that only client send the keep-alives and server just ack it.=20 The client side can assume that server is dead when it doesn't receive acknowledgements for 3 successive keep-alives and similarly server can assume client is not alive when it doesn't get 3 consecutive keep-alives on time. The code changes required for this from the current scheme of both ends sending keep-alives is very minimal (runs to few lines and is easy to implement). But if someone feels that we need to still retain the older scheme, then we can make this negotiable by introducing one more capability. regards, -shridhar- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From swadhwa@juniper.net Thu Feb 19 18:56:57 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 92A983A69DC for ; Thu, 19 Feb 2009 18:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Q6xTmh8hcktu for ; Thu, 19 Feb 2009 18:56:56 -0800 (PST) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id 2E0763A6B43 for ; Thu, 19 Feb 2009 18:56:56 -0800 (PST) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSZ4cBjWUdGBw4QTUoVF5Tkd7RXgYkDi+@postini.com; Thu, 19 Feb 2009 18:57:10 PST Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Thu, 19 Feb 2009 18:56:18 -0800 Received: from p-emsmtp03.jnpr.net ([66.129.254.54]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 18:56:18 -0800 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Feb 2009 18:56:17 -0800 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 19 Feb 2009 21:56:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Feb 2009 21:56:15 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C281A2CDA12@proton.jnpr.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Proposing that keep-alives be sent only from client Thread-Index: AclZLWi472QILb2YRiiUO7dT3wLrywAATJCQAADpsIAAnMNzcAGO3PVABIdutYAAAJYi8AfAEh3g References: <0458D2EE0C36744BABB36BE37805C29A03016CC2@FRVELSMBS11.ad2.ad.alcatel.com><7168964CAC5C144685272595141B6DBA019F1442@FRVELSMBS22.ad2.ad.alcatel.com> From: Sanjay Wadhwa To: "Shridhar Rao (shrirao)" , X-OriginalArrivalTime: 20 Feb 2009 02:56:16.0671 (UTC) FILETIME=[CC7EAAF0:01C99306] Subject: Re: [ANCP] Proposing that keep-alives be sent only from client 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, 20 Feb 2009 02:56:57 -0000 Hi Shridhar I don't quite see how the suggestion below lessens message exchange or improves utilization. It requires two messages each keep-alive interval (keep-alive and ACK). With what we have today in the draft, both AN & NAS send their own keep-alive message. Note that this is not an echo function i.e. no ACK is required. It is a single message in each direction generated asynchronously (i.e. still two messages each keep-alive cycle). The interval on either end can be configurable and the draft doesn't preclude asymmetric values. Each side retains controls of how long it takes for the other side to declare it dead on not seeing any activity. In your proposal the NAS has no control on this.=20 If indeed an echo behavior is desired, I would argue it should be bi-directional and independent in each direction, but that doubles the number of messages. Regards -Sanjay -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Shridhar Rao (shrirao) Sent: Sunday, January 11, 2009 10:34 AM To: ancp@ietf.org Subject: [ANCP] Proposing that keep-alives be sent only from client Hi all, Based on section 5.2 of ANCP protocol draft, both server and client have to send keep-alives. To help reduce the unnecessary message exchange between server and client and for a better utilization of bandwidth we are proposing that only client send the keep-alives and server just ack it.=20 The client side can assume that server is dead when it doesn't receive acknowledgements for 3 successive keep-alives and similarly server can assume client is not alive when it doesn't get 3 consecutive keep-alives on time. The code changes required for this from the current scheme of both ends sending keep-alives is very minimal (runs to few lines and is easy to implement). But if someone feels that we need to still retain the older scheme, then we can make this negotiable by introducing one more capability. regards, -shridhar- _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From Matthew.Bocci@alcatel-lucent.com Tue Feb 24 03:51:22 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 4F0B53A6849 for ; Tue, 24 Feb 2009 03:51:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 QvJVuJcNtKpV for ; Tue, 24 Feb 2009 03:51:21 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 4640E3A682A for ; Tue, 24 Feb 2009 03:51:21 -0800 (PST) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1OBpZ1H006205 for ; Tue, 24 Feb 2009 12:51:35 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Feb 2009 12:51:35 +0100 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_01C99676.3E32FC5F" Date: Tue, 24 Feb 2009 12:51:33 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A035E6CD8@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG Last Call for draft-ietf-ancp-security-threats-06.txt Thread-Index: AclZL5lCZTP0rH0tR1qIblTT8SftyQ9RoY6A From: "BOCCI Matthew" To: "BOCCI Matthew" , X-OriginalArrivalTime: 24 Feb 2009 11:51:35.0311 (UTC) FILETIME=[3E5931F0:01C99676] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [ANCP] WG Last Call for draft-ietf-ancp-security-threats-06.txt 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, 24 Feb 2009 11:51:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C99676.3E32FC5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This last call has now closed.=20 Since extensive review of the draft occurred earlier in the year, I will provide a document write-up to the list shortly. Matthew > _____________________________________________=20 > From: BOCCI Matthew =20 > Sent: 08 December 2008 12:22 > To: 'ancp@ietf.org' > Subject: WG Last Call for draft-ietf-ancp-security-threats-06.txt >=20 > This email is to start a two week working group last call for > draft-ietf-ancp-security-threats-06.txt > Please review and provide comments to the list by Monday 22nd > December. >=20 > Best regards, >=20 > Matthew >=20 >=20 ------_=_NextPart_001_01C99676.3E32FC5F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: WG Last Call for = draft-ietf-ancp-security-threats-06.txt

This last call has = now closed.

Since extensive = review of the draft occurred earlier in the year, I will provide a = document write-up to the list shortly.

Matthew

    _____________________________________________
    From:   BOCCI Matthew 
    Sent:   08 December 2008 12:22
    To:     'ancp@ietf.org'
    Subject:       = WG Last Call for = draft-ietf-ancp-security-threats-06.txt

    This email is to start a two week = working group last call for = draft-ietf-ancp-security-threats-06.txt
    Please review and provide comments to = the list by Monday 22nd December.

    Best regards,

    Matthew


------_=_NextPart_001_01C99676.3E32FC5F-- From Matthew.Bocci@alcatel-lucent.com Tue Feb 24 04:28:07 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 7671428C11B for ; Tue, 24 Feb 2009 04:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.124 X-Spam-Level: X-Spam-Status: No, score=-6.124 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 ljVIH6CFaw+Y for ; Tue, 24 Feb 2009 04:28:05 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 3E7E43A67A4 for ; Tue, 24 Feb 2009 04:28:05 -0800 (PST) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n1OCSJRR002526; Tue, 24 Feb 2009 13:28:19 +0100 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.31]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 24 Feb 2009 13:28:19 +0100 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_01C9967B.5FBEEF19" Date: Tue, 24 Feb 2009 13:28:16 +0100 Message-ID: <0458D2EE0C36744BABB36BE37805C29A035E6D25@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ancp-security-threats-analysis-06.txt PROTO statement Thread-Index: AcmWe15+3A5iDMImRQ+JqNvc5wvTOg== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 24 Feb 2009 12:28:19.0373 (UTC) FILETIME=[60125DD0:01C9967B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: [ANCP] draft-ietf-ancp-security-threats-analysis-06.txt PROTO statement 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, 24 Feb 2009 12:28:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9967B.5FBEEF19 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ancp-security-threats-06.txt Document Shepherd Write-Up (1.a) Who is the Document Shepherd for this document? Has the=20 Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 Matthew Bocci (matthew.bocci@alcatel-lucent.com) Yes, I have reviewed the document and I believe it is ready for=20 forwading to the IESG. (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed?=20 Yes, the document has received adequate review. The document=20 received in depth review from five reviewers nominated by the=20 WG, as well as comments during WG last call. =20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 No, although as it is a security threats analysis, close attention from the Security ADs would be appropriate. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director=20 and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 No specific concerns.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it?=20 I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. =20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 None indicated. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See=20 http://www.ietf.org/ID-Checklist.html and=20 http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 The document uses a per-5378 boilerplate because it was submitted prior to the change in boilerplate requirements. This is an informational security threats analysis, so was not subject to MIB doctor or other reviews.=20 (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 Yes, the references are split appropriately. There is one reference to the ANCP framework, that will need to be updated as both documents should be published together. (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations section exists and there are no requests=20 for IANA allocations. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 There are no sections that use a formal language. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 The Access Node Control Protocol (ANCP) aims to communicate QoS- related, service-related and subscriber-related configurations and operations between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)). The main goal of this protocol is to allow the NAS to configure, manage and control access equipments including the ability for the access nodes to report information to the NAS. The present document investigates security threats that all ANCP nodes could encounter. This document develops a threat model for ANCP security aiming to decide which security functions are required. Based on this, security requirements regarding the Access Node Control Protocol are defined. This document is a product of the ANCP working group. This document is INFORMATIONAL. ------_=_NextPart_001_01C9967B.5FBEEF19 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-ancp-security-threats-analysis-06.txt PROTO = statement

draft-ietf-ancp-security-threats-06.txt

Document Shepherd Write-Up


    (1.a) Who is the = Document Shepherd for this document? Has the
          = Document Shepherd personally reviewed this version of the
          = document and, in particular, does he or she believe this
          = version is ready for forwarding to the IESG for publication?

        Matthew Bocci (matthew.bocci@alcatel-lucent.com)
        Yes, I have = reviewed the document and I believe it is ready for
        forwading to = the IESG.


    (1.b) Has the = document had adequate review both from key WG members
          = and from key non-WG members? Does the Document Shepherd have
          = any concerns about the depth or breadth of the reviews that
          = have been performed?

        Yes, the = document has received adequate review. The document
        received in = depth review from five reviewers  nominated by the
        WG, as well as = comments during WG last call.
       


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

       = No, although as it is a security threats analysis, close = attention
       = from the Security ADs would be appropriate.


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

       No = specific concerns.


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

      I am = comfortable that the document represents WG consensus and has
      been = reviewed by a reasonable number of active WG participants.
 

    (1.f) Has anyone = threatened an appeal or otherwise indicated extreme
          = discontent? If so, please summarise the areas of conflict in
          = separate email messages to the Responsible Area Director. (It
          = should be in a separate email because this questionnaire is
          = entered into the ID Tracker.)

       = None indicated.


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


       = The document uses a per-5378 boilerplate because it was submitted = prior
       = to the change in boilerplate requirements.
       = This is an informational security threats analysis, so was not = subject
       = to MIB doctor or other reviews.

    (1.h) Has the = document split its references into normative and
          = informative? Are there normative references to documents that
          = are not ready for advancement or are otherwise in an unclear
          = state? If such normative references exist, what is the
          = strategy for their completion? Are there normative references
          = that are downward references, as described in [RFC3967]? If
          = so, list these downward references to support the Area
          = Director in the Last Call procedure for them [RFC3967].

      Yes, the = references are split appropriately. There is one reference
      to the = ANCP framework, that will need to be updated as both documents
      should = be published together.



    (1.i) Has the = Document Shepherd verified that the document IANA
          = consideration section exists and is consistent with the body
          of = the document? If the document specifies protocol
          = extensions, are reservations requested in appropriate IANA
          = registries? Are the IANA registries clearly identified? If
          = the document creates a new registry, does it define the
          = proposed initial contents of the registry and an allocation
          = procedure for future registrations? Does it suggest a
          = reasonable name for the new registry? See [RFC5226]. If the
          = document describes an Expert Review process has Shepherd
          = conferred with the Responsible Area Director so that the IESG
          = can appoint the needed Expert during the IESG Evaluation?

      The IANA = considerations section exists and there are no requests
      for = IANA allocations.


    (1.j) Has the = Document Shepherd verified that sections of the
          = document that are written in a formal language, such as XML
          = code, BNF rules, MIB definitions, etc., validate correctly in
          an = automated checker?

      There = are no sections that use a formal language.


    (1.k) The IESG = approval announcement includes a Document
          = Announcement Write-Up. Please provide such a Document
          = Announcement Write-Up? Recent examples can be found in the
          = "Action" announcements for approved documents. The approval =
          = announcement contains the following sections:

   The Access Node Control = Protocol (ANCP) aims to communicate QoS-
   related, service-related = and subscriber-related configurations and
   operations between a = Network Access Server (NAS) and an Access Node
   (e.g., a Digital = Subscriber Line Access Multiplexer (DSLAM)).  The
   main goal of this = protocol is to allow the NAS to configure, manage
   and control access = equipments including the ability for the access
   nodes to report = information to the NAS.
   The present document = investigates security threats that all ANCP
   nodes could = encounter.  This document develops a threat model for
   ANCP security aiming to = decide which security functions are required.
   Based on this, security = requirements regarding the Access Node
   Control Protocol are = defined.

   This document is a product = of the ANCP working group.

   This document is = INFORMATIONAL.


------_=_NextPart_001_01C9967B.5FBEEF19-- From roberta.maglione@telecomitalia.it Wed Feb 25 01:30:25 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 CE42F3A695E for ; Wed, 25 Feb 2009 01:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.14 X-Spam-Level: * X-Spam-Status: No, score=1.14 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 PONYPJ3azsYl for ; Wed, 25 Feb 2009 01:30:24 -0800 (PST) Received: from GRFEDG702RM001.telecomitalia.it (grfedg702rm001.telecomitalia.it [217.169.121.21]) by core3.amsl.com (Postfix) with ESMTP id 3D6BB3A697F for ; Wed, 25 Feb 2009 01:30:24 -0800 (PST) Received: from grfhub702rm001.griffon.local (10.19.3.9) by GRFEDG702RM001.telecomitalia.it (10.173.88.21) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 25 Feb 2009 10:29:04 +0100 Received: from GRFMBX702RM001.griffon.local ([10.19.3.19]) by grfhub702rm001.griffon.local ([10.19.9.235]) with mapi; Wed, 25 Feb 2009 10:30:41 +0100 From: Maglione Roberta To: "'Aniruddha A (anira)'" , "'matthew.bocci@alcatel.co.uk'" , "Wojciech Dec (wdec)" Date: Wed, 25 Feb 2009 10:30:40 +0100 Thread-Topic: ANCP messages for Multicast query and report Thread-Index: Acl03aoXUeqKXaQARgaXa0fvaISgPwiTA05g Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ancp@ietf.org" Subject: Re: [ANCP] ANCP messages for Multicast query and report 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, 25 Feb 2009 09:30:25 -0000 Hi Matthew & Woj, as the proposed ancp charter includes a separate WG item for Additional= Multicast Extensions, in case ancp working group approves Aniruddha's prop= osal about ANCP messages for Multicast query and report, I was wondering if= this work should be included in the ancp protocol draft or if it should g= o in a separate section of Additional Multicast Extensions draft. Thanks Regards, Roberta -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Ani= ruddha A (anira) Sent: Monday, January 12, 2009 6:46 PM To: ancp@ietf.org Subject: [ANCP] ANCP messages for Multicast query and report Hi all, In the ANCP multicast extensions, there has to be a way For the NAS to query the AN for the state of active multicast flows on it. We propose the following 2 new messages for this purpose: - Active-Flow Request - Active-Flow Report The query from the NAS can be for all flows on the AN or flows active on a single port. Message Type 0x92 is used. Description and message formats: Active-Flow Request Message The Active Flow Request message is sent by the NAS to the AN to request multicast flow status on the AN. The payload contains the following TLVs: o The Active-Flow-Req TLV (0x103) A Mandatory TLV. o The Target Type TLV. Optional TLV, if present, request is for a single port. On receiving the Active Flow Request message, the AN MUST respond with the Active Flow Report containing the requested information if the Multicast capability has been negotiated. The format of the message is shown below: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=3D0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 Active-Flow Report Message The Active Flow Report message is sent from the AN to the NAS in response to the Active Flow Request message. Active Flow Report message contains information on the requested multicast flows. The report can be for a single port, or all ports depending on the Target Type in the request. o Single Port Report If the Active Flow Request had a specific port (the presence of a Target Type TLV), the response has the following format: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ActiveFlowPortEntryTLV =3D0x105 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target-type-TLV=3D0x1000 | Target-TLV-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID type | Circuit ID Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Client-ID ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 Followed by the Multicast Flow ID TLVs (0x107), one for each flow on the port. The format of the Flow ID TLV is: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 S is the source flag, if set, multicast source address MUST be present (SSM). o Report for all ports If the Active Flow Request did not specify a specific port (no Target Type TLV), the response will have the following format: 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 |MsgType=3D0x92 | Res | Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Partition ID | Transaction Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I| SubMessage Number | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |ActiveFlowMcastEntryTLV =3D0x104 | ActiveFlow-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AddrFamily | EncType | Mcast group | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Followed by the Target Type TLV. A Multicast Entry TLV (0x104) determines the (flow, port), therefore it will have a Flow ID TLV and a Target-Type TLV as its sub TLVs, and there will be as many Multicast Entry TLVs as the number of flows on the AN. We have an implementation running with these message types. -- Regards, Aniruddha. A _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From wdec@cisco.com Wed Feb 25 03:08:41 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 CDFF128C0D0 for ; Wed, 25 Feb 2009 03:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 ZYcgWpc-y1pY for ; Wed, 25 Feb 2009 03:08:40 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id A94F93A6B73 for ; Wed, 25 Feb 2009 03:08:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,264,1233532800"; d="scan'208";a="34775617" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2009 11:08:58 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n1PB8wid006256; Wed, 25 Feb 2009 12:08:58 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n1PB8wPT017090; Wed, 25 Feb 2009 11:08:58 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Feb 2009 12:08:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Feb 2009 12:08:55 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP messages for Multicast query and report Thread-Index: Acl03aoXUeqKXaQARgaXa0fvaISgPwiTA05gAAPO6mA= References: From: "Wojciech Dec (wdec)" To: "Maglione Roberta" , "Aniruddha A (anira)" , X-OriginalArrivalTime: 25 Feb 2009 11:08:58.0596 (UTC) FILETIME=[74D73240:01C99739] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10050; t=1235560138; x=1236424138; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20messages=20for=20Multic ast=20query=20and=20report |Sender:=20; bh=K8SfuvCrwhVD1RfH37pJC9MYzEb/Ladl3/ZqIbc54ws=; b=AWTaXLZTOWjrHJjMvftPughF+rcCzQTt7jeg7W/E7JmxHicVG2x32lfCFB 2gTRbuXk+j1tjKjZOCjcSQht3PnqrhsCbR633wisHONx1O0Dm0wqMxqyrC2M hplDd+XNY4; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP messages for Multicast query and report 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, 25 Feb 2009 11:08:41 -0000 Hi Roberta,=20 We'll discuss this at the meeting. Last time round we arrived at the conclusion that the mcast extensions with which the WG had a good degree of comfort would be merged into the protocol spec, while the others progressed in the new id. Regards, Woj. > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 > Behalf Of Maglione Roberta > Sent: 25 February 2009 10:31 > To: Aniruddha A (anira); 'matthew.bocci@alcatel.co.uk';=20 > Wojciech Dec (wdec) > Cc: ancp@ietf.org > Subject: Re: [ANCP] ANCP messages for Multicast query and report >=20 > Hi Matthew & Woj, > as the proposed ancp charter includes a separate WG item=20 > for Additional Multicast Extensions, in case ancp working=20 > group approves Aniruddha's proposal about ANCP messages for=20 > Multicast query and report, I was wondering if this work=20 > should be included in the ancp protocol draft or if it=20 > should go in a separate section of Additional Multicast=20 > Extensions draft. > Thanks > Regards, > Roberta >=20 >=20 > -----Original Message----- > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On=20 > Behalf Of Aniruddha A (anira) > Sent: Monday, January 12, 2009 6:46 PM > To: ancp@ietf.org > Subject: [ANCP] ANCP messages for Multicast query and report >=20 > Hi all, >=20 > In the ANCP multicast extensions, there has to be a way For=20 > the NAS to query the AN for the state of active multicast flows on it. >=20 > We propose the following 2 new messages for this purpose: > - Active-Flow Request > - Active-Flow Report >=20 > The query from the NAS can be for all flows on the AN or=20 > flows active on a single port. Message Type 0x92 is used. >=20 > Description and message formats: >=20 > Active-Flow Request Message >=20 > The Active Flow Request message is sent by the NAS to the AN to > request multicast flow status on the AN. The payload contains the > following TLVs: >=20 > o The Active-Flow-Req TLV (0x103) > A Mandatory TLV. >=20 > o The Target Type TLV. > Optional TLV, if present, request is for a single port. >=20 > On receiving the Active Flow Request message, the AN MUST respond > with the Active Flow Report containing the requested information if > the Multicast capability has been negotiated. The format of the > message is shown below: >=20 > 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 |MsgType=3D0x92 | Res | Code = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ActiveFlowReq TLV =3D0x103 | ActiveFlow-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target-type-TLV=3D0x1000 | Target-TLV-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID type | Circuit ID Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Client-ID ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 1 >=20 > Active-Flow Report Message >=20 > The Active Flow Report message is sent from the AN to the NAS in > response to the Active Flow Request message. Active Flow Report > message contains information on the requested multicast flows. The > report can be for a single port, or all ports depending on=20 > the Target > Type in the request. >=20 > o Single Port Report >=20 > If the Active Flow Request had a specific port (the presence of a > Target Type TLV), the response has the following format: >=20 > 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 |MsgType=3D0x92 | Res | Code = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ActiveFlowPortEntryTLV =3D0x105 | ActiveFlow-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Target-type-TLV=3D0x1000 | Target-TLV-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ID type | Circuit ID Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Client-ID ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 2 >=20 > Followed by the Multicast Flow ID TLVs (0x107), one for=20 > each flow on > the port. The format of the Flow ID TLV is: >=20 > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily | EncType | Mcast source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily | EncType | Mcast group | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 3 >=20 > S is the source flag, if set, multicast source address MUST be > present (SSM). >=20 > o Report for all ports >=20 > If the Active Flow Request did not specify a specific port=20 > (no Target > Type TLV), the response will have the following format: >=20 > 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 |MsgType=3D0x92 | Res | Code = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |ActiveFlowMcastEntryTLV =3D0x104 | ActiveFlow-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Mcast Flow ID TLV =3D 0x107 |S| Mcast Flow ID-Length = | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily | EncType | Mcast source | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | AddrFamily | EncType | Mcast group | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Figure 4 >=20 > Followed by the Target Type TLV. >=20 > A Multicast Entry TLV (0x104) determines the (flow, port),=20 > therefore > it will have a Flow ID TLV and a Target-Type TLV as its=20 > sub TLVs, and > there will be as many Multicast Entry TLVs as the number=20 > of flows on > the AN. >=20 > We have an implementation running with these message types. > -- > Regards, > Aniruddha. A > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >=20 > Questo messaggio e i suoi allegati sono indirizzati=20 > esclusivamente alle persone indicate. La diffusione, copia o=20 > qualsiasi altra azione derivante dalla conoscenza di queste=20 > informazioni sono rigorosamente vietate. Qualora abbiate=20 > ricevuto questo documento per errore siete cortesemente=20 > pregati di darne immediata comunicazione al mittente e di=20 > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may=20 > contain privileged information intended for the addressee(s)=20 > only. Dissemination, copying, printing or use by anybody else=20 > is unauthorised. If you are not the intended recipient,=20 > please delete this message and any attachments and advise the=20 > sender by return e-mail, Thanks. >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp >=20 From tom.taylor@rogers.com Wed Feb 25 12:31:04 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 274C528C341 for ; Wed, 25 Feb 2009 12:31:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.939 X-Spam-Level: X-Spam-Status: No, score=-0.939 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_20=-0.74] 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 3gBm0DieScgQ for ; Wed, 25 Feb 2009 12:31:03 -0800 (PST) Received: from smtp123.rog.mail.re2.yahoo.com (smtp123.rog.mail.re2.yahoo.com [206.190.53.28]) by core3.amsl.com (Postfix) with SMTP id 20C0F28C2AF for ; Wed, 25 Feb 2009 12:31:03 -0800 (PST) Received: (qmail 22999 invoked from network); 25 Feb 2009 20:31:23 -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=jZRE0E6nu9KcW5uYR5X8fAa/6nSdnaBTjL+TkoDSDnulcStih9jYM4hstkGWIHOR7O7JzvhQKEh/6Oyka4pLK5SR2K9KXltYRk8Y32PHnHLz9zVKhLxalJhfpEgf04M3WvwqSgqn39D9H6TTLSfndYEGjiwFHYkcbSuwfOcQb+Q= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp123.rog.mail.re2.yahoo.com with SMTP; 25 Feb 2009 20:31:23 -0000 X-YMail-OSG: 9wnCM4MVM1nDmyL_RthhZW9.bvISg4XJkjTLIQrYsRiICGTlcjoHGfG3W7.Y63a_tw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A5AA9B.3000903@rogers.com> Date: Wed, 25 Feb 2009 15:31:23 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] Technology dependence in ANCP 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, 25 Feb 2009 20:31:04 -0000 This started out as a note on the use of Access-Loop-Circuit-Id TLV in the Port Management message and how that would evolve when we started working on PON. However, a bit of research indicated to me that we have fundamental problems extending the protocol in its current form to a new technology. The key difficulty is the definition of the Extension TLV in section 5.4.1.1 of the base protocol draft. According to this section: "The Message Type plus the Tech Value uniquely define a single Extension Type and can be treated as a single 16 bit extension type." That means that whatever extensions to the Port Management message we define for DSL have to be defined all over again for PON. Would it not make more sense to decouple the technology type from the extension type? Tom Taylor From tom.taylor@rogers.com Thu Feb 26 08:44:08 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 AE7163A6BD3 for ; Thu, 26 Feb 2009 08:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.983 X-Spam-Level: X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.616, 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 T0gXAWFVk4mn for ; Thu, 26 Feb 2009 08:44:07 -0800 (PST) Received: from smtp116.rog.mail.re2.yahoo.com (smtp116.rog.mail.re2.yahoo.com [68.142.225.232]) by core3.amsl.com (Postfix) with SMTP id E49AE3A6A65 for ; Thu, 26 Feb 2009 08:44:06 -0800 (PST) Received: (qmail 93569 invoked from network); 26 Feb 2009 16:44:28 -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=GKMzhU/QoyVh27CiERyf+FCvtfQts/tZsq922p3EMo2xOU7cUqMBvTAbWU3pjrIlWMzOpTep42cZPCuD8AkdN0uRdln/aMnPzFZfnGIMCAfa8VKb6cTeC4ZBM2VWLDcWOVDjeuPXYNtTTU8UHQ5T8u4zSnryiUnzCqWMNQdNATo= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp116.rog.mail.re2.yahoo.com with SMTP; 26 Feb 2009 16:44:28 -0000 X-YMail-OSG: uOuFrTsVM1kjPZiewmWwsgtxAgAw4wmuAHg03sFJ_F7uVf_upvMPo22ey0vWznNaiQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6C6EB.70400@rogers.com> Date: Thu, 26 Feb 2009 11:44:27 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: BOCCI Matthew References: <0458D2EE0C36744BABB36BE37805C29A0358BA21@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0358BA21@FRVELSMBS11.ad2.ad.alcatel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] Updates to ANCP charter 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, 26 Feb 2009 16:44:08 -0000 I'll express my support for the updated charter. I may have time before the deadline to do a survey of technology-specific aspects of the current protocol specification that need amendment to include PON. This would just be a working document, not intended to be a WG deliverable. Tom Taylor BOCCI Matthew wrote: > All > > There has been some interest shown in expanding the scope of ANCP to > include PON. However, our charter up until now has been pretty specific > about focussing on DSL. > > We would therefore like to propose some updates to the charter to allow > ANCP to develop extensions for other technologies apart from DSL. We > also need to revise our goals and milestones to reflect the latest > status of the multicast work. > > Please find attached a draft revised charter. Please can you post any > comments to the list by the end of the February to give us time to make > any updates before the next IETF. > > Best regards > > Matthew & Woj > > Description of Working Group: > > Purpose: > > The purpose of the ANCP WG is to standardize an IP based Access Node > Control Protocol (ANCP) for use in service provider broadband access and > aggregation > networks e.g. Digital Subscriber Line (DSL) and Passive Optical Network > (PON). ANCP operates between an > Access Node (AN) and Network Access Server (NAS). > > Necessary Terminology: > > Access Node (AN) - Network device, usually located at a service > provider central office or street cabinet, that terminates access loop > connections from Subscribers. In DSL, this is often referred to as a > Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is > usually comprised of an Optical Network Termination (ONT) and an Optical > Line Termination (OLT). > > Network Access Server (NAS) - Network device which aggregates > multiplexedSubscriber traffic from a number of Access Nodes. The NAS > plays a central role in per-subsciber policy enforcement and QoS. > Often referred to as a Broadband Network Gateway (BNG) or Broadband > Remote Access Server (BRAS). A detailed definition of the NAS is given > in RFC2881. > > Goals: > > ANCP is intended to address the requirement for a bidirectional, IP- > based, control protocol that operates across multiple types (i.e., > Ethernet, ATM) of DSL and PON access and aggregation networks. The goal > of an > ANCP message exchange is to convey status and control information > between one or more ANs and one or more NASs without going through > intermediate element managers. > > The ANCP WG will address the following four use-cases: > > 1. Dynamic Access Loop Attributes > Various queuing and scheduling mechanisms are used in access networks > to avoid congestion while dealing with multiple flows and distinct QoS > profiles. Communicating the access-loop status, attributes and current > DSL synchronization rate between the AN and Subscriber up to the NAS > is desirable, particularly when the NAS is providing QoS for > individual flows and subscribers. ANCP will provide a mechanism to > communicate dynamic access-loop attributes from the AN to the NAS. > > 2. Access Loop Configuration > In additional to reporting Access Loop characteristics from the AN to > the NAS, ANCP will allow a NAS to send loop-specific configuration > information to an AN based on the results of subscriber authentication > and authorization (e.g., after AAA responses have been received at the > NAS). > > 3. Remote Connectivity Test > Traditional DSL access and aggregation networks employ point-to-point > ATM circuits between the AN and NAS for each subscriber, allowing > troubleshooting of the local loop from the NAS via ATM OAM tools. With > the increasing deployment of Ethernet in the access and aggregation > network, operators require consistent methods to test and troubleshoot > connectivity for mixed Ethernet and ATM access networks (including the > local loop). ANCP will allow a remote procedure for a local loop > connectivity test to be triggered from the NAS with results > communicated back to the NAS. > > 4. Multicast > When multicast replication for subscriber-bound traffic is performed at > the AN, it offloads the network between the AN and NAS. However, a > subscriber's policy and configuration for multicast traffic may only be > known at the NAS. ANCP will provide a mechanism to communicate the > necessary information exchange between the AN and NAS so as to allow > the AN to perform subscriber bound multicast group replication in line > with the subscriber's policy and configuration, and also allow the NAS > to follow each subscriber's multicast group membership. > > Non-Goals: > > ANCP is an IP-based protocol that operates between the AN and NAS, > over a broadband access and aggregation network. It will not address > setup > or configuration of circuits or connections in the access and > aggregation network itself. > > The focus of this WG is on one very specific application space. While > the design of the protocol must be general as to not preclude other > uses in the future should a need arise, it is not a goal of this WG > to address specific requirements outside of broadband access and > aggregation > networks. > > Security: > > The ANCP working group will provide a threat analysis and address the > associated security aspects of the control protocol. > > Resiliency and Scalability: > > A graceful restart mechanism will be defined to enable the protocol to > be resilient to network failures between the AN and NAS. > > Scalability at the NAS is of primary concern, as it may be aggregating > traffic from a large number of ANs, which in turn may be serving a > large number of Subscribers. ANCP traffic should not become a denial > of service attack on the NAS control plane. Format of messages, > pacing, transport over UDP or TCP, etc. will be considered with this > in mind. > > For reasons of aggregation network scalability, some use cases require > that aspects of NAS or AN functionality may be distributed in nodes in > the aggregation network. In these cases, ANCP can run between these > nodes. > > Deliverables: > > The working group will define a basic framework and requirements > document intended for Informational publication, focusing on the four > use-cases outlined in this charter. This document will include a > security threat analysis and associated requirements. The WG will then > investigate and define a solution for an IP based control protocol > meeting these requirements. > > There are early interoperable implementations of an ANCP-like protocol > which are based on an extended subset of the GSMPv3 protocol. This > running code will be the starting point for the working group > solution, and will be abandoned only if the WG determines it is not > adequate to meet requirements going forward. > > Coordination with other Working Groups or Organizations: > > The working group will coordinate with the ADSL MIB working group so > the management framework and MIB modules are consistent for DSL > access environments. The working group will re-use, as far as > possible, standard MIB modules that have already been defined. > > The working group will coordinate with the Broadband Forum to ensure > that > ANCP meets the requirements of broadband access networks. > > The remote connectivity test use case may require coordination with > ITU-T Ethernet OAM work, and with IEEE 802.1ag. > Goals and Milestones: > Done Accept WG I-D for ANCP Framework and Requirements > Done Accept WG I-D for Access Node Control Protocol (ANCP) > Done Accept WG ID for Security Threats analysis > Done Accept WG I-D for ANCP MIB > Done Security Threats Analysis last call > Mar 2008 ANCP MIB Last Call > Done Framework and Requirements last call > Mar 2009 Accept WG I-D for Additional Multicast Extensions > Mar 2009 Accept WG I-D for ANCP applicability to PON > Aug 2009 Access Node Control Protocol (ANCP) Last Call > Dec 2009 Additional Multicast Extensions Last Call > Dec 2009 Re-charter or conclude Working Group > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From tom.taylor@rogers.com Thu Feb 26 08:48:13 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 10DA83A6A65 for ; Thu, 26 Feb 2009 08:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.034 X-Spam-Level: X-Spam-Status: No, score=-2.034 tagged_above=-999 required=5 tests=[AWL=0.565, 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 8umd5m0Dr-nT for ; Thu, 26 Feb 2009 08:48:12 -0800 (PST) Received: from smtp107.rog.mail.re2.yahoo.com (smtp107.rog.mail.re2.yahoo.com [68.142.225.205]) by core3.amsl.com (Postfix) with SMTP id 1DBAB3A692E for ; Thu, 26 Feb 2009 08:48:11 -0800 (PST) Received: (qmail 97669 invoked from network); 26 Feb 2009 16:48:33 -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=4hPnJlxTmaffOdND7Fl5MPoo3CYLOutnEjlbZp9fgl2uvFRmB4B+tbvxik0fmU2dyWKmAr00g7ubAzhrz4h4YqeezRUvnmiMh5IKjobXrhkXevI0RFEmpV/zn719nvfD/8CCoic2nXUJzxxvrsWuNvfBREG4Gu0XiX3l7ETlj5E= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp107.rog.mail.re2.yahoo.com with SMTP; 26 Feb 2009 16:48:33 -0000 X-YMail-OSG: xrbvlrYVM1n89mEK.wGpMoQEPKg6M.8YaeBAocmo6DHi5fE.iWG68YlhLB40Drlraw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6C7E0.4090200@rogers.com> Date: Thu, 26 Feb 2009 11:48:32 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] IANA Considerations in the protocol document 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, 26 Feb 2009 16:48:13 -0000 It's really time we got our registries defined and values assigned. Working on the multicast extensions document, I find it inconvenient not to have an up-to-date list of codepoint assignments. I can propose text for the IANA Considerations section of the base protocol document if the design team can't do it. Tom taylor From tom.taylor@rogers.com Thu Feb 26 09: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 1834E3A6838 for ; Thu, 26 Feb 2009 09:21:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[AWL=0.521, 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 nqghViH-drjK for ; Thu, 26 Feb 2009 09:21:25 -0800 (PST) Received: from smtp108.rog.mail.re2.yahoo.com (smtp108.rog.mail.re2.yahoo.com [68.142.225.206]) by core3.amsl.com (Postfix) with SMTP id 0E9F53A67B6 for ; Thu, 26 Feb 2009 09:21:24 -0800 (PST) Received: (qmail 28767 invoked from network); 26 Feb 2009 17:21:46 -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=o1AOZv99cf3cjZdJJQhZBd6N599Hbt+CW4Zx6XU1ln6kXNHxXYPYlP8V5JdLkWNlPuj6Dv+wEXlg6xXqX97eG5xAIsG9gC4U32SyRpReGN/Ij5sOGHmQvrUb6a6enCB2qHxVXu/JV35BqRGAt4P4Gb8SouwNANMxcqFULsp1auw= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp108.rog.mail.re2.yahoo.com with SMTP; 26 Feb 2009 17:21:46 -0000 X-YMail-OSG: 0SJytVMVM1mrNTMMSFsCRzTIbaCQ.qobvWBTw4Us3RbE6wtaJrMkicAL0jMb25WQSQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6CFA9.4020908@rogers.com> Date: Thu, 26 Feb 2009 12:21:45 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ancp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ANCP] Definition of codepoints in Code header field 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, 26 Feb 2009 17:21:26 -0000 It isn't clear to me from the current base protocol specification whether codepoints for the Code header field can be defined on an individual message basis or must be coordinated across all messages. Could this be clarified? Tom Taylor From tom.taylor@rogers.com Thu Feb 26 09:47:46 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 404EC3A6830 for ; Thu, 26 Feb 2009 09:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 yULa-TyT1xA7 for ; Thu, 26 Feb 2009 09:47:45 -0800 (PST) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id 4B82B3A699E for ; Thu, 26 Feb 2009 09:47:45 -0800 (PST) Received: (qmail 85544 invoked from network); 26 Feb 2009 17:48:06 -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=4Ry+8ZKPOvS0/BG46EKs29LdLotyDMXJ/hH5gj9Ry0QHbGE5gq52s/CNAdTHqBeHkstwCw5DmzQ+DSBmP/8bfShCr2W7L7pQHTB6KwKfUn/aAz76TzMN1GT9cohAy9TPGA+tXYTzH8uZVLv/AevbHlwQh/7RpCTlEx16dJ12jLk= ; Received: from unknown (HELO ?192.168.0.101?) (tom.taylor@72.140.46.24 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 26 Feb 2009 17:48:06 -0000 X-YMail-OSG: TOpqt.UVM1kD7jS8HzKcEC32l9E8xrjCK87DmdSwWkD5akVR86VimRDTLqT87sDofw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49A6D5D6.2080907@rogers.com> Date: Thu, 26 Feb 2009 12:48:06 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: ancp@ietf.org References: <49A6CFA9.4020908@rogers.com> In-Reply-To: <49A6CFA9.4020908@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [ANCP] Definition of codepoints in Code header field 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, 26 Feb 2009 17:47:46 -0000 I should say that RFC 3292 defines these code points and established the registry: "Failure Response Message Names". This should be mentioned in the description of the Code field in section 5 of the base ANCP protocol specification. Tom Taylor wrote: > It isn't clear to me from the current base protocol specification > whether codepoints for the Code header field can be defined on an > individual message basis or must be coordinated across all messages. > Could this be clarified? > > Tom Taylor > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > From xiayangsong@huawei.com Sat Feb 28 09:41: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 0FF3C28C0EA for ; Sat, 28 Feb 2009 09:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, STOX_REPLY_TYPE=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 Ebt4zlZb9IBu for ; Sat, 28 Feb 2009 09:41:10 -0800 (PST) Received: from nlpi101.prodigy.net (nlpi101.prodigy.net [207.115.36.117]) by core3.amsl.com (Postfix) with ESMTP id 3F5903A69B2 for ; Sat, 28 Feb 2009 09:41:10 -0800 (PST) X-ORBL: [70.242.114.191] Received: from X24512z (ppp-70-242-114-191.dsl.rcsntx.swbell.net [70.242.114.191]) by nlpi101.prodigy.net (8.13.8 out.ldap.dk.spool/8.13.8) with ESMTP id n1SHfWqE029099 for ; Sat, 28 Feb 2009 11:41:33 -0600 Message-ID: <014201c999cb$cb814fb0$0201a8c0@china.huawei.com> From: "Frank Xia" To: Date: Sat, 28 Feb 2009 11:41:32 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Subject: [ANCP] Access Node Control Protocol for Source Adress Validation 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: Sat, 28 Feb 2009 17:41:11 -0000 Hi Folks We just submitted the draft http://www.ietf.org/internet-drafts/draft-kaippallimalil-ancp-sav-00.txt Comments are most welcome. BR Frank ----- Original Message ----- From: "IETF I-D Submission Tool" To: Cc: Sent: Saturday, February 28, 2009 11:24 AM Subject: New Version Notification for draft-kaippallimalil-ancp-sav-00 A new version of I-D, draft-kaippallimalil-ancp-sav-00.txt has been successfuly submitted by Frank Xia and posted to the IETF repository. Filename: draft-kaippallimalil-ancp-sav Revision: 00 Title: Access Node Control Protocol for Source Adress Validation Creation_date: 2009-02-28 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document specifies an extension of Access Node Control Protocol to provide source address validation for IPv4 and IPv6 networks. An access router uses the proposed mechanism to provision source address validation states on a layer 2 device which a host may directly connects to. The solution proposed here can be used in either public access networks or enterprise networks. The IETF Secretariat.