Re: [Idr] Poll on the RFC5575bis implementations about the suggested changes during IETF review
Alvaro Retana <aretana.ietf@gmail.com> Thu, 30 April 2020 11:14 UTC
Return-Path: <aretana.ietf@gmail.com>
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 A05453A09D9; Thu, 30 Apr 2020 04:14:20 -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, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Ojk28hXI4g5C; Thu, 30 Apr 2020 04:14:19 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 7EE563A09D8; Thu, 30 Apr 2020 04:14:18 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id x25so1393600wmc.0; Thu, 30 Apr 2020 04:14:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=QBvICIvudjIapJMF7w2M2fb2JiBF+Unhv1od5sx0l48=; b=ramHJLFkJq2Pys7XMwLbV1LFliO4PKsaKEBb2/bP5KKI1J6PUqUiV8w2PuQUtkXyCP ZY38JAZAFhqvASEzjwO8xDNFrQ1xjAsH73TrM903I/raZ8zakZZMELqkKcpNYwMdIltd xUN6oDPo1L71qUFN6s/3E46hn1n9808dZLu4ION3ObR4N8iDbEsHR3c1enSGzVwgy7Wh juQMUww44gNsitqW4F/6QnuzlTid2ce6zRUiDLdwDTatJjS0mpkDqFoQ06EHkEHGtrNm z4tCm5w41rrWr1T4c7FOAOFGT5GkWtD+xhoXIJmxDPu6o/q6XN1+qz3vznuVWxFVtk5O gaxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=QBvICIvudjIapJMF7w2M2fb2JiBF+Unhv1od5sx0l48=; b=PSfoD53zfMbL7HaGA++bhJhzp4gb1llTeyWUBUPDKf3V155iUR98ve3fBZh1fD9jmG kKCjFz5KHYtpp0h/qNiVWPkoPmA2LgJPEohzktRfDorcwCktGJ2SJUbuoOZVka0+22o6 /VwZ7mASUo92yJ33M0jJYz8/7PhuTgu9WuBqSOJ1epeSuPhH4ctK/kW83Y564gpvWNLJ N/GAaw6Vui3d+4gKsVJiTqCTM+ivV27I+xP1VCFPZJXVuWa8HVno1vSDXLWzR6m8oWoI XmbK3JVOWK99d+UGhR5TuUKARskNlw6Q3s5vUEoDXBWQM5Y82hf8yTmJNqF1wXKrt9fF ulGg==
X-Gm-Message-State: AGi0Pub4LPG93tosFe09W9SnnX+Ceaz/1oKOCfU0HH2RpwAqirUR0kBt Dcmpd69SKq65WxlsNjtHXkanHEG24L4MM/am8Oo=
X-Google-Smtp-Source: APiQypLmyiA1JNNTaRbN8zI9mQTfg9NuKfOmHm2lB0tiygeLWn4jAD3u6Xn5gUCY+uPoWR4HsBxhAo/GtGkhlc+Nfx0=
X-Received: by 2002:a05:600c:1:: with SMTP id g1mr2386460wmc.142.1588245257057; Thu, 30 Apr 2020 04:14:17 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 30 Apr 2020 04:14:16 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <20200430024817.GE28692@pfrc.org>
References: <14293c9f9c2e41219a13f09adacb6289@huawei.com> <20200430024817.GE28692@pfrc.org>
MIME-Version: 1.0
Date: Thu, 30 Apr 2020 04:14:16 -0700
Message-ID: <CAMMESsygf77w4pZZEkXBuArYiCXHYmXjn8M3vSc4KDSHLAYHSw@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "Dongjie (Jimmy)" <jie.dong@huawei.com>
Cc: "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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Qf2BfMQaMFwVivs2carQTYhtmFE>
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:14:21 -0000
On April 29, 2020 at 10:41:32 PM, Jeffrey Haas wrote: Jeff: Hi! ... > The pattern we normally want to see is "MUST be set to zero and SHOULD be > ignored on receipt". > > By requiring it to be set, you have expectations for a compliant > implementation of a given draft. > > By ignoring it on receipt, you permit the field to be used for something > further in the future. > > The above is consistent with Postel's Maxim. That makes sense. > 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. Does this behavior also apply to §4.2.2.12 (Fragment)? Thanks! Alvaro.
- [Idr] Poll on the RFC5575bis implementations abou… Dongjie (Jimmy)
- Re: [Idr] Poll on the RFC5575bis implementations … Jeffrey Haas
- Re: [Idr] Poll on the RFC5575bis implementations … Alvaro Retana
- Re: [Idr] Poll on the RFC5575bis implementations … Jeffrey Haas
- Re: [Idr] Poll on the RFC5575bis implementations … Dongjie (Jimmy)
- Re: [Idr] Poll on the RFC5575bis implementations … Jeffrey Haas