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

[Pushpasis Sarkar <[e-mail]>]

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