BESS session
1- Working Group Status
(Matthew)
one change in the agenda - srv6-mup-yang draft will not be discussed.
Status update:
2- draft-zzhang-bess-ipvpn-payload-only
Presented by Jeffrey. Started in the pals group and ended up here.
Use-case is 5G, transport of GTP in an IPVPN.
There is a draft in DMM to replace GTP with SRv6, replacement is under
the hood. The GTP header info is moved into the SRv6 header (which could
also be an MPLS stack).
The work started with a PW, but it is generalized to IPVPN transport.
Label is mapped to the reconstructed info at the egress PE. There are
options to transport traffic with or without UDP, src IP.
New SAFI including label, RD, dest IP and optionally other fields.
Updates carry the same route-targets as ipvpn would.
Greg: other use-cases? reasonable to expand use-cases to LTE networks.
Mixed environment or you envision transition to 5G and this case?
Jeffrey: Basically same thing with GTP tunnels. Any situation where you have IP traffic between hosts.
Greg: technically possible. Operationally?
Jorge: why RD and RT in the GT? can you not use RD=0 and no Route-Target for the Global Table?
Jeffrey: the use-case started with IPVPN, but yes, you can use it with RD=0 and no RT.
3- draft-zzhang-bess-mvpn-evpn-cmcast-enhancements
Presented by Jeffrey.
Fixes some issues in current specs. Presented in the past, stayed
dormant for a while, now it is the right moment to resurrect it.
Overlapping with a draft that’ll be presented during the session. Discussion ongoing in the mailing list.
The ask is to put this into the adoption queue.
Fanghong: my document uses ipv6 infrastructure.
Jeffrey: different solutions for inter-as propagation. Need to convince each other what solution is better or both are needed.
4- draft-mishra-bess-ipv4-only-pe-design-all-safi
By Gyan
4 different drafts, 2 for ipv6 and 2 for ipv4.
First draft based on 3 SAFIs and a proof of concept among some vendors. A
few peering scenarios included. Similar POC testing BCP for IPv4 as
well, including vendor testing.
Benefits are really CAPEX/OPEX savings to operators, depending on the solution.
RFC8950 does not use an ipv4 mapped address as next-hop anymore. Industry has moved away from it. This draft is aligned with it.
Gyan goes thru the examples in the slides.
Jorge: you’re listing some illegal AFI/SAFI combinations.
Gyan: ok, thanks
5- draft-saum-evpn-lsp-ping-extension
by Saumya
Extensions to the existing evpn lsp ping draft.
After checking with evpn lsp ping authors, the feedback derived into this new draft. Queries about three requirements.
Patrice: need to describe the use case better
Jorge: I agree with Patrice. Also, in the Wildcard TLV there must be some limitations, you can’t wildcard every field (e.g., you can’t wildcard the MAC field if you are pinging the MAC/IP route) - you need to specify those limitations. Finally, you’re not requesting code-points in the IANA section.
Saumya: sure, I’ll take care of it.
6- draft-saumthimma-evpn-ip-binding-sync-00.txt
by Saumya
Addresses the identification of IP bindings and their synch to remote
networks. Example in the slide with three EVPN sites. At the access, IP
bindings are snooped at the access, and VLANs are extended to the remote
sites. The approval IDs need to be synchronized. Solution uses the
MAC/IP routes with a new ext community with some ‘credentials’ in this
ext community.
Synch ID configured at all the VTEPs to be validated.
Patrice: need to clarify use-case. It does not really add security, can you use the route-targets.
Saumya: need more granularity.
Jorge: can you use a normal community or large community?
Saumya: want to standardize the ext community for future extension.
7- draft-saum-bess-dampening-backoff
draft-saumvinayak-bess-all-df-bum
Jorge: No comments for the dampening draft, good that is made informational. For the all-df one, please change the DF Alg to a different value, and clarify the remote PE behavior.
Saumya: sure, will change codepoint to TBD.
Patrice: check the irb mobility draft and the l2gw drafts. That could solve your use-cases.
Saumya: ok, will check
8- draft-duan-bess-mvpn-ipv6-infras
by Fanghong
Requested presentation in IETF 113 but couldn’t present. Discussion in
the mailing list. Slides show the problem for inter-as and RFC6514.
The proposed solution suggests some actions on the Intra/Inter AS IPMSI
routes as well as the c-mcast routes on the sender PE. Also on RRs.
The ask is more comments in the mailing list.
9- draft-wang-bess-mvpn-upstream-df-selection
presented by
complements the RFC9026 cases for UMH selection. Map the role of VRRP on
the upstream PEs to primary and standby PEs. VRRP is just one solution,
other ways possible. On the downstream PEs, the standby PE community no
longer needed.
10- draft-fu-bess-evpn-vpws-seamless
by Zheng Fu
solution that identifies SRv6 EVPN route and PW route so that the EVPN
can take precedence. Slide presenting the different cases for composite
PEs in evpn-vpws seamless draft and the issue.
The ask is more feedback
Patrice: we have the evpn-vpws-seamless draft, we should add the solution to the draft.
Jorge: it has to be discussed in the context of the evpn-vpws-seamless draft. You may think of other ways to identify the VPWS and EVPN routes. For example, use the same IPv4 or IPv6 next-hops on both. Or you can even use the Originating PE (OPE) attribute in draft-heitz-bess-evpn-option-b.
end of the session…