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

Hi Dan,

Could you look at the recently posted version -05 to see if this
resolves your comments?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3(_at_)gmail(_dot_)com


On Wed, Jan 18, 2017 at 2:16 PM, Donald Eastlake <d3e3e3(_at_)gmail(_dot_)com> 
wrote:
> Hi Dan,
>
> On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu 
> <dromasca(_at_)gmail(_dot_)com> wrote:
> > 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.
> Sure, I agree that it would benefit for the addition of some text here
> and there./
>
> > Specifically:
> >
> > > 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.
> >
> > 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?
> 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.
>
> > > 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.
> >
> > 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).
> OK.
>
> > > 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.
> >
> > 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.
> 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
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3(_at_)gmail(_dot_)com
>
> > Thanks and Regards,
> > Dan
> >
> >
> > On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake 
> > <d3e3e3(_at_)gmail(_dot_)com> wrote:
> > > 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 do not believe it is as bad as you say.
> > >
> > > On Thu, Jan 12, 2017 at 11:04 AM, Dan Romascanu 
> > > <dromasca(_at_)gmail(_dot_)com>
> > > 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   +1-508-333-2270 (cell)
> > >  155 Beaver Street, Milford, MA 01757 USA
> > >  d3e3e3(_at_)gmail(_dot_)com