[bess] Re: Review of draft-ietf-bess-evpn-ipvpn-interworking-10

[Jeffrey Haas <[e-mail]>]

Jorge,

On Mon, Jun 17, 2024 at 08:19:49PM +0000, Jorge Rabadan (Nokia) wrote:
> > Having reviewed the full document for the procedure, there's discussion that
> > Domains are prepended to the D-PATH similar to the AS_PATH.  However, part of
> > BGP's procedures for AS_PATH effectively is how to minimize segments.  From
> > RFC 4271, Section 5.1.2.b.1
> 
> > The normative text describing prepending Domains to the D-PATH attribute needs
> > some text describing when new segments are generated.
> 
> [jorge] I added the following text, let me know what you think:
> 
> 
> a.      Identifies the sequence of domains, each identified by a <DOMAIN-ID:ISF_SAFI_TYPE> through which a given ISF route of type IPVPN or EVPN has passed.
> 
> o    This attribute list MAY contain one or more segments. Each segment's Domain Segment Length MUST be equal or greater than one.
> 
> <snip>
> 
> o    In order to minimize the number of segments in the D-PATH attribute, the local gateway PE prepends its own domain as the last element of the domain segment. If the act of prepending a new domain causes an overflow in the domain segment (i.e., more than 255 domains), the local gateway PE MUST prepend a new segment and prepend its own domain to this new segment.

That works.

> > The intent for domain id appears to be that the contents of the type is
> > "structured", in the sense that it has a "global" field and a "local" field is
> > clear.  The related intent here appears to be that the contents are opaque.
> > Several examples for the Global Admin field are offered.  The fact that the
> > examples are aligned with RFC 4360 Extended Community types is perhaps not a
> > surprise.
> > [...]
> > Consider whether the intended opaqueness and flexibility will be worth the
> > future contention over display formats in interoperable management systems.
> 
> [jorge] The format of the global admin value is purposedly kept lose so that the spec is not closed to a specific structure that may be useful. In reality, there are only two ‘structures’ – ipv4 address format or an unsigned integer (which can match an ASN). Based on the implementations I am aware of, and that we tested at the EANTC event over the years, I can see that most vendors use the 4-octet-uint:2-octet-uint format for global-admin:local-admin values. I only know of one vendor that allows the ipv4 address format as an option. As you say, this does not represent a functional interoperability issue. But I see your point about YANG implementations using different structures. I added the following, which I think should be sufficient to guide people to use opaque unsigned integers as structure, while not forbidding the use of other structures:
> 
> “The representation of the Global Administrator and Local Administrator values as opaque unsigned integers is RECOMMENDED.”

That works.  It'll also provide the relevant guidance when it's time to do
the YANG work.

> > 546        c.  For a local ISF route, i.e., a configured route or a route
> > 547            learned from a local attachment circuit, a gateway PE has three
> > 548            choices:
> >
> > There are three MAYs above.  Is there a motivation to not make one of these the
> > RECOMMENDED case?  Some of the normative text later on, e.g. Section 8, has
> > explicit procedure for this.
> 
> [jorge] I added this in option 3, let me know if it helps:
> 
> 
> “3. It MAY advertise that ISF route with a D-PATH attribute that contains a configured domain specific to its local ISF routes into one or more of its configured domains, in which case the D-PATH attribute in each copy of the ISF route is initialized with a ISF_SAFI_TYPE of 0 and the DOMAIN-ID for the local ISF routes. This DOMAIN-ID MUST be globally unique and MAY be shared by two or more gateway PEs. Although the three options help detect control plane loops, this option 3 is RECOMMENDED, since it is the option that provides more information about the differentiated origin of the route (it uses a DOMAIN-ID and ISF_SAFI_TYPE that identifies the route as a local gateway route).”

That addresses the comment.

> 
> 
> 
> 629        g.  The following error-handling rules apply to the D-PATH attribute:
> 
> 631            1.  A received D-PATH attribute is considered malformed if it
> 632                contains a malformed Domain Segment.
> 
> 634            2.  A Domain Segment is considered malformed in any of the
> 635                following cases:
> 
> 637                *  The Domain Segment length of the last Domain Segment
> 638                   causes the D-PATH attribute length to be exceeded.
> 
> Is the intention of this sentence to say "the remaining content is longer than
> the d-path path attribute length?  (I generally refer to such overrun issues an
> "enveloping" problem.)
> 
> [jorge] another way of explaining would be: when parsing the domain segments, the last one has a length that is greater than the d-path attribute length minus the sum of the lengths of all the already parsed domain segments. To me the above should be clear, but let us know if you prefer a different wording.

Since this is the eveloping issue, perhaps a slight tweak to the verbiage.
How about:

The length of Domain Segment is longer than the D-PATH attribute that
contains it.

> > 651            5.  In case a PE receives more than one D-PATH attribute with a
> > 652                route, the PE SHALL process the first one in the list and not
> > 653                store and propagate the others.
> > 
> > This point goes against RFC 4271's requirement to not duplicate path attributes.
> > RFC 7606 doesn't loosen this stricture.
> 
> [jorge] hmm.. can you please elaborate a bit? Do you mean that this point is not needed because the originating PE should not duplicate the D-PATH attribute in the first place? This is just saying what to do in case that happens (even if it shouldn’t).

Basically, "Path Attribute type 36, D-PATH, MUST NOT occur more than once in
the BGP UPDATE's Path Attributes".

As written above, you're saying more than one is fine.

> > 766     5.3.  Aggregation of Routes and Path Attribute Propagation
> > [...]
> > 
> > 790        *  An ISF aggregate route SHOULD NOT be advertised unless all the
> > 791           contributing ISF routes have the same D-PATH value.  If there is
> > 792           at least one contributing ISF route that has different D-PATH, the
> > 793           gateway PE SHOULD advertise each contributing ISF route with its
> > 794           own D-PATH (prepended with the gateway's domain).  An
> > 795           implementation MAY override this behavior, via policy, to
> > 796           advertise an ISF aggregate route without D-PATH in case the
> > 797           contributing routes did not have the same D-PATH value.
> > 
> > While the D-PATH is built as a vector rather than as a set, the loop prevention
> > characteristics are "does the receiving domain exist in the D-PATH attribute".
> > I.e., it's set membership as an operation.
> > 
> > "the same D-PATH value" implies exact match.  Would it be more precise to
> > compare D-PATH attributes that do not have the same members?
> > 
> > A secondary consideration is that the ISF_SAFI_TYPE is irrelevant to loop
> > detection and is only informational.  Thus, for aggregation purposes, are the
> > following D-PATHs equivalent?
> > 
> > <65001:1:0>
> > <65001:1:EVPN>
> > <65001:1:IPVPN>
> 
> [jorge] good point. I agree it is more accurate to refer to D-PATH DOMAIN-ID members. I changed it to:
> 
> 
> “An ISF aggregate route SHOULD NOT be advertised unless all the contributing ISF routes have the same D-PATH DOMAIN-ID members. If there is at least one contributing ISF route that has a different D-PATH DOMAIN-ID, the gateway PE SHOULD advertise each contributing ISF route with its own D-PATH (prepended with the gateway's domain). An implementation MAY override this behavior, via policy, to advertise an ISF aggregate route without D-PATH in case the contributing routes did not have the same D-PATH DOMAIN-ID members.”

I recommend a very minor tweak to the above:
“An ISF aggregate route SHOULD NOT be advertised unless all the contributing
ISF routes have the same D-PATH DOMAIN-ID members, regardless of their
order."

Basically, emphasize that order is unimportant.

> > Note that while this practice was established in RFC 1997, modern
> > implementations do not always provide such aggregation of communities.
> > Minimally, I recommend this be changed from MUST to SHOULD.
>
> [jorge] ok, it’s a fair point. Changed to “SHOULD”.

Great.

> > 812     6.  Route Selection Process for ISF Routes
> > [...]
> > 875        Example 1 - PE1 receives the following routes for IP1/32, that are
> > 876        candidate to be imported into IP-VRF-1:
> > 
> > 878        {SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=(100,200)}
> > 879        {SAFI=EVPN, RT-5, Local-Pref=100, AS-Path=(100,200)}
> > 880        {SAFI=128, Local-Pref=100, AS-Path=(100,200)}
> > 
> > 882        Selected route: {SAFI=EVPN, RT-2, Local-Pref=100, AS-Path=100,200]
> > 883        (due to step 3, and no ECMP).
> > 
> > I suspect this example, and the following one, intend "RT-" to be "RD-".
> > The RT in question should be the same for the candidate routes for the VRF and
> > the RD is used to distinguish those routes.
> 
> [jorge] in the example RT-2 is “route type 2”, whereas RT-5 is “route type 5”, as in the terminology section. So I left it as is for the moment. Let us know if you are ok with it.

Okay, let's leave it if it's consistent with existing EVPN examples.

> > 894     7.  Composite PE Procedures
> >
> > It may be worth highlighting that while the procedure here is clear, that a note
> > regarding prioritzing the announcement of the EVPN route prior to the IPVPN
> > route may be a good idea.  According to the route selection rules, the EVPN
> > route will win vs. the same ISF carried in an IPVPN route.  As noted in the
> > following section:
>
> [jorge] to me this is implementation specific, but it may still be a good point to document, thanks. I added this:
> 
> 1.      The composite PEs MUST advertise the same IP prefixes in each ISF SAFI to the Route Reflector (RR). For example, in Figure 7<https://author-tools.ietf.org/api/export/e90bacfc-96a6-46a2-bbc7-53497e930289/draft-ietf-bess-evpn-ipvpn-interworking-11.html#composite-pe-example>, the prefix IP1/24 is advertised by PE1 and PE2 to the Route Reflector in two separate NLRIs, one for AFI/SAFI 1/128 and another one for EVPN. If the two routes are advertised with the same set of attributes, the remote Composite PE selection process will pick up the EVPN route over the IPVPN route (as per Section 6<https://author-tools.ietf.org/api/export/e90bacfc-96a6-46a2-bbc7-53497e930289/draft-ietf-bess-evpn-ipvpn-interworking-11.html#sect-6>) For this reason, prioritizing the announcement of the EVPN route prior to the IPVPN route is an OPTIONAL optimization, since, if the EVPN route arrives at the composite PE first, the selected route is not replaced by the IPVPN route later.

OPTIONAL is a fine way to handle this, thanks.

> > 1178    10.  BGP Error Handling on Interworking PEs
> > [...]
> > 
> > 1190       *  The Interworking PEs do not introduce any new error-handling rules
> > 1191          for UPDATES received with NLRIs and BGP Path Attributes defined in
> > 1192          other specifications.  Interworking PEs follow the error-handling
> > 1193          defined in the specification for the specific NLRI or BGP Path
> > 1194          Attribute.  In other words, UPDATES for BGP IP routes MUST follow
> > 1195          the error-handling procedures of [RFC4760] [RFC8950], UPDATES for
> > 1196          IPVPN routes MUST follow the error-handling rules of [RFC4364]
> > 1197          [RFC4659], UPDATES for EVPN MAC/IP routes MUST follow the error-
> > 1198          handling of [RFC7432] [RFC8365] and UPDATES for EVPN IP Prefix
> > 1199          routes MUST follow the error-handling in [RFC9136].
> > 
> > 1201       *  Received UPDATE messages to be programmed in IP-VRFs supporting
> > 1202          Segment Routing for IPv6 data path (SRv6) follow the error-
> > 1203          handling rules defined in [RFC9252].
> > 
> > What's the motivation for the statements above?  In general, when new BGP
> > attributes are used, the error handling for those attributes is expected also to
> > be used.  The above text seems to imply, "don't do that".
> 
> [jorge] not sure if I understand. The only motivation for those statements is to remind the reader that the error-handling defined in other specs related to those routes are also applicable, and they should be aware of it. Do you mean that is not needed to say and we should remove those two points?

The text can be construed as being proscriptive as to "only these procedures
are used".

One way to address this is to rephrase slightly so that you're just
referring readers to some of the necessary procedures rather than trying to
limit them.

Perhaps:
The Interworking PEs do not introduce any new error-handling rules
for UPDATES received with NLRIs and BGP Path Attributes defined in
other specifications.  Implementors should refer to the appropriate error
handling documents for each of the supported route types.  These include:

BGP IP: [RFC4760] [RFC8950]
IPVPN: RFC4364] [RFC4659]
EVPN MAC/IP: [RFC7432] [RFC8365] 
EVPN IP Prefix: [RFC9136].

Received UPDATE messages to be programmed in IP-VRFs supporting
Segment Routing for IPv6 data path (SRv6): [RFC9252].

Although, consider perhaps specifying the full afi/safi/route-type.



> > 1265    12.  Security Considerations
> > I don't know that the security directorate would consider D-PATH a "security"
> > tool.  I'd suggest stating instead:
> 
> "Section 4 introduces the use of the D-PATH attribute, which provides a loop
> prevention mechanism that is used by gateway PEs that propagate ISF IPVPN/EVPN
> routes between domains."
> 
> [jorge] ok, I made the suggested change. Thanks!

Thanks.

-- Jeff