IETF Logo Mail Archive

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

Tianran Zhou <zhoutianran@huawei.com> Tue, 05 November 2019 08:33 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35C91201E4 for <ipv6@ietfa.amsl.com>; Tue, 5 Nov 2019 00:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 PdTKzniohOBQ for <ipv6@ietfa.amsl.com>; Tue, 5 Nov 2019 00:33:20 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE37F12006E for <ipv6@ietf.org>; Tue, 5 Nov 2019 00:33:19 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 16B595B2431F9209BCF9 for <ipv6@ietf.org>; Tue, 5 Nov 2019 08:33:17 +0000 (GMT)
Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Nov 2019 08:33:16 +0000
Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 5 Nov 2019 08:33:16 +0000
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 5 Nov 2019 08:33:16 +0000
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0439.000; Tue, 5 Nov 2019 16:33:04 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Ole Troan <otroan@employees.org>
CC: Tom Herbert <tom@herbertland.com>, Giuseppe Fioccola <giuseppe.fioccola@huawei.com>, 6man WG <ipv6@ietf.org>
Subject: RE: Comments on raft-fz-6man-ipv6-alt-mark-01
Thread-Topic: Comments on raft-fz-6man-ipv6-alt-mark-01
Thread-Index: AQHVkNp1vSw+2l7wQkiVjZA5BgCgSqd2EMsAgAAC24CAAAVMgIAGGU5Q//+BjICAAI5ZsA==
Date: Tue, 05 Nov 2019 08:33:03 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BF07AD37@NKGEML515-MBX.china.huawei.com>
References: <CALx6S35298CHBJsSs3LGY_0Pp2_eW-dQFCbQ6SLQneoQ5U=_yQ@mail.gmail.com> <FE11E326-43C2-409C-864E-62AD8B893050@employees.org> <BBA82579FD347748BEADC4C445EA0F21BF07ACE4@NKGEML515-MBX.china.huawei.com> <B5464B84-1105-4133-8E77-09FF739D8D38@employees.org>
In-Reply-To: <B5464B84-1105-4133-8E77-09FF739D8D38@employees.org>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.156.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Z_JpEbNwfbJ_SuXRPBl8xRUXvLw>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2019 08:33:22 -0000

Hi Ole,

Yes, I know 8200 considered and changed the way to process the HBH.
Do you mean the following words?
 NOTE: While [RFC2460] required that all nodes must examine and
 process the Hop-by-Hop Options header, it is now expected that nodes
 along a packet's delivery path only examine and process the
 Hop-by-Hop Options header if explicitly configured to do so.

>From this I am always confused. We can decide/configure whether to process the HBH. But we cannot decide whether it's processed in fast path or slow path. I think this is one issue raised by the reference
https://tools.ietf.org/html/draft-ietf-6man-hbh-header-handling-03
Do I miss some other words in 8200?

In addition, we did test many asics and devices. They will direct packet to the slow path.
In addition, in real deployment, there are legacy devices that follow RFC2460.

So our idea is to show alternative options for potential environment. 

Thanks,
Tianran

> -----Original Message-----
> From: Ole Troan [mailto:otroan@employees.org]
> Sent: Tuesday, November 05, 2019 3:51 PM
> To: Tianran Zhou <zhoutianran@huawei.com>
> Cc: Tom Herbert <tom@herbertland.com>; Giuseppe Fioccola
> <giuseppe.fioccola@huawei.com>; 6man WG <ipv6@ietf.org>
> Subject: Re: Comments on raft-fz-6man-ipv6-alt-mark-01
> 
> 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
>    markings."
> 
> The work in 6MAN is done and the definition of HBH is updated in RFC8200.
> 
> Best regards,
> Ole

v2.23.0 | Report a Bug | By Email