[Lsvr] Fwd: Error Handling for BGP-LS with Segment Routing

Alvaro Retana <aretana.ietf@gmail.com> Wed, 19 December 2018 18:00 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: lsvr@ietfa.amsl.com
Delivered-To: lsvr@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 40CD2130E9C for <lsvr@ietfa.amsl.com>; Wed, 19 Dec 2018 10:00:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nE5A7gpb8Ohc for <lsvr@ietfa.amsl.com>; Wed, 19 Dec 2018 10:00:25 -0800 (PST)
Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26306130EC9 for <lsvr@ietf.org>; Wed, 19 Dec 2018 10:00:25 -0800 (PST)
Received: by mail-ot1-x32a.google.com with SMTP id n8so19900117otl.6 for <lsvr@ietf.org>; Wed, 19 Dec 2018 10:00:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=OQ+ZQi3Br+TKEN9Gj/mszeRgjs8er4JBTXTbrCkMTf4=; b=Qd3eW+DVX46Qn/ojhm40pazXGbOlwdIENNMDLN5/JI/dd0cgorcVT7bzELCSD1JeQ8 e6QNufqWse66kWkvDJyPlx8b2hV9jODhQiTfGLGiHFOiis/FLItp62u8spfqUM0L5LXm fmQS50yPdtzI2X1iLhNwy5XHjELWpVxtub5M/8IrfU+/99WDDu7YQZ5AEGNzdYeummeE 4fq0Zw4GfSzSuFYr8nXeev5FI/GDIcH1RvaT4HWJIERqvwOkySTInIG3QyqljNioFejS ujkGzNbmA5nKGa/+5zZpNK6NNO/e1gU83KwhxCAKUrNGVv8QMMU3sO8XBLf2cPDTYn2A Hvmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=OQ+ZQi3Br+TKEN9Gj/mszeRgjs8er4JBTXTbrCkMTf4=; b=LWe6pUwlTygj6LN4I+QV8ExWXJdFEL7xjhV8awL/XA4HTlyZ3qYQ2dd7VMESDBFJ8S qO5TCxU7Rx5GmH+NL7MemczXsHPwKS/MzRi+gdIH4nG3rYJYs/eH0+OGsokZdZuURNCa Hu9w5jXGCOvwJSuvMOigB1gkahCo/BdMYBKZU2mihUhHEssJ7ul/3adNvZJjYe07smbP 8+RjD+gfoe9r5W4tlbjsZc4OkzFfytkJ3gFrbbInf/kNtPkA7oqq5davtJ5di3cXy0G0 GoIZVB0DFvQ1Papz/RZZyOdRarW5xfEFk9ZJbjxGC9cBt3ApTuIZqEo4ffEdMCFwDZv3 6RYQ==
X-Gm-Message-State: AA+aEWaz0s8rU4mPhJgLGnS4+wdkAyy9HUKnQY0Ma0cTEvXKdwd2cN57 PI6bgjH4+HCqYrOwNZR7TkmSN4XUNeEUsr/c1/PxWg==
X-Google-Smtp-Source: AFSGD/VKfgTIzlPoiyOiOw2jd6s83e55qBwAkQacbhHEqdWTgOh6zCnLrWEJXGhv3D1m7ciRjanPyNdnMPE+UbJIlIc=
X-Received: by 2002:a9d:694a:: with SMTP id p10mr16785597oto.44.1545242424329; Wed, 19 Dec 2018 10:00:24 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 19 Dec 2018 10:00:23 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
X-Mailer: Airmail (528)
MIME-Version: 1.0
Date: Wed, 19 Dec 2018 10:00:23 -0800
Message-ID: <CAMMESsyfs1+6hJRcMb2EukXTAQrZDkz77toH3XjKsiz+_iMiXw@mail.gmail.com>
To: lsvr@ietf.org
Content-Type: multipart/alternative; boundary="000000000000cb4af0057d63c99e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsvr/x-Are7uDrJJswFQ1Ev1jeRXJacw>
Subject: [Lsvr] Fwd: Error Handling for BGP-LS with Segment Routing
X-BeenThere: lsvr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Link State Vector Routing <lsvr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsvr>, <mailto:lsvr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsvr/>
List-Post: <mailto:lsvr@ietf.org>
List-Help: <mailto:lsvr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsvr>, <mailto:lsvr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 18:00:28 -0000


I sent this message to the idr and spring WGs yesterday.  It was suggested
that this WG should be interested in the topic as well.  I’m hoping that
most of you are also subscribed to the idr list; if possible, please reply
to the original thread:



On December 18, 2018 at 4:09:07 PM, Alvaro Retana (aretana.ietf@gmail.com)

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

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

   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 that...so 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,

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

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




[1] https://mailarchive.ietf.org/arch/msg/idr/FomvQV2DqjaaRiAcLYLn3LcIdYM
[2] https://mailarchive.ietf.org/arch/msg/idr/wbPNQ-HM2NeR75gR2Or948J9o1I