MBONED draft minutes
Leonard Giuliano <lenny <at> juniper.net>
2015-03-25 14:36:36 GMT
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
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,
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
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
Audience: Nothing known, but believe there should be docs
somewhere, and will look
o Comments on not covering settlement, to keep the document shorter,
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
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
Greg Shepherd BIER update
Best draft to start reading is the problem statement, then
If there is a solution in IPv6 please bring to the group
MBONED mailing list
MBONED <at> ietf.org