Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03

Hi,

I have the following nits/questions/comments. This email is only about the asymmetric section  - I may send another one about symmetric section.

"inter-subnet switching" is confusing. Shouldn't it be "inter-subnet routing" instead of "intra-subnet switching"? While it's EVPN aware, it still goes through routing first.

Isn't requirement R1 covered by R2?

   This is an environment where all NVEs to which an EVPN instance could
   potentially be attached (or moved)

Strike the "(or moved)"?

>From RFC 7432:

10.1.  Default Gateway
   ...
   The IP Address field of the MAC/IP Advertisement route is set to the
   default gateway IP address for that subnet (e.g., an EVPN instance).
   For a given subnet (e.g., a VLAN or EVPN instance), the default
   gateway IP address is the same across all the participant PEs. The
   inclusion of this IP address enables the receiving PE to check its
   configured default gateway IP address against the one received in the
   MAC/IP Advertisement route for that subnet (or EVPN instance), and if
   there is a discrepancy, then the PE SHOULD notify the operator and
   log an error message.

This draft:

   2. Each NVE of a given EVPN instance uses its own default gateway IP
   and MAC addresses, and these addresses are aliased to the same
   conceptual gateway through the use of the Default Gateway extended
   community as specified in [EVPN], which is carried in the EVPN MAC
   Advertisement routes. On each NVE, this default gateway IP/MAC
   address correspond to the IRB interface connecting the MAC-VRF of
   that EVI to the corresponding IP-VRF.

The above 2nd model seems to be conflicting with RFC 7432? Also, what does "this default gateway" refer to? Each NVE's "own default gateway" or "the same conceptual gateway"?
Is it that besides their own default gateway, an additional common gateway is advertised using that extended community? If so, what's the purpose to call those different IP addresses on the IRB interfaces "default gateway"? I assume the hosts will be using the common gateway address?

   It is worth noting that if the applications that are running on the
   TS's are employing or relying on any form of MAC security, then the
   first model (i.e. using anycast addresses) would be required to
   ensure that the applications receive traffic from the same source MAC
   address that they are sending to.

Why is that? As long as an NVE changes the source MAC to the one it sends in the ARP reply, it should work even with the 2nd model?

3.2 Heterogeneous Environment

   .. Even though policies
   among multiple subnets belonging to same tenant can be simpler,

s/simpler/simple/?

   ... Therefore, there can be a mixed environment where an NVE
   performs inter-subnet switching for some EVPN instances and the L3GW
   for others.

For the above sentence, it helps a lot if the last part reads "and the L3GW performs inter-subnet switching for other EVPN instances".

4.1 Among EVPN NVEs within a DC

   ... It also rewrites the source MAC address with its IRB
   Interface MAC address.

Need to make it clear that the above mentioned IRB interface is for the destination subnet. Same issue in 4.2.

For section 4.2, the processing on the ingress and egress NVE is no different from 4.1; the processing on the ASBRs is vanilla EVPN forwarding and not specific to inter-subnet forwarding at all; therefore, 4.2 is not really needed? Additionally, the section is about "w/o GW", yet the text talks about ingress/egress Gateway. It's better to replace Gateway with ASBRs.

4.3 Among EVPN NVEs in Different DCs with GW

   ... It also rewrites the
   source MAC address with its own IRB Interface MAC address.

Similar to 4.1, the above needs to be clear that it's the IRB interface for the subnet between the NVE and the GW. More below on this.

   ... This implies that the GW1 needs to keep the remote
   host MAC addresses along with the corresponding EVPN labels in the
   adjacency entries of the IP-VRF table (i.e., its ARP table).	

Does that mean GW1 needs to keep all type-2 IP/MAC addresses that GW2 learns from NVEs in DC2? Also does that mean GW1 and GW2 must be attached to all subnets? If so, between the source NVE and its local GW, when the source NVE route the traffic to the GW, I assume it's the destination subnet's IRB interface's mac address that will be used as the source mac address, and GW1's IRB mac address for the destination subnet is used as the dst mac address. It is true that an NVE may have the same system mac address for all its IRB interfaces, but it's good to point out which IRB is used (and if different IRB mac address is used, things will still work out).

Also, while each subnet is attached to each NVE, the IP routing process (e.g. TTL decrement) happens twice - first on the source NVE and then on the source GW. That's probably OK, but better point out all these details.

4.5 Use of Centralized Gateway

   In this scenario, the NVEs within a given data center need to forward
   traffic in L2 to a centralized L3GW for a number of reasons: a) they
   don't have IRB capabilities or b) they don't have required policy for
   switching traffic between different tenants or security zones.

For b), do we configure IRB on those non-centralized gateways at all? I assume not (even though the NVE could support IRB) - It's better to be clear.

I'll send a follow up email about the symmetric section.

Thanks.

Jeffrey

> -----Original Message-----
> From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Martin Vigoureux
> Sent: Monday, February 13, 2017 5:07 PM
> To: BESS <bess@ietf.org>
> Subject: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
> 
> Hello Working Group,
> 
> This email starts a Working Group Last Call on
> draft-ietf-bess-evpn-inter-subnet-forwarding-03 [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-inter-subnet-forwarding, 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-inter-subnet-forwarding-03 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-inter-subnet-forwarding/
> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
> 
> _______________________________________________
> BESS mailing list
> BESS@ietf.org
> https://www.ietf.org/mailman/listinfo/bess