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) <[email protected]> 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:* [email protected] [mailto:[email protected]] *On Behalf Of *Robert > Raszuk > *Sent:* Friday, April 21, 2017 3:30 PM > *To:* Kausik Majumdar (kmajumda) <[email protected]> > *Cc:* [email protected]; Krishna Deevi (kdeevi) <[email protected]> > *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) < > [email protected]> 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: [email protected] [mailto:[email protected]] > Sent: Friday, April 21, 2017 12:35 PM > To: Kausik Majumdar (kmajumda) <[email protected]>; Krishna Deevi > (kdeevi) <[email protected]>; Krishna Deevi (kdeevi) <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/spring > > >
_______________________________________________ spring mailing list [email protected] https://www.ietf.org/mailman/listinfo/spring
