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

Robert Raszuk <robert@raszuk.net> Wed, 05 August 2020 15:35 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 114A73A0BA1 for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 08:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38aBKqeA0Y0P for <idr@ietfa.amsl.com>; Wed, 5 Aug 2020 08:35:13 -0700 (PDT)
Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7D43A0B98 for <idr@ietf.org>; Wed, 5 Aug 2020 08:35:13 -0700 (PDT)
Received: by mail-ej1-x635.google.com with SMTP id l4so46815865ejd.13 for <idr@ietf.org>; Wed, 05 Aug 2020 08:35:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=INzxAK67+5NbFzuYHdl6QROVEFWJ7GRMj+UD3Ddew1E=; b=NfQ4PeJoXH2oYV+Syeo37NK12ysd1ejJlBIOpmzSN94IL+5rxD4TMdqflTYq8slzID 2947N3YRNhgBhjpsFrah5sxMJZOpc4wBbkU6bQuBUrdJyAGSQOJFa98IQlvZO9gM6xRe cPC+WtXT5FI6sujGwg7U27+WVdiDoY29gGtwVdnS3vpgsJP70cq82J04mh6w5u8kkQNn VDssojb0VvpbncagQBuqRULqC2cjeZSgKrKXAYRL7iCJENBE/HB8Ezc9WiMU1nea9RkR LKerVY4EemzyrM4uSxqPIamIGwRzOsT4GJbUDXq7R/2X5/Tahd4Lbz/UIF70bwMh9SJU DvHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=INzxAK67+5NbFzuYHdl6QROVEFWJ7GRMj+UD3Ddew1E=; b=bQJCM+7QQf2FqKwQmwI22XXOTK9IdAAa7VkWrJgewoQl0TU5ilSh+Dqs1J0lFDnnMm Rws+2embYgj4dIxgo2LbnIbjFM6DUcSnZkP8XZvAM3n4bYI86sqNnq+UkGdnARAzvFPZ V3BBE1vgNsGoMOwakGjpSFOYbCqDy2yspCWeUv41Uf0oxjdWSvYcaSZ9BdH3vYmQ7NXb 2olcVae8eXVXhRC0Dhx0StMxFuTGwjasJAkzeWY5NhNSSaVjVrN1+eLo0QUvhJxuUfU/ aHyrT5UzEgagefuO+meF7chm/b4qpQyiZ/RhT3BVANCaa9q6hpvNaG/2zBMymIEOxWsN Tknw==
X-Gm-Message-State: AOAM532U1y/bZ98pWCjJdwttiwNovk9lpInAeN4J/J72nszTGEQ2Hwkz RyB8jBY+xe1K3MmeeAsrsWb1Whj8J2/f17RQVNq6xbsZ
X-Google-Smtp-Source: ABdhPJxpxs4GiedzvDXyzhB0w0J/VDZN1290QRMVVEw2CC88jKRrKRXQijt287KtS5J6NXG0L8Zm699QSfHdS/UdZp4=
X-Received: by 2002:a17:906:7104:: with SMTP id x4mr3929007ejj.417.1596641711697; Wed, 05 Aug 2020 08:35:11 -0700 (PDT)
MIME-Version: 1.0
References: <059401d66ad0$f96c3b50$ec44b1f0$@tsinghua.org.cn> <CAOj+MMHgwXNcGduKHXoQNsn_UJS9Kpz_kDcpXH_kAhpotDKWng@mail.gmail.com> <05d501d66afc$420efe30$c62cfa90$@tsinghua.org.cn>
In-Reply-To: <05d501d66afc$420efe30$c62cfa90$@tsinghua.org.cn>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 5 Aug 2020 17:35:01 +0200
Message-ID: <CAOj+MMFDwoJqNY0pXBQEffVMv9-JukKSAmqZ3qMYySMKKD=i+Q@mail.gmail.com>
To: Aijun Wang <wangaijun@tsinghua.org.cn>
Cc: Keyur Patel <keyur@arrcus.com>, idr <idr@ietf.org>, wangw36@chinatelecom.cn
Content-Type: multipart/alternative; boundary="0000000000000f480905ac231e15"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/x45mAg-1NJ9N_TYSHT4lrnhjzX4>
Subject: Re: [Idr] [Responses for the comments during the IETF108] New Version Notification for draft-wang-idr-rd-orf-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 15:35:15 -0000

Aijun,

*[WAJ] Route Import is based on RTs, but different VRFs on one PE will use
> different RDs(and also different import RTs). Then filter based on RD will
> not influence the route import in another VRF, especially within the same
> PE.*
>

That is incorrect.

When you filter VPNv4 routes based on the RD you are suppressing this route
say on remote PE or RR such that it will never arrive on the PE.

And please kindly observe that VPNv4 routes carry a lot of RTs attached. So
one VRF may import this route based on the RT1 and the other may import the
same route based on the presence of RT2.

That means that healthy VRF may no longer be able to import this route when
you suppress it upstream in spite of the fact that there is no problem with
overflow on a given VRF.

Your scheme could work if we would assume no extranets nor more then one RT
per VPNv4 route. But this is not the case in the specification nor in any
deployment I have seen or run.


For me this is showstopper - and pretty fatal one to use RD for filtering.
> We do import based on RTs and filtering should also be done based on the
> RTs.
>
> *[WAJ] RT can’t be uniquely to identify one specified VPN.*
>

It sure can. Just add one more RT to identify the VPN on export. You may
not even ever import that RT anywhere. It would be used just as a VPN-ID in
your network.


> My other serious concern is that end customer will in no one be notified
> about such RD-ORF filtering ... - that is frankly not acceptable to me or
> to any L3VPN or L2VPN customer. As comparison when you use prefix limit on
> the PE-CE customer's session goes down hence customer is alerted about the
> problem.
>
> See worst "solutions" are those which may cause silent failures. We should
> avoid those at all cost.
>
> *[WAJ] The RD-ORF message is initiated from the overflow PE.  The RR or
> the source of VPN overflow act based on the instruction from the applier.
> Then this is not silent failures.*
>

There is no such a thing like an overflow PE. PE has different RIBs usually
one per VRF. So ultimately the overflow is coming from a VRF. And as we
proven that is not possible to avoid based on the RD filtering without
affecting other VRFs.

It is a silent failure for customers as customers never see the RD-ORF.

I would be willing to state that it may be better to fail such overflown PE
other then trying to recover and keep it running on the clif by shaving of
VPN routes arrving to it. Either such PE needs replacement or operator
running such PE needs to update his resume.


> *[WAJ] RD-ORF just want to keep the disaster as small as possible, based
> on the parachutes **J*
>

We are here to avoid silent disasters. Or when it happens make a big enough
boom.

Thx,
R.