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
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
