From tom.taylor@huawei.com Sat Jan 1 19:21:35 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9C533A6978 for ; Sat, 1 Jan 2011 19:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.009 X-Spam-Level: X-Spam-Status: No, score=-1.009 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYotHFmf4-7l for ; Sat, 1 Jan 2011 19:21:35 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 021CC3A696E for ; Sat, 1 Jan 2011 19:21:35 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LED00KGCLF7EV@szxga05-in.huawei.com> for ancp@ietf.org; Sun, 02 Jan 2011 11:23:31 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LED00I7ULF6R9@szxga05-in.huawei.com> for ancp@ietf.org; Sun, 02 Jan 2011 11:23:31 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LED00COQLF5VW@szxml01-in.huawei.com> for ancp@ietf.org; Sun, 02 Jan 2011 11:23:30 +0800 (CST) Date: Sat, 01 Jan 2011 22:23:31 -0500 From: Tom Taylor To: "ancp@ietf.org" Message-id: <4D1FEFB3.2020609@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Subject: [ANCP] Security issues 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: Sun, 02 Jan 2011 03:21:36 -0000 I'm almost done the revision of the base protocol document, just expanding the Security Considerations section. So far I have concluded: 1.The protocol is extremely vulnerable to attacks on the underlying TCP session. Loss of the TCP session appears to imply that the adjacency has to be reestablished, and generally, unless one wants to live dangerously, that all the AN state has to be cleared down and reestablished. I'm still studying the issue, but we probably need to prescribe use of either IPSEC or the TCP Authentication Option [RFC 5925] as well as TLS. One uses RFC 5925 in preference to IPSEC for operational reasons which probably don't apply, or because it is important to protect individual TCP connections with separate keys, which may apply. Can we envision multiple TCP connections over the same link between the AN and NAS? I assume user traffic would be on separate links, but would there be management operations (SNMP, whatever) over the same link as ANCP, requiring separate authentication keys? 2. We recommend a per-line rate-limiting mechanism for the sending of Port Up/Port Down messages. How about making that a general limit on message rates for individual lines to limit the IGMP-based DoS attacks identified in RFC 5713 and any similar attacks people could come up with? Tom Taylor From tom.taylor@huawei.com Sun Jan 2 18:15:19 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D9728C0EF for ; Sun, 2 Jan 2011 18:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=1.516, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3MaJdEBKB5E for ; Sun, 2 Jan 2011 18:15:19 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id CFC2828C0EB for ; Sun, 2 Jan 2011 18:15:18 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEF0000UD0RQK@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:17:15 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEF00MEBD0RZR@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:17:15 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEF00HICD0P4A@szxml01-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:17:15 +0800 (CST) Date: Sun, 02 Jan 2011 21:17:16 -0500 From: Tom Taylor To: "ancp@ietf.org" Message-id: <4D2131AC.3000502@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Subject: [ANCP] More thoughts on security 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, 03 Jan 2011 02:15:19 -0000 Rereading the IPsec [RFC4301] and IKEv2 [RFC5992] documentation and comparing it with our [RFC5713] security requirements, it becomes fairly clear that IPsec ESP + IKEv2 will do everything we need without bothering with TLS. I'm going ahead on that assumption, pending list discussion. I'd like to get an updated document out ASAP so people can let me know if I've gone astray. Tom Taylor From tom.taylor@huawei.com Sun Jan 2 18:15:37 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9C528C0F1 for ; Sun, 2 Jan 2011 18:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.063 X-Spam-Level: X-Spam-Status: No, score=-3.063 tagged_above=-999 required=5 tests=[AWL=1.432, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsRejd33Ihmc for ; Sun, 2 Jan 2011 18:15:36 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 017BD28C0EF for ; Sun, 2 Jan 2011 18:15:36 -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 <0LEF00IC2D16EC@szxga04-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:17:30 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEF004DND16LG@szxga04-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:17:30 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEF00HIND144A@szxml01-in.huawei.com>; Mon, 03 Jan 2011 10:17:30 +0800 (CST) Date: Sun, 02 Jan 2011 21:17:31 -0500 From: Tom Taylor In-reply-to: <05B6A5C4AE3BDA4EB276DB70EB548BA30E09F4B9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> To: "DE CNODDER, STEFAAN (STEFAAN)" Message-id: <4D2131BB.60707@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: <05B6A5C4AE3BDA4EB276DB70EB548BA30E09F4B9@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> Cc: "ancp@ietf.org" Subject: Re: [ANCP] comments on -12 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, 03 Jan 2011 02:15:37 -0000 Having finished the update at last, I need to re-answer the reviews with what is now in place. Thanks again for your comments. On 22/09/2010 2:16 PM, DE CNODDER, STEFAAN (STEFAAN) wrote: > Hi Tom, > > Below some comments on draft-ietf-ancp-protocol-12, I hope they are useful. > > Regards, > Stefaan > > > - Section 4.5.2 says that the pType field should be set to zero (No Partition). I guess that is wrong because it has to contain the partition id? [PTT] The pType field actually says how the PartionID is negotiated, rather than giving its value. Here is the updated text for pType: "The pType field MAY be set to 0 (No Partition) or another value depending on local configuration." > - Section 4.6.2 says that if the recipient of a message does not understand a particular TLV, it must silently ignore it, but on the other hand there is a code defined "84 TLV not supported". So must an unknown TLV be ignored, or should a failure be returned with this error code? [PTT] Deleted the error code. > - Tech type has been removed in the adjacency (see note in section 4.5.1, btw, better to remove that note in the RFC version), but not in the other messages. Is that the intention? Should it not be better to make the Techtype field "reserved"? [PTT] I left Tech Type in the Port Up/Down message because it may be useful. It has been changed to Reserved in the Port Management message and text has been added explaining how Port Management can be used for other capabilities and technologies. One issue is that the access line identifiers specified in the base document may not apply to non-DSL technologies. > - In section 5.2.3.1 I find it a bit confusing that it says "MUST support the following ANCP protocol elements, while some TLVs are mandatory. The wording does not look correct to me. The same comment applies to the other use cases. In that same section, capability type should be 0x0001 instead of 0x01 [PTT] Rewritten according to the resolution agreed on the list. Fixed the capability type values. > - Figure 8, 13 and 16 have a typo in the ANCP general message header: should refer to section 4.6 instead of 4.4 [PTT] Fixed. > - Section 5.2.3.3.3: In case a DSLAM is directly connected to the NAS, a single VLAN can be used, so this should also be covered, e.g, Length could be set to 4 if only 1 VLAN, or keep it to 8 and set outer VLAN to 0. [PTT] Done. I chose this method because I didn't know if there was any otherwise forbidden value of VLAN identifier to usae as a null entry. > - Section 5.2.3.3.4: The text implies that the NAS must be able to parse the text string while the format of it is not a MUST, but is just a typical format. I would just remove this TLV. The VLANs are known from the previous TLV. What if the uplink is a link aggregate? What if the uplink changes? These things are not covered. [PTT] I think that has been addressed by leaving it all up to the control application. I gave references for formats in an informational section, but not the actual formats themselves. > - No Iana for DSL-Type TLV? I would also rename "UNKNOWN" into "OTHER" because the DSL-type is always known by the DSLAM, and you might give it a value 0 or 0xffffffff. [PTT] DSL-Type is there. 0x0091. UNKNOWN changed to OTHER. Gave it value 0. > - According to figure 13, the # of TLV field is 15 bits, and the extension block length field is 17 bits. I believe it should be 16 bits each. [PTT] Fixed. > - Section 5.3.3.3: A "MUST" in combination with "depending upon the deployment scenario" is quite vague. I do not see immediately when which TLV is used. Could this be made more formal and when which TLV to be used? [PTT] Fixed by the rewrite. It's all up to the control application now, although I do describe informatively what that application has to consider. > > From tom.taylor@huawei.com Sun Jan 2 18:16:12 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C60BC28C0FA for ; Sun, 2 Jan 2011 18:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SR6OqBKLgMc for ; Sun, 2 Jan 2011 18:16:10 -0800 (PST) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D697C28C0EB for ; Sun, 2 Jan 2011 18:16:09 -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 <0LEF00IU6D26YQ@szxga04-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:18:06 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEF00MLED1ZFC@szxga04-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:18:06 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEF00HJ2D1X4A@szxml01-in.huawei.com>; Mon, 03 Jan 2011 10:18:00 +0800 (CST) Date: Sun, 02 Jan 2011 21:18:00 -0500 From: Tom Taylor In-reply-to: <030F37126795E34DB4796609C4FEAA4A1284589757@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> To: "Bocci, Matthew (Matthew)" Message-id: <4D2131D8.4020209@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: <030F37126795E34DB4796609C4FEAA4A1284589757@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> Cc: "Wadhwa, Sanjay \(Sanjay\)" , "draft-ieft-ancp-protocol@tools.ietf.org" , "ancp@ietf.org" Subject: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.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: Mon, 03 Jan 2011 02:16:12 -0000 Thanks once again for your comments. My dispositions indicated below. On 05/10/2010 10:16 AM, Bocci, Matthew (Matthew) wrote: > Authors, > > As a part of my role as shepherd for the ANCP protocol draft, I have reviewed it and provide comments in the attached. Many of these are just editorial, but some also pertain to, and probably overlap with the other comments that have been provided so far regarding clarification of what is mandatory and what is optional. > > My comments are prefixed by 'MB>'. > > Please can you address these comments in an new version of the draft before I forward to the IESG for publication. > > Best regards > > Matthew > > ------------------------------------------------------ > > > > > Network Working Group S. Wadhwa > Internet-Draft J. Moisand > Intended status: Standards Track Juniper Networks > Expires: February 25, 2011 T. Haag > Deutsche Telekom > N. Voigt > Nokia Siemens Networks > T. Taylor, Ed. > Huawei Technologies > August 24, 2010 > > MB> Please update Sanjay's affiliation to Alcatel-Lucent [PTT] Done. > ... > > 2.1. Terminology > > Access Node (AN): Network device, usually located at a service > provider central office or street cabinet that terminates access > (local) loop connections from subscribers. In case the access > loop is a Digital Subscriber Line (DSL), the Access Node provides > DSL signal termination, and is referred to as a DSL Access > Multiplexer (DSLAM). > > Network Access Server (NAS): Network element which aggregates > subscriber traffic from a number of Access Nodes. The NAS is an > injection point for policy management and IP QoS in the access > ^^^^^^^^^ > MB> I would suggest using ther term 'enforcement' rather than 'injection'. [PTT] Done. > > network. It is also referred to as a Broadband Network Gateway > (BNG) or Broadband Remote Access Server (BRAS). > > > Home Gateway (HGW): Network element that connects subscriber devices > to the Access Node and the access network. In the case of DSL, > the Home Gateway is a DSL network termination that may operate > either as a layer 2 bridge or as a layer 3 router. In the latter > case, such a device is also referred to as a Routing Gateway (RG). > > Net Data Rate: portion of the total data rate of the DSL line that > can be used to transmit actual user information (e.g. ATM cells > of Ethernet frames). It excludes overhead that pertains to the > ^^ > MB>s/of/or > [PTT] Done. > physical transmission mechanism (e.g. trellis coding in case of > > > > Wadhwa, et al. Expires February 25, 2011 [Page 6] > > Internet-Draft ANCP Protocol August 2010 > > > DSL). This is defined in section 3.39 of ITU-T G.993.2. > > DSL line (synch) rate: the total data rate of the DSL line, > including the overhead attributable to the physical transmission > mechanism. > > DSL multi-pair bonding: method for bonding (or aggregating) multiple > xDSL lines into a single bi-directional logical link, henceforth > referred to in this draft as "DSL bonded circuit". DSL "multi- > pair" bonding allows an operator to combine the data rates on two > or more copper pairs, and deliver the aggregate data rate to a > single customer. ITU-T recommendations G.998.1 and G.998.2 > respectively describe ATM and Ethernet based multi-pair bonding. > > Type-Length-Value (TLV): a data structure consisting of a sixteen- > bit type field, a sixteen-bit length field, and a variable-length > value field padded to the nearest 32-bit word boundary, as > described in Section 4.6.2. The value field of a TLV can contain > other TLVs. An IANA registry is maintained for values of the ANCP > TLV Type field. > > ANCP Protocol Capability: A detailed specification of ANCP messages, > message content, and procedures required to implement a specific > use case or set of use cases. ANCP capabilities may be specific > to one access technology or technology independent. The set of > capabilities applicable to a given ANCP session are negotiated > during session startup. > > ANCP session (also called an adjacency): A session between a NAS and > an Access Node, beginning with the initiation of the transport > connection by the AN, passing through adjacency negotiation, > discovery and provisioning stages, and continuing with service > control and possible OAM operations until the transport connection > is terminated. There may be more than one ANCP session active > between the NAS and a given AN due to partitioning. > > MB> Please add formal references to the ITU-T Recommendations mentioned above. [PTT] Done. > > 3. Broadband Access Aggregation > > 3.1. ATM-based broadband aggregation > > The end to end DSL network consists of network service provider (NSP) > and application service provider (ASP) networks, regional/access > network, and customer premises network. Figure 1 shows ATM broadband > access network components. > > The regional/access network consists of the regional network, Network > Access Server (NAS), and the access network as shown in Figure 1. > > > > Wadhwa, et al. Expires February 25, 2011 [Page 7] > > Internet-Draft ANCP Protocol August 2010 > > > Its primary function is to provide end-to-end transport between the > customer premises and the NSP or ASP. > > The Access Node terminates the DSL signal. It may be in the form of > a DSLAM in the central office, or a remote DSLAM, or a Remote Access > Multiplexer (RAM). The Access Node is the first point in the network > where traffic on multiple DSL lines will be aggregated onto a single > network. > > The NAS performs multiple functions in the network. The NAS is the > aggregation point for subscriber traffic. It provides aggregation > capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network > and the NSP or ASP. These include traditional ATM-based offerings > and newer, more native IP-based services. This includes support for > Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet > (PPPoE), as well as direct IP services encapsulated over an > appropriate layer 2 transport. > > Beyond aggregation, the NAS is also the injection point for policy > ^^^^^^^^^ > MB> enforcement? > [PTT] Done. > management and IP QoS in the regional/access networks. To allow IP > QoS support over an existing non-IP-aware layer 2 access network > without using multiple layer 2 QoS classes, a mechanism based on > hierarchical scheduling is used. This mechanism, defined in > [TR_059], preserves IP QoS over the ATM network between the NAS and > the routing gateway (RG) at the edge of the subscriber network, by > carefully controlling downstream traffic in the NAS, so that > significant queuing and congestion does not occur further down the > ATM network. This is achieved by using a diffserv-aware hierarchical > scheduler in the NAS that will account for downstream trunk > bandwidths and DSL synch rates. > > [RFC5851] provides detailed definition and functions of each network > element in the broadband reference architecture. > > > > > > > > > > > > > > > > > > > Wadhwa, et al. Expires February 25, 2011 [Page 8] > > Internet-Draft ANCP Protocol August 2010 > > > Access Customer > <--- Aggregation --> <------- Premises -------> > Network Network > > +------------------+ +--------------------------+ > +---------+ +---+ | +-----+ +------+ | |+-----+ +---+ +---------+ | > NSP| | +-|NAS|-| |ATM |-|Access| --||DSL |-|HGW|-|Subscriber|| > ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices || > |Broadband| | +---+ | +------+ | |+-----+ +----------+| > ASP|Network |-+-|NAS| +--------------|---+ +--------------------------+ > ---+ | | +---+ | +--------------------------+ > | | | +---+ | |+-----+ +---+ +----------+| > +---------+ +-|NAS| +-----|| DSL |-|HGW|-|Subscriber|| > +---+ ||Modem| +---+ |Devices || > |+-----+ +----------+| > +--------------------------+ > HGW : Home Gateway > NAS : Network Access Server > > > Figure 1: ATM Broadband Aggregation Topology > > 3.2. Ethernet-based broadband aggregation > > The Ethernet aggregation network architecture builds on the Ethernet > bridging/switching concepts defined in IEEE 802. The Ethernet > aggregation network provides traffic aggregation, class of service > distinction, and customer separation and traceability. VLAN tagging > defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as > standard virtualization mechanism in the Ethernet aggregation > network. The aggregation devices are "provider edge bridges" defined > in IEEE 802.ad. > > Stacked VLAN tags provide one possible way to create equivalent of > "virtual paths" and "virtual circuits" in the aggregation network. > The "outer" vlan can be used to create a form of "virtual path" > between a given DSLAM and a given NAS. "Inner" VLAN tags create a > form of "virtual circuit" on a per DSL line basis. This is the 1:1 > VLAN allocation model. An alternative model is to bridge sessions > from multiple subscribers behind a DSLAM into a single VLAN in the > aggregation network. This is the N:1 VLAN allocation model. > Architectural and topological models of an Ethernet aggregation > network in context of DSL aggregation are defined in [TR_101]. > > MB> Please add specific references to the Ethernet concepts described above. > [PTT] Replaced the final sentence with: "Section 1.6 of provides brief definitions of these two models, while section 2.5.1 describes them in more detail." ... > > 4.5.2. ANCP Adjacency Procedures > > The NAS MUST set the M-flag in the SYN message (signifying it is the > master). Once the adjacency is established, periodic adjacency > messages (type ACK) MUST be exchanged. The default for the ACK > interval to be advertised in the adjacency messages is 25 seconds for > ANCP. The actual value SHOULD be configurable and is an > implementation choice. It is RECOMMENDED that both ends specify the > ^^^^^^^^^^^^^^ > MB> If it is configurable, then it is a deployment choice rather than an > implementation choice. > [PTT] Fixed as suggested. > > > Wadhwa, et al. Expires February 25, 2011 [Page 15] > > Internet-Draft ANCP Protocol August 2010 > > > same timer value; to achieve this, each end SHOULD compare the timer > value in the first adjacency message it receives with its own > preferred value and agree to use the higher of the two values. That > is, the node that receives a higher timer value than its own SHOULD > reply in its subsequent adjacency messages (such as SYNACK, ACK) with > the higher timer value. > > In the adjacency protocol the version and sub-version fields are used > for version negotiation. The version negotiation is performed before > synchronisation is achieved. In a SYN message the version/ > sub-version fields always contain the highest version understood by > the sender. A receiver receiving a SYN message with a version/ > sub-version higher than it understands MUST silently discard that > message. A receiver receiving a SYN message with a version/ > sub-version within the range of versions that it understands MUST > reply with a SYNACK with the version/sub- version from the received > SYN in its ANCP version/sub-version fields. This defines the > version/sub-version of the ANCP protocol to be used while the > adjacency remains synchronised. All other ANCP messages within the > session MUST use the agreed version in the version/sub-version > fields. > > The semantics and suggested values for the Code, Sender Name, > Receiver Name, Sender Instance, and Receiver Instance fields are as > defined in Section 11 of [RFC3292]. The Sender Port, and Receiver > Port SHOULD be set to 0 by both ends. The pType field SHOULD be set > to 0 (No Partition). The pFlag SHOULD be set to 1 (New Adjacency). > > If the adjacency times out on either end, due to not receiving an > adjacency message for a duration of (3 * Timer value), where the > timer value is specified in the adjacency message, all the state > received from the ANCP neighbor SHOULD be cleaned up, and the TCP > connection SHOULD be closed. The NAS MUST continue to listen for new > connection requests. The AN MUST try to re-establish the TCP > connection and both sides MUST attempt to re-establish the adjacency. > > The handling defined above will need some modifications when ANCP > graceful restart procedures are defined. These procedures will be > defined in a separate document. > > MB> The above paragraph should be removed as we do not currently have an > MB> active GR draft. It is up to any future GR document to state > MB> whether it modifies/updates the procedures in this document. > [PTT] Done. > Both the NAS and the Access Node MUST advertise supported > capabilities in the adjacency messages they send. The same message > MAY advertise capabilities for any mixture of access technologies. > If a received adjacency message indicates no support for a capability > that is supported by the receiving device, it MUST turn off the > ^^^^^^^^ > MB> disable? > [PTT] Done. > capability locally and MUST send an updated adjacency message with > the corresponding capability field omitted to match the received > capability set. This process will eventually result in both sides > > > > Wadhwa, et al. Expires February 25, 2011 [Page 16] > > Internet-Draft ANCP Protocol August 2010 > > > agreeing on the maximal common set of supported capabilities. The > adjacency MUST NOT come up if that common set is empty. > > After initial synchronization, if at any time a capability mismatch > is detected, the adjacency MUST be brought down (RSTACK MUST be > generated by the device detecting the mismatch), and synchronization > MUST be re-attempted. > > 4.6. ANCP General Message Formats > > This section describes the general format of ANCP messages other than > the adjacency messages. > > The GSMPv3 general message format, used by all GSMP messages other > than adjacency protocol messages, is defined in Section 3.1.1 of > GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format as > shown in Figure 5. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Message Payload ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 5: ANCP General Message Format > > 4.6.1. The ANCP Message Header > > MB> A geneal comment on this section: > - Please clarify what is mandatory and what is optional. e.g. > It is unclear whether a sender MUST support result codes, and what > a receiver MUST do with them. Are they just logged in a MIB, or somehting else? > Please calrify, > [PTT] As far as general support, you'll find the "MUSTs" in the descriptions of the individual messages. Example from the documentation of the Provisioning message: "The message header field settings given below are REQUIRED in the Provisioning message. The remaining message header fields MUST be set as specified in Section 3.6.1." As you know, the documentation of Code values has been much expanded. > The immediately visible differences from GSMPv3 are the subdivision > of the Version field into version and sub-version, and the > reallocation of space between Result and Code to enlarge the range > for Code. The 8-bit version field in the base GSMPv3 message header > is split into two 4 bit fields for carrying the version and a sub- > version of the ANCP protocol. The Result field in the message header > has been modified to be 4 bits long, and the Code field to be 12 bits > long. > > A complete explanation of the header fields is as follows: > > > > Wadhwa, et al. Expires February 25, 2011 [Page 17] > > Internet-Draft ANCP Protocol August 2010 > > > Version and Sub-version: The version of the ANCP protocol that was > agreed for the session during adjacency negotiation. For the > values that must be placed into these fields, see Section 4.1. > > Message Type: The ANCP message type. Message type values are > registered in a common GSMPv3/ANCP IANA registry. > > Result: The Result field is derived from GSMPv3 [RFC3292]. Ignore > (0x0) is a new value added by ANCP. The remaining Result values > below are a subset of those defined for GSMPv3. GSMPv3 expected > the sender of a request to choose between NAck (0x1) and AckAll > (0x2) according to its needs. ANCP specifies what Result value > each request should have. Responses indicate either Success (0x3) > or Failure (0x4) as the case may be. > > Ignore: Res = 0x0 - Ignore this field on receipt and follow the > procedures specified for the received message type. > > Nack: Res = 0x1 - Result code indicating that no response is > expected to the message other than in cases of failure caused > during the processing of the message contents or of the > contained directive(s). > > AckAll: Res = 0x2 - Result code indicating that a response to the > message is requested in all cases. > > Success: Res = 0x3 - Set in a response message by the receiver of > a request to indicate successful execution of all directives in > the corresponding request message. > > Failure: Res = 0x4 - Set in a response message by the receiver of > a request to indicate either that there was an error in the > content of the request message or that one or more directives > in the corresponding request could not be executed > successfully. > > Code: This field gives further information concerning the result in > a response message. It is mostly used to pass an error code in a > failure response but can also be used to give further information > in a success response message or an event message. In a request > message, the Code field is not used and MUST be set to zero. > > ANCP implementations MAY use any of the Code values specified in > the IANA registry "Global Switch Management Protocol version 3 > (GSMPv3) Failure Response Message Name Space" if they appear > applicable. In particular, the values: > > > > > > Wadhwa, et al. Expires February 25, 2011 [Page 18] > > Internet-Draft ANCP Protocol August 2010 > > > 2 Invalid request message (i.e., a properly formed message which > violates the protocol through its timing or direction of > transmission) > > 4 One or more of the specified ports do not exist > > 6 One or more of the specified ports are down > > 7 Invalid Partition ID > > 19 Out of resources (e.g. memory exhausted, etc.) > > 30 The limit on the maximum number of point-to-multipoint > connections that the switch can support has been reached > > 31 The limit on the maximum number of branches that the specified > point-to-multipoint connection can support has been reached > > may unfortunately apply to ANCP usage, where "Port" is interpreted > to mean an access line or a Target as defined in Section 6.2.1. > > Instead of the value: > > 3 The specified request is not implemented on this switch > > specified by [RFC3292], this specification defines a new value: > > 81 Request message type not implemented > > MB> Please use normative specification language. I assume that this > MB> means that 3 MUST NOT be used, and instead ANCP MUST use 81? [PTT] Currently the document says: "3 or 81 (latter preferred)". > > This value MAY be sent in a failure response from either the AN or > the NAS. This specification also defines the additional values: > > 82 Transaction identifier out of sequence > > 83 Malformed message > > 84 TLV or value not supported by negotiated capability set > > > ANCP extensions defining new code values SHOULD use the range 256 > (0x100) through 511 (0x1FF) for this purpose. > > The range of values from 256 to 4095 is reserved for IETF use. > > MB> It is not clear what the above means. Do you mean that ANCP uses 256 - > MB> 511, and that the allocation procedure for 256-511 is IETF consensus? > [PTT] Changed to "IETF Consensus". > > > Partition ID: This field is a 8 bit number which signifies a > partition on the AN. > > The AN and NAS may agree on the partition ID using one of the > > > > Wadhwa, et al. Expires February 25, 2011 [Page 19] > > Internet-Draft ANCP Protocol August 2010 > > > following possible options: > > 1 - The partition ID may be configured on the AN and learned by > the NAS in the adjacency message; > > 2 - The partition ID may be statically configured on the NAS as > part of configuring the neighbor information. > > Transaction ID: 24-bit field set by the sender of a request message > to associate a response message with the original request message. > Unless otherwise specified for a given message type, the > Transaction ID in request messages MUST be set to a value in the > range (1, 2^24 - 1). When used in this manner, the Transaction ID > sequencing MUST be maintained independently for each ANCP > adjacency and per message type. Furthermore, it SHOULD be > incremented linearly for each new message of the given type, > cycling back to 1 after running the full range. Each Transaction > ID sequence SHOULD be reinitialized to a random non-zero value > when an adjacency is negotiated. For event messages, the > Transaction ID SHOULD be set to zero. > > Unless otherwise specified, the default behaviour for all ANCP > responses is that the value of the Transaction ID MUST be copied > from the corresponding request message. > > I flag and SubMessage Number: An ANCP implementation SHOULD set the > I Flag and subMessage Number fields to 1 to signify no > fragmentation. > > Length: Length of the ANCP message including its header fields and > defined ANCP message body. > > 4.6.2. The ANCP Message Body > > The detailed contents of the message payload portion of a given ANCP > message may vary with the capability in the context of which it is > being used. However, the general format consists of zero or more > fixed fields, followed by a variable amount of data in the form of > Type-Length-Value (TLV) data structures. > > The general format of a TLV is shown in Figure 6: > > > > > > > > > > > Wadhwa, et al. Expires February 25, 2011 [Page 20] > > Internet-Draft ANCP Protocol August 2010 > > > 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 (IANA registered) | Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Value ~ > ~ ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 6: General TLV Format > > The fields of a TLV are defined as follows: > > Type: The TLV Type is a 16-bit unsigned value identifying the TLV > type and nature of its contents. An IANA registry has been > established for ANCP TLV Type codes. > > Length: The number of bytes of data in the Value field of the TLV, > excluding any padding required to bring this TLV to a 4-byte word > boundary (see "Value" below). If a TLV contains other TLVs, any > padding in the contained TLVs MUST be included in the value of > Length. > > If the TLV contains another TLV followed by other data, the > outer TLV will not be properly parsable unless Length is set as > indicated; if the interior padding is omitted from Length, as > many bytes of data at the end of the outer TLV will be missed. > If the outer TLV contains another TLV as its final field it > requires no padding of its own (since the contained TLV > including padding ends on a 4-byte boundary). In this case the > issue is one of consistency rather than parsability, since the > padding of that final TLV could be omitted from Length without > loss of data. > > MB> the above paragraph seems redundant. I suggest removing it. [PTT] Done. > > Depending on the specification of the TLV, the value of Length may > be zero, a constant for all instances of the TLV, or a varying > quantity. > > Value The actual data carried by the TLV, if any. The value field > in each TLV MUST be padded with zeroes as required to align with a > 4-byte word boundary. The Value field of a TLV may include fixed > fields and/or other TLVs. > > Unless otherwise specified, TLVs MAY be added to a message in any > order. If the recipient of a message does not understand a > particular TLV, it MUST silently ignore it. > > > > > Wadhwa, et al. Expires February 25, 2011 [Page 21] > > Internet-Draft ANCP Protocol August 2010 > > > A number of TLVs are specified in the remainder of this document. > > > 5. ANCP Capabilities For Digital Subscriber Lines (DSL) > > 5.1. Overview > > MB> This section should be simplified and should reference RFC5851. i think it > MB> would be better if this section simply summarised the pertinent > MB> points from the framework. [PTT] Did a major truncation, then pulled the definition of the access identifiers into this sectionb for common use by all the DSL capabilities. > ... > > 5.2. ANCP Based DSL Topology Discovery > > 5.2.1. Goals > > MB> Again, it would be better if this section simply refereced the framework > MB> with some summary text. [PTT] Done. > ... > > 5.2.3.2.1. Procedures > > MB> It is not clear what is mandatory to implement (i.e. MUST) if you support > MB> this use case. Please clarify the minimum to implement (i.e. MUST) > MB> and optional (i.e. SHOULD/MAY etc). [PTT] I think that is done with the new text. > ... From tom.taylor@huawei.com Sun Jan 2 18:16:27 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DEF28C0EF for ; Sun, 2 Jan 2011 18:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.154 X-Spam-Level: X-Spam-Status: No, score=-3.154 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VTWR3vDNuy7 for ; Sun, 2 Jan 2011 18:16:26 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0F7F928C0EB for ; Sun, 2 Jan 2011 18:16:26 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEF00A7CD2MJG@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:18:22 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEF00IJID2M20@szxga03-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:18:22 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEF00HJKD2K4A@szxml01-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 10:18:22 +0800 (CST) Date: Sun, 02 Jan 2011 21:18:23 -0500 From: Tom Taylor In-reply-to: <002501cb796f$bfd3ca50$3f7b5ef0$@com> To: Hongyu Li Message-id: <4D2131EF.30608@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: <002501cb796f$bfd3ca50$3f7b5ef0$@com> Cc: ancp@ietf.org Subject: Re: [ANCP] Double tag in Access-Loop-Encapsulation TLV 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, 03 Jan 2011 02:16:27 -0000 Done, thanks. On 31/10/2010 10:51 PM, Hongyu Li wrote: > Hi all, > > > > When reading draft-ietf-ancp-protocol-12, I found Access-Loop-Encapsulation > supports only untagged Ethernet or single-tagged Ethernet encapsulation. > What about double-tagged ones? > > > > Current definition comes from TR-101. However, as double-tagged interface is > common and useful for BNG to know, I suggest we add: > > > > Byte 2: Encapsulation 1 > > > > Double-tagged Ethernet = 3 > > > > > > Hongyu > > > > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From HaagT@telekom.de Mon Jan 3 02:41:05 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C955F28C10F for ; Mon, 3 Jan 2011 02:41:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIt5kFD1a1fA for ; Mon, 3 Jan 2011 02:41:02 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id C60F828C0FE for ; Mon, 3 Jan 2011 02:40:57 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 03 Jan 2011 11:43:02 +0100 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Jan 2011 11:42:59 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Jan 2011 11:42:58 +0100 Message-ID: <5661758E3E93364685B91DD8272F287603D90943@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4D2131D8.4020209@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Comments on draft-ietf-ancp-protocol-12.txt Thread-Index: Acuq7IlG8qmc1Um5REudSfONW2YqzAARgRjw References: <030F37126795E34DB4796609C4FEAA4A1284589757@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> <4D2131D8.4020209@huawei.com> From: To: X-OriginalArrivalTime: 03 Jan 2011 10:42:59.0813 (UTC) FILETIME=[FD648950:01CBAB32] Cc: sanjay.wadhwa@alcatel-lucent.com, draft-ieft-ancp-protocol@tools.ietf.org, ancp@ietf.org, matthew.bocci@alcatel-lucent.com Subject: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.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: Mon, 03 Jan 2011 10:41:05 -0000 Tom, thanx for this detailed work. I checked chapter 8.5.1. Here I found a comment from Immo Wetzel NSN(12th of Nov 2010)mentioning = that length should be changed from 2 to 4 bytes.=20 Regards Thomas -----Urspr=FCngliche Nachricht----- Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = Tom Taylor Gesendet: Montag, 3. Januar 2011 03:18 An: Bocci, Matthew (Matthew) Cc: Wadhwa, Sanjay (Sanjay); draft-ieft-ancp-protocol@tools.ietf.org; = ancp@ietf.org Betreff: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.txt Thanks once again for your comments. My dispositions indicated below. On 05/10/2010 10:16 AM, Bocci, Matthew (Matthew) wrote: > Authors, > > As a part of my role as shepherd for the ANCP protocol draft, I have = reviewed it and provide comments in the attached. Many of these are just = editorial, but some also pertain to, and probably overlap with the other = comments that have been provided so far regarding clarification of what = is mandatory and what is optional. > > My comments are prefixed by 'MB>'. > > Please can you address these comments in an new version of the draft = before I forward to the IESG for publication. > > Best regards > > Matthew > > ------------------------------------------------------ > > > > > Network Working Group S. = Wadhwa > Internet-Draft J. = Moisand > Intended status: Standards Track Juniper = Networks > Expires: February 25, 2011 T. = Haag > Deutsche = Telekom > N. = Voigt > Nokia Siemens = Networks > T. Taylor, = Ed. > Huawei = Technologies > August 24, = 2010 > > MB> Please update Sanjay's affiliation to Alcatel-Lucent [PTT] Done. > ... > > 2.1. Terminology > > Access Node (AN): Network device, usually located at a service > provider central office or street cabinet that terminates = access > (local) loop connections from subscribers. In case the access > loop is a Digital Subscriber Line (DSL), the Access Node = provides > DSL signal termination, and is referred to as a DSL Access > Multiplexer (DSLAM). > > Network Access Server (NAS): Network element which aggregates > subscriber traffic from a number of Access Nodes. The NAS is = an > injection point for policy management and IP QoS in the access > ^^^^^^^^^ > MB> I would suggest using ther term 'enforcement' rather than = 'injection'. [PTT] Done. > > network. It is also referred to as a Broadband Network Gateway > (BNG) or Broadband Remote Access Server (BRAS). > > > Home Gateway (HGW): Network element that connects subscriber = devices > to the Access Node and the access network. In the case of DSL, > the Home Gateway is a DSL network termination that may operate > either as a layer 2 bridge or as a layer 3 router. In the = latter > case, such a device is also referred to as a Routing Gateway = (RG). > > Net Data Rate: portion of the total data rate of the DSL line = that > can be used to transmit actual user information (e.g. ATM = cells > of Ethernet frames). It excludes overhead that pertains to the > ^^ > MB>s/of/or > [PTT] Done. > physical transmission mechanism (e.g. trellis coding in case of > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 6] > > Internet-Draft ANCP Protocol August = 2010 > > > DSL). This is defined in section 3.39 of ITU-T G.993.2. > > DSL line (synch) rate: the total data rate of the DSL line, > including the overhead attributable to the physical = transmission > mechanism. > > DSL multi-pair bonding: method for bonding (or aggregating) = multiple > xDSL lines into a single bi-directional logical link, = henceforth > referred to in this draft as "DSL bonded circuit". DSL "multi- > pair" bonding allows an operator to combine the data rates on = two > or more copper pairs, and deliver the aggregate data rate to a > single customer. ITU-T recommendations G.998.1 and G.998.2 > respectively describe ATM and Ethernet based multi-pair = bonding. > > Type-Length-Value (TLV): a data structure consisting of a = sixteen- > bit type field, a sixteen-bit length field, and a = variable-length > value field padded to the nearest 32-bit word boundary, as > described in Section 4.6.2. The value field of a TLV can = contain > other TLVs. An IANA registry is maintained for values of the = ANCP > TLV Type field. > > ANCP Protocol Capability: A detailed specification of ANCP = messages, > message content, and procedures required to implement a = specific > use case or set of use cases. ANCP capabilities may be = specific > to one access technology or technology independent. The set of > capabilities applicable to a given ANCP session are negotiated > during session startup. > > ANCP session (also called an adjacency): A session between a NAS = and > an Access Node, beginning with the initiation of the transport > connection by the AN, passing through adjacency negotiation, > discovery and provisioning stages, and continuing with service > control and possible OAM operations until the transport = connection > is terminated. There may be more than one ANCP session active > between the NAS and a given AN due to partitioning. > > MB> Please add formal references to the ITU-T Recommendations = mentioned above. [PTT] Done. > > 3. Broadband Access Aggregation > > 3.1. ATM-based broadband aggregation > > The end to end DSL network consists of network service provider = (NSP) > and application service provider (ASP) networks, regional/access > network, and customer premises network. Figure 1 shows ATM = broadband > access network components. > > The regional/access network consists of the regional network, = Network > Access Server (NAS), and the access network as shown in Figure 1. > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 7] > > Internet-Draft ANCP Protocol August = 2010 > > > Its primary function is to provide end-to-end transport between = the > customer premises and the NSP or ASP. > > The Access Node terminates the DSL signal. It may be in the form = of > a DSLAM in the central office, or a remote DSLAM, or a Remote = Access > Multiplexer (RAM). The Access Node is the first point in the = network > where traffic on multiple DSL lines will be aggregated onto a = single > network. > > The NAS performs multiple functions in the network. The NAS is = the > aggregation point for subscriber traffic. It provides aggregation > capabilities (e.g. IP, PPP, ATM) between the Regional/Access = Network > and the NSP or ASP. These include traditional ATM-based offerings > and newer, more native IP-based services. This includes support = for > Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet > (PPPoE), as well as direct IP services encapsulated over an > appropriate layer 2 transport. > > Beyond aggregation, the NAS is also the injection point for policy > ^^^^^^^^^ > MB> enforcement? > [PTT] Done. > management and IP QoS in the regional/access networks. To allow = IP > QoS support over an existing non-IP-aware layer 2 access network > without using multiple layer 2 QoS classes, a mechanism based on > hierarchical scheduling is used. This mechanism, defined in > [TR_059], preserves IP QoS over the ATM network between the NAS = and > the routing gateway (RG) at the edge of the subscriber network, by > carefully controlling downstream traffic in the NAS, so that > significant queuing and congestion does not occur further down the > ATM network. This is achieved by using a diffserv-aware = hierarchical > scheduler in the NAS that will account for downstream trunk > bandwidths and DSL synch rates. > > [RFC5851] provides detailed definition and functions of each = network > element in the broadband reference architecture. > > > > > > > > > > > > > > > > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 8] > > Internet-Draft ANCP Protocol August = 2010 > > > Access Customer > <--- Aggregation --> <------- Premises = -------> > Network Network > > +------------------+ = +--------------------------+ > +---------+ +---+ | +-----+ +------+ | |+-----+ +---+ = +---------+ | > NSP| | +-|NAS|-| |ATM |-|Access| --||DSL = |-|HGW|-|Subscriber|| > ---+ Regional| | +---+ | +-----+ | Node | | ||Modem| +---+ |Devices = || > |Broadband| | +---+ | +------+ | |+-----+ = +----------+| > ASP|Network |-+-|NAS| +--------------|---+ = +--------------------------+ > ---+ | | +---+ | = +--------------------------+ > | | | +---+ | |+-----+ +---+ = +----------+| > +---------+ +-|NAS| +-----|| DSL = |-|HGW|-|Subscriber|| > +---+ ||Modem| +---+ |Devices = || > |+-----+ = +----------+| > = +--------------------------+ > HGW : Home Gateway > NAS : Network Access Server > > > Figure 1: ATM Broadband Aggregation Topology > > 3.2. Ethernet-based broadband aggregation > > The Ethernet aggregation network architecture builds on the = Ethernet > bridging/switching concepts defined in IEEE 802. The Ethernet > aggregation network provides traffic aggregation, class of service > distinction, and customer separation and traceability. VLAN = tagging > defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used = as > standard virtualization mechanism in the Ethernet aggregation > network. The aggregation devices are "provider edge bridges" = defined > in IEEE 802.ad. > > Stacked VLAN tags provide one possible way to create equivalent of > "virtual paths" and "virtual circuits" in the aggregation network. > The "outer" vlan can be used to create a form of "virtual path" > between a given DSLAM and a given NAS. "Inner" VLAN tags create a > form of "virtual circuit" on a per DSL line basis. This is the = 1:1 > VLAN allocation model. An alternative model is to bridge sessions > from multiple subscribers behind a DSLAM into a single VLAN in the > aggregation network. This is the N:1 VLAN allocation model. > Architectural and topological models of an Ethernet aggregation > network in context of DSL aggregation are defined in [TR_101]. > > MB> Please add specific references to the Ethernet concepts described = above. > [PTT] Replaced the final sentence with: "Section 1.6 of provides brief definitions of these two models, while section 2.5.1 describes them in more detail." ... > > 4.5.2. ANCP Adjacency Procedures > > The NAS MUST set the M-flag in the SYN message (signifying it is = the > master). Once the adjacency is established, periodic adjacency > messages (type ACK) MUST be exchanged. The default for the ACK > interval to be advertised in the adjacency messages is 25 seconds = for > ANCP. The actual value SHOULD be configurable and is an > implementation choice. It is RECOMMENDED that both ends specify = the > ^^^^^^^^^^^^^^ > MB> If it is configurable, then it is a deployment choice rather than = an > implementation choice. > [PTT] Fixed as suggested. > > > Wadhwa, et al. Expires February 25, 2011 [Page = 15] > > Internet-Draft ANCP Protocol August = 2010 > > > same timer value; to achieve this, each end SHOULD compare the = timer > value in the first adjacency message it receives with its own > preferred value and agree to use the higher of the two values. = That > is, the node that receives a higher timer value than its own = SHOULD > reply in its subsequent adjacency messages (such as SYNACK, ACK) = with > the higher timer value. > > In the adjacency protocol the version and sub-version fields are = used > for version negotiation. The version negotiation is performed = before > synchronisation is achieved. In a SYN message the version/ > sub-version fields always contain the highest version understood = by > the sender. A receiver receiving a SYN message with a version/ > sub-version higher than it understands MUST silently discard that > message. A receiver receiving a SYN message with a version/ > sub-version within the range of versions that it understands MUST > reply with a SYNACK with the version/sub- version from the = received > SYN in its ANCP version/sub-version fields. This defines the > version/sub-version of the ANCP protocol to be used while the > adjacency remains synchronised. All other ANCP messages within = the > session MUST use the agreed version in the version/sub-version > fields. > > The semantics and suggested values for the Code, Sender Name, > Receiver Name, Sender Instance, and Receiver Instance fields are = as > defined in Section 11 of [RFC3292]. The Sender Port, and Receiver > Port SHOULD be set to 0 by both ends. The pType field SHOULD be = set > to 0 (No Partition). The pFlag SHOULD be set to 1 (New = Adjacency). > > If the adjacency times out on either end, due to not receiving an > adjacency message for a duration of (3 * Timer value), where the > timer value is specified in the adjacency message, all the state > received from the ANCP neighbor SHOULD be cleaned up, and the TCP > connection SHOULD be closed. The NAS MUST continue to listen for = new > connection requests. The AN MUST try to re-establish the TCP > connection and both sides MUST attempt to re-establish the = adjacency. > > The handling defined above will need some modifications when ANCP > graceful restart procedures are defined. These procedures will be > defined in a separate document. > > MB> The above paragraph should be removed as we do not currently have = an > MB> active GR draft. It is up to any future GR document to state > MB> whether it modifies/updates the procedures in this document. > [PTT] Done. > Both the NAS and the Access Node MUST advertise supported > capabilities in the adjacency messages they send. The same = message > MAY advertise capabilities for any mixture of access technologies. > If a received adjacency message indicates no support for a = capability > that is supported by the receiving device, it MUST turn off the > ^^^^^^^^ > MB> disable? > [PTT] Done. > capability locally and MUST send an updated adjacency message with > the corresponding capability field omitted to match the received > capability set. This process will eventually result in both sides > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 16] > > Internet-Draft ANCP Protocol August = 2010 > > > agreeing on the maximal common set of supported capabilities. The > adjacency MUST NOT come up if that common set is empty. > > After initial synchronization, if at any time a capability = mismatch > is detected, the adjacency MUST be brought down (RSTACK MUST be > generated by the device detecting the mismatch), and = synchronization > MUST be re-attempted. > > 4.6. ANCP General Message Formats > > This section describes the general format of ANCP messages other = than > the adjacency messages. > > The GSMPv3 general message format, used by all GSMP messages other > than adjacency protocol messages, is defined in Section 3.1.1 of > GSMPv3 [RFC3292]. ANCP modifies this base GSMPv3 message format = as > shown in Figure 5. > > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 = 1 > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vers | Sub | Message Type | Result| Code = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Partition ID | Transaction Identifier = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |I| SubMessage Number | Length = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | = | > ~ Message Payload = ~ > | = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Figure 5: ANCP General Message Format > > 4.6.1. The ANCP Message Header > > MB> A geneal comment on this section: > - Please clarify what is mandatory and what is optional. e.g. > It is unclear whether a sender MUST support result codes, and = what > a receiver MUST do with them. Are they just logged in a MIB, or = somehting else? > Please calrify, > [PTT] As far as general support, you'll find the "MUSTs" in the=20 descriptions of the individual messages. Example from the documentation=20 of the Provisioning message: "The message header field settings given below are REQUIRED in the Provisioning message. The remaining message header fields MUST be set as specified in Section 3.6.1." As you know, the documentation of Code values has been much expanded. > The immediately visible differences from GSMPv3 are the = subdivision > of the Version field into version and sub-version, and the > reallocation of space between Result and Code to enlarge the range > for Code. The 8-bit version field in the base GSMPv3 message = header > is split into two 4 bit fields for carrying the version and a sub- > version of the ANCP protocol. The Result field in the message = header > has been modified to be 4 bits long, and the Code field to be 12 = bits > long. > > A complete explanation of the header fields is as follows: > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 17] > > Internet-Draft ANCP Protocol August = 2010 > > > Version and Sub-version: The version of the ANCP protocol that = was > agreed for the session during adjacency negotiation. For the > values that must be placed into these fields, see Section 4.1. > > Message Type: The ANCP message type. Message type values are > registered in a common GSMPv3/ANCP IANA registry. > > Result: The Result field is derived from GSMPv3 [RFC3292]. = Ignore > (0x0) is a new value added by ANCP. The remaining Result = values > below are a subset of those defined for GSMPv3. GSMPv3 = expected > the sender of a request to choose between NAck (0x1) and AckAll > (0x2) according to its needs. ANCP specifies what Result value > each request should have. Responses indicate either Success = (0x3) > or Failure (0x4) as the case may be. > > Ignore: Res =3D 0x0 - Ignore this field on receipt and follow = the > procedures specified for the received message type. > > Nack: Res =3D 0x1 - Result code indicating that no response is > expected to the message other than in cases of failure = caused > during the processing of the message contents or of the > contained directive(s). > > AckAll: Res =3D 0x2 - Result code indicating that a response = to the > message is requested in all cases. > > Success: Res =3D 0x3 - Set in a response message by the = receiver of > a request to indicate successful execution of all directives = in > the corresponding request message. > > Failure: Res =3D 0x4 - Set in a response message by the = receiver of > a request to indicate either that there was an error in the > content of the request message or that one or more = directives > in the corresponding request could not be executed > successfully. > > Code: This field gives further information concerning the result = in > a response message. It is mostly used to pass an error code in = a > failure response but can also be used to give further = information > in a success response message or an event message. In a = request > message, the Code field is not used and MUST be set to zero. > > ANCP implementations MAY use any of the Code values specified = in > the IANA registry "Global Switch Management Protocol version 3 > (GSMPv3) Failure Response Message Name Space" if they appear > applicable. In particular, the values: > > > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 18] > > Internet-Draft ANCP Protocol August = 2010 > > > 2 Invalid request message (i.e., a properly formed message = which > violates the protocol through its timing or direction of > transmission) > > 4 One or more of the specified ports do not exist > > 6 One or more of the specified ports are down > > 7 Invalid Partition ID > > 19 Out of resources (e.g. memory exhausted, etc.) > > 30 The limit on the maximum number of point-to-multipoint > connections that the switch can support has been reached > > 31 The limit on the maximum number of branches that the = specified > point-to-multipoint connection can support has been reached > > may unfortunately apply to ANCP usage, where "Port" is = interpreted > to mean an access line or a Target as defined in Section 6.2.1. > > Instead of the value: > > 3 The specified request is not implemented on this switch > > specified by [RFC3292], this specification defines a new value: > > 81 Request message type not implemented > > MB> Please use normative specification language. I assume that this > MB> means that 3 MUST NOT be used, and instead ANCP MUST use 81? [PTT] Currently the document says: "3 or 81 (latter preferred)". > > This value MAY be sent in a failure response from either the AN = or > the NAS. This specification also defines the additional = values: > > 82 Transaction identifier out of sequence > > 83 Malformed message > > 84 TLV or value not supported by negotiated capability set > > > ANCP extensions defining new code values SHOULD use the range = 256 > (0x100) through 511 (0x1FF) for this purpose. > > The range of values from 256 to 4095 is reserved for IETF use. > > MB> It is not clear what the above means. Do you mean that ANCP uses = 256 - > MB> 511, and that the allocation procedure for 256-511 is IETF = consensus? > [PTT] Changed to "IETF Consensus". > > > Partition ID: This field is a 8 bit number which signifies a > partition on the AN. > > The AN and NAS may agree on the partition ID using one of the > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 19] > > Internet-Draft ANCP Protocol August = 2010 > > > following possible options: > > 1 - The partition ID may be configured on the AN and learned = by > the NAS in the adjacency message; > > 2 - The partition ID may be statically configured on the NAS = as > part of configuring the neighbor information. > > Transaction ID: 24-bit field set by the sender of a request = message > to associate a response message with the original request = message. > Unless otherwise specified for a given message type, the > Transaction ID in request messages MUST be set to a value in = the > range (1, 2^24 - 1). When used in this manner, the Transaction = ID > sequencing MUST be maintained independently for each ANCP > adjacency and per message type. Furthermore, it SHOULD be > incremented linearly for each new message of the given type, > cycling back to 1 after running the full range. Each = Transaction > ID sequence SHOULD be reinitialized to a random non-zero value > when an adjacency is negotiated. For event messages, the > Transaction ID SHOULD be set to zero. > > Unless otherwise specified, the default behaviour for all ANCP > responses is that the value of the Transaction ID MUST be = copied > from the corresponding request message. > > I flag and SubMessage Number: An ANCP implementation SHOULD set = the > I Flag and subMessage Number fields to 1 to signify no > fragmentation. > > Length: Length of the ANCP message including its header fields = and > defined ANCP message body. > > 4.6.2. The ANCP Message Body > > The detailed contents of the message payload portion of a given = ANCP > message may vary with the capability in the context of which it is > being used. However, the general format consists of zero or more > fixed fields, followed by a variable amount of data in the form of > Type-Length-Value (TLV) data structures. > > The general format of a TLV is shown in Figure 6: > > > > > > > > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 20] > > Internet-Draft ANCP Protocol August = 2010 > > > 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 (IANA registered) | Length = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | = | > ~ Value = ~ > ~ = ~ > | = | > = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 6: General TLV Format > > The fields of a TLV are defined as follows: > > Type: The TLV Type is a 16-bit unsigned value identifying the TLV > type and nature of its contents. An IANA registry has been > established for ANCP TLV Type codes. > > Length: The number of bytes of data in the Value field of the = TLV, > excluding any padding required to bring this TLV to a 4-byte = word > boundary (see "Value" below). If a TLV contains other TLVs, = any > padding in the contained TLVs MUST be included in the value of > Length. > > If the TLV contains another TLV followed by other data, the > outer TLV will not be properly parsable unless Length is set = as > indicated; if the interior padding is omitted from Length, = as > many bytes of data at the end of the outer TLV will be = missed. > If the outer TLV contains another TLV as its final field it > requires no padding of its own (since the contained TLV > including padding ends on a 4-byte boundary). In this case = the > issue is one of consistency rather than parsability, since = the > padding of that final TLV could be omitted from Length = without > loss of data. > > MB> the above paragraph seems redundant. I suggest removing it. [PTT] Done. > > Depending on the specification of the TLV, the value of Length = may > be zero, a constant for all instances of the TLV, or a varying > quantity. > > Value The actual data carried by the TLV, if any. The value = field > in each TLV MUST be padded with zeroes as required to align = with a > 4-byte word boundary. The Value field of a TLV may include = fixed > fields and/or other TLVs. > > Unless otherwise specified, TLVs MAY be added to a message in any > order. If the recipient of a message does not understand a > particular TLV, it MUST silently ignore it. > > > > > Wadhwa, et al. Expires February 25, 2011 [Page = 21] > > Internet-Draft ANCP Protocol August = 2010 > > > A number of TLVs are specified in the remainder of this document. > > > 5. ANCP Capabilities For Digital Subscriber Lines (DSL) > > 5.1. Overview > > MB> This section should be simplified and should reference RFC5851. i = think it > MB> would be better if this section simply summarised the pertinent > MB> points from the framework. [PTT] Did a major truncation, then pulled the definition of the access=20 identifiers into this sectionb for common use by all the DSL = capabilities. > ... > > 5.2. ANCP Based DSL Topology Discovery > > 5.2.1. Goals > > MB> Again, it would be better if this section simply refereced the = framework > MB> with some summary text. [PTT] Done. > ... > > 5.2.3.2.1. Procedures > > MB> It is not clear what is mandatory to implement (i.e. MUST) if you = support > MB> this use case. Please clarify the minimum to implement (i.e. = MUST) > MB> and optional (i.e. SHOULD/MAY etc). [PTT] I think that is done with the new text. > ... _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From tom.taylor@huawei.com Mon Jan 3 05:31:10 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF0328C121 for ; Mon, 3 Jan 2011 05:31:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.723, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2DEDIPjr9iZ for ; Mon, 3 Jan 2011 05:31:08 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id B5AD528C11D for ; Mon, 3 Jan 2011 05:31:08 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEG009WA8B59K@szxga05-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 21:33:05 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEG0078N8B4DM@szxga05-in.huawei.com> for ancp@ietf.org; Mon, 03 Jan 2011 21:33:05 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEG00CQJ8B1KR@szxml02-in.huawei.com>; Mon, 03 Jan 2011 21:33:04 +0800 (CST) Date: Mon, 03 Jan 2011 08:33:04 -0500 From: Tom Taylor In-reply-to: <5661758E3E93364685B91DD8272F287603D90943@S4DE8PSAAQC.mitte.t-com.de> To: HaagT@telekom.de Message-id: <4D21D010.9090005@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 8BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 References: <030F37126795E34DB4796609C4FEAA4A1284589757@FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com> <4D2131D8.4020209@huawei.com> <5661758E3E93364685B91DD8272F287603D90943@S4DE8PSAAQC.mitte.t-com.de> Cc: sanjay.wadhwa@alcatel-lucent.com, draft-ieft-ancp-protocol@tools.ietf.org, ancp@ietf.org, matthew.bocci@alcatel-lucent.com Subject: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.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: Mon, 03 Jan 2011 13:31:10 -0000 Unfortunately that directly contradicts the definition of length for a TLV. The definition excludes padding. Take a look at the Access-Loop-Encapsulation TLV for another example. On 03/01/2011 5:42 AM, HaagT@telekom.de wrote: > > Tom, > thanx for this detailed work. > > I checked chapter 8.5.1. > > Here I found a comment from Immo Wetzel NSN(12th of Nov 2010)mentioning that length should be changed from 2 to 4 bytes. > > > Regards > Thomas > > > -----Ursprüngliche Nachricht----- > Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Tom Taylor > Gesendet: Montag, 3. Januar 2011 03:18 > An: Bocci, Matthew (Matthew) > Cc: Wadhwa, Sanjay (Sanjay); draft-ieft-ancp-protocol@tools.ietf.org; ancp@ietf.org > Betreff: Re: [ANCP] Comments on draft-ietf-ancp-protocol-12.txt > > Thanks once again for your comments. My dispositions indicated below. > > On 05/10/2010 10:16 AM, Bocci, Matthew (Matthew) wrote: ... From Internet-Drafts@ietf.org Tue Jan 4 06:45:03 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE343A6C47; Tue, 4 Jan 2011 06:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdMmM1O7OGa1; Tue, 4 Jan 2011 06:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 642843A6AD9; Tue, 4 Jan 2011 06:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110104144502.13307.43531.idtracker@localhost> Date: Tue, 04 Jan 2011 06:45:02 -0800 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-13.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, 04 Jan 2011 14:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-13.txt Pages : 72 Date : 2011-01-04 This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS- related, service-related and subscriber-related operations. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-protocol-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-04063144.I-D@ietf.org> --NextPart-- From tom.taylor@huawei.com Tue Jan 4 10:41:33 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8809D3A6CF6 for ; Tue, 4 Jan 2011 10:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivX-wROoER75 for ; Tue, 4 Jan 2011 10:41:32 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1C5083A6CD9 for ; Tue, 4 Jan 2011 10:41:32 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEI00GNKHCGBG@szxga05-in.huawei.com> for ancp@ietf.org; Wed, 05 Jan 2011 02:43:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEI00IXDHCGQM@szxga05-in.huawei.com> for ancp@ietf.org; Wed, 05 Jan 2011 02:43:28 +0800 (CST) Received: from [192.168.2.15] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEI00LRJHCEDH@szxml01-in.huawei.com> for ancp@ietf.org; Wed, 05 Jan 2011 02:43:28 +0800 (CST) Date: Tue, 04 Jan 2011 13:43:29 -0500 From: Tom Taylor To: "ancp@ietf.org" Message-id: <4D236A51.3090303@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Subject: [ANCP] Guided tour through the latest protocol draft 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, 04 Jan 2011 18:41:33 -0000 draft-ietf-ancp-protocol-13 has now been submitted. The biggest changes are the ones we discussed on the list: -- defining a boundary between the protocol and the control application, and removing material that specified behaviour at the level of the control application -- much fuller description of what to do if particular Code values are received. However, there have been lots of smaller changes throughout the document, so this is a section-by-section guided tour. I'll use the section numbers of version -13 in describing those changes. Here is the section-by-section review. 1. Introduction Technical: added the architectural model for the protocol, as proposed and agreed on the list. An "oops" just below that -- TLS is mentioned, but the Security Considerations section now calls for IPsec instead. Added the terms "AN-side ANCP agent" and "NAS-side ANCP agent" to denote the implementations of the protocol on the AN and NAS respectively. Editorial: included the "Requirements Language" section in the Introduction. We'll see if IDNits lets us do that. Added requirements terminology for interaction between the ANCP agent and the control application. In the Terminology subsection, changed the order of the definitions so they pass from architecture through protocol to specific technology. Changed some of the definitions of terms already defined in the framework document to quote directly from that document. Modified the RFC 5851 definition of adjacency to use the more specific terminology of the present document. 2. Broadband Access Aggregation Unchanged from old Section 3 except for more specific TR-101 references at the end, as requested by Matthew Bocci. 3. Access Node Control Protocol -- General Aspects This was section 4. Deleted the detailed list of changes from GSMPv3 -- I figured this document was addressed to ANCP implementors, not people who had implemented GSMP and were modifying it. Subsections 3.1 through 3.4: no changes. Subsection 3.5 Use of the GSMPv3 Adjacency Protocol 3.5.1: Moved the text describing the settings of the legacy fields in the messages from the procedures subsection to this section. Corrected the pType setting as indicated in the reply to Stefaan De Cnodder. 3.5.2: Added text on interactions between the ANCP agent and control application, at the beginning and end of the section. Moved timeout handling down, to follow logically after negotiation is complete. Subsection 3.6 ANCP General Message Formats 3.6.1.4: greatly expanded Code field descriptions. Removed Code values 3 and 4 in favour of 81 and 1280. An "oops" here: 3 and 4 still appear in the introductory text. Removed 30 and 31 except in the introductory text. Removed 83 because it doesn't seem necessary for the receiver to track Transaction IDs, as discussed on the list. Changed 84 to Mandatory TLV missing, per Stefaan De Cnodder's comment about the former descriptione being inconsistent with the instruction to silently ignore unknown TLVs. Added 85. 3.6.1.6: Simplified the requirements for management of Transaction IDs. Actually, as far as I can see, the only real requirement is that Transaction IDs for the current set of outstanding requests have to be unique. We could modify the subsection to say that if people agree. 3.6.1.7: added a little explanation. 3.6.1.8: expanded the definition of Length slightly. 3.6.2: deleted the note in the definition of TLV length, as suggested by Matthew Bocci. Subsection 3.7 General Principles for the Design of ANCP Messages Moved up from old 6.1.1. Decided that instructions to specification writers have to have capitalized SHOULD and MUST, just like instructions to protocol implementors, after experience with an AD review of another document I'm editing. 4. Generally Useful ANCP Messages and TLVs Moved up from old Section 6. It seemed logical to move from the general (facilities for all capabilities) to the particular (DSL capabilities). 4.1 Provisioning Message Added a statement that support of the message is optional except as part of a capability the ANCP agent claims to support. Added a statement that the message can carry information for more than one capability at once. 4.2 Generic Response Message Made support of the Generic Response message mandatory. Added access line identifying TLVs at the top level (copied from the original request if present there). Have a couple of glitches to fix in the figure. Added that the contents of the Status-Info depend also on the Code value. Prohibited a response to a Generic Response because of an error in the latter. 4.3. Target TLV and 4.4. Command TLV Added a statement that support of the TLV is optional except as part of a capability the ANCP agent claims to support. 4.5. Status-Info TLV Made support of the Status-Info TLV mandatory. Dropped the recommendations of what it should contain for given Code values, since that is now covered by Code value documentation. 5. Introduction To ANCP Capabilities For Digital Subscriber Lines (DSL) Made this a separate section to reduce the depth of the header numbers in succeeding text. Greatly shortened the introduction because of overlap with RFC 5851. 5.1. DSL Access Line Identification Created this new subsection because line identifiers are common to all of the DSL capabilities. 5.1.1 Control Context Added a new informative section to describe what the different identifier TLVs mean and what the control applications will do with them. Gave specific TR-101 references on format but didn't get specific on the format itself in this document. 5.1.2 TLVs For DSL Access Line Identification Gave normative constraints on the identifiers that have to be present in a message. Gave the TLV specifications, removing the parts that are the responsibility of the control applications. Made the sender-side choice between Access-Aggregation-Circuit-ID -Binary and -ASCII an implementation decision, on the grounds that they carry the same information when everything is taken into account. The receiver has to be able to parse both. Added more detail on the construction of the -Binary form. 6. ANCP Based DSL Topology Discovery Rewritten as discussed on the list. Because of the move of the identifier TLVs, the protocol requirements now include a normative reference to section 5.1.2. Made Figure 14 clearer by labelling unused fields and showing the identifier TLVs separately from the DSL-Line-Attributes TLV. 7. ANCP based DSL Line Configuration Rewritten in a similar spirit to the topology capability. I note that the definition of Function doesn't treat the access line identifiers properly (assumes there is always just one TLV). I'll fix that. Tech Type has been removed. The DSL-specific aspect is really the access line identifier TLV types. I'm expecting that other access technologies may have to introduce new identifier TLV types. Added a couple of paragraphs at the end of the message description (section 7.3) describing reuse of the Port Management message for other capabilities. Of course, I have multicast in mind. Added a statement that line configuration can be done in any line state. Added a statement that the AN-side agent MUST wait for the AN control application to indicate success before replying. This was really to make handling of the message consistent with the handling of the Port Management (OAM) message, where the delay in replying is essential. 8. ANCP-Based DSL Remote Line Connectivity Testing Rewritten in a similar spirit to the topology capability. A lot of procedural material previously in the TLV definitions has been moved to the Control Context section, since it is the responsibility of the control application. Added a figure for the Port Management (OAM) message, even though it is almost the same as the Port Management (line configuration). Did not add text on reuse for other access technologies -- they probably have their own TLVs for line identification and for test parameters. Added that testing can be attempted regardless of the state of the line, but could fail in some states. Added that the AN-side agent MUST wait for the result from the control application before replying. I need help on the "DSL line status" code values. Are they successes or failures? I assume "DSL line integrity error" is a failure, but wasn't 100% sure. (The testing was successful but the line failed the test.) Opinions? 9. IANA Considerations Deleted a couple of Editor's Notes and updated the Code registry (i.e., the Failure Response Message Name registry). 10. Security Considerations Expanded to list the requirements from RFC 5713, note the vulnerability of adjancies to attacks on the TCP session, and describe the IPsec solution. Tom Taylor From Internet-Drafts@ietf.org Tue Jan 11 12:00:02 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD3B93A6A9E; Tue, 11 Jan 2011 12:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smEEqTyO7k0q; Tue, 11 Jan 2011 12:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DD528C0EF; Tue, 11 Jan 2011 12:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110111200001.18018.39760.idtracker@localhost> Date: Tue, 11 Jan 2011 12:00:01 -0800 Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-14.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, 11 Jan 2011 20:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Access Node Control Protocol Working Group of the IETF. Title : Protocol for Access Node Control Mechanism in Broadband Networks Author(s) : S. Wadhwa, et al. Filename : draft-ietf-ancp-protocol-14.txt Pages : 72 Date : 2011-01-11 This document describes the Access Node Control Protocol (ANCP). ANCP operates between a Network Access Server (NAS) and an Access Node (e.g., a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS- related, service-related and subscriber-related operations. Use cases for ANCP are documented in RFC 5851. As well as describing the base ANCP protocol, this document specifies capabilities for Digital Subscriber Line (DSL) topology discovery, line configuration, and remote line connectivity testing. The design of ANCP allows for protocol extensions in other documents if they are needed to support other use cases and other access technologies. ANCP is based on GSMPv3 (RFC 3292), but with many modifications and extensions, to the point that the two protocols are not interoperable. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-protocol-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-11115904.I-D@ietf.org> --NextPart-- From tom.taylor@huawei.com Tue Jan 11 12:31:43 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A78AA28C2E2 for ; Tue, 11 Jan 2011 12:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.233 X-Spam-Level: X-Spam-Status: No, score=-3.233 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL68uYyLm5CV for ; Tue, 11 Jan 2011 12:31:43 -0800 (PST) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id DDEC528C127 for ; Tue, 11 Jan 2011 12:31:42 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV002CSL4DDH@szxga03-in.huawei.com> for ancp@ietf.org; Wed, 12 Jan 2011 04:33:50 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LEV00A5OL4D43@szxga03-in.huawei.com> for ancp@ietf.org; Wed, 12 Jan 2011 04:33:49 +0800 (CST) Received: from [192.168.2.17] (bas4-ottawa10-1176115117.dsl.bell.ca [70.26.23.173]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LEV00H0EL4CCU@szxml02-in.huawei.com> for ancp@ietf.org; Wed, 12 Jan 2011 04:33:49 +0800 (CST) Date: Tue, 11 Jan 2011 15:33:53 -0500 From: Tom Taylor To: "ancp@ietf.org" Message-id: <4D2CBEB1.4050005@huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 Subject: [ANCP] Base protocol draft update X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 20:31:43 -0000 Update was purely editorial, to fix the errors I noted in my previous walk-through message. Tom Taylor From matthew.bocci@alcatel-lucent.com Mon Jan 17 02:52:10 2011 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094303A6F2D for ; Mon, 17 Jan 2011 02:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.927 X-Spam-Level: X-Spam-Status: No, score=-105.927 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsdU70y0g3yL for ; Mon, 17 Jan 2011 02:52:08 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id BAD893A6D44 for ; Mon, 17 Jan 2011 02:52:07 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p0HAs6kW018885 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 17 Jan 2011 11:54:38 +0100 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.38]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Mon, 17 Jan 2011 11:54:16 +0100 From: "Bocci, Matthew (Matthew)" To: "ancp@ietf.org" Date: Mon, 17 Jan 2011 11:54:09 +0100 Thread-Topic: Second WG Last Call for draft-ietf-ancp-protocol-14 Thread-Index: Acu2NOHuoXrhDQEjSD+vu8/SZyJFkw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C959D037764Fmatthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: [ANCP] Second WG Last Call for draft-ietf-ancp-protocol-14 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, 17 Jan 2011 10:52:10 -0000 --_000_C959D037764Fmatthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This email begins a two week working group last call on draft-ietf-ancp-pro= tocol-14. The version covered by this last call can be found at: http://tools.ietf.org/html/draft-ietf-ancp-protocol-14 Please review the draft and post any comments to the ANCP mailing list by M= onday 31st Jan 2011. Please also note the following IPR declaration: https://datatracker.ietf.org/ipr/1124/ Regards, Matthew & Woj --_000_C959D037764Fmatthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
This email begins a two = week working group last call on draft-ietf-ancp-protocol-14. 

The version covered by this last call can be found at:

Please review the draft and post any comments to the ANCP mailing l= ist by Monday 31st Jan 2011.

Please also note the = following IPR declaration:

Regards,

Matthew & Woj
--_000_C959D037764Fmatthewboccialcatellucentcom_--