[Idr] Re: I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-15.txt

Jeffrey Haas <jhaas@pfrc.org> Tue, 27 August 2024 20:39 UTC

Return-Path: <jhaas@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 C6805C18DB98 for <idr@ietfa.amsl.com>; Tue, 27 Aug 2024 13:39:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c2d44JIbEDRr for <idr@ietfa.amsl.com>; Tue, 27 Aug 2024 13:39:27 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 85F61C18DBB9 for <idr@ietf.org>; Tue, 27 Aug 2024 13:39:27 -0700 (PDT)
Received: from smtpclient.apple (172-125-100-52.lightspeed.livnmi.sbcglobal.net [172.125.100.52]) by slice.pfrc.org (Postfix) with ESMTPSA id 8CE051E039; Tue, 27 Aug 2024 16:39:26 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_69C2D087-C7A7-42F5-8D26-45D850D3E412"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <ZsSaLa0WH8tGu5rY@diehard.n-r-g.com>
Date: Tue, 27 Aug 2024 16:39:26 -0400
Message-Id: <BDDB8EC7-9883-4769-AA8D-7E1DC3130A7F@pfrc.org>
References: <172409169774.1909130.7745685666245560135@dt-datatracker-6df4c9dcf5-t2x2k> <ZsSaLa0WH8tGu5rY@diehard.n-r-g.com>
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
X-Mailer: Apple Mail (2.3696.120.41.1.8)
Message-ID-Hash: 6LOOZD2BNTAWEFG372NBBAZLNEP6PRUV
X-Message-ID-Hash: 6LOOZD2BNTAWEFG372NBBAZLNEP6PRUV
X-MailFrom: jhaas@pfrc.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: idr@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Idr] Re: I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-15.txt
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0ZraSNHhMP7TegVJYU8sYx5e2tY>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Note: I'm speaking as a strongly opinionated member of the WG here rather than with my chair hat.  I'd normally just skip some of the commentary, but Sue explicitly requested it for the list.


> On Aug 20, 2024, at 9:29 AM, Claudio Jeker <cjeker@diehard.n-r-g.com> wrote:
> 
> On Mon, Aug 19, 2024 at 11:21:37AM -0700, internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> wrote:
>> Internet-Draft draft-ietf-idr-deprecate-as-set-confed-set-15.txt is now
>> available. It is a work item of the Inter-Domain Routing (IDR) WG of the IETF.
>> 
>>   Title:   Deprecation of AS_SET and AS_CONFED_SET in BGP
> 
> I had a look at this draft and think
> Section 3.1 Considerations for AS4_PATH needs to be adjusted.
> 
> 3.1.  Considerations for AS4_PATH
> 
>   [RFC6793] created support for four-octet AS numbers in BGP using the
>   optional transitive AS4_PATH attribute.  The mandatory AS_PATH
>   attribute is always present in a route [RFC4271], while the AS4_PATH
>   may or may not be present.  If both AS_PATH and AS4_PATH attributes
>   are present, an AS_SET present in one would also be necessarily
>   present in the other.  So, it is sufficient to perform the "treat-as-
>   withdraw" error handling as specified above using the AS_PATH alone.
> 
> I think this is incorrect. You can not assume anything about AS4_PATH. The
> only thing RFC6793 mandates is that aspath length of AS4_PATH is smaller
> or equal to the aspath length of AS_PATH.

I agree with your assessment here.  

I have long been of the opinion that the re-assembly rules for 4 byte ASes are a huge mess.

In a prior implementation, not at my current employer, my code was done in a way that attempted to reconcile the AS_PATH and the AS4_PATH.  In the absence of aggregation or confederations, normal operation of the protocol would normally suggest that the AS4_PATH should have contents that directly aligned with the AS_PATH.  Much of the time the AS4_PATH should directly line up with the trailing end of the AS_PATH.

4-byte private ASes that are touched by 2 byte speakers before "remove-private" is involved is an example where that may not happen.  It's a theoretically testable case, but the 4-byte private range was allocated after the 4-byte transition mechanism was defined.

There are also features that meddle inappropriately with the AS_PATH by removing ASes, or adding them.  There's no way to appropriately account for those.

The RFC 6793 procedures for confederations effectively mean that mixed deployment 2/4 with confederations isn't necessarily safe.  If your confederation member ASes are in the two byte space, it might work out fine.  Given there are data center BGP fabric practices relying on private 4-byte confederation ASes, again, good luck with that.

And relevant to the deprecate as-set/confed-set draft, the RFC 6793 procedures are sloppy with regard to handling of AS_SETs.  When there are misalignments with sets, but the lengths are such that the procedures permit you to reconstruct the path, you could end up with very peculiar outputs.

It's reasonable to assume that the outcome of the 4-byte transition mechanism is "try, don't try very hard, and worry about keeping the path length long enough that default route selection keeps this from getting too bad."

> 
> If a router sends you an AS_PATH without AS_SET and an AS4_PATH with AS_SET
> then the reconstruction will introduce an AS_SET. This is possible and
> since AS4_PATH is transitive you can not even assume it was your peer
> playing games with you.

This could happen in some flavors of "brief" aggregation.  The scenario being:
1. Aggregation happens, route has an AS_SET
2. Route enters a 2-byte-only domain, AS_PATH has transitional AS_SET
3. Route is further aggregated with brief.  AS_PATH now has only AS_SEQUENCE while AS4_PATH has an AS_SET

RFC 6793 §4.2.3 tries to hint at this mess when discussing the aggregator attribute by discussing when the aggregator values don't line up.

It then proceeds to further be a mess.  When the aggregator AS isn't AS_TRANS (which can happen still with an aggregating AS in the 2 byte space), you just blindly take the AS_PATH without reconstruction.  




> 
> So instead I would suggest what OpenBGPD does. By default reject AS4_PATH
> attributes that contain AS_SET and use "attribute discard" for them.

I don't think you mean that.  That would mean you're discarding the whole attribute.  Do you mean you ignore the set segment types?

> If the AS_PATH had a AS_SET as well then the prefix will be withdrawn
> anyway but if not then there will be no merge of this bad AS4_PATH.
> If the user explicitly allows AS_SET then skip the above.

The text included in the next rev of the deprecate document basically says "if sets are present in either type, treat as withdraw".

> 
> I hope that after deprecating AS_SET for good we will be able to deprecate
> old 2-byte ASnum sessions as well since the hoops introduced by RFC6793
> give me the heebie-jeebies.

Speaking for myself but nodding toward my chair hat, I don't know that we can ever do that.  You can proclaim all you want that "we'll never do 2 byte" but implementations will still need to deal with as4-path for time to come.

That said, as a vendor, I'm happy to support knobs that say "don't let peering come up unless 4-byte is negotiated".  Sadly, we have knobs that do the opposite.

-- Jeff