Subject: RE: questions on INFORM draft

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 19 Aug 2002 10:59:36 -0400

I believe the INFORM message mechanism is a GOOD idea to provide a vehicle
for future implementations to convey BGP status information between peers
without implying a session reset.   

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Saturday, August 17, 2002 2:19 PM
> To: George Sheng
> Cc: [email-masked]
> Subject: Re: questions on INFORM draft
> 
> 
> George,
> 
> On Sat, Aug 17, 2002 at 05:38:06AM +0000, George Sheng wrote:
> > that is cool. but still the question is why bgp?
> 
> Why not?  Has the idea been previously proposed for other protocols?
> 
> > there are a couple of protocols need inter-noc communications,
> 
> For each of these, there may be appropriate information that should
> be conveyed.
> 
> > 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.
> 
> > Those actions may include send an
> > inter-noc trap to another NOC,
> 
> Exactly.  But:
> 1. Do you want SNMP coming from the other provider?
> 2. Why should the information come from a remote NMS rather than
>    the adjacent router?  You do provide some useful justifications:
> 
> > 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. :-)
> 
> > 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.
> 
> > 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.
> 
> > 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
>

---

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

> without implying a session reset.   

The fact that its rate limited means that some status is likely to be lost.

-- 
Jeff Haas 
NextHop Technologies