Re: [Isis-wg] Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)

Alia Atlas <akatlas@gmail.com> Tue, 16 August 2016 16:18 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFE712D728; Tue, 16 Aug 2016 09:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.699
X-Spam-Level:
X-Spam-Status: No, score=-102.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham 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 EmO9Bm9OpWpd; Tue, 16 Aug 2016 09:18:37 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 805DB12D121; Tue, 16 Aug 2016 09:18:37 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id 52so37451652qtq.3; Tue, 16 Aug 2016 09:18:37 -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=X8R87oYH9gP2TKQ5OUZa1nwm5DI22fcAxQsZxjJKd/U=; b=pMgANBZhoBf2GqE8hvaUMCtkQm9AGEd1m94xt95WVG77QJNsZqRFx0GW6H1zP6jG5Z bMAYeiMv2OHI8fPYiYIcwXt9PBtx7XuowXjKQ5pHowPWHMGhb0eqDp/1QuajgjE+B/VB 4t9SqYt2HwDjBBW5o8KGIToeTeyrF+ec9XPaw6SRIHpn9MaGVI4tKmf6pRAe/6lOAf+M wOL121qXLitLN9V5cFTXB+sz2/AqcLhhohIclrCdlJ1AGB8Rp63F2QSY8UtVOkqD22n2 MnuUBka7jvAvLcjmsmeHRFLkgvaAXqqFwqhml+jokk6I/xTsniC2+3yFO//ylOu8BJUc 4ERA==
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=X8R87oYH9gP2TKQ5OUZa1nwm5DI22fcAxQsZxjJKd/U=; b=kqWkK2SbbJMjqJwAP3lSnJre6l7rDxD1fBGF3+5nHSYj5d7Nq+POKqKVa1AfoyTX1W QdIUHucauKBcbsxYSDw7S57G22TYXIZeZIOxQDyD8JP9J/9oXhn2ji70qJCRt2dJk87m hR5NnWUBDgmje3qYT4gi9i4bvJ+p/mtoTShj/JDnVzvxpOzhGciw27jFG9ZpaJAYbJqJ CTSz5cewDPVAflySPoneuHxOF36/+8wwR/1iQLXLaSj/SwqtF1US+QzqxHiNd6mTOpll WQpfCR8dGoOrXN2x2YXuEFwVm0vV4iJXcMZYm1VwUVuSJ8k+OvdEByoNWdGAGrqqzcyd JArg==
X-Gm-Message-State: AEkooutbMiH+yqbjn//x+tdOMck0TK1oT4sV9BrqVRWqynjzoXv47Jqx5I+MWX/ChwqXlCOkys/QvIATo91ZlQ==
X-Received: by 10.237.44.66 with SMTP id f60mr39443378qtd.11.1471364316611; Tue, 16 Aug 2016 09:18:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.52.193 with HTTP; Tue, 16 Aug 2016 09:18:35 -0700 (PDT)
In-Reply-To: <1471364164.2609509.697007537.7E0612EB@webmail.messagingengine.com>
References: <147136220282.22903.10134856216046001373.idtracker@ietfa.amsl.com> <CAG4d1rfoW_7R0qkKvLt71-P1XegGPd1CLwLtXtmTCS4N50kaQQ@mail.gmail.com> <1471364164.2609509.697007537.7E0612EB@webmail.messagingengine.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 16 Aug 2016 12:18:35 -0400
Message-ID: <CAG4d1re4inwF6_yQT=qKCXz=PeUQzMYBfoyPvvN60h_QJZWPDQ@mail.gmail.com>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Content-Type: multipart/alternative; boundary=94eb2c06bee46dac00053a32b391
Archived-At: <https://mailarchive.ietf.org/arch/msg/isis-wg/IAiYgH7mIMOPXcr28OCLMFp54uQ>
Cc: isis-chairs@ietf.org, Christian Hopps <chopps@chopps.org>, draft-ietf-isis-rfc4971bis@ietf.org, The IESG <iesg@ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] Alexey Melnikov's Discuss on draft-ietf-isis-rfc4971bis-03: (with DISCUSS and COMMENT)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/isis-wg/>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Aug 2016 16:18:40 -0000

On Tue, Aug 16, 2016 at 12:16 PM, Alexey Melnikov <aamelnikov@fastmail.fm>
wrote:

> Hi Alia,
>
> On Tue, Aug 16, 2016, at 05:03 PM, Alia Atlas wrote:
>
> Hi Alexey,
>
> On Tue, Aug 16, 2016 at 11:43 AM, Alexey Melnikov <aamelnikov@fastmail.fm>
> wrote:
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I would like to get clarification on the following points before
> recommending approval of this document:
>
> 1) How do multiple CAPABILITY TLVs from the same source treated, if they
> have the same S and D flags, but different subTLV? Are the cumulative? Or
> this is not allowed?
> I am sorry if I missed where this was described, let me know if I did.
>
>
> The end of Section 3 says " Where a receiving system has two copies of a
> CAPABILITY TLV from the same system that have different settings for a
> given attribute, the procedure used to choose which copy shall be used is
> undefined."
>
>
> Ok, I wasn't sure that this was talking about the same thing.
>
> So just to double check: using multiple CAPABILITY TLVs with different S
> and D flags is Ok (and described), but use of multiple CAPABILITY TLVs with
> identical S and D flags is undefined as per the sentence you quoted above?
>

They have to have the same attribute - which could be a sub-TLV.

This bis is to update the handling for IPv6; there was no discussion about
> changing the basic details (such as this)
> in the updated version.
>
> 2) In Section 4, 1st sentence: how can this specification have
> requirements on implementation that don't support this extension? If this
> behaviour is already prescribed by another specification, then you should
> not use RFC 2118 keyword and you should reference the relevant
> specification.
>
>
> RFC1195 says
> "   Any codes in a received PDU that are not recognised shall be ignored
>    and, for those packets which are forwarded (specifically Link State
>    Packets), passed on unchanged."
>
> A reference would be fine - but this is basic well-known behavior for
> IS-IS.
> The authors may have more details.
>
>
> My problem was that the document seemed to impose new requirements. I
> think the sentence needs to be reworded to say "As per RFC 1195, ..." and
> don't use RFC 2119 language.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Should subTLVs have an IANA registry? Or is there an existing one
> already?
>
>
> It's already there - http://www.iana.org/assignments/isis-tlv-
> codepoints/isis-tlv-codepoints.xhtml#isis-tlv-codepoints-242
> but it does look like an updated reference to rfc4971bis would be a good
> idea.
>
> Indeed.
>
>