Re: [L2CP] Updated LC charter

Stefaan,

The working group only has requirements for DSL at present, but I agree
that the ANCP protocol should be engineered such that it can be applied to
other access technologies in the future. The charter needs to be a bit
clearer on this distinction, and so I suggest loosening the wording of the
purpose and the AN definition, so that we do not preclude the AN from being
something other than a DSLAM:

"Purpose:

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

"Access Node (AN) - Network device, usually located at a service
provider central office, that terminates access loop connections from
Subscribers. For DSL, this is often referred to as a Digital Subscriber
Line Access
Multiplexer (DSLAM)"

best regards,

Matthew

             Stefaan DE                                                    
             CNODDER/BE/ALCATE                                             
             L@ALCATEL                                                  To 
                                       Matthew BOCCI/GB/ALCATEL@ALCATEL    
             24/05/2006 13:51                                           cc 
                                       l2CP@ietf.org                       
                                                                   Subject 
                                       Re: [L2CP] Updated LC charter       

Hi Matthew,

In that case it is better to use the IETF terminology (NAS) and put a
reference to the relevant RFC.

One more comment on this part of the charter:

"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."

This is rather vague to me. According to me the requirements are only
comming from DSL, and the WG does not have to look to solutions for
non-DSL requirements but the protocol that has to meet these
requirements has to be DSL independent. For each requirement, there must
be the necessary TLVs to meet the requirement. If a non-DSL access
network has the same requirement, then the same TLVs can be used. For
instance, advertising the bandwidth might be used for non-DSL as well,
possibly by defining some extra encapsulation types in the existing
sub-tlv if needed. This is to avoid that we have in the future many TLVs
that are actually doing the same.

Obviously, when there is a requirement to advertise certain DSL specific
attributes, then this will result in a TLV that is only relevant for DSL
but that is not a problem because non-DSL will never has this
requirement and hence will not use the TLV.

This will have impact on the protocols draft because it defines the TLV
"DSL Line Attribute" which is too specific but I believe with renaming
the TLVs/sub-TLVs and rewording the description, it can be made more
general.

regards,
Stefaan

Matthew.Bocci@alcatel.co.uk wrote:

> 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