Re: [Idr] FW: [bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

["Rabadan, Jorge (Nokia - US/Mountain View)" <[e-mail]>]

Hi Sue,

My apologies for the delay.

Thank you very much for your review!
We’ve just published rev 06 which addresses some of your comments.

Please see below in-line with [jorge].

Thanks.
Jorge


From: BESS [mailto:[e-mail]] On Behalf Of Susan Hares
Sent: Tuesday, July 27, 2021 12:19 PM
To: [e-mail]
Cc: 'idr-chairs'; [e-mail]
Subject: [bess] Review of draft-ietf-bess-evpn-ipvpn-interworking-05.txt

Bess chairs reminded me that IDR WG was requested at IETF 110 to review draft-ietf-bess-evpn-ipvpn-interworking-05.txt. Since we did not receive reviews from the IDR WG, the IDR chairs have taken on the task of reviewing this document.

Full review is at:
https://trac.ietf.org/trac/idr/wiki/Hares-review-draft-ietf-bess-evpn-ipvpn-internetworking-05
High level points at:
https://trac.ietf.org/trac/idr/wiki/draft-ietf-bess-evpn-ipvpn-interworking

Summary Review:
========
The desire of users to have gateways between EVPNs and IPVPNs is evident due to the deployment of these technologies in the market place.  The BESS chairs request is due to the changes made to BGP in addition of a BGP Attribute and changes to RFC4271’s route selection.  In addition, the IDR and BESS chairs have begun to discuss additional BGP error handling for embedded NRLIs beyond RFC7606.

This email is about 6 high-level issues in this draft and major editing issues.  It does not consider editorial issues in the text.

Deployment information on this draft draft-ietf-bess-evpn-ipvpn-interworking would help in the consideration of solutions to these high-level issues.  If this specification has 2 implementations, then these implementation teams may be able to quickly fill in the missing pieces of the document.
<<<<<<<<<<<<<<
[jorge] The document has several implementations. In particular, Nokia has a full implementation of this draft. Also interoperability across implementations has been recently demonstrated.
<<<<<<<<<<<<<<

=======
High level technical issues:

1) Lack of error handling for NLRIs which carry semantics beyond prefixes.

RFC7606 focused on the error handling for prefixes accompanied by attributes and
Communities (basic and extended) specified by RFCs 4271, 4360, 4456, 4760,
5543, 5701, 6368.

The embedded prefixes which combine prefixes with external information
(RD, EVI, ET, MPLS label, Domain, SID, and other tags) create a new  class of errors where the packet can be well-formed and invalid.   The handling of this information requires
careful consideration of the error handling.  The technology specified in this draft does
not consider the error cases of well-formed and invalid.

The IDR chairs suggest that this type of error handling should be defined as a general BGP functionality to expand RFC7606 to the embedded prefixes by the IDR WG.  This general functionality will then need to be applied to the handling of embedded prefixes.

This draft and existing RFCs (e.g. RFC7432) would be updated with the new error handling.

<<<<<<<<<<<<<<
[jorge] I fail to see if any action specific to this document is required from the above point. Seems a generic statement that applies to existing standards track documents that define NLRIs in EVPN, but not to this document specifically. This document does not define any new NLRI, and therefore no action related to (1) is needed. Can you please confirm?

<<<<<<<<<<<<<<



2) Domain BGP Path Attribute (section 4) debugging and scaling

Domain Path IDs provide parallel numbering scheme that does not have a universal definition.  Debugging these Domain IDs in the Internet wild without this definition seems difficult at best.  It is unclear why the Domain IDs did settle on ASN (4 byte) plus some identifier.  There are numerous private AS numbers that can be used for DC tenants.

The automatic generation of AS numbers based on the starting point of private as numbers should take care of most Data Center automation tools.  Why does this specification stick with AS numbers?

<<<<<<<<<<<<<<<<<<<<<<
[jorge] the domain-id is really a 6-byte arbitrary number, it does not need to contain an ASN, but the authors thought it could be convenient for the operator give it a structure with a global and a local identifiers, where the global id may or may not match the ASN. Again, only on those cases that it makes sense for the operator, and if it helps the troubleshooting and debugging. If it helps, we can clarify that? For instance, we could make the following change:

OLD:

   o  DOMAIN-ID is a 6-octet field that represents a domain.  It is

      composed of a 4-octet Global Administrator sub-field and a 2-octet

      Local Administrator sub-field.  The Global Administrator sub-field

      MAY be filled with an Autonomous System Number (ASN), an IPv4

      address, or any value that guarantees the uniqueness of the

      DOMAIN-ID when the tenant network is connected to multiple

      Operators.

NEW:



   o  DOMAIN-ID is an arbitrary 6-octet field that represents a domain.  It is

      composed of a 4-octet Global Administrator sub-field and a 2-octet

      Local Administrator sub-field.  The Global Administrator sub-field

      MAY be filled with an Autonomous System Number (ASN), an IPv4

      address, or any value that guarantees the uniqueness of the

      DOMAIN-ID (when the tenant network is connected to multiple

      Operators) and simplifies troubleshooting and debugging.
<<<<<<<<<<<<<<<<<<<<<<



Error handling: (section 4 – pages 11-14)
The error handling of the DPATH seeks to define:
(4.a) add/delete/change conditions for transit routes and locally generated routes
(4.b) malformed DPATH attributes.

It does not define error conditions if the syntax conditions
cause (4.a) to fail.
<<<<<<<<<<<<<<<<<<<<<<
[jorge] not sure if I understand your 4.a. The document specifies under what conditions D-PATH is added, and modified (new domain-id prepended). It also specifies the propagation between ISF SAFIs on Gateways in section 5. Can you please be more specific on what things you are missing so that we can clarify better? Maybe an example would help. Sorry if I’m missing something.
<<<<<<<<<<<<<<<<<<<<<<


3) Route selection process modifies the RFC4271 and may not scale

This draft modifies the RFC4271 to include D-PATH (page 17) without providing a solid
reasoning why it is necessary and why it scales.  Proof of the scalability may be included in another document or by public reports. As the topics of the ANRW indicates, BGP research for scalability of an application is always a “hot” research topic.

The definition of the BGP route selection changes (page 17)  #3 and 4 is not tightly defined using an example rather that specification. Any proposed changes to the BGP route selection should be done in formal language for changes to the text.

Language such as “could possible leave” or “by default” is not specific (page 17) is not specific enough.

<<<<<<<<<<<<<<<<<<<<<<
[jorge] About scale:
D-PATH was added to provide visibility and avoid loops in Service Provider networks, where multiple Gateways are deployed, for ISF SAFIs 128 and 70. So VPNs really. We later added SAFI 1, mostly due to PE-CE routes, but this is not envisioned to be used in the wide Internet, so I don’t think scale would be an issue. For SAFI 1 among Providers, the AS-PATH already provides the visibility and loop protection needed. Note that D-PATH is only added or modified in the context of an IP-VRF, and it is NOT modified by a router if no IP-VRF is present. We can add some text about this, if it helps?

About the BGP route selection changes, let me know if the following changes we made in rev 06 remove your concerns:

OLD:

<snip>
   4.  Steps 1-3 could possibly leave Equal Cost Multi-Path (ECMP)
       between non-EVPN and EVPN paths.  By default, the EVPN path is
       considered (and the non-EVPN path removed from consideration).
       However, if ECMP across ISF SAFIs is enabled by policy, and one
       EVPN path and one non-EVPN path remain at the end of step 3, both
       path types will be used.
<snip>

NEW:

<snip>

   4.  If Steps 1-3 leave Equal Cost Multi-Paths (ECMP)
       between non-EVPN and EVPN paths, the EVPN path MUST
       be considered (and the non-EVPN path removed from consideration).
       However, if ECMP across ISF SAFIs is enabled by policy, and one
       EVPN path and one non-EVPN path remain at the end of step 3, both
       path types MUST be used.

The above process modifies the [RFC4271] selection criteria to include
the shortest D-PATH so that operators minimize the number of Gateways
and domains through which packets need to be routed.
<snip>
<<<<<<<<<<<<<<<<<<<<<<



4) Error handling in Gateway PE (section 8)  between different AFI/SAFI prefixes is unclear

This draft defines translation between certain embedded prefixes see table below.  The interworking of the embedded prefix depends the basic error handling working correctly for embedded prefixes (#1) and the Domain Path (#2). Since these two items are unclear AND
I do not see definitions “well-formed but invalid” case is not covered for this draft.

AFI with SAFIs
1 – 1, 128
2 -  1, 128
25 – 70

Section 8 attempts to provide this rules as an example.  However section 8 requires the following syntax validity checks beyond well-formed:
1) It must be a ISF route from AFI/SAFI pairs + allowed by policy (?)
2) for gateway PE advertising ISF routes, must
    a) include a D-PATH attribute
    b) EVPN to other VPNS must append Domain with
2) The domain inside D-PATH must have a specific Domain-ID
3) determination on what Route Distinguisher or Route Targets are valid,
4) determination on what support for import/export of routes with different RD and RTs.

<<<<<<<<<<<<<<<<<<<<<<
[jorge] section 8 has been re-written in rev 06 clarifying the rules based on your feedback. Please let us know if this helps.
<<<<<<<<<<<<<<<<<<<<<<


5) Section 7 – normative or informative

It is unclear if section 7 provides normative details on the Route Reflector or informative.  It is also unclear if the EVPN forwarding constraints are normative or informative.
<<<<<<<<<<<<<<<<<<<<<<
[jorge] section 7 has been re-written in rev 06 to clarify this. Please let us know if this helps.
<<<<<<<<<<<<<<<<<<<<<<

Phrases like “as a consequence of this, the indirection provided by RT’s recursive resolution and its benefits in a scaled network, will not be available in all PEs in the network” (page 20) is worrisome.  If it is normative, then is this solution only partial?
<<<<<<<<<<<<<<<<<<<<<<
[jorge] We modified the text in rev 06. This is informative, and it simply says that if the gateway PE selects an IPVPN route for prefix P instead of an EVPN route, the EVPN specific attributes or NLRI fields are not available. Simply because IPVPN and EVPN routes are different.
<<<<<<<<<<<<<<<<<<<<<<


6) Section 11 security considerations needs to align with document

The proof of phrase “a correct use of the D-PATH will prevent control plane and data plane loops in the network”  exhibits facts not in evidence in the document.

The proof of the phrase “incorrect configuration of the DOMAIN-IDs on the gateway PEs may lead to the detection of false route loops and the blackholing of the traffic”  also exhibits facts not in evidence in the document.

The security considerations need to be based on a revised error handling.

It is appropriate to mention that stripping path attributes at a gateway will cause problems.
<<<<<<<<<<<<<<<<<<<<<<
[jorge] we modified the text to mention that last part in rev 06. I hope the rest is clarified with the modified sections 7 and 8. Let us know otherwise please.
<<<<<<<<<<<<<<<<<<<<<<