Re: [bess] Roman Danyliw's No Objection on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with COMMENT)
Hi Roman, Thanks for your comments. Please see my replies inline marked with [AS]: On 7/15/20, 6:45 PM, "BESS on behalf of Roman Danyliw via Datatracker" wrote: Roman Danyliw has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ -- COMMENT: -- I support the DISCUSS ballot position of Erik Kline I support the DISCUSS ballot position of Alvaro Retana I support the DISCUSS ballot position of Ben Kaduk Not much to add to the feedback of my peer ADs. ** Please respond to the SECDIR feedback (and thank you Chris Lonvick for doing it!) ** Section 11. As there is nothing documented to prevent this approach from being used across administrative domains with different policies (i.e., there is no applicability statement or normative language providing caution from being used outside of the commonly reference data center use case) or any security assumptions made about the elements involved, please reiterate that there are no inherent security services being provided to protect the traffic. If this is desired it should provide through other means. [AS] I added a paragraph to section 11 per another feedback to address this. It is reflected in rev10. Cheers, Ali ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] I-D Action: draft-ietf-bess-evpn-irb-mcast-05.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 : EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding Authors : Wen Lin Zhaohui Zhang John Drake Eric C. Rosen Jorge Rabadan Ali Sajassi Filename: draft-ietf-bess-evpn-irb-mcast-05.txt Pages : 77 Date: 2020-10-13 Abstract: Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the endusers to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-irb-mcast/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bess-evpn-irb-mcast-05 https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-irb-mcast-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-evpn-inter-subnet-forwarding
Dear Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan: An IPR disclosure that pertains to your Internet-Draft entitled "Integrated Routing and Bridging in EVPN" (draft-ietf-bess-evpn-inter-subnet-forwarding) was submitted to the IETF Secretariat on 2020-10-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4348/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-bess-evpn-inter-subnet-forwarding" Thank you IETF Secretariat ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
[bess] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-bess-evpn-inter-subnet-forwarding
Dear Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan: An IPR disclosure that pertains to your Internet-Draft entitled "Integrated Routing and Bridging in EVPN" (draft-ietf-bess-evpn-inter-subnet-forwarding) was submitted to the IETF Secretariat on 2020-10-12 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4347/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-bess-evpn-inter-subnet-forwarding" Thank you IETF Secretariat ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
Re: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
Hi Alvaro, Thanks very much for your comments and sorry for the delay, please refer to my replies marked with [AS]. On 7/14/20, 10:51 AM, "Alvaro Retana via Datatracker" wrote: Alvaro Retana has entered the following ballot position for draft-ietf-bess-evpn-inter-subnet-forwarding-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwarding/ -- DISCUSS: -- I'm balloting DISCUSS because the specification in §9.1.1 is not clear, and it is not in sync with draft-ietf-idr-tunnel-encaps. [Some of the points below are not DISCUSS-worthy, but I'm including them here because they are related to the larger point.] §9.1.1 talks about using the Encapsulation Extended Community *and* the Router's MAC Extended Community. However, the requirement for these communities to appear together is not explicit anywhere. What are the implications for only one of them being present? [AS] These two ECs are intended for two different purposes - one is to indicate tunnel type and the other to indicate PE's MAC address when doing Ethernet NVO tunnel. These two ECs don't need to appear together all the time - only for a specific use case which is described in section 9.1.1. The Router's MAC Extended Community "is only required when Ethernet NVO tunnel type is used". It seems to me that normatively requiring the extended community is important in this case. [AS] Changed the sentence to "The Router's MAC Extended community MUST be added when Ethernet NVO tunnel is used." What exactly is the "Ethernet NVO tunnel type"? §1 (Terminology) says that "Examples of this type of tunnels are VXLAN or GENEVE." A standards track document should be specific about when something is required. For example, I assume that it would also be required when using NVGRE. The tunnel types are a finite number, so please be specific. [AS] I changed it as follow: "Ethernet NVO tunnel: refers to Network Virtualization Overlay tunnels with Ethernet payload as specified for VxLAN in and for NVGRE in . Where is the GENEVE tunnel type (to be used in the Encapsulation Extended Community) defined? BTW, the [GENEVE] reference is also missing. [AS] I removed GENEVE since it was just an example and I am not aware of any implementation that uses GENEVE tunnel type since it is not defined. §4 has this text: "the tunnel connecting these IP-VRFs can be either IP-only tunnel (in case of MPLS or GENEVE encapsulation) or Ethernet NVO tunnel (in case of VxLAN encapsulation)." It confuses me because of the apparent contradiction between GENEVE being an example of an Ethernet NVO tunnel type, but also (?) an IP-only tunnel in this case. [AS] Yes, GENEVE can do both tunnel types; whereas, VxLAN can only do Ethernet NVO. GPE which is evolution of VxLAN, can also do both. I changed the example from GENEVE to GPE because GPE tunnel type is defined but not GENEVE: https://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#tunnel-types. §4.2/draft-ietf-idr-tunnel-encaps mentions possible conflicts created by the Router's MAC Extended Community and how it may be ignored, but this document doesn't mention using the Encapsulation Sub-TLVs (also from draft-ietf-idr-tunnel-encaps) for the same function. Can the same function be achieved with the Encapsulation Sub-TLVs? [AS] All the info that is needed is already in the EVPN route itself and that is why there is no need to use Encapsulation Sub-TLVs. The tunnel-encap draft does a good job to explain when the tunnel-type EC is sufficient and when not to send the attribute itself. We coordinated that with Eric Rosen and it looked good the last time I checked. "section 4.5 of [TUNNEL-ENCAP]" is mentioned a couple of times, but there is no §4.5 in draft-ietf-idr-tunnel-encaps, and there's no reference either. Please remove the specific section number (to avoid becoming out of sync), and instead mention the Encapsulation Extended Community by name. Add a Normative reference to draft-ietf-idr-tunnel-encaps. [AS] Sounds good. I took care of it. BTW, there is already an informative reference. -- COMMENT:
