IETF Logo Mail Archive

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

Lou Berger <lberger@labn.net> Sun, 21 May 2017 19:58 UTC

Return-Path: <lberger@labn.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 D268112946F for <idr@ietfa.amsl.com>; Sun, 21 May 2017 12:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level:
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 JmzUXhn-2JKS for <idr@ietfa.amsl.com>; Sun, 21 May 2017 12:58:38 -0700 (PDT)
Received: from gproxy3.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 307B212702E for <idr@ietf.org>; Sun, 21 May 2017 12:58:38 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id D0C38401B4 for <idr@ietf.org>; Sun, 21 May 2017 13:58:34 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id P7yW1v00N2SSUrH017yZWV; Sun, 21 May 2017 13:58:34 -0600
X-Authority-Analysis: v=2.2 cv=VKStp5HX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=tJ8p9aeEuA8A:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=C2NkijaDB96XFB6hWy4A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=w2l21ksHr2TAUA4w2xbqDZu1HOb6cjJQ+QGt+UIIhy0=; b=LZMjyV4dwkfsuJ8YoaVpoguXMD +weaAfdXOMCzogd0UNjJwGZzdoptwXH5PC9Zn0IOa938PQW9OQktlMQAi5engjjRy79scUuFrfHH3 STSXWwE1p++6+n3HZnjOaDAGX;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:53262 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dCWzm-0004oV-Ok; Sun, 21 May 2017 13:58:30 -0600
To: "John G. Scudder" <jgs@juniper.net>
Cc: idr@ietf.org, draft-ietf-idr-tunnel-encaps@ietf.org
References: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net>
From: Lou Berger <lberger@labn.net>
Message-ID: <213015a0-eb5f-3f17-f5f0-3aa864304a6d@labn.net>
Date: Sun, 21 May 2017 15:58:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <2AEDAB02-02F4-46C2-92CA-8880BBAFAAAB@juniper.net>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dCWzm-0004oV-Ok
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.84.20]:53262
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/POJurrfC0jowoagwbExkPcKA5e8>
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: Sun, 21 May 2017 19:58:40 -0000

On 05/20/2017 03:47 PM, John G. Scudder wrote:
> Hi All,
> 
> 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.
> 
> Authors, please confirm that any relevant IPR has been disclosed.
> 
> https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-04
> 
> Thanks,
> 
> --John
> 

Overall I support this document being published, but after addressing
some comments, most importantly the first one:

1. I think this document needs to cover its impact on RF5566.  My
personal preference is for this document to subsume/obsolete 5566, but
the types defined in 5566 shouldn't be lost. (BTW I previously provided
authors with text to allow this draft to obsolete 5566 as well, and can
do so to the list if it would be helpful.)

2. WRT the Encapsulation Extended Community.  I find the following rule
very hard to parse:

      A Tunnel Encapsulation attribute MUST NOT include a barebones
      Tunnel TLV.  Instead of placing such a TLV in the Tunnel
      Encapsulation attribute attached to a particular route, the
      corresponding Encapsulation Extended Community MUST be attached to
      the route.

Are you saying the extended community MUST be "barebones".  If so, I
agree as this matches 5512 formatting.  If you want this extended
community to carry sub-tlv information, then I see no backwards
compatibility basis for this and don't support this.  Either way, I
think this rule needs to be clarified.

3. I'm not sure why the color sub-tlv is still needed. why not just use
the Color Extended Community alone?  (Is there really a case where the
recursive lookup in section 7 would have a different color?)

4. In section 12.4, values should be defined by this document fo the
newly established Tunnel Encapsulation Attribute Sub-TLVs registry.

5. Nit: the document says "This document deprecates the Encapsulation
SAFI (which has never been used)".  The use part of this statement isn't
strictly true as it can be found implemented in FRRouting (a fork of
quagga). This said, I fully support its depreciation and look forward to
submitting the patch that will remove it!  Just drop the two never used
comments.

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

This is open source code so anyone is free to review and submit changes.

Lou

v2.23.0 | Report a Bug | By Email