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

Dan Romascanu <dromasca@gmail.com> Sat, 11 March 2017 07:46 UTC

Return-Path: <dromasca@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 22FE91293FD; Fri, 10 Mar 2017 23:46:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 5b_1SChq73Cn; Fri, 10 Mar 2017 23:46:15 -0800 (PST)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 6D9751279EB; Fri, 10 Mar 2017 23:46:15 -0800 (PST)
Received: by mail-qt0-x236.google.com with SMTP id i34so4514097qtc.0; Fri, 10 Mar 2017 23:46:15 -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=ICJ+EcScPd72SuZ8IkMuzT22IW52Gv3IHbqRl7Xr6Rs=; b=Tqs8qUKigkeQkmJuFGvNX1kcsbh2cQKmEzOQcspuqGrlaDAN9LMUY94vygdUJ2j5Is /fRpd6tzOEXeL29ZI1xEQ/mU0+D7VIJS8KRzPDdud8pMouAIkoEAgvvjQ6l6zpU6VoMP d++ILsuvPy0p3JDWdbaSsjtalmufKtyPrpDaXeG4f6guQNjdQ1zB53wM6kS1B8q64G0P CTpVlsSCpkE0EIqiRE7RDlRc+8Owrd8Wr9FCWuSiqOAuag3vFdhvYnMI4VQ7TT7aAY3+ DURZj+jiPNoxIerILsR8Lo/rCZArxPqYTo4b0nM6hfeQySkB+of6LDukuOSZBV3Rm7aU XFwg==
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=ICJ+EcScPd72SuZ8IkMuzT22IW52Gv3IHbqRl7Xr6Rs=; b=hmSVo5sJfPS6oQjv0wUX+I46MFj3X1Lk1Uvxv3hoDLOtgT8OykygZpsezW5rIXPxPF nr611gPscPJh6djEF0qnh4Jo2Jzw52lTDKKke93f+Q12OoyRnJzVI3CROJf69XBIhbOx gP5lZIzNWbnvaz31XnbsZlYMagYRdkzDCn4dT8KQVnGfBPeLAiqdbIVueu+AaWE8nJkP WKr4oBgRWC5yXwS1Nv6VRgTNqZKKjuhQqbzuUs+yKh2heqgX0WIt8HYN63xRLUKn5aH1 MrprhUQUXJd3M/dLlzI/DliFTgFjdDCepV68uH93doMUlMSkj4tIKJB3dBA5UGlC/WA+ 4fng==
X-Gm-Message-State: AMke39n70ra3dQJ0ajVgQirsMgtVODdVammrnWyv9NnO7K5GsuZCRtlVNqu59xnGLoCnddKXdkWYeIZfcOveHQ==
X-Received: by 10.200.40.210 with SMTP id j18mr25282067qtj.272.1489218374429; Fri, 10 Mar 2017 23:46:14 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.41.170 with HTTP; Fri, 10 Mar 2017 23:46:13 -0800 (PST)
In-Reply-To: <CAF4+nEExM7ob+n+6OZsUEW8azwbFK7U6RF5NW68NHCi6rAhdNA@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> <CAF4+nEExM7ob+n+6OZsUEW8azwbFK7U6RF5NW68NHCi6rAhdNA@mail.gmail.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Sat, 11 Mar 2017 18:16:13 +1030
Message-ID: <CAFgnS4UHAwp+SF4Sn0CAzmifSpToV7oXHcjTiz0BJVK2xfEq_w@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Content-Type: multipart/alternative; boundary=001a11405b4e337449054a6fac2d
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/MN4J6R3gW_zRf-9_322aaRJB2SU>
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 07:46:18 -0000

Looks good now. Thanks for addressing my concerns.

Dan



On Sat, Mar 11, 2017 at 3:10 PM, Donald Eastlake <d3e3e3@gmail.com>; 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@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
> >>
> >>
>