Re: [bess] Chair review of draft-ietf-bess-evpn-bum-procedure-updates

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

Hi Stephane,

Thanks for your review and comments/suggestions. Please see zzh> below (and diff in https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-bum-procedure-updates-08).

From: [e-mail] <[e-mail]>
Sent: Wednesday, November 13, 2019 9:11 PM
To: [e-mail]; [e-mail]
Subject: Chair review of draft-ietf-bess-evpn-bum-procedure-updates

Hi,

Before moving forward to IESG, here is my review of the document:

Section 2:

"Note that these are to be applied

   to EVPN only, even though sometimes they may sound to be updates to

   [RFC7117<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7117__;!8WoA6RjC81c!Rt3VAuyRgtWfhTdkP8k2Y7tvamLYm-MqQ2q6tqzgSHpBFeYkTX7kbAqUhNbNeio1$>] or [RFC7524<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc7524__;!8WoA6RjC81c!Rt3VAuyRgtWfhTdkP8k2Y7tvamLYm-MqQ2q6tqzgSHpBFeYkTX7kbAqUhENk13cl$>]. >
The second part of the sentence is not really appropriate for a standard document. The text should always be crystal clear that it applies to EVPN only, reuse the procedures from other RFCs with the associated modifications. But you must never talk about updating VPLS RFCs, if you don't.

Zzh> The second part of that sentence is meant to say that they MIGHT SOUND like updates to 7117/7524 but they're not. I changed it to "and not updates to [RFC7117] or [RFC7524]".

Section 3:
Not all the route types are coming from RFC7432, could you provide a reference for route-types that are not defined in RFC7432 ?

Zzh> Done.

Section 3.1:
As you say in the text, the extended community is not an attribute here. Wouldn't it be better to rename it as Region ID, telling then in the text that it is encoded similarly to an extended community using type/subtype/...
In case you agree, update of 6.2 is necessary.


Zzh> Done.


Section 4:
s/and an receiving NVE/and a receiving NVE
s/In a nut shell/In a nutshell
s/S-SPMSI/S-PMSI

s/an egress NVE may omit the Leaf/an egress NVE MAY omit the Leaf
s/if it already advertises/if it has already advertised
s/and the source NVE will use that/and the source NVE MUST use that

zzh> Fixed.

Section 5.1
In the proposal text changes for 7.2.2.4 in RFC7117, please use normative language s/must/MUST

Zzh> Done.

Section 5.2:
I don't understand this sentence (ps: I'm not telling the sentence is wrong) :

"Note

   that in case of Ingress Replication, when an ASBR re-advertises IBGP

   I-PMSI A-D routes, it MUST advertise the same label for all those for

   the same Ethernet Tag ID and the same EVI. "
Could you please explain me ? Do you mean that ASBR allocate the same label for different routes with same ETAG/EVI ?

Zzh> Right - as you understood that ASBR1/3 below will advertise the same label for IMET routes from PE2/PE3.
Zzh> I did change "re-advertise IBGP I-PMSI A-D routes" to "re-advertise IMET A-D routes to IBGP peers".

Consider the following setup

PE1 -(CORE)-- ASBR1 ---- ASBR2 ---(CORE)  ---PE2
                      --ASBR3 --- ASBR4 ---         ------- PE3

PE1 being the source of BUM.

PE2 and PE3 send IMET route for EVI1/ETAG1 respectively with label 20 and 30 (IR assumed).
ASBR2 and ASBR4 sends the route as Inter-AS A-D routes setting themselves as NH and using PTA type set to IR. Does it set a different label value for each Inter-AS A-D route ?

Zzh> ASBR2/4 does not need to modify the label in PE2/3's IMET routes when they're re-advertised to ASBR1/3. The reason is that for traffic from beyond ASRBR1/3, the PE2/PE3's IMET routes will not be used by ASBR1/3. Rather, the Leaf A-D routes from ASBR2/4 (triggered by PE1's IMET route) will be used. I did realize that additional changes need to be made in section 5.1 (see diffs for the new revision).

I understand that the behavior described above (from your draft) applies to ASBR1 and ASBR3 which will readvertise the same label for both routes but why not doing the label aggregation at ASBR2/4 ?

Zzh> As mentioned above, there is no need on ASBR2/4.

The text talks about I-PMSI A-D routes, but do you confirm that you talk about Inter-AS I-PMSI A-D routes ?

Zzh> When I-PMSI A-D route is used w/o "Inter-AS", it means "Intra-AS I-PMSI" which is IMET route in case of EVPN and type 1 route in case of MVPN. However, when not doing per-AS/region aggregation, an "Intra-AS I-PMSI" route is also re-advertised across AS boundaries, while RFC7117 refers any across-AS routes as "Inter-AS AD routes".
Zzh> That's why I mentioned in this document that "Intra-AS I-PMSI" routes are better called per-PE I-PMSI routes while MVPN's "Inter-AS I-PMSI" routes are called per-AS I-PMSI routes and the name "per-region I-PMSI" route is introduced in this document (since we're talking about aggregation at "region" level).
Zzh> Given all these, in this section I changed to using IMET route instead, which is a per-PE I-PMSI route for EVPN (and this section's context is w/o per-region aggregation).

In addition, you should use normative language in :

"When an ingress PE builds

   its flooding list, multiple routes may have the same (nexthop, label)

   tuple and they will only be added as a single branch in the flooding

   list. >

zzh> The "may" is changed to "might" (it should not change to "MAY"). The "will" is changed to "MUST".
Zzh> Thanks!
Zzh> Jeffrey