Splitting multicast from protocol doc

This comfirms IMO the issue raised from Thomas.
As specified = above,=20 the the AN must report the port status as part of establishing the = Access Node=20 Control Adjacency. In practice the Adjacency protocol is established = before all=20 the dsl lines are in showtime. Which layer 2 mode (atm=20 or eth) should the AN add into the Access-Node-Identifier? At = this=20 point of time, he does not know, in which layer 2 mode the port is = operating. He=20 may derives the information from the configured value in the line = profile but if=20 the port is configured with multiple modes enabled (e. g. = ADSL2plus=20 and VDSL2), there is no clear disctinction=20 possible.

Regards
Markus

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Haag,=20 Thomas
Gesendet: Mittwoch, 1. April 2009 16:36
An:=20 wdec@cisco.com; ancp@ietf.org
Betreff: Re: [ANCP] TC = Information=20 "unknown" State

Hi Woj,

the point is that the DSLAM does not know in = which Layer 2=20 mode (Packet Mode, ATM Mode) the Line will synchronize if a port is = configured=20 for multimode.

From an ANCP perspective all ports have to = report their=20 status regardless if in sync, out of sync, idle what = ever.

But those ports which do not know = the mode=20 because of not beeing synchronized the first time = will not retrieve an=20 information from DSL port beeing communicated via ANCP.=20

If a port is not ATM synchronized and if a port = is not ETH=20 synchronized what has the DSLAM to report? The Layer 2 status is unknown. =

From protocol point of view it should be a = point of=20 integrity because we use it for a use case called topology discovery = which means=20 to have real information about all ports within a domain.=20

The BRAS can use it for statistics correlate = with OAM use=20 case, Line config use case or irgnore it. But this is not a = protocol=20 issue it is an element implementation issue.

Regards

Thomas

Von: Wojciech Dec (wdec) = [mailto:wdec@cisco.com]=20
Gesendet: Mittwoch, 1. April 2009 13:31
An: Haag, = Thomas;=20 ancp@ietf.org
Betreff: RE: [ANCP] TC Information "unknown"=20 State

Hi Thomas,

I=20 still don't quite follow.

If the DSLAM is pre-provisioned and the port is down (no CPE on = the other=20 end), what is the point of signalling this pre-provisioned but down and=20 "unknown" port to the NAS?

Thanks,

Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of=20 HaagT@telekom.de
Sent: 01 April 2009 11:34
To: = Wojciech Dec (wdec); ancp@ietf.org
Subject: Re: [ANCP] TC=20 Information "unknown" State

Hi Woj,

the case occurs if:

a IP-DSLAM Port is preprovisioned=20 and

aDSL port operates in Multi Mode (without = DSL=20 pre-enforcement to VDSL2(ETH) or ADSL2plus(ATM)) and =

customer did not switch on his CPE (first=20 time) and

DSLAM-BNG sets up adjacency or =

a DSL line card comes = up.

In that situation a DSLAM does not know on = which Layer 2=20 mode the DSL line will synchronize. Having only ATM and ETH without = "Unknown"=20 coded the message will be wrong because a DSLAM does not know what to = choose=20 because of an unknown L2 status at the DSL = port.

Regards

Thomas

Von: Wojciech Dec (wdec)=20 [mailto:wdec@cisco.com]
Gesendet: Mittwoch, 1. April 2009=20 10:46
An: Haag, Thomas; ancp@ietf.org
Betreff: RE: = [ANCP]=20 TC Information "unknown" State

Hi Thomas,

if the line is not (and never was) synchronised to a = CPE, what=20 would be the point of reporting it to the NAS?

Thanks,

Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of=20 HaagT@telekom.de
Sent: 01 April 2009 = 08:29
To:=20 ancp@ietf.org
Subject: [ANCP] TC Information "unknown"=20 State

All,

operating a DSL = port in=20 multi mode which means that ADSL2plus (ATM )=20 and VDSL2 (ETH) is enabled the following situation=20 occur:

For=20 a DSL port which has never = been=20 synchronized with a CPE (regardless if ADSL2plus = or VDSL2)=20 there = is the = situation,=20 which layer 2 information has to be reported to BNG via ANCP port = status=20 message. In that case new information in the protocol is=20 necessary to = inform the=20 BNG about this "unknown"=20 State which is = neither=20 represented by ATM = nor=20 ETH.

I like to = encourage ANCP=20 working group to tackle this issue and define a new TC information = [ATM,=20 ETH; UNKNOWN] in the protocol draft to indicate the port = status as=20 described above.

Best = regards=20

Thomas=20

------_=_NextPart_001_01C9B680.09F998C6-- From Matthew.Bocci@alcatel-lucent.com Mon Apr 6 02:13:05 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 D5C053A6B6A for ; Mon, 6 Apr 2009 02:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc+AGB37DK5p for ; Mon, 6 Apr 2009 02:13:04 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 747793A69D0 for ; Mon, 6 Apr 2009 02:11:06 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n369Beaf018319; Mon, 6 Apr 2009 11:11:46 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 11:11:43 +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_01C9B697.B3FF348B" Date: Mon, 6 Apr 2009 11:11:42 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A0399C36C@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised charter Thread-Index: Acm2l7OPJDgxXxYHQhiQkDPTZUj7Sw== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 06 Apr 2009 09:11:43.0443 (UTC) FILETIME=[B4160A30:01C9B697] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [ANCP] Revised charter X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:13:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B697.B3FF348B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, Following the discussion in San Francisco, please find the revised ANCP charter below. Please send any comments to the list by Friday 17th April. Best regards Matthew Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node=20 Control Protocol (ANCP) for use in e.g. service provider Digital Subscriber=20 Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS).=20 Necessary Terminology: Access Node (AN) - Network device, usually located at a service=20 provider central office or street cabinet, that terminates access loop=20 connections from Subscribers. In DSL, this is often referred to as a=20 Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually=20 comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU)=20 and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates=20 multiplexed Subscriber traffic from a number of Access Nodes. The NAS=20 plays a central role in per-subscriber policy enforcement and QoS.=20 This is often referred to as a Broadband Network Gateway (BNG) or Broadband=20 Remote Access Server (BRAS). A detailed definition of the NAS is given=20 in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e.,=20 Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an=20 ANCP message exchange is to convey status and control information=20 between one or more ANs and one or more NASs without going through=20 intermediate element managers.=20 The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks=20 to avoid congestion while dealing with multiple flows and distinct QoS=20 profiles. Communicating the access-loop status, attributes and current=20 DSL synchronization rate between the AN and Subscriber up to the NAS=20 is desirable, particularly when the NAS is providing QoS for=20 individual flows and subscribers. ANCP will provide a mechanism to=20 communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to=20 the NAS, ANCP will allow a NAS to send loop-specific configuration=20 information to an AN based on the results of subscriber authentication=20 and authorization (e.g., after AAA responses have been received at the=20 NAS).=20 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point=20 ATM circuits between the AN and NAS for each subscriber, allowing=20 troubleshooting of the local loop from the NAS via ATM OAM tools. With=20 the increasing deployment of Ethernet in the access and aggregation=20 network, operators require consistent methods to test and troubleshoot=20 connectivity for mixed Ethernet and ATM access networks (including the=20 local loop). ANCP will allow a remote procedure for a local loop=20 connectivity test to be triggered from the NAS with results=20 communicated back to the NAS.=20 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow=20 the AN to perform subscriber bound multicast group replication in line=20 with the subscriber's policy and configuration, and also allow the NAS=20 to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS,=20 over a DSL access and aggregation network. It will not address setup=20 or configuration of circuits or connections in the access and=20 aggregation network itself. The focus of this WG is on one very specific application space. While=20 the design of the protocol must be general as to not preclude other=20 uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation=20 networks.=20 Security: The ANCP working group will provide a threat analysis and address the=20 associated security aspects of the control protocol.=20 Resiliency and Scalability:=20 A graceful restart mechanism will be defined to enable the protocol to=20 be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating=20 traffic from a large number of ANs, which in turn may be serving a=20 large number of Subscribers. ANCP traffic should not become a denial=20 of service attack on the NAS control plane. Format of messages,=20 pacing, transport over UDP or TCP, etc. will be considered with this=20 in mind. For reasons of aggregation network scalability, some use cases require=20 that aspects of NAS or AN functionality may be distributed in nodes in=20 the aggregation network. In these cases, ANCP can run between these=20 nodes. Deliverables: The working group will define a basic framework and requirements=20 document intended for Informational publication, focusing on the four=20 use-cases outlined in this charter. This document will include a=20 security threat analysis and associated requirements. The WG will then=20 investigate and define a solution for an IP based control protocol=20 meeting these requirements.=20 There are early interoperable implementations of an ANCP-like protocol=20 which are based on an extended subset of the GSMPv3 protocol. This=20 running code will be the the starting point for the working group=20 solution, and will be abandoned only if the WG determines it is not=20 adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so=20 the management framework and MIB modules are consistent for DSL=20 access environments. The working group will re-use, as far as=20 possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with=20 ITU-T Ethernet OAM work, and with IEEE 802.1ag. Goals and Milestones: Done Accept WG I-D for ANCP Framework and Requirements=20 Done Accept WG I-D for Access Node Control Protocol (ANCP)=20 Done Accept WG ID for Security Threats analysis=20 Done Accept WG I-D for ANCP MIB=20 Done Security Threats Analysis last call=20 Done Framework and Requirements last call=20 Apr 2009 ANCP MIB Last Call=20 Mar 2009 Accept WG I-D for ANCP applicability to PON June 2009 Access Node Control Protocol (ANCP) Last Call=20 Aug 2009 Re-charter or conclude Working Group=20 ------_=_NextPart_001_01C9B697.B3FF348B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Revised charter

All,

Following the discussion in San = Francisco, please find the revised ANCP charter below.

Please send any comments to the list by = Friday 17th April.

Best regards

Matthew

Description of Working Group:
Purpose:

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

Necessary Terminology:

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

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

Goals:

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

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

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

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

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

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

Non-Goals:

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

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

Security:

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

Resiliency and Scalability:

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

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

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

Deliverables:

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

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

Coordination with other Working Groups = or Organizations:

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

The remote connectivity test use case = may require coordination with
ITU-T Ethernet OAM work, and with IEEE = 802.1ag.

Goals and Milestones:

Done    =       Accept WG I-D for ANCP Framework and = Requirements
Done    =       Accept WG I-D for Access Node Control = Protocol (ANCP)
Done    =       Accept WG ID for Security Threats = analysis
Done    =       Accept WG I-D for ANCP MIB
Done    =       Security Threats Analysis last call =
Done     =        Framework and Requirements last = call
Apr 2009 =       ANCP MIB Last Call
Mar = 2009        Accept WG I-D for ANCP = applicability to PON
June = 2009       Access Node Control Protocol = (ANCP) Last Call
Aug = 2009        Re-charter or conclude = Working Group

------_=_NextPart_001_01C9B697.B3FF348B-- From Sven.Ooghe@alcatel-lucent.be Mon Apr 6 06:39:58 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 686403A6C88 for ; Mon, 6 Apr 2009 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.697 X-Spam-Level: X-Spam-Status: No, score=-0.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_FR=0.35, 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 gcaXVYmAORQB for ; Mon, 6 Apr 2009 06:39:57 -0700 (PDT) Received: from smail6.alcatel.fr (unknown [62.23.212.42]) by core3.amsl.com (Postfix) with ESMTP id EE38E3A6C72 for ; Mon, 6 Apr 2009 06:39:56 -0700 (PDT) Received: from FRVELSBHS02.ad2.ad.alcatel.com (frvelsbhs02.dc-m.alcatel-lucent.com [155.132.6.74]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n36DernB026230 for ; Mon, 6 Apr 2009 15:41:00 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.52]) by FRVELSBHS02.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Apr 2009 15:40:58 +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_01C9B6BD.515BF8BB" Date: Mon, 6 Apr 2009 15:40:58 +0200 Message-ID: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Framework draft question Thread-Index: Acm2vVE7MxPMo20zQvaJjXUtx/LJ1g== From: "OOGHE Sven" To: X-OriginalArrivalTime: 06 Apr 2009 13:40:58.0927 (UTC) FILETIME=[518143F0:01C9B6BD] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [ANCP] Framework draft question 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, 06 Apr 2009 13:39:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B6BD.515BF8BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I would like to raise a question regarding draft-ietf-ancp-framework-08. Section 4.1 states "The ANCP MUST allow fast completion of a given operation, in the order of magnitude of tens of milliseconds."=20 This is as such not a protocol requirement, but rather a requirement on the platform choice (e.g. CPU speed). I am soliciting feedback what to do with this (drop / reword / keep). Regards, Sven ------_=_NextPart_001_01C9B6BD.515BF8BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework draft question

Hi,

I would like to raise a question = regarding draft-ietf-ancp-framework-08.

Section 4.1 states "The ANCP MUST = allow fast completion of a given operation, in the order of magnitude of = tens of milliseconds."

This is as such not a protocol = requirement, but rather a requirement on the platform choice (e.g. CPU = speed).

I am soliciting feedback what to do = with this (drop / reword / keep).

Regards,
Sven

------_=_NextPart_001_01C9B6BD.515BF8BB-- From fqhuang@huawei.com Mon Apr 6 21:26:55 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22D23A67E9 for ; Mon, 6 Apr 2009 21:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.76 X-Spam-Level: X-Spam-Status: No, score=0.76 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, 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 0LIZsq2YbpmX for ; Mon, 6 Apr 2009 21:26:48 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 177843A680A for ; Mon, 6 Apr 2009 21:26:42 -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 <0KHP00C23R21B7@szxga03-in.huawei.com> for ancp@ietf.org; Tue, 07 Apr 2009 12:27:37 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KHP00F2JR21QR@szxga03-in.huawei.com> for ancp@ietf.org; Tue, 07 Apr 2009 12:27:37 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KHP00NLOR1Z2G@szxml04-in.huawei.com> for ancp@ietf.org; Tue, 07 Apr 2009 12:27:35 +0800 (CST) Date: Tue, 07 Apr 2009 12:27:35 +0800 From: Fortune HUANG To: ancp@ietf.org Message-id: <00d701c9b739$2d0c4ed0$7b27460a@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_3qDpUjt8w79iyUxgT195/Q)" Thread-index: Acm3OSz0fRJk81LAS/ytLoiulpiByg== Subject: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 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, 07 Apr 2009 04:26:55 -0000 This is a multi-part message in MIME format. --Boundary_(ID_3qDpUjt8w79iyUxgT195/Q) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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_3qDpUjt8w79iyUxgT195/Q) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

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_3qDpUjt8w79iyUxgT195/Q)-- From shrirao@cisco.com Tue Apr 7 00:09:58 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 EE7A73A67FD for ; Tue, 7 Apr 2009 00:09:58 -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 TvFGSi3ZGv69 for ; Tue, 7 Apr 2009 00:09:50 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 2FCD13A6D84 for ; Tue, 7 Apr 2009 00:09:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,336,1235952000"; d="scan'208";a="151025321" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by sj-iport-3.cisco.com with ESMTP; 07 Apr 2009 07:10:55 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n377As3d010494 for ; Tue, 7 Apr 2009 12:40:54 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n377Ar9O010130 for ; Tue, 7 Apr 2009 07:10:53 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 12:40:53 +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: Tue, 7 Apr 2009 12:40:53 +0530 Message-ID: In-Reply-To: <48C276B536524E478C659685995F6AA5A30B9F924E@RBSJX.ad.redback.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Splitting multicast from protocol doc Thread-Index: AcmyF963r95pJCb0R/a3GxzjO9kQMQAiX65QASue/8A= References: <0458D2EE0C36744BABB36BE37805C29A039300AF@FRVELSMBS11.ad2.ad.alcatel.com> <48C276B536524E478C659685995F6AA5A30B9F924E@RBSJX.ad.redback.com> From: "Shridhar Rao (shrirao)" To: X-OriginalArrivalTime: 07 Apr 2009 07:10:53.0895 (UTC) FILETIME=[FD6E8D70:01C9B74F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1297; t=1239088254; x=1239952254; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=shrirao@cisco.com; z=From:=20=22Shridhar=20Rao=20(shrirao)=22=20 |Subject:=20RE=3A=20[ANCP]=20Splitting=20multicast=20from=2 0protocol=20doc |Sender:=20; bh=a2GxcrN7xO0BPkmwjt7D3fCX8u9h9Bm+cIRV+ElwrgI=; b=j0YvgmziO6orxCL3FIYz6JPawN4tEWezo0A676dqnWlPe4TYofiY/qYyY2 T2w92N5Cev0BYz54K+F10eOFXRVAdFs2HdOOhgJYOcSauuR5iHIGtkqYm7m+ iCFoX+iTba; Authentication-Results: ind-dkim-1; header.From=shrirao@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Subject: Re: [ANCP] Splitting multicast from protocol doc 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, 07 Apr 2009 07:09:59 -0000 I support this proposal. -Shridhar- ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Peter Arberg Sent: Wednesday, April 01, 2009 1:41 PM To: BOCCI Matthew; ancp@ietf.org Subject: Re: [ANCP] Splitting multicast from protocol doc I support this proposal. Peter ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: 31. marts 2009 08:47 To: ancp@ietf.org Subject: [ANCP] Splitting multicast from protocol doc =09 =09 There was a proposal at the last IETF to take the multicast text from draft-ietf-ancp-protocol-05 and merge it with draft-lefaucheur-ancp-mc-extensions-01. We would thus have two protocol drafts:=20 draft-ietf-ancp-protocol : Containing the solutions for the Topology discovery, line configuration and OAM use cases=20 Multicast extensions draft: Containing the transactional multicast solution and all of the content of draft-lefaucheur=20 This would allow us to move forward with WG LC on the basic use case solutions, and also keep all of the multicast extensions in a single draft. Please can you indicate to the list whether you support this proposal.=20 Regards=20 Matthew=20 From Matthew.Bocci@alcatel-lucent.com Tue Apr 7 09:26:23 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 609C33A6889 for ; Tue, 7 Apr 2009 09:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.17 X-Spam-Level: X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CY4TSZIPBZoC for ; Tue, 7 Apr 2009 09:26:22 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 5D4A53A67A6 for ; Tue, 7 Apr 2009 09:26:22 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.dc-m.alcatel-lucent.com [155.132.6.78]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n37GRRFF017173 for ; Tue, 7 Apr 2009 18:27:27 +0200 Received: from FRVELSMBS11.ad2.ad.alcatel.com ([155.132.6.33]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 18:27:27 +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_01C9B79D.BD6D1CAA" Date: Tue, 7 Apr 2009 18:27:26 +0200 Message-ID: <0458D2EE0C36744BABB36BE37805C29A0399CB26@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: San Francisco Minutes Thread-Index: Acm3nb0EkAfmpeAaTJCd5AMTw6x1qA== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 07 Apr 2009 16:27:27.0014 (UTC) FILETIME=[BD482460:01C9B79D] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Subject: [ANCP] San Francisco Minutes 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, 07 Apr 2009 16:26:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B79D.BD6D1CAA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I have uploaded the draft minutes from San Francisco to the IETF server at: http://www.ietf.org/proceedings/09mar/minutes/ancp.txt Many thanks to Tom for taking notes. Please send your comments to the list. Regards Matthew ------_=_NextPart_001_01C9B79D.BD6D1CAA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable San Francisco Minutes

Folks,

I have uploaded the draft minutes from = San Francisco to the IETF server at:

http://www.ietf.org/proceedings/09mar/minutes/ancp.txt

Many thanks to Tom for taking = notes.

Please send your comments to the = list.

Regards

Matthew

------_=_NextPart_001_01C9B79D.BD6D1CAA-- From wdec@cisco.com Thu Apr 9 02:20:19 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 727813A6BCC for ; Thu, 9 Apr 2009 02:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTG3r6b7A4NQ for ; Thu, 9 Apr 2009 02:20:18 -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 0F41E3A6B42 for ; Thu, 9 Apr 2009 02:20:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,159,1238976000"; d="scan'208,217";a="37834871" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Apr 2009 09:21:24 +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 n399LOWW019116; Thu, 9 Apr 2009 11:21:24 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n399LOEN009598; Thu, 9 Apr 2009 09:21:24 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Apr 2009 11:21:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B8F4.8D993080" Date: Thu, 9 Apr 2009 11:21:21 +0200 Message-ID: In-Reply-To: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Framework draft question Thread-Index: Acm2vVE7MxPMo20zQvaJjXUtx/LJ1gCNsybA References: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com> From: "Wojciech Dec (wdec)" To: "OOGHE Sven" , X-OriginalArrivalTime: 09 Apr 2009 09:21:24.0732 (UTC) FILETIME=[8DCCF3C0:01C9B8F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3327; t=1239268884; x=1240132884; 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]=20Framework=20draft=20question |Sender:=20; bh=z1JE4L4Gh6NIcjsoaPbHKTWF6qgsEAHU0jwTCBj9riQ=; b=Yz1TVkkxN5glb1IaGJ1gq5eiFUzYS4d8cxlIYeEzmLwJXf4Z13AzAvPoDB 8gjQ/dEhrIuJ8x9Q2FfpxbeqYQ51P1gSuBUv6SAX6WpGOdGUCUCdQ708lN4K YR/E9E9hmD; Authentication-Results: ams-dkim-1; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Subject: Re: [ANCP] Framework draft question 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, 09 Apr 2009 09:20:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B8F4.8D993080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, my opinion is that this requirement isn't for a framework as it is a performace requirement that depends on a large number of things. I'd say drop. =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: 06 April 2009 15:41 To: ancp@ietf.org Subject: [ANCP] Framework draft question =09 =09 Hi,=20 I would like to raise a question regarding draft-ietf-ancp-framework-08.=20 Section 4.1 states "The ANCP MUST allow fast completion of a given operation, in the order of magnitude of tens of milliseconds."=20 This is as such not a protocol requirement, but rather a requirement on the platform choice (e.g. CPU speed).=20 I am soliciting feedback what to do with this (drop / reword / keep).=20 Regards,=20 Sven=20 ------_=_NextPart_001_01C9B8F4.8D993080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework draft question

FWIW, my opinion is that this requirement isn't for a = framework as=20 it is a performace requirement that depends on a large number of things. = I'd say=20 drop.

-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE = Sven
Sent:=20 06 April 2009 15:41
To: ancp@ietf.org
Subject: = [ANCP]=20 Framework draft question

Hi,

I would like to raise a question = regarding=20 draft-ietf-ancp-framework-08.

Section 4.1 states "The ANCP MUST allow = fast=20 completion of a given operation, in the order of magnitude of tens of=20 milliseconds."

This is as such not a protocol = requirement, but=20 rather a requirement on the platform choice (e.g. CPU speed). =

I am soliciting feedback what to do = with this (drop=20 / reword / keep).

Regards,
Sven

------_=_NextPart_001_01C9B8F4.8D993080-- From tom.taylor@rogers.com Thu Apr 9 12:45: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 D8F8D3A6802 for ; Thu, 9 Apr 2009 12:45:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.206 X-Spam-Level: X-Spam-Status: No, score=-2.206 tagged_above=-999 required=5 tests=[AWL=0.393, 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 qa5mg-eVv6F1 for ; Thu, 9 Apr 2009 12:45:56 -0700 (PDT) Received: from smtp128.rog.mail.re2.yahoo.com (smtp128.rog.mail.re2.yahoo.com [206.190.53.33]) by core3.amsl.com (Postfix) with SMTP id CAB003A679F for ; Thu, 9 Apr 2009 12:45:55 -0700 (PDT) Received: (qmail 29337 invoked from network); 9 Apr 2009 19:47:03 -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=P5d8shKB5iCsCLvSJEg5wCA6sLs9jcYlQn2+vxgGU17OnJzRF+IhaMpQgWW2bE2ABJ0d9voBz0lHCiaWHQxPpeNoRzJFD2L1qnfUrx1F++NDsHrXrD3RQpJ5PYo+5WCdJhhgiYNN/qz5vRGZz/r5AYob1aZVKYlTUujq/Tsgdp8= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp128.rog.mail.re2.yahoo.com with SMTP; 9 Apr 2009 19:47:03 -0000 X-YMail-OSG: aAqkoXcVM1mtJLUJilyvruENXvVspViX71EFIb_NTMZHkMsQNZBj_tyvn1_g8mulrg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49DE50B9.7020208@rogers.com> Date: Thu, 09 Apr 2009 15:47:05 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Shridhar Rao (shrirao)" References: <0458D2EE0C36744BABB36BE37805C29A037E9EB2@FRVELSMBS11.ad2.ad.alcatel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ancp@ietf.org Subject: Re: [ANCP] Comments on draft-lefaucheur-ancp-mc-extensions-01.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: Thu, 09 Apr 2009 19:45:56 -0000 Sorry for not responding sooner. I lost track of this one. Shridhar Rao (shrirao) wrote: > Hi Francois , et al , > > Queries/comments/observations : > > 1. Program limit (I guess the number of multicast flows allowed for a > subscriber ) - It is mentioned only once in the draft. There is no TLV > mentioned for this. Is this to be configured locally on AN? [PTT] I suppose for consistency it should be provisioned from the NAS. We can add it on the next cycle. > > 2. Timing of bandwidth reallocation and multicast admission control > messages : if AN is waiting for a response to bandwidth reallocation can > it send MCAST admission control in the middle (for the same subscriber > port)? What happens if the NAS answers positively to the Mcast Admission > control message (i.e. Access Control is OK) but responds negatively to > the Bandwidth Allocation message (and thus AN has to reject flow). > [PTT] The flow as presented in the document made the admission request follow the response to the bandwidth allocation request. I suppose, though, that they could proceed in parallel. The AN would then have to wait until both responses came back before admitting the flow. > The draft mentions running a timer at AN after it sends a Multicast > admission control but how long can we wait at AN for bandwidth > reallocation response? [PTT] It's a human factor thing, rather than a protocol issue, so I don't think we should specify it. > > 3. What would happen when bandwidth delegation control TLV is turned on > whereas the capability negotiated between AN and NAS through > transactional multicast cap. is only 2 (meaning no bandwidth delegation > but only admission control) ? > > If the negotiated Capability is not equal to 3, then NAS should not send > bandwidth delegation TLV to activate it. [PTT] Agreed. I expect the AN should provide a protocol error response. We can add that. > > > 4. Discovering IPV6 multicast joins/leaves: Perhaps it wouldn't hurt to > replace "IGMP" by "IGMP/MLD" everywhere so we keep it clear. [PTT] Thanks, will do. > > > Thanks and regards, > > -shridhar- > > > _______________________________________________ > ANCP mailing list > ANCP@ietf.org > https://www.ietf.org/mailman/listinfo/ancp > > From flefauch@cisco.com Fri Apr 10 05:44:42 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 6C7D13A6D96 for ; Fri, 10 Apr 2009 05:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.656 X-Spam-Level: X-Spam-Status: No, score=-9.656 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO4GcHaDV+Pn for ; Fri, 10 Apr 2009 05:44:41 -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 B95C33A6CD6 for ; Fri, 10 Apr 2009 05:44:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,166,1238976000"; d="scan'208,217";a="37947146" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2009 12:45:48 +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 n3ACjmnF026206; Fri, 10 Apr 2009 14:45:48 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3ACjmvx012060; Fri, 10 Apr 2009 12:45:48 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 14:45:48 +0200 Received: from ams-flefauch-8715.cisco.com ([10.55.161.198]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 14:45:47 +0200 Message-Id: From: Francois Le Faucheur IMAP To: Tom Taylor , "Shridhar Rao (shrirao)" In-Reply-To: <49DE50B9.7020208@rogers.com> Content-Type: multipart/alternative; boundary=Apple-Mail-9--932659101 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 10 Apr 2009 14:45:45 +0200 References: <0458D2EE0C36744BABB36BE37805C29A037E9EB2@FRVELSMBS11.ad2.ad.alcatel.com> <49DE50B9.7020208@rogers.com> X-Mailer: Apple Mail (2.930.3) X-OriginalArrivalTime: 10 Apr 2009 12:45:47.0389 (UTC) FILETIME=[4553AAD0:01C9B9DA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4665; t=1239367548; x=1240231548; 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]=20Comments=20on=20draft-lefauche ur-ancp-mc-extensions-01.txt |Sender:=20; bh=0X8W9u+N1eRqanzAJERIMCgWSKj3nhsOSn5Z7Up2tlc=; b=hUEK72s0SKFtNFgX3GzkAhM7USxRToBbXtp320zKljeYjekqbr43ObeqcP 92J3ja3ltyyj9OPsMtXwY1tal8VVYQMZ93lPe7t/fPgamWIs1DImTuXZPFUS icugXGHCN4; 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] Comments on draft-lefaucheur-ancp-mc-extensions-01.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: Fri, 10 Apr 2009 12:44:42 -0000 --Apple-Mail-9--932659101 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Tom, Shridhar, > > >> 2. Timing of bandwidth reallocation and multicast admission control >> messages : if AN is waiting for a response to bandwidth >> reallocation can >> it send MCAST admission control in the middle (for the same >> subscriber >> port)? What happens if the NAS answers positively to the Mcast >> Admission >> control message (i.e. Access Control is OK) but responds negatively >> to >> the Bandwidth Allocation message (and thus AN has to reject flow). > [PTT] The flow as presented in the document made the admission > request follow the response to the bandwidth allocation request. I > suppose, though, that they could proceed in parallel. The AN would > then have to wait until both responses came back before admitting > the flow. In the scenario described by Shridhar (ie NAS says yes to Admission Control request but says No to Bandwidth Allocation message): * the AN knows what to do: reject the join because of insufficient bandwidth * But the NAS may be confused because it would assume that the actually succeeded. So far we have always kept the NAS fully aware of current join/leave state for a Grey Flow and I think we want to maintain that. A simple solution to that it to mandate that the "admission control" decision is completed and positive before the ANCP Admission Control message is sent by the AN. The call flow diagram (Fig 23) already shows it that way. Looking back at section 4.1.1, I think the text pretty much implies that ordering already. If that works for all, we can simply make the text more explicit about the strict ordering I concur with all the other points/proposal. Francois --Apple-Mail-9--932659101 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Tom, = Shridhar,

2. Timing of bandwidth reallocation and multicast = admission control
messages : = if AN is waiting for a response to bandwidth reallocation = can
it send MCAST admission = control in the middle (for the same = subscriber
port)? What happens = if the NAS answers positively to the Mcast = Admission
control message = (i.e. Access Control is OK) but responds negatively = to
the Bandwidth Allocation = message (and thus AN has to reject flow).
[PTT] The flow = as presented in the document made the admission request follow the = response to the bandwidth allocation request. I suppose, though, that = they could proceed in parallel. The AN would then have to wait until = both responses came back before admitting the = flow.

In the scenario = described by Shridhar (ie NAS says yes to Admission Control request but = says No to Bandwidth Allocation message):

* the AN = knows what to do: reject the join because of insufficient = bandwidth

* But the NAS may be confused = because it would assume that the actually succeeded. So far we have = always kept the NAS fully aware of current join/leave state for a Grey = Flow and I think we want to maintain that.

A = simple solution to that it to mandate that the "admission control" = decision is completed and positive before the ANCP Admission Control = message is sent by the AN.

The call flow diagram (Fig 23) = already shows it that way.

Looking back at section 4.1.1, = I think the text pretty much implies that ordering = already.

If that works for all, we can simply make the = text more explicit about the strict ordering

I concur with = all the other = points/proposal.

Francois

= --Apple-Mail-9--932659101-- From swadhwa@juniper.net Fri Apr 10 07:52: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 F1E7E3A67DD for ; Fri, 10 Apr 2009 07:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.765 X-Spam-Level: X-Spam-Status: No, score=-5.765 tagged_above=-999 required=5 tests=[AWL=0.833, 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 YvC8J9Q2Cn0v for ; Fri, 10 Apr 2009 07:52:07 -0700 (PDT) Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by core3.amsl.com (Postfix) with ESMTP id 1C2723A6925 for ; Fri, 10 Apr 2009 07:52:06 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKSd9dUvpfvIwwR3IZ6GnbIPn+7pfUE7s3@postini.com; Fri, 10 Apr 2009 07:53:16 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.340.0; Fri, 10 Apr 2009 07:47:05 -0700 Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 07:47:05 -0700 Received: from antipi.jnpr.net ([10.10.2.34]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Apr 2009 07:47:05 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by antipi.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Apr 2009 10:47:03 -0400 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_01C9B9EB.34E9B52C" Date: Fri, 10 Apr 2009 10:47:00 -0400 Message-ID: <9BD5D7887235424FA97DFC223CAE3C281BE875A2@proton.jnpr.net> In-Reply-To: <00d701c9b739$2d0c4ed0$7b27460a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Thread-Index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQ References: <00d701c9b739$2d0c4ed0$7b27460a@china.huawei.com> From: Sanjay Wadhwa To: "Fortune HUANG" , X-OriginalArrivalTime: 10 Apr 2009 14:47:03.0799 (UTC) FILETIME=[3667B870:01C9B9EB] Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 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, 10 Apr 2009 14:52:09 -0000 ------_=_NextPart_001_01C9B9EB.34E9B52C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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. =20 Regards -Sanjay =20 ________________________________ 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 =20 Hi all, =20 I have a question about the Tech Type in ANCP protocol for clarification. =20 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. =20 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. =20 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=20 Reference=20 [RFC5213 ]=20 Registration Procedures=20 Expert Review=20 Value Description Reference Registration Date 0 Reserved [RFC5213 ] =20 1 Virtual [RFC5213 ] =20 2 PPP [RFC5213 ] =20 3 IEEE 802.3 [RFC5213 ] =20 4 IEEE 802.11a/b/g [RFC5213 ] =20 5 IEEE 802.16e [RFC5213 ] =20 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 =20 =20 =20 =20 Best Regards, Fortune =20 ------_=_NextPart_001_01C9B9EB.34E9B52C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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           &nb= sp;           &nbs= p;            = ;           Reference
-------- ------------------------------------------------- ---------
0         Reserved           = ;            =             &= nbsp;       [RFC-leung-mip4-proxy-mode-10.txt]
1         802.3           &n= bsp;           &nb= sp;           &nbs= p;          [RFC-leung-mip4-proxy-mode-10.txt]
2         802.11a/b/g          &n= bsp;           &nb= sp;           &nbs= p;     [RFC-leung-mip4-proxy-mode-10.txt]
3         802.16e           =             &= nbsp;           &n= bsp;        [RFC-leung-mip4-proxy-mode-10.txt]
4         802.16m           =             &= nbsp;           &n= bsp;        [RFC-leung-mip4-proxy-mode-10.txt]
5         3GPP EUTRAN/LTE          &nb= sp;           &nbs= p;            = ; [RFC-leung-mip4-proxy-mode-10.txt]
6         3GPP UTRAN/GERAN          &n= bsp;           &nb= sp;            [RFC-leung-mip4-proxy-mode-10.txt]
7         3GPP2 1xRTT/HRPD          &nb= sp;           &nbs= p;            [RFC-leung-mip4-proxy-mode-10.txt]
8         3GPP2 UMB           &nbs= p;            = ;            =       [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<= /p>	Reserved	[RFC5213]
1<= /p>	Virtual	[RFC5213]
2<= /p>	PPP	[RFC5213]
3<= /p>	IEEE 802.3	[RFC5213]
4<= /p>	IEEE 802.11a/b/g	[RFC5213]
5<= /p>	IEEE 802.16e	[RFC5213]
6<= /p>	3GPP GERAN	[3GPP TS 29.275][Julien_Laganier]	2008-07-30
7<= /p>	3GPP UTRAN	[3GPP TS 29.275][Julien_Laganier]	2008-07-30
8<= /p>	3GPP E-UTRAN	[3GPP TS 29.275][Julien_Laganier]	2008-07-30
9<= /p>	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

------_=_NextPart_001_01C9B9EB.34E9B52C-- From fqhuang@huawei.com Sun Apr 12 18:16: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 758353A6C7E for ; Sun, 12 Apr 2009 18:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.667 X-Spam-Level: * X-Spam-Status: No, score=1.667 tagged_above=-999 required=5 tests=[AWL=-0.582, BAYES_20=-0.74, 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 1G0rOjIVuapD for ; Sun, 12 Apr 2009 18:16:12 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 8D4663A6934 for ; Sun, 12 Apr 2009 18:16:11 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI000HVBM8M56@szxga02-in.huawei.com> for ancp@ietf.org; Mon, 13 Apr 2009 09:17:11 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI000I9IM8MC0@szxga02-in.huawei.com> for ancp@ietf.org; Mon, 13 Apr 2009 09:17:10 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI000JB7M8M2R@szxml06-in.huawei.com> for ancp@ietf.org; Mon, 13 Apr 2009 09:17:10 +0800 (CST) Date: Mon, 13 Apr 2009 09:17:10 +0800 From: Fortune HUANG In-reply-to: <9BD5D7887235424FA97DFC223CAE3C281BE875A2@proton.jnpr.net> To: 'Sanjay Wadhwa' , ancp@ietf.org Message-id: <003c01c9bbd5$91cd9f90$7b27460a@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_muSfNXPKajumAO2GhwaTlA)" Thread-index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQAHpyZPA= Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 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 Apr 2009 01:16:14 -0000 This is a multi-part message in MIME format. --Boundary_(ID_muSfNXPKajumAO2GhwaTlA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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_muSfNXPKajumAO2GhwaTlA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

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.

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_muSfNXPKajumAO2GhwaTlA)-- From B.Witschurke@telekom.de Mon Apr 13 23:33: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 A36B83A6A27 for ; Mon, 13 Apr 2009 23:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 hMa87m1XYS7w for ; Mon, 13 Apr 2009 23:33:12 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 9B0F93A68AA for ; Mon, 13 Apr 2009 23:33:12 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 14 Apr 2009 08:34:22 +0200 Received: from S4DE9JSAAMV.ost.t-com.de ([10.125.177.113]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Apr 2009 08:34:22 +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_01C9BCCB.0BCF7E06" Date: Tue, 14 Apr 2009 08:34:21 +0200 Message-ID: <4CEAE28166928E4C8915DA65C65CCB88065272A6@S4DE9JSAAMV.ost.t-com.de> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A039300A4@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] draft-bitar-wadhwa-ancp-pon-01.txt to WG draft? Thread-Index: AcmyFoOHJTCTudvkSS+NhWzE018hTQKs2WYw References: <0458D2EE0C36744BABB36BE37805C29A039300A4@FRVELSMBS11.ad2.ad.alcatel.com> From: To: X-OriginalArrivalTime: 14 Apr 2009 06:34:22.0522 (UTC) FILETIME=[0C29D1A0:01C9BCCB] Subject: Re: [ANCP] draft-bitar-wadhwa-ancp-pon-01.txt to WG draft? X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 06:33:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCCB.0BCF7E06 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I support this. =20 Regards =20 Birgit =20 ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von = BOCCI Matthew Gesendet: Dienstag, 31. M=E4rz 2009 17:37 An: ancp@ietf.org Betreff: [ANCP] draft-bitar-wadhwa-ancp-pon-01.txt to WG draft? There was a proposal at the last IETF to accept = draft-bitar-wadhwa-ancp-pon-01.txt as an ANCP working group draft.=20 This is the start of a two week poll to test the consensus of the WG.=20 Please can you respond to the ANCP list, indicating if you support this = (or otherwise).=20 The poll will close on 14th April 2009.=20 Regards=20 Matthew=20 ------_=_NextPart_001_01C9BCCB.0BCF7E06 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bitar-wadhwa-ancp-pon-01.txt to WG = draft?

I support this.

Regards

Birgit

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von BOCCI=20 Matthew
Gesendet: Dienstag, 31. M=E4rz 2009 = 17:37
An:=20 ancp@ietf.org
Betreff: [ANCP] = draft-bitar-wadhwa-ancp-pon-01.txt to WG=20 draft?

There was a proposal at the last IETF to = accept=20 draft-bitar-wadhwa-ancp-pon-01.txt as an ANCP working group = draft.

This is the start of a two week poll to = test the=20 consensus of the WG.

Please can you respond to the ANCP list, = indicating=20 if you support this (or otherwise).

The poll will close on 14th April = 2009.

Regards

Matthew

------_=_NextPart_001_01C9BCCB.0BCF7E06-- From HaagT@telekom.de Tue Apr 14 00:41: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 32CB43A6CDB for ; Tue, 14 Apr 2009 00:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=0.248, 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 b0vBmhtG0rcq for ; Tue, 14 Apr 2009 00:41:06 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 266C13A6D90 for ; Tue, 14 Apr 2009 00:41:00 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 14 Apr 2009 09:42:10 +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); Tue, 14 Apr 2009 09:42:09 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BCD4.8421CCBE" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 14 Apr 2009 09:42:10 +0200 Message-ID: <5661758E3E93364685B91DD8272F28760117D4DD@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0399C36C@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Revised charter Thread-Index: Acm2l7OPJDgxXxYHQhiQkDPTZUj7SwGPLcSg References: <0458D2EE0C36744BABB36BE37805C29A0399C36C@FRVELSMBS11.ad2.ad.alcatel.com> From: To: , X-OriginalArrivalTime: 14 Apr 2009 07:42:09.0712 (UTC) FILETIME=[8465C300:01C9BCD4] Subject: Re: [ANCP] Revised charter X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 07:41:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCD4.8421CCBE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable o.k. =20 Thanks. =20 =20 Thomas ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von BOCCI Matthew Gesendet: Montag, 6. April 2009 11:12 An: ancp@ietf.org Betreff: [ANCP] Revised charter All,=20 Following the discussion in San Francisco, please find the revised ANCP charter below.=20 Please send any comments to the list by Friday 17th April.=20 Best regards=20 Matthew=20 Description of Working Group:=20 Purpose:=20 The purpose of the ANCP WG is to standardize an IP-based Access Node=20 Control Protocol (ANCP) for use in e.g. service provider Digital Subscriber=20 Line (DSL) and Passive Optical Network (PON) access and aggregation networks.=20 ANCP operates between an Access Node (AN) and Network Access Server (NAS).=20 Necessary Terminology:=20 Access Node (AN) - Network device, usually located at a service=20 provider central office or street cabinet, that terminates access loop=20 connections from Subscribers. In DSL, this is often referred to as a=20 Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually=20 comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU)=20 and an Optical Line Termination (OLT).=20 Network Access Server (NAS) - Network device which aggregates=20 multiplexed Subscriber traffic from a number of Access Nodes. The NAS=20 plays a central role in per-subscriber policy enforcement and QoS.=20 This is often referred to as a Broadband Network Gateway (BNG) or Broadband=20 Remote Access Server (BRAS). A detailed definition of the NAS is given=20 in RFC2881.=20 Goals:=20 ANCP is intended to address the requirement for a bidirectional, IP-=20 based, control protocol that operates across multiple types (i.e.,=20 Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an=20 ANCP message exchange is to convey status and control information=20 between one or more ANs and one or more NASs without going through=20 intermediate element managers.=20 The ANCP WG will address the following four use-cases:=20 1. Dynamic Access Loop Attributes=20 Various queuing and scheduling mechanisms are used in access networks=20 to avoid congestion while dealing with multiple flows and distinct QoS=20 profiles. Communicating the access-loop status, attributes and current=20 DSL synchronization rate between the AN and Subscriber up to the NAS=20 is desirable, particularly when the NAS is providing QoS for=20 individual flows and subscribers. ANCP will provide a mechanism to=20 communicate dynamic access-loop attributes from the AN to the NAS.=20 2. Access Loop Configuration=20 In additional to reporting Access Loop characteristics from the AN to=20 the NAS, ANCP will allow a NAS to send loop-specific configuration=20 information to an AN based on the results of subscriber authentication=20 and authorization (e.g., after AAA responses have been received at the=20 NAS).=20 3. Remote Connectivity Test=20 Traditional DSL access and aggregation networks employ point-to-point=20 ATM circuits between the AN and NAS for each subscriber, allowing=20 troubleshooting of the local loop from the NAS via ATM OAM tools. With=20 the increasing deployment of Ethernet in the access and aggregation=20 network, operators require consistent methods to test and troubleshoot=20 connectivity for mixed Ethernet and ATM access networks (including the=20 local loop). ANCP will allow a remote procedure for a local loop=20 connectivity test to be triggered from the NAS with results=20 communicated back to the NAS.=20 4. Multicast=20 When multicast replication for subscriber-bound traffic is performed at=20 the AN, it offloads the network between the AN and NAS. However, a=20 subscriber's policy and configuration for multicast traffic may only be=20 known at the NAS. ANCP will provide a mechanism to communicate the=20 necessary information exchange between the AN and NAS so as to allow=20 the AN to perform subscriber bound multicast group replication in line=20 with the subscriber's policy and configuration, and also allow the NAS=20 to follow each subscriber's multicast group membership.=20 Non-Goals:=20 ANCP is an IP-based protocol that operates between the AN and NAS,=20 over a DSL access and aggregation network. It will not address setup=20 or configuration of circuits or connections in the access and=20 aggregation network itself.=20 The focus of this WG is on one very specific application space. While=20 the design of the protocol must be general as to not preclude other=20 uses in the future should a need arise, it is not a goal of this WG=20 to address specific requirements outside of DSL access and aggregation=20 networks.=20 Security:=20 The ANCP working group will provide a threat analysis and address the=20 associated security aspects of the control protocol.=20 Resiliency and Scalability:=20 A graceful restart mechanism will be defined to enable the protocol to=20 be resilient to network failures between the AN and NAS.=20 Scalability at the NAS is of primary concern, as it may be aggregating=20 traffic from a large number of ANs, which in turn may be serving a=20 large number of Subscribers. ANCP traffic should not become a denial=20 of service attack on the NAS control plane. Format of messages,=20 pacing, transport over UDP or TCP, etc. will be considered with this=20 in mind.=20 For reasons of aggregation network scalability, some use cases require=20 that aspects of NAS or AN functionality may be distributed in nodes in=20 the aggregation network. In these cases, ANCP can run between these=20 nodes.=20 Deliverables:=20 The working group will define a basic framework and requirements=20 document intended for Informational publication, focusing on the four=20 use-cases outlined in this charter. This document will include a=20 security threat analysis and associated requirements. The WG will then=20 investigate and define a solution for an IP based control protocol=20 meeting these requirements.=20 There are early interoperable implementations of an ANCP-like protocol=20 which are based on an extended subset of the GSMPv3 protocol. This=20 running code will be the the starting point for the working group=20 solution, and will be abandoned only if the WG determines it is not=20 adequate to meet requirements going forward.=20 Coordination with other Working Groups or Organizations:=20 The working group will coordinate with the ADSL MIB working group so=20 the management framework and MIB modules are consistent for DSL=20 access environments. The working group will re-use, as far as=20 possible, standard MIB modules that have already been defined.=20 The remote connectivity test use case may require coordination with=20 ITU-T Ethernet OAM work, and with IEEE 802.1ag.=20 Goals and Milestones:=20 Done Accept WG I-D for ANCP Framework and Requirements=20 Done Accept WG I-D for Access Node Control Protocol (ANCP)=20 Done Accept WG ID for Security Threats analysis=20 Done Accept WG I-D for ANCP MIB=20 Done Security Threats Analysis last call=20 Done Framework and Requirements last call=20 Apr 2009 ANCP MIB Last Call=20 Mar 2009 Accept WG I-D for ANCP applicability to PON=20 June 2009 Access Node Control Protocol (ANCP) Last Call=20 Aug 2009 Re-charter or conclude Working Group=20 ------_=_NextPart_001_01C9BCD4.8421CCBE Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Revised charter

o.k.

Thanks.

Thomas

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von BOCCI=20 Matthew
Gesendet: Montag, 6. April 2009 11:12
An:=20 ancp@ietf.org
Betreff: [ANCP] Revised = charter

All,

Following the discussion in San = Francisco, please=20 find the revised ANCP charter below.

Please send any comments to the list by = Friday 17th=20 April.

Best regards

Matthew

Description of Working Group: =
Purpose:

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

Necessary Terminology:

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

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

Goals:

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

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

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

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

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

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

Non-Goals:

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

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

Security:

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

Resiliency and Scalability:

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

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

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

Deliverables:

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

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

Coordination with other Working Groups or = Organizations:

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

The remote connectivity test use case may = require=20 coordination with
ITU-T Ethernet = OAM work,=20 and with IEEE 802.1ag.

Goals and Milestones:

Done    =20       Accept WG I-D for ANCP Framework and = Requirements=20
Done    =20       Accept WG I-D for Access Node Control = Protocol=20 (ANCP)
Done    = =20       Accept WG ID for Security Threats = analysis=20
Done    =20       Accept WG I-D for ANCP MIB =
Done    =      =20 Security Threats Analysis last call
Done     =       =20 Framework and Requirements last call
Apr=20 2009       ANCP MIB Last Call =
Mar 2009        = Accept WG=20 I-D for ANCP applicability to PON
June=20 2009       Access Node Control Protocol = (ANCP)=20 Last Call
Aug=20 2009        Re-charter or conclude = Working=20 Group

------_=_NextPart_001_01C9BCD4.8421CCBE-- From HaagT@telekom.de Tue Apr 14 02:34:52 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 990E83A67A1 for ; Tue, 14 Apr 2009 02:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 DHLinPCoVixb for ; Tue, 14 Apr 2009 02:34:51 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 121463A6AE9 for ; Tue, 14 Apr 2009 02:34:50 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail31.telekom.de with ESMTP; 14 Apr 2009 11:36:00 +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); Tue, 14 Apr 2009 11:36:00 +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_01C9BCE4.6B523222" Date: Tue, 14 Apr 2009 11:35:58 +0200 Message-ID: <5661758E3E93364685B91DD8272F28760117D622@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Framework draft question Thread-Index: Acm2vVE7MxPMo20zQvaJjXUtx/LJ1gCNsybAAPvwWyA= References: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com> From: To: , , X-OriginalArrivalTime: 14 Apr 2009 09:36:00.0103 (UTC) FILETIME=[6BA0B770:01C9BCE4] Subject: Re: [ANCP] Framework draft question 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 Apr 2009 09:34:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BCE4.6B523222 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 you're right that this is a performance requirement.=20 But I think this is an important requirement which has impact on protocol design and gives some developing guideline.=20 So I would propose to keep it. =20 Regards =20 Thomas ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Donnerstag, 9. April 2009 11:21 An: OOGHE Sven; ancp@ietf.org Betreff: Re: [ANCP] Framework draft question FWIW, my opinion is that this requirement isn't for a framework as it is a performace requirement that depends on a large number of things. I'd say drop. =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: 06 April 2009 15:41 To: ancp@ietf.org Subject: [ANCP] Framework draft question =09 =09 Hi,=20 I would like to raise a question regarding draft-ietf-ancp-framework-08.=20 Section 4.1 states "The ANCP MUST allow fast completion of a given operation, in the order of magnitude of tens of milliseconds."=20 This is as such not a protocol requirement, but rather a requirement on the platform choice (e.g. CPU speed).=20 I am soliciting feedback what to do with this (drop / reword / keep).=20 Regards,=20 Sven=20 ------_=_NextPart_001_01C9BCE4.6B523222 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework draft question

Hi,

you're right that this is a performance = requirement.=20

But I think this is an important requirement = which has=20 impact on protocol design and gives some developing guideline.=20

So I would propose to keep = it.

Regards

Thomas

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 9. April 2009 11:21
An: = OOGHE=20 Sven; ancp@ietf.org
Betreff: Re: [ANCP] Framework draft=20 question

FWIW, my opinion is that this requirement isn't for a = framework as=20 it is a performace requirement that depends on a large number of things. = I'd say=20 drop.

-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE = Sven
Sent:=20 06 April 2009 15:41
To: ancp@ietf.org
Subject: = [ANCP]=20 Framework draft question

Hi,

I would like to raise a question = regarding=20 draft-ietf-ancp-framework-08.

Section 4.1 states "The ANCP MUST allow = fast=20 completion of a given operation, in the order of magnitude of tens of=20 milliseconds."

This is as such not a protocol = requirement, but=20 rather a requirement on the platform choice (e.g. CPU speed). =

I am soliciting feedback what to do = with this (drop=20 / reword / keep).

Regards,
Sven

------_=_NextPart_001_01C9BCE4.6B523222-- From wdec@cisco.com Tue Apr 14 06:49:23 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 21BAC3A6DC2 for ; Tue, 14 Apr 2009 06:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.723 X-Spam-Level: X-Spam-Status: No, score=-9.723 tagged_above=-999 required=5 tests=[AWL=0.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YuXlxFKRsP39 for ; Tue, 14 Apr 2009 06:49:22 -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 502C33A6D97 for ; Tue, 14 Apr 2009 06:49:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,185,1238976000"; d="scan'208,217";a="38260956" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 14 Apr 2009 13:50:31 +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 n3EDoVgV003035; Tue, 14 Apr 2009 15:50:31 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3EDoT43027698; Tue, 14 Apr 2009 13:50:31 GMT Received: from xmb-ams-33b.cisco.com ([144.254.231.86]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Apr 2009 15:50:31 +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_01C9BD07.F9A0F51E" Date: Tue, 14 Apr 2009 15:50:25 +0200 Message-ID: In-Reply-To: <5661758E3E93364685B91DD8272F28760117D622@S4DE8PSAAQC.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Framework draft question Thread-Index: Acm2vVE7MxPMo20zQvaJjXUtx/LJ1gCNsybAAPvwWyAACMAZ0A== References: <7168964CAC5C144685272595141B6DBA020E79ED@FRVELSMBS22.ad2.ad.alcatel.com> <5661758E3E93364685B91DD8272F28760117D622@S4DE8PSAAQC.mitte.t-com.de> From: "Wojciech Dec (wdec)" To: , , X-OriginalArrivalTime: 14 Apr 2009 13:50:31.0041 (UTC) FILETIME=[F9D0EF10:01C9BD07] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8427; t=1239717031; x=1240581031; 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]=20Framework=20draft=20question |Sender:=20; bh=obWpv0Ot3yJGSHrvY5HhWF0enXTLb6o1C/0s5ZZfZNM=; b=bU6EXMSIBOzoyZZmAtFbp6joEIKWSMQL4W3otpWkmVtPRIaB80DGq3yKjZ 2pLqtAf6bCquzJN2b/s7pgX3Sj9WU0q5I/FumQdAcRQv3e6QKHxeQMURdQkG LNeVDfwv3l; Authentication-Results: ams-dkim-2; header.From=wdec@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Subject: Re: [ANCP] Framework draft question 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 Apr 2009 13:49:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BD07.F9A0F51E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The performance of even the most optimized implementation of a protocol on an OS, a generic CPU and I/O platform will degrade with the messaging load. Hence what guideline is being provided here is doubtful. I don't quite know who would develop any an implementation that was purposefully slow, and it's equally doubtful as to what would happen should the 10s of ms requirement below not be met (will the protocol break? Will the use-fullness of the protocol disappear?) =20 Cheers, Woj. ________________________________ From: HaagT@telekom.de [mailto:HaagT@telekom.de]=20 Sent: 14 April 2009 11:36 To: Wojciech Dec (wdec); Sven.Ooghe@alcatel-lucent.be; ancp@ietf.org Subject: AW: [ANCP] Framework draft question =09 =09 Hi, =20 you're right that this is a performance requirement.=20 But I think this is an important requirement which has impact on protocol design and gives some developing guideline.=20 So I would propose to keep it. =20 Regards =20 Thomas ________________________________ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec (wdec) Gesendet: Donnerstag, 9. April 2009 11:21 An: OOGHE Sven; ancp@ietf.org Betreff: Re: [ANCP] Framework draft question =09 =09 FWIW, my opinion is that this requirement isn't for a framework as it is a performace requirement that depends on a large number of things. I'd say drop. =20 -Woj. ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE Sven Sent: 06 April 2009 15:41 To: ancp@ietf.org Subject: [ANCP] Framework draft question =09 =09 Hi,=20 I would like to raise a question regarding draft-ietf-ancp-framework-08.=20 Section 4.1 states "The ANCP MUST allow fast completion of a given operation, in the order of magnitude of tens of milliseconds."=20 This is as such not a protocol requirement, but rather a requirement on the platform choice (e.g. CPU speed).=20 I am soliciting feedback what to do with this (drop / reword / keep).=20 Regards,=20 Sven=20 ------_=_NextPart_001_01C9BD07.F9A0F51E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Framework draft question

The performance of even the most optimized implementation of a = protocol=20 on an OS, a generic CPU and I/O platform will degrade with the = messaging load. Hence what guideline is being provided here is = doubtful. I=20 don't quite = know who=20 would develop any an implementation that was purposefully slow, and it's = equally=20 doubtful as to what would happen should the 10s of ms requirement below = not be=20 met (will the protocol break? Will the use-fullness of the protocol=20 disappear?)

Cheers,

Woj.

From: HaagT@telekom.de=20 [mailto:HaagT@telekom.de]
Sent: 14 April 2009 = 11:36
To:=20 Wojciech Dec (wdec); Sven.Ooghe@alcatel-lucent.be;=20 ancp@ietf.org
Subject: AW: [ANCP] Framework draft=20 question

Hi,

you're right that this is a performance = requirement.

But I think this is an important requirement = which has=20 impact on protocol design and gives some developing guideline.=20

So I would propose to keep = it.

Regards

Thomas

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Wojciech Dec=20 (wdec)
Gesendet: Donnerstag, 9. April 2009 = 11:21
An: OOGHE=20 Sven; ancp@ietf.org
Betreff: Re: [ANCP] Framework draft=20 question

FWIW, my opinion is that this requirement isn't for a = framework as=20 it is a performace requirement that depends on a large number of = things. I'd=20 say drop.

-Woj.

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of OOGHE=20 Sven
Sent: 06 April 2009 15:41
To:=20 ancp@ietf.org
Subject: [ANCP] Framework draft=20 question

Hi,

I would like to raise a question = regarding=20 draft-ietf-ancp-framework-08.

Section 4.1 states "The ANCP MUST = allow fast=20 completion of a given operation, in the order of magnitude of tens = of=20 milliseconds."

This is as such not a protocol = requirement, but=20 rather a requirement on the platform choice (e.g. CPU speed). =

I am soliciting feedback what to do = with this=20 (drop / reword / keep).

Regards,
Sven

------_=_NextPart_001_01C9BD07.F9A0F51E-- From lihy@huawei.com Wed Apr 15 01:54: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 493BD3A6A74 for ; Wed, 15 Apr 2009 01:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=-1.053, 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 frhr3Qks4ZgX for ; Wed, 15 Apr 2009 01:54:41 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id E37C63A659C for ; Wed, 15 Apr 2009 01:54:40 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI400FEPWSTV2@szxga01-in.huawei.com> for ancp@ietf.org; Wed, 15 Apr 2009 16:55:42 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KI4002S4WSTJ5@szxga01-in.huawei.com> for ancp@ietf.org; Wed, 15 Apr 2009 16:55:41 +0800 (CST) Received: from L26465 ([10.70.40.87]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI400G07WSSI3@szxml06-in.huawei.com> for ancp@ietf.org; Wed, 15 Apr 2009 16:55:41 +0800 (CST) Date: Wed, 15 Apr 2009 16:55:39 +0800 From: Hongyu Li In-reply-to: <0458D2EE0C36744BABB36BE37805C29A0399C36C@FRVELSMBS11.ad2.ad.alcatel.com> To: 'BOCCI Matthew' , ancp@ietf.org Message-id: <000e01c9bda7$f345dd40$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_MXVOpxaAITdoNxGjwoO+mA)" Thread-index: Acm2l7OPJDgxXxYHQhiQkDPTZUj7SwHD2qUA Subject: Re: [ANCP] Revised charter X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 08:54:43 -0000 This is a multi-part message in MIME format. --Boundary_(ID_MXVOpxaAITdoNxGjwoO+mA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT As the scope is extended from DSL to PON, the following words in charter need to be harmonized. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over a DSL access and aggregation network. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks. Proposal is: Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over a DSL or PON access and aggregation network. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL or PON access and aggregation networks. cheers, Hongyu _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: Monday, April 06, 2009 5:12 PM To: ancp@ietf.org Subject: [ANCP] Revised charter All, Following the discussion in San Francisco, please find the revised ANCP charter below. Please send any comments to the list by Friday 17th April. Best regards Matthew Description of Working Group: Purpose: The purpose of the ANCP WG is to standardize an IP-based Access Node Control Protocol (ANCP) for use in e.g. service provider Digital Subscriber Line (DSL) and Passive Optical Network (PON) access and aggregation networks. ANCP operates between an Access Node (AN) and Network Access Server (NAS). Necessary Terminology: Access Node (AN) - Network device, usually located at a service provider central office or street cabinet, that terminates access loop connections from Subscribers. In DSL, this is often referred to as a Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU) and an Optical Line Termination (OLT). Network Access Server (NAS) - Network device which aggregates multiplexed Subscriber traffic from a number of Access Nodes. The NAS plays a central role in per-subscriber policy enforcement and QoS. This is often referred to as a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in RFC2881. Goals: ANCP is intended to address the requirement for a bidirectional, IP- based, control protocol that operates across multiple types (i.e., Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an ANCP message exchange is to convey status and control information between one or more ANs and one or more NASs without going through intermediate element managers. The ANCP WG will address the following four use-cases: 1. Dynamic Access Loop Attributes Various queuing and scheduling mechanisms are used in access networks to avoid congestion while dealing with multiple flows and distinct QoS profiles. Communicating the access-loop status, attributes and current DSL synchronization rate between the AN and Subscriber up to the NAS is desirable, particularly when the NAS is providing QoS for individual flows and subscribers. ANCP will provide a mechanism to communicate dynamic access-loop attributes from the AN to the NAS. 2. Access Loop Configuration In additional to reporting Access Loop characteristics from the AN to the NAS, ANCP will allow a NAS to send loop-specific configuration information to an AN based on the results of subscriber authentication and authorization (e.g., after AAA responses have been received at the NAS). 3. Remote Connectivity Test Traditional DSL access and aggregation networks employ point-to-point ATM circuits between the AN and NAS for each subscriber, allowing troubleshooting of the local loop from the NAS via ATM OAM tools. With the increasing deployment of Ethernet in the access and aggregation network, operators require consistent methods to test and troubleshoot connectivity for mixed Ethernet and ATM access networks (including the local loop). ANCP will allow a remote procedure for a local loop connectivity test to be triggered from the NAS with results communicated back to the NAS. 4. Multicast When multicast replication for subscriber-bound traffic is performed at the AN, it offloads the network between the AN and NAS. However, a subscriber's policy and configuration for multicast traffic may only be known at the NAS. ANCP will provide a mechanism to communicate the necessary information exchange between the AN and NAS so as to allow the AN to perform subscriber bound multicast group replication in line with the subscriber's policy and configuration, and also allow the NAS to follow each subscriber's multicast group membership. Non-Goals: ANCP is an IP-based protocol that operates between the AN and NAS, over a DSL access and aggregation network. It will not address setup or configuration of circuits or connections in the access and aggregation network itself. The focus of this WG is on one very specific application space. While the design of the protocol must be general as to not preclude other uses in the future should a need arise, it is not a goal of this WG to address specific requirements outside of DSL access and aggregation networks. Security: The ANCP working group will provide a threat analysis and address the associated security aspects of the control protocol. Resiliency and Scalability: A graceful restart mechanism will be defined to enable the protocol to be resilient to network failures between the AN and NAS. Scalability at the NAS is of primary concern, as it may be aggregating traffic from a large number of ANs, which in turn may be serving a large number of Subscribers. ANCP traffic should not become a denial of service attack on the NAS control plane. Format of messages, pacing, transport over UDP or TCP, etc. will be considered with this in mind. For reasons of aggregation network scalability, some use cases require that aspects of NAS or AN functionality may be distributed in nodes in the aggregation network. In these cases, ANCP can run between these nodes. Deliverables: The working group will define a basic framework and requirements document intended for Informational publication, focusing on the four use-cases outlined in this charter. This document will include a security threat analysis and associated requirements. The WG will then investigate and define a solution for an IP based control protocol meeting these requirements. There are early interoperable implementations of an ANCP-like protocol which are based on an extended subset of the GSMPv3 protocol. This running code will be the the starting point for the working group solution, and will be abandoned only if the WG determines it is not adequate to meet requirements going forward. Coordination with other Working Groups or Organizations: The working group will coordinate with the ADSL MIB working group so the management framework and MIB modules are consistent for DSL access environments. The working group will re-use, as far as possible, standard MIB modules that have already been defined. The remote connectivity test use case may require coordination with ITU-T Ethernet OAM work, and with IEEE 802.1ag. Goals and Milestones: Done Accept WG I-D for ANCP Framework and Requirements Done Accept WG I-D for Access Node Control Protocol (ANCP) Done Accept WG ID for Security Threats analysis Done Accept WG I-D for ANCP MIB Done Security Threats Analysis last call Done Framework and Requirements last call Apr 2009 ANCP MIB Last Call Mar 2009 Accept WG I-D for ANCP applicability to PON June 2009 Access Node Control Protocol (ANCP) Last Call Aug 2009 Re-charter or conclude Working Group --Boundary_(ID_MXVOpxaAITdoNxGjwoO+mA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Revised charter

As the scope is extended from DSL to PON, the following words in charter need to be harmonized.

Non-Goals:

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

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

Proposal is:

Non-Goals:

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

cheers,

Hongyu

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew
Sent: Monday, April 06, 2009 5:12 PM
To: ancp@ietf.org
Subject: [ANCP] Revised charter

All,

Following the discussion in San Francisco, please find the revised ANCP charter below.

Please send any comments to the list by Friday 17th April.

Best regards

Matthew

Description of Working Group:
Purpose:

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

Necessary Terminology:

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

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

Goals:

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

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

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

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

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

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

Non-Goals:

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

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

Security:

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

Resiliency and Scalability:

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

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

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

Deliverables:

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

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

Coordination with other Working Groups or Organizations:

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

The remote connectivity test use case may require coordination with
ITU-T Ethernet OAM work, and with IEEE 802.1ag.

Goals and Milestones:

Done          Accept WG I-D for ANCP Framework and Requirements
Done          Accept WG I-D for Access Node Control Protocol (ANCP)
Done          Accept WG ID for Security Threats analysis
Done          Accept WG I-D for ANCP MIB
Done          Security Threats Analysis last call
Done            Framework and Requirements last call
Apr 2009       ANCP MIB Last Call
Mar 2009        Accept WG I-D for ANCP applicability to PON
June 2009       Access Node Control Protocol (ANCP) Last Call
Aug 2009        Re-charter or conclude Working Group

--Boundary_(ID_MXVOpxaAITdoNxGjwoO+mA)-- From alan.kavanagh@ericsson.com Wed Apr 15 07:57:23 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 6387B3A6E97 for ; Wed, 15 Apr 2009 07:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.626, 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 Y9lOKtIb0MgN for ; Wed, 15 Apr 2009 07:57:21 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 78B623A6EB4 for ; Wed, 15 Apr 2009 07:57:21 -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 n3FEwSRs010150; Wed, 15 Apr 2009 09:58:28 -0500 Received: from ecamlmw720.eamcs.ericsson.se ([142.133.1.72]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Apr 2009 09:58:14 -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_01C9BDDA.989E20D3" Date: Wed, 15 Apr 2009 10:58:11 -0400 Message-ID: <35815C929B41D2479A224FE098A272270726037B@ecamlmw720.eamcs.ericsson.se> In-Reply-To: <0458D2EE0C36744BABB36BE37805C29A0399C36C@FRVELSMBS11.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Revised charter Thread-Index: Acm2l7OPJDgxXxYHQhiQkDPTZUj7SwHQoh+g References: <0458D2EE0C36744BABB36BE37805C29A0399C36C@FRVELSMBS11.ad2.ad.alcatel.com> From: "Alan Kavanagh" To: "BOCCI Matthew" , X-OriginalArrivalTime: 15 Apr 2009 14:58:14.0077 (UTC) FILETIME=[99FCC6D0:01C9BDDA] Subject: Re: [ANCP] Revised charter X-BeenThere: ancp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Access Node Control Protocol working group mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2009 14:57:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BDDA.989E20D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks good, just one very small comment in the Non-Goals section: =20 " The focus of this WG is on one very specific application space. While=20 the design of the protocol must be general as to not preclude other=20 uses in the future should a need arise, it is not a goal of this WG=20 to address specific requirements outside of DSL access and aggregation=20 networks. " we should add PON here also! ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI Matthew Sent: April 6, 2009 5:12 AM To: ancp@ietf.org Subject: [ANCP] Revised charter All,=20 Following the discussion in San Francisco, please find the revised ANCP charter below.=20 Please send any comments to the list by Friday 17th April.=20 Best regards=20 Matthew=20 Description of Working Group:=20 Purpose:=20 The purpose of the ANCP WG is to standardize an IP-based Access Node=20 Control Protocol (ANCP) for use in e.g. service provider Digital Subscriber=20 Line (DSL) and Passive Optical Network (PON) access and aggregation networks.=20 ANCP operates between an Access Node (AN) and Network Access Server (NAS).=20 Necessary Terminology:=20 Access Node (AN) - Network device, usually located at a service=20 provider central office or street cabinet, that terminates access loop=20 connections from Subscribers. In DSL, this is often referred to as a=20 Digital Subscriber Line Access Multiplexer (DSLAM). In PON, this is usually=20 comprised of an Optical Network Termination (ONT) / Optical Network Unit (ONU)=20 and an Optical Line Termination (OLT).=20 Network Access Server (NAS) - Network device which aggregates=20 multiplexed Subscriber traffic from a number of Access Nodes. The NAS=20 plays a central role in per-subscriber policy enforcement and QoS.=20 This is often referred to as a Broadband Network Gateway (BNG) or Broadband=20 Remote Access Server (BRAS). A detailed definition of the NAS is given=20 in RFC2881.=20 Goals:=20 ANCP is intended to address the requirement for a bidirectional, IP-=20 based, control protocol that operates across multiple types (i.e.,=20 Ethernet, ATM) of DSL and PON access and aggregation networks. The goal of an=20 ANCP message exchange is to convey status and control information=20 between one or more ANs and one or more NASs without going through=20 intermediate element managers.=20 The ANCP WG will address the following four use-cases:=20 1. Dynamic Access Loop Attributes=20 Various queuing and scheduling mechanisms are used in access networks=20 to avoid congestion while dealing with multiple flows and distinct QoS=20 profiles. Communicating the access-loop status, attributes and current=20 DSL synchronization rate between the AN and Subscriber up to the NAS=20 is desirable, particularly when the NAS is providing QoS for=20 individual flows and subscribers. ANCP will provide a mechanism to=20 communicate dynamic access-loop attributes from the AN to the NAS.=20 2. Access Loop Configuration=20 In additional to reporting Access Loop characteristics from the AN to=20 the NAS, ANCP will allow a NAS to send loop-specific configuration=20 information to an AN based on the results of subscriber authentication=20 and authorization (e.g., after AAA responses have been received at the=20 NAS).=20 3. Remote Connectivity Test=20 Traditional DSL access and aggregation networks employ point-to-point=20 ATM circuits between the AN and NAS for each subscriber, allowing=20 troubleshooting of the local loop from the NAS via ATM OAM tools. With=20 the increasing deployment of Ethernet in the access and aggregation=20 network, operators require consistent methods to test and troubleshoot=20 connectivity for mixed Ethernet and ATM access networks (including the=20 local loop). ANCP will allow a remote procedure for a local loop=20 connectivity test to be triggered from the NAS with results=20 communicated back to the NAS.=20 4. Multicast=20 When multicast replication for subscriber-bound traffic is performed at=20 the AN, it offloads the network between the AN and NAS. However, a=20 subscriber's policy and configuration for multicast traffic may only be=20 known at the NAS. ANCP will provide a mechanism to communicate the=20 necessary information exchange between the AN and NAS so as to allow=20 the AN to perform subscriber bound multicast group replication in line=20 with the subscriber's policy and configuration, and also allow the NAS=20 to follow each subscriber's multicast group membership.=20 Non-Goals:=20 ANCP is an IP-based protocol that operates between the AN and NAS,=20 over a DSL access and aggregation network. It will not address setup=20 or configuration of circuits or connections in the access and=20 aggregation network itself.=20 The focus of this WG is on one very specific application space. While=20 the design of the protocol must be general as to not preclude other=20 uses in the future should a need arise, it is not a goal of this WG=20 to address specific requirements outside of DSL access and aggregation=20 networks.=20 Security:=20 The ANCP working group will provide a threat analysis and address the=20 associated security aspects of the control protocol.=20 Resiliency and Scalability:=20 A graceful restart mechanism will be defined to enable the protocol to=20 be resilient to network failures between the AN and NAS.=20 Scalability at the NAS is of primary concern, as it may be aggregating=20 traffic from a large number of ANs, which in turn may be serving a=20 large number of Subscribers. ANCP traffic should not become a denial=20 of service attack on the NAS control plane. Format of messages,=20 pacing, transport over UDP or TCP, etc. will be considered with this=20 in mind.=20 For reasons of aggregation network scalability, some use cases require=20 that aspects of NAS or AN functionality may be distributed in nodes in=20 the aggregation network. In these cases, ANCP can run between these=20 nodes.=20 Deliverables:=20 The working group will define a basic framework and requirements=20 document intended for Informational publication, focusing on the four=20 use-cases outlined in this charter. This document will include a=20 security threat analysis and associated requirements. The WG will then=20 investigate and define a solution for an IP based control protocol=20 meeting these requirements.=20 There are early interoperable implementations of an ANCP-like protocol=20 which are based on an extended subset of the GSMPv3 protocol. This=20 running code will be the the starting point for the working group=20 solution, and will be abandoned only if the WG determines it is not=20 adequate to meet requirements going forward.=20 Coordination with other Working Groups or Organizations:=20 The working group will coordinate with the ADSL MIB working group so=20 the management framework and MIB modules are consistent for DSL=20 access environments. The working group will re-use, as far as=20 possible, standard MIB modules that have already been defined.=20 The remote connectivity test use case may require coordination with=20 ITU-T Ethernet OAM work, and with IEEE 802.1ag.=20 Goals and Milestones:=20 Done Accept WG I-D for ANCP Framework and Requirements=20 Done Accept WG I-D for Access Node Control Protocol (ANCP)=20 Done Accept WG ID for Security Threats analysis=20 Done Accept WG I-D for ANCP MIB=20 Done Security Threats Analysis last call=20 Done Framework and Requirements last call=20 Apr 2009 ANCP MIB Last Call=20 Mar 2009 Accept WG I-D for ANCP applicability to PON=20 June 2009 Access Node Control Protocol (ANCP) Last Call=20 Aug 2009 Re-charter or conclude Working Group=20 ------_=_NextPart_001_01C9BDDA.989E20D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Revised charter

Looks good, just one very small comment in the = Non-Goals=20 section:

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

From: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] On Behalf Of BOCCI = Matthew
Sent:=20 April 6, 2009 5:12 AM
To: ancp@ietf.org
Subject: = [ANCP]=20 Revised charter

All,

Following the discussion in San = Francisco, please=20 find the revised ANCP charter below.

Please send any comments to the list by = Friday 17th=20 April.

Best regards

Matthew

Description of Working Group: =
Purpose:

Necessary Terminology:

Goals:

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

Non-Goals:

Security:

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

Resiliency and Scalability:

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

Deliverables:

Coordination with other Working Groups or = Organizations:

The remote connectivity test use case may = require=20 coordination with
ITU-T Ethernet = OAM work,=20 and with IEEE 802.1ag.

Goals and Milestones:

------_=_NextPart_001_01C9BDDA.989E20D3-- From lihy@huawei.com Wed Apr 15 18:59:00 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 D34243A67FC for ; Wed, 15 Apr 2009 18:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.526, 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 xmgg-HstWVPj for ; Wed, 15 Apr 2009 18:58:59 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id B49783A6934 for ; Wed, 15 Apr 2009 18:58:58 -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 <0KI600AM1880OJ@szxga03-in.huawei.com> for ancp@ietf.org; Thu, 16 Apr 2009 10:00:00 +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 <0KI600GJ5880LW@szxga03-in.huawei.com> for ancp@ietf.org; Thu, 16 Apr 2009 10:00:00 +0800 (CST) Received: from L26465 ([10.70.40.87]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KI600B5B87Z8S@szxml06-in.huawei.com> for ancp@ietf.org; Thu, 16 Apr 2009 10:00:00 +0800 (CST) Date: Thu, 16 Apr 2009 10:00:02 +0800 From: Hongyu Li In-reply-to: <1B6169C658325341A3B8066E23919E1C015EB404@S4DE8PSAANK.mitte.t-com.de> To: Markus.Freudenberger@t-systems.com, HaagT@telekom.de, wdec@cisco.com, ancp@ietf.org Message-id: <009201c9be37$0e343130$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_HKE+KVHA4GIPrEQj15riMg)" Thread-index: AcmykynN/76iRUjbRlynF3ZIly2OZwAEuVwgAAFjj/AABF4KoAAGCKswAOn+SSAB7hxnsA== Subject: Re: [ANCP] TC Information "unknown" State 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 Apr 2009 01:59:00 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HKE+KVHA4GIPrEQj15riMg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT >From view of topology discovery, sending all physically existing ports is necessary. "unknown" is a proper value for never synced ports. Besides, exploring more about the case that these "unknown" state ports are discovered and reported, tens of ports' status may be reported at the same time, e.g. triggered by pre-provision or line cards come up. Therefore, I suggest we think about using a batch mode sending such a report, which means multiple discovery messages are merged into on ANCP message. This may greatly improve performance and efficiency. Of course, format of such message needs further study. BR, Hongyu _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Markus.Freudenberger@t-systems.com Sent: Monday, April 06, 2009 2:22 PM To: HaagT@telekom.de; wdec@cisco.com; ancp@ietf.org Subject: Re: [ANCP] TC Information "unknown" State All, in the framwork draft (draft-ietf-ancp-framework-08), there is a passage in chapter 4.4 saying the following: o The ANCP MUST support a mechanism to synchronize access port configuration and status information between ANCP peers as part of establishing or recovering the Access Node Control Adjacency. This comfirms IMO the issue raised from Thomas. As specified above, the the AN must report the port status as part of establishing the Access Node Control Adjacency. In practice the Adjacency protocol is established before all the dsl lines are in showtime. Which layer 2 mode (atm or eth) should the AN add into the Access-Node-Identifier? At this point of time, he does not know, in which layer 2 mode the port is operating. He may derives the information from the configured value in the line profile but if the port is configured with multiple modes enabled (e. g. ADSL2plus and VDSL2), there is no clear disctinction possible. Regards Markus _____ Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Haag, Thomas Gesendet: Mittwoch, 1. April 2009 16:36 An: wdec@cisco.com; ancp@ietf.org Betreff: Re: [ANCP] TC Information "unknown" State Hi Woj, the point is that the DSLAM does not know in which Layer 2 mode (Packet Mode, ATM Mode) the Line will synchronize if a port is configured for multimode. >From an ANCP perspective all ports have to report their status regardless if in sync, out of sync, idle what ever. But those ports which do not know the mode because of not beeing synchronized the first time will not retrieve an information from DSL port beeing communicated via ANCP. If a port is not ATM synchronized and if a port is not ETH synchronized what has the DSLAM to report? The Layer 2 status is unknown. >From protocol point of view it should be a point of integrity because we use it for a use case called topology discovery which means to have real information about all ports within a domain. The BRAS can use it for statistics correlate with OAM use case, Line config use case or irgnore it. But this is not a protocol issue it is an element implementation issue. Regards Thomas _____ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Gesendet: Mittwoch, 1. April 2009 13:31 An: Haag, Thomas; ancp@ietf.org Betreff: RE: [ANCP] TC Information "unknown" State Hi Thomas, I still don't quite follow. If the DSLAM is pre-provisioned and the port is down (no CPE on the other end), what is the point of signalling this pre-provisioned but down and "unknown" port to the NAS? Thanks, Woj. _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de Sent: 01 April 2009 11:34 To: Wojciech Dec (wdec); ancp@ietf.org Subject: Re: [ANCP] TC Information "unknown" State Hi Woj, the case occurs if: * a IP-DSLAM Port is preprovisioned and * aDSL port operates in Multi Mode (without DSL pre-enforcement to VDSL2(ETH) or ADSL2plus(ATM)) and * customer did not switch on his CPE (first time) and * DSLAM-BNG sets up adjacency or * a DSL line card comes up. In that situation a DSLAM does not know on which Layer 2 mode the DSL line will synchronize. Having only ATM and ETH without "Unknown" coded the message will be wrong because a DSLAM does not know what to choose because of an unknown L2 status at the DSL port. Regards Thomas _____ Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com] Gesendet: Mittwoch, 1. April 2009 10:46 An: Haag, Thomas; ancp@ietf.org Betreff: RE: [ANCP] TC Information "unknown" State Hi Thomas, if the line is not (and never was) synchronised to a CPE, what would be the point of reporting it to the NAS? Thanks, Woj. _____ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de Sent: 01 April 2009 08:29 To: ancp@ietf.org Subject: [ANCP] TC Information "unknown" State All, operating a DSL port in multi mode which means that ADSL2plus (ATM ) and VDSL2 (ETH) is enabled the following situation occur: For a DSL port which has never been synchronized with a CPE (regardless if ADSL2plus or VDSL2) there is the situation, which layer 2 information has to be reported to BNG via ANCP port status message. In that case new information in the protocol is necessary to inform the BNG about this "unknown" State which is neither represented by ATM nor ETH. I like to encourage ANCP working group to tackle this issue and define a new TC information [ATM, ETH; UNKNOWN] in the protocol draft to indicate the port status as described above. Best regards Thomas --Boundary_(ID_HKE+KVHA4GIPrEQj15riMg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT TC Information "unknown" State

From view of topology discovery, sending all physically existing ports is necessary. "unknown" is a proper value for never synced ports.

Besides, exploring more about the case that these "unknown" state ports are discovered and reported, tens of ports' status may be reported at the same time, e.g. triggered by pre-provision or line cards come up. Therefore, I suggest we think about using a batch mode sending such a report, which means multiple discovery messages are merged into on ANCP message. This may greatly improve performance and efficiency. Of course, format of such message needs further study.

BR,

Hongyu

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of Markus.Freudenberger@t-systems.com
Sent: Monday, April 06, 2009 2:22 PM
To: HaagT@telekom.de; wdec@cisco.com; ancp@ietf.org
Subject: Re: [ANCP] TC Information "unknown" State

All,

in the framwork draft (draft-ietf-ancp-framework-08), there is a passage in chapter 4.4 saying the following:

o The ANCP MUST support a mechanism to synchronize access port configuration and status information between ANCP peers as part of establishing or recovering the Access Node Control Adjacency.

This comfirms IMO the issue raised from Thomas.
As specified above, the the AN must report the port status as part of establishing the Access Node Control Adjacency. In practice the Adjacency protocol is established before all the dsl lines are in showtime. Which layer 2 mode (atm or eth) should the AN add into the Access-Node-Identifier? At this point of time, he does not know, in which layer 2 mode the port is operating. He may derives the information from the configured value in the line profile but if the port is configured with multiple modes enabled (e. g. ADSL2plus and VDSL2), there is no clear disctinction possible.

Regards
Markus

Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Haag, Thomas
Gesendet: Mittwoch, 1. April 2009 16:36
An: wdec@cisco.com; ancp@ietf.org
Betreff: Re: [ANCP] TC Information "unknown" State

Hi Woj,

the point is that the DSLAM does not know in which Layer 2 mode (Packet Mode, ATM Mode) the Line will synchronize if a port is configured for multimode.

From an ANCP perspective all ports have to report their status regardless if in sync, out of sync, idle what ever.

But those ports which do not know the mode because of not beeing synchronized the first time will not retrieve an information from DSL port beeing communicated via ANCP.

If a port is not ATM synchronized and if a port is not ETH synchronized what has the DSLAM to report? The Layer 2 status is unknown.

From protocol point of view it should be a point of integrity because we use it for a use case called topology discovery which means to have real information about all ports within a domain.

The BRAS can use it for statistics correlate with OAM use case, Line config use case or irgnore it. But this is not a protocol issue it is an element implementation issue.

Regards

Thomas

Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Gesendet: Mittwoch, 1. April 2009 13:31
An: Haag, Thomas; ancp@ietf.org
Betreff: RE: [ANCP] TC Information "unknown" State

Hi Thomas,

I still don't quite follow.

If the DSLAM is pre-provisioned and the port is down (no CPE on the other end), what is the point of signalling this pre-provisioned but down and "unknown" port to the NAS?

Thanks,

Woj.

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de
Sent: 01 April 2009 11:34
To: Wojciech Dec (wdec); ancp@ietf.org
Subject: Re: [ANCP] TC Information "unknown" State

Hi Woj,

the case occurs if:

a IP-DSLAM Port is preprovisioned and

aDSL port operates in Multi Mode (without DSL pre-enforcement to VDSL2(ETH) or ADSL2plus(ATM)) and

customer did not switch on his CPE (first time) and

DSLAM-BNG sets up adjacency or

a DSL line card comes up.

In that situation a DSLAM does not know on which Layer 2 mode the DSL line will synchronize. Having only ATM and ETH without "Unknown" coded the message will be wrong because a DSLAM does not know what to choose because of an unknown L2 status at the DSL port.

Regards

Thomas

Von: Wojciech Dec (wdec) [mailto:wdec@cisco.com]
Gesendet: Mittwoch, 1. April 2009 10:46
An: Haag, Thomas; ancp@ietf.org
Betreff: RE: [ANCP] TC Information "unknown" State

Hi Thomas,

if the line is not (and never was) synchronised to a CPE, what would be the point of reporting it to the NAS?

Thanks,

Woj.

From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of HaagT@telekom.de
Sent: 01 April 2009 08:29
To: ancp@ietf.org
Subject: [ANCP] TC Information "unknown" State

All,

operating a DSL port in multi mode which means that ADSL2plus (ATM ) and VDSL2 (ETH) is enabled the following situation occur:

For a DSL port which has never been synchronized with a CPE (regardless if ADSL2plus or VDSL2) there is the situation, which layer 2 information has to be reported to BNG via ANCP port status message. In that case new information in the protocol is necessary to inform the BNG about this "unknown" State which is neither represented by ATM nor ETH.

I like to encourage ANCP working group to tackle this issue and define a new TC information [ATM, ETH; UNKNOWN] in the protocol draft to indicate the port status as described above.

Best regards

Thomas

--Boundary_(ID_HKE+KVHA4GIPrEQj15riMg)-- From fqhuang@huawei.com Tue Apr 21 02:18: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 437C228C120 for ; Tue, 21 Apr 2009 02:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.281 X-Spam-Level: X-Spam-Status: No, score=-0.281 tagged_above=-999 required=5 tests=[AWL=1.433, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJKhyOuTEEzG for ; Tue, 21 Apr 2009 02:18:52 -0700 (PDT) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 93BBE3A67CF for ; Tue, 21 Apr 2009 02:18:44 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIG00K1U1X9SU@szxga02-in.huawei.com> for ancp@ietf.org; Tue, 21 Apr 2009 17:19:58 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIG0071Q1X9UF@szxga02-in.huawei.com> for ancp@ietf.org; Tue, 21 Apr 2009 17:19:57 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIG00LUH1X9K0@szxml06-in.huawei.com> for ancp@ietf.org; Tue, 21 Apr 2009 17:19:57 +0800 (CST) Date: Tue, 21 Apr 2009 17:19:57 +0800 From: Fortune HUANG In-reply-to: <003c01c9bbd5$91cd9f90$7b27460a@china.huawei.com> To: ancp@ietf.org Message-id: <002001c9c262$56b49ab0$7b27460a@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_7WIGiEjPXBZ894aMsKG7Hw)" Thread-index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQAHpyZPABolJpoA== Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 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, 21 Apr 2009 09:18:54 -0000 This is a multi-part message in MIME format. --Boundary_(ID_7WIGiEjPXBZ894aMsKG7Hw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT 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_7WIGiEjPXBZ894aMsKG7Hw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

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.

"Tech Type

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

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

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.

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_7WIGiEjPXBZ894aMsKG7Hw)-- From swadhwa@juniper.net Tue Apr 21 05:25:09 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31FD73A6B88 for ; Tue, 21 Apr 2009 05:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.973 X-Spam-Level: X-Spam-Status: No, score=-5.973 tagged_above=-999 required=5 tests=[AWL=0.625, 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 1Q0qe-+SgV6l for ; Tue, 21 Apr 2009 05:24:56 -0700 (PDT) Received: from chip3og55.obsmtp.com (chip3og55.obsmtp.com [64.18.14.175]) by core3.amsl.com (Postfix) with ESMTP id 8ECE43A6B38 for ; Tue, 21 Apr 2009 05:24:54 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by chip3ob55.postini.com ([64.18.6.12]) with SMTP ID DSNKSe27Yi2lD9ur14uTP0VFlw9OfXH3zG4S@postini.com; Tue, 21 Apr 2009 05:26:13 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.1.340.0; Tue, 21 Apr 2009 05:25:01 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Apr 2009 08:25:00 -0400 From: Sanjay Wadhwa To: Fortune HUANG , "ancp@ietf.org" Date: Tue, 21 Apr 2009 08:24:59 -0400 Thread-Topic: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 Thread-Index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQAHpyZPABolJpoAAHJt9g Message-ID: <998644D4818FC74AA6232DE1D3537977982CB04D41@EMBX01-WF.jnpr.net> References: <003c01c9bbd5$91cd9f90$7b27460a@china.huawei.com> <002001c9c262$56b49ab0$7b27460a@china.huawei.com> In-Reply-To: <002001c9c262$56b49ab0$7b27460a@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_998644D4818FC74AA6232DE1D3537977982CB04D41EMBX01WFjnprn_" MIME-Version: 1.0 Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 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, 21 Apr 2009 12:25:09 -0000 --_000_998644D4818FC74AA6232DE1D3537977982CB04D41EMBX01WFjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 For= tune 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-protoco= l-05 Hi all, Given no further response on this thread, I assume almost none of the peopl= e 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 acco= rding to the charter of ANCP WG, only the DSL and PON (newly added) technol= ogies 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 For= tune 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-protoco= l-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 regi= stry, then what types of technologies are the 0x01 ~ 0x04 indicates respect= ively? I think they should be clearly specified, although I guess they migh= t be 0x01 for 802.3, 0x02 for 802.11a/b/g, 0x03 for 802.163, 0x04 for 802.1= 6m. 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-protoco= l-05 Hi Fortune The intent is to define an ANCP specific tech-type registry, and not take w= hat MIP/PMIP uses as per your reference below. Regards -Sanjay ________________________________ From: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] On Behalf Of For= tune 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 re= gistries. Is the first registry with the name Access Technology Types the r= ight registry for the Tech Type in ANCP protocol, please? If it is, I propo= se we change the 0x05 for DSL in section 5.4.1.1 to be 0x09 or "to be alloc= ated 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-mip= 4-proxy-mode-10.txt] 1 802.3 [RFC-leung-mip= 4-proxy-mode-10.txt] 2 802.11a/b/g [RFC-leung-mip= 4-proxy-mode-10.txt] 3 802.16e [RFC-leung-mip= 4-proxy-mode-10.txt] 4 802.16m [RFC-leung-mip= 4-proxy-mode-10.txt] 5 3GPP EUTRAN/LTE [RFC-leung-mip= 4-proxy-mode-10.txt] 6 3GPP UTRAN/GERAN [RFC-leung-mip= 4-proxy-mode-10.txt] 7 3GPP2 1xRTT/HRPD [RFC-leung-mip= 4-proxy-mode-10.txt] 8 3GPP2 UMB [RFC-leung-mip= 4-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_Ch= owdhury] 2008-08-21 10 3GPP2 HRPD [3GPP2 X.P0061][Kuntal_Ch= owdhury] 2008-08-21 11 3GPP2 1xRTT [3GPP2 X.S0011][Kuntal_Ch= owdhury] 2008-08-21 12 3GPP2 UMB [3GPP2 X.S0054][Kuntal_Ch= owdhury] 2008-08-21 13-255 Unassigned Best Regards, Fortune --_000_998644D4818FC74AA6232DE1D3537977982CB04D41EMBX01WFjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Fortune

Tech Type was originally s= pecified 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 protoc= ol draft). We don’t need to change what has been allocated for DSL (0x05= ) though. We will need to allocate a value for PON.<= /p>

Regards

-Sanjay

From: ancp-bou= nces@ietf.org [mailto:ancp-bounces@ietf.org] On Behal= f Of Fortune HUANG
Sent: Tuesday, April 21, 200= 9 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 thr= ead, I assume almost none of the people in the ANCP mailing list knows what thos= e technologies indicated by Tech Type values of 0x01~0x04 are. =

If Sanjay was right that the Tech Typ= e would a new IANA registry, then according to the charter of ANCP WG, only the DSL and PON (newl= y 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@ie= tf.org
Subject: Re: [ANCP] Question= about the Tech Type in draft-ietf-ancp-protocol-05

Hi Sanjay,

Thank you very much for your answer.<= /span>

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

<= span style=3D'font-size:10.0pt;color:blue'>      &= nbsp; An 8-bit field indicating the applicable technology type value= .
         The Message Type plus the Tech Value uniquely define a single<= br>          Extension Type and can be treated as a single 16 bit extension=
         type. "Tech Type&q= uot; value of 0x05 SHOULD be used by ANCP for DSL
         technology.

<= span style=3D'font-size:10.0pt;color:blue'> &= nbsp; 0x00 Extension block not in use.

<= span style=3D'font-size:10.0pt;color:blue'> &= nbsp; 0x01 - 0x04 Already in use by various technologies

<= span style=3D'font-size:10.0pt;color:blue'> &= nbsp; 0x05 DSL

<= span style=3D'font-size:10.0pt;color:blue'> &= nbsp; 0x06 - 0xFE Reserved

<= span style=3D'font-size:10.0pt;color:blue'> &= nbsp; 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, 200= 9 12:28 AM
To: ancp@ietf.org
Subject: [ANCP] Question abo= ut 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 u= sed by ANCP for DSL technology in section 5.4.1.1 of draft-ietf-ancp-protocol-0= 5.

I can find two related technology type registries at the we= bsite http://www.iana.org/protocols/<= /span> as follow= s, 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, ple= ase? If it is,&nbs= p;= I propose we = change the 0x05 for DSL in section 5.4.1.1 to be 0x09 or "to be allocated= by IANA"&nb= sp;= 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            = ;            &n= bsp;            = ;          Reference
-------- ------------------------------------------------- ---------
0         Reserved           &= nbsp;           &nbs= p;            &= nbsp;      [RFC-leung-mip4-proxy-mode-10.txt]
1         802.3           &nbs= p;            &= nbsp;           &nbs= p;         [RFC-leung-mip4-proxy-mode-10.txt]
2         802.11a/b/g          &nbs= p;            &= nbsp;           &nbs= p;    [RFC-leung-mip4-proxy-mode-10.txt]
3         802.16e           &n= bsp;            = ;            &n= bsp;       [RFC-leung-mip4-proxy-mode-10.txt]
4         802.16m           &n= bsp;            = ;            &n= bsp;       [RFC-leung-mip4-proxy-mode-10.txt]
5         3GPP EUTRAN/LTE           = ;            &n= bsp;            [RFC-leung-mip4-proxy-mode-10.txt]
6         3GPP UTRAN/GERAN          &nbs= p;            &= nbsp;           [RFC-leung-mip4-proxy-mode-10.txt]
7         3GPP2 1xRTT/HRPD           = ;            &n= bsp;           [RFC-leung-mip4-proxy-mode-10.txt]
8         3GPP2 UMB            =             &nb= sp;            =      [RFC-leung-mip4-proxy-mode-10.txt]
9-255     Unassigned

Access Technology Type Option type values=

Reference

[RFC5213<= /span>= ]

Registration Procedures

Expert Review <= font size=3D2>

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<= /font>]	2008-08-21
10	3GPP2 HRPD	[3GPP2 X.P0061][Kuntal_Chowdhury<= /font>]	2008-08-21
11	3GPP2 1xRTT	[3GPP2 X.S0011][Kuntal_Chowdhury<= /font>]	2008-08-21
12	3GPP2 UMB	[3GPP2 X.S0054][Kuntal_Chowdhury<= /font>]	2008-08-21
13-255<= /span>	Unassigned

Best Regards,

Fortune

--_000_998644D4818FC74AA6232DE1D3537977982CB04D41EMBX01WFjnprn_-- From HaagT@telekom.de Tue Apr 21 05:53: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 BE58C28C22A for ; Tue, 21 Apr 2009 05:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=0.186, 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 F2Ze5bzObScm for ; Tue, 21 Apr 2009 05:53:18 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 35AB828C22D for ; Tue, 21 Apr 2009 05:53:16 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 21 Apr 2009 14:54:28 +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); Tue, 21 Apr 2009 14:54:27 +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_01C9C280.4DCFF0D9" Date: Tue, 21 Apr 2009 14:54:25 +0200 Message-ID: <5661758E3E93364685B91DD8272F28760121B653@S4DE8PSAAQC.mitte.t-com.de> In-Reply-To: <998644D4818FC74AA6232DE1D3537977982CB04D41@EMBX01-WF.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ANCP] Question about the TechType in draft-ietf-ancp-protocol-05 Thread-Index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQAHpyZPABolJpoAAHJt9gAAEXLWA= References: <003c01c9bbd5$91cd9f90$7b27460a@china.huawei.com><002001c9c262$56b49ab0$7b27460a@china.huawei.com> <998644D4818FC74AA6232DE1D3537977982CB04D41@EMBX01-WF.jnpr.net> From: To: , , X-OriginalArrivalTime: 21 Apr 2009 12:54:27.0955 (UTC) FILETIME=[4E26FC30:01C9C280] Subject: Re: [ANCP] Question about the TechType in draft-ietf-ancp-protocol-05 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, 21 Apr 2009 12:53:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C280.4DCFF0D9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sanjay, Fortune, =20 given the fact that an access node became now a multi service access node.=20 Would it make sense if we specify new tech type values considering most common existing AN-UNI interfaces as well? The next step should be to identify which use case keeps valid for which technology. =20 I'm thinking of - ATM/STM-1 tributary line card - GE-UNI =20 Regards =20 Thomas =20 _____ =20 Von: ancp-bounces@ietf.org [mailto:ancp-bounces@ietf.org] Im Auftrag von Sanjay Wadhwa Gesendet: Dienstag, 21. April 2009 14:25 An: Fortune HUANG; ancp@ietf.org Betreff: Re: [ANCP] Question about the TechType 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. =20 Regards -Sanjay _____ =20 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 =20 Hi all, =20 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.=20 =20 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.=20 =20 But since PON is now in the charter, we should anyway allocate a Tech Type value for PON.=20 =20 =20 Best Regards, Fortune =20 _____ =20 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, =20 Thank you very much for your answer. =20 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? =20 "Tech Type =20 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. =20 0x00 Extension block not in use. =20 0x01 - 0x04 Already in use by various technologies =20 0x05 DSL =20 0x06 - 0xFE Reserved =20 0xFF Base Specification Use " =20 Best Regards, Fortune _____ =20 From: Sanjay Wadhwa [mailto:swadhwa@juniper.net]=20 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. =20 Regards -Sanjay =20 _____ =20 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 =20 Hi all, =20 I have a question about the Tech Type in ANCP protocol for clarification. =20 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. =20 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. =20 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=20 Reference=20 [ RFC5213]=20 Registration Procedures=20 Expert Review=20 Value Description Reference Registration Date 0 Reserved [ RFC5213] =20 1 Virtual [ RFC5213] =20 2 PPP [ RFC5213] =20 3 IEEE 802.3 [ RFC5213] =20 4 IEEE 802.11a/b/g [ RFC5213] =20 5 IEEE 802.16e [ RFC5213] =20 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 =20 =20 =20 =20 Best Regards, Fortune =20 ------_=_NextPart_001_01C9C280.4DCFF0D9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sanjay, Fortune,

given the fact that an access node became now = a multi=20 service access node.

Would it make sense if we specify new tech = type values=20 considering most common existing AN-UNI interfaces as = well?

The next step should be to identify which use = case=20 keeps valid for which technology.

I'm thinking of - ATM/STM-1 tributary line=20 card

&nbs= p; = ; -=20 GE-UNI

Regards

Thomas

Von: ancp-bounces@ietf.org=20 [mailto:ancp-bounces@ietf.org] Im Auftrag von Sanjay=20 Wadhwa
Gesendet: Dienstag, 21. April 2009 14:25
An: = Fortune=20 HUANG; ancp@ietf.org
Betreff: Re: [ANCP] Question about the = TechType=20 in draft-ietf-ancp-protocol-05

Fortune

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

Regards

-Sanjay

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

Hi=20 all,

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

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

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

Best=20 Regards,

Fortune

From:=20 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';=20 ancp@ietf.org
Subject: Re:=20 [ANCP] Question about the Tech Type in=20 draft-ietf-ancp-protocol-05

Hi=20 Sanjay,

Thank you = very much=20 for your answer.

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

"Tech=20 Type

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

<= /SPAN> 0x00 = Extension block=20 not in use.

<= /SPAN> 0x01 - 0x04 = Already=20 in use by various technologies

<= /SPAN> 0x05=20 DSL

<= /SPAN> 0x06 - 0xFE = Reserved

<= /SPAN> 0xFF Base=20 Specification Use

Best=20 Regards,

Fortune

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

Hi=20 Fortune

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

Regards

-Sanjay

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

Hi = all,

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

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

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

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

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

Access Technology Type = Option type=20 values=20

Reference =

[RFC5213]=20

Registration Procedures=20

Expert Review =

Value

Description

Reference

Registration=20 Date

Reserved

[RFC5213]

Virtual

[RFC5213]

PPP

[RFC5213]

IEEE=20 802.3

[RFC5213]

IEEE=20 802.11a/b/g

[RFC5213]

IEEE=20 802.16e

[RFC5213]

3GPP=20 GERAN

[3GPP TS = 29.275][Julien_Laganier]

2008-07-30

3GPP=20 UTRAN

[3GPP TS = 29.275][Julien_Laganier]

2008-07-30

3GPP=20 E-UTRAN

[3GPP TS = 29.275][Julien_Laganier]

2008-07-30

3GPP2=20 eHRPD

[3GPP2=20 X.P0057][Kuntal_Chowdhury]

2008-08-21

3GPP2=20 HRPD

[3GPP2=20 X.P0061][Kuntal_Chowdhury]

2008-08-21

3GPP2=20 1xRTT

[3GPP2=20 X.S0011][Kuntal_Chowdhury]

2008-08-21

3GPP2=20 UMB

[3GPP2=20 X.S0054][Kuntal_Chowdhury]

2008-08-21

13-255

Unassigned

Best=20 Regards,

Fortune

------_=_NextPart_001_01C9C280.4DCFF0D9-- From fqhuang@huawei.com Tue Apr 21 18:10: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 DBD7428C388 for ; Tue, 21 Apr 2009 18:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.692 X-Spam-Level: X-Spam-Status: No, score=0.692 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, 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 es3TCqUSNxQl for ; Tue, 21 Apr 2009 18:10:15 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C098328C25B for ; Tue, 21 Apr 2009 18:10:14 -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 <0KIH00LDK9YWPS@szxga04-in.huawei.com> for ancp@ietf.org; Wed, 22 Apr 2009 09:11:20 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KIH00JEZ9YWCI@szxga04-in.huawei.com> for ancp@ietf.org; Wed, 22 Apr 2009 09:11:20 +0800 (CST) Received: from h36145c ([10.70.39.123]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KIH00BGZ9YW3S@szxml06-in.huawei.com> for ancp@ietf.org; Wed, 22 Apr 2009 09:11:20 +0800 (CST) Date: Wed, 22 Apr 2009 09:11:18 +0800 From: Fortune HUANG In-reply-to: <998644D4818FC74AA6232DE1D3537977982CB04D41@EMBX01-WF.jnpr.net> To: 'Sanjay Wadhwa' , ancp@ietf.org Message-id: <002f01c9c2e7$3e05a100$7b27460a@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_ktO6RY3kMMnaXGB68PUpOA)" Thread-index: Acm3OSz0fRJk81LAS/ytLoiulpiBygCsVGqQAHpyZPABolJpoAAHJt9gABs/BsA= Subject: Re: [ANCP] Question about the Tech Type in draft-ietf-ancp-protocol-05 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 Apr 2009 01:10:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_ktO6RY3kMMnaXGB68PUpOA) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT 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_ktO6RY3kMMnaXGB68PUpOA) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT

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.

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

Best Regards,

Fortune

Hi Sanjay,

Thank you very much for your answer.

"Tech Type

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

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

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.

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_ktO6RY3kMMnaXGB68PUpOA)-- From anira@cisco.com Mon Apr 27 21:53:33 2009 Return-Path: X-Original-To: ancp@core3.amsl.com Delivered-To: ancp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8F1F3A7007 for ; Mon, 27 Apr 2009 21:53:33 -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 NMCeaW39nZs9 for ; Mon, 27 Apr 2009 21:53:31 -0700 (PDT) Received: from ind-iport-1.cisco.com (ind-iport-1.cisco.com [64.104.129.195]) by core3.amsl.com (Postfix) with ESMTP id 0460C3A6802 for ; Mon, 27 Apr 2009 21:53:30 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,258,1238976000"; d="scan'208";a="49196314" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-1.cisco.com with ESMTP; 28 Apr 2009 04:54:49 +0000 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3S4snh5004088; Tue, 28 Apr 2009 10:24:49 +0530 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3S4rOCV020463; Tue, 28 Apr 2009 04:54:46 GMT Received: from xmb-blr-415.apac.cisco.com ([64.104.140.144]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 10:24:09 +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: Tue, 28 Apr 2009 10:24:07 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Sub Capability Negotiation Thread-Index: AcnHvVzNeH5Ljj8LRXuAqsjQlTz63w== From: "Aniruddha A (anira)" To: "Francois Le Faucheur (flefauch)" , "Maglione Roberta" , "Tom Taylor" X-OriginalArrivalTime: 28 Apr 2009 04:54:09.0440 (UTC) FILETIME=[5DDED200:01C9C7BD] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1486; t=1240894489; x=1241758489; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=anira@cisco.com; z=From:=20=22Aniruddha=20A=20(anira)=22=20 |Subject:=20Sub=20Capability=20Negotiation |Sender:=20; bh=zRN49dEsxVfO8mP39n+jRaX8Q5UCyMeMQ2Vjw2GCBTA=; b=kp6Sx5PSjSAlwR8Yb+IYn/v9QmjtFV5GRiR0YRhCuym+qO89hG4vYt71QO DN38ocLFVlfGzN07xaYgDqeoE5Dg4ZjT3XLqj3QSKjZ/DeGGAJkqB3XthMQD CDS69A0Myu; Authentication-Results: ind-dkim-1; header.From=anira@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: ancp@ietf.org Subject: [ANCP] Sub Capability Negotiation 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 Apr 2009 04:53:33 -0000 Hi All, =20 In draft-lefaucheur-ancp-mc-extensions-01, we have a non boolean capability - Multicast with sub-capability negotiation. The value of the TLV is 1 byte, so there has to be padding to align it to 32-bit boundary, in that case, I want to know how the sub-capabilities are to be=20 encoded, i.e., will we have the value in LSB (padding followed by value) or MSB (value followed By padding) ? With sub-capabilities, I would like to propose that we use 1 bit for each value, and change the Length to 4 bytes to simplify encode/decode. i.e, From draft-lefaucheur-ancp-mc-extensions-01, Section 5: Capability Data (1 byte): The following values are defined: + 0x00: Reserved + 0x01: "Transactional Multicast" + 0x02: "Transactional Multicast" and "Multicast Admission Control without Bandwidth Delegation" + 0x03: "Transactional Multicast", "Multicast Admission Control without Bandwidth Delegation" and "Multicast Admission Control with Bandwidth Delegation" + other values: Reserved =20 Instead, use: + 0x00: Reserved + 0x01: "Transactional Multicast" + 0x02: "Multicast Admission Control without Bandwidth Delegation" + 0x04: "Multicast Admission Control with Bandwidth Delegation" If the AN has all 3 Multicast sub-capabilities, then the sub-capability value will be 0x07 -- Regards, Aniruddha. A From tom.taylor@rogers.com Tue Apr 28 06:33:23 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 580193A6C38 for