Re: [Isis-wg] review comments on draft-ietf-isis-fs-lsp-01

Alia Atlas <akatlas@gmail.com> Tue, 20 May 2014 23:29 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: isis-wg@ietfa.amsl.com
Delivered-To: isis-wg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17FD1A03B6 for <isis-wg@ietfa.amsl.com>; Tue, 20 May 2014 16:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 57pE94GeIo6l for <isis-wg@ietfa.amsl.com>; Tue, 20 May 2014 16:29:40 -0700 (PDT)
Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E1D1A03AE for <isis-wg@ietf.org>; Tue, 20 May 2014 16:29:40 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id z6so1030070yhz.20 for <isis-wg@ietf.org>; Tue, 20 May 2014 16:29:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eNTMCZdi4970udIdl6Mfa4Zlimb27GHUP9AxAIXk7mE=; b=F6vu8K3lOoNPyneidxc46w3bbbUeCm7ur3WmhjzMWVOt9odKExvuUONw9BZi4oOYqh NNUkIofHDKT83UWm/lLDSkn/kh/XYfMOBGtnMacfDYop4Fc266KvNRIuCoi2b7WZKB9U wYOJiFyuEthsQBFraep6h3MRUP3tNFnDBpym4OlCN1lcqd+WjIJzV8lTUh2xNJkeIemg xGfotddKhbYcvBRXG5RoIKAzf+YFQZhsTr3snDx5YWq0wgmFCYEmqbi20/o92Fv7n/d1 C9UZxyUw36WKD8WoHPBftFByCa/XVYLdMoh0EJWa2RtrGJ6/ByLWD1cFPOPaUckDCdJX 88wQ==
MIME-Version: 1.0
X-Received: by 10.236.105.141 with SMTP id k13mr20010802yhg.141.1400628579751; Tue, 20 May 2014 16:29:39 -0700 (PDT)
Received: by 10.170.194.2 with HTTP; Tue, 20 May 2014 16:29:39 -0700 (PDT)
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F23DBEBD7@xmb-aln-x02.cisco.com>
References: <CAG4d1rcW+JwryVr3RxOkTeBpaCKGUijz_F+f9w0e+5pV6YEzOg@mail.gmail.com> <F3ADE4747C9E124B89F0ED2180CC814F23DBEBD7@xmb-aln-x02.cisco.com>
Date: Tue, 20 May 2014 19:29:39 -0400
Message-ID: <CAG4d1rfSy85+w99DTC4q6AiJVqguO9PvDUNhfUReYEY7imMt7w@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/isis-wg/vE5-mXfCCg_mJUygRxOBetdcpIM
Cc: Adrian Farrel <adrian@olddog.co.uk>, "isis-chairs@tools.ietf.org" <isis-chairs@tools.ietf.org>, "draft-ietf-isis-fs-lsp@tools.ietf.org" <draft-ietf-isis-fs-lsp@tools.ietf.org>, "isis-wg@ietf.org" <isis-wg@ietf.org>
Subject: Re: [Isis-wg] review comments on draft-ietf-isis-fs-lsp-01
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 20 May 2014 23:29:42 -0000

Hi Les,

On Tue, May 20, 2014 at 7:11 PM, Les Ginsberg (ginsberg)
<ginsberg@cisco.com> wrote:
> (Resending - including WG and Adrian)
>
> Alia -
>
> Thanx for your comments.
> Inline.
>
>> -----Original Message-----
>> From: Alia Atlas [mailto:akatlas@gmail.com]
>> Sent: Tuesday, May 20, 2014 2:37 PM
>> To: isis-chairs@tools.ietf.org; draft-ietf-isis-fs-lsp@tools.ietf.org
>> Subject: review comments on draft-ietf-isis-fs-lsp-01
>>
>> As a standard part of my process for evaluating drafts before starting
>> IETF Last Call,
>> I do a review of the draft.  This is that review.
>>
>> In general, this is a really clear and well written draft.  Thank you
>> for articulating the reasons and requirements so clearly and for
>> taking advantage of this opportunity to make the
>> backwards-incompatible changes.
>>
>> This draft is in excellent shape and I will start the IETF Last Call
>> for it - but I do have a couple specific comments below.  These can be
>> handled during IETF Last Call and addressing any concerns raised
>> there.
>>
>> Specific comments:
>>
>> In Sec 11, could the following text be clarified?
>> " A list of the circuit scopes supported on this circuit and
>>   other non-circuit flooding scopes supported.
>>
>>        R bit MUST be 0 and is ignored on receipt.
>>
>>        In a Point-Point IIH L1, L2 and domain-wide scopes MAY
>>        be advertised.
>>        In Level 1 LAN IIHs L1 and domain-wide scopes MAY be advertised.
>>        In Level 2 LAN IIHs L2 and domain-wide scopes MAY be advertised.
>> "
>> For instance, does this mean that circuit scopes MAY be advertised?
>
> An IIH is a circuit scoped PDU. It therefore is expected that if the new Scoped Flooding Support TLV is sent in an IIH that it would include the circuit scopes supported on that circuit. The language regarding L1, L2, domain-wide scopes explicitly specifies what scopes - in addition to circuit scopes - MAY be included in the three IIH PDU types. The expectation regarding circuit scope  is explicitly stated by the earlier sentence:
>
> " A list of the circuit scopes supported on this circuit and  other non-circuit flooding scopes supported."
>
> I think your point may be that it would be clearer to also include "circuit scopes" in the statement regarding each PDU type - something like:
>
> <Begin revised text>
> In a Point-Point IIH L1, L2, domain-wide, and circuit scopes MAY  be advertised.
> In Level 1 LAN IIHs L1, domain-wide, and  circuit scopes MAY be advertised.
> In Level 2 LAN IIHs L2, domain-wide, and circuit scopes MAY be advertised.
> <End revised text>
>
> If you think the revised text is clearer I have no objection.

I think it is clearer.

>> In a Level 1 LAN IIHs, L1 scopes MUST NOT be advertised?
>
> Did you mean L2 scopes MUST NOT be advertised in an L1 LAN IIH? If so, yes that is the intent of listing the scopes which MAY be advertised in a given PDU. What is not specifically permitted is prohibited.

Could you please state that?  A big friendly MUST NOT clarifies things.

>>
>> In the IANA section, do the registries for the sub-TLVs also need to
>> be extended?
>
> The draft introduces 16 bit TLVs and 16 bit sub-TLVs - so if/when new sub-TLV registries associated w extended TLV codepoints (i.e. codepoint > 255) are required they will have to support 16 bit sub-TLV codepoints.   However, the existing sub-TLV registries (e.g. Sub-TLVs for TLV 22, 141, and 222) do NOT need to be extended. This is because those registries are associated with Standard TLVs and therefore the sub-TLV codepoints are restricted to be within the Standard sub-TLV range.
>
> As we are not introducing any new sub-TLV registries in this document I think the existing language in the IANA section is appropriate. We could add a statement like:
>
> "Future sub-TLV registries associated with Extended TLVs will support values in the range of 0 - 65535."
>
> I am not sure that is necessary.

Probably not needed, thanks.  I just wanted to be sure it hadn't been
overlooked.

Alia
>    Les
>
>>
>> Thanks,
>> Alia