BESS Working Group Agenda

Matthew goes through the slides, showing the status
Andrew points that there are a few in Telechat and some documents
should soon be in RFC editor
The virtual-ES draft had a lot of comments and was sent back to WG.
Ali mentions that the changes are minimum and the review should be
quick.
Sasha asks about the state of the BESS and L2VPN YANG models.
Jeff Hass says that BGP yang model is now stable, and this was one
of the dependencies for the BESS models using BGP.
There will be more discussions if there is interest in the WG
Andrew goes through the state of the main documents in his hands.
Also Andrew goes to the mike and discusses the quality of the
documents that get to WG LC.
Document quality is an issue. Real issues with grammar and typos.
Some of them make the docs difficult to understand. We need to make
them readable and high quality.
We will create a review team at WG level to make sure the documents
do not progress till these issues are fixed. Group of people ready
to step up and fix grammar.
The directorate does a good job, but they may not get to all
documents.
Jorge requests to consider the srv6 arguments in BGP services draft
to go immediately to WG adoption since it is almost an RFC9252
errata

Jorge goes thru the main concepts of the draft and history
Main issue with DPATH being solved with new revision 08.
New version 09 will be published with more text on the security
considerations section.
Jeff says at the mike that a new review is needed by Sue as the
other IDR chair

Jorge presents an optional procedure to simplify the EVPN aliasing
operation
Big debate including Ali, Sami and Alex on the mike. With arguments
in favor and against.
- [Ali] Concern on creating more ECMP addresses. Aggregate
  address is already best common practice. MAC IP route is the
  larger volume for control plane. All active multihoming is
  flexible.
- [Sasha] Need to address troubleshooting operations.
- [Sami] I like underlay convergence.
- [Alex] reduction of quarter million routes
- [Ali] reduction in MAC IP routes would be an order bigger
Jeff Tantsura mentions that the draft needs to analyze the
operations and troubleshooting impact of this draft "ECMP-set"
without too much A-D routes, efficient forwarding A-D per EVI routes
are supressed for ES, anycast VTEP address is removed from underlay
if

Patrice encourage people to review the draft and provide feedback
and support to progress it

Ali goes thru the new changes needed for EVPN E-Tree
Sasha mentions that he’d like to see a section stating what the
changes are, compared to the baseline RFC8317. Similar to what’s
been done with rfc7432bis.

Before starting, Matthew mentions that this draft may not belong to
BESS since there are no BGP aspects at all. Sami mentions that they
will add BGP signaling.
Sami presents the draft
Big debate among Sami and Ali. Ali mentions this is covered by
RFC7438 for static vxlan and it shouldn’t be taken by the WG
Jorge mentions that the document might belong to PALS, since it is
an improvement over PW based VPLS. Jorge also mentions that the use
of “anycast IP per ES” in the draft is not accurate since Ethernet
Segment is an EVPN concept and this document is not using any EVPN
procedures, at all.

Krishna presents an update, this time no NLRI change is required in
the RR
Jorge asks about the interaction between the state created by
snooping DHCP and the same state created by proxy-arp/nd (RFC9161)
or arp/nd on IRBs.
Sasha asks whether there is any implementation yet. Krishna asnwers
that there is code but not shipping code yet.
draft-kaliraj-bess-bgp-sig-private-mpls-labels-06 Kaliraj Vairavakkalai 5 min
Kaliraj presents this draft
No questions asked

Jeffrey presents a hybrid solution between inter-as model B and C,
where the ASBRs change the next hop to self but they do not change
service-labels, and add a second label for transport (as opposed to
use BGP LU for that).
Jorge mentions that the multiple label NLRI solution can be used for
IPVPN but not with EVPN (RFC8277 does not define it for EVPN, only
for SAFIs 4 and 128). Also EVPN uses already multiple labels in some
NLRIs (e.g. route type 2).
Jeffrey says that due to that the use of the Tunnel Encap Attribute
(TEA) instead of multiple labels, might be better. Jorge agrees.

Gyan goes thru the latest changes. Testing for these drafts is
progressing well.
Jeff T. goes to the mike and states that vendors should do this kind
of testing for other things too, and that this is a great
initiative.

If Time Permits