ANCP Tuesday Mar 24/09 Matthew Bocci and Wojciech Dec chairing Agenda and status ================= Matthew Agenda accepted. Charter: adding PON. Comments? comment: Noted that ONT could actually be located on customer premises. Comment: Architectural problem with ONU. Reflects on framework -- latter should be aligned with charter. Be specific in charter. Comment: difference in technology may mean difference in framework. Optical and electrical domains quite different. Other issues? -- original commenter: just with details AD Ralph Droms: how much additional work? Have draft already, can write as delta to original work. This was acceptable to Ralph. Milestone added. Re: MIB. No reviewers, no advancement. ANCP Protocol spec ------------------ Woj. (1) Partition-id ------------ Sanjay: concerned that removing the partition-id reduces extensibility. Thomas Haag: need multiple partition-ids because one might need to distinguish between BRASs when expanding the network. Woj: send e-mail. Thomas: already did. Makes for operational problems if partition-id not available. No one felt strongly -- will keep "as is". (2) Graceful restart/redundant controller ------------------------------------- Subject raised, some activity. Mark as gap in base protocol or cover in extension document? Sanjay: does need to be considered because of service impact. Tom: adjacency aspect could be in base, state sharing between redundant controllers a separate topic. Sanjay generally agrees. Chairs agree. (3) Adjacency keep-alives --------------------- Problem is mismatched timers between peers. Sanjay sees no issue -- provision that prevents problems already there. Should keepalive timer setting be negotiable? Woj sees no need, but concerned that timer field doesn't go high enough for a NAS controlling many ANs. Nabil Bitar: could have scaling factor. Sanjay: could have need at times for adaptability. Should perhaps provide means for receiver to back sender off. Thomas Haag: then have to add elements to protocol. Have to look at implications before making decision. Sanjay: doesn't have to be new capability. Continue discussion on list. (4) Multicast reports ----------------- Proposal made on list for three types of NAS-triggered report: per Access Port, per multicast flow, and globally per Access Node. Sanjay notes previous agreement in principle. Will reissue proposal to list. (5) Vendor Specific Option ---------------------- Waiting for new version -- should be available in a couple of days. Tom Taylor also raised issue of technology dependence of TLV definitions -- sent message to list. TLVs are intended to be reusable. Tom to get together with editorial team to agree on wording that conveys intentions. Framework, security threats going to IESG -- need some edits. ANCP for Source Address Validation ================================== http://www.ietf.org/internet-drafts/draft-kaippallimalil-ancp-sav-00.txt Frank Xia (xiayangsong@huawei.com) Source address validation can be enforced by both switches and routers. Currently switch builds up validation table through traffic snooping and control plane. Prtoposal is that router builds up validation states and passes them to AN. Could this be a WG work item? Alan Kavanaugh: solution not right -- SAVI doesn't go on NAS. Beyond that, scenario has some applicability. Sympathizes with intent. Need to review use cases, then craft a solution. Re: SAVI vs. NAS: deployments currently establish SAVI on switch Issue of link-local addresses. First-come-first-served validation policy a quick-and-dirty solution, though it can deny the rightful owner service if the interloper comes first. Woj: does draft meet a SAVI requirement SAVI does not? Yes. Alan: not hostile to work. But need good use cases. He feels we do not have enough info to make a decision. SAVI fcfs only covers DSLAM. Do need BRAS capability too. But need use cases showing what SAVI can and cannot do. Sanjay: do Layer 2 switches also need these bindings? Problem that NAS would need to know topology of the aggregation network. Woj: bring back the use cases showing what SAVI cannot cover. If such use cases identified, can view as ANCP work item. Thomas: has to fit in our present framework, otherwise useless -- have an addressing scheme already defined. ANCP Applicability to PON ========================= http://tools.ietf.org/html/draft-bitar-wadhwa-ancp-pon-01 Sanjay Wadhwa (swadhwa@juniper.net) Differences from DSL. How many have read latest version? Alan: basically, summarizing, don't base on OMCI, with OMCI extension a fallback possibility. Really prefer ANCP with proxying at OLT. Delegation applicable here? Sanjay: could also be done here. Thomas: can this also be extended to ONU? Yes. Francois: take decision on adoption of this draft as baseline text to list. Chairs agree. Multicast Extensions ==================== http://tools.ietf.org/html/draft-lefaucheur-ancp-mc-extensions-01.txt Francois Le Faucheur (flefauch@cisco.com) Review of changes from -00 to -01. Review of bandwidth delegation. Sanjay: this does not take care of over-subscription in the aggregation segment. Disposition proposal to list -- out of time. Proposal is to merge into protocol document. Use cases accepted in past. This provides solution. Have separate base and multicast drafts or merge? To the list. Understood that a separate multicast draft would also pick up multicast-related material in current base draft.