Agenda items for IETF75 ANCP WG meeting

Maybe this was not=A0clarified in the Introduction of the draft. We=A0= submitted a new version for the draft,=A0clarifying=A0such point in=A0the= =A0Introduction and also considering the other comments that we received.

=A0

Kind regards,

Hassnaa=A0

-----Message d'origine-----
De : Ran = Canetti [mailto:canetti@post.tau.= ac.il]
Envoy=E9 : samedi 4 juillet 2009 18:13
=C0 : ancp@ietf.org; se= cdir@mit.edu; MOUSTAFA Hassnaa RD-CORE-ISS; Ran Canetti
Objet : SECDIR review of hassnaa.moustafa@orange-ftgroup.com

*** =A0 I have revi= ewed this document as part of the security directorate's
*** =A0 ong= oing effort to review all IETF documents being processed by the
*** =A0 IESG. =A0These comments were written primarily for the benefit of t= he
*** =A0 security area directors. =A0Document editors and WG chairs sh= ould treat
*** =A0 these comments just like any other last call comments= .

The draft describes potential threats and attacks, and consequently sec= urity requirements for the Access Note Control Protocol. (This protocol all= ows configuring the components of DSL connections to the Internet.)

My main comment is that most (if not all) of the attacks seem to be gen= eric
=A0man-in-the-middle and DOS attacks. Also the short list of securi= ty requirements that are derived from these attacks (section 8) seem pretty= generic authentication and secrecy requirements for Internet connections.<= br> It would be nice to differentiate and highlight the security threats and co= ncerns that are special to the ANCS setting. In particular, what are the tr= ust relationships between the different =A0protocol principals/entities? Are they all run by the same administrative domain? =A0Also, are all links = equally untrusted, or are there links that are less trusted than others?Also, are all attacks equally devestating? Which are more costly/important= to prevent?

Best,
Ran

--000e0cd1e85c2b91c7046e459ad5-- From root@core3.amsl.com Mon Jul 13 01:15:02 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A380E3A6CFA; Mon, 13 Jul 2009 01:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713081501.A380E3A6CFA@core3.amsl.com> Date: Mon, 13 Jul 2009 01:15:01 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-protocol-06.txt X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 08:15: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-06.txt Pages : 55 Date : 2009-07-13 This document describes proposed extensions to the GSMPv3 protocol to allow its use in a broadband environment, as a control plane between Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). These proposed extensions are required to realize a protocol for "Access Node Control" mechanism as described in [ANCP-FRAMEWORK]. The resulting protocol with the proposed extensions to GSMPv3 [RFC3292] is referred to as "Access Node Control Protocol" (ANCP). This document currently focuses on specific use cases of access node control mechanism for topology discovery, line configuration, and OAM as described in ANCP framework document [ANCP-FRAMEWORK]. It is intended to be augmented by additional protocol specification for future use cases considered in scope by the ANCP charter. ANCP framework document [ANCP-FRAMEWORK] describes the ANCP use-cases in detail. Illustrative text for the use-cases is included here to help the protocol implementer understand the greater context of ANCP protocol interactions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13010401.I-D@ietf.org> --NextPart-- From Sven.Ooghe@alcatel-lucent.be Mon Jul 13 06:52:40 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25A83A6D7E; Mon, 13 Jul 2009 06:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7L9OmB-WOF8c; Mon, 13 Jul 2009 06:52:39 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 534F13A6B44; Mon, 13 Jul 2009 06:52:38 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6DDqnHR024612; Mon, 13 Jul 2009 15:52:57 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 15:52:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 13 Jul 2009 15:52:54 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA0292927D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <20090629133536.8D9DF1938B8C@newdev.eecs.harvard.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSV review of draft-ietf-ancp-framework-10.txt thread-index: Acn4voERPs33U50PRzqwqvcBQxAtUgLAcYRQ References: <20090629133536.8D9DF1938B8C@newdev.eecs.harvard.edu> From: "OOGHE Sven" To: "Scott O. Bradner" , X-OriginalArrivalTime: 13 Jul 2009 13:52:55.0898 (UTC) FILETIME=[3955DBA0:01CA03C1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: ancp@ietf.org Subject: Re: [ANCP] TSV review of draft-ietf-ancp-framework-10.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, 13 Jul 2009 13:52:41 -0000 Scott Thanks for reviewing. See inline. -----Original Message----- From: Scott O. Bradner [mailto:sob@harvard.edu]=20 Sent: maandag 29 juni 2009 15:36 To: tsv-dir@ietf.org Cc: ancp@ietf.org; haagt@telekom.de; michel.platnic@ecitele.com; norbert.voigt@nsn.com; OOGHE Sven; swadhwa@juniper.net Subject: TSV review of draft-ietf-ancp-framework-10.txt TSV-dir review of draft-ietf-ancp-framework-10.txt I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. The primary transport-related issue I see with the document is its some naive assumption that simple prioritization will mean that the control protocol will not experience congestion. (See, for example section 2.3) I would suggest that the document say that use of a IETF approved congestion aware reliable transport protocol (e.g., TCP or SCTP) be required for the control protocol wherever the control protocol is transported on IP. (Section 4.5)=20 The intent of the wording in section 2.3 was to prioritize the ANCP traffic over other sources of traffic. I agree that this does not by itself avoid packet loss, but it should reduce the likelihood of dropping packets in a number of cases. I propose to reword the text to reflect this, e.g.: "These ATM PVCs would then be given a high priority so that at times of network congestion, loss of the ATM cells carrying the Access Node Control Protocol is avoided or minimized." The abstract says that the purpose of the document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)). But the document is more than a framework document. As indicated by the title, the document also includes a set of requirements for an Access Node Control Mechanism. The document also includes a set of functional requirements for devices involved in such a system. It seems to me that the document is trying to do too much. =20 *** I will update the abstract to better reflect the purpose of the document. I find that the framework presented in this document to be complex and, too often, vague. I also find many of the requirements to be incomplete. a few examples - this is not an exhaustive list I note that there is a mixture of "MUST" and "must" - that could be confusing - since this is supposed to be framework & requirements documents it may be reasonable to not use RFC 2119 termonology This was also noted by Ralph Droms. I will clarify in an updated version. The main purpose was to only use capitalized words for protocol-releated requirements. Nodal requirements are written in the document as guidelines but not as absolute design requirements. Therefore RFC 2119 was not intended to applly to the nodal requirements. section 4.1 -=20 "The ANCP MUST address all use cases described in this document" - there are many use cases in the document - it seems to me that requiring support for all use cases is not needed for interoperability and limits a vendor's ability to design a product for a specific need. (See RFC 2119 section 6) =20 "The ANCP MUST be flexible enough to accommodate the various technologies that can be used in an access network and in the Access Node." if this means Ethernet & ATM say so - if it means more - say so . "The Access Node Control interactions MUST be reliable (using either a reliable transport protocol (e.g. TCP) for the Access Node Control Protocol messages, or by designing ANCP to be reliable)." - see above, I do not think that the time it would take to make the ANCP a reliable (and congestion responsive) protocol is nearly worth the effort. "The ANCP MUST allow fast-paced transactions, in order to provide real time transactions between a NAS and a fully populated Access Node." - without a definition of "fast-paced" this is an impossible requirement to meet "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently." - see previous comment section 4.2 "In case of Admission Control without AN Bandwidth Delegation, the ANCP must allow the NAS to reply to a query from the AN indicating whether or not a multicast flow may be replicated to a particular Access Port." - is this saying that it has permission or that this just could happen? "In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port for multicast services only." - "delegate " or "dedicate"? "In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the AN to autonomous release redundant multicast bandwidth on a given Access Port." - meaning that the protocol must include a way for the AN to say that it did this? - otherwise not sure how the requirement applies to the control protocol. - e.g. sections 4.6 and 4.7 are mixtures of protocol requirements and device requirements section 4.3=20 "The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes with limited control plane resources (e.g. CPU and memory)." - see previous two comments section 4.4 - Access Node Control Adjacency Requirements please be specific as to what this section is talking about - DSLAMs figuring out that ANs exist? adjacent DSLAMs? adjacent control systems? in same provider or different providers? section 4.6.1 - I did not understand the 1st paragraph in section 4.6.1 section 4.6.2 -=20 "The Access Node must process control transactions in real-time." - what does this mean? a specific data rate? a specific response latency? "The Access Node should mark Access Node Control Protocol messages with a high priority (e.g. VBR-rt for ATM cells, p-bit 6 or 7 for Ethernet packets) in order for the packets not to be dropped in case of congestion." - see 1st comment - this is a naive assumption section 4.6.5=20 2nd pp - sentence is not quite English and needs references for PPPoE and DHCP messages section 4.7.1 "The NAS must support learning of access loop attributes (e.g. net data rate), from its peer Access Node partitions via the Access Node Control Mechanism." - this is one way to phrase this but it seems to me that "learning" is not the right concept - it may be better to say that the access loop attributes used by the NAS are configured by the ANCP - this applies in a number of other cases "The NAS must correlate Access Node Control information with the RADIUS authorization process and related subscriber data." - I have no idea what this means "The NAS should support shaping traffic directed towards a particular access loop to include layer-1 and layer-2 encapsulation overhead information received for a specific access loop from the AN via the Access Node Control Mechanism." - no do I understand what this means there are many other requirements in this document that I find to be vague or incomplete - the above are just some examples Scott From Sven.Ooghe@alcatel-lucent.be Mon Jul 13 23:22:14 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E64D3A6D71; Mon, 13 Jul 2009 23:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 7YcYu+zMPBUp; Mon, 13 Jul 2009 23:22:13 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 839D13A68B9; Mon, 13 Jul 2009 23:22:12 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6E6M77k026751; Tue, 14 Jul 2009 08:22:08 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 08:22:07 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Jul 2009 08:22:07 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA0292939C@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSV review of draft-ietf-ancp-framework-10.txt Thread-Index: Acn4voERPs33U50PRzqwqvcBQxAtUgLAcYRQAABCDjA= References: <20090629133536.8D9DF1938B8C@newdev.eecs.harvard.edu> From: "OOGHE Sven" To: "Scott O. Bradner" , X-OriginalArrivalTime: 14 Jul 2009 06:22:07.0948 (UTC) FILETIME=[69E9F8C0:01CA044B] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: ancp@ietf.org Subject: Re: [ANCP] TSV review of draft-ietf-ancp-framework-10.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, 14 Jul 2009 06:22:14 -0000 Scott Sorry, hit the send button too quickly. Thanks for reviewing. See inline. -----Original Message----- From: Scott O. Bradner [mailto:sob@harvard.edu]=20 Sent: maandag 29 juni 2009 15:36 To: tsv-dir@ietf.org Cc: ancp@ietf.org; haagt@telekom.de; michel.platnic@ecitele.com; norbert.voigt@nsn.com; OOGHE Sven; swadhwa@juniper.net Subject: TSV review of draft-ietf-ancp-framework-10.txt TSV-dir review of draft-ietf-ancp-framework-10.txt I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. The primary transport-related issue I see with the document is its some naive assumption that simple prioritization will mean that the control protocol will not experience congestion. (See, for example section 2.3) I would suggest that the document say that use of a IETF approved congestion aware reliable transport protocol (e.g., TCP or SCTP) be required for the control protocol wherever the control protocol is transported on IP. (Section 4.5)=20 The intent of the wording in section 2.3 was to prioritize the ANCP traffic over other sources of traffic. I agree that this does not by itself avoid packet loss, but it should reduce the likelihood of dropping packets. I propose to reword the text to reflect this, e.g.: "These ATM PVCs would then be given a high priority so that at times of network congestion, loss of the ATM cells carrying the Access Node Control Protocol is avoided or minimized." The abstract says that the purpose of the document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)). But the document is more than a framework document. As indicated by the title, the document also includes a set of requirements for an Access Node Control Mechanism. The document also includes a set of functional requirements for devices involved in such a system. It seems to me that the document is trying to do too much. =20 I will update the abstract to better reflect the purpose of the document. I find that the framework presented in this document to be complex and, too often, vague. I also find many of the requirements to be incomplete. a few examples - this is not an exhaustive list I note that there is a mixture of "MUST" and "must" - that could be confusing - since this is supposed to be framework & requirements documents it may be reasonable to not use RFC 2119 termonology This was also noted by Ralph Droms. I will clarify this in an updated version. The intent is to only use capitalized words for protocol-releated requirements. Nodal requirements are written in the document as guidelines but not as absolute design requirements. Therefore RFC 2119 does not to apply to the nodal requirements. section 4.1 -=20 "The ANCP MUST address all use cases described in this document" - there are many use cases in the document - it seems to me that requiring support for all use cases is not needed for interoperability and limits a vendor's ability to design a product for a specific need. (See RFC 2119 section 6) This is a protocol requirement, not a nodal requirement. It is intended to ensure that the protocol design done by the ANCP WG covers all the use cases defined in the ANCP framework document. It is NOT intended as a nodal requirement. "The ANCP MUST be flexible enough to accommodate the various technologies that can be used in an access network and in the Access Node." if this means Ethernet & ATM say so - if it means more - say so . I will edit to clarify that it refers to ATM and Ethernet.=20 "The Access Node Control interactions MUST be reliable (using either a reliable transport protocol (e.g. TCP) for the Access Node Control Protocol messages, or by designing ANCP to be reliable)." - see above, I do not think that the time it would take to make the ANCP a reliable (and congestion responsive) protocol is nearly worth the effort. The requiement is written in such a way that it may be TCP based. The framework document doesn't want to take a stance on what approach needs to be selected; that's up to the ANCP protocol team to decide. =20 "The ANCP MUST allow fast-paced transactions, in order to provide real time transactions between a NAS and a fully populated Access Node." - without a definition of "fast-paced" this is an impossible requirement to meet Correct. I will solicit feedback on the ANCP exploder and ask if this should be dropped. "The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently." - see previous comment See above. section 4.2 "In case of Admission Control without AN Bandwidth Delegation, the ANCP must allow the NAS to reply to a query from the AN indicating whether or not a multicast flow may be replicated to a particular Access Port." - is this saying that it has permission or that this just could happen? It refers to having permission to replicate. I will reword to clarify. "In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port for multicast services only." - "delegate " or "dedicate"? Delegate. "In case of Admission Control with AN Bandwidth Delegation, the ANCP must allow the AN to autonomous release redundant multicast bandwidth on a given Access Port." - meaning that the protocol must include a way for the AN to say that it did this? - otherwise not sure how the requirement applies to the control protocol. - e.g. sections 4.6 and 4.7 are mixtures of protocol requirements and device requirements This is indeed a protocol requirement, allowing the Access Node to inform the NAS that a certain portion of bandwdith has been freed up on an Access Port. I will reword/clarify. section 4.3=20 "The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes with limited control plane resources (e.g. CPU and memory)." - see previous two comments I will solicit feedback on the list. section 4.4 - Access Node Control Adjacency Requirements please be specific as to what this section is talking about - DSLAMs figuring out that ANs exist? adjacent DSLAMs? adjacent control systems? in same provider or different providers? The "Access Node Control Adjacency" is defined in the Definitions section. I'll add a reference. section 4.6.1 - I did not understand the 1st paragraph in section 4.6.1 Proposed rewording: "The Access Node Control Mechanism is defined to operate between an Access Node (AN) and a NAS. In some cases, one AN can be connected to more than one physical NAS devices (e.g. in case different wholesale service providers have different NAS devices). In such a model, the physical AN needs to be split in virtual ANs, each having its own Access Node Control reporting and/or enforcement function." section 4.6.2 -=20 "The Access Node must process control transactions in real-time." - what does this mean? a specific data rate? a specific response latency? The latter. I will edit the requirement to clarify ("i.e. with a specific response latency"). Admittedly, this is again a vague requirement, so I will bring it to the list. "The Access Node should mark Access Node Control Protocol messages with a high priority (e.g. VBR-rt for ATM cells, p-bit 6 or 7 for Ethernet packets) in order for the packets not to be dropped in case of congestion." - see 1st comment - this is a naive assumption I will reword to: "The Access Node should mark Access Node Control Protocol messages with a high priority (e.g. VBR-rt for ATM cells, p-bit 6 or 7 for Ethernet packets) in order to avoid or reduce the likelihood of dropping packets in case of network congestion. " section 4.6.5=20 2nd pp - sentence is not quite English and needs references for PPPoE and DHCP messages Proposed rewording: "In a Broadband Forum TR-101 network arcitecture, an Access Circuit Identifier (ACI), identifying an AN and Access Port, is added to DHCP and PPPoE messages. The NAS must use the same ACI format in ANCP messages in order to allow the NAS to correlate this information with the information present in DHCP and PPPoE messages." =20 section 4.7.1 "The NAS must support learning of access loop attributes (e.g. net data rate), from its peer Access Node partitions via the Access Node Control Mechanism." - this is one way to phrase this but it seems to me that "learning" is not the right concept - it may be better to say that the access loop attributes used by the NAS are configured by the ANCP - this applies in a number of other cases How about "The NAS must support *obtaining* access loop information (e.g. net data rate..." ? IMHO, the requirement leans more towards "learning" than towards "configuring". "The NAS must correlate Access Node Control information with the RADIUS authorization process and related subscriber data." - I have no idea what this means I will bring this to the list. "The NAS should support shaping traffic directed towards a particular access loop to include layer-1 and layer-2 encapsulation overhead information received for a specific access loop from the AN via the Access Node Control Mechanism." - no do I understand what this means Proposed rewording: "In a TR-059/TR-101 network architecture, the NAS shapes traffic sent to a particular Access Port according to the bitrate available on that port. The NAS should take into account the layer-1 and layer-2 encapsulation overhead on the Access Port, retrieved from the AN via the Access Node Control Mechanism." there are many other requirements in this document that I find to be vague or incomplete - the above are just some examples I appreciate your comments - they will help to improve the quality of the document. How do you suggest to proceed at this point? Are there other critical items in the document that must be tackled? =20 Regards Sven Scott From sob@harvard.edu Tue Jul 14 06:34:47 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADFF928C117; Tue, 14 Jul 2009 06:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id df4xudD8+JL0; Tue, 14 Jul 2009 06:34:47 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 17BF23A692B; Tue, 14 Jul 2009 06:34:18 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id F395F1A6C6A3; Tue, 14 Jul 2009 09:34:19 -0400 (EDT) To: sob@harvard.edu, Sven.Ooghe@alcatel-lucent.be, tsv-dir@ietf.org In-Reply-To: <7168964CAC5C144685272595141B6DBA0292939C@FRVELSMBS22.ad2.ad.alcatel.com> Message-Id: <20090714133419.F395F1A6C6A3@newdev.eecs.harvard.edu> Date: Tue, 14 Jul 2009 09:34:19 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Cc: ancp@ietf.org Subject: Re: [ANCP] TSV review of draft-ietf-ancp-framework-10.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, 14 Jul 2009 13:34:47 -0000 these proposed changes loook fine to me > How do you suggest to proceed at this point? > Are there other critical items in the document that must be tackled? I suggest drafting someone new to walk through each requirement to be sure they make sense and are implementable Scott From Sven.Ooghe@alcatel-lucent.be Wed Jul 15 04:47:13 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3325C3A68E8 for ; Wed, 15 Jul 2009 04:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 OzDuvdoX04Jk for ; Wed, 15 Jul 2009 04:47:12 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 350203A67BD for ; Wed, 15 Jul 2009 04:47:12 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6FBiR8f017528; Wed, 15 Jul 2009 13:46:35 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 13:46:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 13:46:04 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA029895AE@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP framework - questions Thread-Index: AcoFQdWEzj+sxmTgQ4uH6/FSORzHFQ== From: "OOGHE Sven" To: X-OriginalArrivalTime: 15 Jul 2009 11:46:05.0815 (UTC) FILETIME=[D632D870:01CA0541] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: [ANCP] ANCP framework - questions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 11:47:13 -0000 All, During the IESG review a number of questions / comments were issued on draft-ietf-ancp-framework-10. The majority of the comments can be resolved fairly easily. I have been working on a -11 version and will upload it shortly. Before doing so, there are a few comments where I want to solicit feedback from this list. Below you can find the comment received + my proposed resolution. Please let me know if you are in agreement. If so, I will edit the document accordigly and post version 11. Regards, Sven --- Section 4.1 . The ANCP MUST allow fast-paced transactions, in order to provide real time transactions between a NAS and a fully populated Access Node. Remark received: without a definition of "fast-paced" this is an impossible requirement to meet. Can we be specific on this? According to me, there is nothing in the protocol that prevents fast-paced transactions from happening. If so, I feel it is probably better to drop this requirement. . The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently. I received a similar remark. Given this will remain a vague requirement which is not protocol-specific, I would be inclined to drop it. Section 4.3 . The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes with limited control plane resources (e.g. CPU and memory)." Same comment received. I suggest to reword this to " The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes that does not specifically require additional control plane resources (e.g. additional CPU and memory requirements)." Section 4.6.2 . The Access Node must process control transactions in real-time (i.e. with a specific response latency). Can we be more specific here? I suggest to maintain the requirement as-is (it is a nodal requirement with uncapitalized "must"). Section 4.7.1 . The NAS must correlate Access Node Control information with the RADIUS authorization process and related subscriber data. Given that this is not a protocol requirement but an architecture requirement, it doesn't belong in this draft. I propose do remove this requirement. From alan.kavanagh@ericsson.com Thu Jul 16 08:04:27 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0B93A67AC for ; Thu, 16 Jul 2009 08:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.434 X-Spam-Level: X-Spam-Status: No, score=-5.434 tagged_above=-999 required=5 tests=[AWL=1.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmekoIa8LsSJ for ; Thu, 16 Jul 2009 08:04:26 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5E38D3A6A83 for ; Thu, 16 Jul 2009 08:04:19 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6GF4jlY015242; Thu, 16 Jul 2009 10:04:47 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 10:03:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Jul 2009 11:03:39 -0400 Message-ID: <35815C929B41D2479A224FE098A27227078B5C9D@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <7168964CAC5C144685272595141B6DBA029895AE@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP framework - questions Thread-Index: AcoFQdWEzj+sxmTgQ4uH6/FSORzHFQA5LltA References: <7168964CAC5C144685272595141B6DBA029895AE@FRVELSMBS22.ad2.ad.alcatel.com> From: "Alan Kavanagh" To: "OOGHE Sven" , X-OriginalArrivalTime: 16 Jul 2009 15:03:40.0436 (UTC) FILETIME=[9A843540:01CA0626] Subject: Re: [ANCP] ANCP framework - questions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2009 15:04:27 -0000 Hi Sven Im fine with the suggested changes. Alan=20 -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: July 15, 2009 7:46 AM To: ancp@ietf.org Subject: [ANCP] ANCP framework - questions All, During the IESG review a number of questions / comments were issued on draft-ietf-ancp-framework-10. The majority of the comments can be resolved fairly easily. I have been working on a -11 version and will upload it shortly. Before doing so, there are a few comments where I want to solicit feedback from this list. Below you can find the comment received + my proposed resolution. Please let me know if you are in agreement. If so, I will edit the document accordigly and post version 11. Regards, Sven --- Section 4.1 . The ANCP MUST allow fast-paced transactions, in order to provide real time transactions between a NAS and a fully populated Access Node. Remark received: without a definition of "fast-paced" this is an impossible requirement to meet. Can we be specific on this? According to me, there is nothing in the protocol that prevents fast-paced transactions from happening. If so, I feel it is probably better to drop this requirement. . The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently. I received a similar remark. Given this will remain a vague requirement which is not protocol-specific, I would be inclined to drop it. Section 4.3 . The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes with limited control plane resources (e.g. CPU and memory)." Same comment received. I suggest to reword this to " The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes that does not specifically require additional control plane resources (e.g. additional CPU and memory requirements)." Section 4.6.2 . The Access Node must process control transactions in real-time (i.e. with a specific response latency). Can we be more specific here? I suggest to maintain the requirement as-is (it is a nodal requirement with uncapitalized "must"). Section 4.7.1 . The NAS must correlate Access Node Control information with the RADIUS authorization process and related subscriber data. Given that this is not a protocol requirement but an architecture requirement, it doesn't belong in this draft. I propose do remove this requirement. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From Sven.Ooghe@alcatel-lucent.be Fri Jul 17 06:22:54 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E67128C2E3 for ; Fri, 17 Jul 2009 06:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 YM4bIAIdvoIF for ; Fri, 17 Jul 2009 06:22:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 6C17A3A68B3 for ; Fri, 17 Jul 2009 06:22:52 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6HDMSgS018904 for ; Fri, 17 Jul 2009 15:22:28 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:22:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Jul 2009 15:22:27 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA02989E4D@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <7168964CAC5C144685272595141B6DBA029895AE@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP framework - questions Thread-Index: AcoFQdWEzj+sxmTgQ4uH6/FSORzHFQBcr9Gg References: <7168964CAC5C144685272595141B6DBA029895AE@FRVELSMBS22.ad2.ad.alcatel.com> From: "OOGHE Sven" To: X-OriginalArrivalTime: 17 Jul 2009 13:22:28.0427 (UTC) FILETIME=[A1BAE9B0:01CA06E1] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [ANCP] ANCP framework - questions X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 13:22:54 -0000 All, So far I have received one positive response to the below proposed resolution. I intend to make these changes and submit version 11 on Monday. Regards Sven -----Original Message----- From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: woensdag 15 juli 2009 13:46 To: ancp@ietf.org Subject: [ANCP] ANCP framework - questions All, During the IESG review a number of questions / comments were issued on draft-ietf-ancp-framework-10. The majority of the comments can be resolved fairly easily. I have been working on a -11 version and will upload it shortly. Before doing so, there are a few comments where I want to solicit feedback from this list. Below you can find the comment received + my proposed resolution. Please let me know if you are in agreement. If so, I will edit the document accordigly and post version 11. Regards, Sven --- Section 4.1 . The ANCP MUST allow fast-paced transactions, in order to provide real time transactions between a NAS and a fully populated Access Node. Remark received: without a definition of "fast-paced" this is an impossible requirement to meet. Can we be specific on this? According to me, there is nothing in the protocol that prevents fast-paced transactions from happening. If so, I feel it is probably better to drop this requirement. . The ANCP SHOULD support a means to handle sending/receiving a large burst of messages efficiently. I received a similar remark. Given this will remain a vague requirement which is not protocol-specific, I would be inclined to drop it. Section 4.3 . The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes with limited control plane resources (e.g. CPU and memory)." Same comment received. I suggest to reword this to " The ANCP MUST be simple and lightweight enough to allow an implementation on Access Nodes that does not specifically require additional control plane resources (e.g. additional CPU and memory requirements)." Section 4.6.2 . The Access Node must process control transactions in real-time (i.e. with a specific response latency). Can we be more specific here? I suggest to maintain the requirement as-is (it is a nodal requirement with uncapitalized "must"). Section 4.7.1 . The NAS must correlate Access Node Control information with the RADIUS authorization process and related subscriber data. Given that this is not a protocol requirement but an architecture requirement, it doesn't belong in this draft. I propose do remove this requirement. _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp From HaagT@telekom.de Fri Jul 17 08:27:16 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6998C3A6AA6 for ; Fri, 17 Jul 2009 08:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, 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 BxdqvL8-MWCR for ; Fri, 17 Jul 2009 08:27:11 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 64A1C3A680E for ; Fri, 17 Jul 2009 08:27:09 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 17 Jul 2009 17:26:07 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 17:26:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA06F2.E7CD4292" Date: Fri, 17 Jul 2009 17:26:06 +0200 Message-ID: <5661758E3E93364685B91DD8272F2876018B2EA0@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF75 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhQIA02Dg References: From: To: X-OriginalArrivalTime: 17 Jul 2009 15:26:07.0659 (UTC) FILETIME=[E7EFDFB0:01CA06F2] Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 15:27:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA06F2.E7CD4292 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi all, =20 allthough discussed in the past the issue of coding a protocol version field for ancp seems to be unavoidable.=20 Earlier discussions ended up with the assumption that one final protocol draft will exist covering the whole ancp story.=20 =20 This assumption is not longer valid because of four reasons: =20 =20 1. Today four use cases have been identified, three are described in detail in the protocol specification (Topology discovery, OAM, Multicast).=20 Use Case line configuration is described briefly but not finally with all paramters and corresponidng TLVs. The latter use case is most flexible and not all-embraced described because the expected=20 paramterset is not fixed today =20 2. Broadband Forum started in march 2009 a new working text dealing with new requirements, new use cases. ANCP should be prepared for tackeling the issue that the protocol spec will have=20 continous requirements tackling in future different versions. Considering this today makes ancp future proof. =20 3. Allthough framework of ancp describes the usage for ancp for DSL access, latest activities show that ancp can also be used for other technologies like PON.=20 Therefore it is expected that dependend on adressed technology ancp has to be open for future use - an important requirment for versioning. =20 4. Existing pre versions showing field proof implemtation of ancp have to be recognised as well and to be handled in the same manner. Therefore an indication is neccessary to identifiy protocol versions. =20 =20 =20 Facing all listed issues an operator needs to identify ancp versions because nobody in the world will upgrade 1 BRAS and up 5000 access nodes simoultanously. This has to be recognised making ancp carrier grade. =20 Therefore I propose ancp working group to address this issue in the agenda for the upcoming meeting in stockholm, to discuss it and find a solution to handle the facing challenges which helps industry and operators. =20 Ad hoc I can think of two options solving this issue: =20 Option 1: use the sub version field for ANCP - Versioning (because it is derived from GSMP but not needed any more for ANCP purpose) =20 Option 2: define a new field or TLV for Version purpose =20 =20 Best regards =20 Thomas Haag =20 _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Dienstag, 7. Juli 2009 12:05 An: ancp@ietf.org Betreff: [ANCP] Agenda items for IETF75 ANCP WG meeting Hi All,=20 We're taking requests for slots in the agenda for our next ANCP WG meeting in Stockholm. Please respond with any requests. Thanks,=20 Matthew & Woj=20 ------_=_NextPart_001_01CA06F2.E7CD4292 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Agenda items for IETF75 ANCP WG meeting

Hi all,

allthough discussed in the past the issue of = coding a=20 protocol version field for ancp seems to be unavoidable. =

Earlier discussions ended up with the = assumption=20 that one final protocol draft will exist covering the whole ancp = story.=20

This assumption is not longer valid because=20 of four reasons:

1. Today four use cases have been = identified, =20 three are described in detail in the protocol specification (Topology = discovery,=20 OAM, Multicast).
Use Case line configuration is = described=20 briefly but not finally with all paramters and corresponidng TLVs. The = latter=20 use case is most flexible and not all-embraced described because the = expected=20
paramterset is not fixed = today

2. Broadband Forum started in march 2009 a = new working=20 text dealing with new requirements, new use cases. ANCP should be = prepared for=20 tackeling the issue that the protocol spec will have =
=20 continous requirements tackling in future different versions. = Considering this=20 today makes ancp future proof.

3. Allthough framework of ancp describes the = usage for=20 ancp for DSL access, latest activities show that ancp can also be used = for other=20 technologies like PON.
Therefore it is expected = that=20 dependend on adressed technology ancp has to be open for future use = - an=20 important requirment for versioning.

4. = Existing pre versions showing field=20 proof implemtation of ancp have to be recognised as well and to be = handled in=20 the same manner. Therefore an indication is neccessary to identifiy = protocol=20 versions.

Facing all listed issues an operator needs to = identify=20 ancp versions because nobody in the world will upgrade 1 BRAS and up = 5000 access=20 nodes simoultanously.

This has to be recognised making ancp carrier = grade.

Therefore I propose ancp working group to = address this=20 issue in the agenda for the upcoming meeting in stockholm, to discuss it = and=20 find a solution to handle the facing challenges which helps industry and = operators.

Ad hoc I can=20 think of two options solving this=20 issue:

Option 1: use the sub=20 version field for ANCP - Versioning (because it is derived from GSMP but = not=20 needed any more for ANCP purpose)

Option 2:=20 define a new field or TLV for Version=20 purpose

Best=20 regards

Thomas=20 Haag

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Dienstag, 7. Juli 2009 12:05
An:=20 ancp@ietf.org
Betreff: [ANCP] Agenda items for IETF75 ANCP WG=20 meeting

Hi All,

We're taking requests for slots = in the agenda=20 for our next ANCP WG meeting in Stockholm. Please respond with any=20 requests.

Thanks,
Matthew & Woj

------_=_NextPart_001_01CA06F2.E7CD4292-- From Sidd.Aanand@ecitele.com Fri Jul 17 08:55:51 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767723A6893 for ; Fri, 17 Jul 2009 08:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb88j+sfoHOW for ; Fri, 17 Jul 2009 08:55:50 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 2E5143A677C for ; Fri, 17 Jul 2009 08:55:48 -0700 (PDT) Received: from unknown (HELO ILPTAM01.ecitele.com) ([147.234.244.44]) by ilptiron01.ecitele.com with ESMTP; 17 Jul 2009 18:48:49 +0300 Received: from ilptexch01.ecitele.com ([172.31.244.40]) by ILPTAM01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 18:54:03 +0300 Received: from ilptextms01.ecitele.com (147.234.245.175) by ilptexch01.ecitele.com (172.31.244.40) with Microsoft SMTP Server id 8.1.375.2; Fri, 17 Jul 2009 18:54:03 +0300 Received: from USPITMAIL02.ecitele.com ([10.0.0.30]) by ilptextms01.ecitele.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 18:54:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA06F6.CD750F5C" Date: Fri, 17 Jul 2009 11:54:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF75 ANCP WG meeting Thread-Index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhQIA02DgAAI59FA= References: <5661758E3E93364685B91DD8272F2876018B2EA0@S4DE8PSAAQC.mitte.t-com.de> From: Sidd Aanand To: , X-OriginalArrivalTime: 17 Jul 2009 15:54:03.0334 (UTC) FILETIME=[CEB79660:01CA06F6] Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 15:55:51 -0000 ------_=_NextPart_001_01CA06F6.CD750F5C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thomas, I am not sure I understand the problem here. There is already a version, sub-version field defined in the current draft that get set to 3 and 1 respectively. Are we trying to define a method so that different version/sub-version implementations can handshake prior to establishing an adjacency or is there some other problem. =20 Thanks, Sidd ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de Sent: Friday, July 17, 2009 11:26 AM To: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting Hi all, =20 allthough discussed in the past the issue of coding a protocol version field for ancp seems to be unavoidable.=20 Earlier discussions ended up with the assumption that one final protocol draft will exist covering the whole ancp story.=20 =20 This assumption is not longer valid because of four reasons: =20 =20 1. Today four use cases have been identified, three are described in detail in the protocol specification (Topology discovery, OAM, Multicast).=20 Use Case line configuration is described briefly but not finally with all paramters and corresponidng TLVs. The latter use case is most flexible and not all-embraced described because the expected=20 paramterset is not fixed today =20 2. Broadband Forum started in march 2009 a new working text dealing with new requirements, new use cases. ANCP should be prepared for tackeling the issue that the protocol spec will have=20 continous requirements tackling in future different versions. Considering this today makes ancp future proof. =20 3. Allthough framework of ancp describes the usage for ancp for DSL access, latest activities show that ancp can also be used for other technologies like PON.=20 Therefore it is expected that dependend on adressed technology ancp has to be open for future use - an important requirment for versioning. =20 4. Existing pre versions showing field proof implemtation of ancp have to be recognised as well and to be handled in the same manner. Therefore an indication is neccessary to identifiy protocol versions. =20 =20 =20 Facing all listed issues an operator needs to identify ancp versions because nobody in the world will upgrade 1 BRAS and up 5000 access nodes simoultanously. This has to be recognised making ancp carrier grade. =20 Therefore I propose ancp working group to address this issue in the agenda for the upcoming meeting in stockholm, to discuss it and find a solution to handle the facing challenges which helps industry and operators. =20 Ad hoc I can think of two options solving this issue: =20 Option 1: use the sub version field for ANCP - Versioning (because it is derived from GSMP but not needed any more for ANCP purpose) =20 Option 2: define a new field or TLV for Version purpose =20 =20 Best regards =20 Thomas Haag =20 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Dienstag, 7. Juli 2009 12:05 An: ancp@ietf.org Betreff: [ANCP] Agenda items for IETF75 ANCP WG meeting Hi All,=20 We're taking requests for slots in the agenda for our next ANCP WG meeting in Stockholm. Please respond with any requests. Thanks,=20 Matthew & Woj=20 ------_=_NextPart_001_01CA06F6.CD750F5C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda items for IETF75 ANCP WG meeting

Thomas,

I am not sure=20 I understand the problem here. There is already a version, sub-version = field=20 defined in the current draft that get set to 3 and 1 respectively. Are = we trying=20 to define a method so that different version/sub-version implementations = can=20 handshake prior to establishing an adjacency or is there some other=20 problem.

Thanks,

Sidd

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of=20 HaagT@telekom.de
Sent: Friday, July 17, 2009 11:26=20 AM
To: ancp@ietf.org
Subject: Re: [ANCP] Agenda = items for=20 IETF75 ANCP WG meeting

Hi all,

allthough discussed in the past the issue of = coding a=20 protocol version field for ancp seems to be unavoidable. =

Earlier discussions ended up with the = assumption=20 that one final protocol draft will exist covering the whole ancp = story.=20

This assumption is not longer valid because=20 of four reasons:

Facing all listed issues an operator needs to = identify=20 ancp versions because nobody in the world will upgrade 1 BRAS and up = 5000 access=20 nodes simoultanously.

This has to be recognised making ancp carrier = grade.

Ad hoc I can=20 think of two options solving this=20 issue:

Option 1: use the sub=20 version field for ANCP - Versioning (because it is derived from GSMP but = not=20 needed any more for ANCP purpose)

Option 2:=20 define a new field or TLV for Version=20 purpose

Best=20 regards

Thomas=20 Haag

Hi All,

We're taking requests for slots = in the agenda=20 for our next ANCP WG meeting in Stockholm. Please respond with any=20 requests.

Thanks,
Matthew & Woj

------_=_NextPart_001_01CA06F6.CD750F5C-- From tom.taylor@rogers.com Fri Jul 17 09:01:47 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392C73A6834 for ; Fri, 17 Jul 2009 09:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSxDl1lQTdZS for ; Fri, 17 Jul 2009 09:01:46 -0700 (PDT) Received: from smtp111.rog.mail.re2.yahoo.com (smtp111.rog.mail.re2.yahoo.com [206.190.37.1]) by core3.amsl.com (Postfix) with SMTP id 161313A69D4 for ; Fri, 17 Jul 2009 09:01:45 -0700 (PDT) Received: (qmail 38988 invoked from network); 17 Jul 2009 16:02:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=B0bDsna72dyBE1RVAB/zahyK9c76vhkV9CCMwnQRDv9pHygbR+oCrYDJiLSOqqv1zstlmqCCd+ZOowiR4345cyNgeZ4VqZaV33ze3HCS37rOS0Or1tEI5FNZyqVtNmAFJtaXWBgbp/bYVt8plcQjahvo4Hu7lQCnZ3M537tVZjA= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp111.rog.mail.re2.yahoo.com with SMTP; 17 Jul 2009 16:02:07 -0000 X-YMail-OSG: pn5kKRQVM1nSLxorl3siQ7PrsXFq5gQwOyn8pl3g.wQ47OZpJbCVTghe.b9TYBpg_w-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A60A07B.7040803@rogers.com> Date: Fri, 17 Jul 2009 12:02:03 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: HaagT@telekom.de References: <5661758E3E93364685B91DD8272F2876018B2EA0@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <5661758E3E93364685B91DD8272F2876018B2EA0@S4DE8PSAAQC.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2009 16:01:47 -0000 Don't the capabilities satisfy this requirement? HaagT@telekom.de wrote: > Hi all, > > allthough discussed in the past the issue of coding a protocol version > field for ancp seems to be unavoidable. > Earlier discussions ended up with the assumption that one final protocol > draft will exist covering the whole ancp story. > > This assumption is not longer valid because of four reasons: > > > 1. Today four use cases have been identified, three are described in > detail in the protocol specification (Topology discovery, OAM, Multicast). > Use Case line configuration is described briefly but not finally > with all paramters and corresponidng TLVs. The latter use case is most > flexible and not all-embraced described because the expected > paramterset is not fixed today > > 2. Broadband Forum started in march 2009 a new working text dealing with > new requirements, new use cases. ANCP should be prepared for tackeling > the issue that the protocol spec will have > continous requirements tackling in future different versions. > Considering this today makes ancp future proof. > > 3. Allthough framework of ancp describes the usage for ancp for DSL > access, latest activities show that ancp can also be used for other > technologies like PON. > Therefore it is expected that dependend on adressed technology ancp > has to be open for future use - an important requirment for versioning. > > 4. Existing pre versions showing field proof implemtation of ancp have > to be recognised as well and to be handled in the same manner. Therefore > an indication is neccessary to identifiy protocol versions. > > > > Facing all listed issues an operator needs to identify ancp versions > because nobody in the world will upgrade 1 BRAS and up 5000 access nodes > simoultanously. > This has to be recognised making ancp carrier grade. > > Therefore I propose ancp working group to address this issue in the > agenda for the upcoming meeting in stockholm, to discuss it and find a > solution to handle the facing challenges which helps industry and operators. > > Ad hoc I can think of two options solving this issue: > > Option 1: use the sub version field for ANCP - Versioning (because it is > derived from GSMP but not needed any more for ANCP purpose) > > Option 2: define a new field or TLV for Version purpose > > > Best regards > > Thomas Haag > > > ------------------------------------------------------------------------ > *Von:* ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] *Im Auftrag > von *Wojciech Dec (wdec) > *Gesendet:* Dienstag, 7. Juli 2009 12:05 > *An:* ancp@ietf.org > *Betreff:* [ANCP] Agenda items for IETF75 ANCP WG meeting > > Hi All, > > > We're taking requests for slots in the agenda for our next ANCP WG > meeting in Stockholm. Please respond with any requests. > > Thanks, > Matthew & Woj > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From fqhuang@huawei.com Sun Jul 19 19:36:43 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCB6E3A6CE6 for ; Sun, 19 Jul 2009 19:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.804 X-Spam-Level: ** X-Spam-Status: No, score=2.804 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 hfeclRqZrNnY for ; Sun, 19 Jul 2009 19:36:33 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 865A83A6CB8 for ; Sun, 19 Jul 2009 19:36:32 -0700 (PDT) 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 <0KN20038X78LGN@szxga04-in.huawei.com> for ancp@ietf.org; Mon, 20 Jul 2009 10:36:21 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN200KG078LY5@szxga04-in.huawei.com> for ancp@ietf.org; Mon, 20 Jul 2009 10:36:21 +0800 (CST) Received: from h36145c ([10.70.39.54]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN200JTV78K68@szxml04-in.huawei.com> for ancp@ietf.org; Mon, 20 Jul 2009 10:36:21 +0800 (CST) Date: Mon, 20 Jul 2009 10:36:20 +0800 From: Fortune HUANG To: ancp@ietf.org Message-id: <002601ca08e2$ddd95780$3627460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_bo/VkoKMd1r/WMNJil6VLg)" Thread-index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQAHpyZPABolJpoAAHJt9gABs/BsARfZWC8A== Subject: [ANCP] A Question about draft-ietf-ancp-protocol-06 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, 20 Jul 2009 02:36:44 -0000 This is a multi-part message in MIME format. --Boundary_(ID_bo/VkoKMd1r/WMNJil6VLg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, Sanjay and I agree on the following points below in the email thread "Question about the Tech Type in draft-ietf-ancp-protocol-05" (attached below). "Given "Tech type" is not part of base GSMP RFC, and is an ANCP specific extension, it makes sense to define ANCP specific "Tech type" registry where 0x01-0x04 should be available for allocation (we can update the ANCP protocol draft). We don't need to change what has been allocated for DSL (0x05) though. We will need to allocate a value for PON." Given no negative response received, I almost assumed those points were acceptable. But I don't know why those points were not implemented in the -06 version. I would also like to know if there were any concerns about those points, please. Best regards, Fortune _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Wednesday, April 22, 2009 9:11 AM To: 'Sanjay Wadhwa'; ancp@ietf.org Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Hi Sanjay, Thank you very much for your answer. I agree with your opinion that we should keep 0x05 for DSL. Given 0x01~0x04 should be available for allocation, I propose to allocate 0x01 for PON. Is it acceptable, please? Best Regards, Fortune _____ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: Tuesday, April 21, 2009 8:25 PM To: Fortune HUANG; ancp@ietf.org Subject: RE: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Fortune Tech Type was originally specified in GSMPv3 drafts (post RFC). 0x01-0x04 was intended to be allocated for existing technologies that were trying to leverage GSMP at the time. Given "Tech type" is not part of base GSMP RFC, and is an ANCP specific extension, it makes sense to define ANCP specific "Tech type" registry where 0x01-0x04 should be available for allocation (we can update the ANCP protocol draft). We don't need to change what has been allocated for DSL (0x05) though. We will need to allocate a value for PON. Regards -Sanjay _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Tuesday, April 21, 2009 5:20 AM To: ancp@ietf.org Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Hi all, Given no further response on this thread, I assume almost none of the people in the ANCP mailing list knows what those technologies indicated by Tech Type values of 0x01~0x04 are. If Sanjay was right that the Tech Type would a new IANA registry, then according to the charter of ANCP WG, only the DSL and PON (newly added) technologies should be defined and maybe we should withdraw the allocation of 0x01~0x04. But since PON is now in the charter, we should anyway allocate a Tech Type value for PON. Best Regards, Fortune _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Monday, April 13, 2009 9:17 AM To: 'Sanjay Wadhwa'; ancp@ietf.org Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Hi Sanjay, Thank you very much for your answer. But in the text in section 5.4.1.1 as follows, if the tech type is new registry, then what types of technologies are the 0x01 ~ 0x04 indicates respectively? I think they should be clearly specified, although I guess they might be 0x01 for 802.3, 0x02 for 802.11a/b/g, 0x03 for 802.163, 0x04 for 802.16m. Is it correct? "Tech Type An 8-bit field indicating the applicable technology type value. The Message Type plus the Tech Value uniquely define a single Extension Type and can be treated as a single 16 bit extension type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL technology. 0x00 Extension block not in use. 0x01 - 0x04 Already in use by various technologies 0x05 DSL 0x06 - 0xFE Reserved 0xFF Base Specification Use " Best Regards, Fortune _____ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] Sent: Friday, April 10, 2009 10:47 PM To: Fortune HUANG; ancp@ietf.org Subject: RE: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Hi Fortune The intent is to define an ANCP specific tech-type registry, and not take what MIP/PMIP uses as per your reference below. Regards -Sanjay _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG Sent: Tuesday, April 07, 2009 12:28 AM To: ancp@ietf.org Subject: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Hi all, I have a question about the Tech Type in ANCP protocol for clarification. It says "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL technology in section 5.4.1.1 of draft-ietf-ancp-protocol-05. I can find two related technology type registries at the website http://www.iana.org/protocols/ as follows, but the 0x05 has been allocated in both registries. Is the first registry with the name Access Technology Types the right registry for the Tech Type in ANCP protocol, please? If it is, I propose we change the 0x05 for DSL in section 5.4.1.1 to be 0x09 or "to be allocated by IANA" in order to avoid incorrect implementation. Registry Name: Access Technology Types Reference: [RFC-leung-mip4-proxy-mode-10.txt] Registration Procedures: Expert Review Registry: Value Name Reference -------- ------------------------------------------------- --------- 0 Reserved [RFC-leung-mip4-proxy-mode-10.txt] 1 802.3 [RFC-leung-mip4-proxy-mode-10.txt] 2 802.11a/b/g [RFC-leung-mip4-proxy-mode-10.txt] 3 802.16e [RFC-leung-mip4-proxy-mode-10.txt] 4 802.16m [RFC-leung-mip4-proxy-mode-10.txt] 5 3GPP EUTRAN/LTE [RFC-leung-mip4-proxy-mode-10.txt] 6 3GPP UTRAN/GERAN [RFC-leung-mip4-proxy-mode-10.txt] 7 3GPP2 1xRTT/HRPD [RFC-leung-mip4-proxy-mode-10.txt] 8 3GPP2 UMB [RFC-leung-mip4-proxy-mode-10.txt] 9-255 Unassigned Access Technology Type Option type values Reference [ RFC5213] Registration Procedures Expert Review Value Description Reference Registration Date 0 Reserved [ RFC5213] 1 Virtual [ RFC5213] 2 PPP [ RFC5213] 3 IEEE 802.3 [ RFC5213] 4 IEEE 802.11a/b/g [ RFC5213] 5 IEEE 802.16e [ RFC5213] 6 3GPP GERAN [ 3GPP TS 29.275][ Julien_Laganier] 2008-07-30 7 3GPP UTRAN [ 3GPP TS 29.275][ Julien_Laganier] 2008-07-30 8 3GPP E-UTRAN [ 3GPP TS 29.275][ Julien_Laganier] 2008-07-30 9 3GPP2 eHRPD [ 3GPP2 X.P0057][ Kuntal_Chowdhury] 2008-08-21 10 3GPP2 HRPD [ 3GPP2 X.P0061][ Kuntal_Chowdhury] 2008-08-21 11 3GPP2 1xRTT [ 3GPP2 X.S0011][ Kuntal_Chowdhury] 2008-08-21 12 3GPP2 UMB [ 3GPP2 X.S0054][ Kuntal_Chowdhury] 2008-08-21 13-255 Unassigned Best Regards, Fortune --Boundary_(ID_bo/VkoKMd1r/WMNJil6VLg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear all,

Sanjay and I agree on the following points below in the email thread "Question about the Tech Type in draft-ietf-ancp-protocol-05" (attached below).

"Given “Tech type” is not part of base GSMP RFC, and is an ANCP specific extension, it makes sense to define ANCP specific “Tech type” registry where 0x01-0x04 should be available for allocation (we can update the ANCP protocol draft). We don’t need to change what has been allocated for DSL (0x05) though. We will need to allocate a value for PON."

Given no negative response received, I almost assumed those points were acceptable. But I don't know why those points were not implemented in the -06 version. I would also like to know if there were any concerns about those points, please.

Best regards,

Fortune

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG
Sent: Wednesday, April 22, 2009 9:11 AM
To: 'Sanjay Wadhwa'; ancp@ietf.org
Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05

Hi Sanjay,

Thank you very much for your answer.

I agree with your opinion that we should keep 0x05 for DSL.

Given 0x01~0x04 should be available for allocation, I propose to allocate 0x01 for PON. Is it acceptable, please?

Best Regards,

Fortune

From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]
Sent: Tuesday, April 21, 2009 8:25 PM
To: Fortune HUANG; ancp@ietf.org
Subject: RE: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05

Fortune

Tech Type was originally specified in GSMPv3 drafts (post RFC). 0x01-0x04 was intended to be allocated for existing technologies that were trying to leverage GSMP at the time. Given “Tech type” is not part of base GSMP RFC, and is an ANCP specific extension, it makes sense to define ANCP specific “Tech type” registry where 0x01-0x04 should be available for allocation (we can update the ANCP protocol draft). We don’t need to change what has been allocated for DSL (0x05) though. We will need to allocate a value for PON.

Regards

-Sanjay

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG
Sent: Tuesday, April 21, 2009 5:20 AM
To: ancp@ietf.org
Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05

Hi all,

Given no further response on this thread, I assume almost none of the people in the ANCP mailing list knows what those technologies indicated by Tech Type values of 0x01~0x04 are.

If Sanjay was right that the Tech Type would a new IANA registry, then according to the charter of ANCP WG, only the DSL and PON (newly added) technologies should be defined and maybe we should withdraw the allocation of 0x01~0x04.

But since PON is now in the charter, we should anyway allocate a Tech Type value for PON.

Best Regards,

Fortune

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG
Sent: Monday, April 13, 2009 9:17 AM
To: 'Sanjay Wadhwa'; ancp@ietf.org
Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05

Hi Sanjay,

Thank you very much for your answer.

But in the text in section 5.4.1.1 as follows, if the tech type is new registry, then what types of technologies are the 0x01 ~ 0x04 indicates respectively? I think they should be clearly specified, although I guess they might be 0x01 for 802.3, 0x02 for 802.11a/b/g, 0x03 for 802.163, 0x04 for 802.16m. Is it correct?

"Tech Type

         An 8-bit field indicating the applicable technology type value.
         The Message Type plus the Tech Value uniquely define a single
         Extension Type and can be treated as a single 16 bit extension
         type. "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL
         technology.

0x00 Extension block not in use.

0x01 - 0x04 Already in use by various technologies

0x05 DSL

0x06 - 0xFE Reserved

0xFF Base Specification Use

Best Regards,

Fortune

From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]
Sent: Friday, April 10, 2009 10:47 PM
To: Fortune HUANG; ancp@ietf.org
Subject: RE: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05

Hi Fortune

The intent is to define an ANCP specific tech-type registry, and not take what MIP/PMIP uses as per your reference below.

Regards

-Sanjay

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Fortune HUANG
Sent: Tuesday, April 07, 2009 12:28 AM
To: ancp@ietf.org
Subject: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05

Hi all,

I have a question about the Tech Type in ANCP protocol for clarification.

It says "Tech Type" value of 0x05 SHOULD be used by ANCP for DSL technology in section 5.4.1.1 of draft-ietf-ancp-protocol-05.

I can find two related technology type registries at the website http://www.iana.org/protocols/ as follows, but the 0x05 has been allocated in both registries. Is the first registry with the name Access Technology Types the right registry for the Tech Type in ANCP protocol, please? If it is, I propose we change the 0x05 for DSL in section 5.4.1.1 to be 0x09 or "to be allocated by IANA" in order to avoid incorrect implementation.

Registry Name: Access Technology Types
Reference: [RFC-leung-mip4-proxy-mode-10.txt]
Registration Procedures: Expert Review

Registry:
Value     Name                                               Reference
-------- ------------------------------------------------- ---------
0         Reserved                                           [RFC-leung-mip4-proxy-mode-10.txt]
1         802.3                                              [RFC-leung-mip4-proxy-mode-10.txt]
2         802.11a/b/g                                        [RFC-leung-mip4-proxy-mode-10.txt]
3         802.16e                                            [RFC-leung-mip4-proxy-mode-10.txt]
4         802.16m                                            [RFC-leung-mip4-proxy-mode-10.txt]
5         3GPP EUTRAN/LTE                                    [RFC-leung-mip4-proxy-mode-10.txt]
6         3GPP UTRAN/GERAN                                   [RFC-leung-mip4-proxy-mode-10.txt]
7         3GPP2 1xRTT/HRPD                                   [RFC-leung-mip4-proxy-mode-10.txt]
8         3GPP2 UMB                                          [RFC-leung-mip4-proxy-mode-10.txt]
9-255     Unassigned

Access Technology Type Option type values

Reference

[RFC5213]

Registration Procedures

Expert Review

Value	Description	Reference	Registration Date
0	Reserved	[RFC5213]
1	Virtual	[RFC5213]
2	PPP	[RFC5213]
3	IEEE 802.3	[RFC5213]
4	IEEE 802.11a/b/g	[RFC5213]
5	IEEE 802.16e	[RFC5213]
6	3GPP GERAN	[3GPP TS 29.275][Julien_Laganier]	2008-07-30
7	3GPP UTRAN	[3GPP TS 29.275][Julien_Laganier]	2008-07-30
8	3GPP E-UTRAN	[3GPP TS 29.275][Julien_Laganier]	2008-07-30
9	3GPP2 eHRPD	[3GPP2 X.P0057][Kuntal_Chowdhury]	2008-08-21
10	3GPP2 HRPD	[3GPP2 X.P0061][Kuntal_Chowdhury]	2008-08-21
11	3GPP2 1xRTT	[3GPP2 X.S0011][Kuntal_Chowdhury]	2008-08-21
12	3GPP2 UMB	[3GPP2 X.S0054][Kuntal_Chowdhury]	2008-08-21
13-255	Unassigned

Best Regards,

Fortune

--Boundary_(ID_bo/VkoKMd1r/WMNJil6VLg)-- From HaagT@telekom.de Mon Jul 20 00:07:31 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEFDD3A6AC9 for ; Mon, 20 Jul 2009 00:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.835 X-Spam-Level: X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, 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 Os-M0uiXbg8Z for ; Mon, 20 Jul 2009 00:07:24 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 53B183A68AC for ; Mon, 20 Jul 2009 00:07:23 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 20 Jul 2009 09:07:07 +0200 Received: from S4DE8PSAAQC.mitte.t-com.de ([10.151.229.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:07:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2009 09:07:06 +0200 Message-ID: <5661758E3E93364685B91DD8272F2876018B3076@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <4A60A07B.7040803@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Agenda items for IETF75 ANCP WG meeting Thread-Index: AcoG9/KcCu9T7v4SQgqBdxONiON+kQCEFnTg References: <5661758E3E93364685B91DD8272F2876018B2EA0@S4DE8PSAAQC.mitte.t-com.de> <4A60A07B.7040803@rogers.com> From: To: X-OriginalArrivalTime: 20 Jul 2009 07:07:07.0796 (UTC) FILETIME=[B1A09540:01CA0908] Cc: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting 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, 20 Jul 2009 07:07:31 -0000 Tom, no, the capabilities adresses the supported use cases only. As stated = not all use cases are coded finally. Requested versioning would provide a function distinguishing different = codes. Regards Thomas -----Urspr=FCngliche Nachricht----- Von: Tom Taylor [mailto:tom.taylor@rogers.com]=20 Gesendet: Freitag, 17. Juli 2009 18:02 An: Haag, Thomas Cc: ancp@ietf.org Betreff: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting Don't the capabilities satisfy this requirement? HaagT@telekom.de wrote: > Hi all, > =20 > allthough discussed in the past the issue of coding a protocol version = > field for ancp seems to be unavoidable. > Earlier discussions ended up with the assumption that one final = protocol=20 > draft will exist covering the whole ancp story. > =20 > This assumption is not longer valid because of four reasons: > =20 > =20 > 1. Today four use cases have been identified, three are described in=20 > detail in the protocol specification (Topology discovery, OAM, = Multicast). > Use Case line configuration is described briefly but not finally=20 > with all paramters and corresponidng TLVs. The latter use case is most = > flexible and not all-embraced described because the expected > paramterset is not fixed today > =20 > 2. Broadband Forum started in march 2009 a new working text dealing = with=20 > new requirements, new use cases. ANCP should be prepared for tackeling = > the issue that the protocol spec will have > continous requirements tackling in future different versions.=20 > Considering this today makes ancp future proof. > =20 > 3. Allthough framework of ancp describes the usage for ancp for DSL=20 > access, latest activities show that ancp can also be used for other=20 > technologies like PON. > Therefore it is expected that dependend on adressed technology = ancp=20 > has to be open for future use - an important requirment for = versioning. > =20 > 4. Existing pre versions showing field proof implemtation of ancp have = > to be recognised as well and to be handled in the same manner. = Therefore=20 > an indication is neccessary to identifiy protocol versions. > =20 > =20 > =20 > Facing all listed issues an operator needs to identify ancp versions=20 > because nobody in the world will upgrade 1 BRAS and up 5000 access = nodes=20 > simoultanously. > This has to be recognised making ancp carrier grade. > =20 > Therefore I propose ancp working group to address this issue in the=20 > agenda for the upcoming meeting in stockholm, to discuss it and find a = > solution to handle the facing challenges which helps industry and = operators. > =20 > Ad hoc I can think of two options solving this issue: > =20 > Option 1: use the sub version field for ANCP - Versioning (because it = is=20 > derived from GSMP but not needed any more for ANCP purpose) > =20 > Option 2: define a new field or TLV for Version purpose > =20 > =20 > Best regards > =20 > Thomas Haag > =20 >=20 > = ------------------------------------------------------------------------ > *Von:* ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] *Im = Auftrag=20 > von *Wojciech Dec (wdec) > *Gesendet:* Dienstag, 7. Juli 2009 12:05 > *An:* ancp@ietf.org > *Betreff:* [ANCP] Agenda items for IETF75 ANCP WG meeting >=20 > Hi All, >=20 >=20 > We're taking requests for slots in the agenda for our next ANCP WG=20 > meeting in Stockholm. Please respond with any requests. >=20 > Thanks, > Matthew & Woj >=20 >=20 > = ------------------------------------------------------------------------ >=20 > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From fqhuang@huawei.com Tue Jul 21 19:31:53 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45CF13A6859 for ; Tue, 21 Jul 2009 19:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.104 X-Spam-Level: *** X-Spam-Status: No, score=3.104 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkiwRpMO1foS for ; Tue, 21 Jul 2009 19:31:52 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 51C8F3A635F for ; Tue, 21 Jul 2009 19:31:52 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN5005BDWBEX5@szxga03-in.huawei.com> for ancp@ietf.org; Wed, 22 Jul 2009 10:30:50 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN500F4FWBEGF@szxga03-in.huawei.com> for ancp@ietf.org; Wed, 22 Jul 2009 10:30:50 +0800 (CST) Received: from h36145c ([10.70.39.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN500EKRWBESS@szxml06-in.huawei.com> for ancp@ietf.org; Wed, 22 Jul 2009 10:30:50 +0800 (CST) Date: Wed, 22 Jul 2009 10:30:50 +0800 From: Fortune HUANG To: ancp@ietf.org Message-id: <001a01ca0a74$6d7db740$3627460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_32cefqVgN1wlDUE8xEXKPQ)" Thread-index: AcoKdG1VLsZlKrrWQwej85hJkBck3w== Subject: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 02:31:53 -0000 This is a multi-part message in MIME format. --Boundary_(ID_32cefqVgN1wlDUE8xEXKPQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear all, The delegated bandwidth query request in draft-ietf-ancp-mc-extensions-00 is only triggered by the NAS(see section 4.8). However, I think the delegated bandwidth query request is also needed to be triggered by the AN. For example, AN requests to reallocate the delegated bw, NAS/PS does so but the response gets lost. In this case, the delegated bandwidth data in both sides may be inconsistent but only the AN knows this happens. I think the bandwidth query request triggered by the AN can be useful in this case. Best regards, Fortune --Boundary_(ID_32cefqVgN1wlDUE8xEXKPQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear all,

The delegated bandwidth query request in draft-ietf-ancp-mc-extensions-00 is only triggered by the NAS(see section 4.8). However, I think the delegated bandwidth query request is also needed to be triggered by the AN. For example, AN requests to reallocate the delegated bw, NAS/PS does so but the response gets lost. In this case, the delegated bandwidth data in both sides may be inconsistent but only the AN knows this happens. I think the bandwidth query request triggered by the AN can be useful in this case.

Best regards,
Fortune

--Boundary_(ID_32cefqVgN1wlDUE8xEXKPQ)-- From lihy@huawei.com Wed Jul 22 18:19:28 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2C743A6CA0 for ; Wed, 22 Jul 2009 18:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 t3XqxwXoq+53 for ; Wed, 22 Jul 2009 18:19:28 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 2C25D3A6CAC for ; Wed, 22 Jul 2009 18:18:53 -0700 (PDT) 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 <0KN700LTUNLRCZ@szxga04-in.huawei.com> for ancp@ietf.org; Thu, 23 Jul 2009 09:17:51 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN7000E1NLRJT@szxga04-in.huawei.com> for ancp@ietf.org; Thu, 23 Jul 2009 09:17:51 +0800 (CST) Received: from L26465 ([10.70.40.87]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN7000CMNLRY5@szxml04-in.huawei.com> for ancp@ietf.org; Thu, 23 Jul 2009 09:17:51 +0800 (CST) Date: Thu, 23 Jul 2009 09:17:55 +0800 From: Hongyu Li In-reply-to: <5661758E3E93364685B91DD8272F2876018B2EA0@S4DE8PSAAQC.mitte.t-com.de> To: HaagT@telekom.de, ancp@ietf.org Message-id: <005201ca0b33$68777fa0$5728460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_U7uWdLTrBXXKAwoL04VMkQ)" Thread-index: Acn+6ltl92lm+d4MS0WQoGhkOfvVhQIA02DgARFiNBA= Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 01:19:29 -0000 This is a multi-part message in MIME format. --Boundary_(ID_U7uWdLTrBXXKAwoL04VMkQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Since this is a problem we have to solve, it should be solved the earlier the better. Meeting in Stockholm is a good chance. Cheers, Hongyu _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de Sent: Friday, July 17, 2009 11:26 PM To: ancp@ietf.org Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting Hi all, allthough discussed in the past the issue of coding a protocol version field for ancp seems to be unavoidable. Earlier discussions ended up with the assumption that one final protocol draft will exist covering the whole ancp story. This assumption is not longer valid because of four reasons: 1. Today four use cases have been identified, three are described in detail in the protocol specification (Topology discovery, OAM, Multicast). Use Case line configuration is described briefly but not finally with all paramters and corresponidng TLVs. The latter use case is most flexible and not all-embraced described because the expected paramterset is not fixed today 2. Broadband Forum started in march 2009 a new working text dealing with new requirements, new use cases. ANCP should be prepared for tackeling the issue that the protocol spec will have continous requirements tackling in future different versions. Considering this today makes ancp future proof. 3. Allthough framework of ancp describes the usage for ancp for DSL access, latest activities show that ancp can also be used for other technologies like PON. Therefore it is expected that dependend on adressed technology ancp has to be open for future use - an important requirment for versioning. 4. Existing pre versions showing field proof implemtation of ancp have to be recognised as well and to be handled in the same manner. Therefore an indication is neccessary to identifiy protocol versions. Facing all listed issues an operator needs to identify ancp versions because nobody in the world will upgrade 1 BRAS and up 5000 access nodes simoultanously. This has to be recognised making ancp carrier grade. Therefore I propose ancp working group to address this issue in the agenda for the upcoming meeting in stockholm, to discuss it and find a solution to handle the facing challenges which helps industry and operators. Ad hoc I can think of two options solving this issue: Option 1: use the sub version field for ANCP - Versioning (because it is derived from GSMP but not needed any more for ANCP purpose) Option 2: define a new field or TLV for Version purpose Best regards Thomas Haag _____ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Dienstag, 7. Juli 2009 12:05 An: ancp@ietf.org Betreff: [ANCP] Agenda items for IETF75 ANCP WG meeting Hi All, We're taking requests for slots in the agenda for our next ANCP WG meeting in Stockholm. Please respond with any requests. Thanks, Matthew & Woj --Boundary_(ID_U7uWdLTrBXXKAwoL04VMkQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Agenda items for IETF75 ANCP WG meeting

Since this is a problem we have to solve, it should be solved the earlier the better. Meeting in Stockholm is a good chance.

Cheers,

Hongyu

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de
Sent: Friday, July 17, 2009 11:26 PM
To: ancp@ietf.org
Subject: Re: [ANCP] Agenda items for IETF75 ANCP WG meeting

Hi all,

allthough discussed in the past the issue of coding a protocol version field for ancp seems to be unavoidable.

Earlier discussions ended up with the assumption that one final protocol draft will exist covering the whole ancp story.

This assumption is not longer valid because of four reasons:

1. Today four use cases have been identified, three are described in detail in the protocol specification (Topology discovery, OAM, Multicast).
    Use Case line configuration is described briefly but not finally with all paramters and corresponidng TLVs. The latter use case is most flexible and not all-embraced described because the expected
    paramterset is not fixed today

2. Broadband Forum started in march 2009 a new working text dealing with new requirements, new use cases. ANCP should be prepared for tackeling the issue that the protocol spec will have
    continous requirements tackling in future different versions. Considering this today makes ancp future proof.

3. Allthough framework of ancp describes the usage for ancp for DSL access, latest activities show that ancp can also be used for other technologies like PON.
    Therefore it is expected that dependend on adressed technology ancp has to be open for future use - an important requirment for versioning.

4. Existing pre versions showing field proof implemtation of ancp have to be recognised as well and to be handled in the same manner. Therefore an indication is neccessary to identifiy protocol versions.

Facing all listed issues an operator needs to identify ancp versions because nobody in the world will upgrade 1 BRAS and up 5000 access nodes simoultanously.

This has to be recognised making ancp carrier grade.

Therefore I propose ancp working group to address this issue in the agenda for the upcoming meeting in stockholm, to discuss it and find a solution to handle the facing challenges which helps industry and operators.

Ad hoc I can think of two options solving this issue:

Option 1: use the sub version field for ANCP - Versioning (because it is derived from GSMP but not needed any more for ANCP purpose)

Option 2: define a new field or TLV for Version purpose

Best regards

Thomas Haag

Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec)
Gesendet: Dienstag, 7. Juli 2009 12:05
An: ancp@ietf.org
Betreff: [ANCP] Agenda items for IETF75 ANCP WG meeting

Hi All,

We're taking requests for slots in the agenda for our next ANCP WG meeting in Stockholm. Please respond with any requests.

Thanks,
Matthew & Woj

--Boundary_(ID_U7uWdLTrBXXKAwoL04VMkQ)-- From flefauch@cisco.com Thu Jul 23 05:56:20 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29983A6870 for ; Thu, 23 Jul 2009 05:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhya-RQmTJQX for ; Thu, 23 Jul 2009 05:56:19 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B2A433A63EB for ; Thu, 23 Jul 2009 05:56:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcAAIT6Z0qQ/uCKe2dsb2JhbACZcwEBFiQGnRyIJZEJBYQN X-IronPort-AV: E=Sophos;i="4.43,254,1246838400"; d="scan'208";a="45683018" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Jul 2009 12:53:19 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6NCrIuB012515; Thu, 23 Jul 2009 14:53:18 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6NCrIBS029011; Thu, 23 Jul 2009 12:53:18 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 14:53:18 +0200 Received: from ams-flefauch-8716.cisco.com ([10.55.161.199]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Jul 2009 14:53:17 +0200 Message-Id: <90A10D5C-4977-435A-927C-11705718D6AA@cisco.com> From: Francois Le Faucheur IMAP To: Tom Taylor Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 23 Jul 2009 14:53:16 +0200 X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 23 Jul 2009 12:53:18.0362 (UTC) FILETIME=[8D16AFA0:01CA0B94] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1231; t=1248353598; x=1249217598; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Admission=20Control=20notification=20for=20grey =20list |Sender:=20; bh=yWctdIJ+BRKQQY6B70LWmZPZl5crRFR3mD6Mjd3+WCQ=; b=Xpj7iNL0o++p2rtGV/mfpJfGZ2KEWzu9Zt2dUt+Q200dFZ6SmXQ3pTsWJK o+SgmVI7s2/GD3kTnKdjfY+RXd9l2qTc8/4N7UfJE2KrcjhTlr2XVDrV4hBt nqoz12/KCT; Authentication-Results: ams-dkim-1; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: ancp@ietf.org Subject: [ANCP] Admission Control notification for grey list X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 12:56:20 -0000 Tom and all, In section "5.1.1. Profile Processing At the Access Node" we currently have the following note: "[Editor's Note: for grey list requests, there is a currently unfulfilled need to indicate to the NAS (or require the NAS to know) whether admission control has been done at the AN. If so, the NAS can skip the admission control step and just apply policy.]" I am picturing a simple model for Bandwidth Delegation whereby: * if Bandwidth Delegation is activated on the AN, then the AN would always perform admission control (and therefore perform admission control for both white and grey groups) * If Bandwidth delegation is not activated on the AN, then the AN would never perform admission control (and therefore not perform admission control for both white and grey groups) With this model, it is very easy for the NAS to know whether admission control has been performed or not for a grey group (or for a white group for that matter): it purely depends on whether Bandwidth Delegation is activated on the AN or not. So, to me, there is not an unfulfilled need here and I'd propose to remove this editing note in next rev. Do you see an issue with that? Francois From tom.taylor@rogers.com Thu Jul 23 06:50:04 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4918B3A67B3 for ; Thu, 23 Jul 2009 06:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6y+Tf9yDLZpV for ; Thu, 23 Jul 2009 06:50:03 -0700 (PDT) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id 263B73A67CC for ; Thu, 23 Jul 2009 06:50:01 -0700 (PDT) Received: (qmail 9278 invoked from network); 23 Jul 2009 13:42:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=1M9Je3deJ5GurIAtZDJYdU//9GMiSXpgFC4FSXnfknw8TeH0nZWWmqS34YQJd66cyNg6mMYnm4TwUACbU9ZpZRS9QZ05N0X941g28d4x+IAvLim1eJ0WfFqQkMIcczkT9TFGb+QsmR9ZCoHwRj7XkkEeU7sNScq0NmZYwCPNxuw= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 23 Jul 2009 13:42:24 -0000 X-YMail-OSG: xULW3C8VM1mzMtDIx2gh7Dp5nLsIOOdMjA5Sj8l25x.Y4I00ZWfP0lGaPf_h1gpOQg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6868BE.1030809@rogers.com> Date: Thu, 23 Jul 2009 09:42:22 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Le Faucheur IMAP References: <90A10D5C-4977-435A-927C-11705718D6AA@cisco.com> In-Reply-To: <90A10D5C-4977-435A-927C-11705718D6AA@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] Admission Control notification for grey list X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 13:50:04 -0000 This seems reasonable to me. Francois Le Faucheur IMAP wrote: > Tom and all, > > In section "5.1.1. Profile Processing At the Access Node" we currently > have the following note: > "[Editor's Note: for grey list requests, there is a currently > unfulfilled need to indicate to the NAS (or require the NAS to know) > whether admission control has been done at the AN. If so, the NAS can > skip the admission control step and just apply policy.]" > > I am picturing a simple model for Bandwidth Delegation whereby: > * if Bandwidth Delegation is activated on the AN, then the AN would > always perform admission control (and therefore perform admission > control for both white and grey groups) > * If Bandwidth delegation is not activated on the AN, then the AN > would never perform admission control (and therefore not perform > admission control for both white and grey groups) > > With this model, it is very easy for the NAS to know whether admission > control has been performed or not for a grey group (or for a white group > for that matter): it purely depends on whether Bandwidth Delegation is > activated on the AN or not. > So, to me, there is not an unfulfilled need here and I'd propose to > remove this editing note in next rev. > Do you see an issue with that? > > Francois > > From root@core3.amsl.com Mon Jul 27 01:00:02 2009 Return-Path: X-Original-To: ancp@ietf.org Delivered-To: ancp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 33C8328C14C; Mon, 27 Jul 2009 01:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090727080002.33C8328C14C@core3.amsl.com> Date: Mon, 27 Jul 2009 01:00:02 -0700 (PDT) Cc: ancp@ietf.org Subject: [ANCP] I-D Action:draft-ietf-ancp-framework-11.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, 27 Jul 2009 08: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 : Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks Author(s) : S. Ooghe, et al. Filename : draft-ietf-ancp-framework-11.txt Pages : 55 Date : 2009-07-27 The purpose of this document is to define a framework for an Access Node Control Mechanism between a Network Access Server (NAS) and an Access Node (e.g. a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture in order to perform QoS-related, service-related and Subscriber-related operations. The Access Node Control Mechanism will ensure that the transmission of the information does not need to go through distinct element managers but rather using a direct device-device communication. This allows for performing access link related operations within those network elements, while avoiding impact on the existing Operational Support Systems (OSSes). This document first identifies a number of use cases for which the Access Node Control Mechanism may be appropriate. It then presents the requirements for the Access Node Control Protocol that must be taken into account during protocol design. Finally, it describes requirements for the network elements that need to support ANCP and the described use cases. These requirements should be seen as guidelines rather than as absolute requirements. RFC 2119 therefore does not apply to the nodal requirements. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ancp-framework-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27005152.I-D@ietf.org> --NextPart-- From flefauch@cisco.com Mon Jul 27 02:24:08 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1233A6C1C for ; Mon, 27 Jul 2009 02:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.456 X-Spam-Level: X-Spam-Status: No, score=-9.456 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJjvyqeA1aMr for ; Mon, 27 Jul 2009 02:24:02 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 2878E3A6C3F for ; Mon, 27 Jul 2009 02:23:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQAAEsPbUqQ/uCLe2dsb2JhbACCJS+XKwEBFiQGngCIKI1mBYQN X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208,217";a="45888373" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 27 Jul 2009 09:23:50 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6R9NodI027246; Mon, 27 Jul 2009 11:23:50 +0200 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6R9NoJ2004767; Mon, 27 Jul 2009 09:23:50 GMT Received: from xfe-ams-331.emea.cisco.com ([144.254.231.72]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:23:50 +0200 Received: from dhcp-15a6.meeting.ietf.org ([10.61.102.203]) by xfe-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Jul 2009 11:23:49 +0200 Message-Id: <098BFEAB-E693-4D80-BA6B-8CB2546204CB@cisco.com> From: Francois Le Faucheur IMAP To: Fortune HUANG In-Reply-To: <001a01ca0a74$6d7db740$3627460a@china.huawei.com> Content-Type: multipart/alternative; boundary=Apple-Mail-1--203510934 Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 27 Jul 2009 11:23:48 +0200 References: <001a01ca0a74$6d7db740$3627460a@china.huawei.com> X-Mailer: Apple Mail (2.935.3) X-OriginalArrivalTime: 27 Jul 2009 09:23:49.0637 (UTC) FILETIME=[F3327350:01CA0E9B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3658; t=1248686630; x=1249550630; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=flefauch@cisco.com; z=From:=20Francois=20Le=20Faucheur=20IMAP=20 |Subject:=20Re=3A=20[ANCP]=20About=20Delegated=20bandwidth= 20query=20in=20draft-ietf-ancp-mc-extensions-00 |Sender:=20; bh=lW1iH5p6i9fRlujXvLHGRJ2o3LVciC0dHw0rzL6G95g=; b=RnK5d/p7Se/a7C2uUEQRaYC4h5aOca3HmdNEfa6stiZlrrLeYC1qEMVJxB R+9QwQ+VrXBn0Ww2ZW+GnhYZ5GQ9HMUitvVM3m5BAWaf1Y76S+WkpYskvVW3 XxcSGOqia6; Authentication-Results: ams-dkim-2; header.From=flefauch@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: ancp@ietf.org Subject: Re: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:24:08 -0000 --Apple-Mail-1--203510934 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hello Fortune On 22 Jul 2009, at 04:30, Fortune HUANG wrote: > Dear all, > > The delegated bandwidth query request in draft-ietf-ancp-mc- > extensions-00 is only triggered by the NAS(see section 4.8). > However, I think the delegated bandwidth query request is also > needed to be triggered by the AN. For example, AN requests to > reallocate the delegated bw, NAS/PS does so but the response gets > lost. that should not happen too often since we are assuming reliable transport. > In this case, the delegated bandwidth data in both sides may be > inconsistent but only the AN knows this happens. I think the > bandwidth query request triggered by the AN can be useful in this > case. Is this situation not already addressed via the Delegated Bandwidth reset procedure of section 4.10? ie AN knows it has an invalid Delegated Bandwidth, so it triggers bandiwtdh delegation reset. Francois > > > Best regards, > Fortune > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp --Apple-Mail-1--203510934 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello = Fortune

On 22 Jul 2009, at 04:30, Fortune HUANG = wrote:

Dear all,

The delegated bandwidth = query request in draft-ietf-ancp-mc-extensions-00 is only triggered by = the NAS(see section 4.8). However, I think the delegated bandwidth query = request is also needed to be triggered by the = AN. For example, AN requests to reallocate the delegated bw, NAS/PS does = so but the response gets = lost.

that = should not happen too often since we are assuming reliable = transport.

In this case, the delegated bandwidth data in both sides = may be inconsistent but only the AN knows this happens. I think the = bandwidth query request triggered by the AN can be useful in this = case.

Is = this situation not already addressed via the Delegated Bandwidth reset = procedure of section 4.10?

ie AN knows it has an invalid = Delegated Bandwidth, so it triggers bandiwtdh delegation = reset.

Francois

=

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

= --Apple-Mail-1--203510934-- From shrirao@cisco.com Mon Jul 27 03:10:50 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 347073A6A4B for ; Mon, 27 Jul 2009 03:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzfAGXtmrk6J for ; Mon, 27 Jul 2009 03:10:49 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5C9913A684A for ; Mon, 27 Jul 2009 03:10:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIsabUqrR7MV/2dsb2JhbAC4MIgojWMFhA0 X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="40079703" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 27 Jul 2009 10:10:50 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6RAAoqS005267; Mon, 27 Jul 2009 03:10:50 -0700 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n6RAATpI017984; Mon, 27 Jul 2009 10:10:49 GMT Received: from xmb-bgl-416.cisco.com ([72.163.129.212]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 15:40:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Jul 2009 15:40:46 +0530 Message-ID: In-Reply-To: <098BFEAB-E693-4D80-BA6B-8CB2546204CB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] comments on draft-ietf-ancp-mc-extensions-00 Thread-Index: AcoOnAV52fkDnfygSeWHwWrZkeisfwABbPLg References: <001a01ca0a74$6d7db740$3627460a@china.huawei.com> <098BFEAB-E693-4D80-BA6B-8CB2546204CB@cisco.com> From: "Shridhar Rao (shrirao)" To: "Francois Le Faucheur (flefauch)" , , , X-OriginalArrivalTime: 27 Jul 2009 10:10:47.0266 (UTC) FILETIME=[82A28420:01CA0EA2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2745; t=1248689450; x=1249553450; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shrirao@cisco.com; z=From:=20=22Shridhar=20Rao=20(shrirao)=22=20 |Subject:=20=20[ANCP]=20comments=20on=20draft-ietf-ancp-mc- extensions-00 |Sender:=20; bh=+PlzFPRGO4uiA8Ggpwt8wa/YW6/I1XbOhErSfEPIdhI=; b=LNssjXBX3V5bng3ELbNHxe/rlXi0jpFTc3L89i8/YoPGfaJwQIMHzZHUZg zPEtsiVuDJQD74SUZNhIxNRf3u3oghGEKtaFSN3TVA/Bt998WyURx1Gibzvx 9de9fFm9qHL33YLKyIjz2s1HeM8NHz54gujZUEDrQkBQEr3hyDQh8=; Authentication-Results: sj-dkim-1; header.From=shrirao@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [ANCP] comments on draft-ietf-ancp-mc-extensions-00 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 10:10:50 -0000 =20 Hi folks, Some of my observations: I found that encoding of following can be made to be word aligned to make the coding simple and consistent:=20 1. Multicast-Service-Profile TLV (actually, I am referring to Single Multicast flow field inside this TLV) +-+-+-+-+-+-+-+-+ | Group PrefLen | +-+-+-+-+-+-+-+-+ | Source PrefLen| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Prefix (multicast) (0 to 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Prefix (unicast, SSM only) (0 to 16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ To make it word aligned, it's better to change Group Preflen and Source PrefLen fields to 16 bits instead of 8 bits, or we can add 2 bytes of padding immedtiately after Source PrefLen so that Group (or Source) Prefix starts at a word aligned address (it's easier to deal with word aligned addresses) 2. Multicast-Flow TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =3D Multicast-Flow | TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Flow Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Flow Source Address (Ctnd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Even here, we can make Addr Family and Encoding Type 16 bit fields to have Flow Addresses start from word aligned addresses. 3. Request-Source-IP sub-TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |sub-TLV Type =3D Request-Source-IP | Request-S-IP sub-TLV Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Unicast Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Same comment applies to this too. 4. Command TLV 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command Code |R O M Flags | Command Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Multicast Flow Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Multicast Flow Source Address (Ctnd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again, the same comments : make Addr Family and Encoding Type 16 bits fields. Thanks, -shridhar- From wdec@cisco.com Tue Jul 28 02:30:43 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95D73A6E98 for ; Tue, 28 Jul 2009 02:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+7y7mX2MQJT for ; Tue, 28 Jul 2009 02:30:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DDD9F3A6E8D for ; Tue, 28 Jul 2009 02:30:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAG9ibkqrR7O6/2dsb2JhbACCJS+3W4gnj0MFhAyBTQ X-IronPort-AV: E=Sophos;i="4.43,282,1246838400"; d="scan'208,217";a="355360643" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 28 Jul 2009 09:30:13 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6S9UDXS026811; Tue, 28 Jul 2009 02:30:13 -0700 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6S9U1xk001837; Tue, 28 Jul 2009 09:30:12 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:30:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0F66.016DAECD" Date: Tue, 28 Jul 2009 11:30:06 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtew== From: "Wojciech Dec (wdec)" To: X-OriginalArrivalTime: 28 Jul 2009 09:30:12.0450 (UTC) FILETIME=[01C8D420:01CA0F66] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3664; t=1248773413; x=1249637413; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20ANCP=20Protocol=20Versioning |Sender:=20; bh=0HhfJP+lLcpL1uqT18iMfjxtbRYKdcjZl1EtH7hptoQ=; b=Ciprw+L00rRjVZVwUj8lcyovWbuKmKR2WE/v/Dy+5TvRN55cK07aCy0UcL VrRvFyDeZnt3fXYAuirhx7DeJurb0wy5wkxvAjr+xGzkFuI+6UPYrUpSsuwo RkLlufQDq2; Authentication-Results: sj-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 09:30:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0F66.016DAECD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards, Woj.=20 ------_=_NextPart_001_01CA0F66.016DAECD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Protocol Versioning

Hi = All,

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

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

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

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

Regards,
Woj.

------_=_NextPart_001_01CA0F66.016DAECD-- From fqhuang@huawei.com Tue Jul 28 08:20:51 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D0D3A6AAB for ; Tue, 28 Jul 2009 08:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.849 X-Spam-Level: ** X-Spam-Status: No, score=2.849 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jv0dmUPZ4Gz3 for ; Tue, 28 Jul 2009 08:20:47 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 609CD3A6AD9 for ; Tue, 28 Jul 2009 08:20:46 -0700 (PDT) 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 <0KNH00EPUZY9LX@szxga04-in.huawei.com> for ancp@ietf.org; Tue, 28 Jul 2009 23:20:33 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KNH004EXZY32D@szxga04-in.huawei.com> for ancp@ietf.org; Tue, 28 Jul 2009 23:20:33 +0800 (CST) Received: from WWWE99ECC189FD (dhcp-14dd.meeting.ietf.org [130.129.20.221]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KNH006A3ZXV33@szxml01-in.huawei.com>; Tue, 28 Jul 2009 23:20:28 +0800 (CST) Date: Tue, 28 Jul 2009 17:20:23 +0200 From: Fortune HUANG In-reply-to: <098BFEAB-E693-4D80-BA6B-8CB2546204CB@cisco.com> To: 'Francois Le Faucheur IMAP' Message-id: <377C230C0C384DDE9028417DAB5A3B2D@WWWE99ECC189FD> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Wxl9jyXoSCESRYSSu8Mizg)" Thread-index: AcoOnZ/43H5GqTxdSaKzPgnXpw6J5gA9F9Lw Cc: ancp@ietf.org Subject: Re: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:20:51 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Wxl9jyXoSCESRYSSu8Mizg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello Francois, As said during the ANCP session yesterday, the reset procedure can address this situation, but the reset procedure itself is too heavy. There reasons are as follows: 1) In the example in my previous email, there is no need for the NAS/PS to stop admitting new requests. 2) In the example in my previous email, there is no need for the NAS/PS to query the AN's view of the delegation when the AN triggers the query. My proposal is to have a simple request-response query triggered by the AN. If the NAS/PS does need to know the AN's view of the delegation, this information can be carried in the request. Best regards, Fortune _____ From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] Sent: Monday, July 27, 2009 11:24 AM To: Fortune HUANG Cc: Francois Le Faucheur IMAP; ancp@ietf.org Subject: Re: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00 Hello Fortune On 22 Jul 2009, at 04:30, Fortune HUANG wrote: Dear all, The delegated bandwidth query request in draft-ietf-ancp-mc-extensions-00 is only triggered by the NAS(see section 4.8). However, I think the delegated bandwidth query request is also needed to be triggered by the AN. For example, AN requests to reallocate the delegated bw, NAS/PS does so but the response gets lost. that should not happen too often since we are assuming reliable transport. In this case, the delegated bandwidth data in both sides may be inconsistent but only the AN knows this happens. I think the bandwidth query request triggered by the AN can be useful in this case. Is this situation not already addressed via the Delegated Bandwidth reset procedure of section 4.10? ie AN knows it has an invalid Delegated Bandwidth, so it triggers bandiwtdh delegation reset. Francois Best regards, Fortune _______________________________________________ ANCP mailing list ANCP@ietf.org https://www.ietf.org/mailman/listinfo/ancp --Boundary_(ID_Wxl9jyXoSCESRYSSu8Mizg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hello Francois,

As said during the ANCP session yesterday, the reset procedure can address this situation, but the reset procedure itself is too heavy.

There reasons are as follows:

1) In the example in my previous email, there is no need for the NAS/PS to stop admitting new requests.

2) In the example in my previous email, there is no need for the NAS/PS to query the AN’s view of the delegation when the AN triggers the query.

My proposal is to have a simple request-response query triggered by the AN. If the NAS/PS does need to know the AN’s view of the delegation, this information can be carried in the request.

Best regards,

Fortune

From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com]
Sent: Monday, July 27, 2009 11:24 AM
To: Fortune HUANG
Cc: Francois Le Faucheur IMAP; ancp@ietf.org
Subject: Re: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00

Hello Fortune

On 22 Jul 2009, at 04:30, Fortune HUANG wrote:

Dear all,

that should not happen too often since we are assuming reliable transport.

In this case, the delegated bandwidth data in both sides may be inconsistent but only the AN knows this happens. I think the bandwidth query request triggered by the AN can be useful in this case.

Is this situation not already addressed via the Delegated Bandwidth reset procedure of section 4.10?

ie AN knows it has an invalid Delegated Bandwidth, so it triggers bandiwtdh delegation reset.

Francois

Best regards,
Fortune

_______________________________________________
ANCP mailing list
ANCP@ietf.org
https://www.ietf.org/mailman/listinfo/ancp

--Boundary_(ID_Wxl9jyXoSCESRYSSu8Mizg)-- From tom.taylor@rogers.com Tue Jul 28 08:37:44 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAEE43A7093 for ; Tue, 28 Jul 2009 08:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8FDMa7KhOLi for ; Tue, 28 Jul 2009 08:37:43 -0700 (PDT) Received: from smtp111.rog.mail.re2.yahoo.com (smtp111.rog.mail.re2.yahoo.com [206.190.37.1]) by core3.amsl.com (Postfix) with SMTP id AA2C63A6CC2 for ; Tue, 28 Jul 2009 08:37:43 -0700 (PDT) Received: (qmail 53515 invoked from network); 28 Jul 2009 15:37:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oxeezo1gOPwdi0L9phrwa3xI/GUd78HI/N8TN4F5PkR02XSMnINhga4sGlaYLoH/a2rsEndTGTEwMXesJgxVQB5jkb0WugowLLMKe84t+fr2d0QXWYV8kcvtwPz5TYa7ioJ0kwDuwMGs84YUylw6+tlLMA7n3t+m32v+d4EvLRM= ; Received: from unknown (HELO ?130.129.22.181?) (tom.taylor@130.129.22.181 with plain) by smtp111.rog.mail.re2.yahoo.com with SMTP; 28 Jul 2009 15:37:42 -0000 X-YMail-OSG: NitFASsVM1nt3W9TiJ1EGPAovk5DUZmsgGd6PqRWw1DeS8iROlYmV6VsgzCObEP4RA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A6F1B44.2070700@rogers.com> Date: Tue, 28 Jul 2009 11:37:40 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Fortune HUANG References: <377C230C0C384DDE9028417DAB5A3B2D@WWWE99ECC189FD> In-Reply-To: <377C230C0C384DDE9028417DAB5A3B2D@WWWE99ECC189FD> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] About Delegated bandwidth query in draft-ietf-ancp-mc-extensions-00 X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 15:37:44 -0000 I'm willing to admit that I put together the reset procedure and may have seen more stringent requirements than in fact are applicable. Fortune HUANG wrote: > Hello Francois, > > > > As said during the ANCP session yesterday, the reset procedure can address > this situation, but the reset procedure itself is too heavy. > > There reasons are as follows: > > 1) In the example in my previous email, there is no need for the NAS/PS to > stop admitting new requests. > > 2) In the example in my previous email, there is no need for the NAS/PS to > query the AN's view of the delegation when the AN triggers the query. > > > > My proposal is to have a simple request-response query triggered by the AN. > If the NAS/PS does need to know the AN's view of the delegation, this > information can be carried in the request. > > > > > > Best regards, > > Fortune > > > > _____ > > From: Francois Le Faucheur IMAP [mailto:flefauch@cisco.com] > Sent: Monday, July 27, 2009 11:24 AM > To: Fortune HUANG > Cc: Francois Le Faucheur IMAP; ancp@ietf.org > Subject: Re: [ANCP] About Delegated bandwidth query in > draft-ietf-ancp-mc-extensions-00 > > > > Hello Fortune > > > > On 22 Jul 2009, at 04:30, Fortune HUANG wrote: > > > > > > Dear all, > > > > The delegated bandwidth query request in draft-ietf-ancp-mc-extensions-00 is > only triggered by the NAS(see section 4.8). However, I think the delegated > bandwidth query request is also needed to be triggered by the AN. For > example, AN requests to reallocate the delegated bw, NAS/PS does so but the > response gets lost. > > > > that should not happen too often since we are assuming reliable transport. > > > > > > In this case, the delegated bandwidth data in both sides may be > inconsistent but only the AN knows this happens. I think the bandwidth query > request triggered by the AN can be useful in this case. > > > > Is this situation not already addressed via the Delegated Bandwidth reset > procedure of section 4.10? > > ie AN knows it has an invalid Delegated Bandwidth, so it triggers bandiwtdh > delegation reset. > > > > Francois > > > > > > > > > > Best regards, > Fortune > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From alan.kavanagh@ericsson.com Tue Jul 28 10:29:49 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8B453A6EA7 for ; Tue, 28 Jul 2009 10:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POrGFqzJAX9C for ; Tue, 28 Jul 2009 10:29:49 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id DD54F3A6E9A for ; Tue, 28 Jul 2009 10:29:48 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n6SHSsU2004742; Tue, 28 Jul 2009 12:28:55 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 12:28:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0FA8.C82DB5A7" Date: Tue, 28 Jul 2009 13:28:11 -0400 Message-ID: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhA References: From: "Alan Kavanagh" To: "Wojciech Dec (wdec)" , X-OriginalArrivalTime: 28 Jul 2009 17:28:12.0795 (UTC) FILETIME=[C89A2CB0:01CA0FA8] Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 17:29:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0FA8.C82DB5A7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt ) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA0FA8.C82DB5A7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ANCP Protocol Versioning

Hi Woj et.al

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

Alan K

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

Hi All, =

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

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

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

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

Regards, =
Woj.=20

------_=_NextPart_001_01CA0FA8.C82DB5A7-- From wdec@cisco.com Wed Jul 29 00:33:25 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 445E83A6E92 for ; Wed, 29 Jul 2009 00:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9axc-EnK2V+t for ; Wed, 29 Jul 2009 00:33:24 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 7223C3A6E76 for ; Wed, 29 Jul 2009 00:33:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUAAMCYb0qQ/uCKe2dsb2JhbACCJy6XNQEBFiQGoU6IJ5AjBYQQgU0 X-IronPort-AV: E=Sophos;i="4.43,288,1246838400"; d="scan'208,217";a="46032202" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 07:33:11 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6T7X9Ci010415; Wed, 29 Jul 2009 09:33:09 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6T7X9ks013921; Wed, 29 Jul 2009 07:33:09 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 09:33:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA101E.D23C4D9C" Date: Wed, 29 Jul 2009 09:33:01 +0200 Message-ID: In-Reply-To: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcA= References: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se> From: "Wojciech Dec (wdec)" To: "Alan Kavanagh" , X-OriginalArrivalTime: 29 Jul 2009 07:33:10.0108 (UTC) FILETIME=[D28E39C0:01CA101E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7626; t=1248852789; x=1249716789; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20Protocol=20Versioning |Sender:=20; bh=gWr9BsTRwm53krYICnw0vGTjJ5SOZhtHovTtYQ0CQqo=; b=sAnXqlndMwt6Kxc7TaGWqDgQCxPEGzQZtqruOB2gdJ+AKB+Mp14TtNR5mU F5NUdO8dgjO/8Syf2i13IxJu7l7z7tPs0HwqMHX+2LpJdw4mTM7eg7ljTEX2 2F7MsnAmDv; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 07:33:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA101E.D23C4D9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc. =20 -Woj. ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning =09 =09 Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt ) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA101E.D23C4D9C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Protocol Versioning

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

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

-Woj.

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

Hi Woj et.al

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

BR

Alan K

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

Hi = All,

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

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

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

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

Regards,
Woj.=20

------_=_NextPart_001_01CA101E.D23C4D9C-- From alan.kavanagh@ericsson.com Wed Jul 29 06:30:24 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFD1F3A6EEE for ; Wed, 29 Jul 2009 06:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU8oYBC8tu9g for ; Wed, 29 Jul 2009 06:30:23 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A95703A6E94 for

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

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

-Sanjay

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

Cheers=20 Woj

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

Alan

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

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

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

-Woj.

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

Hi Woj=20 et.al

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

Alan=20 K

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

Hi=20 All,

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

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

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

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

Regards, =
Woj.

------_=_NextPart_001_01CA1053.9B479079-- From wdec@cisco.com Wed Jul 29 07:00:57 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B14B3A70B0 for ; Wed, 29 Jul 2009 07:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.148 X-Spam-Level: X-Spam-Status: No, score=-9.148 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QC5FOVdSh2v for ; Wed, 29 Jul 2009 07:00:56 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EAE993A70B8 for ; Wed, 29 Jul 2009 07:00:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsAAPvyb0qQ/uCLe2dsb2JhbACCKSyXNxYkBqEEiCeQOQWEEYFO X-IronPort-AV: E=Sophos;i="4.43,289,1246838400"; d="scan'208,217";a="46072261" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 14:00:53 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6TE0rif030406; Wed, 29 Jul 2009 16:00:53 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6TE0row008840; Wed, 29 Jul 2009 14:00:53 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 16:00:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1054.FC7436F0" Date: Wed, 29 Jul 2009 16:00:50 +0200 Message-ID: In-Reply-To: <35815C929B41D2479A224FE098A272270798C1CB@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEA== References: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se><35815C929B41D2479A224FE098A272270798C191@ecamlmw720.eamcs.ericsson.se><998644D4818FC74AA6232DE1D353797799E12F8056@EMBX01-WF.jnpr.net> <35815C929B41D2479A224FE098A272270798C1CB@ecamlmw720.eamcs.ericsson.se> From: "Wojciech Dec (wdec)" To: "Alan Kavanagh" , "Sanjay Wadhwa" , X-OriginalArrivalTime: 29 Jul 2009 14:00:53.0682 (UTC) FILETIME=[FCB9E920:01CA1054] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=21575; t=1248876053; x=1249740053; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20Protocol=20Versioning |Sender:=20; bh=Cz8Acm2gMthVg+yWE3ODJ5heacfy9x9WPenXWvRwiog=; b=ez6uKdjoPTXQHfaCK12tfn4dS4AzUpf/w0CY3CqruK8+vZ0LQ+9DQlMYLS HE/C0VnYaYRRXv4+cIhy6/0nT01Y4tVj/hyogORN6vLlE1PQhOeslyfU25t9 UfW0Nhx2nH; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 14:00:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1054.FC7436F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread... =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility between BNG and AN needs to be handled. =20 -Sanjay =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft. =20 Alan =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc. =20 -Woj. =20 =09 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt ) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA1054.FC7436F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Protocol = Versioning

Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 = which is=20 NOT defined anywhere (in any normative reference or RFC) does not = seem to=20 be acceptable.

The (minuted) discussion did not cover the notion of how ANCP = "version=20 incompatibility" will be handled. Given that we're not out in the = WG to=20 create version compatibility between an ANCP standard protocol and an=20 ANCP non-standard based one (or GSMP for that matter), it would = seem=20 that no new definition needs to take place. Feel free to discuss = this=20 further on this thread...

-Woj.

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

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

Alan

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

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

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

-Sanjay

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

Cheers=20 Woj

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

Alan

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

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

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

-Woj.

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

Hi Woj=20 et.al

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

BR

Alan=20 K

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

Hi=20 All,

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

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

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

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

Regards, =
Woj. =

------_=_NextPart_001_01CA1054.FC7436F0-- From alan.kavanagh@ericsson.com Wed Jul 29 10:10:56 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AEC3A6830 for ; Wed, 29 Jul 2009 10:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qhagB8hrmRK for ; Wed, 29 Jul 2009 10:10:55 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 3111D3A69FC for ; Wed, 29 Jul 2009 10:10:55 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n6THAq2h012267; Wed, 29 Jul 2009 12:10:54 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 12:10:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA106F.81CEB3C9" Date: Wed, 29 Jul 2009 13:10:43 -0400 Message-ID: <35815C929B41D2479A224FE098A272270798C3E1@ecamlmw720.eamcs.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFg References: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se><35815C929B41D2479A224FE098A272270798C191@ecamlmw720.eamcs.ericsson.se><998644D4818FC74AA6232DE1D353797799E12F8056@EMBX01-WF.jnpr.net> <35815C929B41D2479A224FE098A272270798C1CB@ecamlmw720.eamcs.ericsson.se> From: "Alan Kavanagh" To: "Wojciech Dec (wdec)" , "Sanjay Wadhwa" , X-OriginalArrivalTime: 29 Jul 2009 17:10:44.0978 (UTC) FILETIME=[8277BD20:01CA106F] Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 17:10:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA106F.81CEB3C9 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable So what are you sugegsting will happen with current deployments....!!! Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here. =20 By the time you agree on everything we will be onto ANCP Version 4.10 !!! We are spending far too long on getting this draft out the door. ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread... =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility between BNG and AN needs to be handled. =20 -Sanjay =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft. =20 Alan =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc. =20 -Woj. =20 =09 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt ) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA106F.81CEB3C9 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable ANCP Protocol = Versioning

So what are you sugegsting will happen with = current=20 deployments....!!! Like it or not Woj, fact is it must be covered, if = you dont=20 agree then thats just your single opinion here.

By the time you agree on everything we will be = onto ANCP=20 Version 4.10 !!! We are spending far too long on getting this draft out = the=20 door.

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

Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 = which is=20 NOT defined anywhere (in any normative reference or RFC) does not = seem to=20 be acceptable.

-Woj.

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

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

Alan

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

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

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

-Sanjay

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

Cheers=20 Woj

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

Alan

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

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

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

-Woj.

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

Hi Woj=20 et.al

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

BR

Alan=20 K

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

Hi=20 All,

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

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

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

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

Regards, =
Woj. =

------_=_NextPart_001_01CA106F.81CEB3C9-- From tom.taylor@rogers.com Wed Jul 29 11:56:21 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9A8E3A6AC3 for ; Wed, 29 Jul 2009 11:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, RCVD_IN_SORBS_WEB=0.619] 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 so0dbkxxeLlV for ; Wed, 29 Jul 2009 11:56:20 -0700 (PDT) Received: from smtp113.rog.mail.re2.yahoo.com (smtp113.rog.mail.re2.yahoo.com [68.142.225.229]) by core3.amsl.com (Postfix) with SMTP id 862F43A6923 for ; Wed, 29 Jul 2009 11:56:20 -0700 (PDT) Received: (qmail 13854 invoked from network); 29 Jul 2009 18:56:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=DlzqXzGvLKam/L5W7ilLiwj8Gbey56XHriX4zEHv9VP8YO4oHVt1sjteNIkw7E3Bd4926OdiMyK0S8LJmKa1Ae05FL7nBDqrD77VbP0ppDGbuIZ9caj90BrDW4MWPVBW7+RlumEGkYTzcaUVWlsiJYxUa4P+T5mpzuWiKIMVqZk= ; Received: from unknown (HELO ?192.168.0.31?) (tom.taylor@212.214.133.101 with plain) by smtp113.rog.mail.re2.yahoo.com with SMTP; 29 Jul 2009 18:56:19 -0000 X-YMail-OSG: dgfeDDIVM1lZVVoSI0IMRu1pd19P_DhfMIzMFPs.iFXwbI_B9HdJ3b.0JqQ9tCN98Q-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A709B51.9020206@rogers.com> Date: Wed, 29 Jul 2009 20:56:17 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Alan Kavanagh References: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se><35815C929B41D2479A224FE098A272270798C191@ecamlmw720.eamcs.ericsson.se><998644D4818FC74AA6232DE1D353797799E12F8056@EMBX01-WF.jnpr.net> <35815C929B41D2479A224FE098A272270798C1CB@ecamlmw720.eamcs.ericsson.se> <35815C929B41D2479A224FE098A272270798C3E1@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <35815C929B41D2479A224FE098A272270798C3E1@ecamlmw720.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 18:56:21 -0000 The idea is that there will be two classes of implementation: those conforming to the RFC (I.e. version 3.2) and all the others. Thomas saw the problem as distinguishing between those two classes. That was because in his network only one other implementation will be deployed. Alan Kavanagh wrote: > So what are you sugegsting will happen with current deployments....!!! > Like it or not Woj, fact is it must be covered, if you dont agree then > thats just your single opinion here. > > By the time you agree on everything we will be onto ANCP Version 4.10 > !!! We are spending far too long on getting this draft out the door. > > ________________________________ > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: July 29, 2009 10:01 AM > To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is > NOT defined anywhere (in any normative reference or RFC) does not seem > to be acceptable. > The (minuted) discussion did not cover the notion of how ANCP "version > incompatibility" will be handled. Given that we're not out in the WG to > create version compatibility between an ANCP standard protocol and an > ANCP non-standard based one (or GSMP for that matter), it would seem > that no new definition needs to take place. Feel free to discuss this > further on this thread... > > -Woj. > > > ________________________________ > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Alan Kavanagh > Sent: 29 July 2009 15:51 > To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org > Subject: Re: [ANCP] ANCP Protocol Versioning > > > Exactly, hence we should ahve this explicitly noted in the > draft. > > Alan > > ________________________________ > > From: Sanjay Wadhwa [mailto:swadhwa@juniper.net] > Sent: July 29, 2009 9:48 AM > To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > > > In order to ease migration, it will help if BNGs are able to > handle multiple peers with different versions (e.g. a 3.2 compliant BNG > implementation able to work with a 3.1 AN and a 3.2 AN). Although > implied by the protocol, we may want to explicitly state that version > compatibility requirement is on an adjacency basis. > > The draft will also need to define how the version > incompatibility between BNG and AN needs to be handled. > > > > -Sanjay > > > ________________________________ > > > From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On > Behalf Of Alan Kavanagh > Sent: Wednesday, July 29, 2009 9:30 AM > To: Wojciech Dec (wdec); ancp@ietf.org > Subject: Re: [ANCP] ANCP Protocol Versioning > > > > Cheers Woj > > > > The only point i would note (excuse if it was already raised on > Monday as i did not attend) is "backward compatibility" between the > different versions of 3.1, 3.2 and future versions if/when/as needed. > this should be noted in the draft. > > > > Alan > > > > > ________________________________ > > > From: Wojciech Dec (wdec) [mailto:wdec@cisco.com] > Sent: July 29, 2009 3:33 AM > To: Alan Kavanagh; ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > Not entirely. ANCP already has a versioning field, hence nothing > new is being defined. Also strictly speaking there is no distinction > between version and sub-version, so the choice of 3.2 is purely based on > custom (it can equally well have been 4.0). > > Of course this will mean that all "pre-rfc" implementations will > automatically be 100% incompatible with the rfc. > > > > -Woj. > > > > > ________________________________ > > > From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] > Sent: 28 July 2009 19:28 > To: Wojciech Dec (wdec); ancp@ietf.org > Subject: RE: [ANCP] ANCP Protocol Versioning > > Hi Woj et.al > > > > So are we agreeing that option 1 as noted on slide 15 in > the Thomas's presentation is what was agreed on at yesterdays meeting? > > > > BR > > Alan K > > > > > ________________________________ > > > From: ancp-bounces@ietf.org > [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) > Sent: July 28, 2009 5:30 AM > To: ancp@ietf.org > Subject: [ANCP] ANCP Protocol Versioning > > Hi All, > > During yesterday's ANCP WG meeting at IET75 we discussed > the topic of ANCP versioning and in the room arrived at the following > conclusion: > > The Pre-RFC version of ANC will continue to be 3.1 as > per draft-ietf-ancp-protocol, however an RFC Editor's note will be > introduced to change version from 3.1 to 3.2 upon publication of the > RFC. This will clearly de-lineate any pre-RFC implementations with > post-RFC ones and alleviate the operators'' problems presented > (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt > ) > > Going beyond the publication of the RFC, the > introduction of new capabilities or TLVs is expected to be handled by > the capability negotiation mechanism (and new capabilities) or possibly > by generalizing the notion of sub-capability currently in place for the > multicast-control use-cases. > > We would like to get feedback from the wider WG on the > above, especially in terms of anyone who was not able to voice their > opinion at the meeting. Based on the received feedback, we'll make a > call regarding the WG consensus on this matter. > > Regards, > Woj. > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp From wdec@cisco.com Wed Jul 29 12:21:53 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAA793A6FF0 for ; Wed, 29 Jul 2009 12:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.318 X-Spam-Level: X-Spam-Status: No, score=-9.318 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRl8an0+4ctp for ; Wed, 29 Jul 2009 12:21:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F3B963A6FE4 for ; Wed, 29 Jul 2009 12:21:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsAAPs9cEqQ/uCKe2dsb2JhbACCKSyXNxYkBqFsiCeQOwWEEYFO X-IronPort-AV: E=Sophos;i="4.43,290,1246838400"; d="scan'208,217";a="46093078" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 29 Jul 2009 19:21:51 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6TJLpDZ019629; Wed, 29 Jul 2009 21:21:51 +0200 Received: from xbh-ams-102.cisco.com (xbh-ams-102.cisco.com [144.254.73.132]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6TJLoSV016246; Wed, 29 Jul 2009 19:21:51 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 21:21:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA1081.D2D5D78A" Date: Wed, 29 Jul 2009 21:21:48 +0200 Message-ID: In-Reply-To: <35815C929B41D2479A224FE098A272270798C3E1@ecamlmw720.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] ANCP Protocol Versioning Thread-Index: AcoPZf5AmXT9J6uSR5Ou1YHKkJwtewAQoLhAAB1afcAADKVzcAAAG2DgAACkaOAAABSFEAAG2NFgAANYqCA= References: <35815C929B41D2479A224FE098A272270798BDC3@ecamlmw720.eamcs.ericsson.se><35815C929B41D2479A224FE098A272270798C191@ecamlmw720.eamcs.ericsson.se><998644D4818FC74AA6232DE1D353797799E12F8056@EMBX01-WF.jnpr.net> <35815C929B41D2479A224FE098A272270798C1CB@ecamlmw720.eamcs.ericsson.se> <35815C929B41D2479A224FE098A272270798C3E1@ecamlmw720.eamcs.ericsson.se> From: "Wojciech Dec (wdec)" To: "Alan Kavanagh" , "Sanjay Wadhwa" , X-OriginalArrivalTime: 29 Jul 2009 19:21:51.0441 (UTC) FILETIME=[D33EBC10:01CA1081] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=27435; t=1248895311; x=1249759311; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wdec@cisco.com; z=From:=20=22Wojciech=20Dec=20(wdec)=22=20 |Subject:=20RE=3A=20[ANCP]=20ANCP=20Protocol=20Versioning |Sender:=20; bh=iBhgI0oeYk9ZQ4zi9Gw2xMcNoEqgfHhnzh29K9hZKqI=; b=SoXMYZE7wOSqAL6m879AmxAEgD1hWcfwvD/QTIHBVzXMGyWTDrfPCCLP5F eFilhbptT3zGQW69vI98Bj/6EHFkqIb5+L2cCIspVPDiuLLTj4BxvLTdBFrv 2cukZmewWB; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] ANCP Protocol Versioning X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 19:21:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA1081.D2D5D78A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your post bears no useful or constructive input regarding the topic. Attempting to define backwards compatibility means drawing on a normative reference to non-standard drafts and is not reasonable (a reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as to where ANCP version 3.1 is defined and can be normatively referenced in a v3.2 RFC?=20 If v3.2 and v3.1 are 100% compatible, except for new capabilities, then there is hardly a reason for a version change. The only way to have a reference to v3.1 in an rfc re v3.2 is either as a historic note, without claims of backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be appealing. =20 In addition, you may also want to reflect on the quality of your conclusions and comprehension of general facts... =20 -Woj. =20 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 29 July 2009 19:11 To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 So what are you sugegsting will happen with current deployments....!!! Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here. =20 By the time you agree on everything we will be onto ANCP Version 4.10 !!! We are spending far too long on getting this draft out the door. ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 10:01 AM To: Alan Kavanagh; Sanjay Wadhwa; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable. The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread... =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: 29 July 2009 15:51 To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =09 =09 Exactly, hence we should ahve this explicitly noted in the draft. =20 Alan ________________________________ From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 Sent: July 29, 2009 9:48 AM To: Alan Kavanagh; Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning =09 =09 In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis. The draft will also need to define how the version incompatibility between BNG and AN needs to be handled. =20 -Sanjay =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Alan Kavanagh Sent: Wednesday, July 29, 2009 9:30 AM To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] ANCP Protocol Versioning =20 Cheers Woj =20 The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft. =20 Alan =20 =09 ________________________________ From: Wojciech Dec (wdec) [mailto:wdec@cisco.com]=20 Sent: July 29, 2009 3:33 AM To: Alan Kavanagh; ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0). Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc. =20 -Woj. =20 =09 ________________________________ From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: 28 July 2009 19:28 To: Wojciech Dec (wdec); ancp@ietf.org Subject: RE: [ANCP] ANCP Protocol Versioning Hi Woj et.al =20 So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting? =20 BR Alan K =20 =09 ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Wojciech Dec (wdec) Sent: July 28, 2009 5:30 AM To: ancp@ietf.org Subject: [ANCP] ANCP Protocol Versioning Hi All,=20 During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion: The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt ) Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases. We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter. Regards,=20 Woj.=20 ------_=_NextPart_001_01CA1081.D2D5D78A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ANCP Protocol = Versioning

Your post bears no useful or constructive input regarding the = topic.=20 Attempting to define backwards compatibility means drawing on a = normative=20 reference to non-standard drafts and is not reasonable (a = reading of=20 http://tools.ietf.org/html/rf= c4897 helps).=20 Perhaps you could be so kind as to give us advise the WG as to where = ANCP=20 version 3.1 is defined and can be normatively referenced in a v3.2=20 RFC?

If v3.2 and v3.1 are 100% compatible, except for new = capabilities, then=20 there is hardly a reason for a version change. The only way to have a = reference=20 to v3.1 in an rfc re v3.2 is either as a historic note, without claims = of=20 backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). = Neither=20 of these proposals seem to be appealing.

In addition, you may also want to reflect on the quality = of your=20 conclusions and comprehension of general facts...

-Woj.

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

So what are you sugegsting will happen with = current=20 deployments....!!! Like it or not Woj, fact is it must be covered, if = you dont=20 agree then thats just your single opinion here.

By the time you agree on everything we will = be onto ANCP=20 Version 4.10 !!! We are spending far too long on getting this draft = out the=20 door.

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

Sorry, but reference in a future ANCP v3.2 RFC to a version = 3.1 which=20 is NOT defined anywhere (in any normative reference or RFC) does = not seem=20 to be acceptable.

The (minuted) discussion did not cover the notion of how ANCP = "version=20 incompatibility" will be handled. Given that we're not out in the = WG to=20 create version compatibility between an ANCP standard protocol and an=20 ANCP non-standard based one (or GSMP for that matter), it would = seem=20 that no new definition needs to take place. Feel free to discuss = this=20 further on this thread...

-Woj.

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

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

Alan

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

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

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

-Sanjay

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

Cheers=20 Woj

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

Alan

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

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

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

-Woj.

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

Hi Woj=20 et.al

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

BR

Alan=20 K

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

Hi=20 All,

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

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

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

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

Regards,=20
Woj.=20