[bess] I-D Action: draft-ietf-bess-evpn-per-mcast-flow-df-election-06.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : Per multicast flow Designated Forwarder Election for EVPN Authors : Ali Sajassi Mankamana Mishra Samir Thoria Jorge Rabadan John Drake Filename: draft-ietf-bess-evpn-per-mcast-flow-df-election-06.txt Pages : 12 Date: 2022-01-26 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.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] 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 [I-D.ietf-bess-evpn-df-election-framework] 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 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-per-mcast-flow-df-election-06 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
[bess] I-D Action: draft-ietf-bess-srv6-services-09.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BGP Enabled ServiceS WG of the IETF. Title : SRv6 BGP based Overlay Services Authors : Gaurav Dawra Clarence Filsfils Ketan Talaulikar Robert Raszuk Bruno Decraene Shunwan Zhuang Jorge Rabadan Filename: draft-ietf-bess-srv6-services-09.txt Pages : 31 Date: 2022-01-26 Abstract: This document defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN, and Internet services. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-srv6-services/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-bess-srv6-services-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-srv6-services-09 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] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon
Hi, I have a question concerning the IANA considerations section: IANA currently has no registry for the flags field of EVPN ESI Label extended community to “request/allocate” SHT bits. This has come up before for e.g. draft-ietf-bess-evpn-l2gw-proto which requests a 3-bit field for load-bal modes. Should one or the other draft request an IANA registry ? Ref: https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-l2gw-proto#section-4 Regards, Luc André Luc André Burdet | Cisco | laburdet.i...@gmail.com | Tel: +1 613 254 4814 From: BESS on behalf of "slitkows.i...@gmail.com" Date: Wednesday, January 26, 2022 at 04:50 To: "bess@ietf.org" , "draft-ietf-bess-evpn-mh-split-hori...@ietf.org" Cc: "bess-cha...@ietf.org" Subject: [bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon Hello Working Group, This email starts a two weeks Working Group Last Call on draft-ietf-bess-evpn-mh-split-horizon [1]. This poll runs until *the 9th of Feb*. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or a Contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors. There is no IPR currently disclosed. If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. We are also polling for any existing implementation as per [2]. Thank you, Stephane & Matthew [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] WGLC, IPR and implementation poll for draft-ietf-bess-evpn-mh-split-horizon
Hello Working Group, This email starts a two weeks Working Group Last Call on draft-ietf-bess-evpn-mh-split-horizon [1]. This poll runs until *the 9th of Feb*. We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as an Author or a Contributor of this document please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors. There is no IPR currently disclosed. If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. We are also polling for any existing implementation as per [2]. Thank you, Stephane & Matthew [1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-mh-split-horizon/ [2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] EVPN IRB - Clarifications on MAC/IP route with only the MAC address
Hi, RFC9135 describes some scenarios where a PE withdraws a MAC/IP route with only the MAC address if it had advertised such a route before. Here is one such scenario: On the source NVE, an age-out timer (for the silent host that has moved) is used to trigger an ARP probe. This age-out timer can be either an ARP timer or a MAC age-out timer, and this is an implementation choice. The ARP request gets sent both locally to all the attached TSs on that subnet as well as to all the remote NVEs (including the target NVE) participating in that subnet. *The source NVE also withdraws the EVPN MAC/IP Advertisement route with only the MAC address (if it has previously advertised such a route).* Have some questions: 1) If the source NVE had allocated MPLS Label1 on a per MAC basis, is the source NVE expected to retain Label1 even after withdrawing the MAC/IP route with only the MAC address? Otherwise, it would invalidate the MAC/IP route with both the MAC and IP addresses since Label1 is mandatory and expected to be valid in that route, right? 2) If the source NVE re-advertises the MAC/IP route with both the MAC and IP addresses after withdrawing the MAC/IP route with only the MAC address, say because of a route refresh request, should the re-advertised route carry only the IP VRF Route Target? 3) Can the user assign the same route target for both the IP and MAC VRFs and use it to match against both? RFC9135 does not explicitly prohibit, but that may cause problems, for e.g. in #2 above, right? Comments/clarifications would be helpful.. Regards, Muthu ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
