Subject: [MBONED] MBONED draft minutes

From: Leonard Giuliano <[email-masked]>
Date: Wed, 25 Mar 2015 07:36:36 -0700

Draft notes from yesterday's lively and spirited MBONED meeting (thank you 
Duke F. for taking them).  Please take a look while it's fresh on your 
mind and send any edits as it was tough to keep up with all the fast and 
furious discussions.

Agenda begins:
 	Status of Active WG Docs
 	RFC7450 Greg B, finally made to RFC status after  14 years

Percy Tarapore presented : (draft-tarapore-mboned-multicast-cdni)
 	Percy would like to know if name should be changes, what version, 
need guidance
o	Lenny  recommend name change and version to start at zero
 	Lenny questioned relevance of AMT tunnel  (section 3)
 	Percy ask for thoughts where 2 domains my not utilize same 
protocols (section 4.2)
o	From audience
 	1st  recommendation is to put into separate document
 	2nd recommendation is to state in document that this will not be 
addressed
 	3rd recommendation is if there is a consensus that this is not a 
good idea, then do not put into document.  Do not need to include every 
corner case/crazy idea a SP might have.
 	(there were other comments, but they fit into the same as above)
 	Asking for overall feedback (section 4.3)
 	Lenny: what about ASM?  Specifically, should MSDP be mentioned 
since it has been used for peering in the past?
 	Consensus: No, should focus on SSM only for interdomain and not 
document ASM since it is not recommended.
o	Lenny  this document is basically for peering, could we use 
unicast peering guidelines as a template.  Asked audience if anyone knows 
of one.
 	Audience:  Nothing known, but believe there should be docs 
somewhere, and will look
o	Comments on not covering settlement, to keep the document shorter, 
more focused
o	Comment on need of this document.   Is there a need for mcast 
peering between providers?  We tried several years to get global multicast 
to work and failed.
o	Can we add section on troubleshooting and diagnostics
o	Percy summarized that this section should be condensed, but also 
add troubleshooting piece
o	Lenny  would like to get more operator input

Ali Begin presented (draft-singer-appsawg-mcast-url-00)
o	Lenny  asked why fcast
 	Ali asked for general questions: Is there a need for this, do you 
care or not care?
o	Can background on how these are URLs are used in unicast? To 
provide an example, would be helpful
o	How do notify the clients to switch to multicast
 	Redirect to a different URL to join multicast stream
 	Should be done in real time without prior signaling
o	FCAST would like to be used since it is being adopted by much of 
industry
o	Could you bring aspects of AMT into this also?
 	Lenny polled room on who has read the draft?
o	None, but this has not been sent to MBONED working group
o	Please troll the WG before submitted
 	Poll on who thinks should be MBONED working group
o	~ 7-8 support adoption, 0 against

Bill Atwood presented (Secure and Accountable AMT)
 	General questions at the end
o	Was any of the security issues addressed with AMT?   Comment that 
the security issues have been verified.
 	Bill said he will provide additional information on the list

Lenny presented (Multicast Requirements for 2015)
 	Some comments from audience:
o	Bursty sources  not sure if the requirement should be removed
 	Do we want one solution to that covers everything:  Question of
 	discovery of sources
 	Do we want the network to do the discovery or the application
o	Separation of control and data to keep to improve multicast
o	The network already has unicast capability to everyone, why do I
 	need to complicate it with multicast?
 	Belief that live linear is not dead, there is a need for multicast
 	in the future, with future applications?
o	The question is how much do you want to do?  Just how large of
 	scope do you cover?
 	If this WG could provide useful guidance to app developers, that
 	would be great.  The other questions is would it even matter
o	There was a ton of comments and feedback here  too many to
 	document

Greg Shepherd  BIER update
 	Best draft to start reading is the problem statement, then 
architecture
 	If there is a solution in IPv6 please bring to the group

---

From: Mike McBride <[email-masked]>
Date: Thu, 26 Mar 2015 15:00:00 -0500

Great meeting. I also seem to recall Beau discussing details about some sort of extraction. Perhaps you can provide more info. 

We didn't discuss wifi MCAST much. If anyone is interested in writing up the problem with me please ping me. 

mike

> On Mar 25, 2015, at 9:36 AM, Leonard Giuliano <[email-masked]> wrote:
> 
> 
> Draft notes from yesterday's lively and spirited MBONED meeting (thank you Duke F. for taking them).  Please take a look while it's fresh on your mind and send any edits as it was tough to keep up with all the fast and furious discussions.
> 
> 
> 
> Agenda begins:
>    Status of Active WG Docs
>    Percy would like to know if name should be changes, what version, need guidance
>    Percy ask for thoughts where 2 domains my not utilize same protocols (section 4.2)
> o    From audience
>    2nd recommendation is to state in document that this will not be addressed
>    3rd recommendation is if there is a consensus that this is not a good idea, then do not put into document.  Do not need to include every corner case/crazy idea a SP might have.
>    Lenny: what about ASM?  Specifically, should MSDP be mentioned since it has been used for peering in the past?
>    Consensus: No, should focus on SSM only for interdomain and not document ASM since it is not recommended.
> o    Lenny  this document is basically for peering, could we use unicast peering guidelines as a template.  Asked audience if anyone knows of one.
>    Audience:  Nothing known, but believe there should be docs somewhere, and will look
> o    Comments on not covering settlement, to keep the document shorter, more focused
> o    Comment on need of this document.   Is there a need for mcast peering between providers?  We tried several years to get global multicast to work and failed.
> o    Percy summarized that this section should be condensed, but also add troubleshooting piece
>    Ali asked for general questions: Is there a need for this, do you care or not care?
> o    Can background on how these are URLs are used in unicast? To provide an example, would be helpful
> o    FCAST would like to be used since it is being adopted by much of industry
> o    Was any of the security issues addressed with AMT?   Comment that the security issues have been verified.
>    Best draft to start reading is the problem statement, then architecture
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned