An in-band BGP mechanism for looking-glass address discovery
draft-jaufeerally-bgp-lg-cap-00

Document Type Active Internet-Draft (individual)
Author Rayhaan Jaufeerally 
Last updated 2021-03-30
Stream (None)
Intended RFC status (None)
Formats plain text pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Internet Engineering Task Force                      R. Jaufeerally, Ed.
Internet-Draft                                                       TBD
Intended status: Standards Track                           30 March 2021
Expires: 1 October 2021

      An in-band BGP mechanism for looking-glass address discovery
                    draft-jaufeerally-bgp-lg-cap-00

Abstract

   This document specifies a mechanism by which eBGP speakers can
   propagate a BGP looking glass API endpoint address, in-band within a
   BGP session.  The looking glass API is defined by RFC 8522

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 1 October 2021.

Copyright Notice

   Copyright (c) 2021 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 Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Jaufeerally              Expires 1 October 2021                 [Page 1]
Internet-Draft              Abbreviated Title                 March 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  Capability wire format  . . . . . . . . . . . . . . . . . . .   2
   3.  Usage examples  . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Autonomous systems that peer with one another using the Border
   Gateway Protocol (RFC 4271 [RFC4271]) do not have an automated way to
   tell if the prefixes announced over a particular peering link are
   acceped by the peer.  One way in which an AS operator can verify
   acceptance of routes by a peer is using a looking glass which may be
   provided by the peer, however this introduces manual toil in the
   operation and turnup of peering links.

   This document proposes a mechanism building on the looking glass API
   defined in RFC 8522 [RFC8522] to enable the automatic discovery of
   the looking glass endpoint, and therefore enable the automated
   probing of announcement acceptance by a peer, for instance.

   The mechanism by which this is achieved is to intoduce a new BGP
   capability which is sent in an OPEN message at session establishment
   time.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Capability wire format

   The capability is composed of two parts, the header and payload.

   The following shows the wire format of the capability payload header:

    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+
   |Version| Type  | ... varies based on type ...
   +-+-+-+-+-+-+-+-+

                                  Figure 1

Jaufeerally              Expires 1 October 2021                 [Page 2]
Internet-Draft              Abbreviated Title                 March 2021

   This document defines version 1 of the capability, and as such the
   Version field MUST be set to 1.  Implementations MUST discard the
   capability if the version number is not recognized.

   Type can be set to one of two values:

                      +-------+--------------------+
                      | Value | Description        |
                      +=======+====================+
                      | 1     | On router endpoint |
                      +-------+--------------------+
                      | 2     | URL endpoint       |
                      +-------+--------------------+

                      Table 1: Type field in header
Show full document text