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

Alia Atlas <akatlas@gmail.com> Wed, 21 May 2014 00:40 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 04C1A1A03CE for <isis-wg@ietfa.amsl.com>; Tue, 20 May 2014 17:40:00 -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 XSxoNMPjVd7N for <isis-wg@ietfa.amsl.com>; Tue, 20 May 2014 17:39:58 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 485671A020E for <isis-wg@ietf.org>; Tue, 20 May 2014 17:39:58 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id b6so1090963yha.3 for <isis-wg@ietf.org>; Tue, 20 May 2014 17:39:56 -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=gFdWvmamm3w7ElsK81e2L0RgJV8j5es+M8iJYKzekts=; b=fZQrsVBkm54BSoXFrN3e9uwMQTxqq+33g1fRkvmTLFqqyahz6qecohOWcn1SH0+lr3 vZsSBT5EkLVj8ooW3655mdglTObAXhYvcKxbh0N2udYwfpH6nDBkL8Ra9jND3SbisLOY Q1JVRtSv7fwxKgx0Gff8Z2x/tbfmDnS8q66ImulvxVlnWbZsZzyOPVRusXXthOfLUn+f amYxipwiQcWQ0BO/DLF6pL/HPYMH9gzljbHN7k3XQX/Uht/mrpPvtgmW5zll9nJGsbSY DIAahnMLlbS80Bfxjk9ia3B8wnqal8omWx0vL92H/QT8DaQqIB1rm3U2WcK0BheMKaAA FW/A==
MIME-Version: 1.0
X-Received: by 10.236.199.78 with SMTP id w54mr20691207yhn.139.1400632796945; Tue, 20 May 2014 17:39:56 -0700 (PDT)
Received: by 10.170.194.2 with HTTP; Tue, 20 May 2014 17:39:56 -0700 (PDT)
In-Reply-To: <F3ADE4747C9E124B89F0ED2180CC814F23DBEC38@xmb-aln-x02.cisco.com>
References: <CAG4d1rcW+JwryVr3RxOkTeBpaCKGUijz_F+f9w0e+5pV6YEzOg@mail.gmail.com> <F3ADE4747C9E124B89F0ED2180CC814F23DBEBD7@xmb-aln-x02.cisco.com> <CAG4d1rfSy85+w99DTC4q6AiJVqguO9PvDUNhfUReYEY7imMt7w@mail.gmail.com> <F3ADE4747C9E124B89F0ED2180CC814F23DBEC38@xmb-aln-x02.cisco.com>
Date: Tue, 20 May 2014 20:39:56 -0400
Message-ID: <CAG4d1rdR8_uRCAe4mwC5n+FhxCgopxre_3Z6o-1pPECYpj8G8w@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/aw8JCzIaIqDjnsZ_zrse7F8tuVA
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: Wed, 21 May 2014 00:40:00 -0000

Les,

Any way that makes it clear is fine. In the registry is a good idea.

I will need an updated  draft right after IETF Last Call is done.
This is for clarity - unwritten  MUST NOTs are a problem in a RFC.

Thanks,
Alia

On Tue, May 20, 2014 at 8:05 PM, Les Ginsberg (ginsberg)
<ginsberg@cisco.com> wrote:
> Alia -
>
>> -----Original Message-----
>> From: Alia Atlas [mailto:akatlas@gmail.com]
>> Sent: Tuesday, May 20, 2014 4:30 PM
>> To: Les Ginsberg (ginsberg)
>> Cc: isis-chairs@tools.ietf.org; draft-ietf-isis-fs-lsp@tools.ietf.org; isis-
>> wg@ietf.org; Adrian Farrel
>> Subject: Re: review comments on draft-ietf-isis-fs-lsp-01
>>
>> 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.
>
> If this is the direction we want to head, then I would suggest removing the text specifying what scope may be advertised in a given IIH from Section 11 and instead add some columns to the "LSP Flooding Scoped Identifier Registry" defined in the IANA section to indicate for each scope identifier whether it can be included in the "Scoped Flooding Support" TLV in a given IIH PDU. I can't format it easily here, but it would add three new columns:
>
> Scoped Flooding Support Advertisement
> P2P-IIH   L1 LAN IIH    L2 LAN IIH
> -------------------------------------------
>  Y/N             Y/N                      Y/N
>
> This would allow the registry to update the definition of what could be advertised when new flooding scopes are invented.
>
> I am hoping this can all be handled during the editing process and that a new version of the draft is not necessary.
> Please let me know.
>
>    Les
>
>
>>
>> >>
>> >> 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