This is OPS-DIR review. It should be take as any other WG LC comments Status: Has Issues and editorial NITS Summary: My main concerns are: 1) RFC9012 related concerns (a) descriptions associated with RFC9012 in sections 2.2 and 3.0 of this document, (b) Warnings about RFC9012 + RFC8365 interactions in Appendix A of RFC9012 (c) Lack of clarity of draft-ietf-bess-evpn-geneve in RFC9012 usage. 2) Error handling a) Lack of Error handling section b) assumptions on NVE actions under local bias (see section 1.2) What is good about the draft: a) Clear description and discussion of ESI Label-based Split Horizon and Local Bias, b) Clear delineation of default (Table 1) c) Consideration of BUM traffic ========== RFC 9012 issues 1) Section 2.2 paragraph 2 states: current text:/ As an example, egress NVEs that support IP-based MPLS tunnels, such as MPLSoGRE or MPLSoUDP, will advertise A-D per ES routes for the ES along with the BGP Encapsulation extended community, as defined in [RFC9012]. This extended community indicates the encapsulation type (MPLSoGRE or MPLSoUDP) and may use the SHT value of 01 or 10 to signify the intent to use Local Bias or ESI Label, respectively./ / It would be helpful to link this to a Encapsulation tunnel type in RFC9012 or other documents. Based on the definitions in your introduction: * MPLSoUDP: Multi-Protocol Label Switching over User Datagram Protocol, [RFC7510] * MPLSoGRE: Multi-Protocol Label Switching over Generic Network Encapsulation, [RFC4023]. What are the correct BGP Encapsulation tunnel types that MPLSoUDP and MPLSoGRE utilize in the extended community? Are you intending the following: * MPLSoGRE: Multi-Protocol Label Switching over Generic Network Encapsulation, MPLS-in-GRE (RFC9012 Tunnel type 11) * MPLSoUDP: Multi-Protocol Label Switching over User Datagram Protocol, [RFC7510], UDP Destintaion port (RFC9012 tunnel type 7)? If so, please specify in the text. If not, please indicate what are the valid RFC9012 tunnel types for these symbols. 2. Section 2.2, paragraph 3, needs to give a direct link to RFC9012 tunnel types. Current text:/ An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with encapsulation types such as VXLAN, NVGRE, MPLS, or no BGP tunnel encapsulation extended community, as specified in [RFC9012]. / Proposed text:/ An egress NVE MUST NOT use an SHT value other than 00 when advertising an A-D per ES route with RFC9012 Tunnel encapsulation types of VXLAN, NVGRE, and MPLS Label stack./ Question to authors: What did you mean "No BGP tunnel encapsulation extended community"? If BGP passses a [RFC9012] tunnel, it must come with a tunnel type. Are you suggesting there is no "Encapsulation Extended Community" Attached? 3. section 2.2, paragraph 4, Geneve tunnel Current text:/ An egress NVE advertising A-D per ES route(s) for an ES with GENEVE encapsulation MAY use an SHT value of 01 or 10. / New text:/ An egress NVE advertising A-D per ES route(s) for an ES with GENEVE tunnel encapsulation [RFC9012, I-D.ietf-bess-evpn-geneve] MAY use an SHT value of 01 or 10. / 4. issue with Geneve specification (draft-ietf-bess-evpn-geneve) RFC9012 only allows the Encapsulation Community to specify RFC9012 tunnel type. draft-ietf-bess-evpn-geneve specifies tunnel type Geneve (Value=19) and the Geneve Tunnel Options SubTLV for the EVPN (AFI: 25/ SAFI: 70). This definition indicates that the Geneve tunnels must have a Tunnel Encapsulation attribute with SubTLVs. draft-ietf-bess-evpn-geneve does not specify: a) What SubTLVs are valid for the Genve Tunnel Type in the Tunnel Encapsulation attribute. b) What validation procedures are used for the Geneve tunnel type with the tunnel encapsulation attribute. c) What happens if the Geneve tunnel type is specified on the Encapsulation Extended Community and a tunnel Encapsulation Attribute? d) What happens if the Geneve Tunnel type is specified in the Encapsulation Extended Community? 5. Need complete specification on what [RFC9012] tunnels are supported by this procedure. Please add a section or a table that indicates which tunnel types can be used for section 2.2 and 2.3. For example, is the Prefix-SID [RFC9012] a valid encapsulation? (see https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml) 6. Section 3, NVE announces multiple A-D with multiple Encapsulations If you have multiple A-D per ES routes for the same ES, will you have multiple encapsulation communities? Section 3 - in the 4th paragraph suggests this point in the text: text:/ a. An A-D per ES route for ES-x may be advertised with multiple encapsulations, some of which support a single Split Horizon method. In this case, the Split Horizon Type (SHT) value MUST be 00. For instance, encapsulations such as {VXLAN, NVGRE}, {VXLAN, GENEVE}, or {MPLS, MPLSoGRE, MPLSoUDP} can be advertised in an A-D per ES route. In all these cases, the SHT value MUST be 00./ In addition, the GENEVE Encapsulation (per draft-ietf-bess-evpn-geneve-08.txt) can only be passed in a Tunnel Encapsulation Attribute [RFC9012]. The error handling does not handle what happens if geneve encapsulation is in a extended community. 7. Why does the text not suggest the possiblity of using the Tunnel Encapsulation Attribute as well as the encapsulation community? It seems that the SRv6 work would hint that the tunnel encapsulation Attribute should be considered in this draft. Procedures + Error issues 1. Section 1.1, paragraph 2 - Local Bias Description could help build the case for NVE errors a) How does NVE track the IP Addresses(es) of other NVEs with which it shares multihomed ESs? What happens to local bias if the following occurs: a) NVEs incorrectly miss the IP addresses of other NVEs on the same multihomed ES. b) What happens if NVE does not filter out frames on the local interfaces connected to ESs that are shared with the same ingress NVE? These errors can cause local bias to have errors. It needs to be stated what happens if these errors occur? There should be some error handling or "manageability" warnings in the text. 2) Due to the complexity of the [RFC9012] issues and the text in sections 2 and 3, it would be good to have a manageability and an error handling section. The manageability section should summarize what operators need to configure and monitor. The error handling section should include RFC9012 error handling (see comments above) and what happens when assumptions (see the word "assume" in this text) does not occur. Editorial NITS: Nit 1: Section 1.1, MPLS and non-MPLS NVO tunnels, 1st sentence. Old text:/ * MPLS and non-MPLS NVO tunnels: refer to Multi-Protocol Label Switching (or the absence of it) Network Virtualization Overlay tunnels. / Comment: This sentence is unclear and needs a rewrite. I think you man MPLS tunnels and non-MPLS NVO tunnels. Nit 2: Section 1.2, paragraph beginning "Similarly, certain IP Tunnels -", In this paragraph, it would be very helpful to provide the sections in [I-D.ietf-bess-evpn-geneve], [RFC9252], and [RFC8986] My understanding is [RFC8986]- section 4.12, RFC9252 - section 6.1.1, draft-ietf-bess-evpn-geneve - section 4.1 Nit 3: Section 2.1, paragraph 1 It would be helpful to augment the second sentence with the section in RFC8365 that is the default behavior. I found the default behavior in section 8.3.2. If this is correct, please add this to sentence 2. Nit 4: Section 2.1, SHT Bit descriptions old text/ 0 0 --> Default SHT. Backwards compatible with [RFC8365] and [RFC7432] / issue: wrap in this text extends past 72 lines, and gets cut off Nit 5: Section 2.1, paragraph 3, "treat-as-withdraw behavior". old text:/ If a route with any of the mentioned encapsulation options is received and has an SHT value different from 00, it SHOULD apply the treat-as-withdraw behavior./ new text:/ If a route with any of the mentioned encapsulation options is received and has an SHT value different from 00, it SHOULD apply the treat-as-withdraw behavior per [RFC7606]. / Nit 6: section 2.2, second to last paragraph, beginning "An egress". reason: clarity of comma usage Old text:/ A value of 00 indicates the default behavior outlined in Table 1, which is to use Local Bias if no ESI-Label is present in the Ethernet option TLV, or if there is no Ethernet option TLV. / Suggested new text:/Old text:/ A value of 00 indicates the default behavior outlined in Table 1 which is to use Local Bias if: a)no ESI-Label is present in the Ethernet option TLV, or b) if there is no Ethernet option TLV. /