Subject: [bess] Alvaro Retana's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)

From: Alvaro Retana via Datatracker <[email-masked]>
Date: Tue, 14 Jul 2020 10:51:24 -0700

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