Hi Suresh, Thank you for your comments. Please see in-line. Thanks. Jorge
From: BESS <bess-boun...@ietf.org> Date: Wednesday, November 18, 2020 at 9:40 PM To: bess@ietf.org <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: <snip> 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. <snip> -- 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 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) --
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess