Subject: [ANCP] IETF71 meeting minutes

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 25 Mar 2008 16:24:51 +0100

Hi Folks,

here are the ANCP IETF71 meeting minutes. Many thanks to minute taker.
Please let us know if you have observations or comments.

 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.

_______________________________________________
ANCP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ancp