Subject: Re: [Idr] draft-scholl-idr-advisory-00

From: David Freedman <[email-masked]>
Date: Wed, 01 Apr 2009 14:28:03 +0100

So it seems to me , we have a number of differing views here.

Scholl recommends we have an unstructured payload, scoped by some
general "types" (I think this is in the -01 version, tom?), length will
be variable.

Nalawade originally recommends we have a structured payload but with the
capability to send an undefined string (see
draft-nalawade-bgp-inform-02, sec 6.1.1), this string can be of variable
length as well

Nalawade then recommends that the payload not include the freedom to
send an unspecified message (closest I could find was CEASE "5 - Other
Configuration Change" , see  draft-nalawade-bgp-soft-notify-01 sec 2.3)

Since a number of purists on here are not happy with the protocol being
"cluttered" by unspecified messages, a "middle of the road" approach
sounds like a structured payload with the ability to send an unspecified
message (without having to hide the fact), this could then be an
implementation decision.

An easy way to do this would be to place the ADVISORY payloads into
soft-notify "Event Message subcodes" (sec 2.3), they would fit quite
nicely here.

So I present the two alternatives as either

- Choose ADVISORY and don't bother with structured payloads

or

- Choose SOFT-NOTIFY and ammend it to suit the purposes of ADVISORY

Both of these cases would satisfy the operator community I believe
(please, somebody correct me if I'm wrong)

Do people concur?

Dave.

---

From: Rob Shakir <[email-masked]>
Date: Thu, 2 Apr 2009 16:08:10 +0100

> (please, somebody correct me if I'm wrong)

Dave,

Thanks for this summary.

I think the major point here, from my point of view  is that we need some way to
be able to deliver a non-fatal message to our peer, to be able to react to some
anomaly, or transmit some further information in-band. I agree that a
soft-notify with some advisory-esque enhancements would deliver this, as would
Tom's draft.

As you say, either is an enhancement to the protocol. I can see both pros and
cons of the additional structure that INFORM brings, but this can also be said
for the flexibility that ADVISORY would bring. I don't have any strong
preference between the two drafts.

I think the worst case here is that we end up with neither INFORM nor ADVISORY,
and end up with two drafts that would have enhanced the operation of the
protocol being rejected.

Although there are quite a few operators commenting on this thread -- it's a
shame we're not more vocal :-)

Kind regards,
Rob

-- 
Rob Shakir                      <[email-masked]>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 04 Apr 2009 09:03:10 -0700

All,

So to change this thread into something which may perhaps result in a 
solution I have tried below to summarize so far received requirements 
from providers as well as so far proposed alternatives.

Please correct/add as appropriate. I have also tried in a neutral way to 
express the current state of conclusion ...

**

1. Is the additional channel of communication to be used as a reactive 
or a proactive tool ?

A -> I think there is clear consensus between all of us that it may work 
well as a reactive tool for getting more information about events which 
have happened. Example: ISP A before controlled session drop or reset 
injects some free form text informing about it which in turn on the 
other side of EBGP session would be displayed at show command.

B -> I think there is a lot of hesitation on how this tool may be used 
pro-actively. At least most of my own comments were from coming from 
this aspect of discussed functionality. The issue is that if those 
messages need to be promptly seen by NOC of given ISP they better get 
there by filtered syslog notifications. Is BGP the write tool to be used 
as a carrier for syslog messages ?

**

2. What is the appropriate size of the free form text msg ? Or to put 
the question the other way what would be sufficient minimum size of the 
message to still serve the purpose ? Or should the max length be at all 
hardcoded ?

-> I don't think there was any consensus reached on this so far.

**

3. What example of messages should be targeted to be send:

  -> notifications about planned router/session outages
  -> reached threasholds of max-prefix
  -> route dampening notifications
  -> policy failing/uRPF hint that you are a DoS src
  -> ...

**

4. How do we plan to accomplish selective reception of such messages ?

-> Do we need new BGP inbound policy paragraphs entries mixed with BGP 
routing policy entries ?

====

Proposed alternatives:

Group of solutions to send more verbal but predefined messages:
---------------------------------------------------------------

* Use INFORM spec instead with all potential warnings listed.
   http://tools.ietf.org/html/draft-nalawade-bgp-inform-02

* Use BGP SOFT-NOTIFY
   http://tools.ietf.org/html/draft-nalawade-bgp-soft-notify-01

Group of solutions to send free form text in band:
--------------------------------------------------

* Use one of the INFORM messages as fee for text (functionally would be 
the the same as new BGP message)

* Maybe the right way to approach this is to add soft notifications, 
define a slew of message types that make sense for all the normal 
conditions that can be thought of, and just add a message type for 
free-form text as well.

Group of solutions to send free form text out of band:
------------------------------------------------------

* Provide ability to auto-negotiate by new bgp capability the current 
and valid email dst for NOC/ADMIN etc ... Those could be used to 
automatically generate warnings from the routers or from the humans 
which would end up simultaneously on peer's syslogs, NOC screens or 
admin cell phones etc ...

* Use syslog to syslog communication channel between providers.

* Use the same as defined in the draft new BGP ADVISORY msg, use 
BGP-light (tcp session and single message) to carry it between routers, 
auto feed it to peer's syslog, but make sure it is carried over 
independent BGP sessions including using different tcp port number as 
compared with routing information. Perhaps as such it could go beyond 
just one router ...

Cheers,
R.