Re: [trill] Review of draft-ietf-trill-rfc6439bis-04
Donald Eastlake <d3e3e3@gmail.com> Sat, 11 March 2017 04:40 UTC
Return-Path: <d3e3e3@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C11129470; Fri, 10 Mar 2017 20:40:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYneXSRGMVeP; Fri, 10 Mar 2017 20:40:34 -0800 (PST)
Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FDC120727; Fri, 10 Mar 2017 20:40:31 -0800 (PST)
Received: by mail-it0-x22b.google.com with SMTP id w124so1863290itb.0; Fri, 10 Mar 2017 20:40:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p0njDvUvVrGTvukYkjW8m8V1DR+dRJHFTaYneXpDl3Y=; b=VZ9Q7MJ+9geo5v1mnglIvAX+75Q1TVwbk8QXdNPfxGAVeBKxeXgXfl5TgH2PsFGYJ3 HWLJaA5o8Hv2hmL60tYaRYUXcwl5ZRuw1J7iwt2xzwoj9MsR6TTVKJYC1PG99dwDPG1R uZWcfo68A4PmA7dQfsXh+rh7aGF3itmDnT8U5YIuVtC1ERgX+OBtOjfMB5Iw/t41CeMI u0gQZttTLr+3/2V9JMq/mv+F0CDJbQ73tw77fZroQQazBKh3n8JoFor/DBOLR7DgIUfK wGfOSDqBtB8zs87P75zD6NpbTn/bd1mUPydxfUvC+WkPScSbQaJFfv549t1SWqKPQ9gg 4cwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p0njDvUvVrGTvukYkjW8m8V1DR+dRJHFTaYneXpDl3Y=; b=X3dolf4GSkabCcjgAV6w1iDCRHJsfUWEEVdxiLqg3t38I51GroxpH50ceN6tEiJBVF dkK7+vWGOE7UVd7o68juLqqJGhwDdkxytXqR6cbKZ0T4+hu9slalpS7QpMyzizFurgiE OSYxK0xyR+8Mitkw6eKGErYLgMk8i4dyH08FQiZtKXxBCK7tnoywl1MfTQYg8VT2Jljk XhLTtorrh2uH+ufg4Sxbl8SSZ1IU5UxlfFR3uRif/gPDIvDjcsDFDg+QFuMTw11Sm12v eC2PBUpyW19Kgh1jIk5q5GkFk4510FPEy92qPT7I9Y3RjoAyZGTv0hJKW1tkW5aCtAZ8 6z3g==
X-Gm-Message-State: AFeK/H1qkWFWbi8gfJyRylAOwU0zHy3cr7v/VRs8u5qX8esHIwga8FgIGbP6LRYUvYI+V9DlLbGDZod+52GNbg==
X-Received: by 10.36.88.202 with SMTP id f193mr2082495itb.14.1489207230669; Fri, 10 Mar 2017 20:40:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.215 with HTTP; Fri, 10 Mar 2017 20:40:15 -0800 (PST)
In-Reply-To: <CAF4+nEGGnJkHC93UokZDEDO2St5SNE0mLvi6-oF3SYj2Lei_BA@mail.gmail.com>
References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> <CAF4+nEEVpXbWiToCq8oK1QFnpL+m8Q7=yuKdOHv4Og98NB6jhg@mail.gmail.com> <CAFgnS4V+yHnpHo0-5tKLo8yDTc7_hgDa5-DFdHwLe4mPtHzDWw@mail.gmail.com> <CAF4+nEGGnJkHC93UokZDEDO2St5SNE0mLvi6-oF3SYj2Lei_BA@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 10 Mar 2017 23:40:15 -0500
Message-ID: <CAF4+nEExM7ob+n+6OZsUEW8azwbFK7U6RF5NW68NHCi6rAhdNA@mail.gmail.com>
To: Dan Romascanu <dromasca@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/qljhLJt1oOK5Y2qSAbq_rbz3dBE>
Cc: Benoit Claise <bclaise@cisco.com>, "ops-dir@ietf.org" <ops-dir@ietf.org>, draft-ietf-trill-rfc6439bis.all@ietf.org, IETF Discussion <ietf@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Review of draft-ietf-trill-rfc6439bis-04
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Mar 2017 04:40:35 -0000
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@gmail.com On Wed, Jan 18, 2017 at 2:16 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: > Hi Dan, > > On Tue, Jan 17, 2017 at 3:45 AM, Dan Romascanu <dromasca@gmail.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@gmail.com > >> Thanks and Regards, >> Dan >> >> >> On Tue, Jan 17, 2017 at 3:48 AM, Donald Eastlake <d3e3e3@gmail.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@gmail.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@gmail.com >> >>
- [trill] Review of draft-ietf-trill-rfc6439bis-04 Dan Romascanu
- Re: [trill] Review of draft-ietf-trill-rfc6439bis… Donald Eastlake
- Re: [trill] Review of draft-ietf-trill-rfc6439bis… Dan Romascanu
- Re: [trill] Review of draft-ietf-trill-rfc6439bis… Donald Eastlake
- Re: [trill] Review of draft-ietf-trill-rfc6439bis… Donald Eastlake
- Re: [trill] Review of draft-ietf-trill-rfc6439bis… Dan Romascanu