Re: [pim] pim-dr-improvement wglc
"Holland, Jake" <jholland@akamai.com> Mon, 14 January 2019 22:08 UTC
Return-Path: <jholland@akamai.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECDD21313B4 for <pim@ietfa.amsl.com>; Mon, 14 Jan 2019 14:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.263
X-Spam-Level:
X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, KHOP_DYNAMIC=2, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 h8mWDWrnbA9y for <pim@ietfa.amsl.com>; Mon, 14 Jan 2019 14:08:03 -0800 (PST)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B331313AF for <pim@ietf.org>; Mon, 14 Jan 2019 14:08:03 -0800 (PST)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x0EM6twG003658; Mon, 14 Jan 2019 22:07:59 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=HE8Z9zvb3pqxXVFD9+gca9ajCD9pjyO+VPbPhQpxuWg=; b=J+VLNe0Gpe6ko/1QGYbBXlrT5F6GusDR/oQcfNBCc2xycdzSTNZW7Mt1ZsLvjennv1Ds MIsgwl67Y6hprxhKE2sg3frpdnRglWSSkcrCykR0I+DMSTz7sxZGwDuUih/rx+ioZT72 1b2+CYuW+mqo67H5i0wtUkx2W8OzrZIiOFXrREIW37hpBSel1VihHlvZmjQ0ljd1IdET xvGu+C0YDWiOklE9y8W1fWrE78a+bP6wmh4xe2KlSL4i3wVjvpzzel7BC7Ws+vgpJyrz dYTZztwwSVgR+eR5w1JOwlnWyE+8qmcYhAls7FDnj9+kt8cqhjlZVCed2E0vf+isdOR+ Kg==
Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2pybfhffkt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 22:07:59 +0000
Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x0EM3Jid031456; Mon, 14 Jan 2019 17:07:58 -0500
Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2pycf2sr3s-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 17:07:56 -0500
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 14 Jan 2019 16:07:47 -0600
Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1365.000; Mon, 14 Jan 2019 16:07:47 -0600
From: "Holland, Jake" <jholland@akamai.com>
To: Michael McBride <Michael.McBride@huawei.com>, "pim@ietf.org" <pim@ietf.org>
Thread-Topic: [pim] pim-dr-improvement wglc
Thread-Index: AQHUrFWUnxaci1JcSvGHpFPjgU4Abw==
Date: Mon, 14 Jan 2019 22:07:46 +0000
Message-ID: <942E4711-72D8-486F-8509-C3E4D74D96C1@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.14.0.181208
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.119.0]
Content-Type: multipart/alternative; boundary="_000_942E471172D8486F8509C3E4D74D96C1akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140169
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_12:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140170
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/bSXUZcbN60hTCfjE2x8mz_CaT7Q>
Subject: Re: [pim] pim-dr-improvement wglc
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2019 22:08:06 -0000
Hi, I think the extension is a good idea and that this doc gives a good explanation of how it works. However, I think there’s some issues that should be addressed before publication as a Standards Track RFC. Major issues: 1. The security considerations section seems too thin. (The complete contents of the section are “For general PIM Security Considerations.”) 1.a. I think there are some security implications because of the new stickiness in the DR election process. For instance, in https://tools.ietf.org/html/rfc5015#section-5.1.1 when describing what happens when a DR has been impersonated, it implies there’s a mitigation (“[The impersonated] node typically will be able to detect the anomaly and, possibly, restart a new election.”) But because the DR is more sticky with this new extension, I think the kind of temporary disruption would have a more permanent effect that the impersonated node could not mitigate. I might be wrong about that being actually more dangerous, but it worries me that there’s no mention of issues like these in the security considerations section. I think for this point, it might be enough to just say that the election process may be more vulnerable to temporary disruption because the DR election is more persistent, and that this increases the importance of using source authentication to avoid DoS from malicious activity. 1.b. I think this probably should mention that BFD security considerations are applicable also, or the considerations for whatever DR failure detection mechanism is used. 2. There should probably be a reference to BFD, and perhaps other fast failure detection mechanisms, if they’re recommended. More generally, it seems to me that the speed of DR failure detection is of critical importance in using this mechanism, so the one brief mention (which doesn't explain the pros and cons of faster detection or make any recommendations about technologies to use) seems like it skims past a key point without explaining it in depth. Minor/editorial issues: 1. In section 3.2, it probably should talk about the IP version in the PIM message, instead of IP version supported by the network. The way it’s written, it seems to make it impossible to run a dual-stacked network with 2 instances of PIM, but I don’t think that’s the intent. 2. Should the reference to 2328 be informative instead of normative? It seems like it’s only used as an example. 3. The IANA considerations section should follow the guidelines from RFC 8126 section 1.3 (exact name of the registry, for instance). It also seems useful to make 2 separate values, TBD1 and TBD2 instead of using TBD for both. 4. “SW” is not defined in the diagram in Figure 1. I think the 2 SW boxes are Layer 2 switches on the same LAN, but I’m not certain. 5. In section 4, I think "MUST not" in the last paragraph should have NOT capitalized? 6. I don't understand the meaning of "The treatment" as the title for section 4.5. 7. There are a lot of English language nits. I saw that Greg covered several of them, so I’ll just mention the ones I saw in sections he didn’t cover: section 1: “can be adjust to” -> “can be adjusted to” “Still, may multicast packets” – should this be “many” instead of “may”? “new comers” is one word (this appears several times in the doc) I’m not certain, but I think each time the word “Ethernet” is used, “LAN” was intended? “new comers which has a higher”: has->have ... (skipping sections Greg Mirsky covered) ... section 4.5: “are start to work on the same time” “when a new router start to work” -> starts to work “fails or manually adjustment” -> fails or is manually adjusted I had to stop early before finishing a catalogue of all the rest of the issues I could find, but because of the very high density of nits, I’ll suggest it might be a good idea to try using an English-language proofreading service that works with technical documents. This is not an endorsement, and I’ve never used their services, but as an example of the kind of service I mean, here’s one I found in a few moments with a search engine: https://www.proof-reading-service.com/ Thanks for this work, it seems like a useful extension. Best, Jake From: Michael McBride <Michael.McBride@huawei.com> Date: 2019-01-08 at 10:29 To: "pim@ietf.org" <pim@ietf.org> Subject: [pim] pim-dr-improvement wglc Happy New Year! Today begins a two week wglc for draft-ietf-pim-dr-improvement-06. In Bangkok, 4 people indicated that they had read the draft and each agreed it’s ready for wglc. Let’s please read the draft one more time and confirm, on this list, that it’s ready to be sent to iesg. https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-06<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dpim-2Ddr-2Dimprovement-2D06&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=bqnFROivDo_4iF8Z3R4DyNWKbbMeXr0LOgLnElT1Ook&m=fIcyCL8wIA2EPznG-rnydT8d8lxOTVQr2JCmbTZQlow&s=6J6K4ZX_93Ir466HVBf_fg7Kc669SUvwl-fLx0v0KN8&e=> thanks, mike
- [pim] pim-dr-improvement wglc Michael McBride
- Re: [pim] pim-dr-improvement wglc Greg Mirsky
- Re: [pim] pim-dr-improvement wglc Holland, Jake
- Re: [pim] pim-dr-improvement wglc Stig Venaas
- Re: [pim] pim-dr-improvement wglc zhang.zheng
- Re: [pim] pim-dr-improvement wglc zhang.zheng
- Re: [pim] pim-dr-improvement wglc zhang.zheng
- Re: [pim] pim-dr-improvement wglc Holland, Jake
- Re: [pim] pim-dr-improvement wglc zhang.zheng
- Re: [pim] pim-dr-improvement wglc Michael McBride
- Re: [pim] pim-dr-improvement wglc zhang.zheng
- Re: [pim] pim-dr-improvement wglc Stig Venaas
- Re: [pim] pim-dr-improvement wglc Greg Mirsky
- Re: [pim] pim-dr-improvement wglc Stig Venaas
- Re: [pim] pim-dr-improvement wglc zhang.zheng