Multi-Part TLVs in IS-IS
draft-ietf-lsr-multi-tlv-19

Many thanks to the authors and the WG for this important document for ISIS that addresses a pressing scaling challenge with a pragmatic solution.

My thanks to Yingzhen as the document shepherd for putting together a very good write-up that provides a summary of the document through its WG phase.

Thanks to the authors for working through addressing all of my DISCUSS concerns and almost all of my comments/suggestions for improving this document. For a couple of non-blocking comments where we could not converge, I am ok with going with what has emerged from the WG consensus.

Hi Parag, Tony L., Tony P., Shraddha, and Les, 

Many thanks for the effort put into this specification. 

I strongly support the objective of this effort and like the pragmatic approach followed here. So, thanks again.

I have some comments that I’d like to be addressed/discussed, especially the ones marked with (*).

# General

## (nit) Please use consistent wording MP-TLV vs. Multi-Part TLV through the document

## (nit) I may be old school, but I think the document should use “router”, instead of “node”.

# Abstract (nit): not every technologies is adding info into IGP + split a long sentence: 

OLD:
   New technologies are adding new information into IS-IS while
   deployment scales are simultaneously increasing, causing the contents
   of many critical TLVs to exceed the currently supported limit of 255
   octets.  

NEW:
   Deploying some new techniques relies upon adding new information into IS-IS while
   deployment scales are simultaneously increasing. This causes the contents
   of many critical TLVs to exceed the currently supported limit of 255
   octets.  

# Introduction

## (nit) s/Some TLV definitions have addressed this by explicitly/Some TLV definitions have addressed this issue by explicitly

## Justification for alternate mechanisms (*)

CURRENT: 

   Any future document which
   proposes a different mechanism for scaling TLV contents for a given
   codepoint MUST provide justification.

I’m not fun of normative language in an introduction (as the context is not yet well established), we may consider replacing “provide justification” with a more meaningful guidance, e.g., “identify the shortcomings of the multiple part approach and motivate the need for a another mechanism”.

Also, you may consider: s/ Any future document which proposes/Any future document that proposes standardizing

## I would delete ", if they choose not to specify another extension mechanism".

# Section 3.2.1

Please cite where type 22 is defined + remind how the identifiers are encoded:

OLD: 
   As an example, consider the Extended IS Reachability TLV (type 22).
   …
   *  Optionally one or more of the following link identifiers:

NEW:
   As an example, consider the Extended IS Reachability TLV (type 22) [RFC5305].
   …
   *  Optionally one or more of the following link identifiers encoded as sub-TLVs (0-244 octets):

# Section 4: On Keys

CURRENT:
   The encoding of TLVs is not altered by the introduction of MP-TLV
   support.  In particular, the "key" which is used to identify the set
   of TLVs which form an MP-TLV is the same key used in the absence of
   MP-TLV support.  Also note the definition of the "key" exists in the
   specification(s) which define(s) the TLV.

   NOTE: This document intentionally does not include a definition of
   the key for each codepoint.  To do so would be redundant and risk
   unintentionally deviating from the definition which already exists in
   the relevant specifications.

## Maybe it is accurate to also remind in the note that term “key” is not used per se in these specs.

## (nit) BTW, please fix this part: s/specification(s) which define(s) the TLV/specification(s) that define(s) a TLV.

# Section 5 (*)

CURRENT: 
   When processing MP-TLVs, implementations MUST NOT impose a minimum
   length check.   

Agree... however, should we have a max of MP-TLVs to be used as a guard for splitting the information into a large numbers of TLVs?

# Section 6

## I don’t parse what is meant by "advertised in a codepoint". I guess you meant advertised with or in a TLV with a type/codepoint. I suggest to make the following change:

s/may be advertised in a single codepoint /may be advertised with a single codepoint

## Simplify

OLD:
   This guarantees that
   any new codepoints defined by future protocol extensions will
   explicitly indicate the applicability of Multi-Part TLV procedures to
   the new codepoints.

NEW:
   Future allocations will
   explicitly indicate the applicability of Multi-Part TLV procedures to
   the new codepoints.

# Section 7

## Please elaborate more the "extremely disruptive" mention in the following:

CURRENT: 
   Introduction of the use of MP-TLV for codepoints where the existing
   specifications have not explicitly defined MP-TLV support can be
   extremely disruptive to network operations in cases where not all

## I don’t parse the following: 

CURRENT:
   It is presumed that if such
   support is provided that it applies to all relevant codepoints.  

## Consider adding examples of deployment scenarios

OLD:
   a given implementation might limit MP-
   TLV support to particular codepoints based on the needs of the
   deployment scenarios in which it is used.

NEW:
   a given implementation might limit MP-
   TLV support to particular codepoints based on the needs of the
   deployment scenarios in which it is used (e.g., set by default
   or controlled by a configuration parameter).  

## I suggest to delete the following. This message is already stated in the document:

CURRENT:
   Note that with the introduction of explicit specification of MP-TLV
   applicability for codepoints (Section 9), implicit MP-TLV support
   will never occur in the future.

## What is the goal of this MUST if the implem is already conformant?! (*)

CURRENT:
   Where MP-TLV support is explicitly
   defined, conformant implementations MUST support MP-TLV.

# Section 8: Not sure the normative language makes sense in the following text:

CURRENT:
   Sending of MP-TLVs in the presence of nodes which do not correctly
   process such advertisements can result in interoperability issues,
   including incorrect forwarding of packets.  This section discusses
   best practices which SHOULD be used when a deployment requires the
   use of MP-TLVs for codepoints for which existing specifications do
   not explicitly indicate MP-TLV support.

# Section 8.1

## Configuration and defaults (*)

CURRENT: 
   It is RECOMMENDED that implementations which support the sending of
   MP-TLVs provide configuration controls to enable/disable generation
   of MP-TLVs.  

 (1) Should we also be able to expose the actual (configurable) capabilities?

 (2) Given the implications of partial support, can we suggest the default be to disable?

## Does the report in the following covers logging? Can we be explicit here? (*)

CURRENT:
   Implementations which support disablement of MP-TLVs MUST report
   alarms under the following conditions:

# Section 9.2: (nit) s/ This document requests that IANA extend/This document requests that IANA extends

# Section 10 (*)

CURRENT:
  This document creates no new security issues for IS-IS.  

Isn’t generalizing applicability of MP-TLV may be misused (e.g., abuse the number of occurrences to consume computing resources of a receiver)?

Cheers,
Med