ANCP WG Meeting, Philadelphia, March 11, 2008 Chairs: Matthew Bocci Wojciech Dec Minute Taker: Eric Voit ------------------------------------ Intro to Session --------------- Files referred to are at: http://tools.ietf.org/wg/ancp/ Woj Dec (WG Chair) went through his slide deck on WG effort status Woj: Vendor specific protocols classified under "possible future extensions" Biggest ANCP Gaps in relation to WT-147 and previously cited features are: - Topology Discovery (uplink) - Access Port Configuration - Multicast VLAN - Link Bundling (from Alias) Unless specific proposals are not received soon, these gaps will be assumed to have no interest and will not be addressed at this stage. ANCP Design team has been making progress on multicast control, but will miss the March 2008 date. New goal is to have the design team complete a proposal for the next meeting and before then field proposals at the earliest to the WG alias on focus topics. Tina (Huawei): How do we increase scope of group if necessary? Woj: Once we get current documents into last call, a WG discussion on charter extensions will be held. Stefaan (Alcatel): If we recharter for future extensions, do we need to redo the framework requirements? Matthew (WG Chair): if there is a new way of using ANCP, we will need a revision of course Mark T (AD): A new thing (use case) and how it is implemented can be overlaid on the existing context in the new documents. ANCP Vendor Specific Extensions - Peter Arberg ----------------------------------------- Peter Arberg Slides (Redback) on ANCP Vendor Specific Messaging draft "draft-arberg-ancp-vendorspecific" Suggests new capability type & vendor specific message extension Mark: confused by Capability Data mechanism: i.e., list of Enterprise numbers. Believes more ability to coordinate between vendor specific features is needed. Lack of structure to the vendor specific type (& its versioning) Peter: This is equivalent to how DHCP does things Mark: What happens when we standardize a vendor specific attribute. Wouldn't it be great to use a different organization of the information so that individual attributes Peter: Data internal to the Vendor Specific Data is opaque -- so this is not an issue. Mark: This is ok, I am back with what you are doing Woj: This looks like how RADIUS does things Mark: Problem with RADIUS is Vendors camped out in standardized address space. Peter: So be it, customers know the drawbacks of Vendor Specific Woj: Proposal reuses extensibility message code point blocks of GSMP. It appears a good idea to revisit this since we're not tied to the GSMP blocks. Peter: We could to set aside a block of Vendor Specific message types like DHCP does Mark: RADIUS was shut down prematurely Mark & Peter: Discussion why maybe we don't use a block of vendor specific messages Description of behavior at each end of the protocol is necessary. If a node doesn't understand the message is received, it is discarded. Need to put more details in the draft on this before we can go much farther Do we accept this as a WG document? Proposal: keep this discussion on the list as a separate draft. The draft requires modifications to clarify the points raised in the discussion. Eventually it could be collapsed into the main protocol document. ANCP Framework - Stefaan ------------------------ Main updates in v5 discussion slide deck presented. Proposal: take this to last call? Nabil B (Verizon): draft is heavy on DSL, but needs coverage for PON. How do we cover PON? Woj: we are chartered primarily for DSL, but also to have the protocol cover other types of access media (even if by extensions). PON is in that category. Nabil: Multicast admission control needs to be covered. How do we bring PON specific items? Woj: Admission control model proposed is what is in the document so far. There has been heated debate on the other options, deferred for later. But we need PON contributions. Sanjay: we don't need to recharter if we have other access types covered. Matthew: We can cover changes based on PON work now, if they aren't too heavy or controversial. Mark: We can change charter if necessary. But major work should be in a new draft. Tina: Slide 6 a way to provision bandwidth to the AN is not in the document. Should be in a future document. Nabil: Lets be timely on the PON extensions. Don't want to serialize documents. Matthew: Great, please bring a draft for this Peter: We shouldn't delay the current protocol draft. Another draft for multicast could follow. Francois: Framework document is stable, do we go for last call? A hum vote on whether the draft was ready for last call was brought to a hum vote by Woj. The hums were evenly divided between yes & no. Mark & Francois: What else do we need to close? Stefaan: for example, Flow group messages issue is an issue that is not closed. For the record: the decision is not to go to last call yet. AN & NAS MIB - Stefaan ---------------------- AN & NAS MIB discussion AN MIB discussed (draft-ancp-mib) in slides Woj: IP interface provisioning issue raised. Some folks want to tie the ANCP session to a specific Layer 2 interface in the MIB. This appears to be undesirable. The tie should be between ANCP and the if-index of the IP interface. Recursively this maps to the L2 interface. Peter: Need to be able to tie things (events) to a specific VLAN for security requirements. If it is an IP interface, we need specific customer tracking info. Woj: Framework draft & Protocol draft need to be consistent here Additional discussions will be on the alias Nobody in the room raised there hand on whether they read the MIB Not ready for last call since nobody has reviewed the document yet. We have one volunteer to review the MIB (Tom Taylor) NAS MIB discussed in slides Nobody except Woj admitted that they read the MIB. Woj: GSMP MIB is included by reference -- we need to break out specifically what we need and not force people to go to the other draft. Mark: Is this a big deal? Stefaan: Textual conventions only. Woj: We need to port whatever is in GSMP MIB that's used to the ANCP MIB doc. What that is will be taken to the list. ANCP and GSMP MIBs should be decoupled. Design Team Update - Sanjay Wadhwa, Roberta , Stefaan, Philippe. ---------------------------------- Design Team slide deck (technical context) reviewed Woj: ACI discussion. In ANCP we have DSLF notion of Circuit ID. This is carried by a generic string or binary attribute. Do we want to use other more specific formats? As long as we remove attribute length restriction of DSLF, and treat as opaque values we should be good. Dave (Nortel): GPON/FSAN issues with multicast raised at recent DSLF. Might want to check with SG15Q2 on issues like Multicast control (white/grey list) Sanjay: We should deal with PON specific issues as WG extensions as discussed earlier in the session. Woj: Message sequencing. We need semantics of whether what is carried in the message is to be handled in sequence or not. This includes implict sequencing if commands are carried in the same message, or explicit sequencing if related commands are carried in different messages. The WG needs to address these sematics in the spec. Francois: Is the protocol allowing things to bundled into a single message? Sanjay: Yes Woj: We need to be explicit on when the contents are meant to be sequenced or not. Matthew: Graceful restart needs to be factored in Peter: Graceful restart should be a separate document Sanjay: Are there field format issues which occur if we don't think about graceful restart early? Stefaan: Proceed without graceful restart? Discussion on how important this is occurred. This is important for Multicast to re-establish state. Sanjay: Graceful restart doesn't need to re-invent all. Flow reporting could be used for multicast. Peter: Graceful restart is a future WG item, not current draft Woj to Design Team: Based on what was presented here is there a way to divide the multicast control problem and complete separately? (e.g., control interactions)? Stefaan: We need framework to be sufficient to go to last call first. Woj: Many of the requirements are aligned with DSLF WT-147. Issues like GSMP maximum length have been spotted in the process because specific items like reporting were looked at. Sanjay: We know many items (Graceful restart?) which need to be covered. We are starting from a blank sheet. Shouldn't we try to cover these? Stefaan: biggest concern is that the framework has new functionality still being added. Matthew: If there is new functionality for the framework, it should be discussed on the mailing list Woj: The main primitives of the future protocol are known. There is sufficient material including proposal for flow reporting for the design team to move forward. Suggested way forward is to address the multicast control messaging first. Treat additional functionality as extensions. Stefaan: This has to be added to the Framework document Woj: Yes assuming it is DSL, or something not terribly impacting the framework for PON Peter: Comfortable with the framework document. Multicast intent is clear to most people. Lets finish the protocol for unicast, and do another protocol draft for multicast Francois: Agree with Stefaan that we should close down the framework with sufficient details prior to protocol specification. We should also look at prioritization of the protocol specs for the Design Team Mark: It's normal to have some churn between spec and framework. Framework document is a tool. Protocol draft is the objective. It is ok to find something on the mailing list which over-rides the Framework document when developing the protocol. Woj repeats Peter's proposal: Should we conclude the current protocol draft at the base capability level (i.e., support what is currently specified and deployed for Unicast)? Mark: this would mean pulling out the multicast part from the unicast proposal. If this matches deployment, this could be a good thing. We need to do the analysis that we don't have to break back open the Unicast document. Matthew: We need to analyze the open issues (accounting, flow-groups, graceful restart) to definitively answer the question of whether we can safely split the document Proposal from Mark/Woj: By next IETF the design team should socialize its proposal on the WG alias. If the team can't cover multicast, then it should fall out to another document Woj: Items like Flow groups is something which based on complexity/priority could fall to a subsequent draft Mark: By Dublin, a final decision on v1 of the protocol needs to be made (i.e., what is in it). Suggests Peter as the person who makes a first cut at what would go into a fall back (divided) document if multicast is pulled out. Woj: for the record, it is up the WG chairs to build the work schedule of the design team for this to occur. Regular calls. Once team consensus forms, result shared with WG. Mark: Would prefer things to be in one document. But would accept multiple based on expediency. Francois: Also possible to have a base multicast capability set included in a divided document. Meeting Ends.