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

"Acee Lindem (acee)" <> Sun, 18 June 2017 18:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8C6A8129494; Sun, 18 Jun 2017 11:37:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9J86ulU1rvPf; Sun, 18 Jun 2017 11:37:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C95F2128954; Sun, 18 Jun 2017 11:37:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14597; q=dns/txt; s=iport; t=1497811065; x=1499020665; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=IzqJgqxdk8EGwddwgF4Ee+2Yi9cxrCE1ymOuIq/T0/w=; b=FMT7Cz6JCIXb0q97VGm2nCLbmi5oHraquz319PpxRDLx5jHsD/xHy0R4 nfUx9pBVe84ar/sf/49QRtmSHjanEfvvknWFian1HCjJ+cIniT6bEZ+Rv Ov1oCvqn9AuHcBzxfGBQlaV/QNj0T0WWrBDr7CR0iDAKVaIvqpM541cOU Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.39,357,1493683200"; d="scan'208,217";a="440431172"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Jun 2017 18:37:44 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v5IIbiVw012481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 18 Jun 2017 18:37:44 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sun, 18 Jun 2017 14:37:43 -0400
Received: from ([]) by ([]) with mapi id 15.00.1210.000; Sun, 18 Jun 2017 14:37:43 -0400
From: "Acee Lindem (acee)" <>
To: Alia Atlas <>, OSPF List <>, "" <>
Thread-Topic: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03
Thread-Index: AQHS6GH4wTdS+O6UOkGzV2DRDznJvQ==
Date: Sun, 18 Jun 2017 18:37:43 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D56C3765B54E7aceeciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 18 Jun 2017 18:37:48 -0000

Please submit a revision addressing Alia’s comments.

From: OSPF <<>> on behalf of Alia Atlas <<>>
Date: Wednesday, June 14, 2017 at 6:56 PM
To: OSPF WG List <<>>, "<>" <<>>
Subject: [OSPF] AD review of draft-ietf-ospf-encapsulation-cap-03

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