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

Alvaro Retana <> Wed, 19 December 2018 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2285C130E91; Wed, 19 Dec 2018 09:57:38 -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 zJ19lhtcaR-e; Wed, 19 Dec 2018 09:57:35 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::32b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B1CE4130E86; Wed, 19 Dec 2018 09:57:35 -0800 (PST)
Received: by with SMTP id v23so19896881otk.9; Wed, 19 Dec 2018 09:57:35 -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=D9I24nAhL62eUOMO1LJ34T2RhUPFGsbJg7SvUfKIkk0=; b=sqGGfKHXE9dfLNqUvOcRLvdfxqcB/ka2O4RINE/HoiSImCu5OzFN3QcjEp/lmNlmWl k8wrlug2D+8W8qj9LndfrAUTS3HxL4qRHuJM7o40ykS1MIqiF0w5ZzD1Udj8FeQXRYLX trEOeWoA7fTgvrgydKCCk42hCmlozVsb5Vi9AS6p46Hq2OR3da1EiRrYQ8SJADiSw0RC 40wX4BEzmO4Dav2bF5sFMDzPMBYpGSvARk1HzjMV0wqRyGiqNBoQANvL2KYzUD6Gt1A6 aOZb6kEmytVviiBUHhfryYBBFuA5XrjWhBMsbCyHk7NKHPc3yKON6EuvFQu+cJCrOmAy O++Q==
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=D9I24nAhL62eUOMO1LJ34T2RhUPFGsbJg7SvUfKIkk0=; b=I46i5H44DpPgCybJ8RCA0iFiZewHiZQBZjKmmUIFQioo9cGMtpk6kEU+mHXbQqUkHX 7tlrlv3CXaPCPw05a4Nd8q+eE1ql0DjoMY8XtFqZxHTxPsaP2iBc9Bqxo5vEepKf5YDE /D/YlciqCyA56W8ZQXIxxkbuGs0m+u9NGRtPnNXLEou05XLZb7j8QpXm79kTWDmalDi1 gnksXU6f1L8X999ow/rILkLzM73EjRu7rOidjKF1prblv3xJ8dQBv/QZCkTb4s1F81bb Dsmo2NaOf6OflseWparU6SKWna9dde0JxKPwyDK3Upj1Q2Zz5rm1ZWkOCgrWSSmSVBKe OtBQ==
X-Gm-Message-State: AA+aEWZE/gW5MUW9uXJXgPsAQzeTVlqCLx/bBId1N5Nx/2btCpJxaLkf dIsWie0BiR4xNPALRWuTmacjJ1tnTzKnr+a+3Yf8Jw==
X-Google-Smtp-Source: AFSGD/UD5kcqNB7y2cP0jj3Y/ILH2BBiVFNW/yOx9+f+TUyclwMhE3WTHrp8Fosxkn2dCm4U0y1DtH62J0MOGyY41os=
X-Received: by 2002:a9d:282:: with SMTP id 2mr15300922otl.287.1545242255017; Wed, 19 Dec 2018 09:57:35 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 19 Dec 2018 09:57:34 -0800
From: Alvaro Retana <>
In-Reply-To: <13486_1545174620_5C197E5C_13486_197_1_53C29892C857584299CBF5D05346208A48970FEB@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
References: <> <13486_1545174620_5C197E5C_13486_197_1_53C29892C857584299CBF5D05346208A48970FEB@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
X-Mailer: Airmail (528)
MIME-Version: 1.0
Date: Wed, 19 Dec 2018 09:57:34 -0800
Message-ID: <>
Cc: "idr@ietf. org" <>, SPRING WG <>
Content-Type: multipart/alternative; boundary="000000000000b3cfbb057d63bff8"
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: Wed, 19 Dec 2018 17:57:38 -0000

On December 18, 2018 at 6:10:21 PM, ( wrote:




1) shouldn’t BGP-LS error handling be also discussed in the LSVR WG? does not
seem to cover this.

And this document was under WGLC till yesterday.

Yes, good point.

I wanted to focus on SR’s use, but I think you’re right to point out that
other applications may have the same needs.  I think/hope that people on
the lsvr list are also on the idr list (at least), so I’ll forward a
pointer to this thread just in case.

2) Regarding BGP-LS error handling, it’s not clear to me that “treat as
withdraw” would be “safer” than “Attribute Discard”. “Session reset” is
safer from an inconsistency standpoint but definitely also “has a direct
effect on how traffic is forwarded in the network” and a sever one.

[Not sure about the ending “…and a sever one”.]

I agree.  I don’t want to rehash the discussion from rfc7606 about the
types of approached and whether there should be more or not (or what those
could be)…. I’m just pointing out that I think the current approach is not
the right one for all applications.


> 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

a) IMHO that implication would be the same without SR, e.g., with RSVP-TE.
In fact, the effect on how traffic is forwarded is coming from the PCE
computation using partial/incorrect topology information, not how the
forwarding is enforced.

b) IMHO RFC7606 was more concerned about forwarding loops/black holing
–especially for IBGP-, rather than changing the path of the traffic.
(as ““treat as withdraw “ or “sessions reset” would also have “a
direct effect on how traffic is forwarded in the network”.) Note that
the latter quote is not from RFC760 which uses the terms  “no effect
on route selection or installation” which is a bit different.

Interpreting the difference between “a direct effect on how traffic is
forwarded in the network” and  “no effect on route selection or
installation” is part of the reason this topic is not straight forward.

To me, in the BGP-LS+SR context, because the controller *installs* the
source route at the ingress router, the two phrases apply.

However, other interpretations are possible…which is one of the reasons for
this thread.  For example, during the rfc7752 discussion, a point was made
that the controller (being at the receiving end of the BGP session) would
not have to worry about the effects of attribute discard because any loss
of information would not have an effect on how it (the controller) selected
or installed routes.  That argument is not completely flawed (the
controller does not use the BGP-LS itself for routing), but (my personal
opinion) is that the use of the information (in later programming the
network) is what is important.

c) Coming back to SR, quickly looking at the ToC, the discard of the
SID simply means that the SID can”t be used by the SR source/ingress
node. The discard of the SR node attribute means that the node can’t
be used to forward a global segment. The use of flex-algo is a bit
more touchy as discarding the support for a flex algo will change the
routing along this flex algo. But only from the perspective of the
BGP-LS consumer, so this would not create forwarding loops/black hole,
but only a non expected routing path.

Which ToC?

You’re right…but only if the information is discarded when it was initially
learned.  If the error occurs later, when the information was changing for
example, there is the possibility that the controller will want to use a
node that shouldn’t be used any more….or be calculating
not-the-best-routes.  Sub-optimal routes are not great and may not matter
too much (compared to loops, for example), but some users may have specific
business objectives (application performance, for instance) tied to the
definition of the paths…it will be important to them.

4)  I haven’t checked but it’s not clear to me that IS-IS has a perfect
(better?) error handling.

If you want to discuss this, please do it in the lsr WG. :-)


5) BGP-LS and IS-IS have chosen a different granularity to advertise the
LSDB (per link/node vs oer LSP) which very likely will result in a
different error handling hence a different vision of the topology. This
looks like day 1 design choice for BGP-LS, so difficult to address.