Subject: questions on INFORM draft

From: "George Sheng" <[email-masked]>
Date: Thu, 15 Aug 2002 21:20:32 +0000

I'm not familiar with implementation side, not sure how
complicated it can be done. By reading this
draft-nalawade-bgp-inform-00.txt draft, it seems to me that it
only serves some logging capability to bgp remove peers, or do i
miss something? from operational point of view, if this bgp
side receives a INFORM message, what do I suppose to do besides
logging? if this bgp needs to do something, then it seems the
implementation will be very complicated. E.g. this bgp sent to
it's peer something really wrong, I doubt this INFORM will bring
this bgp process back to conscious. Do we have concrete examples
from the operations saying people want this? just curious.
It seems to me that if this router sends too many routes to
the peer(an easy example used by the draft), after receiving the
INFORM, should this router just send less routes? but how, which
routes should this bgp drop? If this is only for logging, then
why its particular to bgp?

george

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: [email-masked]
Date: Thu, 15 Aug 2002 14:43:39 -0700

I think it is important to note, that the INFORM message is NOT 
in place to cause the remote router to undertake an automated protocol
action.  It is in place to faciliate communitcation, and capture 
significant information.

Perhaps I can elaborate a little on the example that the authors present
in the draft.  In the current Internet, operators often implement a router
feature where there is a hard cap to the number of routes that they
will accept from any given peer.  Currently, when that cap is reached,
the session is dropped with no indication that it has been dropped.
This inevitably results in a ticket being opened, nocs being contacted,
all of which take time.  In the meantime the session between the two
networks is down, which causes BGP to reconverge, and results in 
possibly sub-optimal routing between the two networks.  (There is
a draft currently to expand the NOTIFY space to allow the remote
peer to know why the session went down, which is a very good thing,
but it doesn't have the ability to prevent the situation.).

With the INFORM message, an operator could, for example, set a
soft cap and a hard cap on the number of sessions that they will
accept from a peer.  When the soft cap is reached, the router
sends an INFORM to it's peer.  The remote router now knows
that it is getting close to the limit, and can log the message.
The log can then be picked up by the other network's monitoring system
and action can be taken on the part of the remote NOC.  In most
cases they will call their peer's NOC and work out a raise in the
cap, if normal route growth is causing the problem.  Under this
set of events, the peering session never has to go down.

Could you completely recreate INFORM's functionality with perfect
monitoring and inter-noc communication?  Probably.  Does that
degree of efficent communication always happen in real backbones?
Unfortuntely, not often enough.

Andrew

On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> Delivered-To: [email-masked]
> X-Originating-IP: [155.53.36.107]
> From: "George Sheng" <[email-masked]>
> To: [email-masked]
> Subject: questions on INFORM draft
> Date: Thu, 15 Aug 2002 21:20:32 +0000
> X-OriginalArrivalTime: 15 Aug 2002 21:20:32.0998 (UTC) FILETIME=[96C91860:01C244A1]
> Precedence: bulk
>

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 15 Aug 2002 17:48:06 -0400

On Thu, Aug 15, 2002 at 09:20:32PM +0000, George Sheng wrote:
> If this is only for logging, then

Not speaking for the INFORM authors, the general idea is to
allow a remote BGP speaker to send O&M type information to you.

Thus, its a "I've done this, you *might* want to know about it."

-- 
Jeff Haas 
NextHop Technologies

---

From: Igor Lasic <[email-masked]>
Date: Thu, 15 Aug 2002 18:03:27 -0400

Typically this type of notifications are better served via SNMP
  traps. Every NOC relies heavily on trap processing to be able to
  determine issues in the network. (NOC - Network ops center) 

  Why not define more BGP traps instead of coming up with a completely
  new mechanism ? There will have be a mechanism to notify the NOC
  about this condidtions anyway (on both peers.) 

  Igor

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 16 Aug 2002 12:06:47 -0400

>   about this condidtions anyway (on both peers.)

More traps would be fine, but would not address the same problem. 
Consider that in order to get the same functionality using traps, for 
each session which you might otherwise send an INFORM over, you must 
have (at least) the NMS address at the NOC which is responsible for 
the peer associated with the session.  This is bad enough from an 
operational scalability perspective, but when you consider that it's 
not unusual to impose various types of packet filtering on SNMP 
traffic from beyond your network's border, it's even worse.

With INFORM if NOC B wants to receive a trap when network A's router 
has a problem, the SNMP part remains with in network B.  The path 
looks like router A --INFORM--> router B --trap--> NOC B.  This 
avoids both the operational and filtering issues.  While not perfect 
INFORM is at least operationally scalable and implementable.

Regards,

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Aug 2002 12:31:58 -0400

On Thu, Aug 15, 2002 at 06:03:27PM -0400, Igor Lasic wrote:
>   new mechanism ?

As is mentioned later, this is an issue of causing traps to show
up on the OTHER router.

As to local traps, please feel free to make suggestions.  The v2mib
has room for more.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Aug 2002 12:57:49 -0400

I have specific issues with some of the events of the INFORM
message - specifically the idea of "fixing" broken packets.
Lets ignore that for the moment.

> INFORM is at least operationally scalable and implementable.

Providing a pushback mechanism to allow O&M information relevant
to the remote peering session is a good idea.

The trick is, are we providing the right information using INFORM?

The events that we have currently enumerate involve:
o Bad packets, fixing or discarding attributes.
o Too many routes (useful!)
o Attribute overflow (useful!)
o Dampening 

The data types that we can return in the PDU are:
o Unspecified 
o String
o PDU
o Attribute
o Integer (suggested name change, Integer32)

For bad packets or attributes, the above provides enough information
for a human looking at the message to know that something bad
has happened and give you a pretty good idea what it is.  Taking
this information and passing it back to the NMS is far trickier,
especially if we're talking SNMP.

For example, if we INFORM on a AS Path that we are noting has changed,
(non-prefixed confederation segments, for example), the NMS could
receive a trap from the BGP MIB that has the path attribute ID and
a generic OCTET STRING showing what was the item that was being complained
about.  The "error" string is far more useful here.

It is very unlikely that enough information will fit in the SNMP Trap
to make it back to the NMS, SNMP being what it is.  We need to find a
way to be concise.

Additionally, NMSs must have the ability to apply some amount of
programmatic logic to collect the information and provide useful
summarizations.  Something a human can read wont scale as nicely
as signalling a particular enumerated event.  A very good example
of this is the "too many prefixes" soft and hard limits.  This
would make for very nice events that are concise enough to fit
into a TRAP.

To summarize, INFORM is currently structured as a useful way to
"bring things to the attention of the router's operator".  However,
it is currently structured in such a way that its more useful as a
syslog/dump.  In order to make things fit in better with current O&M
practices, we would need to find a way to make things more concise
so we could use SNMP TRAPs or similar mechanisms.

Any suggestions from the authors?

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Fri, 16 Aug 2002 17:13:55 -0400 (EDT)

> Lets ignore that for the moment.

Well, INFORM isn't actually suggesting that anyone fix bad
packets, just providing a way to tell someone if you do. That
might be considered encouraging someone to do so, but I wouldn't
consider it telling someone to actually do it. :-)

> It is very unlikely that enough information will fit in the
> SNMP Trap to make it back to the NMS, SNMP being what it is.  
> We need to find a way to be concise.

Couldn't "INFORM TRAPS" be created to provide the right
information back to NMS'?

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Aug 2002 17:50:56 -0400

> information back to NMS'?

MIBs are cleanest to implement when the events are enumerated.
The fact that many of these events are vendor and implementation
version number specific adds the usual awkwardness.

Since the problem is one of enumeration, perhaps a spot can be
set aside in the BGP MIB for the generic INFORM events.  Similarly
a spot can be set aside in the MIB for vendor specific events
with the vendor creating the relevant MIB events.  The base
OID of the trap could be sent as a new type in INFORM and
convention could require that the descriptive text is required
as part of the text.

So, this is a possibility and would address one of the issues.

Note that this would require the vendor to indicate in the INFORM
sufficient information to say what their vendor ID (likely, the
SNMP enterprise number) is for their implementation.  This *might*
be information that a customer may not want to disclose.

Its either that, or create a global registry of all fixup events.

-- 
Jeff Haas 
NextHop Technologies