Subject: mboned: draft minutes of the last mboned session

From: Hiroshi Ohta <[email-masked]>
Date: Wed, 19 Apr 2006 02:32:03 +0900

Working group,

Attached below is the draft minutes of the last mboned session 
in Dallas.  If you have any comments, please post it on this 
list by the end of Thursday this week.

Thank you.
Hiroshi and Marshall

-------------------------------

MBONE Deployment WG
IETF 65 Thursday, 9:00-11:30
=========================================================
introduction of two new chairs: Marshall Eubanks, Hiroshi Ohta
--------
Administriva
*Marshall: still need a secretary and draft reviewers, please volunteer
--------
Review and status of work items
*Marshall: at Vancouver went through a list of IDs and some declared dead then. Decided will not revive those already declared dead without explicitly expressed interest from community. If any IDs missing speak up now or on ML, etc.
--------
draft-ietf-mboned-msdp-mib-01.txt 
*Marshall: On the 2006-3-30 IESG Telechat Agenda (Under AD Evaluation), guess it will go through
*Dave M: was some confusion because last called as informational instead of experimental, Bert was unhappy about that.  But think is ready to go now.
   ----
Draft-ietf-mboned-addrarch (BCP)
*Marshall: Waiting on Proto Review, waiting for someone (this case us) to write an executive summary so ADs can describe doc to IESG. Plan to do within week after this IETF
*Pekka -- addrarch out of the rfc editor queue; RFC editor won't　make the changes, so need to rerun the consenus process
------------
RFC-Ed queue
draft-ietf-mboned-msdp-deploy-06.txt
*John Duran 
	-tried to use msdp-deploy draft to design msdp               deployment. Doesn't want to hold up RFC of draft but has some questions need to be addressed.
	-Questions on multiple route reflectors (not described) and MSDP redundancy. Would like to rev the draft. 
	-there are best current practices for this that are known so may not be difficult to address
*Marshall: encourage to send to ML
	-what is consensus on this?
	-question about whether to yank back or not
*Dave M: has been in RFC queue for 2 yrs so not surprising the world has changed ambivalent but if there are problems more important to produce quality not quantity
*Marshall: if we yank back could get done quickly but a new doc could take a long time
   ----
   draft-ietf-mboned-ssm232-08.txt
*Marshall: Will be out soon : was waiting on the PIM Spec
   ----
   draft-ietf-mboned-mroutesec-04.txt
*Marshall: was waiting on PIM spec
*Pekka Savola: also waiting on generic routing protocol security document form Rpsec, which has been in RFC editors queue for 2 yrs but Rpsec want to take back doc for additional changes, and will need to go through IETF process again.
	-recommends to change reference to that generic routing protocol sec doc from normative to informational, since not really required to read this doc so can be released at same time as PIM sec
*Bert as AD: That is ok to downgrade he reference as long as get consensus on list and the ADs check the change
*Pekka: thinks PIM spec will take long to process anyway, so don't need to hold it up
------------
need a jabber scribe
------------
   Active Drafts
   -------------
   draft-ietf-mboned-addrdisc-problems-01.txt
     Savola
*Pekka -- address discovery problems -- (see slides)
	-Address Discover Problems
	-2 non-major revisions since last IETF
	-generalized registry assignment text
	-add section on DNS redirection
	-other editorial fixes 
	-received comments from Stig
	-correct error on BSR scoping / manual config scoping
	-SDP format instead of SAP format
	-WG not too active. What next? 
	-If you are thinking of solutions in this space, please evaluate against
this document. don't think it should become an RFC at this point, but
just to focus discussions on solutions. 
   ----
   draft-ietf-mboned-routingarch-02.txt 
     Savola
 (no slides)
*Pekka: just editorial update made.
	-thinks its close to ready. wants thorough review so that we can  WGLC... 
no comments from room
   ----
   draft-ietf-mboned-maccnt-req-04.txt     
     Susheela Vaidya 
     (see slides)
*Susheela: Review of status
	-3 revisions since Vancouver
		-addition of definition of eligible user"
		-clarification of the scope of the requirements (adding "Regarding Access Media and User Separation")
		-text added for following: relevancy with respect to MSEC, resource protection, fast join & leave latency
		-significant changes to abstract, intro and conclusion,
		-definition of "fully AAA enabled" IP multicasting network added
		-goal of minimal impact on existing products
	-Proposal to WG: has gone through LC, thinks ready to submit for IESG review
*Kevin Almoroff: may not be related to this doc but should talk about changes to IGMP/MLD
	-it is operational issue
*Marshall: says ready to progress should speak up now or post to ML
	-does anyone think there needs to be a next rev of IGMP/MLD
*Dave M & Marshall-- there should be something simpler than IGMP/MLD
*Dino -- need use cases for IGMPv3
	-magma or mboned do IGMPv3 snooping specs?
*Dave Thaler -- should be MAGMA discussion
*Pekka -- magma is in the process of being shut down
*Marshall -- possibly a BOF on IGMP/MLD in Montreal?
*Dino -- should it be part of the mboned charter
*Marshall -- this discussion should be part of the charter discussion to follow
*Beau  Williamson -- May not be possible to implement a subset of v3. does simplifying IGMP mean IGMPv4
*Ron Pashby -- Has drafts on MLD snooping,  but MAGMA is being shutdown, wants MBONED to pick it up
*Dave Thaler -- wouldn't like to see IGMPv4; doesn't want to rev hosts. 
*Hiroshi Ohta -- took note on possible IGMP/MLD BOF, but back to discussion on draft-ietf-mboned-maccnt-req-04.txt.  Question any objection to send ready for IESG.
No objection in room but final consensus to be made on ML
   ----
   draft-ietf-mboned-rac-issues-02.txt       
     Sato
(see slides)
*Sato :review of multi-entity network model
	-updated since Vancouver, presents 5 major changes and some minor
	-thinks draft is stable, ready for LC soon
	-next step - Framework for "well managed IP multicasting"
	-issues draft should be referenced by framework draft so needs to be RFCs
no comments/objections
*Marshall -- to the list, quickly decide
   ----
  draft-ietf-mboned-auto-multicast-05.txt  
  Dave Thaler (see slides)
*Dave Thaler: 05 went through WGLC discussion, with various discussions
	-Expect -06 soon, early version sent to amt ML
	-Added IGMP/MLD Query to AMT Membership Query
	-message to allow gateway to know what version of report to respond with.
*Dino -- will the amt membership sent periodically? 
*Dave -- sent in response to query (as frequently as the gw asks for it). The QQIC should be used to communicate what the router query intervals etc so that hosts that abuse this and send too much can be ignored 
*Dino -- is the query "quickly" reliable? if lost is retransmitted quickly?
*Dave -- don't remember
*Dino -- take offline
*Greg - Follows IGMP/MLD timing, but you said that the gateway side had the timers. wants the router to control. Need to add text about clarifying what the gateways to (re:timing)
*Dave -- Added text to say the UDP checksum SHOULD BE calculated on control messages but MAY be 0 on the multicast data messages.
*Dino - Checksum: should be zero on data messages
discussion on MAY vs SHOULD, Dave and Dino agree
*Dave -- Clarified that the IP header is included in IGMP/MLD messages as well as the multicast data messages.
	-presention of editorial changes
	- (i).    argument: Support for sourcing, already existing
	-Proposal: 
		-A gw MAY support sourcing
		-Public relays MUST support sourcing   
		-Private relays SHOULD support souring
*Greg -- prefer MAY, MAY, MAY, RPFing to anycast prefix too complex
*Dave -- don't assign same anycast prefix to a gw that does support souring and those that do. 
*Greg -- No, you find the closest one anyway.
*Dino -- If the gateway does a MAY, that means most gws' won't implement, public gws MUST. No working system. MAY, MAY, MAY, and get a gw prefix (second for address allocation). should be consistent
*Pekka -- do you personally expect a sign number sourcing SSM with AMT?
*Dave -- don't know
* Pekka --  MUST in sourcing in AMT
	-whatever decision wants quick decision
*Dave-- agree quick decision necessary
	-(ii).   IPv6 Unicast Prefix Length
		-Draft said /64; perhaps /16           
	- (iii).  Data encapsulation
		-GRE doesn't go though NATs --> just UDP or negoiate for GRE.
		-Proposal: Keep it simple--just UDP (no change to spec) 
*Pekka -- can AMT signaling extensible enough for the routers to signal preference?
*Dave -- you'd have to change the packet format. but are messages that could be extended to do that. would add complexity.
*Pekka -- v6 prefix length --> need at least /32  (otherwise won't be routable).
	-need more clear instructions about IANA
	-maybe update IANA considerations
*Marshall -- tell the chairs what to do so we can talk to IANA, let us know.
*Dino -- don't expect fast mass deployment. But we may get fast deployment, but if it doesn't perform well, won't get to mass deployments, propose we need a simple negotiation
--------
   Individual Drafts
   -----------------
   draft-satou-multiaaa-framework-01.txt
     Sato
   (see slides)
*Sato:  updates: Added roles for each entity
		-added new entity: Transit Provider
		-added modularity
	-Request mboned to accept this I-D as a WG item.
*Dan: should it be in the charter? is this a chartered deliverable?
*Dave Meyer: doesn't necessarily have to be in charter, but ops groups takes on, maybe should be explicitly put in charter
   ----
   draft-mcwalter-ip-mcast-mib-01.txt
     David McWalter
    (see slides)
*David M. : Need to update RFC 2932, IPMROUTE-STD-MIB
	-Add IPv6 
	-SSM IPv4 address range configuration
	-Minor improvements, statistics, etc
	-MBONED the right venue? it is a widely deployed MIB, Bill Fenner doesn't have the time to sponsor it (Pekka's suggestion)
	-draft in good shape, asks if there are objections to having MBONED work on it?
*Pekka -- yes, good idea; minor comment: SSM range config optional?
*Dave -- don't remember, will check and make sure that is the case. 
*Marshall -- Adopted (consensus on that). Is it ready for WGLC? by next week? Any comments on that? 
no strong feelings for or against
   ----
   Others
   ------
   Drafts to be submitted
 draft-pashby-mboned-mc-scoped-addr-01.txt
*Ron Pashby: Scoped ranges (see slides) 
	-should we accept this draft as WG doc?
	-wants more feedback
take to ML
   ------
   draft-pashby-magma-simplify-mld-snooping-00.txt (ron)
         (see slides) 
*Ron Pashby: was in magma, should be in mboned (operational; how to implement inside a l2 switch)
	-purpose:Simplify the forwarding rules for Local Network Control and Dynamically
	-Assigned Link-Local Scoped groups
*Dino -- Is it a problem if you send reports for link-local addrs? 
*Ron -- no.
*Dave Thaler -- magma-snoop-l2 --> seems like optimizing for limited state in the switch, not b/w on wire.  thinks better to let the environment to decide to optimize for state or b/w
*Pekka -- thinks snooping draft will become RFC soon
*Dave Thaler -- clarification question about ranges
   ------
 o Charter Discussion  
(see slides)
*Ohta: question of draft-satou-multiaaa-framework-01.txt being WG item was deferred to charter discussion. Is there any feeling on the floor? 
*Pekka concern: not enough review on ML, not sure if enough people have read would rather talk about big picture (the charter) than a specific draft now
Ohta presents :"MBoned Charter Overview"
 (see slides)
*Ohta: existing items (shall we keep?)
	-10 active drafts (some may be added specifically as items)
*Dave Meyer: recommends generalist and tight milestones both ops groups evolve over time, learn new things/ new things evolve not a protocol group that can just list specific items rechartering is not easy... milestones precise need general, so can take on new items as come on
continuation of Ohta presentation
* Ohta: additional possible new items
	-SSM (shall we use SSM only?)
	-IPTV
	-IPTV Standards
	-Operator Survey
	-AMT
	-Multicast AAA work
	-Multicast Number Registry
	-Port Registry
	-Address Registry
	-Other means to get out of the address mess ?
*Marshall:  thinks that a registry should be established for ports and addresses.
*Dave Thalor: thinks should just go to IANA port, why create separate numbering space?
*Beau: possible charter items.  MAGMA is going away.  PIM going through as RFC.  leaves this group alone as guardian of multicast. thinks charter shouldnt be restrictive so cant 
Sato -- presentation "Proposed Additions to mboned charter"
  (see slides) 
*Sato: proposal:
	-1) review of current state of multicast technology deployment in IP broadcasting
	-2) clarification of requirements for desired new capabilities related to the deployment of multicast technology in IP broadcasting
	-3) development of architectural frameworks for new multicasting operational functions for IP broadcasting
*Marshall: fairly broadly support
*Collin Perkins: generally good idea, dangerous avoid overlap with other groups such as AVT (could be extended to monitoring multicast sessions)
*Marshall: maybe this group should just be pointing to solutions already existing. "here is how to solve X"
*Pekka- thinks first 2 items. doesn't want framework(s), maybe should be one document. 
*Ohta: intention of plural, was we don't know what frameworks are possible.  Possible to have several proposals for discussion purposes, and then select.
*Don: who is audience for this framework document
*Marshall: primary audience is IPTV vendors
*Don:      think need people who can help with each of the documents
*Dino: think mboned session needs more time since this is only forum,Schedule 2 sessions
Marshall -- Whiter MBONED presentation about state of multicast
(see Slides)
*Marshall:  this WG needs to fix reliability issues
	-triple play, IPTV is hot
	-IPTV is using multicast, should be SSM but not
	-no IPTV operators, wireless operators in this room. this is a problem.
	-think operators don't care about bringing in from Internet
	-how can this WG generate interest.
	-operator survey is necessary because we dont know what operators need
	-need to "publicize" the work
	-question if good procedures for how to operate multicast today?
	-in addition: need something to see operational guidelines
	-lots of players don't understand what is possible, they need us to tell them what is possible
*Pekka: no harm in writing a doc to show operators how the pieces fit together
*Beau: many operators have walled-garden mentality in mind, many don't care about bringing in multicast in from the Internet
*Jason:  I'm from an operator.  large reason operators don't come is economics, many operators don't see connection between IETF activities and revenue.
*someone:  easy to deploy multicast, hard to fix problems
          need more of a management information base
*Marshall: agrees this is a problem
*Jason: need high-level views, because many operators can only see complexity
*Ohta: - added as operational guidelines a suggested charter item from the floor
	-also we will discuss charter items on ML
		-SSM
		-port issues
	-framework document as WG item? take to ML 1 or 2 weeks after IETF
-----
Presentation of gift and expression of appreciation to Dave Meyer for his many years as mboned chair.

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 21 Apr 2006 10:19:39 -0400

Hello;

These need to go out today. I have a few small corrections.

If there are no further comments I will post these by COB.

Marshall

On Apr 18, 2006, at 1:32 PM, Hiroshi Ohta wrote:

> *Marshall: at Vancouver went through a list of IDs and some  
> declared dead then. Decided will not revive those

s/some declared/some were declared/

> already declared dead without explicitly expressed interest from  
> community. If any IDs missing speak up now or on ML, etc.

> *Dave M: was some confusion because last called as informational  
> instead of experimental, Bert was unhappy about that.  But think is  
> ready to go now.
>    ----
> *Marshall: Waiting on Proto Review, waiting for someone (this case  
> us) to write an executive summary so ADs can

s/this case/in this case/

> describe doc to IESG. Plan to do within week after this IETF
> *Pekka -- addrarch out of the rfc editor queue; RFC editor won't　 
> make the changes, so need to rerun the consenus process
> ------------
> RFC-Ed queue
> 	-tried to use msdp-deploy draft to design msdp                
> deployment. Doesn't want to hold up RFC of draft but has some  
> questions need to be addressed.
> *Dave M: has been in RFC queue for 2 yrs so not surprising the  
> world has changed ambivalent but if there are problems more  
> important to produce quality not quantity
> *Pekka Savola: also waiting on generic routing protocol security  
> document form Rpsec, which has been in RFC editors queue for 2 yrs  
> but Rpsec want to take back doc for additional changes, and will  
> need to go through IETF process again.
> 	-recommends to change reference to that generic routing protocol  
> sec doc from normative to informational, since not really required  
> to read this doc so can be released at same time as PIM sec
> *Bert as AD: That is ok to downgrade he reference as long as get  
> consensus on list and the ADs check the change
> 		-clarification of the scope of the requirements (adding  
> "Regarding Access Media and User Separation")
> 		-text added for following: relevancy with respect to MSEC,  
> resource protection, fast join & leave latency
> *Hiroshi Ohta -- took note on possible IGMP/MLD BOF, but back to  
> discussion on draft-ietf-mboned-maccnt-req-04.txt.  Question any  
> objection to send ready for IESG.

s/sent/be sent/

> *Dave -- sent in response to query (as frequently as the gw asks  
> for it). The QQIC should be used to communicate what the router  
> query intervals etc so that hosts that abuse this and send too much  
> can be ignored
> *Greg - Follows IGMP/MLD timing, but you said that the gateway side  
> had the timers. wants the router to control. Need to add text about  
> clarifying what the gateways to (re:timing)
> *Dave -- Added text to say the UDP checksum SHOULD BE calculated on  
> control messages but MAY be 0 on the multicast data messages.
> *Dave -- Clarified that the IP header is included in IGMP/MLD  
> messages as well as the multicast data messages.

s/presention/presentation/

> *Dino -- If the gateway does a MAY, that means most gws' won't  
> implement, public gws MUST. No working system.

s/gws/gateways/g

> MAY, MAY, MAY, and get a gw prefix (second for address allocation).  
> should be consistent
> *Dave -- you'd have to change the packet format. but are messages  
> that could be extended to do that. would add complexity.
> *Dino -- don't expect fast mass deployment. But we may get fast  
> deployment, but if it doesn't perform well, won't get to mass  
> deployments, propose we need a simple negotiation
> --------
>    Individual Drafts
>    -----------------
> *Dave Meyer: doesn't necessarily have to be in charter, but ops  
> groups takes on, maybe should be explicitly put in charter
>    ----
> 	-MBONED the right venue? it is a widely deployed MIB, Bill Fenner  
> doesn't have the time to sponsor it (Pekka's suggestion)
> *Dave Thaler -- magma-snoop-l2 --> seems like optimizing for  
> limited state in the switch, not b/w on wire.  thinks better to let  
> the environment to decide to optimize for state or b/w
> *Ohta: question of draft-satou-multiaaa-framework-01.txt being WG  
> item was deferred to charter discussion. Is there any feeling on  
> the floor?
> *Pekka concern: not enough review on ML, not sure if enough people  
> have read would rather talk about big picture (the charter) than a  
> specific draft now
> *Dave Meyer: recommends generalist and tight milestones both ops  
> groups evolve over time, learn new things/ new things evolve not a  
> protocol group that can just list specific items rechartering is  
> not easy... milestones precise need general, so can take on new  
> items as come on
> *Beau: possible charter items.  MAGMA is going away.  PIM going  
> through as RFC.  leaves this group alone as guardian of multicast.  
> thinks charter shouldnt be restrictive so cant
> 	-2) clarification of requirements for desired new capabilities  
> related to the deployment of multicast technology in IP broadcasting
> 	-3) development of architectural frameworks for new multicasting  
> operational functions for IP broadcasting
> *Collin Perkins: generally good idea, dangerous avoid overlap with  
> other groups such as AVT (could be extended to monitoring multicast  
> sessions)
> *Marshall: maybe this group should just be pointing to solutions  
> already existing. "here is how to solve X"
> *Ohta: intention of plural, was we don't know what frameworks are  
> possible.  Possible to have several proposals for discussion  
> purposes, and then select.
> *Beau: many operators have walled-garden mentality in mind, many  
> don't care about bringing in multicast in from the Internet
> *Jason:  I'm from an operator.  large reason operators don't come  
> is economics, many operators don't see connection between IETF  
> activities and revenue.

At the end of the meeting, there was a