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

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 13 Oct 2020 06:55:02 +0000

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-masked]> 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