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

Dan Romascanu <dromasca@gmail.com> Tue, 17 January 2017 08:45 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 16E52129446; Tue, 17 Jan 2017 00:45:43 -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 iGOkMUJY12xt; Tue, 17 Jan 2017 00:45:41 -0800 (PST)
Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 0636F129407; Tue, 17 Jan 2017 00:45:41 -0800 (PST)
Received: by mail-qt0-x233.google.com with SMTP id l7so145144277qtd.1; Tue, 17 Jan 2017 00:45:40 -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=lYBMwHm/pQnY5vTnX0NQhpL4R30Ejx8nCLFWsJy3SZ4=; b=hMiZjj531STDj+ygIzY9g9W6VakP9Y5VcyCdGqyd18Du+hQbFwHBK/Q4FF+OgrFM5n 1Ik8JPUcHiShDj0FLUI4qFWhe0hW4O1OkgjMv4GRMN/SQCSYsEUL6V/b/iSrljyna8f5 lXOsV1H8SkCbj2/W7jRf3wpddmo6a/wUmxUGqMSGidkxfiFzEtQFKv76t59LOfk0WfTj eaXufjPGoWan3aDVO/4gDJPs3rtuJgw6BdIqyCVSWD6ju726U/VWBRcTxYYrFDcAq7yj cTc66NzZx/RfRaMAr2yUYBdVZaTcpfbto1PXB1s00vFqAeXFy4X0tm4R/Lf4YAttHzCu zJmw==
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=lYBMwHm/pQnY5vTnX0NQhpL4R30Ejx8nCLFWsJy3SZ4=; b=TqjNuDRqgKw695Stf3yIEG9FOZ6uKU5aqXzta1Bz1a/cHXqyxfsZwxVhNtUjBhrPP0 uNkUFVn7W4uCK3N3trQDM6N9Okx+jpc7b+GbK9Dfrf3NcB7shS2EAgTZKNPekRmmcanz hl+sXqJua0mj+FcMcG/yoijXHLYQ3jihHvtH5S9VxmqAqHJiXZ7jmFLIp4I1ZC4Kwu7I ZZ8jYrYpHaqQExEzwBUEY2bmYV36ed0ZJaBkthqq1sdosRdKdyiJ6OFcanyoJXs2DPAg Sfdb1/yTjIWU56sVymmRr34LY6NIozhO1N6/v9qIu6cU91GbBdG1TLk9ExBQ4cHDuyLx za6w==
X-Gm-Message-State: AIkVDXKyCG/rPez/+sxOd6OqHJWmCAj7+UtQeNqK2p/GhZ5ExT55GTOW960JurwI4k43ybfgwQaNXr4qiCCbXg==
X-Received: by 10.237.61.20 with SMTP id g20mr36144899qtf.272.1484642740025; Tue, 17 Jan 2017 00:45:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.40.11 with HTTP; Tue, 17 Jan 2017 00:45:39 -0800 (PST)
In-Reply-To: <CAF4+nEEVpXbWiToCq8oK1QFnpL+m8Q7=yuKdOHv4Og98NB6jhg@mail.gmail.com>
References: <148423706509.29345.14522113109638417885.idtracker@ietfa.amsl.com> <CAF4+nEEVpXbWiToCq8oK1QFnpL+m8Q7=yuKdOHv4Og98NB6jhg@mail.gmail.com>
From: Dan Romascanu <dromasca@gmail.com>
Date: Tue, 17 Jan 2017 10:45:39 +0200
Message-ID: <CAFgnS4V+yHnpHo0-5tKLo8yDTc7_hgDa5-DFdHwLe4mPtHzDWw@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Content-Type: multipart/alternative; boundary=001a11432912234afc0546465301
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/ylucfxLtX3ra5P_WLj0NRQaErdA>
Cc: "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: Tue, 17 Jan 2017 08:45:43 -0000

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.

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?

> 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).

> 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.

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 believe 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
>