Hi Jeffrey, WG,
Thanks for the further discussions.
“Didn’t we have such “unified” encoding already – an MPLS label?”
I agree and I would prefer to impl & use MPLS label for service delimiting in
vxlan/nvgre/geneve environment if I have to implement the following 6 options:
BIER+vxlan/nvgre/geneve for unicast vxlan/nvgre/geneve alignment, and BIER +
ip-udp-vxlan/ip-nvgre/ip-udp-geneve for alignment & php.
However there may still be a problem: the MPLS label is short than 24-bit VNI
needed in vxlan/nvgre/geneve enviroment!
Given this I will consider {L2 header + BIER + unified-overlay-header(UOH) },
where the UOH is used for service delimiting and inclusive to 24-bit VNI of any
type.
The UOH can be designed to support L2 header + UOH as well considering the PHP.
Anyway, I know it’s a trade-off between implement cost and market value.
I have no other question/problem with the processing of this draft even if I
think it is wrong direction to me as I see it from implementation view.
Thanks!
Jingrong
From: Jeffrey (Zhaohui) Zhang [mailto:[email protected]]
Sent: Monday, May 10, 2021 10:28 PM
To: Xiejingrong (Jingrong) <[email protected]>; [email protected];
[email protected]
Cc: [email protected]
Subject: RE: [bess] Cross WG review request for draft-ietf-bier-evpn
Hi Jingrong,
Please see zzh> below.
From: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>
Sent: Friday, May 7, 2021 8:19 AM
To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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:[email protected]]
Sent: Tuesday, May 4, 2021 2:39 AM
To: Xiejingrong (Jingrong)
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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 <[email protected]<mailto:[email protected]>> On Behalf Of
Xiejingrong (Jingrong)
Sent: Wednesday, April 7, 2021 3:20 AM
To: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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:[email protected]] On Behalf Of
[email protected]<mailto:[email protected]>
Sent: Friday, April 2, 2021 2:47 PM
To: [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/bess
