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

Jeffrey Haas <jhaas@pfrc.org> Wed, 28 August 2024 01:13 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 26068C1CAE77 for <idr@ietfa.amsl.com>; Tue, 27 Aug 2024 18:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.014
X-Spam-Level:
X-Spam-Status: No, score=-1.014 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no 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 L7-qp0FcCMzE for <idr@ietfa.amsl.com>; Tue, 27 Aug 2024 18:13:37 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 366B4C151990 for <idr@ietf.org>; Tue, 27 Aug 2024 18:13:36 -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 15FF41E039; Tue, 27 Aug 2024 21:13:36 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-F70D7EE4-A9C0-427E-8433-83B16571AA8E"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (1.0)
From: Jeffrey Haas <jhaas@pfrc.org>
In-Reply-To: <SA1PR09MB8142F7CAE6A3A66F4C085F8784942@SA1PR09MB8142.namprd09.prod.outlook.com>
Date: Tue, 27 Aug 2024 21:13:25 -0400
Message-Id: <C1570A21-801B-4C62-AF01-89C29561F792@pfrc.org>
References: <SA1PR09MB8142F7CAE6A3A66F4C085F8784942@SA1PR09MB8142.namprd09.prod.outlook.com>
To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>
X-Mailer: iPhone Mail (21F90)
Message-ID-Hash: T2NSX3PFHPDS3UUS2DZKNHXGOWWLVJIK
X-Message-ID-Hash: T2NSX3PFHPDS3UUS2DZKNHXGOWWLVJIK
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/Y0OHbupIVX4kT1AOYTZoe3vCmrA>
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>

Sriram, 

I did notice. As I said, Sue asked for an explicit reply on the 4 byte AS considerations. 

We’re all good on the results. 

Jeff

On Aug 27, 2024, at 17:32, Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov> wrote:



Jeff,

 

Just in case you did not notice,  this thread was moved to the WG LC thread, and Claudio and I discussed this some there:

https://mailarchive.ietf.org/arch/msg/idr/vtdXncF2MrQgjLaViRuub2rG9zA/" rel="nofollow">https://mailarchive.ietf.org/arch/msg/idr/vtdXncF2MrQgjLaViRuub2rG9zA/

 

Anyway, as you’ve noted (below) all the authors have agreed to “Choice A” mentioned in the above thread and that will be reflected in the forthcoming v-16.  Claudio has said privately that he would go along if all the authored agreed on that.  

 

Sriram  

 

From: Jeffrey Haas <jhaas@pfrc.org>
Sent: Tuesday, August 27, 2024 4:39 PM
To: Claudio Jeker <cjeker@diehard.n-r-g.com>
Cc: idr@ietf.org
Subject: [Idr] Re: I-D Action: draft-ietf-idr-deprecate-as-set-confed-set-15.txt

 

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 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