Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04

Job Snijders <job@ntt.net> Thu, 25 May 2017 13:54 UTC

Return-Path: <job@instituut.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4BAF124234 for <idr@ietfa.amsl.com>; Thu, 25 May 2017 06:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.419
X-Spam-Level:
X-Spam-Status: No, score=-1.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no
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 kbVLXuIN8XiE for <idr@ietfa.amsl.com>; Thu, 25 May 2017 06:54:31 -0700 (PDT)
Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) (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 C5FDE12942F for <idr@ietf.org>; Thu, 25 May 2017 06:54:30 -0700 (PDT)
Received: by mail-wm0-f66.google.com with SMTP id b84so37452845wmh.0 for <idr@ietf.org>; Thu, 25 May 2017 06:54:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=x4khhjHjvVdCb1sLzsTlLVp8izpLtj4KVlL/nQ33pJs=; b=MpQIvIQotZ0jUCSgc1t8LPBdFdL+unigh+4jpsjB4KQ0uqs44qhn1+p+sCOXMHxQQR UtkhcFXZesf3qiCjzPN4OEdlgh5gzUWBBSpMOi50sU9HTiaXckqEPFEJOE39VPrXpdbx 12RYchkElkVAuicl+DY9JFIbmT4A0lmQS/MgSo3VvxcBIKi58Sbe9IbaAUPi6zddUYJU ZeasyUrp2ZOOW9sU96dsFtWvoIZbMZ0bJ362pXGU+zFtxqN0TyukLYIjXDcXP7KYt9JC gM9CRXghwLpG6S9wrkdSxKCja0/qI7q9Z2EX3TOq4zcdhFeCkD363lfJQPdur2n7ffWg fpsQ==
X-Gm-Message-State: AODbwcDYoXD64SxTjXsJ2vB1ILwDmhkov/PX0iX7QcEGzKNygwEaMhT7 xsDEEmk2nZjhQVBO41l+/Q==
X-Received: by 10.28.66.2 with SMTP id p2mr10570943wma.20.1495720468939; Thu, 25 May 2017 06:54:28 -0700 (PDT)
Received: from localhost ([195.138.201.60]) by smtp.gmail.com with ESMTPSA id y6sm10153971wrc.51.2017.05.25.06.54.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 May 2017 06:54:27 -0700 (PDT)
Date: Thu, 25 May 2017 15:54:24 +0200
From: Job Snijders <job@ntt.net>
To: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
Message-ID: <20170525135424.3v3ea3rfdsquwizu@Vurt.local>
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net> <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: NeoMutt/20170306 (1.8.0)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/amPFMYEg-djY4i397t0KxoGiBMk>
Subject: Re: [Idr] Working group last call for draft-ietf-idr-tunnel-encaps-04
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 May 2017 13:54:33 -0000

Dear all,

TL;DR: I do not support advancing this document at this time. Lack of
full-spec implementation experience, and little feedback from actual
implementers, lead me to not support progression of this document. I
understand that this position has little to do with the actual contents
of the document.

On Sun, May 21, 2017 at 03:58:29PM -0400, Lou Berger wrote:
> On 05/20/2017 03:47 PM, John G. Scudder wrote:
> > A working group last call has been requested for
> > draft-ietf-idr-tunnel-encaps-04. Please reply to the list with your
> > comments. As usual note we cannot advance the draft without
> > participation from the group. Please get your comments in before
> > June 5, 2017.
> 
> - Since the question was raised on list: a partial implementation of
> this draft can be found in FRRouting, notably bgp_encap_tlv.{h,c} in
> https://github.com/FRRouting/frr/tree/master/bgpd . It supports:
> 
>  o encap attribute sent with other safis.  The code uses it with the
>    VPN safi to provide underlay tunnel information for VPN routes for
>    NVO3 type applications.
> 
>  o "Remote Endpoint Address sub-TLV" for v4 and v6
> 
>  o encode/decode of type specific and sub-TLV formats
>    per draft -00 or -01 rev (this means it is a subset implementation.

Cool stuff, thanks for sharing that!

While John Scudder pointed out that there is no blocking requirement for
a document to have implementations before passing through WG LC. I (and
probably participants too) am of the opinion that actual feedback from
implementers is extremely valuable.

Should an implementer find an actual technology issue, or lack of
clarity in the wording of the document, as long as the document in the
WG it'll be trivial to resolve any issues. I understand that there are
ways to modify a document after WG LC, but I think its simpler to be
able to say to the working group itself "this technology works, i have
an implementation".

Should someone write a partial implementation, that might be a hint that
the document needs to be split up (or perhaps it is of no significance).
To properly assess a document, I hope for feedback from full
implementations (perhaps two technology components within a doc conflict
with each other). If parts of an Internet-Draft are not implemented by
anyone, I'd advocate the document should not (yet) progress further.

With "implementation" i don't mean that you are shipping code to
customers, I'm fine with stuff hanging in private beta branches - all
I'm looking for is an attestation that the implementer found the
full specification implementable. RFC7942 is good guidance.

I'd like to request the chairs to consider a slight adjustment of the
procedure: encourage the working group to create implementations
_before_ WGLC, so the working group can take implementer feedback into
account when assessing the proposed document.

Kind regards,

Job

ps. if two full implementations show up during this WGLC, I will
ofcourse withdraw my non-support.