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.
===
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.
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?
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.
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.
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
