Re: [Idr] [spring] Error Handling for BGP-LS with Segment Routing

Alvaro Retana <> Fri, 04 January 2019 19:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D8386130E8E; Fri, 4 Jan 2019 11:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SOMko7TUL6ok; Fri, 4 Jan 2019 11:39:58 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A6C16130E8D; Fri, 4 Jan 2019 11:39:58 -0800 (PST)
Received: by with SMTP id y1so31239948oie.12; Fri, 04 Jan 2019 11:39:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=j2qYbxrb11VG+YQPmVuc4eO41OAL5bvFFghMv486VE0=; b=B+OkL/8USE7jlmVtio+xmVvo3ovZoMkxNtIx4QXAY8SrNDtDOcSb2qPFNAH4nGG2aw OAqdbJ2uhXxPx82s59rs0g/ta9BgCCN8/4k2KjbcVCtgR1XjBbBWc/03hLPrljIPXNkT iz8sRfR9ZEuzbLVVkQJXq49X7+trY/01N/zSPhP0pgkymJjA5ZFagQr19g8376HMtzU9 d0ZdjkZM60opQav9clmG9zdm56pIZ242Z9X0jfwycxB7aiqVtoqu/fJo4coUFzrFP8nF a1EUzkicUDLGJbffkpcj8lkaVVrgPUQlebkINZlUjqCi7BdiIszUX2GkdorrR30LvlKe Jnmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=j2qYbxrb11VG+YQPmVuc4eO41OAL5bvFFghMv486VE0=; b=jbwpfVEkEteVhIdYbtNKGL+96isckMBbDUzzQW+etJ/d8KOyWFZxEPYhh2LD+3Pcg3 a9HUfnCYxsMzH+IFiLXdDAlafOpDicyoc4pC4GrIQOkGAFHPyZQzPCULRotxqB5Zj9AU yXhAW9e1VwByazCqYj76L94LfqD29l5EgBtfSIgcnPKaUYvylHxm0g4AlJ2NzjWPK5H6 qJciyZL5u/QbZoKpukIaAq0pPBvoK60RfemacmcrsVIzvrXZ3Z3J5NtPQ9HYj68W4u/c zcDECcwwZ0CnztBI91lEJGmmhgROqi71g4IqkHgGPLA2piiljw1D9SbAr0q4hl7qzZAL skUQ==
X-Gm-Message-State: AJcUukdCF+fCAg9xchJkmT3TETRQO8973lzZ+33L5AN8DAeSWKZ8x8pV +nB3+i1aUcUeC5zak9BwgHTqezNx+sHjBbc70is=
X-Google-Smtp-Source: ALg8bN56QiEob4zis8vVfaqfykpRBB/tQqIeocv4TC7ARhrP5/4jZSfowX5JIbtxbc3SChJH4HjHqcX8/pw8PRyytPE=
X-Received: by 2002:aca:aa81:: with SMTP id t123mr36850992oie.218.1546630798011; Fri, 04 Jan 2019 11:39:58 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 4 Jan 2019 11:39:57 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <>
MIME-Version: 1.0
Date: Fri, 4 Jan 2019 11:39:57 -0800
Message-ID: <>
To: Rob Shakir <>
Cc: "idr@ietf. org" <>, Robert Raszuk <>, SPRING WG <>
Content-Type: multipart/alternative; boundary="00000000000050733d057ea70b98"
Archived-At: <>
Subject: Re: [Idr] [spring] Error Handling for BGP-LS with Segment Routing
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Jan 2019 19:40:01 -0000

On January 3, 2019 at 5:40:23 PM, Rob Shakir ( wrote:

Describing these compromises is, of course, a good idea. However, it's not
clear where this description would go -- we don't really have a document
that describes this overall system and how it might be implemented today
<http://airmail.calendar/2019-01-04 12:00:00 EST>.


I started reviewing the documents with BGP-LS extensions for SR…starting
with draft-ietf-idr-bgp-ls-segment-routing-ext, which is the first BGP-LS
extensions document to be sent for Publication where the application is
explicitly to "construct the end-to-end path (with its associated SIDs)
that need to be applied to an incoming packet to achieve the desired
end-to-end forwarding”.  All other BGP-LS extension documents have in
general followed the “informative” tone of rfc7752.

I don’t necessarily think that the description of the system belongs
there…but there’s no other place to put it, at least not currently.  The SR
Problem Statement (rfc7855) and the SR Architecture (rfc8402) both just
make general statements about the need to support centralized and hybrid
(and distributed, of course) control planes — they don’t go into more