ietf
[Top] [All Lists]

RE: Opsdir telechat review of draft-ietf-isis-l2bundles-04

2017-04-20 20:45:07
Mahesh -

Thanx for the review.
Responses inline. Let me know if these adequately address your comments.


-----Original Message-----
From: Mahesh Jethanandani [mailto:mjethanandani(_at_)gmail(_dot_)com]
Sent: Thursday, April 20, 2017 5:44 PM
To: ops-dir(_at_)ietf(_dot_)org
Cc: draft-ietf-isis-l2bundles(_dot_)all(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org; isis-wg(_at_)ietf(_dot_)org
Subject: Opsdir telechat review of draft-ietf-isis-l2bundles-04

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.


[Les:] There is no default/minimum set of attributes. What attributes will be 
advertised are determined by the use case. What this draft is defining is the 
transport i.e., what attribute advertisements the protocol is capable of 
advertising. As with traditional TE what attributes are actually advertised is 
determined by the application.

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.


[Les:] The definition of "correct operation" depends upon the use case. IS-IS 
is simply transporting the attributes advertisements. It is unaware of how 
these advertisements are being used and how traffic may be affected by the use 
of these advertisements. So it is the application(s) which use this information 
which need to define what behavior is expected.

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.


[Les:] Certainly if the bundle membership changes these change MUST be 
reflected in the advertisements i.e., removal/addition of a bundle member MUST 
result in removal/addition of advertisements associated with that bundle member.
If a bundle member is down this should be reflected in the same way that L3 
advertisements are withdrawn when a given L3 link goes down.

Means of configuration of link attributes is out of scope for this draft. I 
would expect such configuration to be applied in the context of the bundle 
member interfaces.

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.


[Les:] This also falls in the scope of the application. IS-IS does not know how 
or if link attributes are used.

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.


[Les:] Agreed. Security section should reference the standard security 
specifications for the protocol (RFC 5304/RFC 5310).

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'

[Les:] These warnings are seen when referencing non-RFC documents. The 
referenced documents are standards and are correctly identified as normative 
references.

    Les
 

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



<Prev in Thread] Current Thread [Next in Thread>