Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt

Gyan Mishra <> Thu, 06 August 2020 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 48FEB3A10B2 for <>; Thu, 6 Aug 2020 02:41:49 -0700 (PDT)
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=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 5CwvOryptdr8 for <>; Thu, 6 Aug 2020 02:41:47 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5310B3A10B0 for <>; Thu, 6 Aug 2020 02:41:47 -0700 (PDT)
Received: by with SMTP id i129so6490878vsi.3 for <>; Thu, 06 Aug 2020 02:41:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RPIMF6MeS0Nh9D44SXe9NU8Kal7ZC6521k6WukOm9Rw=; b=N2RC5cMx1WNU6nOYpPG4iSpSqv7cwNIz77nt2Mu+jqv/lpTZva6vW3ZHOo/eUFZy7Q Um2NlgLu7pVRV9E+oph3Qju9N2eqNOFO5AbUy9Y+N3kqbZn/dgpMvDh04UrCDsdLMUO0 nNyZqM4Le7qaS2AXIbU5QC7FtGVWaC4EDRKHJPvotNQVjBatMn0VFEXnEn2GMGUSD/SH 6OgsDo+kq18vMzUT5tMs5/NxVtZ82TEHCwFeSOMYpUfKSZW8+u666D3NSn2b7Hn4QrLS oC1TC1taE7MopGTvXz0anSt9vaNJzXMzrRPM7pWqlWFXPZF+EKnok9+2HhNkXHSpFTco fd5w==
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=RPIMF6MeS0Nh9D44SXe9NU8Kal7ZC6521k6WukOm9Rw=; b=StzRCcecE5xd7j/ctJvFnr8izayMWn0sJC1x5AsNVWqDig9F2Pd4FMhnqa0VVzSUfs vbUzf5UM9kswhCKZntxB1q1MCTkUyhjSNCpCpbE0XV+qBZJOKr7oFyQpfJDu9YTTItTf sgJlbsY8gq025tXCp16IUGzhE7/rbcruv+DYWaJElwDhFIlmtoUQyr/fpYuU9UkVv45B c0o9vXwT1rLYsSjyjlTOKTX+ZlKMhEUno3dq7SSa6Fm1fudDmLovjgYKqOyFH9zHyApz 0hGY6mTyrTdDuR/4mVVFoDD8mH75VKjrUJFHVIsRJGNn+e1GfjbAXtQDrEt6XdT+i6+L aN8w==
X-Gm-Message-State: AOAM530sIPXQf+z8ViKRz2kKzyhHT2TYjKY8k/CE1xeiYRi/AWyjXoCW n1po0onLd2pKccOs+JRlwW6BjFw0uCA7K3k0vqg=
X-Google-Smtp-Source: ABdhPJyJm69TLVpjYxVGOLw2wHvMA2x1XePp2p73jLnd7r/bn4w6f7U+ISe+Cufg5xNTpbmKNVpOUJUTvRmBqtjSDHY=
X-Received: by 2002:a67:fbd1:: with SMTP id o17mr5183377vsr.19.1596706906241; Thu, 06 Aug 2020 02:41:46 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Gyan Mishra <>
Date: Thu, 6 Aug 2020 05:41:25 -0400
Message-ID: <>
To: Aijun Wang <>
Cc: Keyur Patel <>, Robert Raszuk <>, idr <>,
Content-Type: multipart/alternative; boundary="000000000000f4fc5205ac324b86"
Archived-At: <>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
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, 06 Aug 2020 09:41:49 -0000

Hi Aijun

I agree with Robert that you cannot filter by RD or you would drop all the
routes and filtering must be done by RT.  Also the issue with RT ORF filter
is as Robert mentioned that you may have the same prefix with two different
RTs which is common unique by RD and so the ORF would drop the prefixes.

I am not sure I understand what problem you are trying to solve that is not
already solved by RTC membership so that only RTs imported by the PE are
what is advertised by the RR.  That is most effective way of cutting down
the RT flooding that occurs in the RR to PE advertisement.  RT filtering is
enabled by Default on all PEs and only if the RT is imported on the PE are
the RTs accepted into the vpn rib. That works pretty well in cutting down
RT advertisements by the RR.

As Robert mentioned each VRF has a maximum prefix which is defined on the
PE RIBs per VRF and in general on most current or even hardware within the
last 10 years is a minimum 1M prefixes per VRF is pretty standard with most
vendors and platforms.  The vpn rib limit is much much higher on the higher
end platforms.

You draft talks about inter-as issues solved with RT-ORF.  So when PE-PE
inter-as option B by default all RTs are dropped due to default RT
filtering and only RTs that are accepted are those RTS that are explicitly
being imported on the PE ASBR.  There is an option for retain route-target
all that disabled the default RT filtering so that all VPN routes can be
accepted on the inter-as option B link.  However a RT filter can still be
applied to the retian-route-target all so that only pertinent RTs are
accepted inter domain.  That seems to work pretty well.

As far as inter-as option C, the PE-PE ASBRs do not maintain the VPN RIB.
BGP LU is enabled on the inter-as link for end to end LSP by importing the
loopback between ASs for the end to end LSPto be built.   The RRs between
the SPs have eBGP VPN IPv4 VPN IPV6 peer with next hop unchanged so the
data plane gets built between the PEs.  The RR by default does not have RT
filtering enabled by default as does the PE, so is able to reflect all the
vpn routes learned to all PEs within each AS.  In the inter-as scenario as
well RTC works very well with the RT membership to cut down on RR to PE vpn
route advertisements.

Kind Regards


On Wed, Aug 5, 2020 at 12:49 PM Aijun Wang <>

> Hi, Robert:
> Aijun Wang
> China Telecom
> On Aug 6, 2020, at 00:14, Robert Raszuk <> wrote:
> [WAJ] The VPN routes imported in these VRFs can’t use the same RD, or
>> else, the VPN prefixes in different VRFs will collision on RR.
> Nothing will "collide" on RRs.
> NLRI = RD+Prefix  not just the RD.
> [WAJ] The prefix part can be overlap in different VRF. If the RD is same,
> RD+Prefix will also be overlap.
> We must make sure different VRF use different RD to make the VPN prefixes
> unique within the domain.
> So you may have completely different prefixes sourced by the same VRF
> going to completely different VRFs on same or different PEs.
> [WAJ] This situation is for extraVPN communication, and should be designed
> carefully to avoid the address collision..
> If the address space in different VRF need to be considered in such
> manner, putting them in one VRF may be more straightforward.
> Kind regards,
> R.
> _______________________________________________
> Idr mailing list


*Gyan Mishra*

*Network Solutions A**rchitect *

*M 301 502-134713101 Columbia Pike *Silver Spring, MD