Return-Path: 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: References: <20160707015330.26824.25840.idtracker@ietfa.amsl.com> From: Donald Eastlake Date: Fri, 5 Aug 2016 23:46:44 -0400 Message-ID: To: "Alvaro Retana (aretana)" Content-Type: multipart/alternative; boundary=94eb2c19258c0e980605395f09e6 Archived-At: Cc: "draft-ietf-trill-channel-tunnel@ietf.org" , "trill-chairs@ietf.org" , The IESG , "shares@ndzh.com" , "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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2016 03:47:03 -0000 --94eb2c19258c0e980605395f09e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alvaro, Version -11 of this draft has been posted which is intended to resolve your DISCUSS. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 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) wrote: > On 7/7/16, 1:16 AM, "Donald Eastlake" wrote: > > Donald: > > Hi! > > >>---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Even though the IANA Considerations section was just updated (in versi= on > >> -10), I am putting in this DISCUSS because it is still > >> incomplete/incorrect. > >> > >> 1. Guidance for managing the SubERR namespace should be included. Not= e > >> that this document only specifies values for ERR 6, but guidance shoul= d > >> 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 th= e > >> creation of a new registry ("RBridge Channel Error Codes=C2=B2), but t= hat > >> 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 RES= V4 > >> field a space that is reserved for potential future use? Why isn=C2= =B9t it > >> ignored on receipt (similar to the RESV field in Section 4.3)? If the= re > >> is potential for use of this space (RESV is defined as 4 bits, which > >> makes me think about potential bit-level allocations), then there shou= ld > >> 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. > > --94eb2c19258c0e980605395f09e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

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

Thanks,
Donald
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=C2=A0Donal= d E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
=C2=A0155 Beaver Street,= Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com

On Thu, Jul 7, 2016 at 6:51 AM, Alvaro Retan= a (aretana) <aretana@cisco.com> wrote:
On 7/7/16, 1:16 AM, "Donald Eastlake" <d3e3e3@gmail.com> wrote:

Donald:

Hi!

>>----------------------------------------------------------------------
>> DISCUSS:
>> ------------------------------------------------------------<= wbr>----------
>>
>> Even though the IANA Considerations section was just updated (in v= ersion
>> -10), I am putting in this DISCUSS because it is still
>> incomplete/incorrect.
>>
>> 1. Guidance for managing the SubERR namespace should be included.= =C2=A0 Note
>> that this document only specifies values for ERR 6, but guidance s= hould
>> 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 w= hy
>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) request= s the
>> creation of a new registry ("RBridge Channel Error Codes=C2= =B2), but that
>> registry was already created by RFC7178.=C2=A0 This document shoul= d then
>>split
>> the requests in two parts: assignment of the vales 6-8, and the ch= ange
>>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 wi= th
>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<= br> >action based on the major ERR code.)

That works for me; I just mentioned the registration procedure becau= se it
had been changed.


>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>> ------------------------------------------------------------<= wbr>----------
>>
>> >From Section 2. (RBridge Channel Header Extension Format), is = the RESV4
>> field a space that is reserved for potential future use?=C2=A0 Why= isn=C2=B9t it
>> ignored on receipt (similar to the RESV field in Section 4.3)?=C2= =A0 If there
>> is potential for use of this space (RESV is defined as 4 bits, whi= ch
>> 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,
>=C2=A0 =C2=A0 =C2=A0if 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<= br> >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.
>=C2=A0 =C2=A0 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<= br> >a Standards Track document in any case. I don't understand why ther= e
>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 rela= ted 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.


--94eb2c19258c0e980605395f09e6--