Looks good now. Thanks for addressing my concerns. Dan
On Sat, Mar 11, 2017 at 3:10 PM, Donald Eastlake <[email protected]> wrote: > 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 > [email protected] > > > On Wed, Jan 18, 2017 at 2:16 PM, Donald Eastlake <[email protected]> wrote: > > Hi Dan, > > > > On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu <[email protected]> > 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 > > [email protected] > > > >> Thanks and Regards, > >> Dan > >> > >> > >> On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake <[email protected]> > 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 <[email protected]> > >>> 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 > >>> [email protected] > >> > >> >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
