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 15:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C8873A171F for <>; Fri, 12 Feb 2021 07:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 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, T_SPF_TEMPERROR=0.01, 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 RF5SZVbSwP4w for <>; Fri, 12 Feb 2021 07:05:03 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 450813A17BA for <>; Fri, 12 Feb 2021 07:04:51 -0800 (PST)
Received: by with SMTP id v30so13203989lfq.6 for <>; Fri, 12 Feb 2021 07:04:51 -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=a+kiJord+o4LOdImx7zwWKyQnfAWmo5Or1r72h8SnGA=; b=Ylfr0kd9GFUlNR3UneUiq/7eLj7ehqgSoUfblSCbE4v+xBgWlH86n6i7LTsWMWsTlL APr8rjl76qvnsoHKMoL+h7ys9QNaGsTz+NCVi+ICTi6xWbAQTNjETfgtE3eJ+uIIdMz+ FHmvLfzMuqzIEEn+2QlUEXBOw1uU1g4xj1NWBgpraTUbyB8Vmj83gxTtSlwA8FLI8LyY K8OhlY8mB2W2Pqdr2Cr8RVt8vZKb7BrbosdSF+bBoM5hldbLOTnHMskvix44rVkX4qXf LdmJRheiobHv8PKgKdnAuatPKZElMa4YCCgGE1orXzreRRKCdey6Svt8isb9v04kDiv3 KjeQ==
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=a+kiJord+o4LOdImx7zwWKyQnfAWmo5Or1r72h8SnGA=; b=VSThk9OBYYHjbQ7tGTxw9biJ2m7Po64SrICrcnSO+1Z0SYXIDu4PVti5Rlfnu7ZEe2 rZbHqYDNfLZhZbXp62xINJJvIIbII4+RfkGUV2WFqv+grOvgduwav7erEeKmghtM6Crd YbEV3fYbrg28SDFTANbqSyRQ/pPmzKPwQK3Hs4NkX5tQIfXVjfZd4fdz86qW3MGgWsP8 wWZUbjZk5upFD2ICEbwsAhnFe+1u+3mmNtxS51GLd0twRsJH8njWr55bqJNYmRE9a742 ltDfQy0twfNEeFSuquMx6bKlffNOz1ylOv8UoUa45lHjBVQUcczie5Bfj1EftseXA/vs XJiA==
X-Gm-Message-State: AOAM532M5aXdw+vrJDH9yLsgNq8NB45TYFL7EZy3eCwjmeVQCZGw1JRW LOpazDRqnrcRpm5n9nq/2ttLJmXyMw4tjvBcGAGDDg==
X-Google-Smtp-Source: ABdhPJycMMjYa9PaPJxspvdtXBSREFIw/WWcW8kkIYs4g2kKzGxoID7zywvArZnhnKDL3r2pdaoz61LVLUmnYn34LvQ=
X-Received: by 2002:ac2:5316:: with SMTP id c22mr1909222lfh.541.1613142286965; Fri, 12 Feb 2021 07:04:46 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 12 Feb 2021 16:04:35 +0100
Message-ID: <>
To: Aijun Wang <>
Cc: Gyan Mishra <>, "Jakob Heitz (jheitz)" <>, Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000fcb78105bb24f491"
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 15:05:10 -0000

Sorry Aijun,

What you say is just handwaving. There is no room for it in any spec.

When code is written PE must deterministically behave so the RR or any
other network element.

Statements "decisions of PE2 to judge" are not acceptable in protocol

Just imagine that each PE does what it feels like in a distributed network
.... Same for BGP same for IGP etc ....

And all of this is not needed if on ingress between PE1 and HQ1 you apply
max prefix of 2 or even 100. It is also not needed if you enable  RTC to
send RT:TO_HUB from PE2 to RR.

But I understand - no matter what we say or how much we spend time to
explain why this idea is a bad idea you are still going to push this fwd.
Oh well ...   If I were you I would spend this time to redefine L3VPN such
that customer routes are never needed to be sent to SP core routers.


On Fri, Feb 12, 2021 at 3:47 PM Aijun Wang <>

> Hi, Robert:
> has
> described such situations, which will require the additional local
> decisions of PE2 to judge whether to send the RD-ORF message out.
> In your example, if only the HUB VRF exceed but the resources of PE2 is
> not exhausted, then the PE2 will not send the RD-ORF message. It may just
> discard the excessive 100000/32 routes.
> If the resources of PE2 is nearly exhausted, it must send the RD-ORF
> message out. Or else not only the Spoke VRF, but also other VPNs on this
> device can’t be used.
> Regarding to RR, it is the same principle: if RR can cope with such
> flooding, it need not send out RD-ORF to PE1. If RR can’t cope with, it
> must send out the RD-ORF message, or else not only the VPN that import RD
> X1 routes can’t work, but also other VPNs that don’t import RD x1 routes.
> RD-ORF mechanism just keep the influences as small as possible.
> Wish the above explanation can refresh your review of this draft.
> We are also hopeful to invite you join us to make RD-ORF mechanism more
> robust and meet the critical challenges.
> Aijun Wang
> China Telecom
> On Feb 12, 2021, at 19:30, Robert Raszuk <> wrote:
> 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.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.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.
> Thx,
> Robert