Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
Xiejingrong <xiejingrong@huawei.com> Sat, 13 July 2019 00:43 UTC
Return-Path: <xiejingrong@huawei.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19447120074; Fri, 12 Jul 2019 17:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.531
X-Spam-Level:
X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, INVALID_MSGID=0.568, 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 4te9d_TAgOoq; Fri, 12 Jul 2019 17:43:24 -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 8378C12000E; Fri, 12 Jul 2019 17:43:23 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DA4D4239808C2904DF0E; Sat, 13 Jul 2019 01:43:20 +0100 (IST)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 13 Jul 2019 01:43:19 +0100
Received: from NKGEML514-MBX.china.huawei.com ([fe80::40a8:f0d:c0f3:2ca5]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Sat, 13 Jul 2019 08:43:07 +0800
From: Xiejingrong <xiejingrong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Antoni Przygienda <prz@juniper.net>, "draft-zhang-bier-bierin6@ietf.org" <draft-zhang-bier-bierin6@ietf.org>, BIER WG <bier@ietf.org>
Thread-Topic: Questions regarding <draft-zhang-bier-bierin6-03>
Thread-Index: AdU2IrLV6PANcPQ8TJ2wzjJsYLxNqQAHa6GgAHBJYdsAJ5LssAAG4U8gABMzeYcAAKuo4AABG4TgAAAgNCAAAQsyQw==
Date: Sat, 13 Jul 2019 00:43:06 +0000
Message-ID: 94D3B0A6-FD7D-486D-9D45-0FA439BFEAE3
References: <16253F7987E4F346823E305D08F9115AAB8DC468@nkgeml514-mbx.china.huawei.com>, <DM5PR05MB3548E853C20E03CC58C7956BD4F10@DM5PR05MB3548.namprd05.prod.outlook.com> <MWHPR05MB32792FD6E09E4444B8DF45C3ACF30@MWHPR05MB3279.namprd05.prod.outlook.com> <16253F7987E4F346823E305D08F9115AAB8DD5B0@nkgeml514-mbx.china.huawei.com>, <DM5PR05MB3548F4EFF3EFC0CCDA3FDE73D4F20@DM5PR05MB3548.namprd05.prod.outlook.com> <16253F7987E4F346823E305D08F9115AAB8DD87A@nkgeml514-mbx.china.huawei.com>, <DM5PR05MB354819A911C930C1B8519CD4D4F20@DM5PR05MB3548.namprd05.prod.outlook.com> FDF1BFA9-7176-45D0-B21B-C15FF4F9EB4E, <DM5PR05MB3548637A9F8CBB1CB70BE3E6D4CD0@DM5PR05MB3548.namprd05.prod.outlook.com>
In-Reply-To: <DM5PR05MB3548637A9F8CBB1CB70BE3E6D4CD0@DM5PR05MB3548.namprd05.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_94D3B0A6FD7D486D9D450FA439BFEAE3_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/QbekuYRl_A8wbzlWv_VLeMdtmyo>
Subject: Re: [Bier] Questions regarding <draft-zhang-bier-bierin6-03>
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jul 2019 00:43:28 -0000
Hi Jeffrey, Pls see my comments in line below. 发件人:Jeffrey (Zhaohui) Zhang <zzhang@juniper.net> 收件人:Xiejingrong <xiejingrong@huawei.com>;Antoni Przygienda <prz@juniper.net>;draft-zhang-bier-bierin6@ietf.org <draft-zhang-bier-bierin6@ietf.org>;BIER WG <bier@ietf.org> 时间:2019-07-13 08:18:36 主 题:RE: Questions regarding Let me ask it this way: What’s the difference between the following situation: 1. <some hop-by-hop or destination option hdr, NH=BIER> (per draft-zhang-bier-bierin6-03) 2. <same hop-by-hop or destination option hdr, NH=<undefined> (per RFC8200) If you have concern with #1, wouldn’t you have the same concern with #2? [XJR] Got your mean. you are right for the listed case: Originally a chip don't necessarily differentiate the above two cases, but sends them to CPU. That's a short and simple process. When using the bierin6 proposal, a chip doesn't have to differentiate the above two cases. just send to CPU the packets with any extensions. There is still example that need a chip to differentiate the process per the draft: 1. (routing header, NH=BIER) 2. (routing header, NH=undefined) this draft also want to support 1, so a chip has to recognize the packet pattern of case 1 and do in fast path. While originally one doesn't need to recognize the special pattern of 1 but just send to CPU the packet with EH. More convinced if a solution want to have more flexibility, for example one may want the same solution (in the future) to support the following fast path processing: 3. (routing header, destination options header, NH=BIER). Thanks, Jingrong. Jeffrey Juniper Business Use Only From: Xiejingrong <xiejingrong@huawei.com> Sent: Friday, July 12, 2019 8:10 PM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Antoni Przygienda <prz@juniper.net>; draft-zhang-bier-bierin6@ietf.org; BIER WG <bier@ietf.org> Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03> Pls See comments inline: 发件人:Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> 收件人:Xiejingrong <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>;Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>;draft-zhang-bier-bierin6@ietf.org <draft-zhang-bier-bierin6@ietf.org<mailto:draft-zhang-bier-bierin6@ietf.org>>;BIER WG <bier@ietf.org<mailto:bier@ietf.org>> 时间:2019-07-13 07:43:22 主 题:RE: Questions regarding Please see zzh> below. Juniper Business Use Only From: Xiejingrong <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>> Sent: Friday, July 12, 2019 7:34 PM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; draft-zhang-bier-bierin6@ietf.org<mailto:draft-zhang-bier-bierin6@ietf.org>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03> Hi Jeffrey, Please see my comments inline below ________________________________ 发件人: Jeffrey (Zhaohui) Zhang [zzhang@juniper.net] 发送时间: 2019年7月12日 22:27 收件人: Xiejingrong; Antoni Przygienda; draft-zhang-bier-bierin6@ietf.org<mailto:draft-zhang-bier-bierin6@ietf.org>; BIER WG 主题: RE: Questions regarding <draft-zhang-bier-bierin6-03> I don’t have a good understanding about the writing in the latest email below, but for the following original comment that led to it: • [XJR Q6]: You have to walk the ext header chain and get the last NH to judge if this packet need to be discard, right? For example for an incoming packet(ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>), you have to walk the whole extension header chain until you know the last NH, to execute the above “discard” action. Right? What is the problem with that? This document is saying that for BIER packets, the only header that is expected is the TBD (for BIER) and otherwise you drop it. Normally, you would not have the (ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>) situation. [XJR] This document also said the following. Any IPv6 packet arriving on BFRs and BFERs, with multiple extension header where the last extension header has a Next Header field set to TBD, SHOULD be discard and the node should transmit an ICMP Parameter Problem message to the source of the packet (BFIR) with an ICMP code value of TBD10 ('invalid options for BIERin6'). If the concern is that someone could maliciously inject that kind of packets for the purpose of slowing down a targeted BFR, then any of the following situation in RFC8200, independent of BIER, will have the same effect: [XJR] Right. There is also concern of injection of packets to slow down a targeted BFR. That may not the below case listed in RFC8200. Zzh> The RFC8200 text that I quoted would have the same concern – that’s my point and it’s not BIER specific. In other words, some one could maliciously construct some NON-BIER IPv6 packets with certain headers and slow down a router. Your concern with this draft would exist with RFC8200 as well. [XJR] rfc8200 doesn't assume specific NH like BIER be processed in fast path. In real world, packets with any extension headers may be sent to CPU without "digging out some bier specific patterns and processing specially" and CPU can do that. They are always slow but doesn't walk the chain in chips. Jingrong Zzh> Jeffrey Also, there are concerns of flexibility as my comments before. For example: BIER may want to process a packet with IPv6 NH=BIER in fast-path, and drop IPv6 NH=xxx and Last_NH=BIER. BIER may want to process a packet with IPv6 NH=BIER or IPv6 NH=RH and RH_NH=BIER in fast-path, and drop IPv6 NH=xxx and Last_NH=BIER. a new feature, let's say REIB may have the similar requirements: REIB may want to process a packet with IPv6 NH=REIB in fast-path, and drop IPv6 NH=xxx and Last_NH=REIB. REIB may want to process a packet with IPv6 NH=REIB or IPv6 NH=RH and RH_NH=REIB in fast-path, and drop IPv6 NH=xxx and Last_NH=REIB. then I guess a lot of "walking through the EH chain" have to be executed like [XJR Q8]. Thanks, Jingrong If, as a result of processing a header, the destination node is required to proceed to the next header but the Next Header value in the current header is unrecognized by the node, it should discard the packet and send an ICMP Parameter Problem message to the source of the packet, with an ICMP Code value of 1 ("unrecognized Next Header type encountered") and the ICMP Pointer field containing the offset of the unrecognized value within the original packet. The same action should be taken if a node encounters a Next Header value of zero in any header other than an IPv6 header. Jeffrey From: Xiejingrong <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>> Sent: Friday, July 12, 2019 7:20 AM To: Antoni Przygienda <prz@juniper.net<mailto:prz@juniper.net>>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; draft-zhang-bier-bierin6@ietf.org<mailto:draft-zhang-bier-bierin6@ietf.org>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: RE: Questions regarding <draft-zhang-bier-bierin6-03> Hi Tony, Exactly, the whole v6 extension headers(EH) and the v6 options consideration is basically a first stab! Once a judgement is based on the “Upper-layer Protocol”, the last next header of a chain, then a walk through the chain is unavoidable, to “dig out” the right format that need to be processed in fast-path. The difficulty with a “regular” IPv6 DA is that, normal things like TCP/UDP/ICMPv6 packet must be handled without much impact on it. Use a “XXX specific IPv6 DA” is not only the SRv6-NetworkProgramming concept, but also the ISO NSAP address as I learned from a book and found in the WIKI https://en.wikipedia.org/wiki/NSAP_address<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_NSAP-5Faddress&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=Rh1tyYzDzhRq7ymA_JEJduNT94j_xiGhiQ-QgbwQ9L4&e=>: The NSEL (Network-Selector) is a field in the NSAP address that identifies the network layer<https://urldefense.proofpoint.com/v2/url?u=https-3A__en.wikipedia.org_wiki_Network-5Flayer&d=DwMFAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=hKlg11Qzoo3dyO4pZGNb6wtU4M6Kb1RXIFHB6JnSl4A&s=CseHsrq8z_Cjx0ZsXzuYT3X9_3CMLv4SkB7Cs2nRPu0&e=> service to which a packet should be sent. BIER forwarding seems match very much a “network layer service” in my opinion, and the “AB37” in “2019::AB37” is very similar to a NSEL too. Thanks Jingrong From: Antoni Przygienda [mailto:prz@juniper.net] Sent: Friday, July 12, 2019 12:02 AM To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Xiejingrong <xiejingrong@huawei.com<mailto:xiejingrong@huawei.com>>; draft-zhang-bier-bierin6@ietf.org<mailto:draft-zhang-bier-bierin6@ietf.org>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>> Subject: Re: Questions regarding <draft-zhang-bier-bierin6-03> 2.1. IPv6 Options Considerations RFC 8200 section 4, defines the IPv6 extension headers. Currently there are two defined extension headers, Hop-by-Hop and Destination options header, which can carry a variable number of options. These extension headers are inserted by the source node. For directly connected BIER routers, IPv6 Hop-by-Hop or Destination options are irrelevant and SHOULD NOT be inserted by BFIR on the BIERin6 packet. In this case IPv6 header, Next Header field should be set to TBD. Any IPv6 packet arriving on BFRs and BFERs, with multiple extension header where the last extension header has a Next Header field set to TBD, SHOULD be discard and the node should transmit an ICMP Parameter Problem message to the source of the packet (BFIR) with an ICMP code value of TBD10 ('invalid options for BIERin6'). [XJR Q6]: You have to walk the ext header chain and get the last NH to judge if this packet need to be discard, right? For example for an incoming packet(ipv6hdr+RoutingHeader+DestOptHdr<nh!=TBD>), you have to walk the whole extension header chain until you know the last NH, to execute the above “discard” action. Right? prz> topic for discussion. The whole v6 options consideration is basically a first stab. This also indicates that for disjoint BIER routers using IPv6 encapsulation, there SHOULD NOT be any IPv6 Hop-by-Hop or Destination options be present in a BIERin6 packet. [XJR Q7]: What does “disjoint BIER router” mean? prz> non-adjacent, good catch Juniper Business Use Only
- [Bier] Questions regarding <draft-zhang-bier-bier… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Jeffrey (Zhaohui) Zhang
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Antoni Przygienda
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Jeffrey (Zhaohui) Zhang
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Jeffrey (Zhaohui) Zhang
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Jeffrey (Zhaohui) Zhang
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Senthil Dhanaraj
- Re: [Bier] Questions regarding <draft-zhang-bier-… Tony Przygienda
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Senthil Dhanaraj
- Re: [Bier] Questions regarding <draft-zhang-bier-… Tony Przygienda
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong
- Re: [Bier] Questions regarding <draft-zhang-bier-… Tony Przygienda
- Re: [Bier] Questions regarding <draft-zhang-bier-… Michael McBride
- Re: [Bier] Questions regarding <draft-zhang-bier-… Greg Shepherd
- Re: [Bier] Questions regarding <draft-zhang-bier-… Tony Przygienda
- Re: [Bier] Questions regarding <draft-zhang-bier-… Xiejingrong