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

Erik Kline via Datatracker <noreply@ietf.org> Wed, 15 July 2020 06:22 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bess@ietf.org
Delivered-To: bess@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 493393A096A; Tue, 14 Jul 2020 23:22:16 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bess-evpn-inter-subnet-forwarding@ietf.org, bess-chairs@ietf.org, bess@ietf.org, Zhaohui Zhang <zzhang@juniper.net>, zzhang@juniper.net
X-Test-IDTracker: no
X-IETF-IDTracker: 7.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <159479413627.21953.4241600579036639955@ietfa.amsl.com>
Date: Tue, 14 Jul 2020 23:22:16 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/jNI9e747eziauU871kJSq0EDYRI>
Subject: [bess] Erik Kline's Discuss on draft-ietf-bess-evpn-inter-subnet-forwarding-09: (with DISCUSS and COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2020 06:22:16 -0000

Erik Kline 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:
----------------------------------------------------------------------

[ general ]

* Can you give an example of what happens to non-IPv4/IPv6 Ethernet packets
  received at the NVE/PE?  Do they get bridged, and if so how far?  What
  happens if a host in BT1 ARPs for IPv4 address associated with a TS in
  a different BT?

* Where there are multiple prefixes in an IP-VRF, is there a constraint that
  any other IP-VRF that contains one of the prefixes must contain all of them?
  Perhaps that's in 7432...?

[ sections 4, 5.4, 5.4, 6.3, 6.4, 9.1.2, 9.2.2 ]

* Please document what happens to IPv4 TTL/IPv6 Hop Limit values as they
  cross various NVEs/PEs.

[ section 7 ]

* Is there a reference for IRB-EXT-MOBILITY?

* The two statements:

  (1) "Although the language used in this section is for IPv4 ARP,
      it equally applies to IPv6 ND."

  (2) "If there is [a] many-to-one relationship such that there are many host
      IP addresses correspond[ing] to a single host MAC address ..., then to
      detect host mobility, the procedures in [IRB-EXT-MOBILITY] must be
      exercised..."

  are in direct conflict.  All IPv6 hosts having at least one non-link-local
  unicast address will have more than one IP address per MAC and this section,
  or even this document, would not apply?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[ general ]

* I believe this is true, but can you just state here (not in the doc) that
  there are no multi-link subnets that can be created with this model as
  defined in RFC 4903? It seems like everything is as it should be, but just
  to double-check.

[ section 1 ]

* IP-VRF definition: s/VPN Routing.../Virtual Routing/?

[ section 3 ]

* 2nd to last paragraph: Is any of this still true for a setup that
  involves multiple IPv6 prefixes per BD, maybe I misunderstood
  (or maybe this assumed single prefix per broadcast domain w/ IPv4-only?).

  Perhaps avoid suggesting there's a 1:1 relationship and use phrases
  likes "at least as many X as there are Y" or something?

[ section 4 ]

* ARP table: a less IPv4-specific name, even though it's define to hold both
  IPv4 and IPv6 associations, would be "neighbor table".  That might be
  overloaded in routing contexts so no need to change it.