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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 27 April 2016 20:27 UTC

Return-Path: <cpignata@cisco.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 6B5EB12DC12; Wed, 27 Apr 2016 13:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 IUOq4lDIFEHI; Wed, 27 Apr 2016 13:27:03 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2292012DC0F; Wed, 27 Apr 2016 13:27:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16262; q=dns/txt; s=iport; t=1461788823; x=1462998423; h=from:to:cc:subject:date:message-id:mime-version; bh=DCWPGKaQC1N3HdASo2sguw2Egqs+OO1aIoF+jEkPTj4=; b=FotAQ3osc8AJ2lZufVRE7bG3Smc0dNuS1S1vTreICKuiorJuqZPVXpra pxfNsukmMyMIjltLwVrsSSZYya7arOxLBkZjAb5b4zzhFe4p0GZdT304d Oj/6knpMp9BjwYO+cotsUHPrpdT1MvvXZOHnmIgz6Nb5JvNRLoTszR75i o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAgD3HyFX/5JdJa1UCoM4U30BBalpi?= =?us-ascii?q?wqEcwENgXYihW0egRo4FAEBAQEBAQFlJ4RII0QSEgEGFi4CBDAnBA6ILw6UHJ0?= =?us-ascii?q?XkRMBAQEBAQEBAQEBAQEBAQEBAQEBF4YhgXWEZIIHSIJgK4IrBZMfhHEBhXuIG?= =?us-ascii?q?4FnToN/iF2PLwEPDwEBQoNrbYg2fwEBAQ?=
X-IronPort-AV: E=Sophos; i="5.24,543,1454976000"; d="scan'208,217"; a="98427201"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Apr 2016 20:27:02 +0000
Received: from XCH-RTP-019.cisco.com (xch-rtp-019.cisco.com [64.101.220.159]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u3RKR1uu018288 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 27 Apr 2016 20:27:02 GMT
Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-019.cisco.com (64.101.220.159) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 27 Apr 2016 16:27:01 -0400
Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1104.009; Wed, 27 Apr 2016 16:27:01 -0400
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-idr-add-paths-13
Thread-Index: AQHRoMMn98zHhK2TjUSNYmp93K/cmA==
Date: Wed, 27 Apr 2016 20:27:00 +0000
Message-ID: <D3BA7D48-BDFD-44F4-B9C1-41BD2E30201F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.150.49.220]
Content-Type: multipart/alternative; boundary="_000_D3BA7D48BDFD44F4B9C141BD2E30201Fciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/NLCg64YJDqQ1gNQaDPugakyS8Ko>
Cc: "<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: [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: Wed, 27 Apr 2016 20:27:05 -0000

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.