ANCP WG IETF 69 meeting minutes TUESDAY, July 24th, 2007: 15:20 - 17:20 ------------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci *** 5 mins - Administrivia : Chairs We're clearly past the shown milestones. Agreed for pushing milestones out by about 6 months for all outstanding items. Mar 2007 becomes Oct 2007. Security requirements doc ready for last call. Sanjay Wadhwa - Still discussion on multicast use case. Protocol depends on Framework and Requirements. ACTION #1 Chairs: Update milestones *** 5 mins - Liaisons : Chairs Received a liaison from DSLF inviting us to refer to WT-147. Includes an invitation to DSLF in Nashville. Wojciech Dec : How many people have read the WT-147 liaison. None. Hassnaa Moustafa : Don't see the coherency between the WT-147 use cases and the wg defined use cases. Is the ANCP protocol suitable for the use-cases identified in WT-147. Decision should be made by ANCP WG. Wojciech Dec : Multicast discussions have been going on for some time in DSL Forum and are still ongoing. WT147 however contains more multicast use-case content than the WG's ANCP Framework doc. The ANCP framework doc derives from the WT-147 framework, so all uses would appear to be covered. Feedback on this from additional WT-147 reviewers would be welcome. ACTION #2 ANCP working group: Review WT-147 and determine deltas (if any). Mark Townsley - Since this is a reply from an earlier WG liaison, we might just send a courtesy reply. Wojciech - It does seem like the DSL Forum?s reply was a response to our previous liaison. Mark Townsley - Ping-pong courtesy replies perhaps not needed then, but we could reply saying "Thank you for the liaison. We've asked the WG to review the doc, etc". ACTION #3 Chairs; draft a liaison to DSLF. *** 15 mins - ANCP Framework / Requirements - Dong Sun (dongsun@alcatel-lucent.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework- 02.txt Presented on behalf of Sven. Main updates: Multicast section as per consensus from last meeting. Made network element requirement informative Other edits as per comments. Multicast - Resource efficient multicast increasing in importance. Requires local replication in access node. In order to maintain backward compatibility, AN and NAS to behave like black box. Implementation of multicast behavior between AN and NAS will not be specified. How to proceed? Can we consider draft complete? Framework is not considered complete (from audience). Wojciech Dec : How many people have read the latest doc? Approx 5 people raise hands. Dong asks for comments about doc. Francois Le Faucheur : Multicast section requirements are woefully incomplete. Can't write a protocol from this level of detail. Either we add more detailed multicast requirements or we define multicast out of the scope of present Framework document. Believe that we need to add same level of detail as for other use-cases. Dong : Wasn't there consensus at the last meeting to keep protocol details out of the framework? Wojciech Dec: Last meeting had consensus on the scope, detailed protocol work is for the protocol spec. Mark : Framework doc is a tool to let the WG come to consensus. If it's a tough issue, maybe it needs even more details than non contentious items. Ultimate output of IETF is a protocol not a framework. Fact that there is a lot of discussion on multicast indicates that more detail needs to be spelled out. Matthew Bocci: There must be at least an equivalent level of detail in the multicast requirements as for other use cases. Sanjay Wadhwa: Doesn't see the detailed message flows in the framework doc. Mark: didn't hear that suggested Woj (expressing opinion): Detailed flows not in framework, but message primitives yes. Francois: Other use-cases have 2-3 main things in framework. 1. Description of use-case 2. description of message exchange. 3 Requirements for protocol. Those three also needs to be in framework document for multicast. The exact message flow should not go into framework but instead in protocol draft. Woj: Seems like we have consensus. Any comments? Jeremy Brayley : Depends how much the primitives define the protocol. Eg one might solve things differently than by having message from Access-Node to NAS. Way use-cases written so far is it describes why a message is to be sent. Woj: Does the framework and requirements doc need to contain enough detail to write the protocol for the multicast use-case. Jeremy : Yes. Separate protocol document describes the flows. Maybe even the primitives. Woj: Key point is the primitives. From what we've heard so far, primitives are to be in the framework doc. Mark : There is an out clause in the document already. It says that the primitives are examples and don't necessarily define the actual messages to be used by the protocol. If you want to do things differently, you can. *** 15 mins - ANCP Security Threats and Requirements - Hassnaa Moustafa (hassnaa.moustafa@orange-ftgroup.com) http://www.ietf.org/internet-drafts/draft-ietf-ancp-security- threats-01.txt Security and authentication/auth per subscriber is out of scope. Added a block to system diagram for aggregation network. Also added "regional network". Considers attacks against multicast use case. Vulnerability analysis covers cases when Access-node does IGMP snooping or proxying, or relays message in transactional ANCP. Multicast scenario attacks in general can be considered similar to attacks in Use-case 1 and 2. Major change: On-path attacks, and active attacks. DoS causing certain subs inability to access certain mcast streams or reduced bandwidth. Man-in the middle - forging messages between a NAS and AN. Message modification i.e. reducing bandwidth Message replay. Asking for comments. Want to move towards last call. Woj: How many people read the draft? 2 hands raised. Woj: Definitely not enough. Mark: Document goes no where without reviewers. Need 5 volunteers to read and comment. Matthew: Call for volunteers. Volunteers: Curtis Sherbo Phillipe Niger Michael Busser Francios LeFaucher Raymond Zhang Mark: Can issue last-call and do review during last call. Woj: Doc covers multicast. Do you see any changes arising out of this from the multicast discussion currently on-going? Hassnaa: No. Doc considers multicast from a general perspective and so all scenarios are addressed. Matthew Bocci: We'll issue a Last-call mail. ACTION #4: Chairs to issue last call for security draft. *** 15 mins - ANCP Protocol Draft - Sanjay Wadhwa (swadhwa@juniper.net) http://www.ietf.org/internet-drafts/draft-ietf-ancp-protocol- 01.txt Not a lot of protocol changes. Most of the changes were in the form of adding more clarity to help implementers. Clarified that draft uses GSMPv3 over TCP. Protocol implementer just needs to look at RFC 3292 and this draft. New text for Section 5. Explicitly specified base GSMPv3 and ANCP message format. Draft uses just a small subset of RFC 3292 messages - explicitly listed in the ANCP spec. Additional messages also covered (Bulking of messages). Multicast use case will likely result in substantial protocol development. Graceful restart and DSL bonding will also require more work. To discuss on mailing list. Woj: Sanjay, will you take the action to initiate the discussions on these two items? Sanjay: yes ACTION #5 Sanjay: Initiate WG mailer discussion on graceful restart and line bonding. Because graceful restart draft has expired, Sanjay will take action to discuss graceful restart on mailing list. Woj: How many people read the draft. 3 hands raised. Matthew: Comment that we always said draft was for DSL, but it should be useful for other technologies. Would like to see a more generic name for attributes (i.e. not DSL line attributes under DSL Tech type). Sanjay: Seems like some attributes can indeed be more generic. Needs more thought. Woj: Definitely a discussion needed. Draft seems to associate functionality with tech type attribute. Sanjay: Sharing of attributes can become cumbersome. Change affects all tech types. Matthew will send comment on list. ACTION #6: Matthew - to send out mail to WG with observations about protocol draft's use for other technologies. Samita (from Azaire) : What access technologies are to be covered? Answer was PON, wireless, etc. Should be extensible beyond DSL. However we will focus on DSL as a deliverable right now. Woj: Charter of the WG makes DSL the primary focus, but intent is to be extensible to others. *** 30 mins - ANCP Multicast Handling - Roberta Maglione ( roberta.maglione@telecomitalia.it) http://www.ietf.org/internet-drafts/draft-maglione-ancp-mcast -00.txt Objectives: Behave like black box, when replication done by AN. Enable NAS to provide info to AN to allow it to make local decisions when possible or query the NAS in all other cases. 4 use cases: Multicast Conditional Access Multicast Admission Control Multicast accounting Multicast termination *Multicast Conditional Access Purpose: To provide network level access control for multicast traffic. Two approaches can be taken. The approaches are also specified by MBONED in multi-aaa framework doc. (policy push and policy pull) 3 scenarios: 1) Decision taken by AN NAS uses ANCP to provision Access-node Defines white, black and neither. White list is the list for which access-node can make decision without querying NAS. Join requests for Black list entries are to be denied. All other requests result in a query to NAS. 2) Decision taken by NAS (or by AAA server) This is a pull model. Desirable to have decision done by NAS or AAA server in more complex policy decisions; video conferencing, multi-party access-control, CAC. Access node is to query to the NAS before allowing a join. 3) Coarse-grained decision by NAS and fine-grained by AN Defines multicast flow groups. Multicast flow-group entries share the same conditional access policy. This will reduce the number of queries to the NAS. *Multicast admission control Objective: Access level admission control for multicast. Same 3 scenarios as Conditional Access case 1) Admission control by AN AN pre-provisioned with AC information 2) Admission control by NAS For Triple Play we want multicast CAC to be synchronized with unicast CAC. 3) Coarse-grained by NAS and fine-grained by AN Flow-Group means same bandwidth. AN performs decisions for flows within same Flow-Group. NAS makes admission control decision for whole Flow-Group. *Multicast accounting Objective: To have capability for per line time or volume multicast accounting. * Multicast termination Objective: Provide capability to dynamically stop multicast replication NAS must be able to revoke authorization granted. AN must stop multicast flow. Roberta then explained the message flows for each case. Roberta : Proposal for WG: Incorporate use-cases and requirements in ANCP framework draft. Message flows in ANCP protocol draft. Wojciech : Consensus on list is that use cases are plausible. So are using white and black lists and provisioning. Discussion on list is whether mechanisms beyond white/black are needed (i.e. query NAS). 1st question: Resolve framework & requirements document issue, discussed earlier. Do we want the doc to contain multicast use-case requirements? Consensus is yes. 2nd question: Would we agree about the optional mechanisms to address the need for flexibility and/or specific use-cases? Add the primitives to the requirements doc? Raymond Zhang : Could white list be considered as a case of black list? Roberta : No. Need to query NAS. Need a third case. Woj: Issue often discussed is predictability. Pre-provisioned lists handle well events that are predictable. Cases where predictability is not possible or feasible, needs reaction when request is issued. Dong : Still some debates on list. Do we need to query the NAS? For TV performance requirement needs to be met. Video conferencing may require application level registration, and authentication. Is IGMP the only trigger or should there be app layer signaling as the trigger? Prefer to use single (IGMP?) mechanism for all services. The solution appears to be complicating not simplifying. Francois : Not going to be 100% agreement. Everybody agree on white/black list. A bunch of people want more. Only talking about an optional mechanism to do more. Roberta and I think we need that flexibility. Other people on the list stated so. Toerless, Sanjay and Curtis want it too. We need flexibility. Also, MBONED defines AAA multicast; explicitly describe push & pull model for multicast. Obviously there is more than enough justification. Mike Mcbride - Agrees. From PIM WG. Read the draft. It seems reasonable with what we are used to in other IETF mcast groups. Dynamic flexibility appears to be necessary, and good to have it as option. Supports proposal. Hiroshi Ohta : From MBONED. MBONED discussing AAA issues in general sense, not focusing on access method. Depending on application, but does definitely see a case for multicast AAA. It is reasonable for framework & requirement to address multicast handling issues. Yes to first question. Agrees that flexible option is useful. Yes to second question. Jeremy : Agree with the NAS making the decision, but why does it require the query/pull mechanism? Why can't all IGMP messages go up to NAS (the transparent snooping case)? If transparent snooping is used, won't there be two messages going to the NAS (query and IGMP). Roberta : There is a common assumption that the AN is acting as an IGMP proxy not transparent snooping. Jeremy : If so, we need to explicitly note that either 1) transparent snooping is not used 2) it won't work or that 3) we don't want to rely on IGMP between the AN. Mark : In one case IGMP comes up. ANCP is involved to send to the NAS. In the other case, IGMP is sent all the way to the NAS. Seem to be very similar. This kind of detail can be for later. Francois : Perhaps terminology is a problem. Key point: Is the decision entirely taken by the AN or not? We're saying that there is a case when the NAS decides. Doesn?t matter too much for the current discussion whether the NAS decides following ANCP or IGMP. Jeremy : But ANCP requires a specific message. Francois : correct. But bigger question is: Do we agree that NAS makes the decision? Sanjay: Agree. Woj: We can have the debate about IGMP trigger or not, but we don't have control over existing IGMP implementations and optimizations. Within ANCP we can introduce own optimizations. Key take away from discussion: There is agreement that ANCP needs to support scenarios where NAS takes the multicast decision. Sanjay: For CAC, the mainstream scenario is for NAS to take decision. Does it make sense to have a grey list? Francois: Initial proposal actual included Grey list. Then it was removed because wed hoped to achieve same thing with masks & ranges. But can now see a case where grey list would help. We need to think more and perhaps to add grey lists. Dong : Question on slide 8. Seems to see performance problems with query. Woj: Two proposals on the table. One says "white&black", other says "white&black + query". Are you saying that we shouldn't discuss the latter? Dong: Need to understand how mechanism works. Woj: Let's take a step back. Do you agree on the CAC use-case? Some of the valid deployment options are to have CAC done by AN, some by NAS. Within the scope of ANCP WG, we deal with what happens between NAS and AN. The use-case here is about CAC done by NAS. Query makes this happen. Dong: Still not clear how query can be used to support use-case. Performance concerns. Curtis Sherbo: Draft proposes white/black lists ? these can be used where performance matters. In other cases when choosing to use conditional access, SPs would knowingly choose the mechanism and be aware of its performance. Dong: Don't see the mechanism in the draft support the scenario you mention. Sanjay: In practical cases, grouping of flows do not result in query per zap. Specific case can be thought of as resulting in query per zap. Mark : Centralized and distributed databases scale in different ways. This is a classic problem. Depends on which you want to optimize. Each has tradeoffs. Centralized slower to access, easier to manage. The mechanism offers operator the choice. Ulf Borinad (Operax) : Clarification question on managing lists. If something doesn?t exist on white/black, it should result in a query. Is the list then updated? Francois: That's a possibility allowed by the proposal. Woj : We have specific proposal in this draft. Mark how do you propose handling it? Mark : As AD I see far more support for flexibility for query mechanism than not in this room. So I don't see any justification to not support that flexibility. Needs to be confirmed on mailing list. Woj: Take flexibility as key thing. Lot of support, individual opposition. ACTION #7: Chairs - confirm multicast direction on list. *** 15 mins - Extension of ANCP for Satellite and Terrestrial Wireless Modem Networks - Lloyd Wood (lwood@cisco.com) http://www.ietf.org/internet-drafts/draft-floreani-ancp- wireless-00 Been dealing with problem with which ANCP can help Smart adaptive modems need to update routers with current satellite modem speed. Similar to DSL. Looking at adding wireless class extension to ANCP. Point-multipoint and point-point cases. Eventually moving to point to point. Use ethernet between modem and router because of cost. Serial would be best option, but not going to happen. ANCP works across TCP. Given that satellite delay is an issue, doing ANCP local looks like the answer. Multicast CAC use-case also of interest to satellite. Interested in comments and whether this is something for ANCP. Francois : Seems to match what ANCP does. But isn't it overkill to use GSMP based protocol just to sync line rate? Lloyd : This may be overkill, but we have working code and it will work. Just software. However a lot of framework is not used. But in deployment scenarios the fuller framework may get used to cover other access types. Sanjay: ANCP between NAS and modem - ok. But ANCP between CPE and modem raises questions. Is CPE trusted device? ANCP is typically contained to trusted domain Discussion on managed CPE options. Are CPE and NAS operated by different companies. Lloyd: Depends on provider. 50/50 case in satellite industry; some provide router+modem, others only modem. Lloyd: Modems turning to L3 device, part of the problem. Is ANCP suitable. Woj: Do you have specific issues with the protocol spec for satellite use? Lloyd: ANCP is an overkill, but it has all we need. Fine for our use. More discussion on CPE side aspect of modem and router. In DSL case there appears to be the same problem on the home side, between router and modem. Problem seems to be applicable to DSL too. Woj: So far we focused on the service provider side, not the home. Home is an un-explored area for us. Wojciech : Broader question is how do we ensure extensibility of ANCP to other technologies? Current text protocol spec to be very DSL tech type centric. Need to decouple function from tech type so that it can be re-used by other tech types. Also need to define extensibility path for TLVs. Sanjay: For each tech type do we need enumerate the TLVs? Woj: No. Usual search for blue sheets...