[OSPF] RtgDir QA review: draft-ietf-ospf-segment-routing-extensions-12

Stig Venaas <stig@venaas.com> Wed, 26 April 2017 22:08 UTC

Return-Path: <stig@venaas.com>
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 1FA73129501 for <ospf@ietfa.amsl.com>; Wed, 26 Apr 2017 15:08:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=venaas-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ryG4IfLs9PJU for <ospf@ietfa.amsl.com>; Wed, 26 Apr 2017 15:08:13 -0700 (PDT)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 3C7EF126CE8 for <ospf@ietf.org>; Wed, 26 Apr 2017 15:08:11 -0700 (PDT)
Received: by mail-qk0-x236.google.com with SMTP id y63so13427651qkd.1 for <ospf@ietf.org>; Wed, 26 Apr 2017 15:08:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=venaas-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=JG9Fl/6WXafCGNgUoyN1e2d3B62Mpu9sOVaw34VmCEA=; b=dDjnWY0r7g9cyDxOMZlh6zhSog6PxDEHlOwKQrxJPY/k9imdQAiEpWWJjVvAJuywCZ K/vfZSMaMoVE4JezI+8/U+CUNIa1lwvMH8YBDkGr6dKhMYQaGkulJ8UVIr0LSEPhHhIE MSGyNULV4xP8CsKIEBaObT/FkhR5c2uQ79Kajsc9Ozj+yw3r7v4EJxTxmdWA0rXhRk1k 8wAq/bMtBsyuvVUa8bTcpYKi8u6h3bjadcKFhZxD376JFmKKJHc1mcrmgWzRDkJYbS22 Qdmqn6Su/XXhPnxKOkHTO9cAjueJVO2wMss83697OllTzxr/qJ/iQ7z6bOqYv4yp9/LM VUAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JG9Fl/6WXafCGNgUoyN1e2d3B62Mpu9sOVaw34VmCEA=; b=Njodndtiu2ZtLGMI9VHzNIZTYC4UGwuyE4k4gFUW8lNDqJtCid2HTdvdAxAV9Jw8C4 v/UMIRBYioF0qhds3twg0OaEyFQVpY69PTIBGHFTzaTRTXDxH94+qIr3Zfxm2z3QP8C7 8mPTSPbgp6LLJftxq3NIZ+wpBz0ENwJ1pwuSCIgv4u/r+v8BzZ7inAUmxIN6yU4qoxFg zDlyi2JQrrxcuint4d2pPSgvqmxije0dhjpN/D4kK0OCqT58pYokXEDmLiN17etUc+gH 7PgahoigtL7XYAdNGYrP1lDnbbSzjcxUUzN+0b16+gMFgLOWCDTLclIBVsX3/jYwczMP xFsA==
X-Gm-Message-State: AN3rC/5cjxfsvpkTRwcAI7rfrggMSqfBirMgBZMBTzW+eTiaFU/BJ/Wt rMdf60W2HHBSlIP7Q9UtPSexmTUSbg==
X-Received: by with SMTP id v77mr2228307qkl.189.1493244490315; Wed, 26 Apr 2017 15:08:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 26 Apr 2017 15:08:09 -0700 (PDT)
From: Stig Venaas <stig@venaas.com>
Date: Wed, 26 Apr 2017 15:08:10 -0700
Message-ID: <CAHANBt+ZdrU_=CquJSzisV1ore_=_QmPcxDfM=MBGYDj0GKZbg@mail.gmail.com>
To: rtg-dir@ietf.org, ospf@ietf.org, ospf-chairs@ietf.org, draft-ietf-ospf-segment-routing-extensions.all@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/Wb3keWVbYGS_A4r0ZeJdOmSuItQ>
Subject: [OSPF] RtgDir QA review: draft-ietf-ospf-segment-routing-extensions-12
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.22
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, 26 Apr 2017 22:08:14 -0000


I have been selected as the Routing Directorate reviewer for this
draft. This is just an early QA review.

The draft is in good shape, but I did find some minor issues and nits.
It is fairly readable, but it could be improved in a few places.

Minor issues:

In 3.1:
The SR-Algorithm TLV is some places called a Sub-TLV. It might be
good to be consistent.

This is not clear in 3.1:
   The SR-Algorithm Sub-TLV is optional. It MAY only be advertised once
   in the Router Information Opaque LSA.
Is this trying to say that it MUST NOT be advertised more than
once? With the current wording this is not obviously that strict.

I see some text regarding multiple SR-Algorithm sub-TLVs, but it also
looks like one can have multiple algorithms in one sub-TLV. At least
from the diagram. But I don't see any discussion about this. Is it OK
to add multiple? When can it be done, what does it mean? What if
routers don't support the exact same set of algorithms?

The term "lowest flooding scope" is used a couple of places. I think I
know what it means, but it might be good to point it out. Also, I'm
used to seeing the term "smallest" rather than "lowest". I'm assuming
they mean the same.

In 3.2 there is this bullet point:
   The receiving router must adhere to the order in which the ranges
   are advertised when calculating a SID/label from a SID index.

You probably should use MUST here.

Section 4:
In section 4 there is a range for advertising a range of prefixes.
But it looks like it contains a single prefix length and it says
the length is the length of the prefix. While it says range size
is the number of prefixes. I don't understand from the text what
really prefix length and range size means and how this should be

I understand this is IPv4 only since OSPFv2, but rather than just
saying IPv4 is 0, maybe refer to an IANA AF registry? This might
be helpful if you want to use the same sub-TLV in OSPFv3 and
use the same code for parsing etc. IANA has 1 for IPv4 though.

Section 5:
Is it intentional that the flags start in position 1 rather than

I see that the NP flag should be ignored when M is set. Then I
see this text:
   As the Mapping Server does not specify the originator of a prefix
   advertisement, it is not possible to determine PHP behavior solely
   based on the Mapping Server advertisement.  However, PHP behavior may
   safely be done in following cases:
This seems not very precise. Could you say exactly what the behavior
should be, rather than saying "behavior may be done"?

Section 6:
It might be good to make clear that other flag positions are
reserved, set to 0 and ignored... Perhaps also point out that
weight is in the range 0-255.

I see this sentence:
      If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV
      more than once, instances other than the first will be ignored and

Should it say MUST be ignored?

Section 6.2 it says:
   All ERO Sub-TLVs must immediately follow the SID/Label Sub-TLV.
   All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV.

Should these be normative MUSTs?

In 6.2.1:
It would be good for all of these to specify that other flags are

The intro should perhaps mention LAN adjacency and binding SIDs?

2nd paragraph of section 2 is confusing. It sounds like
the Opaque LSAs in 7684 were defined for SID in particular,
but it is a generic mechanism. Perhaps SID was the
motivation though?

Section 6.1:
It says:
   The ERO Metric Sub-TLV advertises the cost of an ERO path.  It is
   used to compare the cost of a given source/destination path.  A
   router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO

Is the ERO TLV the ERO Sub-TLVs defined in 6.2? It would be good to
point that out.

In 8.4.2:
   Broadcast, NBMA or or hybrid
Extra "or".

Section 9:
There are no new registries and most of the TLVs are already
allocated? It seems there are a few new ones where it should
probably say TBD, or say something about being suggested values.
That was done in earlier sections. I see in some places it says
"are allocated" here, while it says "suggested" in the definition
of the TLV.

Section 10:
It says there are responses from 2 implementers, but I see 3.

Section 11:
Are these really all the potential security issues?

I'm on vacation the next 2 weeks, so I may not reply to any
emails during that period.