Re: [L2CP] Updated LC charter

stefaan.de_cnodder@alcatel.be Tue, 23 May 2006 10:53 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUVs-000465-BP; Tue, 23 May 2006 06:53:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiUVr-00045y-39 for l2CP@ietf.org; Tue, 23 May 2006 06:53:19 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiTxl-0007bg-7m for l2CP@ietf.org; Tue, 23 May 2006 06:18:05 -0400
Received: from smail.alcatel.fr ([62.23.212.165]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FiTqk-0005Q6-Dw for l2CP@ietf.org; Tue, 23 May 2006 06:10:53 -0400
Received: from bemail06.netfr.alcatel.fr (bemail06.netfr.alcatel.fr [155.132.251.30]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4NAAmYe006468 for <l2CP@ietf.org>; Tue, 23 May 2006 12:10:48 +0200
Received: from [138.203.192.189] ([138.203.192.189]) by bemail06.netfr.alcatel.fr (Lotus Domino Release 5.0.12HF868) with ESMTP id 2006052312104726:2627 ; Tue, 23 May 2006 12:10:47 +0200
Message-ID: <4472DFA7.40609@alcatel.be>
Date: Tue, 23 May 2006 12:10:47 +0200
From: stefaan.de_cnodder@alcatel.be
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthew.Bocci@alcatel.co.uk
Subject: Re: [L2CP] Updated LC charter
References: <OF5D6E27DC.A9A2E902-ON80257176.00657E7F-80257176.00658A53@alcatel.com>
In-Reply-To: <OF5D6E27DC.A9A2E902-ON80257176.00657E7F-80257176.00658A53@alcatel.com>
X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/23/2006 12:10:47, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 05/23/2006 12:10:47, Serialize complete at 05/23/2006 12:10:47
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: l2CP@ietf.org
X-BeenThere: l2cp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Layer 2 Control Protocol Discussion List <l2cp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/l2cp>, <mailto:l2cp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/l2cp>
List-Post: <mailto:l2cp@ietf.org>
List-Help: <mailto:l2cp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/l2cp>, <mailto:l2cp-request@ietf.org?subject=subscribe>
Errors-To: l2cp-bounces@ietf.org

Matthew,

> 
> Network Access Server (NAS) - Network device which aggregates
> multiplexedSubscriber traffic from a number of Access Nodes. The NAS
> plays a central role in per-subsciber policy enforcement and QoS. Often
> referred to as an Broadband Network Gateway (BNG) or Broadband Remote
> Access Server (BRAS).
> 
> [Stefaan] RFC2138 already define the term NAS. Is it the same
> definition? Is it needed to repeat it, if not the same then better to
> use another term.
> 
> MB> Unfortunately they do not seem to be exactly the same, since the RFC
> assumes a RADIUS client in the NAS. Do you have any other suggestions?
> Could we just go with BNG, as per the DSL Forum?
> 

BNG looks fine for me, and remove NAS to avoid confusion.


> 
> 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 end-to-end ATM
> loopbacks. 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.
> 
> [Stefaan] I would remove "via end-to-end ATM loopbacks" because the text
> seems to suggest that ATM loopbacks have to be used consistently...
> 
> MB> This sin't a requirement, but rather an explanation of how things are
> today. How about "...via ATM OAM tools."?
> 

Ok, by rereading it, it looks Ok.

regards,
Stefaan


> 
> 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 should 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.
> 
> 
> [Stefaan] A goal of the working group is to solve the requirements for
> DSL access in such a way that the solution can be re-used later for
> other technologies as well. Is is something that should be clearer in
> the "goals" section.
> 
> 
> 
> 
> regards,
> Stefaan
> 
> 
> 
> 
> 

_______________________________________________
L2cp mailing list
L2cp@ietf.org
https://www1.ietf.org/mailman/listinfo/l2cp