Please find attached the draft minutes from Vancouver.
Please let me know if you have any comments by Friday 4th Jan.
Many thanks to Curtis for taking the notes.
Regards,
Matthew
Thursday, December 6th, 2007 – 13:00 – 15:00
-----------------------------------
CHAIRS: Wojciech Dec (Absent) & Matthew Bocci
SCRIBE: Curtis Sherbo
WG Status and Update – Chairs
-------------------------------------
Milestones:
Security threats review, only 4 of 5 responses received
Sanjay Wadhwa: proposed delaying MIB last call since protocol work is ongoing, Matthew agreed
Protocol draft:
Chairs have asked a small design team to produce text for protocol extensions and/or modification of requirements of multicast control
Ensure protocol meets the requirements/framework
Implement comments for the list
Target of march 08
Francois Le Faucheur: Agree with proposal, would like a couple of iterations of progress for comment. Agreed. Design team will produce iterations for review on WG list.
Design team: Roberta Maglione, Stefaan De Cnodder, Sanjay Wadhwa, Philippe Champagne
ANCP gaps from WT 147 liaison from DSLF:
Topology Discovery
-Access node uplink
Access port configuration
-Configuration of parameters beyond the dsl modem traint rate, eg. acls, vlan assignment, .1p mapping parameters, policer
-Opening and closing of access loop
Multicast
-Assignment of multicast vlan
-Periodic membership reporting
Other gaps from wg alias
Link bundling (Bonding)
NAS MIB:
Francois Le Faucher: Topology discovery link from the NAS, thinks it is important
Stefaan de Cnodder: NAS MIB is planned, but further out
Sanjay Wadhwa: Assignment of mcast vlan is important for wholesale
Mark Townsley: 147 is a set of requirements from DSLF for L2CP. What is the opinion of the industry how to solve these problems? No answer.
Stefaan de Cnodder: Link bundling question, link bonding on dsl line, added to protocol, but not yet in framework
Mark Townsley: what do we do about gaps? Need these items formulated a bit better to understand them.
Matthew noted what has been supported by attendees
Mark Townsley: We should track these gaps, and not proceed until they are addressed.
Action: take to list
Matthew; additionally, some extensibility guidelines should also be laid down
e.g. vendor specific code space
Matthew, suggest design team tackle these and come up with a proposal
Peter Arberg, vendor specific attribute capability, draft on the list after the meeting
ANCP Framework and Requirements – Stefaan de Cnodder (stefaan.de_cnodder at alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
--------------------------------------------------------
History: 04 is the latest version
Version 3: multicast use case updated, bonding, notify NAS of access loop configuration change due to EMS.
04 changes: small terminology consistency change ("net data rate")
New sections:
Section 3 use case multicast
Section 4 requirements, multicast security
Definitions update in section 1.2
Reference architecture two new messages, admission requests and admission response
Use case conditional acceess
Admission control
Accounting
Termination
Sanjay Wadhwa: Third option of admission control discussed on list, IGMP from routed gateway to NAS direct, NAS decide and asynchronous message to access node. Agreed should be included as third option
Sanjay Wadhwa: Same comment for accounting
Next steps - update based on comments
Francois le Faucher: The max number of entries in list was put in doc prematurely, Sven sent to list, one comment, received. Should go to list for more support, minimum threshold,
Matthew doesn't want it removed, then discussed, want it discussed first, then decide what to do,
Matthew will raise on list again.
Francois: Criteria to keep it in need to be more than "no one objects". If no one cares, then it should be off.
Multicast Issues - Roberta Maglione (roberta.maglione at telecomitalia.it)
http://tools.ietf.org/html/draft-ietf-ancp-framework-04
http://tools.ietf.org/wg/ancp/draft-maglione-ancp-mcast-00.txt
--------------------------------------------------------------
Grey list and default behaviour
Spontaneous admission response
Grey list to reduce NAS load according to WG discussion in Chicago
A grey list identifies the multicast flows for which the access node can join before queries for further authorization
What does wg prefer for default behaviour for a join that does not match any list: deny, allow ?
Operator can override with wildcard
General case is where ANCP not used to convey join /leave
Detailed changes title 3.4.4
Use case in 3.4.4
Add modifications related requirement in section 4.2
Accounting
Enhance multicast accounting section
NAS preference to time and /or volume accounting is needed
For mcast flows controlled by NAS (GreyList) at time of message sent to an
For mcast flows controlled by access node white list can convey NAS during white list provision phase
information report message used by an to communicate accounting information to the NAS
AN can consolidate multiple sets of accounting information inside a single ancp message to reduce the number of information report messages sent from the an to the NAS
Detailed changed modify use case 3.4.3
add/modify requirements
multicast reporting
add capability for NAS to query the an to obtain instantaneous report status relate to multicast flows currently replicated by the an
such a reporting function could be useful for troubleshooting and monitoring purposes
three different types of report-query
port report query
multicast flow report query
an global report query
detail replace 3.4.3 title
add use case 3.4.3
requirement s4.2, 4.7.6 and 4.8.6
Stefaan de Cnodder, comment on default behavior, missing option accept on best effort basis
Francois le Faucher: discussion started on list, more discussion to occur, assume that particular mcast, to that particular port ? to Stefaan
Stefaan de Cnodder, don't do any BW admission control, queue in switch, just do best effort
Francois le Faucher: question will you always send high priority before the best effort?
Stefaan: depends on the Marking
Francois le Faucher, who is remarking
Toerless: There is a difference between allow and best effort
Stefaan de Cnodder: allowed if best effort, if there is enough BW, check if sub has subscription,
Francois : response to an for access control, based on bw, suspect that is not what Sven meant
Stefaan, just want third option covered
Peter color names confusing, support Stefaans proposal to be one list, change names to permit deny query
Sanjay Wadhwa, nas send only whitelist, assume all the rest, traverse lists
Peter, if keep as three lists, need priority of lists, should be one list with no priority,
Toerless, means ordered list, does this mean more than three lists
Peter, not same thing, should be like an access list in a router, ordered list, first match behaviour
Toerless, if separate lists, using priority is same behaviour, how much complexity should be allowed, should be three lists, for interop without differing definitions across vendors,
Peter, agree that if lists, need priority
Sanjay Wadhwa, logical single list, an could do three best match lookups, another default action should be query nas
Francois le faucher, comment on, keep definition as is in requirement doc, it is understood, protocol should define it, agreement and resolution in protocol document,
wrt to default behaviour, default default, needs decision, directed towards Sanjay Wadhwa, query default. Agreement; there needs to be a default-default (when nothing is configured) and a configurable default. That latter can be allow/deny/query.
Stefaan, comment on reporting, port report query, support, maybe not agree on all attributes, concern how many (timestamps) need to be tracked by an global reporting, too much information, might not fit in gsmp
Toerless, how does report relate to graceful restart
Stefaan, question for Toerless, does it mean the acls, align state of an with nas, not sure if this is good idea, needs to be examined in graceful restart
Francois le Faucher, question, clear cases where nas has time based info, volume info, cases both, therefore maybe nas tell an do volume based acct or time based, question is that useful, or is easier for an to always maintain and report both?
Stefaan, understand an sends start and stop to nas,
Francois le Faucher, an give all info when queried
Stefaan, an not counting packets, nas counts bytes, an tells nas to start counting
Toerless, packet counting, no sync between forwarding and signalling, an already replicating before nas receives message, question of accuracy
Stefaan, also unicast, sends sync rate, line down, packets lost, accounting already done on NAS, no different
Toerless, are you saying it won't work well, but compatible with unicast
Sanjay Wadhwa NAS might not be in data path
Toerless, does dslf require AN to count packets, if an does, then why not mcast
Stefaan, not sure, but believes motivation for ancp was to do it in a centralized way
Francois le Faucher, current text does not reflect this behaviour; assumption is that AN can count packets.
Matthew, discusion needed on list
ANCP Access Node MIB – Stefaan de Cnodder (stefaan.de_cnodder at alcatel-lucent.be)
http://tools.ietf.org/html/draft-ietf-ancp-mib-an-01
--------------------------------------------------------
01 submitted in November
00 changes:
partitioning, added a scalar to configure wherher partitions are used or not
interface config table
notifications, up and down notifications can be enabled/disabled per session
modifiying attributes
01 session index
ip address
port number configuration possible
ANCP Security Threats – Hassnaa Moustafa (hassnaa.moustafa at orange-ftgroup.com)
http://tools.ietf.org/html/draft-ietf-ancp-security-threats-03
-----------------------------------------------------------------
WG LC in October
Version 3 as a result
Changes, editorial, acknowledgment, admin domain clarification, potential, attacks against ancp clarifing text, multicast use-case added, security requirements updated
Matthew, last meeting, discussed waiting for framework to complete before sending security to iesg, send both together
Hasanna, to keep alive, submit a new version,
Matthew, any more comments can be considered part of previous last call
Mark Townsley: when do framework last call, redo last call on security
ANCP Protocol Draft – Sanjay Wadhwa (swadhwa at juniper.net)
http://tools.ietf.org/html/draft-ietf-ancp-protocol-01
Discuss protocol draft updates and ANCP graceful restart.
----------------------------------------------------------
consistency with framework
new section 2.1 on terminology
net data rate used
new multipair bonding text
text for topology discovery extensions 5.4.2
clarified message format in line configuration extension, section 5.4.3
concern over tlv changes, diverges from tr-101 and rfc 4679 in TLV#. Common notion is for BRAS to pass TLV transparently into Radius. Changes held back. Doesn't see issue as colliding values have been changed previously.
access loop remote id and sub tlv access loop encapsulation
suggest not deprecate these tlvs, keep them alive
Peter, why did Woj want this deprecated, agrees that these shouldn't be deprecated.
Sanjay, reason was to depreciate to avoid overlap, but ROI is small in this case.
graceful restart draft updated, support for multicast use cased agreed upon by the WG.
Matthew, should graceful restart be a separate draft going forward, Sanjay agreed
Matthew, graceful restart not on charter, need to add to milestones
_______________________________________________ ANCP mailing list ANCP at ietf.org https://www1.ietf.org/mailman/listinfo/ancp