Hi Suresh,
Thank you for your comments. Please see in-line.
Thanks.
Jorge
From: BESS
Date: Wednesday, November 18, 2020 at 9:40 PM
To: bess@ietf.org
Subject: [bess] Some clarification required for
draft-ietf-bess-evpn-ipvpn-interworking-03
Hi Authors,
I have the following comments on draft-ietf-bess-evpn-ipvpn-interworking-03
version of the draft.
Please see below.
Thanks,
Suresh
4.1. No-Propagation-Mode
This is the default mode of operation.
Comment:
We must not have default mode of operation which could result in loops.
So the default mode of operation must be Uniform-Propagation-mode,
and No-Propagation-Mode should be made optional.
[jorge] the default mode is compatible with the behavior of a non-upgraded
gateway PE. We don’t want to change the behavior automatically upon upgrade;
but we want the operator to explicitly and consciously change it. Sometimes the
desired behavior would be to re-initialize the path attributes when propagating.
Without the D-PATH, loops are avoided today with more manual methods, such us
the use of site-of-origin extended communities and local policy.
--
4.3. Aggregation of Routes and Path Attribute Propagation
- ISF routes that have different attributes of the following type
codes MUST NOT be aggregated: D-PATH, LOCAL_PREF, ORIGINATOR_ID,
CLUSTER_ID, MED or AIGP.
Comment:
The draft can add a rule on D-PATH asking for not aggregating routes
if they have a different D-PATH value. However, the draft must not talk about
other attributes (this is out of scope of the work).
[jorge] aggregation in general may be out of scope, but the aggregation in the
context of a different ISF SAFI is within the scope of this document. Afaik
there is no other document that specifies the interworking between ISF
(inter-subnet-forwarding) SAFIs.
--
5. Route Selection Process between EVPN and other ISF SAFIs
For a given prefix advertised in one or more non-EVPN ISF routes, the
BGP best path selection procedure will produce a set of "non-EVPN
best paths". For a given prefix advertised in one or more EVPN ISF
routes, the BGP best path selection procedure will produce a set of
"EVPN best paths". To support IP/EVPN interworking, it is then
necessary to run a tie-breaking selection algorithm on the union of
these two sets.
Comment:
The above sentence does not convey the context in which the best path is
calculated. Do you mean the following.
For a given prefix present in one or more ISF routes, the BGP best path is
first run in the respective ISF SAFI and then again on the union of
ISF SAFI best paths in the IP-VRF context.
[jorge] text at the beginning of section 5 should be clear, but in any case in
case it helps I added the following. Hopefully it helps:
To support IP/EVPN interworking in the context of
the same IP-VRF receiving non-EVPN and EVPN ISF routes for the same
prefix, it is then necessary to run a tie-breaking selection
algorithm on the union of these two sets.
--
5. Route Selection Process between EVPN and other ISF SAFIs
4- Steps 1-3 could possibly leave Equal Cost Multi-Path (ECMP)
between IP and EVPN paths. By default, the EVPN path is
considered (and the IP path removed from consideration). However,
if ECMP across ISF SAFIs is enabled by policy, and an "IP path"
and an "EVPN path" remain at the end of step 3, both path types
will be used.
Comment:
Referring to non-EVPN paths as IP paths is confusing since EVPN path is
also an IP path
[jorge] good point. I changed it to “non-EVPN path” instead of “IP path” in the
context of ISF SAFIs.
--
7. Gateway PE Procedures
The gateway PE procedures are described as follows:
o A gateway PE that imports an ISF SAFI-x route to prefix P in an
IP-VRF, MUST export P in ISF SAFI-y if:
1. P is installed in the IP-VRF (hence the SAFI-x route is the
best one for P) and
2. PE has a BGP peer for SAFI-y (enabled for the same IP-VRF) and
3. Either x or y is EVPN
Comment:
This above text is unclear and possibly wrong on a couple of points:
- 1. SAFI-x route is the BGP best path for P and
[jorge] we should only propagate the best path… can you please clarify what you
mean?
- The last point brings some ambiguity. As SAFI 1 is considered as an ISF SAFI,
you have to consider all combinations of ISF at the gateway, not only
EVPN <-> something else. The current text could be interpreted in a way that
SAFI 1 <-> SAFI 128 route export is broken and it must not.
[jorge] the spec’s intend was not to specify new things about SAFI 1 <-> 128
interworking, but rather interworking between EVPN and the other ISF SAFIs. But
I see your point, so I removed the third point and left it as:
A gateway PE that imports an ISF SAFI-x route to prefix P in an
IP-VRF, MUST export P in ISF SAFI-y if:
1. P is installed in the
