Subject: [ANCP] Minneapolis Minutes

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 8 Dec 2008 17:15:10 +0100

Please find below the draft minutes from Minneapolis. Many thanks to
Dave Sinicrope for these.

Please send any corrections / additions to the chairs.

Regards

Matthew

IETF-73 ancp agenda
Slides
Chairs Slides
Framework
Multicast Control Extensions for ANCP
Protocol draft update
PON
Vendor Specific
Agenda

Thursday, November 20th, 2008 - 13:00 - 15:00
 ---------------------------------------------
CAIRS: Wojciech Dec & Matthew Bocci
          
WG Status and Update - Chairs
-----------------------------------------------
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 requsted 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 - Chairs
-------------------------------------------------------------------
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 int
eh pas 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
([email-masked])
------------------------------------------------------------------------
-------------------------------------
          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 clise 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?  
<None in the room. Check on the list.>

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?  <none> any opposition to 1?  <none>
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
([email-masked])
------------------------------------------------------------------------
-----------------------------------------------------------------
 
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  <it's in the slide>  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?  <none>
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 ([email-masked])
------------------------------------------------------------------------
----------------------------------------
          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. 

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