Re: AW: AW: [L2CP] Updated LC charter

Thomas,

I agree with your point about multicast. However, I don't think that the
original charter statement precluding signalling of the underlying
aggregation network disallows this. The issue is more to do with how we
distribute NAS functionality. ANCP needs to be flexible enough to
accommodate the envisaged access/aggregation architectures, and should not
limit the choice of architecture.

I would propose that we add a statement to the effect that, for
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.

Best regards,

Matthew

             "Haag, T"                                                     
             <Thomas.Haag@t-sy                                             
             stems.com>                                                 To 
                                       Matthew BOCCI/GB/ALCATEL@ALCATEL    
             23/05/2006 11:56                                           cc 
                                       l2cp@ietf.org                       
                                                                   Subject 
                                       AW: AW: [L2CP] Updated LC charter   

Matthew,

Thanks for the response. Please see inline.

Regards

Thomas

Thomas,

Thanks for your comments. Please see below.

Matthew

             "Haag, T"
             <Thomas.Haag@t-sy
             stems.com>                                                 To
                                       Matthew BOCCI/GB/ALCATEL@ALCATEL
             23/05/2006 11:18                                           cc
                                       l2cp@ietf.org
                                                                   Subject
                                       AW: [L2CP] Updated LC charter

Matthew,

Please see inline my comments:

?
Necessary Terminology:

Access Node (AN) - Network device, usually located at a service
provider central office [Th. Haag] or street cabinet, that terminates DSL
connections from
Subscribers. Often referred to as a Digital Subscriber Line Access
Multiplexer (DSLAM)

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

1. Dynamic Access Loop [Th.Haag] 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 [Th.Haag] status and 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 [Th.Haag] attributes from the AN to the NAS.

?

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 [Th.Haag] network
management operation of circuits or connections in the access and
aggregation network itself [Th.Haag] but will not exclude use case relevant
aspects of access and aggregation.

MB> We should not loose the fact that ANCP is not a signalling protocol for
the establishment of ATM or Ethernet connectivity in the aggregation
network. The current use cases do not require this, so I'm not sure that I
understand your point.

TH> That's o.k but use case relevant aspects such as e.g. Multicast should
not exclude that elements along the data path between BNG and DSLAM may
retrieve information and support use case specific functionality.
I think of in case of multicast it may be the case that an aggregation
device (aggregating street cabinet DSLAMs; scalability issue) can have the
multicast point which may be controlled by ANCP (e.g. configuration of
access lists...;combined with IGMP snooping in the aggregation).

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.

?
Keeping in mind the following comments of the minutes I propose the changes
regarding Non-goals.

      Mark Townsley:
      - we should not even precule other use of the protocol in other
      areas?.

      Mark Townsley: Scoping of that group is driving to solve existing
      problem. We should use good engineering to build things to allow
      future problems but we should not try to solve everything from the
      start.

Regards
Thomas

-----Ursprüngliche Nachricht-----
Von: Matthew.Bocci@alcatel.co.uk [mailto:Matthew.Bocci@alcatel.co.uk]
Gesendet: Montag, 22. Mai 2006 18:20
An: l2cp@ietf.org
Betreff: [L2CP] Updated LC charter

Folks,

We received a number of comments back from our ADs on the draft charter,
following the last call that we issued a few weeks ago.

Please find attached a new revision of the charter that incorporates these
comments. Please post any comments to the list by this Friday (26th May).

This will be taken to the IESG once once the list has agreed to the
revisions.

best regards,

Matthew
(See attached file: ANCP-charter-220506.txt)

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