Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)

Robert Raszuk <> Fri, 12 February 2021 11:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 237263A15A9 for <>; Fri, 12 Feb 2021 03:30:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.479
X-Spam-Status: No, score=-0.479 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, HTML_IMAGE_ONLY_24=1.618, HTML_IMAGE_RATIO_02=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NMy24Y-KDuE0 for <>; Fri, 12 Feb 2021 03:30:45 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58BF13A15A8 for <>; Fri, 12 Feb 2021 03:30:44 -0800 (PST)
Received: by with SMTP id v30so12254431lfq.6 for <>; Fri, 12 Feb 2021 03:30:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n/p0GJxxGpaVSVI6TjhLmO91BQghp2O8dlE230ijSuA=; b=PMTFfF0+PmkCJNt7niT3qJIGLPT2Gcw5vEPpvPC7psQsTAbHlMvk+QyiHrO7ZUUNp2 jlK1PFqg5zwPyXBESDFGTqZouSBIprdVDZFdz+Pd+xi6NAUpGFdPbg7nX58dzF7YPYHf 97Gm76PB3iEuRrQ1Z9+X5+csgoUoq0AYaArXDgHtO3BwlFeWwk2jXCG+MLBt6EXT8TQX tLa1bZ34oWVwA1+UCA1iJl6Of4U7J3yQxCfwRqFNY2YO2dNyaKDX7LYNDecTbY/yCRGA vvEmJP4ptaCFkHrEnhZ/K6bCXPjECyqnfUQU6homaf+h/uJVd//p8p9ns5Kg1b0huzbz w3+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n/p0GJxxGpaVSVI6TjhLmO91BQghp2O8dlE230ijSuA=; b=ps6gATXZTZeBQ2T2zwsm97D8gQaUugNYH+Lh0YolD7OqlgfWFfVmDioUy3s7GJ0+8j miBvO2fJQACEQru4f6Pj357XXFYnDtMumrs+xTKEvnb0rqpGEaj865uR3Brdk6x72Sv6 5TFYNex1+1Z/Cub27/s0PvsBHWhj2gbzy+fP4V3CzNHe8UTQ/e2JStCaw7m+I5JNEtsn HoiZ1SGxsuhCTfJHbv52k7dTHv4nXySPDss66WR+1dAQ4UmX7k4FRYvOZuFrQzuXUC0p 2uiYFdsabbBMcRl1Wqyf4p5P+lLLArDGDj0O9eig9FcpJvKgBIYU8rke8nZk96Yr75Dm oy+Q==
X-Gm-Message-State: AOAM531yxDEMKiJGXpIAiFyi2FBLMeE/lB0bc6PfmOPJ46ioi8DQU2JB Y5/CKl5RxytTQ0E0Rxd9LLZxj2K086r2/4sOB32krEP4oAMw0Z75
X-Google-Smtp-Source: ABdhPJy3Y8w0aVNgdy+YK9EWwu5KghCbz75c4BudZfqJYOoja7WXxrM1RP5DC2P9V4Iy1245abFbfp8uB48+b4deVBc=
X-Received: by 2002:ac2:5316:: with SMTP id c22mr1422557lfh.541.1613129436771; Fri, 12 Feb 2021 03:30:36 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 12 Feb 2021 12:30:27 +0100
Message-ID: <>
To: Gyan Mishra <>
Cc: Aijun Wang <>, "Jakob Heitz (jheitz)" <>, Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/related; boundary="0000000000000ec9ad05bb21f7cf"
Archived-At: <>
Subject: Re: [Idr] WG Adoption call for draft-wang-idr-rd-orf-05.txt (2/4/2021 to 2/18/2021)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2021 11:30:47 -0000

Aijun & Gyan,

Let me try one more (hopefully last time) to explain to both of you - and
for that matter to anyone how supported this adoption.

Let's consider very typical Hub and Spoke scenario as illustrated below:

[image: image.png]

HQ1 is advertising two routes:

- one default with RDX1 with RT TO_SPOKE
- one or more specifics with RDX1 to the other HUBs

Now imagine HQ1 bought a new BGP "Optimizer" and suddenly is starting to
advertise 100000 /32 routes just to the other HUB with RT: TO_HUB.

[image: image.png]

So PE2 detects this as VRF with RDX2 on it got overwhelmed during import
with RT TO_HUB and starts pushing RDX1 (original RD) to RR to stop getting
those routes.

Well all great except now you are throwing baby with the water as all
spokes attached to PE2 which just import default route to HUB HQ1 also can
no longer reach their hub site as their default route will be removed.
Therefor they will have nothing to import with RT:TO_SPOKE

Further if RR "independently" decided ... oh let's push this ORF to PE1
then all of the spokes attached to perhaps even much more powerful PE3 can
also no longer reach their headquarters.

- - -

*Summary: *

The above clearly illustrates why the proposed solution to use RD for
filtering is in fact harmful.

See when you design new protocol extensions the difficulty is to not break
any existing protocols and deployments.

Hope this puts this long thread to rest now.