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

Alvaro Retana <aretana.ietf@gmail.com> Thu, 03 January 2019 21:40 UTC

Return-Path: <aretana.ietf@gmail.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45002130F89; Thu, 3 Jan 2019 13:40:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7cixufxrMLA; Thu, 3 Jan 2019 13:40:14 -0800 (PST)
Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 6F559130FB7; Thu, 3 Jan 2019 13:40:14 -0800 (PST)
Received: by mail-oi1-x232.google.com with SMTP id a77so28869096oii.5; Thu, 03 Jan 2019 13:40:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yPuNzYH8p61/ogrG5s7LiF/ROi7XjG7lzAPBFBWSEZ4=; b=tGS9B6JhUt0Qw3riL2hdFtWpqgXedBQ1ifI/rzNW5Zie6z5JTpHcH2xqEij9XVZdR7 F5SMxSXqPS94oWpIdqV6Git4y6vSG+tmI9zcXd10KxUFUE6eW884JtuuritmKafxqIN3 w4cXTqXi2c7hpQAt9ftMWm1ynBflT1dRJhEthP727vLF68np5Q1hFYX3zmnhykhWy1zD /IY10dtYvp4CrM4RRnxz5TMp20fvHSFPMTpx+edIqYU78/Icoy+6QFmOQ6adMsyjsJSr ecKosGNTU6MBNOEdZOKOVV7Jj9L/aWxgFZC9rtFJAsM0I27WJbNnpcrZPaMjF+H7v1ha XXew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yPuNzYH8p61/ogrG5s7LiF/ROi7XjG7lzAPBFBWSEZ4=; b=tgl5/uM/auMfgbXJqyxZ/TOQV89+SLBqfC1k/FtZcxpK6ioaIzaKNvXrek7mv/vBhc rPZO6QGPOnlIAv3caYOO/JfyFZoWJ5bomMZqBIjAk39O7Qiil34QpSmhAWOEOnfjPW4B td/NtXj0kxI9YPfko2yfojRsKvXdrJAz37oK4+nht/Y83ZM0opyEZfX32AQVFsYLlpMX lgm6uX+1Lo5zOKzm9L2sul4XgKGSErsrwnS2pXsoI1AYasEh/gifUmIUod5HLmJt10lv xw7hrztxsgpETsmp+1o54Eg9bcx77QwHQL18yngEBNHQ1/mbSKLowl5LnnRUMF7xIb32 Tq8g==
X-Gm-Message-State: AA+aEWZSQtO4VxgLXeDH8VHMD7olVQdcLBgNqhNfxvKHNaQXNHjb12FE YQ7eCtbMh6FUyGOiw73WdN1VSUgDBOWw4qgswL4=
X-Google-Smtp-Source: AFSGD/X76uU1EyO0bsrHYjWwiJwlUoEpTlj/wd1WpGnK0izf+e6PtcZ/d+O+U26g9BHMxmUmheh4FLbJf+CXs4U9k48=
X-Received: by 2002:aca:3cc5:: with SMTP id j188mr34040499oia.278.1546551613665; Thu, 03 Jan 2019 13:40:13 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 3 Jan 2019 13:40:13 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <CAHd-QWu8RjwnwJ8LXWpjTmY=VHA4PwZt=uP+H5M4AnKQVBeG7w@mail.gmail.com>
References: <CAMMESsz8Z_B1aH-4wYL-V9cV=5Xse+tpKqXFish6+V+td7KKzw@mail.gmail.com> <CA+b+ERmic4UXsuWW08SKOH_hwhC5pA+o-J1pHOoT8n2LGJHUng@mail.gmail.com> <CAMMESszxvEFTdsdCS6yEM=Yi6iy=gnrOqWbD07wFTedY90hLkA@mail.gmail.com> <CAHd-QWu8RjwnwJ8LXWpjTmY=VHA4PwZt=uP+H5M4AnKQVBeG7w@mail.gmail.com>
MIME-Version: 1.0
Date: Thu, 3 Jan 2019 13:40:13 -0800
Message-ID: <CAMMESsxQhNtW4GEvucv6A2Sh2=_sxm9wigRax+9Gj3C7caBV5A@mail.gmail.com>
To: Rob Shakir <robjs@google.com>
Cc: SPRING WG <spring@ietf.org>, Robert Raszuk <rraszuk@gmail.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008f3614057e949b9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YSUiy78kMMJs-NgwJNQs4pKpImY>
Subject: Re: [Idr] [spring] Error Handling for BGP-LS with Segment Routing
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jan 2019 21:40:17 -0000

Rob:

Hi!

I don’t think I said it before:  speaking as a WG participant...

I want to pick up on a point you make below, which I agree with: "any
topology discovery mechanism (whether used in real-time or not) needs to
define how it handles cases where it might end up with missing
information”….

BGP-LS only defines a mechanism through which it may miss information, but
not how to handle it — or maybe it does (?): by using attribute discard it
just accepts that the information might be missing going forward…and
doesn’t attempt to do anything.  Maybe this quote is true: "Doing Nothing
Often Leads to the Very Best Something” — Winnie the Pooh

That action may be ok in the general case…but I think that doing nothing
may not be enough/appropriate for an application like SR, because it is
explicitly calculating paths….


The point I’m trying to bring up is not necessarily treat-as-withdraw vs.
attribute discard…. But, first, is attribute discard
enough/appropriate/good for a BGP-LS application such as SR?  If it isn’t,
second, is there a different approach that would be better?  Maybe we then
come to a point where something can change…or accept the limitations of the
system and be clear about them.  I fully realize that I may be the only one
who thinks there’s an issue…

Thanks!!

Alvaro.


On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote:

Alvaro,

I think this is one of the difficulties of overloading a protocol like BGP
with different datasets -- it's not simple to say how particular attributes
are actually going to be used within a protocol deployment. This was one of
the things that was noted in 7606 -- i.e., I can make *any* attribute
really affect forwarding if I write a policy that accepts/rejects some
UPDATE based on the presence of that attribute.

In general, any topology discovery mechanism (whether used in real-time or
not) needs to define how it handles cases where it might end up with
missing information. Let's consider what the different mechanisms for
discovery we have are today:

   - IGP listening -- in this case, if we have some malformed IS-IS TLV,
   then we might end up discarding this information (whether it be at the
   listening node, or a device that didn't flood it earlier in the chain) --
   meaning that we know that we have some potential gap in the topology.
   - Streaming telemetry -- speaking particularly to gNMI for LSDB
   streaming encoded using the OpenConfig model, here, we are tolerant to
   getting as much information as can be parsed, and have a way to carry
   unknown TLVs (which might include those that cannot be successfully parsed)
   as binary data to the external consumer. This means that the approach is
   "as complete data as possible", but has the same characteristic that we can
   also end up having the potential to lose data.
   - BGP-LS with attribute discard -- this has some information loss, since
   we'll have some attributes that could be malformed in the input data, and
   we discard them at the receiver.

It doesn't seem to me that, given the source of the data is the IGP, and we
might have information discarded there -- that we can really guarantee
strong consistency of an off-box view of the network, since we can't
guarantee strong consistency across the IGP domain itself.

Thus, I'm not sure that the issue that is being highlighted here actually
makes a difference when we're considering the overall system design -- we
always need to deal with the fact that the view of the network at the path
computing node might not match exactly the network's current state in the
presence of malformed protocol messages. One motivation for having the LSDB
via streaming telemetry is the ability to provide such validation ("do all
nodes within my IGP domain, including listeners, have a consistent view of
the state of the network?").

If the discussion is "should we adopt treat-as-withdraw vs. attribute
discard?" -- I don't think that from the system perspective there is really
any difference between the two in this situation. We still have the same
potentially inconsistent view of the network.

For these reasons, I'd err on leaving this unchanged in the current
specification(s).

Cheers,
r.