Re: Gen-ART LC review of draft-ietf-isis-node-admin-tag-08

Pushpasis Sarkar <pushpasis.ietf@gmail.com> Tue, 03 May 2016 05:07 UTC

Return-Path: <pushpasis.ietf@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D844012D1BC; Mon, 2 May 2016 22:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 4IwxAgPd9f6k; Mon, 2 May 2016 22:07:19 -0700 (PDT)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (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 76D0E12D1B0; Mon, 2 May 2016 22:07:19 -0700 (PDT)
Received: by mail-pa0-x230.google.com with SMTP id xk12so4806825pac.0; Mon, 02 May 2016 22:07:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=BxkJlmHtZ6bR0/r2nRiAFZF5/k6UWWK8d1hz1fSYPaE=; b=v+bHBA8l9mRkdmJL0qmJpbXk2dJYMzDUjEPJ77fvSzoDNjpTZow4Ui1KP/LjiXo5Dx yZCJAIXrB3865V6hB42600GLaqDlL2BD6mXIhRK5JkNIc4HKZxXlTw5fF5KKLyQDYEAH DtogHPZzknZY+2GCyLcDXqaKvY2FGon5C7QAtw2c507131APVT8zV3WOoEDQh87KW8SI GRtsgKZbKRl+s68D6KBKo2Y8XstbwwFoR3tGeNBeuAafk1YMG1iEvGBLO3vAAgaYJtc5 fwtJfHOqz41RUcjKEnBJsZmkmoWYTNelRIyMP7oG3muP+xfxuzbLvo9gAteElE4xg522 n4bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=BxkJlmHtZ6bR0/r2nRiAFZF5/k6UWWK8d1hz1fSYPaE=; b=W474kDpbRJAnrVFKqanvqrN2ivs4G9Z8PG8PVjBClbN/9vwAFeeigP9Esgf76PMf97 OqXxpRjY1pQtxFDSMUWIkl8vBGof8b0+kWACDNbKo26MvVXYMpHkvk9UY2fg+XFp996U rkybWnh2ymzmjRqHBQEIYf58TQXwS3XBkZPLH/3l4Qd7OUvLzWSIV0r/tXJMy8/kt69k r0qZrf6Xn3PPwP43qkNCRQJWhXTvi93ZVLx2JGkSRoGMHHfY0sq7odlvsws6q+jJ0dSL bOdBDZYkRgBpKWNo91f9i2/hiqnEBFoIyeOwIYcRuaAQnKT5aMtEI75gpkc0W/18pkem 6f5A==
X-Gm-Message-State: AOPr4FUASVilunE5V7MBmAYfFm9hkE3P8izByCrCPUUSWRgAW8kDLYDi/MppNxBzQZgKfg==
X-Received: by 10.66.231.73 with SMTP id te9mr632851pac.62.1462252038992; Mon, 02 May 2016 22:07:18 -0700 (PDT)
Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id s66sm1936340pfi.3.2016.05.02.22.07.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 02 May 2016 22:07:18 -0700 (PDT)
Subject: Re: Gen-ART LC review of draft-ietf-isis-node-admin-tag-08
To: Peter Yee <peter@akayla.com>, draft-ietf-isis-node-admin-tag.all@ietf.org
References: <00ef01d1a2bc$1e6a0130$5b3e0390$@akayla.com> <57278FB0.9090901@gmail.com> <019901d1a4f5$78f91e70$6aeb5b50$@akayla.com>
From: Pushpasis Sarkar <pushpasis.ietf@gmail.com>
Message-ID: <57283202.3030904@gmail.com>
Date: Tue, 3 May 2016 10:37:14 +0530
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <019901d1a4f5$78f91e70$6aeb5b50$@akayla.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/KJAmliPZTqL_3fhM9ghUoFQVAnQ>
Cc: gen-art@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 May 2016 05:07:22 -0000

Hi Peter,

Please find comments inline..

Thanks and Regards,
-Pushpasis

On Tuesday 03 May 2016 10:07 AM, Peter Yee wrote:
> Pushpasis,
>
> 	See my replies below prefaced with PEY>.
>
> 	Thanks.
> 			-Peter
>
> -----Original Message-----
> From: Pushpasis Sarkar [mailto:pushpasis.ietf@gmail.com]
> Sent: Monday, May 02, 2016 10:35 AM
> To: Peter Yee; draft-ietf-isis-node-admin-tag.all@ietf.org
> Cc: gen-art@ietf.org; ietf@ietf.org
> Subject: Re: Gen-ART LC review of draft-ietf-isis-node-admin-tag-08
>
> Hi Peter,
>
> Once again many many thanks for the detailed review comments. Please find
> few comments inline. Unless otherwise there is a counter-comment the comment
> is accepted and will be addressed in the next version to be uploaded soon.
>
> Thanks and Regards,
> -Pushpasis
>
> On 4/30/16 2:11 PM, Peter Yee wrote:
>> I am the assigned Gen-ART reviewer for this draft.  The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed by
>> the IESG for the IETF Chair.  Please treat these comments just like
>> any other last call comment.  For background on Gen-ART, please see
>> the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>
>>
>> Document: draft-ietf-isis-node-admin-tag-08
>> Reviewer: Peter Yee
>> Review Date: April 27, 2016
>> IETF LC End Date: April 29, 2016
>> IESG Telechat date: May 5, 2016
>>
>> Summary: This draft is basically ready for publication as a Standards
>> Track RFC, but has some issues that should be fixed/considered before
> publication.
>> [Ready with issues]
>>
>> This draft defines a means to carry additional per-node administrative
>> tags with the IS-IS protocol.  These tags can be used along with local
>> policy to simplify the management of routing and path selection.  This
>> specification gives informative examples of such tag usage but does
>> not otherwise prescribe the meaning of the tags.
>>
>> This review was generated prior to the release of draft -09 (but not
>> keyed in until April 29th), but many of the issues and nits noted
>> below remain in draft -09.  Obviously, some of my comments no longer
>> apply.  I'll address draft -09 specifically for the telechat review,
>> but you should look at the points here prior to that review to save
>> time.  Given that draft -09 substantially reduces Section 5, I've
>> removed my comments regarding that section as well as in a few other
> places.
>> Major issues: None
>>
>> Minor issues:
>>
>> Page 4, last partial paragraph: the number 63 is given for the maximum
>> number of per-node administrative tags that can be carried in a sub-TLV.
>> Given the maximum length of a sub-TLV is 250 octets (and 2 octets are
>> otherwise used by type and length), I would argue that the correct
>> number here is 62 (62*4 = 248).  Also, I would delete the text starting at
> "and".
>> In all cases, when more than 62 tags are used, a single sub-TLV will
>> not provide sufficient space.
> [Pushpasis] AFAIK, maximum length of sub-TLV is 255 (because length field if
> 1 byte). If you take out 2 bytes for length and value, we have
> 253 bytes left.. 253 divided by 4byte = 63 (63x4=252).. Let me know if my
> understanding is wrong.
>
> PEY>RFC 4971 (Section 2) gives this text: "Set of optional sub-TLVs (0-250
> octets)".  My interpretation was that the Router CAPABILITY TLV can have a
> length of 5-255 octets, of which 4 are the router ID and 1 is the flags,
> leaving up to 250 octets for the sub-TLVs.
[PS2] You are totally right.. I overlooked the structure of the Rtr Cap 
Tlv itself. I will make the changes.
>> Page 5, 1st partial paragraph, 1st full sentence: Sub-TLV values are
>> given here as cumulative.  Is there any need or desire to be able to
>> subtract tags?  How would a router disassociate itself from a tag that
>> was no longer relevant to the router?  This ability is implied in
>> Section 4.3, 2nd paragraph, but that conflicts with the statement
>> given here.  In general, I believe the ability to reset the flooded
>> tags associated with a router or to delete a tag is underspecified.
> [Pushpasis] Assuming the comment is on the following sentence..
> "Such occurrence of the 'Node
>      Administrative Tag' sub-TLV does not cancel previous announcements,
>      but rather is cumulative."
>
> The reference here to "previous announcements" is not the ones received in
> the previous instances of the same LSP fragment but to the ones received in
> other TLVs in same or different LSP fragments originated by the same
> router... What it essentially mean is that if a router originates 3
> node-admin-tag TLVs in three different LSP fragments.. the later ones do not
> cancel/override the previous ones but are rather considered all together..
> in an additive manner.. Perhaps I will add a line or two clarify the same..
> I also see RFC7777 has altogether removed the stanza in the final RFC
> edition.. Will that be fine too with you for this draft?
>
> PEY> Alignment with RFC 7777 makes sense, given that the general concept is
> to do the same thing for each of the routing protocols.
>
> Alternatively, I can propose the following clarifying text... If it makes
> any sense to you :)
>
> "Such occurrence of a
>       'Node Administrative Tag' sub-TLV, found in a LSP fragment received
> recently, does not cancel
>       the one(s) received in any recent versions of other LSP fragments
> originated by the same
>       router. Instead, all the 'Node Administrative Tag' sub-TLVs found in
> all the LSP fragments
>       originated by the same originating router, should be treated as
> cumulative."
>
> PEY> That's less satisfying because it requires some definition of recent.
> It also doesn't seem to solve my cumulative issue in that if an originating
> router sends some number of Node Administrative Tag sub-TLVs, the receiving
> router doesn't seem to have a way of knowing when to flush or reset them
> unless the definition of recent implies this or something in IS-IS makes it
> obvious when the old tags are no longer relevant and new tags should not be
> accumulated with the old ones.
>
>> Page 6, 1st partial paragraph, 1st sentence: Care to define
>> "reasonably small"?  Previously, the ability to send more than 63 (or
>> perhaps 62, see
>> above) tags was specified in section 3.1.  What's the limit to
>> reasonableness?  (Not that an exact number seems to matter at all for
>> the purposes of this specification, which is agnostic to the specific
>> number or the use of the tags.)
> [Pushpasis] I see the only way to resolve this comment is by removing the
> stanza being referred to in the last comment..
>
> PEY> Yeah, that's the problem with words that require interpretation. :-)
[PS2] Will remove it then..
>
>> Page 6, Section 4.3, 2nd paragraph: This paragraph implies that a
>> large set (greater than 62 at least) of sub-TLVs will have to be sent
>> in multiple Router CAPABILITY TLVs and those TLVs must(?) occur in a
>> single Link-State PDU.  Or how is the receiving router to know that it
>> has the complete set of tags?  Also, the implication seems to be that
>> while section 3.1 indicates a strictly cumulative capability, there
>> must be someway of terminating those cumulative changes and allowing a
> reset.  What is that signaling mechanism?
> [Pushpasis] This is dealt with ISIS LSP fragment generation and reception..
> A typical ISIS implementation will be able to figure out any given point
> whether it has received all the fragments originated by a originating router
> or not. Please refer to ISO-10589 for more details..
> There are no extra requirements imposed by this draft in this regard.
>
> PEY> So Section 3.1 indicates accumulation of tags until the IS-IS
> implementation determines that it has received all fragments.  That's fine.
> Then I would indicate in Section 3.1, if you elect to keep that text, that
> completion of fragment reception terminates the cumulative action and new
> fragments will restart the accumulation.  Or just align with RFC 7777, drop
> the cumulative statement, and my comment will seem moot and tiresome. ;-)
[PS2] I see now why RFC7777 chose to drop the text :)