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

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 27 April 2016 13:11 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8C44112D173; Wed, 27 Apr 2016 06:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5JOT2DnDgEcK; Wed, 27 Apr 2016 06:11:18 -0700 (PDT)
Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC37512D17D; Wed, 27 Apr 2016 06:11:17 -0700 (PDT)
Received: from asmtp2.iomartmail.com (localhost.localdomain []) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3RDBEcs021234; Wed, 27 Apr 2016 14:11:14 +0100
Received: from 950129200 (jplon-nat11.juniper.net []) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3RDBDhV021201 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 Apr 2016 14:11:14 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <rtg-ads@ietf.org>
Date: Wed, 27 Apr 2016 14:11:13 +0100
Message-ID: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdGghcVG0QuPS2RxQ6ajDKPyM64Rjw==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--13.416-10.0-31-10
X-imss-scan-details: No--13.416-10.0-31-10
X-TMASE-MatchedRID: LvJXpWO3uAjzLVZFOZrw3hes/RxhysDbFJFr2qlKix9V84HrPxCfbDMB KS/l5ik348guxdxp7TO00HTgX5ZI96z75DRX+d9kKWuiyZLRI4Bu/Xr6CKXiN/xsP7g8BleLFhM gncTYqyTh7zLZMPEJbrLJMDbAGS4OwyCE4EX8iMOVSBCoZUyqbEH7wsB5444wkzE2kM4b6Hpuh7 UAK5WmX+0P6ZIQeqxyPqcZsIcaC2CdVRGgWj1IHAXysW33GYMpJdXjF5ArCFcLBZEuqIL9Sj4hX W7B+PPhNqz0Lvapr6rKxo315+1VtjB9eXnpC3lIRy+94mWbR+YpWss5kPUFdFpbYq2f4jz+eYaA 2aCxgSsJeHUNn+b9lrhXEYVAE0l4KeLGzKm/w9IuLk8NfSpYetxWLypmYlZz5GbPjpDb1sPE7Fz k7PfDjBdhhvQ7ld2C5tlnPJX7htQO9fZKTjt+z4b9ftid8kBcecvjbu/xDjpOIo0O+5ZV4UacLe +k1sVAc3ZlcRIO231d/5IDJqMHBaoDZpNjSrDVaUe/i9AephMBZBplMxI/zhKCZ+Q6yB8qzlCux iVWkhq+FlZl9V5OTDKHOKZCvLKntJieP4rjvdkHTkHUtPYzxdZKsq3DGpalDYbe/PyX8gSVzyuc mj4bkROmces8inKL0hToAWgDRbky9zgULewwZohaKK0I26FpmyqQJWNsuklI7YhsiSUzzOkI/31 bQ36ScITNzcasX/7s+Reb+uzo944a2rhHAtuZdiLDwvWethjuHZGuwo6K7TDJ9a3KikGo13D6mx i/OuYhJ/ufappeEpGTpe1iiCJqtD9qpBlNF8oLbigRnpKlKSPzRlrdFGDw6dIq3kU8x87MeHyRk 1HQkZgHH98I/M9nflMu2qjc54JFZ6er+YR20Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/AhYkGvuZHN0uN6moHQY9YQUA1z0>
Cc: draft-ietf-ospf-sbfd-discriminator.all@ietf.org, rtg-dir@ietf.org, ospf@ietf.org
Subject: [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
Reply-To: adrian@olddog.co.uk
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 13:11:20 -0000


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 

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

I have some minor concerns about this document that I think should be
resolved before publication. 


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

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"
- 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
("superset" would allow you to include any other discriminators!)


Section 2.1
To be totally unambiguous...
   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.
   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.

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...

   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.


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


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)

   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 

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.


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
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
   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
But if you mean should or SHOULD (not MUST), what are the exception