Re: [Idr] RtgDir review: draft-ietf-idr-add-paths-13

Alia Atlas <akatlas@gmail.com> Fri, 29 April 2016 20:30 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50DA212D10E; Fri, 29 Apr 2016 13:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vju380MQqb3Q; Fri, 29 Apr 2016 13:30:55 -0700 (PDT)
Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDBE012D096; Fri, 29 Apr 2016 13:30:55 -0700 (PDT)
Received: by mail-oi0-x22c.google.com with SMTP id k142so131711248oib.1; Fri, 29 Apr 2016 13:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9XM/dRPz6RzLEhu/lUvCojPDAGy8JlLaTVFubmFqA14=; b=snu1koEI26VLFpmsx2GxRtoaNxQOoeAi1mo2ETs+tvr4D+o1tNKEeWMkk8zkJfu4dq OJQVtedBwFGzl1agfdBQrDqgboIS8SHMJZruxWcALtCo0MFNh4BFJ86IPlQGUHswJRq3 W7TME/0ovu1G3p4byXEd5iO0Rze3GChHmv+gog8zL9EJOFZ4GpJMLil7w6iI8TamlyaN EFbChJjM1A5XfHqeM2G81A7PPgG0s4leAQR1HCb3VNKcvXXjLJhxtUH7QTmNvkpGafEL /Jn5dHEkzlDGNmYkVI6vAUj4CjoyQp8yhvura8pHgm/LfcdyGntNUXS6JUbr4UKj1FLX IN+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9XM/dRPz6RzLEhu/lUvCojPDAGy8JlLaTVFubmFqA14=; b=WeZC3zCNpi9aJpygV41kHxtixr32c+E7iXAVC2+TKJ1FXd/v0QOPW29X8Asd6QZ/Zk SGSluKWy+/9tCft+F1u2wcJToEnTT2fNPZI3ngeOZUcyf3UMofto+a/HPYD07R7zDgU6 IFW0EXRy5hLEAOR6585sSiEXon+MbUEquXJZpwzylA/XhHQb6H1HXDzhwpWzVmVozXyL S2H+hz+YSf+0YwjuozVCfppjNWjRjmo5njL5RhfpFWv9RhUgQoS0QvQgZJGxbcoh2fZg 5HZUYhNCwuBQyv/yJY8W4ixVjFJ4MS6YmGrmRntbc57zTi9Y2JGL0mznb6Q1g636Rduq cocw==
X-Gm-Message-State: AOPr4FVw8WX1EpbGnjtEvngjg9WNkHfkgmncJUoFOjfHCz5wxSbexT8ndmIvUPgYGcQ3y1hzExxRQTnKMb8wTw==
MIME-Version: 1.0
X-Received: by 10.157.20.149 with SMTP id d21mr10112777ote.143.1461961855151; Fri, 29 Apr 2016 13:30:55 -0700 (PDT)
Received: by 10.60.115.168 with HTTP; Fri, 29 Apr 2016 13:30:55 -0700 (PDT)
In-Reply-To: <D3BA7D48-BDFD-44F4-B9C1-41BD2E30201F@cisco.com>
References: <D3BA7D48-BDFD-44F4-B9C1-41BD2E30201F@cisco.com>
Date: Fri, 29 Apr 2016 16:30:55 -0400
Message-ID: <CAG4d1rfe1pfSQBOK0cxZ69cNUZbhV+db7nJhHnMN8Z5Z6xCUzg@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Content-Type: multipart/alternative; boundary=001a113e22ac0d38320531a5859d
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/DjGCOTn8HS_LhNk4zRZpcEr-I7k>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "<rtg-dir@ietf.org>" <rtg-dir@ietf.org>, "draft-ietf-idr-add-paths.all@ietf.org" <draft-ietf-idr-add-paths.all@ietf.org>, "idr@ietf.org" <idr@ietf.org>
Subject: Re: [Idr] RtgDir review: draft-ietf-idr-add-paths-13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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, 29 Apr 2016 20:30:58 -0000

Hi Carlos,

Thank you very much for your review.

Shepherd & authors,

Could you please respond and update the draft ASAP with what you agree are
improvements
as well as addressing the one IETF Last Call comment with the agreed
changes?

Thanks,
Alia

On Wed, Apr 27, 2016 at 4:27 PM, Carlos Pignataro (cpignata) <
cpignata@cisco.com>; wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG review,
> and sometimes on special request. The purpose of the review is to
> provide assistance to the Routing ADs. For more information about the
> Routing Directorate, please see ​
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs,
> it would be helpful if you could consider them along with any other
> IETF Last Call comments that you receive, and strive to resolve them
> through discussion or by updating the draft.
>
> Document: draft-ietf-idr-add-paths-13
> Reviewer: Carlos Pignataro
> Review Date: April 25, 2016
> Intended Status: Proposed Standard
>
> https://datatracker.ietf.org/doc/draft-ietf-idr-add-paths/
>
>
> Summary:
> This document is basically ready for publication, but has nits that should
> be considered prior to publication.
>
> Comments:
> This is an extremely well written document, very focused and with high
> SNR. I have a couple totally-non-critical comments and questions below.
>
>
> Major Issues:
> None.
>
>
> Minor Issues:
> I have a couple of questions rather than issues:
>
> 2.  How to Identify a Path
> ...
>    A BGP
>    speaker that receives a route SHOULD NOT assume that the identifier
>    carries any particular semantics; it SHOULD be treated as an opaque
>    value.
>
> I was thinking about why “SHOULD NOT” and not “MUST NOT”, and I understand
> future proofing, but wondering if there’s another reason.
>
> The path identifier has well-defined semantics: make a path unique for a
> given prefix, or make the {identifier; prefix} specify a path among many.
> Does this sentence intend to specify that a BGP receiving a route SHOULD
> NOT assume particular semantics of the numerical value of the field? (such
> as the lower value means a more important route), or SHOULD NOT assume
> particular semantics of the structure of the field? (such as some
> hierarchy, or MSB with some meaning). Or both?
>
> Maybe, “… assume that the value or structure of the identifier carries …”?
> Or maybe it is OK as is and I am reading too much into it?
>
> 6.  Applications
>
>    The BGP extension specified in this document can be used by a BGP
>    speaker to advertise multiple paths in certain applications.  The
>    availability of the additional paths can help reduce or eliminate
>    persistent route oscillations [RFC3345].  It can also help with
>    optimal routing and routing convergence in a network.  The
>    applications are detailed in separate documents.
>
> The final sentence does not seem to add anything, other than questions.
> I’d suggest either adding pointers to those separate documents, or removing
> the sentence. This is a non-normative section.
>
> 7.  Deployment Considerations
>
>    The extension proposed in this document provides a mechanism for a
>    BGP speaker to advertise multiple paths over a BGP session.  Care
>    needs to be taken in its deployment to ensure consistent routing and
>    forwarding in a network, the details of which will be described in
>    separate application documents.
>
> Similarly, which documents? These seem like important considerations.
>
>
> Nits:
>
> 4.  ADD-PATH Capability
>
>    The ADD-PATH Capability is a new BGP capability [RFC5492].  The
>    Capability Code for this capability is specified in the IANA
>    Considerations section of this document.
>
> Why not say "The ADD-PATH Capability is a new BGP capability [RFC5492],
> with Capability Code of 69” and simplify it for the reader?
>
> 9.  Security Considerations
> ...
>   The use of the ADD-PATH Capability is intended to
>    address specific needs related to, for example, eliminating the MED-
>    induced route oscillations in a network
>    [I-D.ietf-idr-route-oscillation-stop].  While the applications for
>    the ADD-PATH Capability are outside the scope of this document, the
>    users are encouraged to examine their behavior and potential impact
>    by studying the best practices described in
>    [I-D.ietf-idr-add-paths-guidelines].
>
> Are these Security Considerations, Applications, or Deployment
> Considerations?
>
>
> I hope these help,
>
> — Carlos.
>