[Idr] Rtgdir telechat review of draft-ietf-idr-bgp-extended-messages-33

Himanshu Shah via Datatracker <noreply@ietf.org> Fri, 19 July 2019 01:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A33461201E3; Thu, 18 Jul 2019 18:33:50 -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: idr@ietf.org, draft-ietf-idr-bgp-extended-messages.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.99.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Himanshu Shah <hshah@ciena.com>
Message-ID: <156350003058.16320.1706123920028504977@ietfa.amsl.com>
Date: Thu, 18 Jul 2019 18:33:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/96opU2QEC3rJRDdO8u8p6RBNA3I>
Subject: [Idr] Rtgdir telechat review of draft-ietf-idr-bgp-extended-messages-33
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2019 01:33:51 -0000

Reviewer: Himanshu Shah
Review result: Has Nits


I have some suggestions to improve the document by adding more context to the
goal of this draft.


The document is concise, clear and easy to read.

Since this is my first review as Routing directorate, the suggestions I have,
could be out-of-scope. Will leave at the discretion of AD and authors, if
suggestions are worth pursuing or not.

While Introduction section briefly mentions newer capabilities as the reason
for extended message size for the BGP, it may help the reader to expand on the
advantages of extended message as compared to current limitation of 4K BGP
messages.  For me, subsequent reading of the document as it underlines the
migration, error cases and security risks, the advantages of extended message
size seems to dissipate.

I also suggest that authors address issue of extended delay at the receiver in
processing of large size BGP messages while TCP’s reliable transport is
building a complete message under challenging network conditions and compare
that against smaller messages in distressed network.

In my view, making a strong case on why extended message size, would greatly
add value.

 Major Issues:

No major issues found.

Minor Issues:

No minor issues found. Please note the suggestion in the comment section above.


See suggestions in comments section