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>; Krishna Deevi > (kdeevi) <kdeevi@cisco.com>; 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 > > >
- Re: [Idr] [spring] FW: New Version Notification f… Robert Raszuk