1. Introduction / agenda tweaking / Blue Sheets (Chairs - 5 mins) 2. Working Group Charter (Chairs - 10 mins) - Changes to the charter since the BoF. - Discussed in BOF - Revised milestones - Mailing list changes Chair: ANCP charter revised and finalized following input from alias and ADs. Milestones adjusted to reflect delivery of requirements draft (end of 2006) before protocol spec. L2CP mailing list no longer active - all members moved to ANCP list. Questions Emmanuel Desmet: Why are we using NAS (IETF) vs BNG (DSL Forum) Chair: Because IETF has traditionally used the term NAS. Q2 (?ECI). What is the connection between DSL Forum work and ANCP WG. A2. IETF defines protocols, DSL Forum defines use cases. Requirements come from DSL Forum. Normal liaison process and common group membership will be used to keep synch. Mark Townsley - DSL Forum relationship is mentioned in charter. 3. ANCP Requirements (Stefaan de Cnodder - 15mins) http://www.ietf.org/internet-drafts/draft-ooghe-ancp-framework-00.txt Update on changes since the BoF Ralph Droms: Clarification on connectivity tests to Home Gateway (Actually NAS to AN). Protocol triggers the NG to perform a line test. Should this become a Working group document? General consensus was YES from those who read the document and present in the room. 4. GSMP extensions for layer2 control (L2C) Topology Discovery and Line Configuration (Sanjay Wadhwa - 15 mins) http://www.ietf.org/internet-drafts/draft-wadhwa-gsmp-l2control-configuration-01.txt Update on changes since the BoF; summary in posted slides 5. ANCP Graceful Restart Mechanism (Sanjay Wadhwa - 10 mins) http://www.ietf.org/internet-drafts/draft-wadhwa-ancp-graceful-restart-00.txt New draft A. Doria: Change to base protocol spec? Sanjay Yes, this mechanism requires modifications to base spec. Mark T.: Consider adding a new milestone. This is ok, as long as work fits within the charter. Doria: Extensions are defined in companion specs. But core spec must be modified to allow graceful restart. How is this to be handled? Discussion on whether to collapse these to specs. Doria suggest that maybe this be appropriate. Mark T.: Call can be made once the requirement doc progresses. Sanjay: Can we make this doc a WG I-D? Charter only has one protocol requirement. Can we add this one. WG Chair: To early to ask for working group consensus on graceful restart doc. Keep as draft for working group to review and consider. Open discussion and Questions on original protocol spec draft (draft-wadhwa-gsmp-l2control-configuration-01.txt and draft-ooghe-ancp-framework-00.txt) : Question: Layer two encaps. Dsl line can have several l2 encaps, vlans w/diff services. Document says one vlan per line and one encaps. How are multiple vlans to be handled? Answer(Sanjay): Multiple vlans are supported. Multiple encaps needs some considerations. Comment from audience: “encap is only important for shaping function on NAS if encap is changing eg from oA to oE”. Q (?FT): Security objectives in charter, does it concern security between NAS and AN or protocol security? Answer (Chair): Requirements doc security section is not completed. Security objective is for the ANCP protocol itself. Mark would like a threat analysis done first then produce security requirements. Q (G. Bailey): Name of use-case “line config and topology discovery Wants it renamed. A(Chair): There is a new name for it. Q (G. Bailey): Should refer back to the framework document? A (Sanjay): Some documents need cleanup because requirements came after some ID's. Q (ECI): What is reason for new remote line id? A (Sanjay): Host identifier is a mandatory. Newly added optional parameter, compatible with dhcp and pppoe. Could be used to convey info from nas to policy server. Different than “local loop identification” contains more user specific information. Comment from audience: Circuit id not always configurable on AN but remote id usually is. Q (P. Arberg): Multiple VC's on line, how should the case be handled when a VC is removed and OAM is attempted? A (Sanjay): OAM specification of VC/VLAN should trigger a specific error code when VC/VLAN does not exist(?) 6. ANCP MIBs (Stefaan de Cnodder - 10 mins) Based on GSMP MIB (3295). ANCP MIB is an extension of GSMP MIB. Q (A. Doria): Suggests doing a whole new GSMP MIB because current one is inadequate. First proposal of Access Node part will be done soon. A (Steffan) would like help working on MIBs, looking for volunteers especially to progress NAS MIBs. Chair: MIB work has to remain open to changes in base protocol spec, especially since security and transport aspects are still to be addressed. 7. Discussion of outstanding working group items (Chairs - 30mins) - Access Node Port and Functional Partitioning and multiple controllers. Description of current 1-1 role of controller and idea of controller redundancy and functional split concept. Questions 1,2 and 3 on the chair's slides. Do we need to add redundancy to controllers? Split functionality of controllers (ie: QOS and OAM and Multicast). Sanjay: Start with controller redundancy split rather than functional split. Chair: Functional split and multiple edge are not excluded by the current scope. Doria: Similar issue seen in Forces WG. What about sync mechanism between redundant controllers? Sanjay: Statefull or Stateless Controller redundancy is the question. First can handle the stateless case and then move to stateful. More show of hands for interest in controller split than functional split. Majority of room with no opinion. Very little comments from audience. To be brought to the WG mailing list for discussion. Mark T: lets take the questions to the list for further consideration. - Light-weight transport protocol. Chair: Light weight transport is intended to make ANCP scale to large deployments with 100s-1000s of nodes. Chair Question 1: what are the actual transport requirements? Sanjay: ANCP requirements should be generic. Requirements spec shold not identify a transport protocol. Protocol spec can contain this level of detail. Requirements should indicate that this use case requires this transport requirement. Chair: Agree. Chair Question2: does light weight transport become the long term goal over TCP? Rough opinion from floor: Would prefer light weight protocol. More discussion needed. Chair Question 3: Do we look for an existing light-weight transport? Preference is clearly for not inventing a new transport protocol. But before any selection can be made requirements need to be drafted. Current protocol requirements doc does not sufficiently address transport requirements. Droms: What is the IESG/IAB guidance regarding transport protocol selection? Mark T: Not going to talk to transport ADs or do protocol selectionuntil we have requirements. Once that's there consultation will be made. Chair: WG needs to contribute transport requirements into existing requirements draft to answer question 1. - ANCP Protocol Security. Chair: No progress on critical item for the protocol. Various aspects have impact on security, eg choice of transport. Thread model is need. Mark T: suggests not using TCP MD5. Chair is looking for volunteers to develop a threat model and derive requirements. - Multicast control. Chair: Two main functions mentioned for multicast so far i) control of replication or multicast data plane and ii) multicast group and statistics reporting. Use cases remain to be firmed up. Would like to involve multicast WGs in this. Susheela Vaidya: Mboned has multicast session control and admission work going on that can go along with this.