Re: [trill] Review of draft-ietf-trill-rfc6439bis-04

[Donald Eastlake <[e-mail]>]

Hi Dan,

Thanks for your review. As per my further response below, while the
draft could perhaps use some clarifying additions related to
operations, I believe is as bad as you say.

On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu <[e-mail]>
wrote:
>
> Reviewer: Dan Romascanu
> 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.
>
> This document clarifies and updates the TRILL Appointed
>  Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and
>  obsoletes RFC 6439.
>
> It's a complex document which requires extra reading to understand
> the context and the interraction with other RFCs. I believe that
> from an OPS-DIR perspective there are issues that need to be
> discussed before the document can be approved.
>
> The main issues with the document in its current form are:
>
> 1. The document makes consistent changes in the way TRILL
> operates. It replaces TLVs and procedures, define new ones,
> obsoletes previous mechanisms that define VLAN mapping, and

I am not aware of any case where this draft replaces a TLV in the
sense of requiring use of a new TLV.  It does provide some new TLVs
and procedures that are believed to be superior to or useful additions
to previous ones. But I am not aware of any case where it "obsoletes"
previous provisions in the sense of prohibiting their use.

> incorporates updated material from other RFCs. There is however no
> indication in the text about the transition between existing
> deployed versions of TRILL based on RFC 6439 and related protocols
> with the current updated mechanisms. Are these backward compatible?

I don't know that much is really required to be said about
"transition" when you specify an optional optimization. Since it is
optional, by implication the implementer is free to use it or not and
things will work either way. This could be stated explicitly in those
cases.

Much of the material in this draft comes from RFC 6439 or the parts of
RFC 7177 that updated RFC 6439. Most of the new material is optional
improved behaviors.

The only mandatory new behavior is the mandatory support of the link
local E-L1CS flooding scope [RFC7357] specified in Section 8. There is
material in this draft covering backwards compatibility for this new
mandatory behavior.  Section 8 already explains how to determine
whether or not all TRILL switches on a link support E-L1CS flooding
scope. The only use of E-L1CS flooding scope in this draft is as part
of a mechanism for the DRB (Designated RBridge (TRILL switch)) to
advertise Forwarder Appointments and, as stated in Section 2.1 (see
paragraph at the bottom of page 8 in draft -04), if any RBridge on the
link does not support E-L1CS, then the DRB MUST fall back to
advertising those appointments in Hellos. Section 8, which mandates
support of E-L1CS, also requires that any use of E-L1CS specified in
the future must provide for backward compatibility.

> Do they need a simultaneous upgrade of the whole network?

No.

> 2. The document lacks a section or even minimal text concerning
> operational and manageability considerations.  There are several

Such a section can be added but there is not much to say. For example,
as explained below, there is very little specified in this document to
configure.

> mentions in the text concerning network managers or operator
> actions, but there is no indication or reference to what management
> protocols and data models are to be used for configuration,

RFC 6325, the base TRILL protocol RFC, says TRILL switches (RBridges)
SHOULD support SNMPv3 and there are TRILL MIB specifications in RFCs
6850 and 7784. However, there are also YANG modules underway in
draft-ietf-trill-yang, draft-ietf-trill-yang-oam, and
draft-ietf-trill-yang-pm.

It does not seem best for this rfc6439bis draft to change the
implementation requirement level for SNMP or NETCONF for TRILL. If that
were to be done, it seems like something more appropriate for the base
TRILL YANG draft (draft-ietf-trill-yang-*) to do.

> retrieval of operational status information, or alerts. I believe
> that these need to be added explicitly or by reference.

Reviewing the significant protocol additions in this draft at a high
level:

- There is significant material about the various ways the Designated
  RBridge on a link can announce who it is selecting as the Appointed
  Forwarder on the link for various VLANs. The election of the
  Designated RBridge depends on a configurable priority but that
  election is unchanged from RFC 7177 and in fact is identical to the
  election of the designated router on any IS-IS link. The decision on
  which RBridges to appointer as forwarder for which VLAN is out of
  scope. I don't see that there is anything to configure here, other
  than RBridge priority to be DRB, which is already specified in other
  RFCs.

- There are some optional optimizations to the inhibition mechanism.
  The inhibition mechanism is necessary for loop safety but any
  RBridge can use or not use any of these optimizations, as they
  choose, and things will work fine.

- Port Shutdown message: There are two new configuration parameters
  here, namely how many copies of the Port Shutdown message to send
  and at what interval. These are listed, along with units and default
  value in Section 6.6.

- FGL-VLAN mapping consistency check: As specified in RFC 7172, in a
  TRILL campus supporting Fine Grained Labels (FGL), the VLAN of a
  native frame can be mapped to an FGL on ingress and an FGL is mapped
  to a VLAN on egress. This draft makes no changes to that mechanism.
  It merely provides that an RBridge performing such mapping can
  optionally advertise the mapping it is performing at a port to other
  RBridges with ports on the same link which can then check it for
  consistency with any mapping they are performing. It is recommended
  that the network operator be alerted to such inconsistency and there
  is a configurable parameter for how long the inconsistency needs to
  exist before such alert. Is it your position that some specific
  protocol mechanism must be specified by which the network operator
  is alerted?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]