Subject: Re: [bess] Some clarification required for draft-ietf-bess-evpn-ipvpn-interworking-03

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Tue, 1 Dec 2020 15:54:21 +0000

Hi Suresh,

Thank you for your comments. Please see in-line.
Thanks.
Jorge

From: BESS <[email-masked]>
Date: Wednesday, November 18, 2020 at 9:40 PM
To: [email-masked] <[email-masked]>
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)

--