Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-channel-tunnel-10: (with DISCUSS and COMMENT)

Donald Eastlake <d3e3e3@gmail.com> Sat, 06 August 2016 03:47 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 C2A0D12D636; Fri, 5 Aug 2016 20:47:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.151
X-Spam-Level:
X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 qsyyxX_aagIH; Fri, 5 Aug 2016 20:47:01 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 2649812B039; Fri, 5 Aug 2016 20:47:01 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id k91so11738730uak.3; Fri, 05 Aug 2016 20:47:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QdXfucONZxC9HZnY6vh4WNYwOUONIPdCCG30y0QMwJQ=; b=F34VjxugocHRMtdE6b6+7OLAMt9evheDyYLbGwiX3kX5SAsGGq3OEOocjbcRS9pBhi YMTjAspdeLCZZFjmclVAWp/wmSCre/mujIyyJNXj/sYajvdHFfEFBl1fplV6+3XpGSnI GWu0iYr9F00X5mxhfBXMgV/E1IG09eljy7wYK68nbBRJdeBkQvYcxOTjKDDZe3dTxkT6 OuFLU3o0i5UDknndk3Yqa82osa6nbpzosMR/q/W+oWwnaMugJBXR0jNvuXCLoiynPSmL SLkdxvUZC0a4MiK1X7QumBeuAr7D2yQz8Bjc+cO/Glm6khOaWYjBGtouEuncVczDS5ma 59Jw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QdXfucONZxC9HZnY6vh4WNYwOUONIPdCCG30y0QMwJQ=; b=gvhyazSx/kaTrutf12fM2TRLqHm6EqRSxhPiqWo9JY/CbPObDYFLMx7HTldLsMsGpD k635TiTT6KsEUmUJXasztITg49VfgCUNYXz/YtiQYkwYDVoULjwzpcOqJF412dvVHpSz U09iVzLw22gtg3t+UMaGvJT7Y8rkbVB13bHuIZ4ycCrSlIqMj8j2u4zJ54sZrOU62xxU +luL7SnMx6ppPsc4o6X9VMNuOcx1uSW0q7mAz9WrYB0FI2FSY8yJpAyeMkBKOL+0i49V pDTAF1PHDOMhpo5WtKWCg3nu/eMjB/zKMibNW0iBnVHlsl8RPITgo48Ix29xJWflh/q3 D16g==
X-Gm-Message-State: AEkoouusG2VZ9A7d3iebrZR27CN/ija6e6N6QxRlLcofE3psOzRZfsBhEhkvEBmKChl53M5JFr2K5RWpFBj35g==
X-Received: by 10.176.81.112 with SMTP id f45mr5953181uaa.53.1470455220179; Fri, 05 Aug 2016 20:47:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.104.2 with HTTP; Fri, 5 Aug 2016 20:46:44 -0700 (PDT)
In-Reply-To: <D3A3B89B.132D72%aretana@cisco.com>
References: <20160707015330.26824.25840.idtracker@ietfa.amsl.com> <CAF4+nEEhg9cDv_O5XbD7XOr01_BX7SbUr1+V-RZz-9Gm0Hiz1w@mail.gmail.com> <D3A3B89B.132D72%aretana@cisco.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 5 Aug 2016 23:46:44 -0400
Message-ID: <CAF4+nEFgNYQ5RR3cMnr1+9wZYowyY8Mo4qFhm_G=R8f6okizkw@mail.gmail.com>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>
Content-Type: multipart/alternative; boundary=94eb2c19258c0e980605395f09e6
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/qYjx-Gd-fuRdYCkuG204HIia62U>
Cc: "draft-ietf-trill-channel-tunnel@ietf.org" <draft-ietf-trill-channel-tunnel@ietf.org>, "trill-chairs@ietf.org" <trill-chairs@ietf.org>, The IESG <iesg@ietf.org>, "shares@ndzh.com" <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Alvaro Retana's Discuss on draft-ietf-trill-channel-tunnel-10: (with DISCUSS and COMMENT)
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, 06 Aug 2016 03:47:03 -0000

Hi Alvaro,

Version -11 of this draft has been posted which is intended to resolve your
DISCUSS.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

On Thu, Jul 7, 2016 at 6:51 AM, Alvaro Retana (aretana) <aretana@cisco.com>;
wrote:

> On 7/7/16, 1:16 AM, "Donald Eastlake" <d3e3e3@gmail.com>; wrote:
>
> Donald:
>
> Hi!
>
> >>----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> Even though the IANA Considerations section was just updated (in version
> >> -10), I am putting in this DISCUSS because it is still
> >> incomplete/incorrect.
> >>
> >> 1. Guidance for managing the SubERR namespace should be included.  Note
> >> that this document only specifies values for ERR 6, but guidance should
> >> be given to IANA for the other ERR values as well.
> >
> >No IANA registry is created for any SubERR values so I'm not sure why
> >there needs to be IANA guidance. The draft can be made clearer that
> >for all values of ERR other than 6, SubErr should be sent as zero and
> >ignored on receipt. If you want, a registry could be added. I would
> >think IETF Review was the appropriate registration procedure.
>
> Yes, I think a registry should be added.
>
> >
> >> 2. Section 6.2.1 (RBridge Channel Error Codes Subregistry) requests the
> >> creation of a new registry ("RBridge Channel Error Codes²), but that
> >> registry was already created by RFC7178.  This document should then
> >>split
> >> the requests in two parts: assignment of the vales 6-8, and the change
> >>to
> >> the registration procedure.
> >
> >You are correct. Sorry for the oversight.
> >
> >However, I actually think the registration procedure should stay as
> >Standards Action for new ERR codes as provided in the current IANA
> >registry.New major error codes can cause substantial problems with
> >older implementations that do not know what they mean. (I do not think
> >this is a problem with SubErr since implementations can take a default
> >action based on the major ERR code.)
>
> That works for me; I just mentioned the registration procedure because it
> had been changed.
>
>
> >
> >> ----------------------------------------------------------------------
> >> COMMENT:
> >> ----------------------------------------------------------------------
> >>
> >> >From Section 2. (RBridge Channel Header Extension Format), is the RESV4
> >> field a space that is reserved for potential future use?  Why isn¹t it
> >> ignored on receipt (similar to the RESV field in Section 4.3)?  If there
> >> is potential for use of this space (RESV is defined as 4 bits, which
> >> makes me think about potential bit-level allocations), then there should
> >> be some guidance in the IANA Considerations.
> >
> >Earlier versions of this document added three features to RBridge
> >Channel. As well as the payload feature and security feature in the
> >current document, which are invoked by non-zero values of the PType
> >and SType nibbles,
> >     if you look at the -01 or -00 version you will see a "Scope"
> >feature invoked by non-zero values of the Scope nibble. RBridge
> >Channel supports messages between RBridges in the same TRILL campus
> >and between an end station and an RBridge on the same link. The Scope
> >feature extended this to support, for example, messages between an end
> >station and an RBridge not on the same link. However, the scope
> >feature added significant complexity and there was no immediate
> >requirement for it so it was dropped and the Scope nibble was
> >relabeled RESV4.
> >    Those bits are deliberately made "critical" so the Scope feature
> >could be revived in the future and Scope-ignorant RBridges would know
> >to reject Extended RBridge Channel messages that are using the Scope
> >feature which changes the format a little. Any attempt to re-instate
> >the Scope feature or to make other use of these four bits will require
> >a Standards Track document in any case. I don't understand why there
> >needs to be any guidance in the IANA Considerations about this. What
> >would it say other than that any non-zero value is treated as an
> >error? which is a technical specification already present in the body
> >of the document and not an IANA Consideration.
>
> I agree with you on the IANA part (no need to add anything related to
> RESV/RESV4).
>
> I still think (non blocking comment) that treating a received non-zero
> value as an error adds unnecessary complexity if it can just be ignored.
> If the Scope feature is ever revived (or any other feature that wants to
> use the field) then it can change the behavior then.
>
> Thanks!
>
> Alvaro.
>
>