[Idr] backward compatibility issues - draft-boutros-bess-evpn-geneve

"Susan Hares" <shares@ndzh.com> Tue, 23 July 2019 20:22 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0C24412099C; Tue, 23 Jul 2019 13:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.949
X-Spam-Status: No, score=0.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hwepIroykwDP; Tue, 23 Jul 2019 13:22:46 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net []) (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 12543120910; Tue, 23 Jul 2019 13:22:46 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=;
From: Susan Hares <shares@ndzh.com>
To: bess@ietf.org
Cc: bess-chairs@ietf.org, idr@ietf.org
Date: Tue, 23 Jul 2019 16:22:41 -0400
Message-ID: <00d301d54194$6141b8c0$23c52a40$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D4_01D54172.DA34ACA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdVBlBVPmqyCQRLaSDWo/DgI+5kxFg==
Content-Language: en-us
X-Antivirus: AVG (VPS 190723-2, 07/23/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GbINREwbTAlnGEyIGTOFqtlrf24>
Subject: [Idr] backward compatibility issues - draft-boutros-bess-evpn-geneve
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 23 Jul 2019 20:22:58 -0000

Bess Chair (Matthew and Stephane) 


If we are going forward to the Tunnel Encapsulation attribute, we need to

whether we should send to RFC new work with the Encapsulation Extended


Otherwise, we are locked into the functionality of the 

Encapsulation Extended Community at the "bare bones" mechanisms. 


Specifications with widely deployed Encapsulation Extended community 

Functionality are one case.  


New Specifications just being adopted to the BGP community are a 

second case.   My point at the Microphone was to find out what

case the draft-boutros-bess-evpn-geneve gives. 
Sue Hares 


   The Encapsulation Extended Community was first defined in [RFC5512
<https://tools.ietf.org/html/rfc5512> ].
   While it provides only a small subset of the functionality of the
   Tunnel Encapsulation attribute, it is used in a number of deployed
   applications, and is still needed for backwards compatibility.  To
   ensure backwards compatibility, this specification establishes the
   following rules:
   1.  If the Tunnel Encapsulation attribute of a given route contains a
       barebones Tunnel TLV identifying a particular tunnel type, an
       Encapsulation Extended Community identifying the same tunnel type
       SHOULD be attached to the route.
   2.  If the Encapsulation Extended Community identifying a particular
       tunnel type is attached to a given route, the corresponding
       barebones Tunnel TLV MAY be omitted from the Tunnel Encapsulation
   3.  Suppose a particular route has both (a) an Encapsulation Extended
       Community specifying a particular tunnel type, and (b) a Tunnel
       Encapsulation attribute with a barebones Tunnel TLV specifying
       that same tunnel type.  Both (a) and (b) MUST be interpreted as
       denoting the same tunnel.


If we are going forward to the attribute, we need to consider