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

Alvaro Retana <> Fri, 04 January 2019 22:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0FADD130E9B; Fri, 4 Jan 2019 14:05:50 -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 uhwGPYuhh5ek; Fri, 4 Jan 2019 14:05:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 866A9130E90; Fri, 4 Jan 2019 14:05:48 -0800 (PST)
Received: by with SMTP id y1so31531559oie.12; Fri, 04 Jan 2019 14:05:48 -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=6XALTTmsSKz1gwkA6jV+737gLK5y7ndXPqWbkPas3uA=; b=fhttuqhdGLg7ON2+OMii7wxZMFFHmK98p3VPZ/ySjQqanti9iv6858Bix012HkNSbR 3kAsHdPADVme9ltBkTpTfGH4nFVezfSUHTCVykb+LakasuWwEmwFsnwRa12QczEZQEUj 5av55VxyoaTJIBtHnfcpVPpb7WfL/TYB//c8eaKwVvEXb/ZV5RPj06yWt9qyJ1X82H7S W5s0tWtRhcWTKTVsYWS6JiCU6bUDuVaDDsZNsAgw32WJCNEQ7HaxHLFHy51aCI6GG3HC TzW8htX+was9PION3rdsAxh+mGwYn65tYigCFtBq8VGVyp3nzxHoYv+AxjbSSbj2FZud lBqw==
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=6XALTTmsSKz1gwkA6jV+737gLK5y7ndXPqWbkPas3uA=; b=tWwbX8gAN0YyHZvFvPngGZSd2XOpxJhcKBAcl8YGj/9hpEaw2SVwkyrrVI6Xa1JA8S zKdfp/AozhznrcOGiV3l9oRziEUq9b5ilDLxXS0bdXgRTBeyZ1NaWXTehcjE+VAzt8OZ A/hk4wmNwOuXlIc4H/hgw9tb6+MYl+vgR3q/ngY1FlORetVg6WuROsn3dWOefXi2Kq9p 89gga+j9mx1GSNYnYt/PfY0ZLw/c+yt/Pg+BXrTw0v7EKEkBT3CFHDEBIK4aN32KhlmL f9aSHrdAHmZ3uM0ZAHmhYVf8triTtPDhkxettii1VDoePdQY4SDhu2IRgsxALkmE5KEp DV7w==
X-Gm-Message-State: AA+aEWab+E+efTiY6jnSKQ6kxZZh/E0kr7gMNDmsB9iF48JdAu7m27O7 NBlCB+tYRWjbUf0lvHhTqyuryY3o98LMrT+fII4=
X-Google-Smtp-Source: AFSGD/UEUPLkH9j5HaT4CA7N/Oeue7GwimoY7nD9Gb/6rLHn5xANmUTG5InaaD0t9GKMlVm+Bfts6WfX/n4E0SPg9hk=
X-Received: by 2002:aca:b6c3:: with SMTP id g186mr37840978oif.289.1546639547800; Fri, 04 Jan 2019 14:05:47 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Fri, 4 Jan 2019 14:05:47 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Date: Fri, 4 Jan 2019 14:05:47 -0800
Message-ID: <>
To: Rob Shakir <>
Cc: SPRING WG <>, "idr@ietf. org" <>, Robert Raszuk <>
Content-Type: multipart/alternative; boundary="000000000000d7a3ae057ea91401"
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 22:05:50 -0000

On January 4, 2019 at 3:48:38 PM, Rob Shakir ( wrote:

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:

We would need something like it in every bgp-ls-sr draft…or a pointer back
to draft-ietf-idr-bgp-ls-segment-routing-ext...

"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.

[This is probably not the right place to wordsmith, but I don’t know how
“MUST/SHOULD consider” can be normatively enforced.]

Because it is implementation/deployment specific, some examples of the
cases where there could be more (or less) potential issues would be ideal.
As Robert’s example: "In my view SR controller is mainly used as
optimization not as critical element - well at least in the deployment
models I would personally recommend to use.”

This last part could end up making the document significantly longer…and it
doesn’t really give me a warm fuzzy feeling adding it after WGLC…to an idr
document...and without it being properly reviewed by the spring WG.  But
these are details we can take care of as we move forward [*].



[*] I haven’t finished my AD Review
of draft-ietf-idr-bgp-ls-segment-routing-ext.