[RTG-DIR] Rtgdir early review of draft-ietf-bess-evpn-mh-split-horizon-04
Himanshu Shah via Datatracker <noreply@ietf.org> Fri, 07 April 2023 17:58 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: rtg-dir@ietf.org
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 05340C1522BD; Fri, 7 Apr 2023 10:58:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Himanshu Shah via Datatracker <noreply@ietf.org>
To: rtg-dir@ietf.org
Cc: bess@ietf.org, draft-ietf-bess-evpn-mh-split-horizon.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 9.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168089032501.2696.11910705338187037707@ietfa.amsl.com>
Reply-To: Himanshu Shah <hshah@ciena.com>
Date: Fri, 07 Apr 2023 10:58:45 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/s0KzvyIEiL_JQVkPIvthUd4xRqE>
Subject: [RTG-DIR] Rtgdir early review of draft-ietf-bess-evpn-mh-split-horizon-04
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Apr 2023 17:58:45 -0000
Reviewer: Himanshu Shah Review result: Ready This draft provides a choice of split-horizon method to use which especially is useful when multiple encapsulations are supported. The Split-Horizon-Type (SHT) is introduced as 2-bits value in the flag field of ETH-AD per ES route. The document is very well written. Every single discrepancies that may occur, along with backward compatibility, is explained and what actions to take are covered. This is important for interoperability. I have a minor comment on last paragraph of section 2.4, as below. The paragraph - If an NVE changes its operational SHT value from 01 to 00 (as a result of a new non-upgraded NVE present in the ES) and it previously advertised a zero ESI Label, it MUST send an update with a non-zero valid ESI Label, unless all the non-upgraded NVEs in the ES support Local Bias only. -- “unless all the non-upgraded NVEs in the ES support Local Bias only” This last sentence needs clarification. Let us say there were N1, N2 and N3 nodes in the ESI and they all advertised SHT as 01 (local bias). Now a new “non-upgraded” (i.e. old SHT unaware) node also joins the same ESI, all newer nodes N1 to N3 will have to re-advertise with non-zero ESI label. …but may be not - if all SHT-unaware NVEs in ES are Local Bias (say VXLAN)? It would be great if this can be clarified with an example. In general, wherever possible, give examples - that would make the document even more easier for implementers to follow. All-in-all, very nicely written document. Thanks, Himanshu
- [RTG-DIR] Rtgdir early review of draft-ietf-bess-… Himanshu Shah via Datatracker
- Re: [RTG-DIR] Rtgdir early review of draft-ietf-b… Jorge Rabadan (Nokia)