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

Robert Raszuk <> Wed, 19 December 2018 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29BB4130EBB for <>; Wed, 19 Dec 2018 11:27:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mYdFo6pYvFu7 for <>; Wed, 19 Dec 2018 11:27:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3CA5C130EBC for <>; Wed, 19 Dec 2018 11:27:20 -0800 (PST)
Received: by with SMTP id r14so23599807qtp.1 for <>; Wed, 19 Dec 2018 11:27:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sKGxsnJauDxlf5jzT4ZuPPu91ET1Gj4b8szoPGbmUcU=; b=OXZQDsN7FGY+3TSl4swQZj+cqyjmxNksGHomKqQJqS9qnrOcbUUTZ/h17YP7IKNo/U NZ1nL/Um2jSW4HPIRnAtrI198AZcD0OFHictJUz+LtbyXx6bZwv0/KMOES/J9rgzx+m+ WVWHK8SkJNFCXgTcHor6AkNAX7tVRG4EyUIWeF2CRaBn+veQcHp2lhDtM/2GZ0+2/mw9 OT2KaTISeSmaE4YQ/tvRETLsWUjA8rmO+0Rfd2UyGGpGr+AbGCT+t0Xv6+X0ikHkOA3H z1FWLXESNIlJBNH+MEKb60wFZhX+Am9AaSTlSFdY9CfHJFd1HexcCdreU3iHLZBIDP1b Y2iw==
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=sKGxsnJauDxlf5jzT4ZuPPu91ET1Gj4b8szoPGbmUcU=; b=eHAEfS+RENSEgi40dmZq7hcExmi7d1VU4YX8XbwxrOVKmnpgP5a7HtGopAUkfWt3z8 cyCjkTYyTMp/YZzXLs6n3QZrZG4q6Tc+NkNLNVcYGG6J33yIwZwzY2cWcskOu6BG9d1T 7wS5PDpvtHAuXLZaOhLqO0j9hAB6TLKOXRSGdh7bDGWlLKIKmq0lXoF5s5q1Z2sLnpZm 4mUb5375G/blOwNvrz55BXuU3x0QcNKyr6Bmm/BYfPnDLyDffj44mIH1tRxAKcByW3zy MkPvk4QO/wLBNh3vqgqL2nxu6pM2sDau/sVpHHcuTJWdzCZU/7MFJzlfS/AEkr9ruvk7 FD+g==
X-Gm-Message-State: AA+aEWZJhgVCznLFfPYq888+QbBIloJ0d6q7wWA/pg8keR8MKi/JgWZD ZwRoTIHxFZN2i8PsJs6h1Cc8dPJY32B2Fo2iLB3s4A==
X-Google-Smtp-Source: AFSGD/U75toyNWdhvjg4TlPcQ7LDav/xtg2jUtkQWfxx6DHC4T8hJen2GdpDIgIuhjlWi49b3Nonkbe6PiuhlBTEJz0=
X-Received: by 2002:a0c:a144:: with SMTP id d62mr23278281qva.50.1545247639354; Wed, 19 Dec 2018 11:27:19 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Wed, 19 Dec 2018 20:27:10 +0100
Message-ID: <>
To: Alvaro Retana <>
Cc: Robert Raszuk <>, "idr@ietf. org" <>, SPRING WG <>
Content-Type: multipart/alternative; boundary="000000000000a25868057d650099"
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 19:27:23 -0000

Hi Alvaro,

> When BGP-LS was defined, it was noted that the "information present in
> this document carries purely application-level data that has no immediate
> corresponding forwarding state impact..”  I think that SR has a direct
> impact on the forwarding state of the network.  That is what is specific
> about BGP-LS+SR.
Ok let's bring this section you partially quoted:

6.1.1 <>.  Operations

   Existing BGP operational procedures apply.  No new operation
   procedures are defined in this document.  It is noted that the
NLRI*   information present in this document carries purely
   data that has no immediate corresponding forwarding state impact.  As
   such, any churn in reachability information has a different impact
*   than regular BGP updates, which need to change the forwarding state
   for an entire router.  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 way I interpret author's intention above was only to say that if you
experience a BGP-LS churn on any BGP speaker which is used to carry it the
impact will not result in RIB/FIB install - as for such BGP speakers the
carried data is of opaque nature as NLRIs are by definition not to be
processed by BGP subsystem.

To be clear, this thread is about using BGP-LS with applications that have
> an impact on forwarding/route selection in the network, like SR (Bruno
> pointed at lsvr and there may be others).  It is not about about the error
> handling approaches (rfc7606) or BGP sessions in general…just that specific
> application.

Well I think you are mixing the potential impact of BGP speakers which
happen to carry BGP-LS from overall impact to the network which may be
fully or partially derived from content of BGP-LS update messages. To the
best of my knowledge BGP-LS always assumed that carried data will be used
on controllers for something real  :)

I think we all agree that BGP-LS keeps the original promise and its NLRIs
do not interfere with local BGP reachability in the domain. The deployments
may be done not in "anticipated" way of using dedicated RRs but I guess
this was expected from the beginning too.

So now the real bigger question is why one SAFI in BGP would be allowed to
carry forwarding information and other SAFI would not ? Say SAFI 4 defined
in RFC3107 piggybacks labels (clearly forwarding state) as part of IPv4
NLRI. SAFI 128 adds VPN labels (also pretty much forwarding information).
SAFI 71 carries some opaque information which are to be used by
controllers. Yet say BFD SAFI may be used in new ways on RS-ers also to
modify set of paths used in data plane etc ... bottom line is that every
extension we are putting in routing protocols have some impact on
forwarding state in the network be it directly installed by routers, by
controllers, by route servers or even by applications which decided based
on the received info to install new paths to new alternative application
level destinations.

And as always I must say that I would like to see BGP-LS being removed from
BGP4 port 179 and replaced by alternative ways to get IGP information
distributed to controllers, but I just do not see how stated in the subject
of this thread "Error Handling of BGP" could be used as a good reason for

Best wishes,

Thanks for helping me clarify what I mean.  Hopefully this makes more
> sense. ;-)
> Alvaro.
> _______________________________________________
> spring mailing list