Hi Jingrong, WG,
I somehow missed this email. Sorry for replying late.
Please see zzh> below.
From: BESS <bess-boun...@ietf.org> On Behalf Of Xiejingrong (Jingrong)
Sent: Wednesday, April 7, 2021 3:20 AM
To: 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,
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
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
