Thursday, November 20th, 2008 - 13:00 - 15:00 --------------------------------------------- CHAIRS: Matthew Bocci & Wojceich Dec SCRIBE: David Sinicrope WG Status and Update - Chairs (Matthew Bocci & Wojceich Dec) Milestones: Asked people to look at the MIB. Need additional review and comment on the MIB. Please provide comments on the list. Chairs will check in with folks requested to review the MIB to see how far progressed. Once another revision of the MIB decide on last call. Framework may be ready for last call. Discuss on the list. Chairs will update the milestones. ANCP Framework and Requirements - Stefaan de Cnodder / Sven Ooghe (Alcatel-Lucent). Slides presented by Matthew Bocci http://tools.ietf.org/html/draft-ietf-ancp-framework-07 Given there are so few folks here post comments to the list. (approx 12-15 people in room, 2-4 on Jabber) See slides. Update to different admission control mechanisms and access and NAS requirements. Francois: Is the Delegation of Authorization a terminology issue or are there other things. Matthew: Only addressing multicast admission control for now. Typo: last slide should read xxx-07 not xxx-05 Woj: never got any feedback regarding gaps regarding BBF WT-147 and this framework. We assume that all people care about is being addressed. Matthew: Can we make that assumption? Woj: Same request made to BBF to read our draft and for us to ready their draft and no response. Mark: Always better to get affirmative responses. What we've done in the past is ask for 5 reviewers. Matthew: didn't ask for 5 reviewers. Need to do this before last call. Given timing we could find some from the BBF that have access here. Editors here are active in BBF and should do cross check. Mark: call out people on the list to get reviewers. Matthew: volunteers? Francois: will review but cant do gap analysis. Matthew: will ask Sven as well since he is active in both. Woj: Call for reviewers and last call can be done in parallel. Got 2 volunteers from Jabber. One is "Lion"? (also got Alan Kavanagh volunteer via SMS) Matthew: Want to make sure we get a minimum amount of review for last call. Sending the document to WG last call we have Tom Francois, 2 from Jabber and will ask Sven to double check with BBF folks. Call will also be put out on the list. Matthew: will give 2 weeks then put in call then give another 2 weeks. ANCP Protocol Draft - Roberta Maglione (roberta.maglione@telecomitalia.it) http://tools.ietf.org/html/draft-ietf-ancp-protocol-04 Woj presented for authors. Post feedback to the list. See slides. Multicast Slide Francois: hoping we could close on using the field set to 0x00 to mean Ignore. We have discussed using 00 on the list after the previous multicast extension document presentation. Now that we all agree on result 0x00, can we upgrade the multicast message in the document to align? Woj: Objections? Multicast Capability Slide (2 alternative) Francois: The 2nd one is kind of closer to the negotiation works today. This is another thing that we should decide on. Approach number 2 simpler. Define 3 capabilities for 3levels of multicast so negotiation works the same. As long as the two ends seen a capability in common they keep it. Only trick is that we define the capabilities as subsets of one another as opposed to alternatives. Don't change negotiations. Option one is more hard core negotiation. Negotiate multicast and then what is supported. Option 2 seems simpler because no change to negotiation machinery. Woj: (opinion) #2 is what we have today. Both depend on sequence of events we have today. Option 1 is a bit odd because conceivably you could advertise capability, but then no subsets. Prefer option 2. Francois: prefer option 2 Tom Taylor: option 1 the base capability gives base functionality and subsequent give additional capabilities. Woj: in 2 you start w/ all and work down. In 1 you start with a small set and work up. Tom assuming in 2 all can be ranked. Option 2 forces you to take ranking. If you advertise capset 1 and 2 then you must support 1 and 2. Francois: defined functionality as strict supersets of one another. Problem for multicast do you do 1, 1,2 or 1,2,3 Can do with approach 1 or 2. For things independent is covered. Need to cover things that are dependent. In approach 2 clever, approach 1 is flexible, but not sure you want that flexibility. Matthew: option 2 seems a complex way to negotiation capabilities. Francois: option 1 is 2 step/level, option 2 is one step. Tom: the strict ordering was defined that way, but not necessary that it be that way. Can define as an incremental capability. Robert: 1 gives a profile and may be limiting capabilities with 2. George Swallow: Defining sets tends to explode set definitions. Well defined sets are good to define but not in protocol. Francois: Option 1 can still allow negotiation in one blow, so am OK with option 1. In this case we need to prevent too much flexibility, so can't say we can do 2 but not 1. Matthew: definiting which capabilities is separate from how you negotiate capabilities. George: in the document you can specify minimum sets for compliance. Woj: Any strong proponents for 2? any opposition to 1? Will go with 1. Tom: Reconsideration of target. Seems like a waste of a word. Woj: discussion on list and concluded on a name. Tom: need to look at list discussion Additional Multicast Control Extensions for ANCP - Francois Le Feucher (flefauch@cisco.com) http://tools.ietf.org/html/draft-lefaucheur-ancp-mc-extensions-00 Francois presented. See slides. Tom: Can you have different versions between source and destination? Francois: yes Tom: If whole profile is on same IP version, then can take version out and put it at a higher level and can save byte Francois: You may want to push both v4 and v6 lists, could have a ver iside entry or a single IP version and then push two profiles. Tom:More compact that way, no gain by mixing. Still must spell out all addresses. Francois: in the port up message don't want to push two profiles. Nabil: could put in a length that tells how many tuples follow Tom: put version at same level as profile name. Francois: Won't work, but then will need to push two profiles. Confusing saying push that list and that list and can't tell which is for v4 or v6. Inside profile we can put a bunch of v4 and a bunch of v6 Robert: If the address is IPv6 then isn't it longer in the diagram. Francois: yes no length assumed Woj: On multicast service profile. Meant to be provisioning message. What is the overall operand AN or particular Access Line. Tom: Access Node because your port management assigns access to the lines. Francois: port up message selects profile for ports. Robert: On TLV encoding, typically if you have a suboption of fixed len, then you don't need a length. In the object it seems to be a good idea to put the lengths in to keep things straight especially when there is a number of variables. Francois: back to Multicast Service Profile TLV. Robert: put length in header will check draft Francois: back to Admission Control Reject - will think a bit more and comment add to next version of document Hand over to protocol document as is and if more stuff, then suggest to editors OR Let run one or two more versions and add some additions then hand over as a stable entity to the protocol document. Matthew: settle on the issues then merge the changes. Jabber: show of hands how many read? ~3-4. Woj: How does the author feel about the comments raised? Francois: Satisfied with resolution of open issues, but more work on Band delegation new messages and tlvs. Two minds, perception works well to focus on multicast and progress in parallel with protocol document. Progress one more time and then when stable hand over. Difficult to propose changes to protocol document. Nabil: When you have the access control decision at the AN, and you have the admin requst to the NAS in that case is the hmp stopped at the AN. What is the impact on the NAS? If you have to initiate PIM, etc. Do you initiate the join? F: Given an addition request, the AN may issue a join. Nabil: documented anywhere? F: no. but discussion should be added because it can act in different ways. Nabil: could be added to whatever access control model the document applies to. Robert: need len on sub TLV. With proper length you would know what is expected could squeeze in field 2. F: we can take this offline Woj: Is there anyone that is unsatisfied with direction of draft if it is merged after one more revision? F: if reissued should it be reissued as WG? Woj: Pretty quick progress, No reason why shouldn't be merged. Matthew: Might as well merge in because will be issued as WG draft and then disappear when merged. W: If author wants WG draft we have precedent that overflow on multicast is in same document F: shows work is work of WG and not individuals i.e., "lunatics" J M: rev draft and then have discussion as to WG or not. Vendor Specific Message for ANCP - Dave Sinicrope (euddasi@redback.com) http://tools.ietf.org/html/draft-arberg-ancp-vendorspecific-01 Dave presented. Rev the draft and address: 1. The scope of the TLVs. Are they specific to a vendor specific message or across all ANCP messages? 2. Trojan horse issue: Is it possible to add a number of actions within the vendor specific TLVs under the vendor specific message? 3. Is the vendor specific TLV only applicable to messages with the extension block or all messages? 4. Need to note that the GSMP vendor specific messages are not used. Only ~3 people read the draft in the room. Will take to the list to see level of review and WG opinion on how to progress to WG document or protocol document section. Applicability of Access Node Control Mechanism to PON based Broadband Networks - Nabil Bitar (Verizon) http://tools.ietf.org/id/draft-bitar-wadhwa-ancp-pon-00.txt This draft was very briefly presented, but there was insufficient time for discussion.