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

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

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"
Thread-Index: AdVBlBVPmqyCQRLaSDWo/DgI+5kxFg==
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/GbINREwbTAlnGEyIGTOFqtlrf24>
Subject: [Idr] backward compatibility issues - draft-boutros-bess-evpn-geneve
Precedence: list

Bess Chair (Matthew and Stephane) 

 

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

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

 

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 

 

 
 
-----------------------
 
 
raft-ietf-idr-tunnel-encaps-13#page-21
 
   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
       attribute.
 
   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

[Idr] backward compatibility issues - draft-boutr… Susan Hares