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
