Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)

Alvaro Retana <> Fri, 24 April 2020 17:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5F6CE3A0EEF; Fri, 24 Apr 2020 10:00:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, UNPARSEABLE_RELAY=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 6TjSq0yId63b; Fri, 24 Apr 2020 10:00:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 097403A0EED; Fri, 24 Apr 2020 10:00:30 -0700 (PDT)
Received: by with SMTP id y24so11663544wma.4; Fri, 24 Apr 2020 10:00:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=xmFQfZmw7gPEObq8eWzKBvPfg6wiDb1y8PmpbX/1Kus=; b=pwv4j22HzSOVFLRxSi+URetcxFi8Pj2XeDLFYR6thWrHFInR4cAdtzr+yzLgj2c4pH 7yJuOZaJreruuisKJ3O83AuT2jiMNatpNW43pV8Mif0HD8rSkYXNl0jevp5tKedeTSrK JIGUGqH0LevYsCd4gF5utis3BlS5vBKY/8JfjnThT0CO1boNcADd/buWA3255oJKW6lY 0FKYf7kbvmW/iTssC+Rgy7sJ1r6oaqMzOQvvr0XxpMfuEhYiVVVDdTvLCqEaPIyot1+D gKDJ13rOwgWTToQdRcSE9kcZ8WGzehcAWRFV+FHT+sOgzYuJj6KN7dPxJRer7w5ZA2lN 8a/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=xmFQfZmw7gPEObq8eWzKBvPfg6wiDb1y8PmpbX/1Kus=; b=L5svOMPLQhkQeFu7NvHa5cqHKI+OJtHo8ZpXf4shckbaFMXlfkOijXWLg2Xuj/oe8o TmXP+1xKEk1wsWFTrgBZ2LQETch6ID29IuDxSA/hF34uHL5u9IzT+4kfz2bdaCEQLvLA fBxo0BNitpPnOJcU7OFFEg43fVLTK7RdXQhmRSs2VyvhTgCI+/0mYuw76jb2o0/Fn18/ tJdb5FENQH9ZA2/rCroxCgXGSrzfiy/cD78Zah2+reik3Nrb6YntAKriAIgSfjMet0pa YG1N+UArhuWEe71e226AyU1J247kITbnYESEDXbg+dI/o7SWBADtKAAGuhErfoGp7j1a vxSQ==
X-Gm-Message-State: AGi0PuYEumrphpShUsgrt23ReCaohAtRztjHmIOlW2lE8CD7bYKY0tu1 UgqPM9mNRZBv9MpuduWmngVEbUJkKrl/dJcqjBk=
X-Google-Smtp-Source: APiQypJWdSmFjTBmaT/hhRrXY+SI2o3VaRJGXQkjl80vHcdTKMsjN1BPJr5t6r2T1q+514IKqMkzXT+xeMxxD1wrU5M=
X-Received: by 2002:a05:600c:28e:: with SMTP id 14mr11742162wmk.79.1587747628439; Fri, 24 Apr 2020 10:00:28 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 24 Apr 2020 10:00:27 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <005f01d61a30$0cc55660$26500320$> <> <018801d61a49$a19f1320$e4dd3960$> <>
MIME-Version: 1.0
Date: Fri, 24 Apr 2020 10:00:27 -0700
Message-ID: <>
To: Susan Hares <>, "Rob Wilton (rwilton)" <>, Jie Dong <>
Cc: "" <>, "" <>, "" <>, The IESG <>
Content-Type: multipart/alternative; boundary="00000000000062df8305a40c4d0e"
Archived-At: <>
Subject: Re: [Idr] Robert Wilton's Discuss on draft-ietf-idr-rfc5575bis-23: (with DISCUSS and COMMENT)
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: Fri, 24 Apr 2020 17:00:33 -0000


As Rob mentioned, we talked about his DISCUSS during today’s IESG Telechat.

We’re all in agreement that the last thing we want to do is to break any
existing implementations, specially because this document is a bis.

I looked at rfc5575, and I didn’t find the same text there — I found no
specification of the setting of the bits, specially the reserved ones.

[I also did a quick and unscientific search of other routing documents and
found a mix of SHOULD/MUST and MUST/MUST constructs…]

Note that there are two distinct cases (in rfc5575bis):

(1) A bit is defined as 0, but the definition is: "0 -  SHOULD be set to
0…” (§  If it’s 0, then I see no reason for that not to be a
MUST.  In fact, if always set to 0 we’re probably over specifying the
field.   There are 3 occurrences of this in the document.

(2) Unused (§7.3) or reserved (§7.5) defined as "SHOULD be set to 0...MUST
be ignored”.  Again, if unused/reserved, I see no reason not to change to
MUST.  I think Rob makes a good point about extensibility.

Before any changes, and in the spirit of not breaking anything, we should
check whether anyone has an implementation what would be impacted.  I
assume/hope that the prototype implementations have already been fixed.

Jie:  As Shepherd, can you please do a quick poll of the people who
reported implementations to confirm that these changes won’t have an



On April 24, 2020 at 12:24:28 PM, Rob Wilton (rwilton) (

> Your question is a good one:
> But I don't understand why that means the
> sender is a "SHOULD be 0" not a "MUST be 0"?
> This text is inherited from RFC5575.
> Originally (which is not in any document)
> this was set because prototype implementations of
> RFC5575 had set it to a 1 during a rushed deployment.
> Whether these implementation still exist in the
> smaller boxes boxes from major vendors - I do not know.
> One of the habits of IDR is not to break existing BGP.
Yes, and I fully support that pragmatic aim.