Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-01.txt
Jeffrey Haas <jhaas@pfrc.org> Mon, 04 November 2019 21:37 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 2643912002E; Mon, 4 Nov 2019 13:37:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 FWfIxFkJoDrX; Mon, 4 Nov 2019 13:37:29 -0800 (PST)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 264B0120041; Mon, 4 Nov 2019 13:37:29 -0800 (PST)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 27BBA1E2F7; Mon, 4 Nov 2019 16:41:10 -0500 (EST)
Date: Mon, 04 Nov 2019 16:41:09 -0500
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
Cc: john heasley <heas@shrubbery.net>, IDR <idr@ietf.org>, "draft-ietf-idr-deprecate-as-set-confed-set@ietf.org" <draft-ietf-idr-deprecate-as-set-confed-set@ietf.org>
Message-ID: <20191104214109.GC3277@pfrc.org>
References: <BN6PR09MB13317B7AD6F4229F5E00FDD284610@BN6PR09MB1331.namprd09.prod.outlook.com> <20191029213844.GC10145@pfrc.org> <BN6PR09MB13310C894E01C67E7E4DC761847F0@BN6PR09MB1331.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: <BN6PR09MB13310C894E01C67E7E4DC761847F0@BN6PR09MB1331.namprd09.prod.outlook.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VlD-LbLXrRLORlY9kr3qZ6PAYi8>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-01.txt
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: Mon, 04 Nov 2019 21:37:31 -0000
Sriram, On Mon, Nov 04, 2019 at 03:45:06AM +0000, Sriram, Kotikalapudi (Fed) wrote: > Agree with you except we need to have “MUST NOT” for > locally generated (initiated) updates with AS_SET. > And it is “SHOULD NOT” for receipt and forwarding as you suggest. > > I have tweaked the text (per your suggestion for the most part) > in the updated -02 draft as follows: > > “This document deprecates the AS_SET (type 1) AS_PATH segment type > from [RFC4271]. BGP speakers conforming to this document (i.e., > conformant BGP speakers) MUST NOT locally generate BGP UPDATE > messages containing AS_SET. Conformant BGP speakers SHOULD NOT send > BGP UPDATE messages containing AS_SET. Upon receipt of such > messages, conformant BGP speakers SHOULD use the "Treat-as-withdraw" > error handling behavior as per [RFC7606].” It will be interesting to see how the unruly mob who's demanding this draft treats the small amount of room this wording gives such a "deprecation". "SHOULD NOT" means "does occasionally". > > The implications: > > - You have to provide an entire revised section 9.1.4 for RFC 4271. > > This is no longer relevant given my response above. > However, section 9.1.4 says (in the last paragraph): > “If a BGP speaker chooses to aggregate, then it SHOULD either include > all ASes used to form the aggregate in an AS_SET, or add the > ATOMIC_AGGREGATE attribute to the route.” > We could recommend changing it to: > “If a BGP speaker chooses to aggregate, then it SHOULD > add the ATOMIC_AGGREGATE attribute to the route.” Minimally, that's necessary. I think we'll find that makes things more annoying than set elements at some point down the line. The motivation to remove sets is that origin validation gets difficult/impossible. You'll find most implementations don't have a way to test for atomic aggregate in policy at all. Why would you care? AA says "never deaggregate". At some place in the network, a given prefix may be encountered with and without AA set. In one of these cases, it used to be the case that the path was shortened from a calculated standpoint (this is a side effect of proxy aggregation - as-sets are length one for the whole set). And now they're differently comparable. This is an edge case. But once this thing ships as an RFC, I'll set a timer for the incoming request for a knob to deal with its consequences. > > > > Misc. open issue: > > - What do you do about "atomic aggregate?" > > - You're also deprecating appendix F.6 of RFC 4271 > > - You're modifying recommendations for appendix F.4 of RFC 4271. > > > > I think we don’t need to change anything about ATOMIC_AGGREGATE > for the purpose of this document. I'll wait on others to comment here. It's been my observation over nigh 20 years of BGP that even the inventor of the feature didn't fully understand what it did. And now, courtesy of removing sets, it'll be more mandated than before. > Yes, we can say “deprecate appendix F.6 of RFC 4271”. > We can say the same about F.4 “deprecate appendix F.4 of RFC 4271”. > F.4 is no longer relevant when AS_SET is deprecated. > > However, I think rather than get specific about such instances, > it better to have an overarching statement. So, the draft now includes > this statement in Section 4: > > “Wherever mentions of AS_SET or AS_CONFED_SET occur in [RFC4271] and > [RFC5065], appropriate modification or elimination of the text must > be made in future RFCs that would replace these RFCs, consistent with > the deprecation of AS_SET and AS_CONFED_SET.” You're making an intrustive change to RFC 4271. Handwaving details and leaving them up to generally clueless implementors to intuit was is meant here is not something we should ship. For my part, I'll strongly suggest to the chairs that we do not pass this document through WGLC without this dealt with. Too many of us spent too many cycles on RFC 4271 and the consequences of sloppy wording thereafter not to do so. [impacts of proxy aggregation] > Regarding your question “How do you do this”, here is my two cents worth. > I think if AS X is aggregating (without using AS_SET) P1/24 (from cust. A), > P2/24 (from cust. B), P3/24 (from cust. C) and P4/24 (from cust. D) to P/22, > then AS X will announce the P/22 aggregate to its transits and later peers > (while including ATOMIC_AGGREGATE attribute in the aggregate update), Implication for RPKI, it is the originating AS and is permitted in the ROA to originate such a shortened route. > but not to the customers. To do so, configuration related to the aggregation now must be pushed to the ASBR connections of the component routes. Previously, the set would obviate the need for this. You've changed the required operational model of such aggregation. > AS X will announce to each of the four customers, > only the more specific prefixes contributed by the other three customers. This point is correct, and should be documented, because it interacts with the operational model change above. We didn't have to filter the less specific to the providers, but we do now. That is likely to be a prefix filter. We need to ensure that the more specifics get propagated. That prefix filter has to be correctly specified vs. the filter on the less specific. (I.e. don't just reject >= /22 to the peers!) > In addition, RFC 4271 (sec. 9.1.4) says the following for all other ASes > (transits, peers, customers of peer, etc.) that receive the aggregate: > “In particular, a route that carries the > ATOMIC_AGGREGATE attribute MUST NOT be de-aggregated.” > > I don’t think we need to put text in the document regarding the above > since it seems to be adequately covered in RFC 4271. Your take? You also now have the fun of what happens when the route gets around to the back door of such an aggregated service provider. Simplified example: Internet --- Aggregating --- Customer | | +----------------------------+ The customer announces P1/24. Aggregating upstream, that peers with customer, generates P1/22, a less specific of the more specific P1/24. It announces it upstream to the Internet, and suppresses P1/24. The customer at some point receives P1/22. This covers their internal address space of P1/24. Previously, when AS_SETs were used, P1/22 would have been dropped by the Customer automatically as a loop. This no longer happens. It is a BCP that providers should filter routes that cover their address space. Filtering out P1/24 and longer is easy. What do they do about P1/22? What filtering construct says "this overlaps my /24?" You've created a new policy need, I think. * If the internal P1/24 reachability goes away, we may end up in temporary forwarding loops until the Internet converges. (Internal traffic heads toward the Internet via the /22 to eventually arrive back through the Aggregating ISP.) Alternatively we end up with some new need to filter outbound traffic for routes we know we announce. -- Jeff * There's a chance I'm missing the obvious here. Generally, my customers are more clever about using our policy than I am. :-) > > Sriram >
- [Idr] I-D Action: draft-ietf-idr-deprecate-as-set… internet-drafts
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Sriram, Kotikalapudi (Fed)
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Nick Hilliard
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Jeffrey Haas
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Alejandro Acosta
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Sander Steffann
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Sriram, Kotikalapudi (Fed)
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Jeffrey Haas
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… john heasley
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Jeffrey Haas
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… john heasley
- Re: [Idr] I-D Action: draft-ietf-idr-deprecate-as… Sriram, Kotikalapudi (Fed)