RE: FYI/Feedback draft-bryant-arch-fwd-layer-ps-00

"Xiejingrong (Jingrong)" <xiejingrong@huawei.com> Tue, 24 March 2020 03:26 UTC

Return-Path: <xiejingrong@huawei.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703073A0FD5; Mon, 23 Mar 2020 20:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hCmq6EShzpHw; Mon, 23 Mar 2020 20:25:59 -0700 (PDT)
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 8EEE33A0FB8; Mon, 23 Mar 2020 20:25:59 -0700 (PDT)
Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5473DFF00BE7EE4A60F9; Tue, 24 Mar 2020 03:25:57 +0000 (GMT)
Received: from nkgeml709-chm.china.huawei.com (10.98.57.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 24 Mar 2020 03:25:56 +0000
Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml709-chm.china.huawei.com (10.98.57.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 24 Mar 2020 11:25:54 +0800
Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1713.004; Tue, 24 Mar 2020 11:25:54 +0800
From: "Xiejingrong (Jingrong)" <xiejingrong@huawei.com>
To: "draft-bryant-arch-fwd-layer-ps@ietf.org" <draft-bryant-arch-fwd-layer-ps@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: RE: FYI/Feedback draft-bryant-arch-fwd-layer-ps-00
Thread-Topic: FYI/Feedback draft-bryant-arch-fwd-layer-ps-00
Thread-Index: AQHWAYH0Ir6LoSZ2sUGzvzaAsR4cHqhXERtg
Date: Tue, 24 Mar 2020 03:25:54 +0000
Message-ID: <8c3304f723864e32bd7d7c4c3dc15359@huawei.com>
References: <20200324021326.GC28168@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20200324021326.GC28168@faui48f.informatik.uni-erlangen.de>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.202.118]
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/rtgwg/5Vh3mpVeHxomWc3SUIejdvloEfc>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Mar 2020 03:26:02 -0000

Hi!

Thanks a lot for the good summary of some very interesting observations.

Here are some comments at first glance for section 6.1.1 ----

I think there are some other restrictions of RFC8200 notable to me that may cause "Forwarding Layer Problem".

(1) restrictions allowing only 1 routing header or similar thing. Forwarding plane has to count how many routing headers. As Radia Perlman said in her famous book:
ISO, being a standards body, was reluctant to specify how to define options -- thus, it provided this level of "flexibility". However, just to show that it does have the clout to make rules, it decreed that no option should appear twice. This restriction places a burden on routers (are they supposed to check that no option appears twice every time they forward a packet?) and reduces flexibility.

(2) the recommended order of the various extension headers:
When more than one extension header is used in the same packet, it is recommended that those headers appear in the following order:
IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet.
The later one is good for "forwarding layer" process, and the former one is not good, and is not the practice and consideration in years of RFCs, e.g., RFC6275 and RFC7837.

(3) The classification of different EH place holder, with some restriction. IPv4 does support Options but doesn't have such classification of EH or restrictions. The IPv6 spec does this classification based on some past patterns, but has some text only fit to some EH, or based on the recommended order, causing "forwarding layer problem" or "reduces flexibility". For example, Can someone invent a new routing header other than the one the place holder (with 4 fields, especially SL field) by the current RFC8200 ? Can someone use DO header working like routing header ? 

Thanks
Jingrong

-----Original Message-----
From: rtgwg [mailto:rtgwg-bounces@ietf.org] On Behalf Of Toerless Eckert
Sent: Tuesday, March 24, 2020 10:13 AM
To: rtgwg@ietf.org
Cc: draft-bryant-arch-fwd-layer-ps@ietf.org
Subject: FYI/Feedback draft-bryant-arch-fwd-layer-ps-00

Dear intarea WG

We think draft https://datatracker.ietf.org/doc/draft-bryant-arch-fwd-layer-ps/
does in part touch aspects related to routing area, so we are interested in your opinion/feedback. We think its mostly architectual through, so maybe architecture-discuss@ietf.org is more appropriate for overall discussions on the topic right now.

Before Corona, we had planned to have an inoffical side-meeting to discuss the topic, we have now set up a virtual inofficial side-meeting instead, This wednesday 03/25/2020, 1500 UTC. Info here:

https://trac.ietf.org/trac/ietf/meeting/wiki/ietf107replacements
https://etherpad.wikimedia.org/p/v107-side-meeting

Cheers
   Toerless (for the authors)

_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg