Hi Jingrong, Please see zzh> below.
From: Xiejingrong (Jingrong) <xiejingr...@huawei.com> Sent: Friday, May 7, 2021 8:19 AM To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; slitkows.i...@gmail.com; bess@ietf.org Cc: bess-cha...@ietf.org Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn [External Email. Be cautious of content] Hi Jeffrey, all, First of all, I am not against the process of this draft. What I really want to discuss is about the “right” design of BIER service solution to make it really implementable and deployable, before it goes to a wrong direction IMO. Zzh> I am not sure if there is a question/problem of “wrong direction” here. The first design of BIER is based on MPLS, and the first BIER overlay encoding is an VPN Label following BIER header, to make it more aligned with the “BIER-MPLS” underlay. However, is this a good design to be just “more aligned”, first with MPLS , then with IP based vxlan/nvgre/geneve ? When MPLS is not preferred encapsulation but BIER is, then MPLS Label encoding after BIER header may not be preferred, and one have to choose a better “aligned” BIER overlay encoding, for example Vxlan. When Vxlan is not preferred for unicast but BIER is preferred for multicast, then a better “aligned” BIER overlay encoding is needed, say NVGRE. When Nvgre is not preferred for unicast but BIER is preferred for multicast, then a better “aligned” BIER overlay encoding is needed, say GENEVE. Zzh> As I mentioned in the previous reply, using VXLAN/NVGRE/GENEVE after BIER is *NOT* a random and single choice. It is based whether an operator uses for unicast. If operator 1 uses VXLAN for unicast, then for BUM it’s BIER header followed by the VXLAN header (w/ or w/o the IP/UDP header depending on whether PHP is needed); if operator 2 uses NVGRE for unicast, then for BUM it’s BIER header followed by the NVGRE header and so on so forth. Remind that Vxlan and Nvgre is informational encapsulation and Geneve is standard, however a router may not support Geneve but support vxlan, and may or may not support BIER. Also remind that, when considering IPv6 encapsulation, vxlan/nvgre/geneve may have another alternative of SRv6-network-programming [RFC8986]. Zzh> If an operator uses SRv6 network programing instead of VXLAN/NVGRE/GENEVE, then of course VXLAN/NVGRE/GENEVE won’t be used with BIER. How about designing one “unified” encoding that is “independent” of these IP based vxlan/nvgre/geneve encodings? say a longer-than-20-bit integer value without Vxlan/Nvgre/Geneve encoding. Zzh> Didn’t we have such “unified” encoding already – an MPLS label? 😊 Zzh> In our previous discussions, I had said that while I understand that an operator may not want to use MPLS for transport purpose, I really don’t see why MPLS labels can’t be used for service delimiting purpose. No matter how/what it is encoded/presented/called, a number is used to represent something and an action is performed when that number is matched. It could be an mpls label, or a VNI, or some SRv6 function/argument bits. The design of such a “unified” encoding can also consider the requirements that have seen: PHP and the problem that the BFIR node information is lost (then basic function like MVPN RPF is lost) etc. If the vxlan/nvgre/geneve is implemented in BIER, then please just ignore these discussions. If it is not, then I think such discussions may make some sense. Zzh> Let me ask it this way – say you’re an operator/vendor who prefers SRv6 for unicast service delimiting. Now for multicast with BIER, if I suggest to use an MPLS label for service delimiting, what would you say? Zzh> If you as an operator use vxlan/nvgre/geneve for unicast service delimiting, and I suggest to use MPLS label for service delimiting for multicast with BIER, what would you say? What’s your opinion ? Can the BESS chair also provide your points on this? Zzh> There must be a reason for so many choices on unicast side. Unless we can force every operator to the same on unicast side, I don’t think we can/need to standardize on a single choice for multicast with BIER. Zzh> Thanks. Zzh> Jeffrey Thanks Jingrong From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net] Sent: Tuesday, May 4, 2021 2:39 AM To: Xiejingrong (Jingrong) <xiejingr...@huawei.com<mailto:xiejingr...@huawei.com>>; slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; bess@ietf.org<mailto:bess@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn Hi Jingrong, WG, I somehow missed this email. Sorry for replying late. Please see zzh> below. From: BESS <bess-boun...@ietf.org<mailto:bess-boun...@ietf.org>> On Behalf Of Xiejingrong (Jingrong) Sent: Wednesday, April 7, 2021 3:20 AM To: slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com>; bess@ietf.org<mailto:bess@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: Re: [bess] Cross WG review request for draft-ietf-bier-evpn [External Email. Be cautious of content] Hi, I have some comments on this draft. 1. There are 3 different encapsulations VXLAN/NVGRE/GENEVE defined in this draft, but it is not clear if there is a mandatory one for interoperable implementation, or all are mandatory ? Zzh> For a particular deployment, only one is needed – whichever one that is used for (known) unicast. The effort to make BIER-EVPN “unified” with Unicast-EVPN (by using 3 BIER proto values) doesn’t seem to be convenient: 1) For implementation, the existing NVO3 VXLAN/NVGRE/GENEVE forwarding module (HW or SW) doesn’t help much because the major gap is BIER. 2) For trouble-shooting like offline LAN analyzing (rfc8279), the existing NVO3 VXLAN/NVGRE/GENEVE header doesn’t help much because the major part is BIER. From my point of view, one uniform encapsulation is better because it is used for one single purpose – to distinguish the tenant and still keep aligned with NVO3 style where “VNI” is used. Zzh> From operational point of view, if a customer uses VXLAN for unicast, it does not make sense if he is forced to use NVGRE/GENEVE as BIER payload? 2. In section 2.1: A well-known IP multicast address (to be assigned by IANA) is used as the destination address and the egress PEs MUST be set up to receive and process packets addressed to the address. It is not clear what are the “set up” and “process” implying. For example: 1) For implementation, does the “set up” mean an MFIB entry populated into forwarding table ? A packet with well-known IP multicast address as destination address (like 224.0.0.1) is usually sent to CPU in a multicast router in my opinion. Zzh> 224.0.0.1 is a good example for what “set up” and “processing” means – the router is prepared to process packets addressed to the well-know address. Whether it is sent to CPU for processing is a local implementation detail - a sane/normal implementation would handle it in fast path but the spec does not have to mandate that. 2) For error-handling, how to “process” if the TTL/Hop limit field in the IP header is 0/1/254/255 ? Zzh> This is like typical TTL handling for VPN/EVPN. For example, in case of VPN/EVPN-MPLS, how the TTL field is set and processed for the tunnel label and VPN/BD label. Here the tunnel label’s TTL field is the BIER TTL and the VPN/BD label’s TTL is the IP header TTL. Neither RFC 7432 nor RFC 8556 has text about it, and we don’t need text here either. From my point of view, the cost to support BIER-PHP this way is fairly high. I am not sure if some words like “recommend” or “not recommend” can help to do the trade-off for implementation/deployment. Zzh> Perhaps that trade-off discussion should happen in the PHP spec? Zzh> Thanks! Zzh> Jeffrey Thanks Jingrong From: BESS [mailto:bess-boun...@ietf.org] On Behalf Of slitkows.i...@gmail.com<mailto:slitkows.i...@gmail.com> Sent: Friday, April 2, 2021 2:47 PM To: bess@ietf.org<mailto:bess@ietf.org> Cc: bess-cha...@ietf.org<mailto:bess-cha...@ietf.org> Subject: [bess] Cross WG review request for draft-ietf-bier-evpn HI folks, The BIER WG is in the last mile of review for draft-ietf-bier-evpn and requests our review on the document before progressing further. Please have a deep look at it and provide your feedback or concerns. Please close the review by April 20th. Thanks in advance, Stephane https://datatracker.ietf.org/doc/draft-ietf-bier-evpn/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bier-evpn/__;!!NEt6yMaO-gk!X79RIuMgyyHS1BTpoeLBKq0UwVKkce0pz7YtdV5iKkHgrUWi-bob9ck749iR-1wK$> Juniper Business Use Only Juniper Business Use Only
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
