Subject: Re: questions on INFORM draft

From: "George Sheng" <[email-masked]>
Date: Mon, 19 Aug 2002 03:43:50 +0000

Jeff,

>
>Why not?  Has the idea been previously proposed for other protocols?
>

Not sure, but do they need to? I assume
the bgp-ignorants in NOCs are still capable of using phones:-)

> > there are a couple of protocols need inter-noc communications,
>
>For each of these, there may be appropriate information that should
>be conveyed.

Just wondering why we have not seen them. This hits me again
there is something special in BGP, or maybe BGP is overloaded
by all sorts of mechanism, add some more is not a big deal;-)

>
> > For some large/huge networks, even the IGPs
> > at different areas are monitored by different departments/NOCs.
>
>In the case of IGP's, SNMP is sufficient.

even in the case of two areas are monitored by diff NOCs?
they seem also need the "inform", if area 0 received too many
inter-area routes for it's peer, No?

>
> > Those actions may include send an
> > inter-noc trap to another NOC,
>
>Exactly.  But:
>1. Do you want SNMP coming from the other provider?

things can be worked out between NOCs. If they don't,
do you think they would love to see your INFORM messages?
or are you saying INFORM can be used to sneak messages around
your competitor's firewall or security system?

>2. Why should the information come from a remote NMS rather than
>    the adjacent router?  You do provide some useful justifications:
>

yes, I did I think.

> > This way, you don't just restrict something to
> > only BGP, but to anything including DDOS attack, weird traffic
> > pattern and other protocol INFORM msgs.
>
>I'm going to take the cop-out on this.
>A generic inter-noc protocol is out of scope for BGP.
>If you can provide such a thing, we should use that instead. :-)

I can only modify our own NMS to include such a functionality
if people here really want this. I can post some pseudo-code
of "expect"/"perl" if people are interested:-)

>
> > In the example
> > of "too many routes", for every peer, you may need to define
> > a "too many routes" limit since they can have different
> > requirements.
>
>This is the way many providers already work.
>
> > Also those limits do change with time.
>
>And this is the way providers usually deal with things.

I think I was talking about more complicated cases when
this INFORM can be really appreciated. For exceeding route
limit, I don't feel reset peer is a bad thing to do. But as
Andrew suggested setting some soft limit, maybe primary soft
and secondary soft, things can get complicated.

>
> > Can ISPs keep up with those configurations?
>
>As soon as someone proposes what they want the traps to look like,
>they'll show up in the bgp v2mib.
>
> > You may also need to define
> > lots of inform-groups(similar to bgp peer-groups) to group
> > all the INFORM parameters for some peers. do we really want
> > to get into this?
>
>Why would you?  Just like you would NOTIFY a given peer, you INFORM
>them.  Its up to the remote implementation to forward the information
>to the party that cares about it.

If you need too much configuration to deal with each INFORM
conditions, to group them into something can be shared
with different peers is a well known mechanism I think.

Basically here is what my take on this proposal:

* bgp serious errors usually better to bring session down
* bgp less serious errors should not bring down session, but
   some human involvement is needed to make a intelligent
   decisions(including make a phone call)
* If vendors do want to help ISPs to improve inter-noc
   communication, then a generic agent would be a nice thing
   to do.
* I'm not routing literate, but I'm wondering if NOTIFY msg can
   be changed to flag not to "reset peer", maybe combined
   with bgp capability attributes so backwards compatibility
   is ensured?
* in order to use this INFORM meaningfully, I'm afraid
   complicated filtering/policy things have to be added later,
   which may not be a good thing for BGP.
* this mechanism does have a simple way to inform the other
   side. if people can find useful things to do(i'm still trying
   to think), then it's ok. but I'm not convinced just yet.

My 2 cents.

>
> > you are probably thinking this(local NMS sending traps to
> > other NOCs) puts to much development burden on ISPs.
>
>What I am thinking is that ISPs must already provide monitoring
>services by monitoring their routers already.  This just provides
>another piece of information that must be collected, summarized and
>processed.  As stands, I don't think INFORM is good enough to
>be summarized and easy to process.  But its a young proposal yet.
>
>
>--
>Jeff Haas
>NextHop Technologies

-george

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

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 19 Aug 2002 11:03:30 -0400

> by all sorts of mechanism, add some more is not a big deal;-)

Much like having an IGP break, breaking BGP means the Internet is
broken.  Your users notice it pretty quickly.

IGPs, for whatever reason, seem to be more stable than BGP.
I'll withhold further comment on that.

> inter-area routes for it's peer, No?

No.
Both are part of the same organization, both are likely receiving
the SNMP from the ABR.

> your competitor's firewall or security system?

I have no idea why you're even thinking this way.

> of "expect"/"perl" if people are interested:-)

Can you convince your upstreams to take your SNMP?

> * bgp serious errors usually better to bring session down

Agreed.

>    decisions(including make a phone call)

Right.  But you need to bring things to the attention of the other
party.

>    communication, then a generic agent would be a nice thing

Out of scope for IDR. 
Border "Glue" Protocol we may be but I don't want to see ASN.1
in my routing streams.

>    with bgp capability attributes so backwards compatibility

Unlikely.  NOTIFY is the ultimate hammer.

>    which may not be a good thing for BGP.

This would have to be added in whatever inter-noc "thing"
you want to put together.  This simply argues for keeping
things in INFORM simple.

>    to think), then it's ok. but I'm not convinced just yet.

I think the idea has some merit but has a ways to go.

-- 
Jeff Haas 
NextHop Technologies