Return-Path: 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 ; 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 ; 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 ; 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 In-Reply-To: Date: Tue, 27 Aug 2024 16:39:26 -0400 Message-Id: References: <172409169774.1909130.7745685666245560135@dt-datatracker-6df4c9dcf5-t2x2k> To: Claudio Jeker 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: =?utf-8?q?=5BIdr=5D_Re=3A_I-D_Action=3A_draft-ietf-idr-deprecate-as-set-conf?= =?utf-8?q?ed-set-15=2Etxt?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_69C2D087-C7A7-42F5-8D26-45D850D3E412 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 = wrote: >=20 > 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. >>=20 >> Title: Deprecation of AS_SET and AS_CONFED_SET in BGP >=20 > I had a look at this draft and think > Section 3.1 Considerations for AS4_PATH needs to be adjusted. >=20 > 3.1. Considerations for AS4_PATH >=20 > [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. >=20 > 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. =20 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." >=20 > 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 =C2=A74.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. =20 >=20 > 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". >=20 > 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 --Apple-Mail=_69C2D087-C7A7-42F5-8D26-45D850D3E412 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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 =C2=A74.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

= --Apple-Mail=_69C2D087-C7A7-42F5-8D26-45D850D3E412--