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

Robert Raszuk <> Thu, 11 February 2021 09:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 983F03A13D2 for <>; Thu, 11 Feb 2021 01:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tS8p_yBMaPaZ for <>; Thu, 11 Feb 2021 01:19:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31E473A13F1 for <>; Thu, 11 Feb 2021 01:19:29 -0800 (PST)
Received: by with SMTP id a22so6481639ljp.10 for <>; Thu, 11 Feb 2021 01:19:28 -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=zYv7CvuGNSzw8YtQM6Gan72wX246fd1q0VYcX62TmG4=; b=HDz2md3DEa8ZJi7M4UUu2zM54tSjl2cW3YMhqdN0bWILiXqVwFU+wXJpiPwggvQtk8 acyshEyoQHq09PcjdmNmVfd6yiV+PV4nN0/vnldN1tGn4FVhucn4I4EI5cIyy2KRk95U u/tk0fsBwozzxFnAb/R4/50XLQEEV6KJzVdcy7o/42PPjwG6/KHdsMAYhdkPt2tBumcw 6cfcuzCKyRKKvWM16fYbCbpFk6aQiJo4u4tN90v4BvxIeSaq2VAXPRNh7BtzOI4gM2Hr 90ABPv4o5ijDNz5kF+u4/dNykKrOuhuGlCpakE7QTsiAUWXQ/3RlTWBzlhAqgVVPyJj5 98Zg==
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=zYv7CvuGNSzw8YtQM6Gan72wX246fd1q0VYcX62TmG4=; b=YY0TfXSOfuOVZRgkkduQJXz8HUChA+BnGwqDZFmthEUhTtztkywdcz+jgSgW3E7TQE N2rUWmHwzEkHv2lcBWqL21eJ+5FYM5d1FLiwoOB1B7cVG3mQW9SYY+4UHdc4F4G/BRn9 r/20i5dQ2OjorQmEytftskB4HcRGoFxrwZBM+mS6fGx8clgKGo/Yr17gwNJlEt99ooBi /SrjkNZHbMIZfZoviPQAcWgN7GxGekclFObj0maRpPjTBq9Fa+mkpVz5LvOQ8hqgJVPY AtXymfRU9w6776QecxYj8jpvWI81V7TQSRC2XG1KGhZRdhfDdajKLFaMYU4ZStB6SFd7 kB0A==
X-Gm-Message-State: AOAM532hS9VT5HIElnOVUr9Xp98xMneHCGThYW/PcKnM1nEksvoH7VFq zX6/DU1q+2OvUP96hfymt5+OJStvejwSdXOFAmuPPewKY/6iGQ==
X-Google-Smtp-Source: ABdhPJxai7FgQ+AW8GW8n9W+4QAXknX92jJnMJ7ea6ba05ZDMFiZr5FI3gh/TDexjMvGmv2tay7/kz0tpW1sHRAzbdU=
X-Received: by 2002:a2e:b80b:: with SMTP id u11mr4424033ljo.361.1613035167075; Thu, 11 Feb 2021 01:19:27 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 11 Feb 2021 10:19:16 +0100
Message-ID: <>
To: Aijun Wang <>
Cc: "Jakob Heitz (jheitz)" <>, Susan Hares <>, "idr@ietf. org" <>, "Acee Lindem (acee)" <>
Content-Type: multipart/alternative; boundary="00000000000024e87105bb0c0462"
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: Thu, 11 Feb 2021 09:19:32 -0000


> [WAJ] As Jim also mentioned, the redistribution between different VRFs is
> poor design and we should avoid it in first place.

What Jim pointed out is the scenario where your proposal misses to address.
I do not see there claim that vrf to vrf route propagation is a poor

But this is just to prove your proposal is incomplete to protect PE from
being overwhelmed with VPN routes. Even basic import to more then one VRF
every operator (example mgmt VRF) is using can not be addressed by your

Or, is the responses for Jakob addressing your concern?

No. Mechanism is defined if you want to break the VPN service use it.

*> The problem with maximum prefix is it is hard to set a limit on the
maximum due to resources statistical multiplexing that all PE-CE links  of
VPNs won’t flood simultaneously thus maximum prefix is either set very high
or not set at all.*

This point one needs to put things in perspective. If your capacity of PE
is 10 M VPN routes and your VPN is giving you 10 routes per site then even
if you set 100 max prefix to 100 no harm will happen. That is how max
prefix is deployed with proper warning threshold and then session drop as
last resort. The point is to protect from accidental mistakes - that's

> So if a PE VRF is overflowing we cannot filter prefixes based on RT for
the overflowing VRF as that would filter all routes.

If VRF is "overflowing" you apply vrf-limit feature which is completely
different then max-prefix on BGP sessions. You may even shut down such VRF
completely which would be way better then partially drop the routes in it.
See in IP networks partially broken reachability is much worse to
troubleshoot then completely broken. Just imagine hours of troubleshooting
when customer calling your NOC complains his app is not working when ping
and trace are perfectly fine. In most cases NOC will say it is application
issue Mr customer pls go home.

We really here in IETF should not be endorsing such completely broken
operational models.

Kind regards,