Subject: Re: questions on INFORM draft

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

Andrew,

>From: [email-masked]
>To: George Sheng <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: questions on INFORM draft
>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.

basically you are saying it's a inter-noc remote-logging
facility.

>
>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.

your example makes some sense. but I am wondering what will be
the gap beteen the soft and hard lines? 100 routes, 1000 routes?
If the gap is too big, you will always hit the soft and never
hit the hard, thus causing two NOCs constantly chatting whethers.
If the gap is too small, then One NOC has not have time to
make the call, the hard limit is already achieved. Reaching
hard limit usually is a serious matter to ISPs, they should
open trouble ticket and call each other to find out why from
my experience.

>
>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.

that's true. If there is something really need to communicate
in this way, I agree that this is useful. but besides this
route-limit example, i still wait to see like what? usually
NOCs talk to each other on circuit problems, excessive traffic
patterns, DOS attacks, which I doubt we should use INFORM to do.

just my 2 cents.

>
>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
> >
> > 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

george

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

---

From: [email-masked]
Date: Fri, 16 Aug 2002 10:46:22 -0700

George,

> basically you are saying it's a inter-noc remote-logging

In a lot of ways, yes. The inter-noc boundry is quite opaque at times.
This should help.

> patterns, DOS attacks, which I doubt we should use INFORM to do.

Another example, could be a case where you want to send more info
before you send a NOTIFY and tear down the session.  In the case
a couple of months ago where a MALFORMED_AS_PATH containing 
as_confed types was being erroniously propegated in the internet
comes to mind.  In this example, a bad attribute was getting passed
around, when an implementation that recognized the bad attribute
received it, it tore down the session, with a MALFORMED_AS_PATH
NOTIFY.  However, there was no indication what route caused the
problem.  If INFORM existed, that information could have been passed
back to the peer, who could have taken action.  

I don't think anyone intends for NOTIFY messages to replace inter-noc
communication.  But it will help things along.  As you pointed out
NOTIFY clearly would not work with DOS attacks or irregular traffic
patterns, or other issues outside the scope of the BGP session between
providers.

Andrew

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 16 Aug 2002 14:24:40 -0400

On Fri, Aug 16, 2002 at 10:46:22AM -0700, [email-masked] wrote:
> In this example, a bad attribute was getting passed

This is a deficiency in the current spec.  There is no reason why
the the AS PATH couldn't be returned in the data section of the
notification, excepting that this is (probably) not deployed practice.

-- 
Jeff Haas 
NextHop Technologies