Guidance for Authors writing text for the BGP Tunnel Encapsulation Attribute

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 4 September 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The BGP [RFC4271] Tunnel Encapsulation Attribute (TEA) [RFC9012] defines a BGP attribute that passes tunnel information. BGP passes this attribute to associate prefixes with a particular tunnel.¶

Currently proposed BGP specifications in the IDR and BESS Working groups have defined new tunnels and new parameters for these tunnels in Sub-TLV. This document provides guidelines to help authors quickly write correct text for new tunnels (defined in tunnel TLVs) and new Sub-TLVs. These guidelines are given as "templates" to aid new authors. More experience authors should view these templates as a list of expected content.¶

One additional challenge for tunnels defined by [RFC9012] TEA is the interaction with the PMSI tunnels ([RFC6514], [RFC7385]) is to carefully define the interaction between PMSI tunnels and TEA tunnels.¶

This set of guidelines comes from the lessons learned from reviewing the following different drafts for the BGP TEA:¶

draft-ietf-idr-sr-policy-safi:

defines a BGP NLRI and a SR Policy tunnel TLV for the BGP TEA, and several Sub-TLVs for the SR Policy Tunnel TLV based on the SR Policy architecture [RFC9552].¶

IDR drafts defining parameters for the SR Policy tunnel:

This includes draft-ietf-idr-sr-policy-nrp, draft-idr-sr-policy-path-mtu, draft-ietf-idr-sr-policy-path-segment, and draft-ietf-sr-policy-seglist)¶

draft-ietf-idr-sdwan-edge-discovery:

defines a Hybrid SDWAN Tunnel and several Sub-TLVs.¶

draft-ietf-bess-multicast-controller:

defines two tunnels (Any Encapsulation tunnel (78), Load-Balancing Tunnel, Segment list Tunnel, and Sub-TLVs for these tunnels.¶

draft-ietf-bess-evpn-geneve:

defines a Geneve tunnel type, and a Geneve Tunnel Option Sub-TLV.¶

The purpose behind the guidelines is content rather than form. In the draft-ietf-idr-sdwan-discovery-document, I used tables to refer to Sub-TLVs supported and sections with the description.¶

I will post prior to IETF-122 on the IDR wiki, reviews and suggested changes based on this document for the BESS and IDR draft using tunnels. This rought draft is to provides an snapshot of the Wiki prior to IETF-122.¶

2. Tunnel TLV Specification Guidelines

This section describes a guideline for information regarding new tunnel types. It is presented as a template to aid new authors.¶

Tunnel encapsulation specification requires the following things for each tunnel:¶

Name:

Short name that will go in IANA allocation¶

Code:

Code assigned by IANA¶

Description:

Give a description of the tunnel and usage. The authors should strive to have a paragraph of description, but the description may point to other sections in the document.¶

List of all Sub-TLVs supported:

This list should include the sub-TLV that may be sent in this tunnel TLV. This list should include mandatory and optional TLVs. Please denote which sub-TLVs are mandatory and which sub-TLVs are optional. Please note any sub-TLVs that are not listed are not supported.¶

List of all Sub-TLVs not supported:

This list includes the Sub-TLVs which are not supported by this tunnel TLV. Note that any Sub-TLVs which are not explicitly defined as supported are by default unsupported.¶

A validation procedure:

Each tunnel should have a set of procedures to determine if tunnel signaled by BGP is valid.¶

Multiple Tunnel interactions:

Multiple Tunnel TLVs can be included in a single BGP TEA. If there are interactions between Tunnel TLVs, then this should be described in this section. For example, if one Tunnel TLV defines a security association that another TLV uses.¶

Security Considerations:

A security section needs to provides specific comments regarding the information passed in the tunnel TLV. Tunnel TLVs can send critical information regarding a network infrastructure, and this critical information needs to be identified. After the critical information is identified, the security section should discuss how network operators should restrict access to such critical information.¶

Management Considerations:

A management section includes comments on how the tunnel will be managed.¶

It is helpful for items 1-5 be clearly laid out in one section.¶

3. Sub-TLV Specification Guidlines

A document specifying a new Sub=TLV needs include the following Information:¶

1. Title:

Short title that goes in IANA documentation (10-15 characters).¶

2. Sub-TLV Type Code:

Value for Type code.¶

3. Encoding of Value bytes:

this information should include:¶

3.1 diagram of value byte¶

3.2 Description of each field in Encoding¶

3.3 Error handling per field¶

4. Tunnel TLVs this Sub-TLV can appear in:

The authors should list tunnel TLVs that support this Sub-TLV as mandatory or optional Sub-TLV¶

5. Sub-TLV role in validation:

Please indicate whether this Sub-TLV play a part in validation in the validation of the validation of any Tunnel TLV.¶

It is helpful for items 1-5 be clearly laid out in one section. If new sub-TLVs are defined, it is helpful that these Sub-TLVs go before the list of all sub-TLVs.¶

In addition, the SUB-tLV may be part of discussions on:¶

• Multiple Tunnel interactions,¶

• security considerations with specific comments regarding critical information passed in a tunnel TLV in a BGP TEA,¶

• management considerations that includes comments on how the tunel will be managed.¶

4. PMSI Interactions Specification Guidelines

The Tunnel Encapsulation [RFC9012] states that the consideration of "P-Multicast Service Interface Tunnel" (PMSI Tunnel) attribute are out of scope.¶

Please fill out the PMSI and TEA template below. Review of these interactions took a long time in [RFC9012], so think carefully about these questions.¶

Here's a few questions that must be answered in the Template:¶

• 1) When is the PMSI tunnel Attribute valid to attach by itself?¶

• 2) When is it valid to attach both the PMSI tunnel attribute and a BGP TEA?¶

  • 2a) In the case that it is valid to attach both PMSI + TEA, what happens if either is malformed?¶

  • 2b) In the case that it is required to attach both, what happens if either the PMSI or TEA is missing? Note: Malformed implies syntax checking.¶

  • 2c) When it is invalid to attach both PMSI and TEA, what is the error procedure if both are attached?¶

• Is there content checking of the TEA that is impacted by PMSI?¶

  • By content checking, this template document means that given valid TEA and PMSI attributes, some content checking must be done prior to installing the tunnel and/or a multicast tunnel.¶

5. IANA Considerations

This section specifies no IANA considerations¶

Author's Address