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

From: Pushpasis Sarkar <[email-masked]>
Date: Mon, 2 May 2016 23:04:40 +0530

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

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

>
> 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..
>
> 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.
>
> Nits:
>
> General:
>
> The use of capitalization of Per-node administrative tag varies throughout
> the document.  It seems clear that you mean for it to be written as
> "Per-node Administrative Tag" when referring to the name of sub-TLV.  For
> other uses, I would suggest using "per-node administrative tag"
> consistently.  Use that to replace "Per-node administrative tag".
>
> Separate parenthetical elements from the preceding and following words with
> a space.  These aren't function calls. ;-)
>
> Replace any use of "per-node admin tag" with "per-node administrative tag".
> The shortening is fine for the document header which would otherwise become
> unreadable.
>
> And change all of my references to "per-node" to "node", since draft -09
> drops the "per-". :-)
>
> Replace "TLV 242" with "the Router CAPABILITY TLV".
>
> Specific:
>
>   Page 1, Abstract:  delete the first comma in the Abstract.
>
> Page 3, first paragraph after the lettered items, 3rd sentence: insert "the"
> before "Router".
>
> Page 3, Section 2, 1st sentence: change "Tag" to "tag".
>
> Page 3, Section 2, 3rd sentence: insert "a" before "certain".
>
> Page  3, Section 3, 1st paragraph, 1st sentence: change "TLV-242" to "TLV
> (IS-IS TLV type 242)" and delete the closing parenthesis after "[RFC4971".
>
> Page 3, Section 3, 1st paragraph, 3rd sentence: change "the same" to "it".
> Change "they" to "it".  Change "specfied" to "specified".  Insert "the"
> before "originating".  Delete "the" before "other".
>
> Page 3, Section 3, 1st paragraph, 5th sentence: change "are" to "is".
>
> Page 3, Section 3, 1st paragraph, 6th sentence: delete the comma.
>
> Page 3, Section 3, 1st paragraph, 7th sentence: change "Operator" to "The
> operator".
>
> Page 4, Section 3, last paragraph, 1st sentence: insert "the" before
> "Per-node" (after having changed "per-node" to "Per-node").
>
> Page 4, Section 3, last paragraph, 2nd sentence: change "topology specific"
> to "topology-specific".
>
> Page 4, Section 3.1, 1st paragraph, 1st sentence: change "ISIS" to "IS-IS".
>
> Page 4, Section 3.1, Length definition: change "A" to "An".
>
> Page 4, Section 3.1, Value definition: change "sequence" to "set".  Sequence
> would seem to imply order which is contradicted by Section 4.1.  Change "4
> octets" to "4-octet values".
>
> Page 5, 1st partial paragraph, 1st full sentence: append a comma after
> "such" and insert "each" before "occurrence".
>
> Page 5, Section 4.1, 1st paragraph, 1st sentence: change "Meaning" to "The
> meaning".
>
> Page 5, Section 4.1, 1st paragraph, 2nd sentence: change "Router" to "A
> router".
>
> Page 5, Section 4.1, 2nd paragraph, last sentence: append a comma after
> "change".
>
> Page 5, Section 4.1, 4th paragraph, 2nd sentence: delete "The".  Change
> "TLVs" to "sub-TLVs".  Change "adminsitrative" to "administrative".
>
> Page 5, Section 4.1, 4th paragraph: the paragraph, starting at "The list of
> per-node" is pretty much redundant given the admonition in the first
> sentence of the previous paragraph.  Perhaps delete it rather than belabor
> the point?
>
> Page 5, Section 4.1, 1st paragraph, 4th sentence: change "well known" to
> "well-known".  Change "capability" to "CAPABILITY".
>
> Page 6, 1st partial paragraph, 2nd sentence: insert "the" before
> "reachability".
>
> Page 6, Section 4.3, 1st paragraph, 1st sentence: delete "(TLV-242)".
>
> Page 6, Section 4.3, 1st paragraph, 3rd sentence: change "an" to "a".  Based
> on Section 3.1, I might change "changes" to "adds to" because Section 3.1
> specifies that sub-TLVs are cumulative.
>
> Page 10, Section 7, 1st paragraph, 3rd sentence: change "ISIS" to "IS-IS".
> Change "is" to "are".
>
> Page 10, Section 7, 2nd paragraph, 2nd sentence: insert "the" before "case".
> Insert "the" before "forwarding".  Insert a space before "and".
>
> Page 12, Section 8, 2nd sentence: insert "The" before "YANG".
>
> Page 12, Section 8, 3rd sentence: insert "The" before "IS-IS".  Insert "the"
> before "routing".
>
> Page 12, Section 9, item i): why is the sub-TLV name hyphenated here and not
> elsewhere?
>
> Page 12, Section 10: append a comma after "Chunduri".
>

---

From: "Peter Yee" <[email-masked]>
Date: Mon, 2 May 2016 21:37:16 -0700

Pushpasis,

	See my replies below prefaced with PEY>.

	Thanks.
			-Peter

-----Original Message-----
From: Pushpasis Sarkar [mailto:[email-masked]] 
Sent: Monday, May 02, 2016 10:35 AM
To: Peter Yee; [email-masked]
Cc: [email-masked]; [email-masked]
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>
>
> 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.
> 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.

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

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
     router. Instead, all the 'Node Administrative Tag' sub-TLVs found in
all the LSP fragments

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
> 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. :-)

> 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. ;-)

---

From: Pushpasis Sarkar <[email-masked]>
Date: Tue, 3 May 2016 10:37:14 +0530

Hi Peter,

Please find comments inline..

Thanks and Regards,
-Pushpasis

> 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.
> PEY> Yeah, that's the problem with words that require interpretation. :-)
[PS2] Will remove it then..
> the cumulative statement, and my comment will seem moot and tiresome. ;-)
[PS2] I see now why RFC7777 chose to drop the text :)