Re: [MBONED] Benjamin Kaduk's No Objection on draft-ietf-mboned-deprecate-interdomain-asm-06: (with COMMENT)
Tim Chown <Tim.Chown@jisc.ac.uk> Mon, 09 March 2020 23:31 UTC
Return-Path: <tim.chown@jisc.ac.uk>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2EAF3A095E for <mboned@ietfa.amsl.com>; Mon, 9 Mar 2020 16:31:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Jrho3CdzJWs for <mboned@ietfa.amsl.com>; Mon, 9 Mar 2020 16:31:24 -0700 (PDT)
Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC75A3A0957 for <mboned@ietf.org>; Mon, 9 Mar 2020 16:31:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1583796681; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=deTM9Z636S5U7lzzt9RTJGwiOksiS4QFnB1mzFA18I4=; b=XSugpeevhKqk3thaiLwBWAnko37b4k3/Ae9tKC/iLCy8EofvHuFzYYMWHSsXBF9PQPmySe F1ZgiJI7gmsBSLC2QWXVB5qJckIlaNXCA90spDhfqjxs34nJNF+irmZnUAyP9ad5TFueZc 9D/D3ZGW26VadQZOyA4AXDzkiU9/9GI=
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2051.outbound.protection.outlook.com [104.47.14.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-233-kEPdeHbCPSupM5aBDYq-2g-1; Mon, 09 Mar 2020 23:31:19 +0000
X-MC-Unique: kEPdeHbCPSupM5aBDYq-2g-1
Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com (10.168.153.149) by AM5PR0701MB2436.eurprd07.prod.outlook.com (10.169.150.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2814.9; Mon, 9 Mar 2020 23:31:17 +0000
Received: from AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::91c1:8431:27ba:21a1]) by AM5PR0701MB2849.eurprd07.prod.outlook.com ([fe80::91c1:8431:27ba:21a1%3]) with mapi id 15.20.2814.007; Mon, 9 Mar 2020 23:31:16 +0000
From: Tim Chown <Tim.Chown@jisc.ac.uk>
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, "draft-ietf-mboned-deprecate-interdomain-asm@ietf.org" <draft-ietf-mboned-deprecate-interdomain-asm@ietf.org>, Colin Doyle <cdoyle@juniper.net>, "mboned-chairs@ietf.org" <mboned-chairs@ietf.org>, "mboned@ietf.org" <mboned@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-mboned-deprecate-interdomain-asm-06: (with COMMENT)
Thread-Index: AQHVxpgbIQcM2S39gkmQ2CvkmtWz5KhBSGsA
Date: Mon, 09 Mar 2020 23:31:16 +0000
Message-ID: <F4D04625-A83B-49E7-BDA3-11BFBE9FD572@jisc.ac.uk>
References: <157853845450.22456.7347219322097492103.idtracker@ietfa.amsl.com>
In-Reply-To: <157853845450.22456.7347219322097492103.idtracker@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.60.0.2.5)
x-originating-ip: [2001:a88:d510:1101:a4eb:4d50:4adf:5b66]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9959780c-7505-464f-d59f-08d7c481f6f4
x-ms-traffictypediagnostic: AM5PR0701MB2436:
x-microsoft-antispam-prvs: <AM5PR0701MB24367224F4B930080632D326D6FE0@AM5PR0701MB2436.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0337AFFE9A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(39860400002)(136003)(366004)(396003)(199004)(189003)(54906003)(6512007)(6916009)(8936002)(6506007)(86362001)(5660300002)(786003)(53546011)(71200400001)(81166006)(81156014)(8676002)(316002)(2906002)(76116006)(4326008)(966005)(2616005)(186003)(21615005)(66946007)(66476007)(66556008)(36756003)(478600001)(91956017)(64756008)(6486002)(66446008)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2436; H:AM5PR0701MB2849.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Bumop5g2FseVCvDVlt3FnvZHbKN7EAfowXduUEZ+eUiebm4Yulh+lcVKL1s8ubnjjUxDlhuQ8L4N/G7hRys4F/G3WEy6Y7Ca0tho4fmw6UsiVO9HCqo88g56n3WJoR5K8hwkV/mdzURLUfu+NpamP/RbukMnC7lPEq/5rC9U+D6Q0FVDYCY26boyKDmxBDjLvgtV9h9iLYn4VLwM7g1oFlNKdDAMcYPFZpO1Rovkl6+WE6/qLAvZU+7Hhuhyosc+DOsbcd+MBjYQVh6he+NlnSCwGSTVaMH92/5lb2LNvPeUIWrJDxaujE7oXZP557m86ZAY344tdJ0vrFXrQgvka59v3GE52lN+8FPKhBmifBYqr/UM42/bCOrLRRCPrHIqqHOlIR1fIDzHd3qSMHtyF2H1r0dypIOVg7mHVXkG3Z+kR3rimQicKiPACQZ19yG+zIYqXnboXdSz58CKjzPO7LElGpRtn5zYjIeW+nOtXi/qZzSrlcLjiJTb3li7BRvNzdIxZHSK1h3HpeYctaWw6A==
x-ms-exchange-antispam-messagedata: P+LkvyJj3Tw5NnoRH9Xbov9OYSFZBwrZ63mR7YWWiH4up49XG8vtlnrRwfdxHbTLbESLmZ0sLkpjrQPSexbbyJsegc9zzxuz0bdS75wpZV6hQmSDhGvY5BaonrGcgU/sXVBKuwpkc+6gHPZ2Wag9FOMxAZBW1HJRKKHI1dnrTPTmyeHUNpc0wMuQnZNobiuL9O0UMxzMV5Z1HlZHQXQ4XA==
x-ms-exchange-transport-forked: True
MIME-Version: 1.0
X-OriginatorOrg: jisc.ac.uk
X-MS-Exchange-CrossTenant-Network-Message-Id: 9959780c-7505-464f-d59f-08d7c481f6f4
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 23:31:16.8260 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: QdZYpRbhRmLwGiw3J1PoohDev3njNf3fXEFNrT4koGMqNlz/fDPBe8c8I1WxrBPIOnK1qHAKSyekS0pTBnBvPw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2436
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: jisc.ac.uk
Content-Type: multipart/alternative; boundary="_000_F4D04625A83B49E7BDA311BFBE9FD572jiscacuk_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/7PXlKsDNtQzoF0Zex_N8XAj9wdI>
Subject: Re: [MBONED] Benjamin Kaduk's No Objection on draft-ietf-mboned-deprecate-interdomain-asm-06: (with COMMENT)
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2020 23:31:28 -0000
Hi, On 9 Jan 2020, at 02:54, Benjamin Kaduk via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote: Benjamin Kaduk has entered the following ballot position for draft-ietf-mboned-deprecate-interdomain-asm-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mboned-deprecate-interdomain-asm/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this well-written document! Section 2.1 to deliver traffic from the sender(s) to the receivers. If there are multiple senders for a given group, traffic from all senders will be delivered to the receiver. Since receivers specify only the group nit: "receivers" plural. Fixed. Section 3.1 troubleshoot. Some of these issues include complex flooding Reverse Path Forwarding (RPF) rules, state attack protection, and filtering of undesired sources. I'm not sure how to parse "complex flooding Reverse Path Forwarding (RPF) rules" (but think I could figure out "complex Reverse Path Forwarding (RPF) flooding rules" -- do I need to try harder? I’ve simply omitted flooding as it’s implied, I think. within one domain. While this approach solves the MSDP issues, it does not solve the problem of unauthorised sources sending traffic to ASM multicast groups; this security issue is one of biggest problems of interdomain multicast. Perhaps it's worth expanding on the security issue as including a substantial level of traffic amplification. (Or do I misunderstand the security issue?) The issue here is injection of spoofed traffic. I’m not sure it’s amplification in the sense used for say open DNS resolver amplification, as the receivers and links to receivers only see one copy of whatever is injected. Section 4.1 The more inclusive interpretation of this recommendation is that it also extends to deprecating use of ASM in the case where PIM is Are we claiming or disclaiming this "more inclusive interpretation"? The current wording feels ambiguous, and I don't think we should leave it that way. We discussed this previously in a WG meeting iirc and it was left that way as there was a feeling that within a single domain an operator can in practice do as they please, and the real focus is in deprecating inter-domain ASM. Section 4.2 support SSM (i.e., explicitly sending source-specific reports). The updated IPv6 Node Requirements RFC [I-D.ietf-6man-rfc6434-bis] states nit: the I-D reference is not yet an RFC, so it's not proper to refer to it as one; since it's only an informative reference we will not necessarily wait to publish this document until that one has an RFC number assigned, so I think this should be reworded. (Also, even if there was a new RFC number, "updated [...] RFC [RFCXXXX]" would still scan kind of strangely.) This is now RFC 8504, updated in the text. Section 4.3 The recommendation to use SSM for interdomain multicast means that applications should properly trigger the sending of IGMPv3/MLDv2 source-specific report messages. It should be noted, however, there is a wide range of applications today that only support ASM. In many cases this is due to application developers being unaware of the operational concerns of networks. This document serves to provide clear direction for application developers to support SSM. Without some discussion of the relative level of difficulty for applications tosupport SSM (to compare against the well-portrayed problems with network support for ASM), it would be fairly easy to misread this as network operators getting an IETF BCP to try to force applications to do what's easy for the network. I'm given to understand that's not actually the case here, as the changes in application software are fairly minor, and no one would expect existing applications to grow a way to announce multicast source addresses spontaneously, so a little more text might go a long way. I’ve added/changed to: "This document serves to provide clear direction for application developers who might currently only consider using ASM to instead support SSM, which only requires relatively minor changes for many applications, particularly those with single sources.” Section 4.4 While the WG discussions had consensus that best practices should be developed to explain when to use SSM in applications, e.g, when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used, it was agreed that documenting such practices are outside the scope of this document. It might be possible to rephrase this in terms of "the conclusions of the MBONED WG" or "the consensus of the MBONED WG"; the current phrasing feels a little informal to me, though I don't place much weight on my sentiment here. Now: "While the consensus of the MBONED WG discussions was that best practices should be developed to explain when to use SSM in applications, e.g, when ASM without (S,G) state in the network is better, or when dedicated service-discovery mechanisms should be used, the WG also agreed that documenting such practices are outside the scope of this document.” Section 4.6 A lot of this section feels somewhat speculative and leaves me uncertain what the BCP recommendations in this space are. In the case of existing ASM applications that cannot readily be ported to SSM, it may be possible to use some form of protocol mapping, i.e., to have a mechanism to translate a (*,G) join or leave to a (S,G) join or leave, for a specific source, S. The general nit: I think this would read better with fewer commas, i.e., "to translate a (*,G) join or leave to a (S,G) join or leave for a specific source S". Fixed. Section 4.9 it. This allows easy migration of ASM applications to SSM/PIM-SSM solely through application side development to handle source- nit: hyphenate "application-side". Fixed. signaling via IGMPv3/MLDv2 and using SSM addresses. No network Do the application developers also consider this work "easy"? ;) The word “easy” has been delated, but “simply” remains :) "This allows migration of ASM applications to SSM/PIM-SSM solely through application-side development to handle source-signaling via IGMPv3/MLDv2 and using SSM addresses." When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also result in the desired PIM-SSM (S,G) operations and bypass any RP procedures, but this is not standardized but depends on implementation and may require additional configuration in available products. [...] nit: this sentence is fairly long and convoluted; could it be reworded and/or split up into smaller pieces? Good suggestion. "When running PIM-SM, IGMPv3/MLDv2 (S,G) membership reports may also result in the desired PIM-SSM (S,G) operations and bypass any RP procedures. This is not standardized but depends on implementation and may require additional configuration in available products." Note that these migration recommendations do not include the considerations when or how to evolve those intradomain applications best served by ASM/Bidir-PIM from PIM-SM to Bidir-PIM. This may also be important but is outside the scope of this document. nit: is there a missing word ("for"/"about"/"on") after "considerations"? "Note that these migration recommendations do not include considerations on when or how to evolve” Accordingly, this document recommends that future work for general purpose interdomain IP multicast focus on SSM items listed in Section 4. nit: hyphenate "general-purpose". Done. Section 6 We could perhaps consider mentioning again the consequences of infrastructure assuming that SSM-range addresses are always used for SSM, such as during the transition period where applications migrating from ASM to SSM continue to use ASM-range addresses, as mentioned in Section 4.7. Changing the model for intradomain multicast to one where source discovery/state-propagation is not done by the network and is instead a responsibility of the application layer means that the applications are responsible for properly implementing such functionality. While it's true that we do want applications to not have bugs in general (and that would hopefully go without saying), we might want to discuss the scope of potential issues if applications get this wrong. Could application bugs (or bugs in host-level IGMPv3 or MLDv2 implementations) specific to SSM usage lead to any worse problems than just "application traffic doesn't flow", e.g., state exhaustion in the network? I’m not sure what text you’d like to see added, so as yet have not added any. This could be the subject of an additional draft providing more specific guidance for developers. Section 10.1 I'm not seeing any references to RFC 4610 that would qualify it as normative; if normative is indeed the proper status, perhaps additional citations are in order? Moved :) Many thanks, Tim
- [MBONED] Benjamin Kaduk's No Objection on draft-i… Benjamin Kaduk via Datatracker
- Re: [MBONED] Benjamin Kaduk's No Objection on dra… Tim Chown