Re: [L2CP] Updated LC charter
Matthew.Bocci@alcatel.co.uk Wed, 24 May 2006 11:29 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirY2-0007Ro-SH; Wed, 24 May 2006 07:29:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirY2-0007Rj-5d for l2CP@ietf.org; Wed, 24 May 2006 07:29:06 -0400
Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FirY0-0000lA-M2 for l2CP@ietf.org; Wed, 24 May 2006 07:29:06 -0400
Received: from gbmail02.netfr.alcatel.fr (gbmail02.netfr.alcatel.fr [155.132.251.26]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4OBT10H005952 for <l2CP@ietf.org>; Wed, 24 May 2006 13:29:01 +0200
In-Reply-To: <4472DFA7.40609@alcatel.be>
Subject: Re: [L2CP] Updated LC charter
To: Stefaan De Cnodder <stefaan.de_cnodder@alcatel.be>
X-Mailer: Lotus Notes Release 6.5 September 26, 2003
Message-ID: <OF82B53986.19BEA0BB-ON80257178.003E4E17-80257178.003E972C@netfr.alcatel.fr>
From: Matthew.Bocci@alcatel.co.uk
Date: Wed, 24 May 2006 12:23:39 +0100
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.13aHF163 | June 23, 2005) at 05/24/2006 12:29:01
MIME-Version: 1.0
Content-type: text/plain; charset="us-ascii"
X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 2086112c730e13d5955355df27e3074b
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
Stefaan, On further investigation, it seems that RFC2881 describes a NAS in detail. This appears to coincide with what the DSLF would term a BNG or BRAS. To keep with current IETF terminology, I suggest we continue to use NAS, but add a reference to RFC2881 for the detailed NAS definition. Best regards, Matthew Stefaan DE CNODDER/BE/ALCATE L@ALCATEL To Matthew BOCCI/GB/ALCATEL@ALCATEL 23/05/2006 11:10 cc l2CP@ietf.org Subject Re: [L2CP] Updated LC charter 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
- [L2CP] Updated LC charter Matthew.Bocci
- Re: [L2CP] Updated LC charter stefaan.de_cnodder
- Re: [L2CP] Updated LC charter Matthew.Bocci
- Re: [L2CP] Updated LC charter stefaan.de_cnodder
- Re: [L2CP] Updated LC charter Matthew.Bocci
- Re: [L2CP] Updated LC charter stefaan.de_cnodder
- Re: [L2CP] Updated LC charter Matthew.Bocci