Re: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Some nits/questions/comments:

Abstract

   EVPN provides a flexible control plane that allows intra-subnet
   connectivity in an IP/MPLS and/or an NVO-based network. In NVO
   networks, there is also a need for a dynamic and efficient inter-
   subnet connectivity across Tenant Systems and End Devices that can be
   physical or virtual and may not support their own routing protocols.

Why is that "need for ..." only in NVO networks?

   Overlay index: object used in the IP Prefix route, as described in
   this document. It can be an IP address in the tenant space or an ESI,
   and identifies a pointer yielded by the IP route lookup at the
   routing context importing the route. An overlay index always needs a
   recursive route resolution on the NVE receiving the IP Prefix route,
   so that the NVE knows to which egress NVE it needs to forward the
   packets.  

Given that there is an "underlay next-hop", perhaps rename "overlay index" to "overlay next-hop" and define it after the "underlay next-hop"? It could also be a MAC address (as described in 5.4.3) as well; in fact I really don't see the need of using ESI (more below).

Suggested text for "overlay next-hop":

  Overlay next-hop: an IP/MAC address in the tenant space or an ESI.
  It is included in the IP Prefix route to specify that the destination
  prefix is reached through the overlay next-hop, which requires a
  recursive lookup of the next-hop in the tenant's space.

--------------------------------

        o Clean identification, operation of troubleshooting of IP
          Prefixes, not subject to interpretation and independent of the
          IPL and the IP value. E.g.: a default IP route 0.0.0.0/0 must
          always be easily and clearly distinguished from the absence of
          IP information.

I had trouble understanding the "independent of" part; then I realized that it reads better if it is moved to the beginning of the clause: "independent of and not subject to the interpretation of ...".

Section 4 should be folded into section 2.2. In fact, much of section 6 can be removed as well.

5.3 ESI overlay index ("Bump in the wire") use-case

How does multicast work, for traffic sourced from SN1?

             . Destination inner MAC = M2 (this MAC will be obtained
               from the Router's MAC Extended Community received along
               with the RT-5 for SN1).

Because the RT-5 has M2 mac attached, the overlay index could be the mac address itself - no need to use the ESI. This has advantage when there is no multihoming (no ESI need to be defined) and can also work with multihoming. In fact, that is what section 5.4.3 does.

5.4 IP-VRF-to-IP-VRF model

   .. EVPN provides connectivity for:

   1. Traffic destined to the IRB IP interfaces as well as
   2. Traffic destined to IP subnets seating behind the TS, e.g. SN1 or
      SN2.
   In order to provide connectivity for (1), MAC/IP routes (RT-2) are
   needed so that IRB MACs and IPs can be distributed. Connectivity type
   (2) is accomplished by the exchange of IP Prefix routes (RT-5) for
   IPs and subnets seating behind certain overlay indexes, e.g. GW IP or
   ESI.

I have trouble understanding #1 above (even with the explanation). #2 is about destinations behind the TS; is #1 about TS themselves? Why is "IRB IP" singled out?

Additionally, I think 5.4 should be promoted to its own section (section 5 is about three use cases of the "overlay index" or "underlay next-hop" and section 6 is about implementing IPVPN using type-5 instead of SAFI 128).

5.4.1 Interface-less IP-VRF-to-IP-VRF model

I suppose this is basically using type-5 vs. SAFI 128 routes to do IPVPN. It's better to point that out.

   b) The IP-VRF instances in the NVE/DGWs are directly connected
      through NVO tunnels, and no IRBs and/or MAC-VRF instances are
      defined at the core.

"at the core" is a little bit confusing. Perhaps 5.4.2/5.4.3 can be discussed first, and then come to this new model where no dedicated mac-VRF is used for the purpose of forwarding IPVPN traffic through this mac-VRF.

Additionally, it is not really "interface-less" vs. "interface-full". It's really if a dedicated mac-VRF is used or not. If you organize it that way, then 5.4.2 and 5.4.3 can be easily merged (the only difference between 5.4.2 and 5.4.3 is whether IRB IP or mac address is used as the overlay-index).

BTW - in an upcoming revision of draft-lin-bess-evpn-irb-multicast, a dedicated mac-VRF (or BD) is also used. It is called PBD (Pseudo Bridge Domain). It would be good to synchronize the two. Will follow up on that separately.

   c) The solution must provide layer-3 connectivity among the IP-VRFs
      for Ethernet NVO tunnels, for instance, VXLAN or nvGRE.

   d) The solution may provide layer-3 connectivity among the IP-VRFs
      for IP NVO tunnels, for example, VXLAN GPE (with IP payload).

Why is c) MUST while d) MAY?

        o RD as per [RFC7432].
        o Eth-Tag ID=0 assuming VLAN-based service.

I suppose no matter how many BDs you have, the type-5 is not tied to any particular BD. In case of VLAN-based service, there would be many EVIs, so saying "RD as per [RFC7432]" is not enough; in case of vlan-aware bundle, what Eth-Tag ID do you use? So the second bullet is not good either? My understanding: RD is not really tied to any of the EVPN EVIs; it's really the RD for the IP-VRF; the Eth-Tag would always be 0 as well, even for vlan-aware bundle?

   (2) DGW1 imports the received routes from NVE1:
        ...
        o Since GW IP=0 and the VNI is a valid value, DGW1 will use the
          VNI and next-hop of the RT-5, as well as the MAC address
          conveyed in the Router's MAC Extended Community (as inner
          destination MAC address) to encapsulate the routed IP packets.

s/encapsulate the routed IP packets/set up relevant forwarding state/? This bullet is about what to do when receiving the route (not when receiving the packet).

        o The IP packet destined to IPx is encapsulated with: Source
          inner MAC = DGW1 MAC, Destination inner MAC = M1, Source outer
          IP (source VTEP) = DGW1 IP, Destination outer IP (destination
          VTEP) = NVE1 IP.

Same comment as in the inter-sbunet-forwarding draft: setting of the inner src/dst mac address to the specific value seems to be tied to certain hardware - in theory they are not needed at all (if not were for certain hardware implementation). If that's the case, the spec should point that out.

5.4.2 Interface-full IP-VRF-to-IP-VRF with core-facing IRB 
   ...
   In this model, the requirements are the following:

Those do not seem to be requirements. Rather they just describe the scenario. Same comment for 5.4.1.

        o RD as per [RFC7432].
        o Eth-Tag ID=0 assuming VLAN-based service.

In this case, I suppose type-5 routes are tied to the core mac-VRF, and the RD is tied to that as wel; for Eth-Tag ID, it's tied to that mac-VRF as well. It's better to spell that out instead of just saying "assuming VLAN-based service".

        o MPLS label or VNI corresponding to the IP-VRF. Note that the
          value SHOULD be zero since the RT-5 route requires a recursive
          lookup resolution to an RT-2 route. The MPLS label or VNI to
          be used when forwarding packets will be derived from the RT-
          2's MPLS Label1 field.

Delete "corresponding to the IP-VRF. Note that the value" so that it reads as following?

        o MPLS label or VNI SHOULD be zero since the RT-5 route requires a recursive
          lookup resolution to an RT-2 route.

For the following:

        o Route type 2 (MAC/IP route for the core-facing IRB)
          containing:
          . Route-target identifying the tenant. This route-target MAY
            be the same as the one used with the RT-5.

The Route-target should really identify the mac-VRF. It is true that the mac-VRF must be present on every NVE for the tenant, but since we're talking about type-2 route it is better to say route target for the mac-VRF.

Similar comments for 5.4.3. However, I suggest to fold 5.4.3 into 5.4.2 - there is really no need to repeat w/ little difference.

Jeffrey

> -----Original Message-----
> From: BESS [mailto:[e-mail]] On Behalf Of Martin Vigoureux
> Sent: Monday, February 13, 2017 5:08 PM
> To: BESS <[e-mail]>
> Subject: [bess] WG Last Call for draft-ietf-bess-evpn-prefix-advertisement-04
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on
> draft-ietf-bess-evpn-prefix-advertisement-04 [1] which is considered
> mature and ready for a final working group review.
> Note that this call is longer than usual because we are pushing two
> correlated documents together.
> 
> Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *5th of March*.
> Note that this is *not only* a call for comments on the document; it is
> also a call for support (or not) to publish this document as a Proposed
> Standard RFC.
> 
> *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-bess-evpn-prefix-advertisement, to ensure that IPR
> has been disclosed in compliance with IETF IPR rules (see RFCs 3979,
> 4879, 3669 and 5378 for more details).
> 
> *If* you are listed as a document author or contributor of
> draft-ietf-bess-evpn-prefix-advertisement-04 please respond to this
> email and indicate whether or not you are aware of any relevant IPR.
> 
> Note that, as of today, no IPR has been disclosed against this document
> or its earlier versions.
> 
> We are also polling for knowledge of implementations of part or all of
> what this document specifies. This information is expected as per [2].
> Please inform the mailing list, or the chairs, or only one of the chairs.
> 
> Thank you,
> M&T
> 
> [1]
> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-prefix-advertisement/
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess