Looks good now. Thanks for addressing my concerns.
DanOn Sat, Mar 11, 2017 at 3:10 PM, Donald Eastlake <d3e3e3@xxxxxxxxx> 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
d3e3e3@xxxxxxxxx
On Wed, Jan 18, 2017 at 2:16 PM, Donald Eastlake <d3e3e3@xxxxxxxxx> wrote:
> 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
>>
>>