Re: [Idr] Erik Kline's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS and COMMENT)

Alvaro Retana <> Thu, 07 January 2021 20:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 561233A0D13; Thu, 7 Jan 2021 12:03:51 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, 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 C0Kr7SzcTSXJ; Thu, 7 Jan 2021 12:03:49 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3AA053A0D3D; Thu, 7 Jan 2021 12:03:32 -0800 (PST)
Received: by with SMTP id b9so11518757ejy.0; Thu, 07 Jan 2021 12:03:32 -0800 (PST)
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=fKWW7RMq6bDW5YJ2hhd3BmwFVEr1Fe8NPWkOlCSAD24=; b=DLvI6t6J2AV55QhbCIU4/MUBHRT1s8HUYufXeGBH1GX4rutyU3sBaW7lci78S/uQHj FsEWvg2WfETaI5XkLTKeR4eLL/uXJi2uotjMSXzXEpOLpmDfzkRiey4CheWUTwx5KDGK npaf35aVD/OLG/f7YeK9BuOo5qhtzCoKLrscUH2I1hYV2YJpFJ8O0YrKWJs1bGXZB4zb cUqvwZTwcOFcF5HmclnaRVcuHtypnfxp1GhoNcXsrneekaWXBxoTgn8WGsfB5KfqirJ6 yJEOvgh5pLsdx84vzeaaSHWcKraO1Zb+8jW/fIRqhvZ0IctGRdrtelB7zYS2IWZ0uGni SYDA==
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=fKWW7RMq6bDW5YJ2hhd3BmwFVEr1Fe8NPWkOlCSAD24=; b=ej6JgfkZfDcNN6UC6caVVtX0/0RCQaLVxNN+OT1SCFASp8jVaCupLWwipAgEXp70qB NTkb6NTJhI7BJoju7jjlgUT4EURMasHlpYhREXfB98bgxxuJnLlTACMX8DI7iZdySYTj N7o9caehK2NLyK9oznFOPwUdm8Nnh6LZPeImyopMj5U4eutBe2fjkmCTUMuhyfGOYL2C R5CUIMyz3DDYlkFHMA1ToyXJ/xFBRaB3oyZqvVT7Iyi8sqIWFNvWzfnLYtVwtEWyshwz gHvURowyleQ336nGOhA6SjR8EtxoJfyynlXzErBe+Vk02FSlOXl8VqLNleI73oZgn8Vq sc4Q==
X-Gm-Message-State: AOAM531rwRXv2ZoT3uVEHoaiAxrsKEyvKVzb2xEZgwhdh9jaAnUTTnnk Z8+VUYnWp4Ua29uruK2PnudAKgWmevrLQi/A2go=
X-Google-Smtp-Source: ABdhPJxG0KXaB399MQ9fFklfLH4WAsPx0ze9LzCgc1Ch6krOZFRBmWiHtyaJ+SdIttFVg6eyizDPaV0LSZAGUi6v/MI=
X-Received: by 2002:a17:907:444f:: with SMTP id on23mr352693ejb.300.1610049810852; Thu, 07 Jan 2021 12:03:30 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 7 Jan 2021 15:03:30 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Thu, 7 Jan 2021 15:03:30 -0500
Message-ID: <>
To: John Scudder <>, Erik Kline <>
Cc: Hares Susan <>, "" <>, The IESG <>, "idr@ietf. org" <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000000bf1df05b854ef86"
Archived-At: <>
Subject: Re: [Idr] Erik Kline's Discuss on draft-ietf-idr-tunnel-encaps-20: (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: Thu, 07 Jan 2021 20:03:52 -0000


Hi!  Happy New Year!

John just submitted -21.  Can you please take a look?  From the exchange
below, it may already address your concerns. ;-)

Please let us know if that is not the case.



On December 2, 2020 at 3:28:30 PM, John Scudder ( wrote:

Hi Erik,

On Dec 1, 2020, at 12:46 AM, Erik Kline <> wrote:



[ section 3.3.1 ]

* The text about "[a]ny one-octet value can be transported" leaves me
 wondering about how values that result in ECN bits being set should be

 I think there needs to be some recognition here that the DSCP part of
 the octet is only 6 bits (2474 section 3), and that bits 6 & 7 "MUST/SHOULD
 be zero on transmission and MUST/SHOULD be ignored by the recipient".

 Another way to ask the question here is: if ECN is not to be specified as
 part of this octet (and IMHO it should not be), which ranges of 6 bit
 values are permitted: [0..63], with the understanding this will be shifted
 before setting the octet, or [0,4,8,12,...,252]?  Given the text "It
 specifies the setting of the one-octet...", I think it implies the latter,
 but some clarification would, I think, be helpful.

If the argument is essentially: this is the value to stuff into
something like setsockopt(..., IP_TOS|IPV6_TCLASS, ...) which (in
Linux) accept an 8 bit value as is, then suppose that makes sense.

Thanks for anticipating my reply, that was exactly the thinking.

If it makes sense, do you think the text is sufficient as written, or if
not do you have any suggestions for clarification?