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 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA5533A113B for <>; Mon, 15 Feb 2021 02:53:21 -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 i0Q7bdQhoZ1z for <>; Mon, 15 Feb 2021 02:53:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5E89B3A113A for <>; Mon, 15 Feb 2021 02:53:17 -0800 (PST)
Received: by with SMTP id f1so9485199lfu.3 for <>; Mon, 15 Feb 2021 02:53:17 -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=+GdOgXN5oENR8JoBIyBpzqlbBk14/JMZdyBbUw2EmoE=; b=Rj9ymmMz+3MZLkdJFw7GPWQK1g5S03wmMCo7QhSas9DHZv/7IVPp9yBeGqhgeAdd1q 2t0sPXAkM7ZiHuVsXomE9ALlMWoKXf3Kg684icHMtIB2bBFiP40Sd/Bk6rJy8wZ7N7r2 MD3KmlSWM8/p+cnNNDzQq36n5ho353YvT3wFoB0GiaVQkhSbgKiR2rrGe1p6dsdWvf7+ F6lNoSxO1bj12bW9xe8FTxZbGi39+ZRYxI/XN9Fm64L20CFV/+FnvFfkGAkg7kz2QF9B B/nJWyCXpKSXA9yeQdUgIYKAjyi2JJyRguIOjUSyJ+qHzTWstRqWREt3MOH+zgN9WOGt vLhQ==
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=+GdOgXN5oENR8JoBIyBpzqlbBk14/JMZdyBbUw2EmoE=; b=DLuIimbG1071RVDKv1oJpGDcwLbL56lHvAvTDcT1Wxg572g80BRsKzqOTHJRlQMJGU r3By8/zGrpucItqSqZivQOZAt3BIqHpl5UyEqnCFIE6IKpLLWLq1/VIWpenuEPT3krae z1Aan3mNrU3u2dUcB2TIrw7ifQBdI+kCqh8QxXpg9ymiBO4P3MPLQhg9vrDEweLnmrBG 2hQi9B+URu8AROuW/Dig2wGjVg9Qdwg46woDiKyheXjKmnTtvFgVlIKQ+zIRnJLRCnyJ 1guVO9mqs8tf3dI61ORQ5iYslJVpHyjIN3fz9FKxqB/764tXZz26uLTyKAeOMI2c8hAd sScQ==
X-Gm-Message-State: AOAM530orsn9jEtI5W9/rOHMU1USAAXCPmNqpyb7w8xl6UPWFpwTBsaX 0KMYfBwdsDiesMs6QunOK9CnUS3OFHurDIB8qFOAgQ==
X-Google-Smtp-Source: ABdhPJz9+EXOPHmVncKo89QQ4KjpJXrtDXKZerPTFbiMYIPMmmcq8xySsAxdyEaABHCD6zCeRMuZmlZjOj+Q36u+9bE=
X-Received: by 2002:a19:df42:: with SMTP id q2mr1700842lfj.396.1613386395144; Mon, 15 Feb 2021 02:53:15 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Mon, 15 Feb 2021 11:53:09 +0100
Message-ID: <>
To: Aijun Wang <>
Cc: Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000f7e54d05bb5dca25"
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 10:53:22 -0000


> But it seems adding RT information can’t still solve the situation
> described in
> 3).
> 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.
> [WAJ] Yes, adding RT information within the current RD-ORF encoding can
> certainly increase the accuracy of the offending VPN routes.


> But in situations described in Figure 3, RD3/RT3 is same for VRF1/2/3. If
> only one of VRF reach the VPN prefixes limit, it should not influence
> otherVRF. In such situation, the RD-ORF message should still not be
> triggered by the PE device, even we use the RD/RT tuple.

Well this is first time I hear you saying that - but sure triggering
sending RD-RT filter would be a local decision anyway.

> don’t know why it selected new SAFI NLRI approach.
> Because ORF is NOT transitive. ORF has no concept of loop prevention.
> [WAJ] ORF is route policy to BGP neighbors. It should not be transitive.
> It does not announce the reachable information, nor the nexthop change, why
> to consider loop prevention?

I am talking about control plane loop not data plane loop.

> It *only* works p2p. Propagation of received ORF entries is something we
> should explicitly forbid in ORF spec.
> [WAJ] Yes. The p2p mode is fine for ORF message. No need to propagation.
> Every node should determine based on its own condition.

See you are again trying to propagate ORF.

This spec should make it as a MUST that such filter should be triggered
only upon import "overflow". That way RRs will not be by the spec able to
send such filters if you insist to put in ORF msg. See RRs do not know what
routes PEs are importing in terms of RD. So it would be bad to assume so
here as well. And for RT they know only if RTC is in use across 100%
of PE-RR sessions.

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
> progress.
> [WAJ] RTC is used to announce “what I want”, it has no mechanism to
> express “What I don’t want”, which the ORF mechanism jump in.
> Then, considering your suggestions, I think adding RT information to
> current RD-ORF encoding is the appropriate approach, instead of changing
> the concept/procedures of RTC.

No one is suggesting touching RTC SAFI 132. We are talking about new SAFI
which can just provide finer filtering in addition to RTC. It can be used
alone or with RTC - no issue either way.

But again this is all applicable only when there is a serious problem. So
far I have not seen much support in terms of operators outside of China
asking for this filtering regardless if this is in ORF or in new SAFI.