Hi Dan, On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu <dromasca@xxxxxxxxx> 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@xxxxxxxxx > Thanks and Regards, > Dan > > > On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake <d3e3e3@xxxxxxxxx> 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@xxxxxxxxx> >> 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@xxxxxxxxx > >