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

Pushpasis Sarkar <> Tue, 03 May 2016 05:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D844012D1BC; Mon, 2 May 2016 22:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4IwxAgPd9f6k; Mon, 2 May 2016 22:07:19 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76D0E12D1B0; Mon, 2 May 2016 22:07:19 -0700 (PDT)
Received: by with SMTP id xk12so4806825pac.0; Mon, 02 May 2016 22:07:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id te9mr632851pac.62.1462252038992; Mon, 02 May 2016 22:07:18 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id s66sm1936340pfi.3.2016. (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 <>,
References: <00ef01d1a2bc$1e6a0130$5b3e0390$> <> <019901d1a4f5$78f91e70$6aeb5b50$>
From: Pushpasis Sarkar <>
Message-ID: <>
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$>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 May 2016 05:07:22 -0000

Hi Peter,

Please find comments inline..

Thanks and Regards,

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 []
> Sent: Monday, May 02, 2016 10:35 AM
> To: Peter Yee;
> Cc:;
> 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 <>
>> 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 :)