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

Alvaro Retana <aretana.ietf@gmail.com> Tue, 08 January 2019 21:15 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 9FB1F12D84D; Tue, 8 Jan 2019 13:15:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, URIBL_BLOCKED=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 L_Hnf6aLSJ2y; Tue, 8 Jan 2019 13:15:18 -0800 (PST)
Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 CE8B2124D68; Tue, 8 Jan 2019 13:15:17 -0800 (PST)
Received: by mail-oi1-x236.google.com with SMTP id y1so4528340oie.12; Tue, 08 Jan 2019 13:15:17 -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=42Wan4WoV9lf+sh9TUbCoqDD+MjzQ0vHy6l3M26FGeo=; b=nV+tCoOY59MZ5kHjhOCSstnK1OlMKbGUAPZ0bgxnVGA0+TF+5DYHal2NL1WKolOkRu NbiRty7EXtN1lsj3a/ubowyfppiVAHbGSB3UI/8FZ6BBnsJc/6YzDGwKFr+d3rvGJhib oWDlWczs6DBNINGK/rOdlLhrUM9CKIcQbe74GU+mJpJSL3PP2Ii7Yp8zHJvaquWjMoKb xE0viqiv2qEdVAhfzaSeYhbxkcUSls3KMHlHopGeQaWRw/niNUCy+g9JZA9SUzM9I63Y uhPWWhgU58Ns9TAfKuDp+YoNLCDoks6Uyf3d+lycjV5Wt4wZ8qN7Afts1F+Vk+rNrWMk r0CQ==
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=42Wan4WoV9lf+sh9TUbCoqDD+MjzQ0vHy6l3M26FGeo=; b=HmX9LwKX2/+5+jf3gW70dW3LL7xWmp50c/EdOZtUIK7NNb1N4IaJ2oideiFaCHZ51J ++LAzU+In8NOZby+9o6FS5ElAcAQfGVUtcb799rDucifIyyxJlKmBN+yPai25LoM+fSD JJhNrVyy6uTzNdyxdNhoAEqwqS4q42V+bzMU1Gi0ni0t5yabdWGCPcuGRvPzygZClebD QiE2BTFnCZ8uA7/ct7MqP+l62tBQHS3DvMGZb+JWjYju4tL+53TDF9f3JcUuDXjmaBz+ 4yk8Iu8WN19aWSDBP4+ggYAqTgJYqo9dafRc3pUcokMy2tdtvLfNCwWVzdlUazwX1ola CAuQ==
X-Gm-Message-State: AJcUukc1q2aCKAUhUFpLnX9RcBeGVJ9SKJS5PzMs/tlGGuHXi23w9WyR Cgiinc1qxfOM19THEkjcZV/NCIg/kdkfygdJwwk=
X-Google-Smtp-Source: ALg8bN5si1LIuXbbYjbSnjH5DsOK8TfnrU8LCS+yB6PZ5cL6BEip4pMjubb/ku0rvN2MGiJmopOSVZEuguC6MmJFQYU=
X-Received: by 2002:aca:3cc5:: with SMTP id j188mr2241338oia.278.1546982117070; Tue, 08 Jan 2019 13:15:17 -0800 (PST)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 8 Jan 2019 13:15:16 -0800
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <1830_1546958029_5C34B4CD_1830_110_1_53C29892C857584299CBF5D05346208A4898A07A@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
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> <CAMMESsxQhNtW4GEvucv6A2Sh2=_sxm9wigRax+9Gj3C7caBV5A@mail.gmail.com> <CAHd-QWskekEA1HrJbAGnwPrv8b2+jy12qg9iazmn4kXDgsN15Q@mail.gmail.com> <1830_1546958029_5C34B4CD_1830_110_1_53C29892C857584299CBF5D05346208A4898A07A@OPEXCAUBM43.corporate.adroot.infra.ftgroup>
MIME-Version: 1.0
Date: Tue, 8 Jan 2019 13:15:16 -0800
Message-ID: <CAMMESsxN0MttLnB17Oqs0De=9UvGgOY3sz9ET-bUA=A2ZjyLOA@mail.gmail.com>
To: bruno.decraene@orange.com
Cc: Robert Raszuk <rraszuk@gmail.com>, "idr@ietf. org" <idr@ietf.org>, SPRING WG <spring@ietf.org>, Rob Shakir <robjs=40google.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008fdd09057ef8d7ec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/857Nv7YBGJWzfycLLyfoIezmBNA>
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: Tue, 08 Jan 2019 21:15:20 -0000

On January 8, 2019 at 9:33:49 AM, bruno.decraene@orange.com (
bruno.decraene@orange.com) wrote:

Bruno:

Hi!

...

But I’m wondering why error handling is that specific to BGP-LS.

It is just in this thread...

Why is that point not been raised on, let’s say,
draft-ietf-ospf-ospfv3-segment-routing-extensions which is currently under
IESG review? I can see that the specific are (a bit) different, but the big
picture seems the same: the information is incomplete, how do we handle
this?

[AD Note:  draft-ietf-ospf-ospfv3-segment-routing-extensions is pending a
new revision to clear an outstanding DISCUSS.  If you (or anyone) has
specific issues about this document, please let me know as I’m ready to
approve the publication.]

I didn’t specifically raise the question of error handling for BGP-LS with
SR against the current document I’m reviewing
(draft-ietf-idr-bgp-ls-segment-routing-ext) because I don’t think the
solution explicitly belongs there…so I started the discussion on the
idr/spring lists.  If there are issues with the OSPFv3 transport then the
solution probably doesn’t belong in the extensions draft.

[This part of the discussion belongs on a different list…] I think that the
link state protocols have different characteristics (than BGP-LS) when it
comes to try to ensure common information between the nodes: reliability at
the LSA/LSP level, db synchronization, etc..  That difference brought me to
not bring up the question of incomplete information when I was reviewing
the SR extension drafts.  I may of course be missing an important piece.
If this point needs to be discussed, we should move to lsr.

Then, I’m not sure that the problem is specific/limited to SR/SID
information.

Right.

I think it’s easier to discuss specific problems first and then
generalize…than start with the general problem.  That is one of the reasons
for this thread.  In the specific case of BGP-LS, rfc7752 makes assumptions
about  about the nature of the information, which I think are broken with
SR…. I think there’s an SR-specific issue that needs to be addressed
somewhere.

As you mentioned before, other applications, like lsvr, could have the same
issues.

Thanks!

Alvaro.