Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
Job Snijders <job@ntt.net> Mon, 12 December 2016 19:12 UTC
Return-Path: <job@ntt.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C893512961C; Mon, 12 Dec 2016 11:12:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.831
X-Spam-Level:
X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
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 8AP_SDEN8F5n; Mon, 12 Dec 2016 11:12:03 -0800 (PST)
Received: from mail3.dllstx09.us.to.gin.ntt.net (mail3.dllstx09.us.to.gin.ntt.net [IPv6:2001:418:3ff:5::26]) (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 D85FB12949F; Mon, 12 Dec 2016 11:12:03 -0800 (PST)
Received: by mail3.dllstx09.us.to.gin.ntt.net with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <job@ntt.net>) id 1cGW14-0002Qc-4C (job@us.ntt.net); Mon, 12 Dec 2016 19:12:03 +0000
Date: Mon, 12 Dec 2016 20:11:59 +0100
From: Job Snijders <job@ntt.net>
To: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <20161212191159.GF75593@Vurt.local>
References: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <07906876-6e21-2df9-c7a0-1270e76fea4e@nostrum.com>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xCwocmynIf2-dLOw-6_Uqm42uN4>
Cc: idr@ietf.org, General Area Review Team <gen-art@ietf.org>, draft-ietf-idr-large-community.all@ietf.org, ietf@ietf.org
Subject: Re: [Idr] Genart LC review: draft-ietf-idr-large-community-11
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2016 19:12:06 -0000
Dear Robert, On Mon, Dec 12, 2016 at 12:43:33PM -0600, Robert Sparks wrote: > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed by > the IESG for the IETF Chair. Please treat these comments just like > any other last call comments. Thank you for taking the time to review this document! > Document: draft-ietf-idr-large-community-11 > Reviewer: Robert Sparks > Review Date: 12 Dec 2016 > IETF LC End Date: 16 Dec 2016 > IESG Telechat date: 5 Jan 2017 > > Summary: Ready with nits > > First a question (I don't know if this should lead to a change in the > document). You say the use of reserved ASNs is NOT RECOMMENDED and > later that the attribute MUST NOT be considered malformed if it has a > reserved ASN in it. Is it clear what a recipient is supposed to do if > one of these reserved ANSs shows up here? If so (for my own education) > could you point me to where that's described? If two ASNs agree to exchange Large Communities with each other where the mutually agreed upon Global Administrator value happens to be a reserved ASN, that is something for those two networks to decide. The key point here is that implementations must not impose any restrictions on the uint32 value in the Global Administrator field. It is entirely at the operator's discretion what to do with any Large Community, this applies to reserved and non-reserved values. The document recommends people to use their globally unique ASN, but this will not be enforced through implementations. The security section refers to "Network administrators should note the recommendations in Section 11 of BGP Operations and Security [RFC7454]." There is some wisdom there to be gleaned. > Nits: > > Section 11.3 in the references is only referenced by the implementation > status section which you instruct the rfc-editor to delete. Do you intend > for the reference to also be deleted? If so, save yourself a round-trip with > the RFC-editor and add instructions now. If not, you'll need to find a way > to work a reference in that won't be deleted. Yes, the intention is that the reference to RFC7942 is to be deleted before publication. This is my mistake: I mistook the hyperlink in https://tools.ietf.org/html/rfc7942#section-2.1 to be a reference, but its just an automagically converted hyperlink. We'll remove the reference in the next version. > David Farmer makes a suggestion at > https://mailarchive.ietf.org/arch/msg/idr/wHOtQfblIiTPqqXsgcGHZOfMQ_s that > looks reasonable to me. Please consider it. I do not believe there is consensus at this moment to make a blanket recommendation based on the contents of the registry (whatever they may be in the future), but rather work with the precise and concise approach which is currently described. Jakob Heitz responded to the suggestion to extend the reserved Global Administrator values, but for some reason I can't find that email in the IETF IDR archive, I've copy+pasted it here: ------------- Date: Mon, 05 Dec 2016 03:16:52 +0100 From: "Jakob Heitz (jheitz)" <jheitz@cisco.com> To: David Freedman <david.freedman@uk.clara.net> Cc: "idr@ietf.org" <idr@ietf.org> Subject: Re: [Idr] New Version Notification for draft-ietf-idr-large-community-11.txt No new text is required to cover this: 23456 is not an ASN. Besides, if anyone were to put it into a large community, no harm would be done other than what would happen if any other unassigned ASN were used. About reserving values, we don't reserve values because the values are unusable, but because we may want to use them for other purposes later. There is no need to reserve another value. 3 is more than enough. Thanks, Jakob. -------------- In addition to the above, although the document does not define any Special-Use BGP Large Communities, the Global Administrator values specified in Section 2 (0, 65535, 4294967295) could be used if there is a future need for them. The purpose of recommending that these values are not to be used is not because there is harm in doing so, but to leave the door open for future things (should they ever arise). From this perspective a blanket reservation based on the ASN registry wouldn't make sense for me. > The security consideration section start out with a sentence that > strongly implies the reader might learn something about the security > considerations for this document by reading RFC1997. That document's > security considerations section says only that "Security issues are > not discussed in this memo." The reference to RFC 1997 was meant to leverage 20 years of experience with implementing and operating networks which use RFC 1997 communities. I agree that the security section of RFC 1997 is somewhat sparse, but the principle still applies: RFC 1997 and Large Communities have similar security implications, even if they are not properly documented in RFC 1997. > I suggest simply deleting this first sentence. Please also consider if > there are other BGP documents with substantive security considerations > sections that you can point to instead. A reference to RFC 7454 is included, I am not aware of other specific resources that can be pointed at. Kind regards, Job
- [Idr] Genart LC review: draft-ietf-idr-large-comm… Robert Sparks
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Job Snijders
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Robert Sparks
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jakob Heitz (jheitz)
- Re: [Idr] One question about "Terminal Action bit… Christoph Loibl
- [Idr] One question about "Terminal Action bit" in… zhang.zheng
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Robert Sparks
- Re: [Idr] One question about "Terminal Action bit… zhang.zheng
- Re: [Idr] One question about "Terminal Action bit… Robert Raszuk
- Re: [Idr] One question about "Terminal Action bit… zhang.zheng
- Re: [Idr] Genart LC review: draft-ietf-idr-large-… Jari Arkko