Telechat Review of draft-ietf-isis-l2bundles-04
review-ietf-isis-l2bundles-04-opsdir-telechat-jethanandani-2017-04-20-00

I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.
 These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed in last
call may be included in AD reviews during the IESG review.  Document editors
and WG chairs should treat these comments just like any other last
call comments.

Document reviewed:  draft-ietf-isis-l2bundles-04

Summary:

There are deployments where the Layer 3 interface on which IS-IS operates is a
Layer 2 interface bundle.  Existing IS-IS advertisements only support
advertising link attributes of the Layer 3 interface. If entities external to
IS-IS wish to control traffic flows on the individual physical links which
comprise the Layer 2 interface bundle link attribute information about the
bundle members is required.

Document Status:

Has Issues

Comments:

The following comments look at the document both from an operational
perspective as well as a management perspective.

Operational Considerations:

Operational considerations include installation and initial setup, migration
path, requirements on other protocols, impact on network operations and
verification of correct operation.

Advertisement of these link attributes needs to be configured, including which
attributes will be advertised. While there are some attributes, e.g. max link
bandwidth, which can be learnt and advertised, there are others that need
configuration. What is not clear from the draft is which of the attributes
should be configured as  a minimum, and if they can have default values that
they can carry.

Since these are TLVs, it is assumed that the controller that does not
understand the advertisement will ignore the TLV. From a network operations
perspective, there will be more of these advertisements that need to be sent,
and will have to tracked and maintained by the controller.

Whether these advertisements result in a correct operation is not obvious,
because there is no feedback mechanism on how these advertisements are being
used, other than watching the changes that happen from a TE perspective.

Management Considerations:

Management considerations include interoperability, fault management,
configuration management, accounting, performance and security.

The attributes being advertised are additional to existing link attributes. In
that sense, it is new and additional information, as does not impact existing
operations. Controllers that understand the new advertisements will use them,
and those that do not, will ignore them. Interoperability therefore, should not
be impacted.

However, there is no discussion of fault management. For example, if one of the
links in the bundle goes down, are the attribute values updated to reflect the
new state of the bundle. There is also no definition of how these attributes
are configured on the box. Ideally, we should see a YANG model defining the new
attributes that can be configured for advertisement.

As discussed above, there is no accounting for how these new advertisements are
being used, or whether they are being used by the controller at all. Updates to
TE as a result of these advertisements should be accounted to indicate the
effectiveness of the new advertisements.

Performance should not be an issue, as these are advertisements, even if they
take up a small amount of additional bandwidth for advertisement.

Finally, and importantly, the draft needs to address the question of security,
even if it means pointing to a boiler plate set of drafts that deal with
similar issues. It would be hard to believe that there are no security
considerations to be had.

A run of idnits revealed no errors, flaws, or warnings. There were 3 comments
though

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802.1AX'

  -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589'

     Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 3 comments (--).