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

[Robert Raszuk <[e-mail]>]

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