Subject: RE: questions on INFORM draft

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 19 Aug 2002 12:44:05 -0400

John and Jeff:
  I cannot imagine any status information that will need subsecond
notification
to a peer. Therefore, the notion of event loss is very unlikely to me.

Can you site some examples where subsecond information is needed to be sent
to a peer?

Ben

> -----Original Message-----
> From: John G. Scudder [mailto:[email-masked]]
> Sent: Monday, August 19, 2002 12:18 PM
> To: Abarbanel, Benjamin
> Cc: 'Jeffrey Haas'; Abarbanel, Benjamin; [email-masked]
> Subject: RE: questions on INFORM draft
> 
> 
> Clearly if you're generating events at a mean rate greater than 
> one/second, then 60/minute rate-limiting will result in the loss of 
> events (or delay approaching infinity if you have an infinite queue 
> available in your router :-).
> 
> Our intent in the proposal is that implementors should generate 
> events sparingly (at a mean rate much lower than one/second) and _if_ 
> micro-events are deemed to be worthy of an INFORM they should be 
> aggregated.
> 
> Furthermore as we discussed on the list about a month ago and as the 
> current version of the draft explicitly states in 7.1.2, we 
> specifically don't want INFORM to be part of BGP's control loop. 
> This relates to rate limiting in that it implies loss or delay of an 
> INFORM won't affect the operation of the protocol.  On the other 
> hand, allowing INFORMs to be spewed arbitrarily fast would have the 
> potential to delay important messages such as UPDATEs; a bad thing.
> 
> Regards,
> 
> --John
> 
> At 11:53 AM -0400 8/19/02, Abarbanel, Benjamin wrote:
> >Jeff:
> >  Section 7.1.1 states,
> >"The rate at which INFORM messages are generated must be 
> rate-limited.
> >  A suggested default limit is 60 messages per minute." This does not
> >  imply that messages are lost, just that status is conveyed 60 times
> >  per second.
> >
> >Ben
> ...
>

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 19 Aug 2002 12:47:01 -0400

>Can you site some examples where subsecond information is needed to be sent

Nope.  I seem to have lost the point of this discussion.

Regards,

--John

---

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

> Can you site some examples where subsecond information is needed to be sent

Who needs subsecond?  More than 60 in a minute is good enough.

As an example, say we are getting INFORMs of a bad aspath that
has been repaired.  It is quite possible that we may need to
do this for the majority of the routes we are sent from a given
peer.  This would mean potentially one INFORM per route we get
sent.

-- 
Jeff Haas 
NextHop Technologies