Re: [Bier] BIER v6 requirementsdraftcomments:draft-ietf-bier-ipv6-requirements ...
<zhang.zheng@zte.com.cn> Wed, 18 December 2019 09:54 UTC
Return-Path: <zhang.zheng@zte.com.cn>
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 4B5F7120938 for <bier@ietfa.amsl.com>; Wed, 18 Dec 2019 01:54:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Q56cHK6sJN8a for <bier@ietfa.amsl.com>; Wed, 18 Dec 2019 01:54:24 -0800 (PST)
Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 45B0D1200F4 for <bier@ietf.org>; Wed, 18 Dec 2019 01:54:22 -0800 (PST)
Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 1A60F7E1CF359EB244FB; Wed, 18 Dec 2019 17:54:20 +0800 (CST)
Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 0C20D85AACCD8A59AF4C; Wed, 18 Dec 2019 17:54:20 +0800 (CST)
Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id xBI9j14T037318; Wed, 18 Dec 2019 17:45:01 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn)
Received: from mapi (njxapp04[null]) by mapi (Zmail) with MAPI id mid203; Wed, 18 Dec 2019 17:45:01 +0800 (CST)
Date: Wed, 18 Dec 2019 17:45:01 +0800
X-Zmail-TransId: 2afc5df9f51d85d05006
X-Mailer: Zmail v1.0
Message-ID: <201912181745013371737@zte.com.cn>
In-Reply-To: <16253F7987E4F346823E305D08F9115AABAF00CC@nkgeml514-mbx.china.huawei.com>
References: 201912131746265802198@zte.com.cn, 16253F7987E4F346823E305D08F9115AABAF00CC@nkgeml514-mbx.china.huawei.com
Mime-Version: 1.0
From: zhang.zheng@zte.com.cn
To: xiejingrong@huawei.com
Cc: mmcbride7@gmail.com, bier@ietf.org, prz=40juniper.net@dmarc.ietf.org
Content-Type: multipart/mixed; boundary="=====_001_next====="
X-MAIL: mse-fl1.zte.com.cn xBI9j14T037318
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/aAbQhrJxJPz2DVBSPh6AmZLb5LY>
Subject: Re: [Bier] BIER v6 requirementsdraftcomments:draft-ietf-bier-ipv6-requirements ...
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: Wed, 18 Dec 2019 09:54:33 -0000
Hi Jingrong, Please see my comments with [Sandy3]. Thanks, Sandy 原始邮件 发件人:Xiejingrong(Jingrong) <xiejingrong@huawei.com> 收件人:张征00007940; 抄送人:mmcbride7@gmail.com <mmcbride7@gmail.com>;bier@ietf.org <bier@ietf.org>;prz=40juniper.net@dmarc.ietf.org <prz=40juniper.net@dmarc.ietf.org>; 日 期 :2019年12月17日 22:59 主 题 :RE: Re:[Bier] BIER v6 requirementsdraftcomments:draft-ietf-bier-ipv6-requirements ... Hi Sandy, Please see my comments with [XJR2]. Thanks, Jingrong From: zhang.zheng@zte.com.cn [mailto:zhang.zheng@zte.com.cn] Sent: Friday, December 13, 2019 5:46 PM To: Xiejingrong (Jingrong) <xiejingrong@huawei.com> Cc: mmcbride7@gmail.com; bier@ietf.org; prz=40juniper.net@dmarc.ietf.org Subject: Re:[Bier] BIER v6 requirements draftcomments:draft-ietf-bier-ipv6-requirements ... Hi Jingrong, Please see my comments with [Sandy2]. Thanks, Sandy 原始邮件 发件人:Xiejingrong(Jingrong) <xiejingrong@huawei.com> 收件人:张征00007940;mmcbride7@gmail.com <mmcbride7@gmail.com>; 抄送人:bier@ietf.org <bier@ietf.org>;prz=40juniper.net@dmarc.ietf.org <prz=40juniper.net@dmarc.ietf.org>; 日 期 :2019年12月13日 11:31 主 题 :Re: [Bier] BIER v6 requirements draftcomments:draft-ietf-bier-ipv6-requirements ... _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier Hi Sandy, Tony and Mike, Please see my comments in line with [XJR]. Thank you! Jingrong From: BIER [mailto:bier-bounces@ietf.org]On Behalf Ofzhang.zheng@zte.com.cn Sent: Thursday, December 12, 2019 11:37 AM To: mmcbride7@gmail.com Cc: bier@ietf.org; prz=40juniper.net@dmarc.ietf.org Subject: Re: [Bier] BIER v6 requirements draft comments:draft-ietf-bier-ipv6-requirements ... Hi Mike, Tony, Please see my comments in line with [Sandy]. Thank you! Sandy 原始邮件 发件人:MikeMcBride <mmcbride7@gmail.com> 收件人:Antoni Przygienda <prz=40juniper.net@dmarc.ietf.org>; 抄送人:bier@ietf.org <bier@ietf.org>; 日 期 :2019年11月19日 20:57 主 题 :Re: [Bier] BIER v6 requirements draft comments:draft-ietf-bier-ipv6-requirements ... Hi Tony, On Mon, Nov 18, 2019 at 9:51 PM Antoni Przygienda <prz=40juniper.net@dmarc.ietf.org> wrote: > > Finally getting to fire off some comments on draft-ietf-bier-ipv6-requirements draft MM: Yay! thank you, happy we are getting some feedback. > 3.4: I see NO requirements to do anything with SR or SRv6 in BIER WG charter so I am not sure how it ended up so prominently in the draft. And BIER is a hop-by-hop technology, it already includes provisions to transition non-BIER nodes via correct algorithms so not sure how SRv6 is of any use or relevance here. Of course BIER could be tunneled with SRv6 but then a BIER frame should be carried natively inside a SRv6 frame. Comingling two level layer 2.5 transport technologies into a single layer format as the draft seems to imply is unnecessary and a bad idea since there will be resulting cross-talk. MM: Unless my co-authors, or anyone else, disagrees, I say we simply remove this section and any and all references to SRv6 if it's not helpful. Focus should be on IPv6 related requirements. [Sandy]: Agree with Tony. If we mention SRv6 here, should we mention any all other potential tunnels (SR P2MP policy, IP in IP. and so on) here? The answer is obvious not. So I don't think it's necessary to mention SRv6 here. > 4.2: completely disagreed. BIER is a hop-by-hop layer 2.5 technology. Modifying IP options is arguably far more expensive than next-protocol frame. MM: You completely disagree with requirement 4.2? You believe that the solution _should_ require hop-by-hop modification of the IP source address field? Or just disagree with our explanation of it? This requirement came from Eric Rosen long ago. Please suggest new requirement wording that makes you happy. [Sandy]: IMO the whole section 4.2 is unnecessary. I don't see any benefits of the SA/DA modification restriction. For SA, we know that there are already OAM function in BIER header, we can use the information from the header directly. The BIER PING for instance, if any intermediate router need to send error message to BFIR, it can get the BFIR-id directly from the packet. For DA, I agree with Tony, BIER is a hop-by-hop lay 2.5 technology, it needn't, and can't make any unnecessary requirement for the outer header. > 4.3: > > fragmentation will only play in IPv6 case if the frame is longer than IPv6 max frame size - BML roughly. No matter _where_ we stick the mask we face the same problem until we start to do BIER fragmentation and reassembly MM: So the requirement "should not require the BFRs to inspect layer 4 or require any changes to layer 4." is fine but you don't like the fragmentation wording? Or do you not like the requirement period? We can certainly re-word it or remove it if it causes heartache. Again this was another Rosen requirement I believe. Fragmentation is optional for BIER, but, from an IPv6 point of view, it is a basic capability and we figured we should support it. Maybe we don't but let's get the requirement down. [Sandy]: At first, I don't think the fragment problem is real existed. We know that we prefer E2E IPv6 forwarding without fragment, there are many ways can provide the prediction of MTU of whole the road. [XJR] That said “fragment problem is not real existed”. I wish I could agree with you, but I can’t. [Sandy2]: Appreciate if you can provide the real deployment situation. [XJR2] Haven’t known about real deployment situation, but I can’t assume there are no deployments of v6 fragmentation, because v6 fragmentation serving as a basic service of IP layer is as basic as v4 fragmentation, and will be supported soon or later in my option. [XJR2] Anyway, I guess the argument here is that, a solution not support fragmentation can also has its use case but need to be said in its proposal. Maybe this can be clarified in the requirements. [Sandy3] So do you mean the fragment is not a mandatory requirement? Then at least we should remove the word "must" from the description, right? Thank you! Supposed that we still need to do fragment in BFIR, how to do the fragment function is depend on implementation. I don't think the situration described here will occur. [XJR] Please tell us how to do the fragment function in the implementation. [Sandy2]: Read RFC8200 may help you. [XJR2] Sorry, my question is how to do the fragment function by the <bierin6> solution. I understand “fragment function is depend on implementation” as every solution has its capability of doing fragment function. Please point out if I understand wrongly. [Sandy3]: Please see the comments from Tony. And I don't agree with you that you don't think <bierin6> can do fragment function. The NH execution function can be defined dynamically. If you still don't understand, please ask for your pruduct line to find help. The authentication function is the same with fragment. [XJR] Please tell us how to provide the authentication function in the implementation. [Sandy2]: Sorry I mean the real deployment situation. AFAIK, E2E authentication is more preferred. Appreciate if you can provide the according information. [XJR2] RFC5374 has it as an example to deploy multicast IPsec optionally. RFC8296 claims one of the security consideration, a BIER-encapsulated packet may be altered. It is a security problem need to cover, this way or that way, or say there is no additional security mechanisms besides rfc8296, no matter if there is real deployment currently. [Sandy3]: I think the argument is that where to put the authentication header, at the user's side, or the network side. The user side authentication can guarantee the security. In this situation, the authentication information is carried as BIER payload. The other argument point is the same with fragment, if we still need do the authentication function at BIER edge routers, the NH execution function can be defined dynamically. About the SRv6, same comments with section 3.4. > Again, SRv6 is neither in the charter nor an issue since BIER is a L2.5 hop-by-hop technology and not, as the authors want it, all of a sudden an implicit tunneling or multi-hop technology MM: Consider SRv6 gone from this draft since having it in there is causing pain. > 4.11: and again BIER is hop-by-hop and it will rely on higher layers to re-assemble just like MPLS does. MM: and again IPv6 does provide the fragmentation/assembly capability, so we figured BIER should inherit such capability but we could certainly be wrong. Are you in favor then of removing the 4.11 requirement involving fragmentation? Or re-wording it? [Sandy]: IMO section 4.11 and 4.12 need to be removed. It's not specific to BIER IPv6. [XJR] Seems the same as above. Do you think the fragmentation or authentication is not existed ? or they are not useful at all ? [Sandy2]: IMO they are not pain spots of BIER IPv6. Appreciate again for you can provide more real deployments about it. [XJR2] As above, my point is that, there may be no real deployments of multicast-in-ipv6 fragmentation or multicast-in-ipv6 IPsec now, but there is still ‘requirements’ of supporting them from the design of a solution. That helps to understand the different impacts of different solutions. Solution does not support them well may still have its advantages in scenarios it’s good at, maybe that kind of advantages can be brought into the requirements list for discussion. > I-D.xie-bier-ipv6-encapsulatio: yes, IPv6 architecture has the loophole for in flight modification of hop-by-hop header options but it does not mean it’s a good idea MM: This isn't a solutions document so whether it's a good idea or not can be saved for that document to justify. We will move the solutions overviews to an appendix. [Sandy]: I don't think it's good to mention specific solution in the requirement document. IMO the requirement document should be neutral and impartial. Thanks! > Last, major objection is that by opening any IPv6 destination address to receive BIER frames from multiple hops away we are opening a completely security nightmare and argumenting that whole BIER layer has to be IPSEC’ed to close that hole is simply going into a seriously wrong direction IMO. MM: Which requirement are you referring to? Perhaps you are referring to requirement 4.3 involving L4 Inspection where we mention IPsec? We figured the IPSEC architecture should be inherited from IPv6 if we are considering BIER in IPv6 but it looks like you don't agree. We are happy to modify/add/remove any requirement just needs specifics. thanks, mike > > > --- tony > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier
- [Bier] BIER v6 requirements draft comments: draft… Antoni Przygienda
- Re: [Bier] BIER v6 requirements draft comments: d… Robert Raszuk
- Re: [Bier] BIER v6 requirements draft comments: d… Mike McBride
- Re: [Bier] BIER v6 requirements draft comments: d… Rajiv Asati (rajiva)
- Re: [Bier] BIER v6 requirements draft comments: d… Xiejingrong (Jingrong)
- Re: [Bier] BIER v6 requirements draft comments: d… Xiejingrong (Jingrong)
- Re: [Bier] BIER v6 requirements draft comments:dr… zhang.zheng
- Re: [Bier] BIER v6 requirements draft comments:dr… Xiejingrong (Jingrong)
- Re: [Bier] BIER v6 requirements draftcomments:dra… zhang.zheng
- Re: [Bier] BIER v6 requirements draftcomments:dra… Xiejingrong (Jingrong)
- Re: [Bier] BIER v6 requirementsdraftcomments:draf… zhang.zheng