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 ANCP at ietf.org https://www.ietf.org/mailman/listinfo/ancp