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? 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. 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. Where is the GENEVE tunnel type (to be used in the Encapsulation Extended Community) defined? BTW, the [GENEVE] reference is also missing. §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. §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? "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. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (1) What is the "Tunnel Type Extended Community"? I'm assuming you mean the Encapsulation Extended Community. (2) s/MUST treat the route as withdraw/MUST use the treat-as-withdraw approach (3) I find the use of normative language (MUSTs) in the description of the requirements (§2) unnecessary. (4) Nits: 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
