[bess] I-D Action: draft-ietf-bess-evpn-per-mcast-flow-df-election-10.txt

[internet-drafts]

Internet-Draft draft-ietf-bess-evpn-per-mcast-flow-df-election-10.txt is now
available. It is a work item of the BGP Enabled ServiceS (BESS) WG of the
IETF.

   Title:   Per multicast flow Designated Forwarder Election for EVPN
   Authors: Ali Sajassi
Mankamana Mishra
Samir Thoria
Jorge Rabadan
John Drake
   Name:draft-ietf-bess-evpn-per-mcast-flow-df-election-10.txt
   Pages:   11
   Dates:   2024-04-25

Abstract:

   [RFC7432] describes mechanism to elect designated forwarder (DF) at
   the granularity of (ESI, EVI) which is per VLAN (or per group of
   VLANs in case of VLAN bundle or VLAN-aware bundle service).  However,
   the current level of granularity of per-VLAN is not adequate for some
   applications.[RFC8584] improves base line DF election by introducing
   HRW DF election.  [RFC9251] introduces applicability of EVPN to
   Multicast flows, routes to sync them and a default DF election.  This
   document is an extension to HRW base draft [RFC8584] and further
   enhances HRW algorithm for the Multicast flows to do DF election at
   the granularity of (ESI, VLAN, Mcast flow).

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-per-mcast-flow-df-election/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-per-mcast-flow-df-election-10

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-bess-evpn-per-mcast-flow-df-election-10

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Considering EVPN BFD as a candidate for the WG LC

[Greg Mirsky]

Thank you, Matthew.
Will work on addressing Sasha's comments and questions.

Regards,
Greg

On Thu, Apr 25, 2024 at 3:55 PM Matthew Bocci (Nokia) <
matthew.bo...@nokia.com> wrote:

> We’ve added this to the queue on the BESS WG WiKi (BESS WG - BGP Enabled
> ServiceS | IETF Community Wiki ).
>
>
>
> Authors, please can you also address Sasha’s comments/questions sent to
> the BESS list on 31st March.
>
>
>
> Matthew
>
>
>
> *From: *Jeff Tantsura 
> *Date: *Friday, 22 March 2024 at 04:21
> *To: *Greg Mirsky 
> *Cc: *bess-cha...@ietf.org , BESS ,
> draft-ietf-bess-evpn-...@ietf.org 
> *Subject: *Re: [bess] Considering EVPN BFD as a candidate for the WG LC
>
>
> CAUTION: This is an external email. Please be very careful when clicking
> links or opening attachments. See the URL nok.it/ext for additional
> information.
>
>
>
> Support
>
> > On Mar 20, 2024, at 17:12, Greg Mirsky  wrote:
> >
> > Hi,
> > I concur with Donald regarding the state of the draft-ietf-evpn-bfd
> document. The document is stable and ready for the WG LC. The authors are
> ready and committed to work and address all questions and comments,
> ensuring the expedient progress of the draft.
> >
> > Regards,
> > Greg
> > ___
> > BESS mailing list
> > BESS@ietf.org
> > https://www.ietf.org/mailman/listinfo/bess
>
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

[bess] Questions about route selection in draft-ietf-bess-evpn-dpath-00

[Jeffrey Haas]

Authors,

As part of reviewing ipvpn interworking, I also have done a higher level
review of the new dpath document below.

In section 4.1, the cited rules for route selection change are:

:If none of the tie-breaking rules up to (and including) rule 5
:produces a single route, the router compares the D-PATH attribute in
:the remaining candidate routes:
: 
:1.  The routes with the shortest D-PATH are preferred, hence routes
:not tied for the shortest D-PATH are removed.  Routes without
:D-PATH are considered zero-length D-PATH.
: 
:2.  Then routes with the numerically lowest left-most Domain-ID are
:preferred, hence routes not tied for the numerically lowest left-
:most Domain-ID are removed from consideration.

The first step is consistent with the ipvpn-interworking document.  The
second step is new. What's the motivation for this second step?

A consequence of this second step is that the configured domain ID, when
routes are redistributed between domains, becomes a "hard yank" to influence
routes to pick a specific domain.

I.e.:
- If there are routes with no dpath and routes with at least one dpath, the
  routes with no dpath will win.  Effectively, the current behavior for each
  of the impacted document sections.
- However, if the dpath is at least one, you prefer routes from the domain
  with the "numerially lowest" domain id.

This is somewhat similar to taking BGP's BGP Identifier check at the *end*
of the route selection process and moving it near to the top.  I suspect
this is not what you want.

Other issues:

"numerically lower" isn't clear with respect to a domain-id, especially
with regard to the ISF_SAFI_TYPE component of it.  Is that used?  Ignoring
that, is the result the same as running C's memcmp() on the two six byte
values?

As discussed in the context of the ipvpn interworking draft, changing route
selection after the fact is messy and could in some cases lead to
inconsistent selection within a network.  However, for the route types that
this procedure is recommended for, have you convinced yourselves that
inconsistent selection is fine?  Or will your recommendation be, similar to
the ipvpn interworking draft, that the entire deployment must be upgraded to
support the new procedure?

-- Jeff

On Tue, Apr 02, 2024 at 05:44:06AM -0700, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-bess-evpn-dpath-00.txt is now available. It is a
> work item of the BGP Enabled ServiceS (BESS) WG of the IETF.
> 
>Title:   Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks

[...]

> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-dpath/

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jeffrey Haas]

On Thu, Apr 25, 2024 at 10:08:19AM -0400, Jeffrey Haas wrote:
> ipvpn authors.

A small addendum:

The use of D-PATH Domain IDs for loop detection purposes are split in the
document.

Section 4.d which defines D-PATH mentions two properties:
1. When a looped entry, having been received, may be considered for use even
when it is looped.
2. It MUST NOT be exported.

In traditional BGP-speak, it MAY be eligible circumstantially for selection
in the LocRib, but is ineligible for placement into the AdjRibsOut.

Section 6 covers the changes to route selection when D-PATH is present for
the different forms of ISF routes.  This parallels BGP's route selection
text in RFC 4271, Section 9.1.2.  However, BGP's section discusses the AS
loops as part of that section.

I'd recommend that a portion of the text relating to route selection and
loops be placed in the ipvpn document's section 6.  Having all of the rules
in a single place will likely avoid certain classes of implementation bugs
and will ease in citation of the rules for the future.

-- Jeff

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Jeffrey Haas]

ipvpn authors.

Here is my long delayed review for draft-ietf-bess-evpn-ipvpn-interworking using
version 10.  To aid in review, I'm using the idnits output for this version of
the draft to help identify line numbers.

Note, idnits is flagging the following, which needs expansion to make the RFC
Editor happy.


  ** The abstract seems to contain references ([RFC4271]), which it
 shouldn't.  Please replace those with straight textual mentions of the
 documents in question.

35 modifies the BGP best path selection for multiprotocol BGP routes of
36 SAFI 128 and EVPN IP Prefix routes, and therefore this document
37 updates the BGP best path selection in [RFC4271], but only for IPVPN
38 and EVPN families.

Here is the citation to 4271 that it wants expanded according to the nits rules.

419 4.  Domain Path Attribute (D-PATH)

[...]

424Similar to AS_PATH, D-PATH is composed of a sequence of Domain
425segments.  Each Domain segment is comprised of , where the domain segment value is a
427sequence of one or more Domains, as illustrated in Figure 6.  Each
428domain is represented by .

The format for D-PATH being a sequence of Domain segments has been there since
the beginning, so note that I'm not recommending any format changes.  It
probably would have simplified things since there is no similar segment type to
motivate needing to differentiate the sequence entries from each other.  For
example, validation becomes "is the attribute length divisible by 7". :-)

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

:  1) if the first path segment of the AS_PATH is of type
: AS_SEQUENCE, the local system prepends its own AS number as
: the last element of the sequence (put it in the leftmost
: position with respect to the position of octets in the
: protocol message).  If the act of prepending will cause an
: overflow in the AS_PATH segment (i.e., more than 255 ASes),
: it SHOULD prepend a new segment of type AS_SEQUENCE and
: prepend its own AS number to this new segment.

The normative text describing prepending Domains to the D-PATH attribute needs
some text describing when new segments are generated.

4460 1 2 3 4 5 6
447+---+---+
448|Global |  Local|
449|Admin  |  Admin|
450+---+---+

452   Figure 6: D-PATH Domain Segment

454*  The domain segment length field is a 1-octet field, containing the
455   number of domains in the segment.

457*  DOMAIN-ID is a 6-octet field that represents a domain.  It is
458   composed of a 4-octet Global Administrator sub-field and a 2-octet
459   Local Administrator sub-field.  The Global Administrator sub-field
460   MAY be filled with an Autonomous System Number (ASN, Public or
461   Private), an IPv4 address, or any value that guarantees the
462   uniqueness of the DOMAIN-ID (when the tenant network is connected
463   to multiple Operators) and helps troubleshooting and debugging of
464   D-PATH in ISF routes.  The Local Administrator sub-field is any
465   local 2-octet value, and its allocation or configuration is a
466   local implementation matter.

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.

However, the comparison with Extended Communities breaks down somewhat in that
the domain-id does not provide an additional qualifier on the semantics of the
Global Admin field.  For Extended Communities, that's the type/subtype.

>From a protocol perspective, this is "fine".  From an operational perspective,
it's somewhat problematic.  Consider two implementations: One which treats
the field as an unsigned 32-bit number; perhaps an AS number, or "just a
number". The other has the configuration semantics of an IPv4 dotted-quad
address.  

Clearly it's possible to map each implementation's configuration type to the
other.  But it creates operational friction.

Another place this ambiguity becomes a challenge will be in future YANG modules.
At this point, I'm unable to find reference to D-PATH in the IETF evpn YANG
module (casual review) or in OpenConfig.  In 

Re: [bess] Considering EVPN BFD as a candidate for the WG LC

[Matthew Bocci (Nokia)]

We’ve added this to the queue on the BESS WG WiKi (BESS WG - BGP Enabled 
ServiceS | IETF Community Wiki).

Authors, please can you also address Sasha’s comments/questions sent to the 
BESS list on 31st March.

Matthew

From: Jeff Tantsura 
Date: Friday, 22 March 2024 at 04:21
To: Greg Mirsky 
Cc: bess-cha...@ietf.org , BESS , 
draft-ietf-bess-evpn-...@ietf.org 
Subject: Re: [bess] Considering EVPN BFD as a candidate for the WG LC

CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See the URL nok.it/ext for additional information.



Support

> On Mar 20, 2024, at 17:12, Greg Mirsky  wrote:
>
> Hi,
> I concur with Donald regarding the state of the draft-ietf-evpn-bfd document. 
> The document is stable and ready for the WG LC. The authors are ready and 
> committed to work and address all questions and comments, ensuring the 
> expedient progress of the draft.
>
> Regards,
> Greg
> ___
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess
___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess