Hi Jorge, Thanks for the revision. I will start the adoption process.
A couple of further questions below. I snipped text for clarity. --------------- 4.1.2. IP A-D per ES route and SRv6 Transport When an SRv6 transport is used, each IP A-D per ES route MUST carry an SRv6 L3 Service TLV within the BGP Prefix-SID attribute [RFC9252]. The Service SID MUST be of value 0. The SRv6 Endpoint Behavior SHOULD be one of these End.DT46, End.DT4, End.DT6, End.DX4, or End.DX6. What is the purpose of the above? [Jorge] A-D per ES routes carry a BGP encapsulation extended community in case of VXLAN, MPLS, etc, and an SRv6 Service TLV in case of SRv6, as also described in draft-trr-bess-bgp-srv6-args. Zhz> It's good to clarify that (like what you did for 4.1.3). --------------- 4.3. Handling Silent Host MAC/IP route for IP Aliasing ... Thus to avoid blackholing, when PE2 detects loss of reachability to PE1, it should trigger ARP/ND requests for all remote IP prefixes received from PE1 across all affected IP-VRFs. This will force host H1 to reply to the solicited ARP/ND messages from PE2 and refresh both MAC and IP for the corresponding host in its tables. This section talks about the silent host MAC/IP route. I suppose there is no similar mechanism for Section 4.2 if a single routing session from the CE to one of the PEs? [Jorge] 4.2 talks about the synchronization of the ip routes on the PEs attached to the same ES, and 4.3 about the synch of the ARP/ND entries on the PEs. Unless a use case is explicitly mentioned, the sections from 2. on are relevant to all use cases - 1.1, 1.2 and 1.3. I added a sentence at the end of section 2. Zzh> What I meant was, if the routes that PE1 learns are from a single routing session (like BGP) vs. ARP/ND, then PE2 can't learn them proactively even after it detects PE1's failure. Is that correct? Zzh> Is "refresh both MAC and IP for the corresponding host in its tables" for PE2? The way the text reads, it's H1. Zzh> Additionally, I noticed the following right after the above quoted text: Even in core failure scenario on PE1, PE1 must withdraw all its local layer-2 connectivity, as Layer-2 traffic should not be received by PE1. Zzh> I struggled with "withdraw all its local layer-2 connectivity". I finally think you probably mean "bring down all its local layer-2 connectivity". Is that right? -------------- For the following normalization rule: ... If the ingress PE learns a prefix P via a non-reserved ESI RT-5 route with a weight (for which IP A-D per ES routes also signal a weight) and a zero ESI RT-5 that includes a weight, the ingress PE will consider all the PEs attached to the ES as a single PE when normalizing weights. As an example, consider PE1 and PE2 are attached to ES-1 and PE1 advertises an RT-5 for prefix P with ESI-1 (and EVPN Link Bandwidth of 1). Consider PE3 advertises an RT-5 for P with ESI=0 and EVPN Link Bandwidth of 2. If PE1 and PE2 advertise an EVPN Link Bandwidth of 1 and 2, respectively, in the IP A-D per ES routes for ES-1, an ingress PE4 SHOULD assign a normalized weight of 1 to ES-1 and a normalized weight of 2 to PE3. What is the rationale for normalizing the weight of ES-1 to 1? [Jorge] the ES represents a single CE, and the weight of the RT-5 with ESI=1 influences the number of flows for that CE. So if the remote PE gets two RT-5s: RT-5 (weight=1) and RT-5 (weight=2) it should apply the weights based on those RT-5s. Zzh> I still don't get the rational. PE1/PE2/PE3 advertise link bandwidth 1/2/2 respectively, yet we normalize ES-1 to weight 1? Zzh> Thanks. Zzh> Jeffrey Thanks. Jeffrey Juniper Business Use Only
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess