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
_______________________________________________
BESS mailing list -- bess@ietf.org
To unsubscribe send an email to bess-le...@ietf.org
