Reviewer: Mahesh Jethanandani
Review result: Has Issues
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
(--).