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

Rob Shakir <> Fri, 04 January 2019 20:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 063CF130E9A for <>; Fri, 4 Jan 2019 12:48:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 NvHyvxpwM6z7 for <>; Fri, 4 Jan 2019 12:48:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 62945124408 for <>; Fri, 4 Jan 2019 12:48:39 -0800 (PST)
Received: by with SMTP id v13so37652964wrw.5 for <>; Fri, 04 Jan 2019 12:48:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t0eNXsMVl6EEqxRa/LsVnX5Nun4dEIhXsNuI25GIeKE=; b=nKWmVHxJiS5OBJMaKhH+6v4w4ePHRIYUcq3jsDPAf3vInwgLeMtenf8x9IQlMnv6bK Sn3d/M84idE1U3TREkg7xXjss676tXM/ZXqpZuWhD3lDd+XmsN/mFsiLXflMScWxxTCS MquSMRExobYWs3zz81F5tNJFXEtnuxlZSkXEspMpKv/d83KcinhOTopCyzHS9Xu0Sb+r w22K0cbmQ6JOKkaMSV8M3NKOBnQ+COHRPEflUPNN9RYROapiaRw3PA2w2AoXBIao9g+R k/xf6U34Y4qFq4i6pVMdR65ZFfNacmeQbfx2y/bPeAGmutoGuqXWlB5jqe4p/YwCd2Im qJAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t0eNXsMVl6EEqxRa/LsVnX5Nun4dEIhXsNuI25GIeKE=; b=BlvOVBx+I9MUmHUpdCt8aWPijSLEQAcEvi3aDQr2bX3uBIzqq1knrYUypX6TyHt6N3 +/Eorn5C4KYTMY8YkYlvIEZpPttmJvvG7JnDG6rgBAdfZhgsXkylsenO59h2dLR/5KDY RlUu5S3WbfwkWT64fSRii065u6ynUAps+zgdQ6LxSOJSPjuKVEokLp6nyzQwDsdMfEme 39WS4DJ9tKqUiDuuqDYwIpV/bjXGRPVi3xz61uMbClt1Ox9XN5A8WhO4Ep3zW+gjCjeA XnBMlxOB/hhGVmQpl2Sl+UiNBz9+InFQ4GKCvoLPgb1nyACwHEL5LgOS9ch+nEbAL/DS XWhA==
X-Gm-Message-State: AJcUukfL+frJUxJluIGsEftjitzuQwE8Q56Vc3rK6+f7eki4jUguAJb9 RW7GMrB2lX0shD+UiuPEivNmgmGfPD1zKUUkG5tVGA==
X-Google-Smtp-Source: ALg8bN5kYVRHW/WIJucsQkAiP4z/wi7DWEjif50N7idxu8EhCY8k/K9EZBHHPh4hLIAuFqk6BLNFrmgyPC7etr4IbXg=
X-Received: by 2002:a5d:528e:: with SMTP id c14mr44535256wrv.236.1546634917255; Fri, 04 Jan 2019 12:48:37 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
From: Rob Shakir <>
Date: Fri, 4 Jan 2019 12:48:25 -0800
Message-ID: <>
To: Alvaro Retana <>
Cc: "idr@ietf. org" <>, Robert Raszuk <>, SPRING WG <>
Content-Type: multipart/alternative; boundary="000000000000d7934e057ea800fb"
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 20:48:42 -0000

The alternative approach is to have an "Operational Considerations" section
of draft-ietf-idr-bgp-ls-segment-routing-ext that simply points out this
consideration. i.e., something like:

"Since the error handling approach defined in RFC7752 specifies 'attribute
discard' as the error handling mechanism for BGP-LS, systems implemented
using BGP-LS for discovery of topological attributes used for path
calculation MUST consider their mode of operation based on incomplete data
being received (due to attribute discard). If an assumption of strong
consistency between the BGP-LS receiver, and the network's topology is
made, system designers and operators SHOULD consider means to detect
erroneous attributes being discarded on a session and act accordingly."

Taking this approach doesn't say "hey, let's change this", and also doesn't
say "here's what the system should do", it just makes sure designers and
operators are aware of the consideration. That said, this is rather
implementation specific.


On Fri, Jan 4, 2019 at 11:39 AM Alvaro Retana <>

> 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%2012:00:00%20EST>.
> Right…
> 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
> specifics…
> …
> Alvaro.