IETF Logo Mail Archive

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

"Alvaro Retana (aretana)" <aretana@cisco.com> Sun, 01 May 2016 00:23 UTC

Return-Path: <aretana@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 3FA6212D1BA; Sat, 30 Apr 2016 17:23:41 -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_H4=-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 J1p8XhzZGAKb; Sat, 30 Apr 2016 17:23:39 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54C7912D1B4; Sat, 30 Apr 2016 17:23:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5230; q=dns/txt; s=iport; t=1462062219; x=1463271819; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=28jPHOSletqYWmLZfb3sNnnkRg54L/oeVKWFqs9SlRg=; b=gg/XrVzE5MVsJU/oqb1B35DIG036VnLcHs+BviYCY+kusvaU+RhV6t9C tmXXF+qpjBTlPLkkWlXZ3lMhW7b75QLP50c0jkESnmjcDW0wbgOz//IE8 K1i8VhBAQ+Zrb5bt1u829gL309MLxmIzDgeIeTC+y6AZYkT+YS+h7VNXy k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BtBwBuSyVX/4kNJK1UCoJsTIFQBrR6hQGBdoYQAoEdORMBAQEBAQEBZSeEQgEBBGcSEAIBCAQ7BzIUEQIEAQ0FiCrDMgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRMgg6CB4V+BY4PhRSEcQGOF48RjzABIQFAg2tshn5/AQEB
X-IronPort-AV: E=Sophos;i="5.24,559,1454976000"; d="scan'208,217";a="268220814"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 May 2016 00:23:38 +0000
Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u410Nc7m003311 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 1 May 2016 00:23:38 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 30 Apr 2016 19:23:37 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.009; Sat, 30 Apr 2016 19:23:38 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Thread-Topic: RtgDir review: draft-ietf-idr-add-paths-13
Thread-Index: AQHRoMMn98zHhK2TjUSNYmp93K/cmJ+jTqEA
Date: Sun, 01 May 2016 00:23:38 +0000
Message-ID: <D34ABA8B.1229DE%aretana@cisco.com>
References: <D3BA7D48-BDFD-44F4-B9C1-41BD2E30201F@cisco.com>
In-Reply-To: <D3BA7D48-BDFD-44F4-B9C1-41BD2E30201F@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.249.22]
Content-Type: multipart/alternative; boundary="_000_D34ABA8B1229DEaretanaciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/9XmgfswC-mGkrkvSEojJd5gZKDk>
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: 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: Sun, 01 May 2016 00:23:41 -0000

On 4/27/16, 4:27 PM, "Carlos Pignataro (cpignata)" <cpignata@cisco.com<mailto:cpignata@cisco.com>> wrote:

<hat>author</hat>

Carlos:

Hi!  Thanks for the review!

I just posted version -14.

Thanks!

Alvaro.


...
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?

At one point in time I think we toyed with the fact that the Path ID could indicate which was the bestpath, for example.  We had added that text to cover the point that there is no specific interpretation that should be assumed.

All the Last Call reviews we got point at this piece of text, so we're modifying it to take the rfc2119 language out.

v2.23.0 | Report a Bug | By Email