WEDNESDAY, March 22, 2006 - 0900-1130 =================================== CHAIRS: Matthew Bocci (matthew.bocci@alcatel.co.uk) & Wojciech Dec (wdec@cisco.com) SCRIBE: Andrew Dolganow (andrew.dolganow@alcatel.com) Presentations available at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Introduction/agenda tweaking (Chairs) ------------------------------------- Matthew provides an introduction to the BoF. Problem Description - Thomas Haag --------------------------------- Draft: draft-ooghe-l2cp-framework-00.txt Presentation included: - Problem statement including reference to existing technology limitations (ITU- T H.610 DSLF TR-059) - Reference architecture, - Use cases: - (current) Access line discovery (reporting access device characteristics (like QoS) to other devices, enforcing service parameters on access links) - (Future) OAM (triggering OAM mechanism on access links, Mechanism include ATM-OAM for ATM-ETh Interworking and Ethernet-OAM for E2E) - (Future) Multicast (multicast info between subscriber management and access devices for things like policy controls) - (Future) Line Configuration (subscriber management or Policy request triggering BNG to send line config to DSLAM) - List of protocol requirements: - keep-alive - shutdown mechanism for graceful shutdown - request/response transaction model - report model for communication to BNG from access node - protocol mapped on top of IP - "boot" sequence for control capabilities between 2 peers Peter Busschbach: Why you need to go through BRAS for your scenarios. May make more sense to have protocol to go directly from management to DSLAM. Thomas: We have some basic scenarios to go through, open to other scenarios. The service node needs to know the state of the link, but currently does not if you go through management. Peter Busschbach: True for ATM, but new generation of DSLAM are Eth based. They can make and look at IP header and make decision based on that. Thomas: Basic intention is to shape at service aggregation point, you need to account for drops, you don't want to drop at access node Peter Busschbach: New gen DSLAMs count packets and discards already. Thomas: Disagreement for some boxes there (street cabinets) Peter Busschbach: Again why wouldn't you go straight from OSS again? Len Casey: Some confusion between BNG and Service nodes in the presentation. Why do you think you need a common protocol for all cases? Why SNMP isn't protocol for 1st case? 2-nd problem with PWE3? You have a generic OAM issue. 3rd multicast: service issue? 4th case provisioning again. Thomas: SNMP does not meet requirements of protocol (keep alive, boot, etc.) ?: The work is great; we see the same requirements from other places. You should extend IP protocol to aggregator. Overview of proposed protocol solution (Sanjay Wadhwa) ----------------------------------------------------- draft-wadhwa-gsmp-l2control-configuration-00.txt The presentation focused on the following main topics: - Terminology - BNG - broadband network gateway - aggregation, injection point of policy and IP QOS - Access Node - terminates local loop, aggregates from local loops into single aggregation network L2CP is a protocol between the 2 - Control Plane req for dynamic QoS, service subscriber related ops Simple (reuse existing work); Lightweight (limited resources on access); Extensible (cater to other things like PON); Flexible (IP based not based on underlying technologies like ATM); Support transaction exchange for communication; Minimize config overhead (Opex reduction); Keepalive; graceful shutdown, scalability (adjacencies, transactions); Ideally no soft state; Incremental update of info; Support non-disruptive "on-demand" state refresh; Support restart, HA mechanisms - GSMPv3 as a base for the protocol GSMPv3 maps well to the use cases. GSMPv3 is big, we only need a subset, the subset is identified in the draft. Master (BNG), Slave (DSLAM), GSMP over TCP; GSMP connection establishment (Access node init connection) - diverge from GSMP spec; Extensions to adjacency protocol (capability TLVs, negotiation of capabilities, capability mismatch handling, etc.) - Restating of use cases identified in the framework with the GSMP mechanism applicabilities (using Port-Up and Port Down Event messages; TLVS for access line identification and attributes; using Port Management message with required extensions to function field, technology type, etc.; no yet extensions to handle Multicast) - Current status of the protocol Some work in DSL forum (working text 147), desire for framework and protocol work in IETF, implementations already exist - need to interop test them. ?: Why do you need TCP? Scalability and DOS attack are a concern Sanjay: Don't want a soft state - will help scalability, there are ways to mitigate DoS attacks, ?: Soft state and UDP are unrelated issues. Wojciech: Regarding TCP, it's one of issues group identified, finding alternative transport to scale protocol may be a work item. Andy Malis: unhappy about the name (DSL control protocol), stay away from L2 CP, Sanjay: Charter does not preclude other access technologies (like PON), open to rename Wojciech: We will likely change the name to avoid confusion Andy Malis: Haven't see a requirement for GSMPv3, what about SNMP? Is the purpose of WG to ratify design choice? Sanjay: there are clearly cases when SNMP is not suitable. State across org boundaries, history thought us SNMP may not work Wojciech: WG is willing to consider extensions to other protocols, Currently limited scope to what was presented Sandy Ng: We need a lighter TCP as scalability issues may be an issue Sanjay: There could be other ways to solve scalability. Using ,mechanisms like BGPs reflectors, the basic issue is how we scale protocol Sandy: Would we be adding more complexity to the protocol by solving scalability in TCP? Dinesh Mohan): Objective to have mechanism independent of L2 technology is good. But the current trends of migration to Ethernet should not be ignored and should be used and considered. There is Ethernet OAM work happening (ITU for example) that could be used here. Sanjay: You are right. As things stand no interworking local (ATM) aggregation (Eth). Nothing in stone, this is simple way. Wojciech: This is not a full-blown OAM, but a gap-fill mechanism; we need the other work Dinesh. mentions Dinesh Mohan: I point this outgoing work as I see no mention of it and how would it be taken into account in the future. Sven Ooghe: First thing: do we agree on the uses cases: I support them, You have QoS in access node (though we need to use it with conjunction of what proposed here), same goes for OAM work in progress, for a mapping of protocol (the work based on GSMP is promising) I support to progress that, we need a clear cut between framework and protocol. Stephaan de Cnodder: quite a lot of TLVs and extensions are defined, where is that choice coming from? Sanjay: No forum where this was discussed in detail, some discussions on using GSMP happened in DSL Forum, don't want to reinvent another protocol Proposed work items (Wojciech Dec) --------------------------------- Protocol challenges: - Applicability of GSMP, - Scalability of transport protocol, - HA/Graceful restart/Stateful switchover handling, - DB scaling and stale entries (1000's of subscribers/lines), -Protocol security/peer authentication One more from the floor: -Integration with multicast (Mark Townsley) Proposed work items: -Framework/requirements (use cases, id protocol requirements) -Protocol spec (extension to existing protocol, proposal to extend a subset of GSMPv3) -MIBs Dan Romascanu: Are you expecting other protocol proposals? Wojciech: The informal WG has chosen GSMP, but if a WG is to be formed, we are open to discussions to change that Mark Townsley: It's important to think have we chosen right, but we have running code so the burden on proof to change the protocol is higher ?: We have BGP running code, so why not use that:-) Loa Andersson: No mention of security at all now? What are security issues? Wojciech: Agree, we know we have security as an issue ?: I think there is a slight confusion on version of GSMP. What the draft mentioned here is version 4. We should update this everywhere Avri Doria: The confusion is my fault as 07 draft is still calling itself v3, as we are moving it forward we will have to upgrade to v4. With the attention to use 07 as base, we missing technology specific piece, we did not want to have that in GSMP draft as not to intro baggage for everyone else. Wojciech: Agreed. It's clear we don't need full GSMP functionality, not an intension to create backward compatible protocol with GSMP v3, but take a base from GSMP and extend to use use cases ?: Is the extension a branching of the protocol? Wojciech: Fair statement. That's a reason we need a new name. There has been fair amount of work carried from and done in DSL Forum, we would likely need to work with them, we want to improve on past DSL Forum experience. Dan Romascanu: We need to limit a first version of the charter to a well-defined scope to solve the immediate problem of people who need this protocol now, and think about generality and expandability later and in a broader context - this not being the only IP control plane for a sub-IP protocol worked in the IETF. Discussion and Focus -------------------- Peter Busschbach: Concern with 1 network element provides policy to another. In the past this did not work best always. There is a set of protocols already, not create a WG, have an info RFC instead. Wojciech: The scope so far is limited to existing use cases; we would need re- charting to bring additional use cases. There is no other protocol specification to convey such info from access node to BNG. This would be a good WG to specify something like this. Dave Allan: 2 points Resiliency (BNG cannot be a single point of failure), BNG owner and DSLAM owner may not be the same entity we need to handle those two. Wojciech: Agree with resiliency we need to handle this Alex Zinn: 2 schools of thought (everything can be done by central OSS or distributed). Any useful QoS, needs this info. IETF should specify this. We have running code that affects us. Jonathan Sadler: there are protocols out there that use SNMP for similar things, this should be explored, having charter to exclude such things seems funny. ?: Agree with Alex, we need to do this work in IETF. Everyone is hitting the same node and have L3 info. You need a lightweight protocol in there. It's about service IP enabled. We need to do this in IETF. In IETF we have many protocols used in various applications, If the app is important and specific enough we should look at how to best solve the problem and not piggy back on existing solution Mark Townsley: When I talk about running code, I don't mean GSMP. I talk about L2CP. The work has already been done however so we need to respect that and the barrier to change protocol is higher (can't ignore that). Ping Pan: We talk about a bunch of cheap boxes, we need something very simple. Defining right protocol is extremely important because of that. This needs to be IETF WG but we need to decide on protocol and not be boxed with GSMP. Roland Schott: This L2CP may be first step to achieve dynamic QoS. Peter Arberg: Support this to become WG. We may need to look back if GSMP is best, but if we can prove the GSMP is bad nobody is likely against this discussion Peter Busschbach: About QoS, it depends on what functionality you support in access. New gen does QoS in DSLAM you don't need BRAS. You don't need this in cable (does not use this model), PON devices are not cheap at all. I have no problem in standardizing protocol but let's not extend the scope to all technologies. I would be against. Alex Zinin: Its becoming harder to get things done. We need to focus, we need to solve relatively simple problem, let's not spend years trying to solve everything for everybody. This is not intent here. We want to be extensible, good engineering rule but don't solve everything ?: This protocol solves today's problem. We can move forward to other access node types. Making the protocol extensible is important. Thomas Haag: "The protocol being ATM oriented", we only have 1 use case for migration, so this is not correct statement. Nurit Sprecher: I support this item, we have something working, we can extend this for future req. Sandy Ng: Support for Alex statement. Call this work LXCP (for future extensions). Mark Townsley: Question: Is the proposed charter reasonable start? Outcome: Shows some (minority) opposition. We need a bit of work on that based on the response from the group. Mark Townsley: Question: How many think this is work IETF should do (assuming perfect charter)? Outcome: Significant support, and one against. Enough to talk about why the charter needs changes. Discussion on the charter modifications: --------------------------------------- Wojciech: Two suggestions so far: - need to spell out security in the charter - need to handle protocol resiliency Do we need any other changes? ?: Mission creep is my problem. Special consideration may be not applicable if this is to be general problem, or we handling only today's problem (with ATM- >Ethernet migration). We need to make decision. Wojciech: Thomas mentioned this before only 1 use case applies to the above comment, so what would you suggest is the way out to clarify that. ?: All use cases should handle future access technologies (like access network with DiffServ capabilities) 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. Dave Allan: Charter goes to a great lengths to describe easy part. Notion of handling non-exclusive owners of devices, this is hard problem we should describe. Mark Townsley: This comment brings the point why we need direct protocol. This should be in the charter John Kenny (?): What you describing is what I would like to see but the charter does not read like that. We need improvements to the charter to spell this out. Matthew Bocci: Summarized: - protocol design will not preclude other use cases - we need to handle trust model, non-exclusive ownership Suggests to take more detailed suggestions on the list Mark Townsley: - we should not even preclude other use of the protocol in other areas So with the mods to the charter (DSL but good engineers, trust model, name - send new name to the list). So assuming those changes are worked out in the list, do we want to form this working group? Andy Malis: Its premature to form a WG unless we have a new charter Mark Townsley: I wanted to see if we even should work on the charter. Mark Townsley: Is this something that the IETF should be working on? Significant majority agree. Based on the sense of the room (decisive support to form the WG), we should handle this on the list and should not need another BoF. Any objections to do that on the list? Single hand only for another BoF