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

Robert Raszuk <> Mon, 15 February 2021 08:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DCFC3A0EB5 for <>; Mon, 15 Feb 2021 00:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[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 jZNqBs5NmhiL for <>; Mon, 15 Feb 2021 00:59:02 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 282B33A0E9F for <>; Mon, 15 Feb 2021 00:59:02 -0800 (PST)
Received: by with SMTP id v6so6804098ljh.9 for <>; Mon, 15 Feb 2021 00:59:02 -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=qkJPvpQ2zkgA+p7Yzn7RBCUeRsHtYjElFlAz+Ccv4BU=; b=Rm28a+jXgtceLWPB5vJ8ihiLD9J+RvpRBpaLof5wadMSe+TJtgY4XLNPgjHczn15uI m3Z2mGLsCO17/fG26CsCC5RrkkhSSXD/+1aTP/NOyOBG3W6MIWt04NEmDcPls6XYWQcP u33grBoSSVXSSKaNB9tb1r2KYF2iFXbIcA2wLnIJpcukHxsmORulat8ijSwR3Em2ybzp MLj6x0KmXTD1bAJGplZVBSxgj9rs0k/pbakebAePUvBZAIDM8c3D8uc5sRpWxNWngscw VNUNL0h5NzaD48+0XihoxV8tZqvUjK0BExmffGp6Nd0sIHdEKPxh5NCaLqiaRSjO4zEN LfZA==
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=qkJPvpQ2zkgA+p7Yzn7RBCUeRsHtYjElFlAz+Ccv4BU=; b=l5C4l0Ld1oLcxS3PO6LX14kr2soC8h3QsOdtPjrTP4sGg6fJIimc0nbrkkTEH5nqkn Up66rXoY53xgOcL5Vc1YgAw56+lPN4cL6wISg6gcqFRAYc9oDJ92IZc6SzykN1cpFwk0 YjW25KF3UQbxa29yZ/Fp6zk/yjOnZ1b3CD0Vr3q7BUl/jIvpjcFD9haRpA2UqC/74So6 vvas9vh/yjDmEmons8/URTxPRTW2hJfdLiDJMZ8ZlUaQ9B44Qo2fKXF+xc/qzDN+KCSr bMS1BZ4Gyw/VNZ7cuKNo53OOFRWu+z1wx2496Qs+bLKhCgw4UmOubRLEYKsPv4A+fqwa x9fA==
X-Gm-Message-State: AOAM531oG3ypco7DtWaj682OmLIOaT011lOGsQJkKLlZ8UrTa5wghyJB kbcLXygsp6impz4H/qBpOaV2hx3mHfzRZjii954ZcA==
X-Google-Smtp-Source: ABdhPJzUQVxtuCPnS4s31yEtMs1B7TzAWGAkQ190trmH3wHT41RSotR5pmSakOLkkxZYD28eZ4G0j1nX0ljYIgqZHwY=
X-Received: by 2002:a05:651c:206:: with SMTP id y6mr6467036ljn.54.1613379540164; Mon, 15 Feb 2021 00:59:00 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 15 Feb 2021 09:58:50 +0100
Message-ID: <>
To: Aijun Wang <>
Cc: Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000006131d705bb5c32ff"
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: Mon, 15 Feb 2021 08:59:05 -0000

> But it seems adding RT information can’t still solve the situation
described in

I am not sure what is yr definition of "solve" - but sending RD3_RT3 tuple
will be no worse then sending RD3 alone. And in many situations as I
illustrated before (hub and spoke case) will actually prevent
unreachability across VRFs.

> don’t know why it selected new SAFI NLRI approach.

Because ORF is NOT transitive. ORF has no concept of loop prevention. It
*only* works p2p. Propagation of received ORF entries is something we
should explicitly forbid in ORF spec. Maybe time for a -bis.
And the objective of RTC is to build a controlled distribution graph of
information across ASNs. That is why this draft did not


On Mon, Feb 15, 2021 at 3:09 AM Aijun Wang <>

> Hi, Robert:
> Thanks for your suggestions!
> But it seems adding RT information can’t still solve the situation
> described in
> 3). The overwhelmed PE need still the local determined behavior(which we
> will add more clear description for this part later) to trigger the RD-ORF.
> And, defining one new SAFI to enhance the RTC mechanism, won’t it confuse
> the deployment of both? Actually, I think the RTC solution(RFC4684) should
> be implemented also on ORF mechanism, don’t know why it selected new SAFI
> NLRI approach.
> Regarding to your worry for the regeneration of RD-ORF on RR/ASBR, I think
> we can consider it in another viewpoint: Treating RR/ASBR as the
> leader/proxy of its clients/neighbors, it should know the
> responsibilities/risks when it trigger the RD-ORF message to upstream
> neighbors (we need also describe more later on the determined behaviors of
> these devices later).
> And, using ORF mechanism can achieve the granular control effects( it is
> hop-by-hop action), contrary to the new SAFI solution, which will be
> advertised immediately to network wide?
> Anyway, we will try to incorporate your finer control suggestions in later
> design, for example, adding RT information to solve the situation that you
> mentioned before?
> Looking forward to more suggestions/consideration on the solution.
> Aijun Wang
> China Telecom
> On Feb 15, 2021, at 07:38, Robert Raszuk <> wrote:
> Hello Aijun,
> I have been re-thinking over a weekend this entire discussion.
> I think I have a suggestion for you which addresses my concerns and I
> believe also addresses yours (and your co-authors) requirements.
> As I said number of times I still suggest we do not send RD to filter.
> Instead we send tuple RD+RTs and only filter VPN routes on logical AND of
> all (all as there can be more then one RT importing given route
> therefore we need to include intersection of local import RTs and RTs
> carried with "offending" routes).
> And to make this easily transitive I recommend we just define a new SAFI
> for it. We can call it RTC+ or Enhanced RTC as examples. Syntax would be
> identical to RTC, semantics opposite. Today RTC defines RTs which PEs need.
> Here we would signal description of subset of those which are "excessive"
> to be dropped on the peer.
> Sending it with ORF say RDRT-ORD (while works p2p)  I do not buy this
> implicit regeneration hack say at RRs, RRs doing option C or ASBRs
> performing option B. So sending it in new SAFI IMHO would be much cleaner.
> Just a thought how we could perhaps move forward here.
> Kind regards,
> Robert
> On Sat, Feb 13, 2021 at 3:32 AM Aijun Wang <>
> wrote:
>> Hi, Susan:
>> Thanks for your suggestions. More responses from the operators are
>> welcome!
>> We think this mechanism can let the network cope with dynamically the
>> extraordinary scenarios for VPN routes advertisement, especially the
>> inter-AS Option B/C scenarios.
>> This can certainly encourage the widespread deployment of inter-AS option
>> B/C solution(especially for EVPN/VXLAN, EVPN/SRv6) increase the VPN
>> services coverage and revenue of the operators.
>> There may be some details procedures and device behaviors need to be
>> clarified further, but this is not unsolvable, considering there are so
>> many experts within IDR WG.
>> Thanks Robert, Jakob, Jim and Acee for the technical challenges to let
>> us/IDRer understand the solution more clearly.
>> Aijun Wang
>> China Telecom