Subject: Re: [L2CP] Updated LC charter

From: [email-masked]
Date: Tue, 23 May 2006 12:10:47 +0200

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2cp

---

From: [email-masked]
Date: Wed, 24 May 2006 12:23:39 +0100

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 
                                       [email-masked]                       
                                                                   Subject 
                                       Re: [L2CP] Updated LC charter       

                                                                           

Matthew,

regards,
Stefaan