Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
Jeffrey Haas <jhaas@pfrc.org> Wed, 31 March 2021 15:52 UTC
Return-Path: <jhaas@slice.pfrc.org>
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 833313A2CC2; Wed, 31 Mar 2021 08:52:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 IIBdSsjCwfA8; Wed, 31 Mar 2021 08:51:55 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 762113A2CBD; Wed, 31 Mar 2021 08:51:55 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 043B81E455; Wed, 31 Mar 2021 12:13:58 -0400 (EDT)
Date: Wed, 31 Mar 2021 12:13:58 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram=40nist.gov@dmarc.ietf.org>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf.org" <idr@ietf.org>, "grow@ietf.org" <grow@ietf.org>, "draft-heitz-idr-wklc@ietf.org" <draft-heitz-idr-wklc@ietf.org>
Message-ID: <20210331161358.GI24667@pfrc.org>
References: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <SA1PR09MB814269138AEE1567CEED703B847C9@SA1PR09MB8142.namprd09.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Pp4XT8OdIWIzoQrnONbLFf1_KIU>
Subject: Re: [Idr] Choice of Large vs. Extended Community for Route Leaks Solution
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 31 Mar 2021 15:52:01 -0000
Sriram, (Clearly I'm not Sue...) Extending the observation I've just made to Gyan, the headache you're going through is trying to avoid the work of creating a new attribute. A result of this is a lot of work trying to proscriptively change how people operate their networks for more general features. Extended communities have functionally behaved as more of a protocol control mechanism in their general history. They already have behaviors that permit them to be selectively transitive or non-transitive across ASes. Operationally, they MAY be stripped by policy, but sanitization practices for them are significantly less codified than RFC 1997 communities. You can thus just get a FCFS extended community from a transitive space TODAY and it'd probably do most of what you want. One of the beneficial properties that extended communities have is the transitivity is at least understood and well deployed. That said, there's still no guarantee that some operator may choose to just delete them all at an ASBR. A discussion I'd suggest is that we've had a need for a "BGP routing security" attribute where we can put these various proposals: - It's not a victim of existing community practices. - Policy might still interact with it, but the baseline maintenance expectations can be set for it. - It can be extensible so new components can be added incrementally. While I understand a motivation for putting this in communities is "faster deployment", take the other example from the life of large communities: when there's sufficient interest, the feature will show up pretty fast. -- Jeff (the best time to plant a tree is ten years ago. the second best time is now...) On Wed, Mar 31, 2021 at 02:56:58PM +0000, Sriram, Kotikalapudi (Fed) wrote: > Hi Sue, > > Thanks for the detailed thoughts you have shared on the IDR list about the WKLC draft and route leaks solution draft (while also responding to Brian’s post). > > At one point in the past, the route leaks solution needed 8 bytes of user data space to accommodate two ASNs but then there was a design change (more than a year ago) and the current draft [1] requires only 4 bytes of user data space (one ASN). So, it seems possible to use a Transitive Extended Community instead of WKLC. > > We (authors of the WKLC draft) can continue working on creating an IANA WKLC registry for the future but I think the route leaks solution draft can switch to using Transitive Extended Community. Especially, if that could help expedite the route leaks draft and its deployment? I would like to seek advice regarding that (I'm cc'ing GROW also here). > > One question is… even after IANA allocation of a Transitive Extended Community for route leaks, there may still be additional effort needed to get the operators to truly treat the EC as *transitive* so that it propagates at least a few hops. How do we accomplish that? Write a BCP in GROW strongly recommending operators to implement default policy to ensure transitivity? We would like to hear people's thoughts about that? > > Thank you. > > Sriram > > [1] Route leaks solution draft (in GROW): https://datatracker.ietf.org/doc/html/draft-ietf-grow-route-leak-detection-mitigation-04
- [Idr] Choice of Large vs. Extended Community for … Sriram, Kotikalapudi (Fed)
- Re: [Idr] Choice of Large vs. Extended Community … Jeffrey Haas
- Re: [Idr] Choice of Large vs. Extended Community … Sriram, Kotikalapudi (Fed)
- Re: [Idr] Choice of Large vs. Extended Community … Jakob Heitz (jheitz)
- Re: [Idr] Choice of Large vs. Extended Community … Jeffrey Haas
- Re: [Idr] Choice of Large vs. Extended Community … Jeffrey Haas
- Re: [Idr] Choice of Large vs. Extended Community … Brian Dickson
- Re: [Idr] [GROW] Choice of Large vs. Extended Com… Randy Bush
- Re: [Idr] [GROW] Choice of Large vs. Extended Com… Gyan Mishra
- Re: [Idr] [GROW] Choice of Large vs. Extended Com… Jeffrey Haas
- Re: [Idr] [GROW] Choice of Large vs. Extended Com… Jeffrey Haas
- Re: [Idr] Choice of Large vs. Extended Community … Sriram, Kotikalapudi (Fed)
- Re: [Idr] [GROW] Choice of Large vs. Extended Com… Brian Dickson
- Re: [Idr] Choice of Large vs. Extended Community … Sriram, Kotikalapudi (Fed)
- Re: [Idr] Choice of Large vs. Extended Community … Brian Dickson
- Re: [Idr] [GROW] Choice of Large vs. Extended Com… Job Snijders
- Re: [Idr] Choice of Large vs. Extended Community … Jakob Heitz (jheitz)
- Re: [Idr] Choice of Large vs. Extended Community … Sriram, Kotikalapudi (Fed)