Wednesday, July 30th, 2008 – 13:00 – 15:00 ----------------------------------------- CHAIRS: Wojciech Dec & Matthew Bocci SCRIBE: Richard Pruss WG Status and Update - Chairs ----------------------------- MB – Agenda bash, administrivia MB – Milestone update MB – ANCP Framework update MB – ANCP Protocol updated to v3, joint editor added Roberta Maglione Sanjay questioned if PON is in scope. Chairs/General Discussion on PON. Summary is that working group is open and welcoming on submissions on all access technologies, and the protocol is made to be extensible, but the immediate focus and priority is to get the DSL work finished. Multicast Use Cases and Requirements - Roberta Maglione (roberta.maglione@telecomitalia.it) http://tools.ietf.org/id/draft-maglione-ancp-mcast-01.txt --------------------------------------------------------- Tom Taylor – Delegation? For white list it makes sense. For grey list it does not save any messaging. The bandwidth delegation makes no sense. Franηois La Feucher– If all groups where white and all were black. If we have for one user, most of the channels are white and one is grey then it makes sense for all the groups to be handled on the access node. For accounting reasons. Tom Taylor – If the flow that is requested is in the pre-allocated amount then the flow is allowed. It has nothing to do with flow accounting. Francois LF – Parked the discussion for the end in the interest of time. Sanjay & Francois – Discussion on the complexity of the messaging to satisfy the requirements. No real conclusion. Sanjay’s concern is that it is either static or complex. Francois feels there is only two models and that makes t simple Francois LF – The proposals are changes to the framework document to support the multicast use cases. Peter A – Clarification on the Conditional Access and CAC diagram. Nabil – Traffic reduction is it permanent and is their any check on the use. Tom T – The bandwidth delegation assumes that the system is ready to reserve some managed bandwidth. Nabil – The problem is for best effort flows they are dynamic and you cannot grab and release traffic. This would be allot of singnalling if the reservations are dynamic. Tom T/Nabil/Francois – The ANCP Framework document should add a note clarifying that the "AN Bandwidth Delegation" model is not easily compatible with dynamic shaping of non-video traffic by the NAS. More generally it would be useful for the framework to capture other pros/ cons/limitations of the various Multicast Admission Control model. Stefan – Question "has flow groups been removed from the draft?" R – Removed for conditional access. Stefan – Flow groups do not exist anymore? R – Flow groups have been replaced by the bandwidth delegation mechanism. This really is an extension of flow groups. Stefan – Proposal to removed the words around flow groups and replaced with the delegated . Woj – How many have read, A good number. Stefan – Some concern on the complexity. Chairs – All future discussion is going to the mailing list. ANCP Multicast Extensions – Roberta Maglione (Roberta.maglione@telecomitalia.it) http://tools.ietf.org/html/draft-ancp-mc-extensions-00 ------------------------------------------------------ Next draft ANCP Multicast Extensions – Roberta Maglione Peter A – remove the TCP header from the draft because it limits this to TCP Woj – while digging into the implementation this has come up Peter A – By using this you limit ANCP to TCP . Woj – There is no explanation of why the Type is needed for TCP Peter – this is the encapsulation of GSMP over TCP Woj – Original intent of the header is not known; it serves no useful purpose. Peter – It is not part of the header. It is part of another header, which defines the encapsulation. It is in the TCP encapsulation definition. Chairs – Take it to the list. Mc draft continues. Tom T – In RTP we have a requirement to randomise the Transaction ID. Peter – Says it may start at any point. Tom T – Says it needs to be measured against the security requirements to see if it should be a must. Peter – Ask why we would want to use the TLV as a target and have its place fixed. Then if the value is fixed. It is really a fixed field, why use a TLV. Mark T – Agreed clarified. Tom T – Added that this was effectively an addition to the header. Woj – What this proposal tries to get to is a famility of TLV’s called target types. Currently only one identitier ACI. Peter – now if we have definied it to one, then we don't need the TLV Woj – How do address a group of ACIs or an ACL? Peter – The ACI definition cannot be changed unless the base protocol is changed. Peter – If you can’t fit this in the 64 bytes of the ACI Sanjay – This is givng you a flexible container for defining target types Peter – The ACI is the flexible container. Woj – We are to handle groups as targets and ACLs. Peter – This really does mean the basic protocol needs to change. Woj - Not quite so. Tom T – Access-Loop-Circit should be identifier type. Peter – This has to be learnt from the protocol. This went to the list R – resumed covering the draft and finished with no more questions. Chairs have a proposed path forward regarding multicast. Add two milestones. - Accept WG- I-D ANCP extensions for multicast control. November 2008 - ANCP extensions for mulitcast control Last Call March 2009 ANCP base spec will not wait for the multicast spec. Long discussion and the points stood but conversation will continue on the list. ANCP Framework and Requirements – Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/html/draft-ietf-ancp-framework-06 ------------------------------------------------------- Stefaan - Given the changes to the multicast proposals, the draft will probably need some more work before going to last call. Chairs - conclusion of disucssion re draft maglione and bandwidth delegation will need to be reflected in the next version. ANCP NAS and AN MIBs – Stefaan de Cnodder (stefaan.de_cnodder@alcatel-lucent.be) http://tools.ietf.org/id/draft-decnodder-ancp-mib-nas-01.txt http://tools.ietf.org/html/draft-ietf-ancp-mib-an-03 ----------------------------------------------------- Woj - Is it still the intent to bind the ANCP adjacency to a VLAN? If so, since ANCP is IP bound, why not use existing MIBs to bind the IP interface to a VLAN? Stefaan - yes, as per DSLF requirements. Woj - this still makes little sense. Peter - The vlan binding is to make sure ANCP packets for the defined IP interface can only be received on the defined vlan, as specified in the DSLF requirements ? Stefan - yes Woj - to be continued on the list. Stefan – struggling for reviewers of the MIb draft. Got three commits Tom, Sanjay and Peter. ANCP Protocol Draft – Sanjay Wadhwa (swadhwa@juniper.net) http://tools.ietf.org/html/draft-ietf-ancp-protocol-03 ------------------------------------------------------ Vitali – Discussion on unused fields from GSMP. Does this preclude their use in the future? Peter – This can be defined in future drafts. Vitali – why specify it must be 0. Tom T – Make it a MUST for 0 else it will be used for other things. Woj – we should try use the header fields for good uses. Non header fields that have no use for ANCP should be deprecated. Tom T - General comment is the PON document will teach how to change the base protocol for extensibility. ANCP Applicability to PON – Nabil Bitar (nabil.n.bitar@verizon.com) & Sanjay Wadhwa (swadhwa@juniper.net) http://tools.ietf.org/html/draft-bitar-wadhwa-ancp-pon-00.txt ------------------------------------------------------------- Peter A - No different between this and the current multicast proposal? Francois F - Hopefully it is the same. Sanjay - bandwidth in the OLT is the new point Toerless - Does the same benefits apply for using this as DSL? Toerless - Is this a multi-vendor space? Toerless - Is the framing fixed? Toerless - please give more on the requirements for the next meeting Woj – lets focus this on what is PON specific. It appears that a good deal of the multicast aspects in this draft are covered by the existing framework/draft-maglione proposals. request to the authors is to attempt to identify deltas for PON and have these presented. Gisel – PON is inherently multicast based. Francois F – Thanks the authors. Everything can be achieved except the flow in figure 8. Where the NAS has to query the OLT for admission for unicast. Nabil – This is a framework for us to be able to examin the applicability in PON. Matthew - continue on the list. Meeting ended out of time