Subject: RE: [Idr] signalled prefix limit as an IDR WG work item

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 19:14:32 -0400

Parantap:

So, you want by individual prefix (not
prefix length, not maximum)

1) Warning level
2) Stop level (Ignore further prefix)

Do you also want a Disconnect in case
of /8 and lots of prefix?

My understanding from the information below
is that you want: global limits (0/0 and
anything that refines it) as well as
these local limits.

Is that correct?

Sue 

-----Original Message-----
From: Parantap Lahiri [mailto:[email-masked]]
Sent: Tuesday, May 11, 2004 3:23 PM
To: Jeffrey Haas; 'Pedro Roque Marques'
Cc: [email-masked]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item

Here is a couple of paragraphs from a mail I dropped to this list some time
back which relates to this discussion ..

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number of prefixes send
by customer could experience a sudden sizeable jump. In today's world, there
is a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session
would go down permanently if the max-prefix-limit is exceeded. It would take
an urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeffrey
Haas
Sent: Tuesday, May 11, 2004 2:51 PM
To: Pedro Roque Marques
Cc: [email-masked]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

On Tue, May 11, 2004 at 10:44:49AM -0700, Pedro Roque Marques wrote:
> Does anyone want to venture how this external knowledge would be
> learned or what would it need to consist off ?

[...]

> For instance if this 'external knowledge' is the exact list of
> prefixes to be allowed, then the entire problem of prefix limits makes
> no sense. i.e. prefix-limits themselfs seem to have been designed to
> deal w/ situations where you have incomplete information.

Perhaps.

One specific example I've heard is that a customer gives their
prefixes they wish to provide to their ISP.  The ISP will permit
those and less specifics to be advertised.  They may also permit
a small number of prefixes to be advertised that are not in this
list.  This permits a new customer to be setup downstream of
the limited connection without the need to immediately update the
list.

(Think of the situation where the NOC of the upstream is slow about
updating these lists.  I think in an ideal world, this would be
dealt with using IRR technology but I'll stick to what we have now.)

In the case of a route explosion, prefer the configured prefixes in
the list and let the others drop.

>   Pedro.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Tue, 11 May 2004 17:08:13 -0700

FWIW, I'm having a hard time understanding why we want the prefix limit 
signaled.

I understand the reason to limit the damage that can be caused by a 
peer, but if
we are concerned about that level of damage, we cannot ignore the 
vulnerability
that any signaled limit is also bogus, either through maliciousness, 
poor
implementation, or human error.

In other words, if we're trying to add a sanity check, we need a sanity 
reference
that isn't provided by the patient.  ;-)

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 11 May 2004 17:08:13 -0700

Tony

---

From: Parantap Lahiri <[email-masked]>
Date: Wed, 12 May 2004 11:53:18 -0400

Sue,

Setting warning/stop levels on individual prefix might get too hard to
manage. I am fine with global limits as far as the levels go. 

>of /8 and lots of prefix?

Even after filtering the more specifics if the number of prefixes crosses
the global upperbound limit, I think the session should be taken down. 

-Parantap

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 7:15 PM
To: Parantap Lahiri; Jeffrey Haas; Pedro Roque Marques
Cc: [email-masked]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item

Parantap:

1) Warning level

Is that correct?

Sue 

-----Original Message-----

[...]

Perhaps.

-- 
Jeff Haas 
NextHop Technologies

---

From: Parantap Lahiri <[email-masked]>
Date: Wed, 12 May 2004 11:53:18 -0400

Sue,

-Parantap

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Tuesday, May 11, 2004 7:15 PM
To: Parantap Lahiri; Jeffrey Haas; Pedro Roque Marques
Cc: [email-masked]
Subject: RE: [Idr] signalled prefix limit as an IDR WG work item

Parantap:

1) Warning level

Is that correct?

Sue 

-----Original Message-----

[...]

Perhaps.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 14 May 2004 11:59:02 -0400

Tony,

> FWIW, I'm having a hard time understanding why we want the prefix limit 

Completely aside from taking some form of remedial step on receipt
of your peer's prefix-limit for you (which is the majority of
where the arguments are happening), this allows for your implementation
to be able to monitor its adj-rib-out count for the peer and to
let management applications (probably SNMP) warn operators when you're
going to hit this limit.

Sure, you could configure this, on your side, but I would wonder if
that would be anywhere near as useful.

I believe this is the point that Tao was making.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 14 May 2004 11:59:02 -0400

Tony,

-- 
Jeff Haas 
NextHop Technologies

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 14 May 2004 13:17:12 -0400

> I believe this is the point that Tao was making.

Having in a past life been an operator I remember that a massive
number of SNMP traps can be generated and no human being is sitting
there looking at them all, but there are programs that look through
them and pick out ones that need attention (some polling to follow up,
and depending on what is found maybe a trouble ticket).

I can think of two cases where prefix limits could come into play and
one side or the other needs to take action.  With static
configuration, the configuration could be different on each side.  One
side may be notified by SNMP that there is a problem but that side may
not be aware that there is a problem because of limitations of their
SNMP trap handler or may be slow to pass the notification to the other
side.

The classic prefix-limit problem is when your peer goofs and
advertises a lot of routes that they have no business advertising.
This could just be a goofed hand edit on a policy statement.  The
assumption is that you are protecting yourself from your peer's goof.
It would also help if the party that goofed got direct notification
rather than NOC to NOC communication that the limit was exceeded.  For
this you need notification on both sides when the limit is exceeded.

Where advertising the prefix limit itself helps is if the prefix limit
is configured too low or wrong on the other side or changed for some
reason without telling the peer.  If you are sending legitimate routes
to your peer and you hit a 80% or 90% threshhold on the advertised
prefix-limit you may want to negociate a higher limit with your peer.
Its better to do this at the 80% mark than wait for an outage and for
your peer to tell you that they have finally discovered that the
problem all along was that they had configured too low a prefix limit.
It also helps to know that a limit that was agreed to by your peer was
actually configured on the other side.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 14 May 2004 13:17:12 -0400

Curtis

---

From: Tony Li <[email-masked]>
Date: Fri, 14 May 2004 10:40:09 -0700

Understood.  My question has much more to do with minimalist design 
principles.
If this is something that doesn't HAVE to be there, then it probably 
shouldn't
be.

What's next?  Do we signal the amount of memory that an implementation 
has left
before it chokes?  How about current CPU utilization?  The phase of the 
moon?

This really smells like hump of camel to me.

Tony

---

From: Tony Li <[email-masked]>
Date: Fri, 14 May 2004 10:40:09 -0700

Tony

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 May 2004 06:55:13 -0700

Parantap,

Could you please clarify whether (a) you are in favor or against
accepting signalled prefix limit as an IDR WG item, and if yes,
then (b) which of the two approaches (draft-chavali-bgp-prefixlimit-02.txt
or draft-keyur-prefixlimit-orf-00.txt) would you favor.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 18 May 2004 06:55:13 -0700

Parantap,

Yakov.

---

From: Parantap Lahiri <[email-masked]>
Date: Tue, 18 May 2004 12:46:30 -0400

(a) I am against accepting signaled prefix as a WG item. Concurring with
Pedro, I think the problem space has to be better understood in its entirety
and the benefits of this new complexity have to be more clearly established.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Yakov
Rekhter
Sent: Tuesday, May 18, 2004 9:55 AM
To: Parantap Lahiri
Cc: [email-masked]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

Parantap,

Yakov.

---

From: Parantap Lahiri <[email-masked]>
Date: Tue, 18 May 2004 12:46:30 -0400

-----Original Message-----

Parantap,

Yakov.