Re: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review

Jeffrey Haas <jhaas@pfrc.org> Thu, 30 April 2020 11:23 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 E5FA63A0A06; Thu, 30 Apr 2020 04:23:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 3gmL_-1Lb7-l; Thu, 30 Apr 2020 04:23:35 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 36C683A0A02; Thu, 30 Apr 2020 04:23:27 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 71E071E2D6; Thu, 30 Apr 2020 07:30:34 -0400 (EDT)
Date: Thu, 30 Apr 2020 07:30:34 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "Dongjie (Jimmy)" <jie.dong@huawei.com>, "Kirill.Kasavchenko@netscout.com" <kirill.kasavchenko@netscout.com>, "jhaas@juniper.net" <jhaas@juniper.net>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "thomas.mangin@exa.net.uk" <thomas.mangin@exa.net.uk>, IDR List <idr@ietf.org>
Message-ID: <20200430113034.GG28692@pfrc.org>
References: <14293c9f9c2e41219a13f09adacb6289@huawei.com> <20200430024817.GE28692@pfrc.org> <CAMMESsygf77w4pZZEkXBuArYiCXHYmXjn8M3vSc4KDSHLAYHSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESsygf77w4pZZEkXBuArYiCXHYmXjn8M3vSc4KDSHLAYHSw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/t-3tIfwnOq24zXsB9XDJWEBzERQ>
Subject: Re: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review
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: Thu, 30 Apr 2020 11:23:37 -0000

Alvaro,

On Thu, Apr 30, 2020 at 04:14:16AM -0700, Alvaro Retana wrote:
> On April 29, 2020 at 10:41:32 PM, Jeffrey Haas wrote:
> > With regard to Juniper's implementation:
> > - In sections 4.2.1.1 and 4.2.1.2 for operators, we originate zeroes when
> > generating new NLRI in the reserved bits and we ignore them on receipt.
> > However, we also propagate what we are sent and use when we're not the
> > originator of that NLRI.
> 
> To make sure I understand: if 0s are not received, you ignore the
> value and process the NLRI.

At the risk of getting into further English ambiguity, we do not use the
contents of the fields but preserve them.

This detail is particularly important vs. BGP (or other protocol) features
since sometimes an implementation will discard the ignored value on
propagation.  It causes all sorts of interesting interop bugs. :-)

> Does this behavior also apply to §4.2.2.12 (Fragment)?

I'm personally unable to confirm that detail right now.  The full set of
code leaves BGP land and goes deep enough into our firewall implementation
that I can't follow it.

And that said, once I get an answer from the group one way or the other,
we'd be aiming for "ignore the MBZ fields".

A discussion point that was held across the 5575 endeavor is that we SHALL
find implementations that are not fully compliant with various details of
the draft.  This isn't because it's on purpose.  It's simply that we're
cleaning up a lot of edge cases and implementations will take time to come
into compliance.  This is a feature, not a bug of our process.

-- Jeff