Working group update Chairs 15 min

Jeffrey and Matthew go through the state and agenda.
There is one presentation dropped in the agenda. So we'll try to
accommodate the extra one.
New AD taking over - Gunter - welcome! and thanks Andrew for his work.
One new RFC and some docs in RFC queue. Quite a few one under AD or IESG
review.
On the sdwan draft, there are two DISCUSSES. Responses sent but still
waiting for the ADs to go yes or not.

Ali: why are the docs showing "with AD" in the slides? what are the
pending actions? especially the one on virtual ES - actions should be
cleared already.

Chairs: yes, it was to be followed up by the new AD.

Gunter: I'll follow up, I have been the AD for just 5 minutes :-)

Some documents under shepherds’ review. The evpn control plane for
geneve draft is waiting for implementations. Two docs failed the WGLC,
the l2gw gateway draft and the evpn-ipvpn-interworking draft. Second one
waiting for the the IDR chairs to review.

Jeff Haas: totally on me, need to clear my queue and get back.
Matthew: after Jeff's review we should do another short WG LC

Himanshu: I want the l2gw draft to progress.

A few docs ready for WGLC:
ac-aware draft - some changes need to be done and questions answered.
mcast flow DF election - expired, needs refresh
extended optimized ir - comments addressed
7242bis - comments addressed, GENART review started. DF election
procedure needs to be clarified
mcast controller draft - reviews are addressed.

Greg: is this an exhaustive list of docs considered for LC?
Matthew: no
Greg: need to advance the lsp-ping and bfd EVPN drafts, they are ready
to progress.
Matthew: send us an email

bgp mcast draft comments addressed.
seamless evpn mvpn draft - comments added, need follow up
srv6-args - request for expedited LC, due to its impact on RFC9252. It
is very important since there are implementations and we want to avoid
issues with new implementors.

About the List for adoption call:
long queue
the first one (dpath), call closes on weds, should be accepted
secure mac signaling - failed
the two mvpn drafts need to be considered together since the issues are
the same, with different solutions. Please review and see which one to
go to.
evpn FRR - review in SPRING, comments from the authors of another draft
that uses a flag in the advertised SID - should this use an argument of
the flag. This discussion needs to be resolved.
private mpls label - nees cross WG review.

Donald: evpn bfd should be included in the LC list.
Matthew: yes. If you see something that you requested and it is not on
the wiki, let us know.

draft-ietf-mpls-1stnibble-04 Greg Mirsky 10 min

Greg presents.
This was named mpls first nibble, but that was misleading, since it is
really about the post stack header and not the mpls labels, really about
what follows the label stack, so the terminology changes.

Why this draft?

The 4 bits following the LSE can impact on load balancing. Some
implementation used to hash based on the content identified by the first
nibble. It is assumed that if the first nibble is 4 or 6, then the
payload is ipv4 or ipv6, and load balancing can be done on the inner IP
headers. Also with PWs, the values 0 are assigned for data and 1 for ACH
VCCV to differentiate from other payloads. In PWs you can have ethernet
as payload as well.

We made the CW optional, and that later was perceived as a mistake due
to MACs could have 4 or 6 in the 1st nibble. We mitigated that using CW,
but still an option and not a MUST.

We want to document what numbers are in used in the first nibble (via
registry in IANA), and also use this opportunity to deprecate cases
where non IP payload are encapsulated in the post stack header. We give
the definition of deprecation. Deprecation is different from making
something obsolete - new implementations that support this document MUST
NOT use non-ip payload without post stack header. Major concern is the
load balancing - which can have undesired outcomes if the inner
destination MAC is mistakenly confused with an IPv4/IPv6 indication.

As part of the work we are updating RFC4928 to make the normative
language stronger, and introduce this updated terminology. In the
document there is an IANA registry as well for the first nibble.
IANA said that they cannot create a register like that. We will discuss
and update the document.
At the moment the registry in the document shows the same value is used
by several applications. We'll find a compromise and update this WG.

Conclusions: Please consider this in the work in this WG.

Jorge: can you go thru the text and let us know if you are happy with
the section on CW?
Greg: I will and get back.
Ali: please go thru the section and say if anything is missing. The text
includes different scenarios. For example, in case of RSVP TE, do you
still mandate the use of CW?
Greg: per flow load balancing will exist whether there is CW or not. Our
concern is for transit nodes to do something not expected, and we
deprecate the use of non CW for non-IP, for avoiding unpredictable load
balancing, regardless of what the transport LSP is.
Ali: that's what we emphasize in 7432bis - make sure there is CW if load
balancing is used, but if no load balancing, such us in case of TE
tunnels, we do not want to add the additional burden of extra overhead.

Greg: I simpathize with the effort, but saving 4 octets in nowadays
networks might not be significant compared with the benefits. I'll read
the document again, but this mihght be the simpler way - CW all the
time.

draft-ietf-bess-evpn-ip-aliasing-01 Jorge rabadan 5 min

Jorge presents.
The updates address the concerns and questions on the list, mostly
related to the use case 3. Also clarifications that will make
implementors' life easier.
The ask is for more feedback and move this to WGLC if no more comments.

Jeff: draft ready but needs implementation report.
Jorge: to the chairs - do we have implementation reports in BESS?
Matthew: we just poll the list, but there is a way to add
implementations in the wiki.
Ali: implementations are only part of the WGLC, right?
Matthew: yes

draft-rabadan-bess-evpn-inter-domain-opt-b-03 Jorge rabadan 5 min

Jorge presents.
Draft is informational and raises issues with inter domain option B, and
offers solutions based on other specs or local implementations without
changing the control plane.
WG adoption is requested by the authors.

draft-rabnic-bess-evpn-mcast-eeg-03 Jorge rabadan 5 min

Jorge presents.
This draft fills the gaps of existing specs for doing intra and inter
subnet multicast forwarding across different EVPN domains connected by
service gateways.
More feedback requested and WG adoption.

Ali: can you not do a RFC9014bis and include these gaps?
Jorge: we could, but that RFC9014bis draft would only address half of
the problem (for layer-2). We would still need to address the inter
subnet multicast across EVPN domains.

draft-zzhang-bess-bgp-mvpn-source-active-route Jeffery 10 min

Jeffrey presenting.
This is for S,G only mode in MVPN.
In the presented scenario, a failure on PE2 should not affect the flow
at all, since PE2 is not even in the path. The solution makes PE1
advertise the SA routes as well as the C-RP PE. Traffic flow won't be
disturbed. This is an extension to RFC6514, where PEs can advertise the
SA routes in two cases: MSDP or PIM anycast, no other ways. This
document discover sources by other methods, including provisioning or
PIM flooding for source discovery (the PIM flooding suggested by
mankamana).

Question is whether we want to progress this document as a separate work
or fold it into RFC6514?

Zheng Zhang: in the figure, is this multihoming?
Jeffrey: if PE1 sends the SA route, we solve the problem
Zheng Zhang: useful and used in many deployments at the moment. This is
an opportunity to review all the content in 6514.

Thoughts on a potential rfc614bis draft Jeffery 10 min

Jeffrey presents thoughts on 6514bis.
Huge spec and has too many follow up specs. For instance, RFC6515, that
is a clarification for ipv6.
Issues in the current 6514:
upstream inter as upstream PE selection
non segmented inter-as using ipv6 infra, it does not work. There are two
drafts addressing the issue. Lots of discussions between the authors of
both documents. No conclusion yet. My personal conclusion is that there
is a simpler solution in the mvpn-evpn-mcast-enhancements draft.

RFC6514bis draft could address the problem as well as other potential
additions.

Ali: great idea to consolidate RFC6514. The extensions in page 2 - the
list was longer than page 6. Is that correct?
Jeffrey: some could not fold into the bis new document. And some could
be tracked separately.

Jorge: good idea. Are you doing this with references to other specs? or
copying the content of the other specs in a single document? also, if
you fold the mvpn and evpn extensions into the new 6514bis document, you
still need to address the evpn extensions somewhere.
Jeffrey: not thought about how to write RFC6514bis yet. The ones related
to extensions for mvpn and evpn are tracked separately in their existing
document and some details for mvpn would go to the bis version.

draft-sajassi-bess-evpn-first-hop-security-02 Krishnaswamy 5 min

Krishna presenting.
Welcome Jorge and Wen to the draft.
Presented in IETFs 116 and 117. Quick recap.
Changes: comments addressed and editorial changes.
Solicit input and WG adoption.
There is an existing implementation in Cisco Nexus devices.

Ali: want to add that the new contributions have been significant. You
can see the improvements in the diff and the document is ready for WG
adoption.
David: are you planning to include prefix delegation in this document?
Krisha: Not really, let's follow up.

Erik: is this for SAVI? is it not the same information needed?
Krishna: not but let's follow up,

draft-wang-bess-secservice Hang Shi 10 min

Linda presenting.
Second time presenting this work.
This is about IPSec over SRv6. Some flow services require encryption.
Similar to secure EVPN. This is only to select some flows that require
encrption. The desired data plane is shown in the slides.

New tunnel type. New IPSec TLVs to describe properties, as defined in
the IDR draft for sdwan.
Next steps: since this is similar to secure EVPN, an option is to add an
extension to secure EVPN. However, the secure EVPN draft is expired at
the moment.

Ali: yes, we need to move the secure-evpn draft forward. The queue is so
long that the draft is not moving, let alone a new draft. Second point
is: are you asking to add a new encap in section 9 of secure EVPN?

Linda: yes

Ali: sounds good, we can do that. This is like vxlan, only that instead
of inner header being vxlan it is srv6. Yes, it should be simple to add
it to the secure EVPN draft. Does this need NAT?

Linda: no NAT traversal.

Ali: let's have a quick follow up.

Darren: anything new for existing ipv6 IPSec?

Linda: no, nothing new

draft-lrss-bess-evpn-group-policy Ali Sajassi 10 min

Ali presents.
History of the draft: merge of two drafts that have been around for a
while. Data plane and the control plane covered in this new document.
The control plane uses an extended community. The data plane an
extension to VXLAN. We decided to merge both since they are
complementary to each other.

Implemented by multiple vendors. So, it is not really a rev 00 but more
mature than that.

Data plane: add group policy id in the reserved fields of the VXLAN
header and a couple of flags. G and A flags.
G=1 - policy id is present, G=0 is not.
A=1 - the policy has been applied and does not need to be applied yet
again. If not, the receiver should apply the policy.

Control plane: group policy ID in the ext community, and scope as well,
to help with interdomain.
Also the draft deals with backwards compatibility with VXLAN nodes.

Next steps, since this is merging two mature drafts, we are seeking for
WG adoption.

Matthew: as BESS and NVO3 chair. Typically, vxlan changes should be done
in NVO3, but no extensions of vxlan can be done, since VXLAN was
independently published, not part of any WG as desired by the authors.
So we need to discussed where to host the VXLAN extensions.

Jeff T.: data plane should be done in NVO3.
Ali: but are there any concerns with respect to VXLAN?

Matthew: not aware of issues. But we are not able to bring VXLAN to
NVO3, because it was published by vendors that didn't want adoption in
NVO3.
Ali: we can change this.

Jorge: this is important work, and irrespective where we host the vxlan
extensions, it is important to do it on vxlan because vxlan is what it
is deployed out there.

Jorge: a question for Ali - is this extended community attached to AD
per EVI routes too for group policy IDs on ACs, outside of multihoming?

Ali: yes, for single homing too, but I see where you are coming from and
the use of ESIs might be problematic. Need follow up.

Jorge: another question about the IPVPN to EVPN interworking section, is
this for ingress enforcement only? I can see that the control plane part
works fine between IPVPN and EVPN families, but what about data plane
and the encoding of group policy ID in MPLS?

Wen: it is workk in progress.

Aijun: we have other use cases; we want to merge the two proposals
because our solution is similar. The solution is similar.

Ali: let's follow up.

draft-sajassi-bess-rfc8317bis Ali Sajassi 10 min

skipped for the lack of time

draft-malhotra-bess-evpn-centralized-anycast-gw Neeraj 10 min

Krishna presents.
Presented in 118, we now reference 7432bis and the MAC selection
including defaulut GW extended community.
We couldn't go thru the entire presentation last time, so we go now.
This is about centralized GWs.
For layer-2 or Asymmetric IRB. This draft makes the use of ARP/ND
snooping a MUST on the access L2 PEs.

Request WG adoption

Himanshu: I don't see anything different from what is already specified?
is it informational?
Krisna: we could make it informational but let's discuss
Neeraj: even there are no on the wire changes, there are certain MUSTs
that are defined so that's why it is standards track for the moment. For
instance the fact that the L2 PEs MUST do ARP/ND snooping and proxy.
Open to suggetsions though.

draft-sajassi-bess-evpn-l3-optimized-irb Chuanfa 10 min

Presented by chuanfa
Goes thru the draft and the two options, with option B being preferred
to avoid packet loss.
Uses the RFC9047 ARP ext community and a bit to indicate the
L3-optimized mode.

Next steps: more input and WG call.