Re: [MBONED] Updating charter / milestones?

Inline GS:

On Tue, Nov 15, 2016 at 7:41 PM, Holland, Jake <jholland@akamai.com> wrote:

> Hi,
>
>
>
> Based on conversations I’ve been having here, the circuit breaker proposal
> I presented Monday (https://tools.ietf.org/html/
> draft-jholland-cb-assisted-cc-00 ) will -- at best -- have a very long,
> very bumpy road to adoption, and to me it looks at least 90% likely to die
> along the way (though I remain hopeful for now that some solution might
> eventually be standardized).
>
>
>
> However, I also believe the problem it’s trying to address is a clear and
> present danger that is a significant barrier to a multicast backbone
> deployment, and even to interdomain multicast deployment in general.
>

GS - How is this different from Unicast? An ill-behaved unicast agent can
open any number of TCP session to DOS itself, and/or any of the links
between itself and the source. The difference being it's UDP and won't
back-off on it's own. But a full pipe is a full pipe.

> Furthermore, I couldn’t find an in-depth discussion of the problem in what
> I thought was a pretty wide review of the literature. There’s a few brief
> mentions, such as the 3rd paragraph in WEBRC’s security section:
> https://tools.ietf.org/html/rfc3738#section-7 , but nothing that I
> thought articulated the severity of the issue as it stands, and most, like
> for instance NORM, a proposed standard (https://tools.ietf.org/html/
> rfc5740#section-7 ), had no mention at all. I might have missed
> something, but I think the Appendix A in my doc is currently the most
> in-depth discussion I’ve seen of the issue, though it certainly could be
> expanded a great deal further.
>

This issue has come up numerous times in the past. I find the conversation
is often focused when you ask what I asked above - what does unicast do? I
think there tends to be excessive caution for all things multicast, and not
always in proportion to the actual threat.

> So I’m thinking the right thing to do is to write an informational problem
> statement draft which explains the problem in more detail, with perhaps a
> detailed explanation of all the known countermeasures and what mitigations
> they can achieve and not achieve. From the mboned charter, it also looks to
> me like if such a draft existed, it would make sense for it to be a mboned
> working group document.
>

That would be helpful, thanks!

> If I were to write such a problem statement informational draft, can I get
> a commitment from members of mboned to review the document, and to read and
> consider it for adoption by the wg?
>

I'll read it.

> Also: would anyone like to volunteer to be a co-author?
>

I'd rather a non-chair take on this task.

Cheers,
Greg

> Jake
>
>
>
> *From: *Tim Chown <Tim.Chown@jisc.ac.uk>
> *Date: *Monday, November 14, 2016 at 10:49 AM
> *To: *"mboned@ietf.org" <mboned@ietf.org>
> *Subject: *[MBONED] Updating charter / milestones?
>
>
>
> Hi,
>
>
>
> Just a quick followup to the mic comment about our charter and milestones.
> Largely as I’m curious as to what work we see coming up in the WG.
>
>
>
> I think the charter still looks good. We might de-emphasise transition
> mechanisms, and perhaps add a more explicit hint of bier.
>
>
>
> Current milestones:
>
> Jan 2014 - Submit Mtracev2 to IESG for Proposed Standards
> - draft-ietf-mboned-mtrace-v2
>
> Mar 2014 - Submit Overview of Multicast in the Data Center to IESG for
> Informational - draft-ietf-mboned-dc-deploy
>
> Mar 2014 - Work with TSV area to submit multicast transport guidelines for
> congestion control
>
>
>
> Mtrace v2 is pretty much there :)
>
> draft-ietf-mboned-dc-deploy-01 seems to have fizzled out - dated Aug 2013.
>
> Not sure where we are on congestion control work, though we saw an
> interesting circuit breaker proposal today.
>
>
>
> The question is what our new milestones might look like?
>
>
>
> The current active WG and individual drafts are:
>
>
>
> WG:
>
> https://tools.ietf.org/html/draft-ietf-mboned-interdomain-peering-bcp-05
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmboned-2Dinterdomain-2Dpeering-2Dbcp-2D05&d=DgMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=82dx21mHKvj42KrXW3ORSqxmXOSfoOIHCUv7bHXLzCU&s=cZIPUalyDnJ2hmUQEipXY5E1xgzFTA9SRdcyd0JgDbc&e=>
>
> https://tools.ietf.org/html/draft-ietf-mboned-mtrace-v2-16
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dmboned-2Dmtrace-2Dv2-2D16&d=DgMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=82dx21mHKvj42KrXW3ORSqxmXOSfoOIHCUv7bHXLzCU&s=ufJ4p753-F6uGOc_dLDiI6u6-ECdQp5DNL7fkwzmhE0&e=>
>
> Both are close to done.
>
>
>
> Personal:
>
> https://tools.ietf.org/html/draft-acg-mboned-multicast-models-00
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dacg-2Dmboned-2Dmulticast-2Dmodels-2D00&d=DgMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=82dx21mHKvj42KrXW3ORSqxmXOSfoOIHCUv7bHXLzCU&s=YIAA9OStzHYvoNQIGvYB-AcYK2Vypd3prRTyJ9pP9G4&e=> -
> a rev is coming soon after Seoul.
>
> https://tools.ietf.org/html/draft-zhang-mboned-multicast-info-model-00
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dzhang-2Dmboned-2Dmulticast-2Dinfo-2Dmodel-2D00&d=DgMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=82dx21mHKvj42KrXW3ORSqxmXOSfoOIHCUv7bHXLzCU&s=Frjcr3k69Iab7SXg7tt-Sqx1yEUVGTMyO3MS-r0RrAc&e=> -
> presented today
>
>
>
> What else might we do?
>
> An operational document around practical deployment of bier might be
> useful, for example?
>
>
>
> Tim
>
>
>
>
>
>
>
> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned
>
>