Subject: Re: [MBONED] Updating charter / milestones?

From: "Holland, Jake" <[email-masked]>
Date: Wed, 16 Nov 2016 03:41:03 +0000

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.

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.

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.

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?

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

Jake

From: Tim Chown <[email-masked]>
Date: Monday, November 14, 2016 at 10:49 AM
To: "[email-masked]" <[email-masked]>
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

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 15 Nov 2016 22:36:55 -0800

Inline GS:

On Tue, Nov 15, 2016 at 7:41 PM, Holland, Jake <[email-masked]> 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 <[email-masked]>
> *Date: *Monday, November 14, 2016 at 10:49 AM
> *To: *"[email-masked]" <[email-masked]>
> *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:
>
> Mar 2014 - Submit Overview of Multicast in the Data Center to IESG for
> Informational - draft-ietf-mboned-dc-deploy
>
> Not sure where we are on congestion control work, though we saw an
> interesting circuit breaker proposal today.
>
>
>
> 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?
>
> _______________________________________________
> MBONED mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mboned
>
>