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

Robert Raszuk <> Tue, 18 December 2018 23:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9E48131221; Tue, 18 Dec 2018 15:23:21 -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, URIBL_BLOCKED=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 smtFEiqXDqGS; Tue, 18 Dec 2018 15:23:19 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B09F1311FA; Tue, 18 Dec 2018 15:23:19 -0800 (PST)
Received: by with SMTP id 101so8538696pld.6; Tue, 18 Dec 2018 15:23:19 -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=l1e2iFpwLu8E0seIM3iMmUTrVnNmSbkZK5eRTnNjtZQ=; b=Z2RcZEEbTHPcvlAhzlD+g8xY49O6+Kz1ngRmXZSh9whivEAKqsk3hYcLvoFQnD4NcU JyiUTuGW9MYezVkCN38A5rvpbBKv2ogATiVdHKK0E/ZNxiW//r4ppfk+URAWC6/lYZUp Htg34PzH9hJsv+hQ6dxP9QAi92ADDujzXtX3hfWmvt2apvSuwPpsxApWoh4wp8s4TJKW +F1OeNxVH6a8Qfs+y/DMan1tgGHuEVKS7nPTHWQSDYk6y4gedolswst2qxP/Ox4VXWnG 9RyE+5fMkTSQlQyodK8FHcdGZQoWDWDhcSiVuww6dMCX5m0n0SDd3AhhIxIpYagmtZnz N8tw==
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=l1e2iFpwLu8E0seIM3iMmUTrVnNmSbkZK5eRTnNjtZQ=; b=uaMESmUfpXBlqpmvzAwHynSZnY1nfxqHVrJE5fqxDNsHOqEn0ikydFbOICzMDuuHud cM/JwsFXZgf+ZnweOBiQm5nH/stM+YpE9vKYbv/ZQtI1biycr9g8QYxAQ81Ad93/xqbj VaLPrZ7uLjX5iYaY/bO7Xmt20yCL/0dNMYJgGpkqw6wsLDlL5ff+3b8c7eEZJGkMNPkh 6Af4VT7RoKJowixWcie69aBiIevEdBs1CwLmSD7RNx7xoVSHKxmGZC76DAThfdhMBjWN NYctLGV/z1A3jSb34pF1nPp9TMzWPv4XNEDwLuTJNxKiyePq+S6Lr44i29m9BkoLcZfQ FiQg==
X-Gm-Message-State: AA+aEWYkqJLf3kBKqc1Yi2Hv/uXi0b9E9rYQbzMiZtdJyf3ekNWyaiaR tuk+CPFZvJ34nhD9GCb9MR0aOJ3vFb7O/QKifUCxbQ==
X-Google-Smtp-Source: AFSGD/XMFXDFupn6r+8JUr/nsLiKGnqYFKm9SeMeRf6P0rwuSK8UDl7RmPAiSkvmpffEfa4+kZSCTSDX1+/VUAJPnX4=
X-Received: by 2002:a17:902:7296:: with SMTP id d22mr18653699pll.265.1545175398014; Tue, 18 Dec 2018 15:23:18 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Wed, 19 Dec 2018 00:23:08 +0100
Message-ID: <>
To: Alvaro Retana <>
Cc: "idr@ietf. org" <>, SPRING WG <>
Content-Type: multipart/alternative; boundary="000000000000b6e65f057d542e65"
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: Tue, 18 Dec 2018 23:23:22 -0000

Hi Alvaro,

What comes as #1 question to your points is a comparison of SR controller
with regular BGP RR.

I think it is safe to assume that error handling on SR controller would be
no more aggressive then on RRs. So if there is error the updates may be
dropped on the RRs itself, logged and proper NOC alarm generated.

IMO this is no different regardless if you use SR with BGP-LS or just plane
regular BGP routing.

So unless your goal here is to point out the deficiency of BGP error
handling RFC I am not sure what is so specific to BGP-LS and SR.

Yes I am not big proponent of using BGP-LS all together, but not because it
has inherited BGP error handling.


On Tue, Dec 18, 2018 at 10:09 PM Alvaro Retana <>

> Dear idr and spring WGs:
> tl;dr  I don't think that BGP-LS, with error handling as specified
> ("attribute discard"), can provide the robustness that an application (like
> SR), with direct impact on the forwarding in the network, needs.  [Jump to
> the bottom for discussion.]
> The BGP-LS extensions for SR (e.g.
> draft-ietf-idr-bgp-ls-segment-routing-ext) are, as explained in that draft,
> used so that "an external component (e.g., a controller) then can collect
> SR information from across an SR domain and 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."
> To me, that obviously implies that use of BGP-LS for SR has a direct
> effect on how traffic is forwarded in the network.  Does any one see it
> differently?
> The error handling mechanism specified in rfc7752 is "attribute discard"
> [rfc7606].  If an error is detected, then the information in the controller
> may be, at best, incomplete, but it could also be out of date...resulting
> in "segment routes" that don't follow the best available path or that may
> even end in a black hole.
> It seems clear to me that this is one of the cases that rfc7606 warned
> about:
>    o  Attribute discard: In this approach, the malformed attribute MUST
>       be discarded and the UPDATE message continues to be processed.
>       This approach MUST NOT be used except in the case of an attribute
>       that has no effect on route selection or installation.
>       ....
>    For any malformed attribute that is handled by the "attribute
>    discard" instead of the "treat-as-withdraw" approach, it is critical
>    to consider the potential impact of doing so.  In particular, if the
>    attribute in question has or may have an effect on route selection or
>    installation, the presumption is that discarding it is unsafe unless
>    careful analysis proves otherwise.  The analysis should take into
>    account the tradeoff between preserving connectivity and potential
>    side effects.
> There was a related discussion as a result of my AD review of
> draft-ietf-idr-ls-distribution (= rfc7606) [1][2].  At that time (2015),
> the consensus on the list was (paraphrasing): if there's a malformed
> attribute we won't be able to recover, but that's ok because BGP-LS is
> "purely application-level data that has no immediate corresponding
> forwarding state impact", and there won't be an impact on critical AFI/SAFI
> for network operations.   No one else argued against I ended up
> in the rough...
> I think the situation has now changed because BGP-LS is carrying SR
> information that is used to define paths in the network -- even if
> isolation exists, as described in rfc7752:
>                  ...    Furthermore, it is anticipated that
>    distribution of this NLRI will be handled by dedicated route
>    reflectors providing a level of isolation and fault containment
>    between different NLRI types.
> ...the BGP-LS information could still be incomplete, stale, etc..
> After all that...  I don't think that BGP-LS, with error handling as
> specified ("attribute discard"), can provide the robustness that an
> application (like SR), with direct impact on the forwarding in the network,
> needs.
> What now?  I see several potential paths forward (there are probably more):
> (1) "fix" BGP-LS to mandate (MUST) isolation and change the error handling
> approach
> (2) change the error handling approach...maybe just when used with SR
> (3) the controller should only use the SR information received from
> routing protocols (IGP/BGP, e.g. draft-ietf-idr-bgp-prefix-sid)
> (4) ..??
> I didn't find a specific discussion about this topic in the archive...but
> I may have missed it in between other related ones.  If I did, please point
> me to it.
> Thoughts/ideas/comments?
> Thanks!
> Alvaro.
> [1]
> [2]
> _______________________________________________
> spring mailing list