[OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

Alia Atlas <akatlas@gmail.com> Wed, 14 June 2017 22:56 UTC

Return-Path: <akatlas@gmail.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 4E4E21294E7; Wed, 14 Jun 2017 15:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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_NONE=-0.0001, SPF_PASS=-0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id AfiwDlLlBqJe; Wed, 14 Jun 2017 15:56:31 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (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 28E7B12025C; Wed, 14 Jun 2017 15:56:31 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id 77so20392338wrb.1; Wed, 14 Jun 2017 15:56:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Qf8pnJ3na9LPOuQ0BpjhkrmeC2jGJMWtzd0GDe1cDF0=; b=aM55qu+bpjdN7UHhjh5UvJZmVskQyDanfcXEF1zyFre6NTtD2CaEwH4jRN+xugYjFC IBmX6uEXUui+21VXW5gf83gU5d903kKFzY9rT8fhKuMIUiqSdS/LEkOTHFb9S1LAkox7 ACvHbHxK14VIZA0rF1KsiygvgFSDouvfvnu0fkTg/RDcLVgubkhNLskiqYFXwulDduXK 32Xo9jPiJ8DxHba3vqYmOP041V5E6fcJ8QU0tgQr1zAGsHCk+M2hiilGTcA/b2sZwmI+ agS8u1BNbu+4Ayj4T4SPTfVhPOHLD0szXqTd6j4R7k6Iih/3Az5aEjESQRCQ5FdFoCMQ maew==
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=Qf8pnJ3na9LPOuQ0BpjhkrmeC2jGJMWtzd0GDe1cDF0=; b=d0ULnL1CakUq0lC5ZPVDBb1kozPyee3sohERJ1543a4B12t+k+54r6eEQkSPLTtKhs wJ6mT9dEfRtcXFQoX8grJuy/tuLjJt1MDQLWNqIsk0bQcxGwL2tF2T2o4tmpwkLmYydo SQctekOMkDHmuA6Vztka0talmRZy5wGS70bdreg8zRKZi8nsySRCQzleaORmlaHO0R6L Z6EK08tcgrXABFz2mP7qd7oK3QxTqRuaHgf3Nk5nZzWkB+D0TE1zB5vkes4e7EdRgIOc RSNpEMg5nfdhOTN0TYcjR5fxuuDM08E1uXLQloiZHl+aigRsLWlBUw4kRYmypa5yKupl 2VkQ==
X-Gm-Message-State: AKS2vOxEsPthXfWbPeiKrOFynHv4Xfj7BikCva6BcE1FCe5N6zf3Vd2q II2d0hOn7oegxQoNTXgvMw4r4++mJL/i9YM=
X-Received: by with SMTP id c11mr1476764wme.109.1497480989335; Wed, 14 Jun 2017 15:56:29 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 14 Jun 2017 15:56:28 -0700 (PDT)
From: Alia Atlas <akatlas@gmail.com>
Date: Wed, 14 Jun 2017 18:56:28 -0400
Message-ID: <CAG4d1rfJPTyz-nENp2ViJYg14BCctGAAzt+TD3E9zEdejpqJaA@mail.gmail.com>
To: OSPF List <ospf@ietf.org>, draft-ietf-ospf-encapsulation-cap@ietf.org
Content-Type: multipart/alternative; boundary="001a114b41306d691f0551f3766a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ospf/wvNe1GvTH9kAx5CJR-WLzBxcZe0>
Subject: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03
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, 14 Jun 2017 22:56:33 -0000

As is customary, I have done my AD review
of draft-ietf-ospf-encapsulation-cap-03.
First, I would like to thank the authors - Xiaohu, Bruno, Robert, Luis, and
Luay - for their work on this useful document.

I do have a few concerns that need addressing before the draft can progress.


1) First, the draft talks about what information is sent - but nothing
about how it is to be understood or used.  That'd be ok if there were a
clear reference to a document that discussed the related procedures.  A
quick scan of draft-ietf-idr-tunnel-encaps-06 seems that it may be the
right place to start - but it's procedures are BGP-focused and while there
are many similarities, there may be interesting differences as well.
For instance, for the Color sub-TLV, is the 4 byte color value expected to
represent the same meaning in OSPF as in BGP?  Can a BGP route with a
particular color extended community then have the OSPF tunnel to use
selected from only those tunnels with the same color?  What does the Color
TLV mean in a purely OSPF context?  Sec 7 of
draft-ietf-idr-tunnel-encaps-06 ("However, suppose that one of the TLVs in
U2's Tunnel Encapsulation attribute contains the Color Sub-TLV.  In that
case, packet P SHOULD
   NOT be sent through the tunnel identified in that TLV, unless U1 is
   carrying the Color Extended Community that is identified in U2's
   Color Sub-TLV.") doesn't seem to strictly apply.

Semantics and behavior need to be specified - not just the encodings, and
that is all this draft currently has.

2) Sec 5.1 and Sec 5.2 refer to the format of the Encapsulation Sub-TLV and
Protocol Sub-TLV coming from draft-ietf-idr-tunnel-encaps-06 - but that
draft defines not merely the format, but allocates an IANA registry for
additional sub-types that can appear and defines the format and contents of
the sub-TLV based upon the tunnel type.   I'm nearly certain that you mean
that these sub-tlvs use not merely the same format (*does variable length
fields based upon the allocated type cause issues for OSPF sub-TLV
parsing???*) but can contain any values and sub-TLVs defined in the
relevant IANA registry. As it is written now, there is no reference to the
registry or ability to easily support more tunnel types in the future.

3) It is unfortunate that Geneve, which is the agreed encapsulation for
NVO3, is not included in the set of tunnels but VXLAN-GPE, which is not
going to be a standard, is.
I know this is duplicating what is in draft-ietf-idr-tunnel-encaps-06 but
it emphasizes the need to assume additional Tunnel Types and related
Encapsulation Sub-TLVs will be defined.

4) Sec 4: Is there a reason to create a new IGP Tunnel Encapsulation Types
registry instead of reusing BGP Tunnel Encapsulation Attribute Tunnel Types
The latter is FCFS and the proposed registry is Standards Action.   There
are already differences and collisions between the two (i.e. value 15).
What would happen if an Encapsulation Sub-TLV needed to include a Tunnel
Type? Which registry would it pull from? Would the value used depend on the
protocol it was signaled in?

5) I-D.ietf-idr-tunnel-encaps has to be a normative reference.

6) Given that some of the references are to in progress documents for the
tunnel types, is it expected that the values will correspond to future
versions or are they nailed to this particular version or something else?


a) Sec 1:"Partial deployment of IPv6 in IPv4 networks or IPv6 in IPv4
      networks as described in [RFC5565]"
s/IPv6 in IPv4/IPv4 in IPv6 for one of the two