Re: [Idr] [spring] FW: New Version Notification for draft-deevimajumdar-spring-bgp-feedback-00.txt

Robert Raszuk <robert@raszuk.net> Sat, 22 April 2017 07:13 UTC

Return-Path: <rraszuk@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 98884128BB7; Sat, 22 Apr 2017 00:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 Job41BwZXxxH; Sat, 22 Apr 2017 00:13:10 -0700 (PDT)
Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 959EE126DED; Sat, 22 Apr 2017 00:13:10 -0700 (PDT)
Received: by mail-it0-x230.google.com with SMTP id g66so9814591ite.1; Sat, 22 Apr 2017 00:13:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JXQzu9XvmEa6Z+M1jdIKfLOmfppdcTbkrzWjGZ99dVg=; b=kgcBd65kNWMVj+C8nFjHv//T+RB9j1XxBND/sJM58hX6C4qthVz1UsAiGAtJtdnURV 6i5Wlw+dK6PCMTSen16u2pJ4OROHBJ5BHn/Syd7mgvZ801rI94rvHeXHKe8zEu8xvRDt 4ut6PtnS3fY2z5BErBKYvy4E7cGH4ovl0kkLu3vTJVJRrMV5WLKHQay/ZdqplA7PEdDf EWqo6hnIz5VvORxlUdALV6rGJ20lU63e1y0rHxXTePa1YIP40emwoKuipCfc+DxJNYpp PbVfS4lc5lgbFiZKy4jRRPwWZUt62LVw9bUoUN7aDnI7c4kC4LgOTOuEXcBfYIBuAaYe zyDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JXQzu9XvmEa6Z+M1jdIKfLOmfppdcTbkrzWjGZ99dVg=; b=e515wENv3UFujnFiBoYfny/BM0/gRg4sp3iyCpS8IL5Uxri4otVz3XrFFI+WF/qt3I GncfILjoJXVZ6mHQNzU8svlR4HU/M3sBq1aHFxvqVJ8hyFlO5t09Gp8/clEXFisjf0pc N5DSRzAXEMsY1WSl8VMKOsQSwR7XzOvrIElBr5p+zHKzUr6F7ZF12swbzdhYlE4teb+3 U/rw0hWVbEH1GbNEHiaWb17t7omWLbHsBloBVWjFy6++R50nmcImfrl//03Uogu4Lrfy O4iUX8FqhqGvpdOVbxmM9w6YqZFoH1sHOlXRCM6/HQ9WLBAF6PP9JpMCF8tV044HwoTJ Iqrw==
X-Gm-Message-State: AN3rC/72MCfqyHbKfoltXJ5alZR8ZqBi35ec2bcV5VCFL0cxW89mjdY8 8KsAHNbWG/VR0wmxIXIMFZIy+bseC0ZnCg8=
X-Received: by 10.36.219.195 with SMTP id c186mr2697620itg.25.1492845189854; Sat, 22 Apr 2017 00:13:09 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.79.170.4 with HTTP; Sat, 22 Apr 2017 00:13:09 -0700 (PDT)
In-Reply-To: <5679a32841c94228bb210e63948682b2@XCH-RTP-001.cisco.com>
References: <149280328448.6973.7420894007746674977.idtracker@ietfa.amsl.com> <91fa537fc336407d8958f816e8d38502@XCH-RTP-001.cisco.com> <CA+b+ERkCp8qkOrobCWu93pMUOkZV1kHudo0UHr0jRkQG6HrHPg@mail.gmail.com> <5679a32841c94228bb210e63948682b2@XCH-RTP-001.cisco.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Sat, 22 Apr 2017 09:13:09 +0200
X-Google-Sender-Auth: 3kHTd0KynqBPqSyy2Pyye4CadpM
Message-ID: <CA+b+ER=66C_61vrXCpFhOXtjx15bgrsA1TWJHpkbHu=Fkr_5yQ@mail.gmail.com>
To: "Kausik Majumdar (kmajumda)" <kmajumda@cisco.com>, "Krishna Deevi (kdeevi)" <kdeevi@cisco.com>
Cc: "spring@ietf.org" <spring@ietf.org>, idr wg <idr@ietf.org>
Content-Type: multipart/alternative; boundary=001a114f5cce3f028a054dbc1b29
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/VnjGHIajImaQF-Y07MSU5eC8OG0>
Subject: Re: [Idr] [spring] FW: New Version Notification for draft-deevimajumdar-spring-bgp-feedback-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 22 Apr 2017 07:13:13 -0000

Hello Kausik & Krishna,

Let me provide few additional comments below regarding your draft.

1. Your draft defines a new BGP message so irrespective on what this new
message is to carry this is within IDR charter not SPRING. Adding IDR WG to
this discussion and I do recommend you rename your draft and repost
accordingly to IETF rules.

2. draft-ietf-idr-operational-message-00 is in expired state but please
keep in mind that it was accepted as IDR WG document. As no money were
behind to implement it by major vendors we stopped refreshing it. However
the objective of former work draft-ietf-idr-advisory as well as
draft-raszuk-bgp-diagnostic-message which after number of discussions in
IDR were both merged into the above operational message document. Note also
that the common goal of all of the above was to provide feedback to eBGP
peers on various BGP propagated data and its state on the receving BGP
speaker.

You state:

"The BGP Feedback message would be a generic purpose message and could

be used for any cases within BGP by defining the required new TLVs

under this message."


This is precisely what BGP OPERATIONAL MESSAGE also defines.


3. You state in your draft that the point of the proposal is to convey the
feedback information to the originator of the message. With that I have
following concerns:

*A*

All information you are proposing to add should already be logged to syslog
and since SR deployments are usually under same administrative umbrella
they can be easily retrieved from it. So effectively you are now defining
new BGP message to carry filtered syslog events in BGP. And while
questionable I am ok with it.

What I am not ok with is that BGP propagates information in p2mp fashion.
It has no provision for p2p messaging even if recently number of attempts
has been made to stretch it that way. So effectively while only originator
of the colliding information needs to get the feedback such feedback will
be propagated to *every bgp speaker* in the AS and beyond the AS (Internet
wide) if new BGP capability has been negotiated with the peer. The draft
even does not bring any form of protection on the intended recipient of the
message and propagation scope. Contrary all it says to define the
propagation rules is this:

   To achieve this a new BGP message type called BGP "Feedback Message"
   is defined in this draft.  The Feedback message type is to provide
   the feedback to the BGP peers.  It would be processed hop by hop like
   update message.


*B*


While I am not questioning use case I do not see that the current
proposal is the right transport for

it. What you need for iBGP side is pub/sub message bus to get syslog
notifications to selected

nodes. For eBGP (when SRv6 goes beying single administrative boundary)
use of Operational

message is something you may reconsider.


*C*


If you however still would like to continue using new message and load
BGP to carry filtered syslog

or effectively selected telemetry data I would recommend to instead
current propagation proposal of

"hop by hop like update message" make it to travel over targeted short
lived TCP sessions directly

between notifier and originator of the information you are proposing
to carry. Is this a good idea to still

call it BGP .. maybe yes .. maybe no. But this is what you really need
here rather then going back

via RRs and hitting 100s of routers which would have to parse new
message only to ignore it and

propagate further. How far .. as indicated above it is currently undefined.


Kind regards,

Robert.



On Sat, Apr 22, 2017 at 2:57 AM, Kausik Majumdar (kmajumda)
<kmajumda@cisco.com> wrote:


>
> Hello Robert,
>
>
>
> Thanks for providing the pointer on the BGP Operation Message Draft. We
> looked through it. In this draft, Operational message is defined to carry
> different types of Operational TLVs like: ADVISE, STATE, DUMP and CONTROL
> and trying to provide network operational data between the BGP nodes.
>
>
>
> The draft we proposed has a different purpose. It doesn’t exchange BGP
> operational data between the BGP nodes. Rather it defines on how to send
> BGP feedback information for a prefix to notify the network inconsistency
> to the BGP originator. The current use cases are in the BGP Segment Routing
> application as described in the draft.
>
>
>
> Thanks & regards
>
>
>
> *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Robert
> Raszuk
> *Sent:* Friday, April 21, 2017 3:30 PM
> *To:* Kausik Majumdar (kmajumda) <kmajumda@cisco.com>
> *Cc:* spring@ietf.org; Krishna Deevi (kdeevi) <kdeevi@cisco.com>
> *Subject:* Re: [spring] FW: New Version Notification for
> draft-deevimajumdar-spring-bgp-feedback-00.txt
>
>
>
> Hello Kausik,
>
>
>
> Are you aware about similar attempts in the past ?
>
>
>
> For starter can you elaborate if you conisdered to just add SR related
> information to BGP Operational Message as defined before in
> https://tools.ietf.org/html/draft-ietf-idr-operational-message-00 ?
>
>
>
> Kind regards,
>
> Dave, Robert & Rob.
>
>
>
>
>
> On Sat, Apr 22, 2017 at 12:02 AM, Kausik Majumdar (kmajumda) <
> kmajumda@cisco.com> wrote:
>
> Hi,
>
> We have submitted the below draft "draft-deevimajumdar-spring-bgp-feedback"
> to describe the framework for BGP Feedback message in Segment Routing to
> notify the inconsistency in the network. Please review and provide valuable
> feedback.
>
> Regards
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: Friday, April 21, 2017 12:35 PM
> To: Kausik Majumdar (kmajumda) <kmajumda@cisco.com>om>; Krishna Deevi
> (kdeevi) <kdeevi@cisco.com>om>; Krishna Deevi (kdeevi) <kdeevi@cisco.com>
> Subject: New Version Notification for draft-deevimajumdar-spring-
> bgp-feedback-00.txt
>
>
> A new version of I-D, draft-deevimajumdar-spring-bgp-feedback-00.txt
> has been successfully submitted by Kausik Majumdar and posted to the IETF
> repository.
>
> Name:           draft-deevimajumdar-spring-bgp-feedback
> Revision:       00
> Title:          A Framework for BGP Feedback Message In Segment Routing
> Document date:  2017-04-21
> Group:          Individual Submission
> Pages:          12
> URL:            https://www.ietf.org/internet-drafts/draft-deevimajumdar-
> spring-bgp-feedback-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-deevimajumdar-
> spring-bgp-feedback/
> Htmlized:       https://tools.ietf.org/html/draft-deevimajumdar-spring-
> bgp-feedback-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-deevimajumdar-
> spring-bgp-feedback-00
>
>
> Abstract:
>    In support of Segment Routing(SR), routing protocols advertise a
>    variety of identifiers used to define the segments that direct packet
>    forwarding.
>
>    In cases where the information advertised by a given protocol
>    instance is either internally inconsistent or conflicts with
>    advertisements from another protocol instance a means of notifying
>    the originator about the inconsistency is required.  This document
>    defines a generic mechanism to notify the BGP originator about the
>    inconsistency in the network.
>
>
>
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.ietf.org/mailman/listinfo/spring
>
>
>