[Pals] 答复: [Int-area] draft-zzhang-intarea-generic-delivery-functions

"Yangfan (IP Standard)" <shirley.yangfan@huawei.com> Tue, 23 February 2021 08:06 UTC

Return-Path: <shirley.yangfan@huawei.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA7B3A2834; Tue, 23 Feb 2021 00:06:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 avJ-c8RRmmxE; Tue, 23 Feb 2021 00:06:00 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B477D3A2832; Tue, 23 Feb 2021 00:05:59 -0800 (PST)
Received: from fraeml710-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DlBLT1vm5z67rKD; Tue, 23 Feb 2021 16:00:33 +0800 (CST)
Received: from nkgeml703-chm.china.huawei.com (10.98.57.159) by fraeml710-chm.china.huawei.com (10.206.15.59) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Feb 2021 09:05:56 +0100
Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml703-chm.china.huawei.com (10.98.57.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 23 Feb 2021 16:05:54 +0800
Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.2106.006; Tue, 23 Feb 2021 16:05:54 +0800
From: "Yangfan (IP Standard)" <shirley.yangfan@huawei.com>
To: Toerless Eckert <tte@cs.fau.de>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>
CC: Kireeti Kompella <kireeti@juniper.net>, mpls <mpls@ietf.org>, Ron Bonica <rbonica@juniper.net>, "int-area@ietf.org" <int-area@ietf.org>, "pals@ietf.org" <pals@ietf.org>
Thread-Topic: [Pals] [Int-area] draft-zzhang-intarea-generic-delivery-functions
Thread-Index: Adbo7ZVM2l5i/x7jTG2A02P2JCK+DQgSmsUAAB5tk7A=
Date: Tue, 23 Feb 2021 08:05:54 +0000
Message-ID: <8058658bb0b54fff9aa255ad95652f15@huawei.com>
References: <MN2PR05MB59813CFC28F62CC076364991D4AA0@MN2PR05MB5981.namprd05.prod.outlook.com> <20210223003016.GA4493@faui48f.informatik.uni-erlangen.de>
In-Reply-To: <20210223003016.GA4493@faui48f.informatik.uni-erlangen.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.243.115]
Content-Type: multipart/alternative; boundary="_000_8058658bb0b54fff9aa255ad95652f15huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/RLmSagSigNowKjrerX6OViZw_4o>
Subject: [Pals] =?gb2312?b?tPC4tDogIFtJbnQtYXJlYV0gZHJhZnQtenpoYW5nLWlu?= =?gb2312?b?dGFyZWEtZ2VuZXJpYy1kZWxpdmVyeS1mdW5jdGlvbnM=?=
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2021 08:06:03 -0000

Hi Toerless and Jeffrey,

I have some comments, and also bring another thread to this topic, please see inline.



Regards,

Fan







-----邮件原件-----
发件人: Pals [mailto:pals-bounces@ietf.org] 代表 Toerless Eckert
发送时间: 2021年2月23日 8:30
收件人: Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>
抄送: Kireeti Kompella <kireeti@juniper.net>et>; mpls <mpls@ietf.org>rg>; Ron Bonica <rbonica@juniper.net>et>; int-area@ietf.org; pals@ietf.org
主题: Re: [Pals] [Int-area] draft-zzhang-intarea-generic-delivery-functions



Hi Jeff, *.



I am very supportive of i think what could be the spirit of this draft (and similar drafts that Stewart mentioned exist), but i am quite worried about some of the current fundamentals:



This looks a lot like



"i have a point problem (MPLS fragmentation), but to sell it better, i will give it a more inclusive name, but i don't really care that much about the other 99% opportunity/challenges".

(not that i am blaming you for trying, just wanting to point this out ;-)



Aka: before this type of draft can earn its ambitious name i think it needs to support a lot more use cases and include solutions for "generic" problems.

[yf]: agree. The use cases are important to be recognized at first, as it is always the principle of defining protocols in IETF.



For example:



- If something claims to be "generic" but does not propose to apply it to what is our

  tier 1 protocol, IPv6, then its more like "generic  for the leftover (non IPv6)", and

  we will continue to still have to provide (unnecessarily) multiple options to do the

  same thing. Aka: superceeding and replacing existing IPv6 extension options would be

  the most solid and important stake in the ground to claim "generic".



[yf]: I support to make maximum use of existing IPv6 extension options to enhance the capability of IP itself, at least we should get started to explore this direction.

Here I have to interrupt and bring another thread to this topic. My colleagues and I uploaded a new I-D yesterday in rtgwg, called "associated channel over IPv6" (https://tools.ietf.org/html/draft-yang-rtgwg-ipv6-associated-channel-00 ). The IPv6 based associated channel is provided to carry types of control and management messages, aiming to provide functions like path identification, OAM, etc. Sharing similar vision, it gives an attempt to IPv6. We would like to hear your comments and feedbacks.



- If we want IEEE to use this, there needs to be a) more work on how to use it with

  ethernet,and b) a way to establish different code-point registries, so IEEE could

  define options for this header by themselves. At least IMHO to maximize the opportunity

  for IEEE to drive this forwrd.



  I am saying this also because in my non-scientific opinion, the likelyhood for better

  QoS extension headers to be built are much better if we leave it up to IEEE and then

  inherit what they have done. Which could be helped by an extension header that IEEE would

  like to use and extend but that would also easily be able to be used with MPLS and IP.

  At least that's my somewhat frustrated opinion about IETFs progress on Qos given

  how we still think after 40 years "8 TOS bits are good enough forever",  L4S trying

  to overload an ECN bit, and only MPLS having been able to partially catch up in DetNet

  with what TSN did in ethernet.



- We ultimately will have layers of header to which such a header could be applied,

  such as ethernet+mpls+ip, and quite frankly i think we need a way to be able to have

  such a header only once instead of replicating it three times, which is what we typically

  would do these days if we needed the processing at all three layers. Aka: push up/down

  the header whenever we push/pop one of the encapsulations. Just as one idea.



- Encoding and forwarding plane support requirements for future extensions. Aka: i don't

  want to see for any future extensions the typical never ending discussions about what

  would be an appropriate way to encode them so that all hardware can support it. I think we

  should have enough of that problem in the wake of SRH now in Spring. If we want to call

  something generic, it should define mandatory encoding rules to be supported for any

  future extensions. Of course, this doesn't say that any extension function could be

  supported by any hardware, but it gets us one step closer. FOr example by codifying

  a mandatory encoding for variable length / optional parameters.



Without any intent to work on such broader strategy aspects, the use of the word "generic" is IMHO inappropriate.



Cheers

    Toerless



_______________________________________________

Pals mailing list

Pals@ietf.org<mailto:Pals@ietf.org>

https://www.ietf.org/mailman/listinfo/pals