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" <[email protected]> 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 <xref target="RFC7348"/> and for NVGRE in <xref target="RFC7637"/>. 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: ---------------------------------------------------------------------- (1) What is the "Tunnel Type Extended Community"? I'm assuming you mean the Encapsulation Extended Community. [AS] Correct. I changed it. (2) s/MUST treat the route as withdraw/MUST use the treat-as-withdraw approach [AS] done. (3) I find the use of normative language (MUSTs) in the description of the requirements (§2) unnecessary. [AS] change them to lower case "must". (4) Nits: [AS] all done. s/In case of/In the case of/g s/forwarding are performed/forwarding is performed s/back hauled/backhauled/g s/drawback of centralized/drawback of the centralized s/relationship among these components/relationship between these components/g s/can consists/can consist s/a IP/an IP/g s/a L3/an L3 s/used in description of/used to describe s/in prior section/in the prior section s/Since the packet forwarding is between ingress PE's...and egress PE's ...procedures follows/Because the packet forwarding is between the ingress PE's...and the egress PE's...procedures follow s/provides different level/provides a different level s/identifying bridge/identifying the bridge s/in data plane/in the data plane s/route route/route s/with BGP Encapsulation/with the BGP Encapsulation s/only L2 forwarding (bridging) part/only the L2 forwarding (bridging) part s/a RT/an RT/g s/RT-*/EVPN RT-*/g s/Lets consider/Let's consider/g s/using EVPN IP Prefix/using the EVPN IP Prefix s/[EVPN-PREFIX]/[I-D.ietf-bess-evpn-prefix-advertisement]/g s/Figure below illustrates this scenario/Figure 7 illustrates the scenario s/as follow/as follows s/as underlay tunnel/as the underlay tunnel s/in access-facing/in an access-facing s/using EVPN IP/using the EVPN IP s/where, IP lookup/where an IP lookup s/feedbacks/feedback s/is this document/in this document s/for application/for the application s/MUST not/MUST NOT "receiving NVE ration MPLS encapsulation" ?? s/Label-1/Label1/g (for consistency with rfc7432) s/Label-2/Label2/g _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
