Re: [bess] Cross WG review request for draft-ietf-bier-evpn

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jingrong, WG,

I somehow missed this email. Sorry for replying late.

Please see zzh> below.

From: BESS <[e-mail]> On Behalf Of Xiejingrong (Jingrong)
Sent: Wednesday, April 7, 2021 3:20 AM
To: [e-mail]; [e-mail]
Cc: [e-mail]
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:[e-mail]] On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Friday, April 2, 2021 2:47 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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