Re: Comments on raft-fz-6man-ipv6-alt-mark-01

Ole Troan <> Tue, 05 November 2019 07:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F019D1200F7 for <>; Mon, 4 Nov 2019 23:51:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qX76X8a-byqM for <>; Mon, 4 Nov 2019 23:51:25 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A16451200CE for <>; Mon, 4 Nov 2019 23:51:25 -0800 (PST)
Received: from (unknown [IPv6:2a02:2121:283:c860:d12a:cf:e287:3e7f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id DE0D34E11A76; Tue, 5 Nov 2019 07:51:24 +0000 (UTC)
Received: from [] (localhost []) by (Postfix) with ESMTP id A97BA21913FF; Tue, 5 Nov 2019 08:51:19 +0100 (CET)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01
From: Ole Troan <>
In-Reply-To: <>
Date: Tue, 5 Nov 2019 08:51:19 +0100
Cc: Tom Herbert <>, Giuseppe Fioccola <>, 6man WG <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Tianran Zhou <>
X-Mailer: Apple Mail (2.3601.0.10)
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2019 07:51:27 -0000

Hi Tianran,

> Yes, your proposal is a very good guidance for users to choose the mode how to take the alt-mark field.
> We will revise to show these considerations.
> But I think this is for the idea cases.
> We would also like to show some "abnormal" usage for legacy network. :-)
> That is to say, using SRH and DO for the hop by hop usage. I see the similar usage in RFC7837.
> What's your thoughts?

From RFC7837:
   "Hop-by-hop options would have been the best solution for carrying
   ConEx markings if they had met requirement R-3.  There is currently
   some work ongoing in the 6MAN working group to address this very
   issue [HBH-HEADER].  This new behavior would address R-3 and would
   make hop-by-hop options the preferred solution for carrying ConEx

The work in 6MAN is done and the definition of HBH is updated in RFC8200.

Best regards,