======================================== ANCP WG, Wed March 24, 2010, 9:00-11:30am Anaheim, IETF 77 * agenda review * administrativia * milestones need to be updated. eg push back some of them to reflect actual progress: * ancp-proto * mib * mcast Chairs will update milestones and post to list. * Documents: see slide. Note: first ANCP RFC is out (Security Threat Analysis) ================================================= * Protocol for Access Node Control Mechanism in Broadband Networks Roberta. Maglione, http://tools.ietf.org/html/draft-ietf-ancp-protocol see slides. describe changes & open issues. 3 open issues: o remove mcast capabilities from ancp-protocol: Roberta Maglione: was discussed on the list. reached agreement with Thomas to remove codepoint 03 from ancp-proto and just have value reserved. Birgit (represents Thomas): should not be removed Roberta: Thomas agreed on list to mark code as reserved Tom Taylor: ancp-proto draft should not be required to specify all capabilities. This is to ensure extendability. Francois: agrees that ancp-proto need not have all capabilities and that mcast capabilities should be removed from ancp-proto. Woj: Agreement to remove 03 from ancp-proto , this will be confirmed on list o Proposal to remove sub-TLV Tom: there is only one complexity associated with that. It is described in ancp-mcast preso (padding issue) Chairs: we'll deal with that during mcast preso Woj: sub-TLVs also used in base Tom: calling them TLVs (instead of sub-TLV) does no harm. the only issue is padding Birgit: my understanding is there is no need to change ancp-proto Woj: it affects ancp-proto because it used to use sub-TLV Tom: well, other than text, it only affects the merging of the IANA registry Birgit: so it does not affect implementation (ie codepoints don't change) Tom: That's right. o Redundant extension block length Roberta: suggest to keep the redundancy to avoid changing the spec at that late stage Tom: I think this was brought up by Fortune Fortune: my comment was about redundant message type Roberta: this is a different topic. that was already clarified on the list. Woj: we have a new protocol version in ancp-proto, so we have the opportunity to clean it up. should we? Tom: there has been resistance to changes before, so there probably would be here too Tom: in ancp-mcast there are other occurrences of redundancy Woj: let's keep the cautious approach of not making change. If anyone disagrees, please comment on list Next Step:Ready for WG Last Call? Tom: I've noticed a few mistakes in codepoints (Hex vs decimal) Tom: I had made an editorial proposal Roberta: It is a major restructure, so create lots of work. Tom: I can write a Taylor version and people can review and choose Francois: it seems like a lot of editorial/review work just for editorial enhancements Tom: OK I withdraw the proposal Woj: we'll go for WG Last Call volunteers to review: 5 or 6 (Tom, Fortune, ???…) =========================================== Multicast Control Extensions for ANCP - Tom Taylor http://tools.ietf.org/html/draft-ietf-ancp-mc-extensions See slides. Describes changes Fragmentation was added Woj: given that ANCP rides on TCP do you still need ANCP fragmentation? Tom: what I am worried about is during transmit of a huge message (perhaps not so critical such as Stats reporting), all other ANCP messages would get held back Woj: concerned that it may be somewhat underspecified Woj: should we include in ancp-proto, as it could be applicable to other usage than just mcast? Tom: good idea. I can propose text for that Woj: Ok. Tom will propose text to move fragmentation into ancp-proto Alan Kavanaugh: what was rationale for removing R flag? Tom: part of the overall change that removes per-flow decision to do admission control or not Alan: is this discussed in ancp-proto? Tom: no discussed, in ancp-mcast Alan: then I am fine Roberta: Q for clarification. currently Command TLV is defined in ancp-proto, so do your change affect ancp-proto? Tom: ancp-proto just has the header and the TLVs are to be defined in other specs (such as ancp-mcast) Padding issue: Tom: this is really a ancp-proto issue. Recommendation is to do alignment as shown on slide. Woj: this would be a clarification in ancp-proto? Tom: Yes. I'll propose text. who has read: 6 people Kris Poscic: Question regarding whether a use case of interest can be supported with defined mechanisms use case is where AN does AC and does IGMP suppression. All I want to do is report bandwidth usage to NAS (eg so NAS adjusts Qos). I saw bandwidth allocation and query. but not quite the same thing. Can this use case be supported? Francois: can possibly be emulated with Bandwidth Delegation capability Chris: possibly but that would not be optimal Francois: I can agree probably agree with that. Let's have a discussion off-line. Next Steps Woj: close/address question from Kris. Could go to WG Last Call after this is closed and after ancp-proto goes to WG Last Call =========================================== Applicability of Access Node Control Mechanism to PON based Broadband Networks - Nabil Bitar http://tools.ietf.org/html/draft-bitar-wadhwa-ancp-pon-03.txt See slides: describe changes Woj: clarification, why did you add MAC address for the multicast group? Nabil Bitar: if you change address family you'd need that. (some explanations followed that the minute taker did not get) Alan Kanavan: ANCP between NAS and OLT all makes sense. Between OLT and ONT/ONU do you see just ANCP? Nabil: we see both OMCI and ANCP be used there. But we only talk here about ANCP as this is the ANCP WG. We are not saying OMCI will not be used. Birgit: will you take that work to BBF? Nabil: planning to take that to BBF Alan: support that work. very glad to see it happening. Wasn't the intention to fold into ancp-framework? Nabil: we had agreed to have it as standalone JongJin: BBF does not discuss VoD. we should look more into the differences between DSL and PON. Nabil: we have the intention to take it to BBF. the I-D actually tries to capture the delta bw DSL & PON. Please comment if something missing there. Alan: another difference in BBF is that they handle wholesale model. So that would have to be addressed to go to BBF. Wholesale not applicable here. What do the chairs recommend: fold wholesale into PON draft or not? Woj: we'd like to see a proposal for Wholesale. Probably it would be a separate I-D Nabil: so you are saying that Wholesale model applies both to DSL and PON. Woj: yes. =========================================== ANCP NAS MIB - M. Rohit (presented by Woj) draft-rohit-ancp-nas-mib-00.txt see slides. describe overview Francois: clarification. Does this aim at covering all of ancp-base, and not ancp-mcast Woj: yes and yes. Q: who has read? no one Woj: usual situation for MIB, but this is a WG item Matthew: will request on list to review and comment about making it WG draft =========================================== Network Anti-Attack for ANCP - B. Wu http://tools.ietf.org/id/draft-fan-ancp-network-anti-attack-00.txt See slides. provides overview. Proposes extension to ANCP to allow distributed protection enforcement on AN instead of NAS. eg NAS uses ANCP to tell AN to block an attacking flow. Presenter: BBF has a reqt doc for this Alan: it has been discussed but not quite agreed. Alan: I have a stack of questions. First, you targeting attack on BNG or behind Presenter: both Alan: SPs don't care if attack is to other hosts. for the BNG, SPs already have standard protection (eg ACL) Alan: if attack is detected, then what do you do. Block port? block MAC address? rate-limit? Presenter: action depends on the attack. generally block MAC works well Alan: what happens if you have enterprise network attached. Blocking MAC would block the whole enterprise. you don't want that. Woj: let me step back. First is there interest in the use case? Junjing: talking for BBF. There is interest in Security and in concept of using ANCP for that Roberta: BBF accepted this use case for ANCP but inquired about whether there was ANCP protocol machinery for that Matthew: would be useful to have liaison from BBF. Woj: also there seems to be some interest here eg Roberta you interested? Roberta : yes. Woj: please update draft based on input Alan: concepts has been presented couple of times in BBF, but it is not obvious that ANCP is the mechanism. If NAS is not attackable (thanks to usual protection) and AN is not addressable, why do need something from ANCP? Woj: does L2CP/ANCP use case doc actually discuss that? JungJing: yes, the L2CP/ANCP document discusses use of ANCP for security 10:31am. Meeting closes.