Subject: Review of draft-ietf-trill-rfc6439bis-04

From: Dan Romascanu <[email-masked]>
Date: Thu, 12 Jan 2017 08:04:25 -0800

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 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? Do they need a simultaneous upgrade of the
whole network? 

2. The document lacks a section or even minimal text concerning
operational and manageability considerations.  There are several
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, retrieval of
operational status information, or alerts. I believe that these need
to be added explicitly or by reference.

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 16 Jan 2017 20:48:59 -0500

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 <[email-masked]>
wrote:
> 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
> these comments just like any other last call comments.
>
> 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.
>
> 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.

> 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   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Dan Romascanu <[email-masked]>
Date: Tue, 17 Jan 2017 10:45:39 +0200

Hi Donald,

Thank you for your answer and explanations. They make sense to me, but I
still beleive that the document may benefit if some edits are being done to
clarify what may be the obvious for the people who know all details and
history, but not for the other users of the document in the future -
implementers and operators.

The header of the document includes Obsoletes 6439. If part of the content
of 6439 remains valid this needs to be clarified, If some superior TLVs and
procedures are introduced there is a need to explain what will happen with
the previous ones. Should they be implemented? deployed? activated?

If I understand what you say, the new features are optional (although the
status of the document is Proposed Standard), they can or cannot be
implemented (one, the other, both?) and the network will  still work. Yes,
I suggest to explicitly state this).

If I was an implementer of TRILL, or an operator considering to deploy
TRILL, I would have a hard time trying to understand what to implement and
what to deploy as management interfaces. Maybe this is not the place but I
believe that there need to be some documentation on this respect.

Thanks and Regards,

Dan

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 18 Jan 2017 14:16:03 -0500

Hi Dan,

> implementers and operators.

Sure, I agree that it would benefit for the addition of some text here
and there./

> the previous ones. Should they be implemented? deployed? activated?

OK. Stating that essentially all of RFC 6439 is incorporated and
outlining what parts of the new draft are optional improvements over
which part of RFC 6439, etc. would probably be a good addition.

> implemented (one, the other, both?) and the network will  still work. Yes, I
> suggest to explicitly state this).

OK.

> believe that there need to be some documentation on this respect.

OK. I think it would be reasonable to say something about the current
implementation requirement level of SNMPv3 and to say that YANG
modules are under development, so implementers will know more about
what is going on.

Thanks,
Donald

>> operations, I do not believe it is as bad as you say.
>>