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 87EB1C1D3DC4 for ; Wed, 19 Feb 2025 20:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 QF8Z7ErP65iA for ; Wed, 19 Feb 2025 20:00:12 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0867C15152E for ; Wed, 19 Feb 2025 20:00:12 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5ded368fcd9so656210a12.1 for ; Wed, 19 Feb 2025 20:00:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740024011; x=1740628811; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ap2wA/G+6i0QPhUrQ8JY6ar6OMCd3Ql7Wd3UHXZVxYk=; b=OtgJqobFKOnM1IWT6K0zJpznY9bFrV8hS8zREDx5LTmxd70CSeuspd6Uo/PT+zRGUL /L6V71m8z9e4bbn+pHZ5AlYCycRd1POvuLPOn1AgSLmm9Rclee+rny+VOU7SIOiI6CBP 4GFjlCUAFJe2gjPGeeJelrxg3AabRGYV0jPaSvUgqDN8Kv/F1AGB/1Pmny7kHIx/dsot KOoVY1KGoDmgESaxc7afWaUr5caGiKP+JgHYt9qmmMoSMgoCeXl1tD89zj0E1PeatzLb GzSC2JspyXMp8ww7Y8Ov1c4cdYbb/edNcX1oLx5rmuyvv4eYt8L87FQFaMaMtv6/AZDR cHVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740024011; x=1740628811; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ap2wA/G+6i0QPhUrQ8JY6ar6OMCd3Ql7Wd3UHXZVxYk=; b=oWgNb3gAvZ+MP19zGiJMYz2R+U+cmeFzJqLbfMxDjiwLngOPjQHaZ3W85FONv532CC cFXRqynGHJH6VqFRy7fOL6jQnac0whmYzTsvp64dRxX5hDsCKdfNoVx6Dq3GY5+0Bq0m M7C2Xnbbe3cX9q32YoMwqemP26bYXj6Gav1v/DfVz/6lkpifJ/LVZEc4LESx/0rTts94 kvKBSpc5orBHeHAR8kcdNJwO6n61yD7RMrVK+dUqa4E0A/IGoCg7Ho+1c4VBqiVezaYN LyzTDIg2uHXO/mfjAXSDm4/pl8sv+30ZxErq+AXKr1pmvBYkbemJ0BCPMpjKsFHgTCJo ayTA== X-Gm-Message-State: AOJu0Yx5kQiTHe4Zuunez6mBMnT6EI8XJDpeFnB5GTk3bYDzKvegmn0S Zl844GHw3T+XoNNuCzHPlO3XGgKbJjKAlxw2/LKITUnCF70KPUu/UGaUCZwStfZm4oM3fXEvf9j uWaxEmSz8V/35AiQGhiKs3ufgFlX4dVjn X-Gm-Gg: ASbGncuK4bQ8TjFsGGkDGNCoEtfBfb5Z/utaxpjvheGIRfRzh7bz+uFdbGQs+eH5Iiw bF7fbArUUYsCELY/SAyWOWCOx5x03thPATB7Yu96oP8G7MyeKaTtXaAc40pbn1LpaZ4C3ZQ== X-Google-Smtp-Source: AGHT+IGWbpWy5V0glKs6+HrkBfeKzGuT7qJIpG4NDxojZvLEt1b7T29B803O2ycs/JBCxWawB1+hyu9gtPP5UCmDQ4U= X-Received: by 2002:a05:6402:270e:b0:5e0:348a:e33c with SMTP id 4fb4d7f45d1cf-5e089521fbamr6449757a12.10.1740024011038; Wed, 19 Feb 2025 20:00:11 -0800 (PST) MIME-Version: 1.0 References: <173996357889.1802420.6482667855998210569@dt-datatracker-75c44cbbdf-pxnd6> In-Reply-To: From: Nat Kao Date: Thu, 20 Feb 2025 11:59:34 +0800 X-Gm-Features: AWEUYZnA4wEfMBzJxGloWYGRoLcVM0vAhYyenpAeaxBHF_n15yRdpWoIoh3Ilkc Message-ID: To: Robert Raszuk Content-Type: multipart/alternative; boundary="000000000000142a07062e8ae9e1" Message-ID-Hash: TQ5E3TTSXWMOIOWCA5OAIXYBVGYZGBNV X-Message-ID-Hash: TQ5E3TTSXWMOIOWCA5OAIXYBVGYZGBNV X-MailFrom: pyxislx@gmail.com 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.9rc6 Precedence: list Subject: =?utf-8?q?=5BIdr=5D_Re=3A_I-D_Action=3A_draft-kao-idr-bitwise-ip-filters-00?= =?utf-8?q?=2Etxt?= List-Id: Inter-Domain Routing Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000142a07062e8ae9e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Robert. Firstly, many thanks for your interest in this draft! On Wed, Feb 19, 2025 at 10:11=E2=80=AFPM Robert Raszuk = wrote: > Hello Nat, > > Would you be so kind and describe why matching on selective bits of src o= r > dst address in the packets is needed ? > > As opposed to matching on all bits from or to a given position in the > address ? > > What is the application which benefits from selective bit matches ? > > The primary use case of these filters is to match 1/Nth fraction of the traffic from or to a specific prefix, provided traffic is distributed almost uniformly among different combinations of the log(N) least significant bits. This assumption holds in most cases in a carrier, so we can match (almost) 1/Nth fraction of traffic uniformly in both directions using the bitwise filter that matches the prefix with a specific combination of log(N) LSBs and then put the matched traffic to the same service instance. Therefore, the bitwise matching filters allow us to symmetrically distribute traffic almost uniformly between N service instances in only N rules. AFAIK we cannot match only log(N) least significant bits using the IPv4 filters defined in FSv2-basic-ip or RFC8955 since the filter defined is . We can match either log(N) least significant bits or the IPv6 Prefix using the IPv6 filters defined in RFC8956, but not both. On the other hand, traffic is usually distributed non-uniformly between different prefixes. If we're trying to load-balance with filters matching contiguous bits since the (almost) uniform distribution assumption does not hold, we need to monitor the traffic of each prefix we can match in real time to load-balance traffic. This approach adds complexity and management costs. > Your draft describes the mechanics and encoding, but I can not find the > use case and real network applications for such selective bit maching. Th= e > first two paragraphs in the Introduction section IMO do not glue well to > the rest of the draft. > > Thanks for your comments. I'll try to improve that in the next version. > Many thx, > Robert > Many Thanks! Nat > > ---------- Forwarded message --------- > From: > Date: Wed, Feb 19, 2025 at 12:13=E2=80=AFPM > Subject: I-D Action: draft-kao-idr-bitwise-ip-filters-00.txt > To: > > > Internet-Draft draft-kao-idr-bitwise-ip-filters-00.txt is now available. > > Title: Bitwise IP Filters for BGP FlowSpec > Author: Nat Kao > Name: draft-kao-idr-bitwise-ip-filters-00.txt > Pages: 12 > Dates: 2025-02-19 > > Abstract: > > This draft introduces the bitwise matching filters for source or > destination IPv4/IPv6 address fields. These filters enhance the > functionalities of the BGP Flow Specification framework and aid > scenarios involving symmetric traffic load balancing. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-kao-idr-bitwise-ip-filters/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-kao-idr-bitwise-ip-filters-00.html > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > I-D-Announce mailing list -- i-d-announce@ietf.org > To unsubscribe send an email to i-d-announce-leave@ietf.org > --000000000000142a07062e8ae9e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Robert.

Firstly, many thanks f= or your interest in this draft!

On Wed, Feb 19, 2025 a= t 10:11=E2=80=AFPM Robert Raszuk <r= obert@raszuk.net> wrote:
Hello Nat,

Would you=C2= =A0be so kind and describe why matching on selective bits of src or dst add= ress in the packets is needed ?=C2=A0

As opposed t= o matching on all bits from or to a given position in the address ?=C2=A0

What is the application which benefits from selecti= ve=C2=A0bit=C2=A0matches ?=C2=A0

The primary use case of these filters is to match 1/Nth fraction of the t= raffic from or to a specific prefix, provided traffic is distributed almost= uniformly among different combinations of the log(N) least significant bit= s.
This assumption holds in most cases in a carrier, so we can match (al= most) 1/Nth fraction of traffic uniformly in both directions using the bitw= ise filter that matches the prefix with a specific combination of log(N) LS= Bs and then put the matched traffic to the same service instance.
Theref= ore, the bitwise matching filters allow us to symmetrically distribute traf= fic almost uniformly between N service instances in only N rules.
AFAIK = we cannot match only log(N) least significant bits using the IPv4 filters d= efined in FSv2-basic-ip or RFC8955 since the filter defined is <Prefix, = Prefix-Length>.
We can match either log(N) least significant bits or = the IPv6 Prefix using the IPv6 filters defined in RFC8956, but not both.

On the other hand, traffic is usually distributed non-uni= formly between different prefixes.
If we're trying to load-balance w= ith filters matching contiguous bits since the (almost) uniform distributio= n assumption does not hold, we need to monitor the traffic of each prefix w= e can match in real time to load-balance traffic.
This approach add= s complexity and management costs.
=C2=A0
Your draf= t describes=C2=A0the mechanics and encoding, but I can not find the use cas= e and real network applications for such selective bit maching. The first t= wo paragraphs in the Introduction section IMO do not glue well to the rest = of the draft.=C2=A0

Thanks for = your comments.
I'll try to improve that in the next version.<= /div>
=C2=A0
Many thx,
Robert
=C2=A0
Many Thanks!
Nat=C2=A0

---------- Forward= ed message ---------
From: <internet-drafts@ietf.org>
Date: Wed, Feb 19, 2025 at 12:13=E2=80=AFPM
Subject: I-D Action:= draft-kao-idr-bitwise-ip-filters-00.txt
To: <i-d-announce@ietf.org>


Internet-Draft draft-kao-idr-bitwise-ip-filters-00.txt is now avai= lable.

=C2=A0 =C2=A0Title:=C2=A0 =C2=A0Bitwise IP Filters for BGP FlowSpec
=C2=A0 =C2=A0Author:=C2=A0 Nat Kao
=C2=A0 =C2=A0Name:=C2=A0 =C2=A0 draft-kao-idr-bitwise-ip-filters-00.txt
=C2=A0 =C2=A0Pages:=C2=A0 =C2=A012
=C2=A0 =C2=A0Dates:=C2=A0 =C2=A02025-02-19

Abstract:

=C2=A0 =C2=A0This draft introduces the bitwise matching filters for source = or
=C2=A0 =C2=A0destination IPv4/IPv6 address fields.=C2=A0 These filters enha= nce the
=C2=A0 =C2=A0functionalities of the BGP Flow Specification framework and ai= d
=C2=A0 =C2=A0scenarios involving symmetric traffic load balancing.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/d= raft-kao-idr-bitwise-ip-filters/

There is also an HTML version available at:
https://www.ietf.org/archive= /id/draft-kao-idr-bitwise-ip-filters-00.html

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


_______________________________________________
I-D-Announce mailing list -- i-d-announce@ietf.org
To unsubscribe send an email to i-d-announce-leave@ietf.org
--000000000000142a07062e8ae9e1--