Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

Alia Atlas <akatlas@gmail.com> Wed, 27 April 2016 16:19 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BE512D51F; Wed, 27 Apr 2016 09:19:25 -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 WWKtZveMIKG6; Wed, 27 Apr 2016 09:19:23 -0700 (PDT)
Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 820CB12D190; Wed, 27 Apr 2016 09:19:21 -0700 (PDT)
Received: by mail-oi0-x229.google.com with SMTP id v145so21317271oie.0; Wed, 27 Apr 2016 09:19:21 -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; bh=7ajTFKxyQTyyg3qZheSROaqTFS7NQs9Ty5iRItjZRko=; b=xibVQZ2xOzIW+G59JZOBSmQR2FZUcGZKHzFQ2EUXP7oVv15G8GFuzrArefyFsasKYY mxorBulydEbyEFPPKFnE3GlIymLe2qEEwlmTmyh7UvgxLXHF8ns+CMszZl0HcZyJ5Rey H+0JB3Ufgr+1JBjpgc8azedgnRyBMCJyE4Zn7xnCS6Q016A7cjqZnWdyUVVDnOtldbD6 /4yrP8kkAHzFoZHJV5SPmnCIsyX8WwUNKFlmBsGbLTa+JL9SwqZNUgpg3eh0HoZCLSwS g3XdDotvVHz8J/vMb4/+bMcOMTMUJtRxIhroWCqhjPUrIkt2RAHy+1hwtIanjrov61af KNqQ==
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:date :message-id:subject:from:to:cc; bh=7ajTFKxyQTyyg3qZheSROaqTFS7NQs9Ty5iRItjZRko=; b=JpCTOX1ywb/D6wxrPZrmBxE1xnuTeja9ZxGRM9jnUKZ/OXzH63ZoqFRFSlNQJZlLby eBPSgeHhiWir2jp+643Dpta+y/H8Zxcpr60KcfXgRyZqoJVKkcHjE2xgEAa0z4ZBAA9r bOQZ7NQnF2tzLYCbGIOYrZ7syCn6rt3ZGPGmDTpzAMisEjyr7nrZjF4mbLAK9lNc3DED aypoT66tMs3NVvpYP6kdvk6KMTysKHfW1m1QK+DTrCyvCmJuZ8bFlZEuXZgJstzG+uUX Xqxd64cc9Ok4e7Y4nGryzUWViC7UvHB7JxfJW73eM4+FgXy/RZ2LqGCAA4faK2p0IslM /gMw==
X-Gm-Message-State: AOPr4FXLJkixQzXLasZqIBnnP/g9kCAr2C+AHFLnywvBk4FNsyq3lV54D1oddVwjcwAJiNp8aD5N1VP/+OWNvw==
MIME-Version: 1.0
X-Received: by 10.157.45.81 with SMTP id v75mr4269589ota.85.1461773960618; Wed, 27 Apr 2016 09:19:20 -0700 (PDT)
Received: by 10.60.115.168 with HTTP; Wed, 27 Apr 2016 09:19:20 -0700 (PDT)
In-Reply-To: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk>
References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk>
Date: Wed, 27 Apr 2016 12:19:20 -0400
Message-ID: <CAG4d1rffwvnOrFjw_vC9a2qUvquYEzzaD-V=r7iEeUDyDpRUtA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Adrian Farrel <adrian@olddog.co.uk>
Content-Type: multipart/alternative; boundary=001a113e9f66aa5139053179c542
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/pQgMnVE_-Bz71IMc8jUkJMdwDoI>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-ietf-ospf-sbfd-discriminator.all@ietf.org, OSPF List <ospf@ietf.org>
Subject: Re: [OSPF] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2016 16:19:25 -0000

Adrian,

Thank you very much for the thorough review!

Authors & Shepherd,

Please go through and update this draft ASAP.  It is on the IESG telechat
on May 5
and is/will be reviewed very soon.

Thanks,
Alia

On Wed, Apr 27, 2016 at 9:11 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The
> Routing Directorate seeks to review all routing or routing-related drafts
> as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs.
> For more information about the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them before or along with any IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-ospf-sbfd-discriminator-04.txt
>  Reviewer: Adrian Farrel
>  Review Date: 27 April 2016
>  IETF LC End Date: 26 April 2016
>  Intended Status: Standards Track
>
> Summary:
> I have some minor concerns about this document that I think should be
> resolved before publication.
>
> Comments:
>
> This is a simple document that doesn't require much to implement or
> understand.  It was disappointing, however, to find a large number of
> small issues and nits.  I don't believe any of these are blocking to
> the utility of the document and if it went for publication in its
> current state it would not be harmful.  But in the interest of making
> our documents useful and accessible, and for the purpose of eliminating
> all possible interoperability and deployment, I think it would be
> valuable to clean up the issues I have listed.
>
> Major Issues:
> No major issues found.
>
> Minor Issues:
>
> I should like to see some small amount of text on the scaling impact on
> OSPF. 1. How much additional information will implementations have to
> store per node/link in the network? 2. What is the expected churn in
> LSAs introduced by this mechanism (especially when the Reflector is
> turned on and off)?
>
> In the second case there is a security implication as well. Can I DoS
> the routing system by toggling some BFD Reflectors? Needs text!
>
> You *do* have...
>    A change in information in the S-BFD Discriminator TLV MUST NOT
>    trigger any SPF computation at a receiving router.
> ...which is a help.
>
> ---
>
> Section 1 has
>
>    This is achieved by using unique
>    network-wide discriminators to identify the Network Targets (e.g., IP
>    addresses).
>
> You may be aware of IPv6 :-)
>
> Although 2.1 gives some hints on the size of a discriminator, I had to
> go back to 5880 to check that *all* discriminators are exactly 4 octets.
> So saying "e.g., IP addresses" is at best confusing.
>
> BTW, draft-ietf-bfd-seamless-base and draft-ietf-bfd-seamless-ip don't
> give any hints on this.
>
> Oh, and what is "network-wide"?
>
> I suggest...
>
>    This is achieved by using four-octet discriminators as defined in
>    [RFC5880] to identify the Network Targets.
>
> ---
>
> In Section 2 you have
>    Upon receipt of the TLV, a
>    router may decide to ignore this TLV or install the S-BFD
>    discriminator in BFD Target Identifier Table.
>
> I think "ignore" is ambiguous. You need to be very clear that "ignore"
> means:
> - take no local action
> - retain the TLV in the opaque LSA
> - continue to advertise the opaque LSA according to its scope
>
> In Section 3 you also have
>    A router not supporting the S-BFD Discriminator TLV will just
>    silently ignore the TLV as specified in [RFC7770].
>
> Am I missing something when I read 7770? I don't find anything about
> handling unknown TLVs.
>
> ---
>
> Section 2 para 3
> s/superset/union/
> ("superset" would allow you to include any other discriminators!)
>
> ---
>
> Section 2.1
> To be totally unambiguous...
> OLD
>    Length - Total length of the discriminator (Value field) in octets,
>    not including the optional padding.  The Length is a multiple of 4
>    octets, and consequently specifies how many Discriminators are
>    included in the TLV.
> NEW
>    Length - Total length of all discriminator in the Value field in
>    octets, not including the optional padding.  The Length is a multiple
>    of 4 octets, and consequently specifies how many Discriminators are
>    included in the TLV.
> END
>
> However (!) are you sure that you can include optional padding? I think
> that 7770 uses padding to take the V field up to a 4 octet boundary.
> Since all of your discriminators are exactly a multiple of 4 octets it
> seems that there will never be any padding and it would be less
> confusing to write...
>
> NEW
>    Length - Total length of all discriminators in the TLV counted in
>    octets.  The Length is a multiple of 4 octets, and consequently
>    specifies how many Discriminators are included in the TLV.
> END
>
> ---
>
> At the end of section 2.1 you have
>
>    S-BFD discriminator is associated with the
>    BFD Target Identifier type, that allows demultiplexing to a specific
>    task or service.
>
> This is a wonderfully throw-away statement with no context and no
> further explanation in the document that I could find. Maybe this is
> just missing a reference to another document, or maybe it needs some
> clarification.
>
> ---
>
> Section 2.2 has
>
>    The flooding scope for S-BFD Discriminator information advertised
>    through OSPF can be limited to one or more OSPF areas, or can be
>    extended across the entire OSPF routing domain.
>
>    Note that the S-BFD session may be required to pan multiple areas, in
>    which case the flooding scope may comprise these areas.  This could
>    be the case for an ABR, for instance, advertising the S-BFD
>    Discriminator information within the backbone area and/or a subset of
>    its attached IGP area(s).
>
> As I understand flooding scope the options for Opaque LSAs (see 5250)
> are:
>
>    o  Link-state type-9 denotes a link-local scope.
>
>    o  Link-state type-10 denotes an area-local scope.
>
>    o  Link-state type-11 denotes that the LSA is flooded throughout the
>       Autonomous System (AS).
>
> Your text seems to imply something different. In particular, you seem to
> be suggesting that I can have a scope that is greater than one area but
> less than the whole AS (assuming "whole AS" == "entire OSPF routing
> domain").
>
> This needs re-writing to clarify what you want to achieve and to bring
> it in line with 5250.
>
> Note that the 4th para of Section 2.2 seems to have this right.
>
> ===
>
> Nits
>
> Has Trilok's affiliation changed?
> --
> Capitalise the document title
> ---
> Expand acronyms in the Abstract if they do not appear with an asterisk
> in http://www.rfc-editor.org/materials/abbrev.expansion.txt
> ---
> Throughout the text, expand acronyms on first use if they do not appear
> within http://www.rfc-editor.org/materials/abbrev.expansion.txt with an
> asterisk.
> ---
> Decide whether "discriminator" or "Discriminator"
> ---
> In 2.1 you have
>    Value - S-BFD network target discriminator value or values.
> But there is no "Value" in the figure.
> ---
> 2.2 para 2
> s/pan/span/
> ---
> 2.2
>    In the case of domain-
>    wide flooding, i.e., where the originator is sitting in a remote
>    area, the mechanism described in section 5 of [RFC5250] should be
>    used.
> s/should/SHOULD/?
> But if you mean should or SHOULD (not MUST), what are the exception
> cases?
> ---
>
> Thanks,
> Adrian
>
>