Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07

"Naiming Shen (naiming)" <naiming@cisco.com> Sun, 07 January 2018 05:22 UTC

Return-Path: <naiming@cisco.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CB51200F3; Sat, 6 Jan 2018 21:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 eP8eohjY4PlQ; Sat, 6 Jan 2018 21:22:07 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F4DD1242EA; Sat, 6 Jan 2018 21:22:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4750; q=dns/txt; s=iport; t=1515302526; x=1516512126; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8Ngk7jal9pL47hhog1QzYgwfv4rs79nyJMAv2fH8keI=; b=L4EDkcYm9OyCbslEEUsCXCpx3EN0/rGw+z57oc2mWEqfukc193G6N3SJ 5yvWVTXyqJ01oNZ3o9bSlOGE9BQpWkUJb3jV9sBYlSl9VCteLIJ77a5RI 0gRIjnnISue6JYZaRxZ4IO8YBjXmSc8UIKyI15hbTQ9AxONQZR8hnYWHh Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAgDnrVFa/5FdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM/gVonB4QAmHyBWyeXKoIVCoU7AhqEGEAXAQEBAQEBAQEBayi?= =?us-ascii?q?FIwEBAQECAR0GEUUFBwQCAQgVAQICAiMDAgICMBQBEAIEDgWKKQiwWYInii8BA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdgQ+FJoM+ASkMgnmDMIIFD4JxMYI0BaNeApU?= =?us-ascii?q?8lAmWagIRGQGBOwEhAjWBUG8VGU4BgX+EV3iIWoEXAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,324,1511827200"; d="scan'208";a="329642539"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2018 05:22:05 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w075M5Yw016094 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 7 Jan 2018 05:22:05 GMT
Received: from xch-rcd-004.cisco.com (173.37.102.14) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 6 Jan 2018 23:22:04 -0600
Received: from xch-rcd-004.cisco.com ([173.37.102.14]) by XCH-RCD-004.cisco.com ([173.37.102.14]) with mapi id 15.00.1320.000; Sat, 6 Jan 2018 23:22:04 -0600
From: "Naiming Shen (naiming)" <naiming@cisco.com>
To: "t.petch" <ietfc@btconnect.com>
CC: "isis-wg@ietf.org" <isis-wg@ietf.org>, Christian Hopps <chopps@chopps.org>, "isis-ads@ietf.org" <isis-ads@ietf.org>
Thread-Topic: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
Thread-Index: AQHTXmMvIlsDCkaUj0W5jcon0L55haMrdnkAgAD5RwCAFzjKAIAWpEsAgAAgg36ADEXKAIAAYM43gADgCoCAAKK6AA==
Date: Sun, 7 Jan 2018 05:22:04 +0000
Message-ID: <5DA4C022-143A-4706-A53E-2C9CFBF4C9DC@cisco.com>
References: <87375fp3hv.fsf@chopps.org> <7185dbc2d3f34b9ea844ddef95b6278c@XCH-ALN-008.cisco.com> <481C1CEE-A8B4-4034-B016-D2673296E96B@cisco.com> <700e8fed-40fc-cb1a-1ae3-f8401f167aae@gmail.com> <DDC43BA0-7D70-4D7E-B023-A5C04E8B1B88@cisco.com> <007601d38094$72d122a0$4001a8c0@gateway.2wire.net> <9EED72FB-9263-4DA1-95C1-D4E1B4C1A6C0@cisco.com> <00e501d386e8$35957bc0$4001a8c0@gateway.2wire.net> <E7B4BFE2-4EA2-4C3A-BCE4-389300D1B8F4@cisco.com>
In-Reply-To: <E7B4BFE2-4EA2-4C3A-BCE4-389300D1B8F4@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.24.76.21]
Content-Type: text/plain; charset="utf-8"
Content-ID: <19F734D25FF21E4C9891AE294909B114@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/EDZsNhEnkLKJZxdW34qRUEjlkqI>
Subject: Re: [Isis-wg] WG Last Call for draft-ietf-isis-reverse-metric-07
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jan 2018 05:22:09 -0000

Tom,

Actually RFC 5029 does not mention anything about handling
multiple same link-attribute sub-TLV, it just says if a router does not support
this sub-TLV, it will silently ignore the sub-TLV, and this is true
for any IS-IS TLV or sub-TLV. If one does not understand, it has
to ignore it. Spiting out an error or debug message or not is up
to the implementation.

thanks.
- Naiming

> On Jan 6, 2018, at 11:39 AM, Naiming Shen (naiming) <naiming@cisco.com> wrote:
> 
> 
> Tom,
> 
> Sure. We can add similar wording on that.
> 
> thanks.
> - Naiming
> 
>> On Jan 6, 2018, at 4:12 AM, t.petch <ietfc@btconnect.com> wrote:
>> 
>> Naiming
>> 
>> One follow-up comment inline
>> 
>> Tom Petch
>> 
>> ---- Original Message -----
>> From: "Naiming Shen (naiming)" <naiming@cisco.com>
>> Sent: Saturday, January 06, 2018 12:31 AM
>> 
>>> Hi Tom,
>>> 
>>> Thanks for the review, some replies inline,
>>> 
>>> On Dec 29, 2017, at 2:53 AM, t.petch
>> <ietfc@btconnect.com<mailto:ietfc@btconnect.com>> wrote:
>>> 
>>> A couple of IANA thoughts on this I-D;
>>> 
>>> "This document requests that IANA allocate from the IS-IS TLV
>>> Codepoints Registry a new TLV, "
>>> 
>>> - Is there a particular range that this value should come from?
>>> 
>>> NS> will add the range.
>>> 
>>> 
>>> - A note in s.2 asking that TBD be replaced by the value that IANA
>>> allocates might be useful for the RFC Editor.
>>> 
>>> NS> will do.
>>> 
>>> 
>>> - Are the flag bits of this new TLV going to form a new registry?
>>> 
>>> NS> it is not.
>>> 
>>> 
>>> - And a non-IANA thought - what does a receiver do if it receives more
>>> than one such TLV?
>>> 
>>> NS> In section 2, it mentions "A sender MUST only transmit a single
>>>    Reverse Metric TLV in a IS-IS Hello PDU.”
>> 
>> I know it does, but I also know that we cannot rely on all
>> implementations being perfect:-)
>> 
>> Look at some other RFC (e.g. RFC5029) and you will find an action
>> defined such as subsequent ones will be ignored, or perhaps that this
>> should be treated as a fatal error or ..  I suggest something similar
>> here although have no strong views what the action should be.
>> 
>> Tom Petch
>> 
>>> "This document also request that IANA allocate from the link-attribute
>>> bit value for sub-TLV 19 of TLV 22."
>>> I struggled to parse this initially.
>>> 
>>> Perhaps
>>> "This document also requests that IANA allocate a bit from the
>>> 'link-attribute bit values for sub-TLV 19 of TLV 22' registry.
>>> 
>>> 
>>> NS> OK.
>>> 
>>> (That registry title is a bit of a mouthful compounded by the lack of
>>> Capitals in the title:-(
>>> 
>>> The coupling between the request to IANA to allocate the bit and the
>>> actual definition in the body of the I-D is ... well, non-existent.
>> You
>>> should have a something about the octet with a TBD2 (not a second TBD)
>>> in section 3.6, a TBD2 in the IANA actions and a request that this be
>>> replaced by RFC Editor by the value that IANA allocates.
>>> 
>>> 
>>> NS> will do.
>>> 
>>> thanks.
>>> - Naiming
>>> 
>>> Yes, a reader can deduce all this but the lack of precision is how
>>> mistakes are made IMO.  RFC5209 has the sort of detail that I would
>>> expect.
>>> 
>>> Tom Petch
>>> 
>>> ----- Original Message -----
>>> From: "Naiming Shen (naiming)"
>> <naiming@cisco.com<mailto:naiming@cisco.com>>
>>> 
>>> 
>>> 
>> 
>