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

From: Yakov Rekhter <[email-masked]>
Date: Mon, 10 May 2004 07:17:53 -0700

Folks,

To answer the first question raised by John Scudder in the attached...

As we discuss relative merits of two approaches to signal prefix
limit, draft-chavali-bgp-prefixlimit-02.txt and
draft-keyur-prefixlimit-orf-00.txt, we also need to step back and
ask whether there is a WG consensus to take signalled prefix limit
as a work item.

For the purpose of measuring consensus on whether the WG should
take signalled prefix limit as a work item, it will be assumed that
those who are in favor of either of the two approaches mentioned
above as being also in favor of taking signalled prefix limit as
a work item (if this assumption is incorrect, please speak up now).

Those who think that the IDR WG should not take signalled prefix
limit as a work item, please speak up now.

The deadline for comments is May 24, 2004.

Yakov.
------- Forwarded Message
To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: [Idr] signalled prefix limits -- contrasting approaches
Date: Thu, 6 May 2004 13:03:27 -0400

Folks,

Regarding prefix limits, it seems to me that there are at least two 
questions for the WG to answer:

First, do we want to take signalled prefix limits as a work item?

Assuming that the answer is "yes", then:

Second, what is the preferred approach?  One of the two that have 
been presented (draft-chavali-bgp-prefixlimit-02.txt, 
draft-keyur-prefixlimit-orf-00.txt)? Something else?

For the interest of forwarding that discussion, I guess I should 
suggest that draft-keyur-prefixlimit-orf-00.txt be a WG document.  I 
hereby do so.

Having done so, below I'll contrast the draft-chavali and draft-keyur 
approaches.  Also, I should point out that draft-keyur can be seen as 
a fully-elaborated statement of what I said at the mic back in 
Minneapolis, so this is not the first time I've suggested this 
approach in an IDR WG forum.

Summarizing the principal differences:

draft-chavali proposes to use dynamic capabilities.  draft-keyur 
proposes to use ORFs.

draft-chavali proposes multiple thresholds, albeit only one mandatory 
one.  draft-keyur proposes one.  The use of multiple, optional 
thresholds drives draft-chavali to have a more elaborate encoding 
than draft-keyur uses.

draft-chavali appears to propose dynamic signalling triggered by 
limits being exceeded.  It's hard to evaluate this properly since I 
can't come up with an unambiguous interpretation of section 4.  In 
any event, draft-keyur does not propose any such dynamic signalling.

That's it in a nutshell.  Now I will discuss the reasons for our choices.

As regards ORFs vs. dynamic capabilities, one may observe that ORFs 
have exactly the desired semantics: supported ORF types are exchanged 
at connection startup, they are typed according to AFI/SAFI, they are 
a way for a router to export its policy to its peer and they can be 
dynamically revised.  All this semantic goodness is part of the basic 
ORF spec, which is already widely implemented and deployed.  Dynamic 
capabilities certainly could be used to exchange such limits, but 
then again any other arbitrary message type could too.  The appeal of 
ORFs is that again, they are already widely implemented and are a 
good semantic fit.  Our experience is that it's not very hard to add 
prefix limit exchange to an implementation that already has ORFs and 
a locally-configured max-prefix feature.

As regards multiple thresholds, Enke Chen already covered this in an 
earlier message to the list, and I agree with what he wrote, but I'll 
say it again in my own words.  The warning limit is not needed since 
warnings can and should be generated as a matter of local policy.  As 
for the reset limit, draft-chavali implicitly acknowledges that it's 
not really needed when it says "It MUST be noted here that this 
situation will never be encountered if adhered to the draft."  Since 
neither limit is required to deliver a useful feature, the KISS 
principle suggests leaving them out.  The obvious riposte to this 
point is that since the features are optional, they need not be 
implemented, to which I would respond, if you don't expect them to be 
implemented, why clutter the spec and risk confusing implementors? 
Other BGP related specs are largely free of optional features 
(internally to themselves anyway), and I think this is a good 
thing... we have enough trouble implementing, deploying, 
interoperating and debugging the mandatory ones!

(As a bit of a tangent, the WG has previously considered at least one 
mechanism to allow arbitrary conditions to be non-destructively 
signalled, and decided at that time not to pursue it.  If we _do_ now 
think that we need such signalling, as the warning limit appears to 
do, perhaps it would be best to re-open the general topic instead of 
building a feature-specific version.  Note that draft-keyur does not 
in any way preclude supporting such a feature in the future if we 
define one.)

As regards dynamic signalling, I found it challenging even to 
understand exactly what draft-chavali is proposing.  To take one 
example, in 4.2.1, it says that when the warning limit is 
encountered, "B generates a dynamic capability" and furthermore 
"either A or B or both of them could generate this message".  Without 
getting into any further details of how the dynamic signalling of 
limits being crossed would be done, I'll discuss the reason why I'm 
generally not attracted to in-band dynamic warnings in any form. 
First, it's unnecessary.  In the example of 4.2.1, A knows how many 
routes it's gotten from B -- it doesn't need B to tell it.  B knows 
how many routes it's sent to A -- it doesn't need A to tell it.  Once 
again, the KISS principle suggests that this feature is therefore not 
required.  Second, it's dangerous.  Consider the case where B's 
advertised route count is hovering near the warning limit, and in 
fact frequently crosses back and forth over the warning limit.  This 
could easily result in excessive warning signalling over the BGP 
session, with resultant bad effects.  Of course, a thoughtful 
implementation would take steps to avoid this, but at the cost of 
additional complexity... and anyway, why leave the door open to 
possible bugs in whatever throttling scheme would be employed (or not 
employed, by a naive implementation)?

To sum up the reasons for the three differences I've identified, they 
are in the case of ORF, a pragmatic engineering choice where we 
selected what appears to us to be the best tool for the job, and in 
the cases of multiple thresholds and dynamic signalling, KISS.

Regards,

--John

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

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

---

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 11 May 2004 21:05:48 -0400

Tony:

<working group chair hat on>

Your vote (per John's/Sue's) suggested
addition of this topic is: NO. 

Please confirm.  Also do you at 
this time represent a vendor,
a service provider or a valued
researcher/expert? (pick any set
out of the three)?

<working group chair hat off> 

Sue

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

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: "Susan Hares" <[email-masked]>
Date: Wed, 12 May 2004 12:19:06 -0400

Parantap:

Thanks for your input. 

Sue

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

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: "Susan Hares" <[email-masked]>
Date: Wed, 12 May 2004 12:28:23 -0400

Tao:

<working group chair hat on>
To summarize your response:

1) Work item: yes
2) draft-chavali-bgp-prefixlimit-02.txt - no
3) keyur-prefixlimit-orf-00.txt - yes

Extra comment: prefix limit should be in
		   ORF MIB event.

<working group chair hat off> 
<co-author hat on> 
I just want to confirm that you
want 1 limit per ORF.  You want
to hit the limit and either disconnect
or ignore prefixes.
<co-author hat off> 

Thanks for your comments,

Sue

-----Original Message-----
From: sun tao [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 10:33 AM
To: [email-masked]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

hello!
    >> Yakov Rekhter writes:
    if only the MIB reason,We have the same request for the mib to monitor the ORF event.So I think the ORF way to complete the prefix limit should be include the ORF event mib too.from the  operation complex,I think the draft-keyur-prefixlimit-orf-00.txt is easy to realize and configure.we needn't do other thing than add new orf  type.
                                                                                                                                                                                    best 
                                                                                                                                                                                                            tao
----- Original Message ----- 
From: "Pedro Roque Marques" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 11, 2004 1:33 AM
Subject: [Idr] signalled prefix limit as an IDR WG work item

> Yakov Rekhter writes:
> It all depends on what is the expectation. I undertand the fact that
> managing prefix-limits of costumer connections is a significant
> operational problem.
> 
> What is not clear to me is what is the expected service model for this
> after signalled prefix limits are agreed.
> 
> My understanding is that different people have different expectations
> regarding what the mecanism is supposed to acomplish.
> 
> i.e. is the point simply to generate a warning limit in the customer
> syste
> 
> or is the fact that the limit is signaled something that just makes
> life easier to the manager of the customer box ?
> 
> or is it a question of transfer of responsability for the session
> reset ?
> 
> or is the expectation that the routers be inteligent enought to
> understand which prefixes are "good" and should be mainatained and
> which prefixes are "bad" and should be droped.
> 
> The latter is quite hard to define and not simple to implement in a
> fail-proof way.
> 
> I would like to clearly define the problem and expectations before we
> solve it... keep in mind that the more complex the problem definition
> the higher the cost of a solution (and thus less likely to come
> about).
> 
>   Pedro.  
> 
!jz²®~?³Ãz®jjS

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 12 May 2004 12:19:06 -0400

Parantap:

Thanks for your input. 

Sue

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

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: "Susan Hares" <[email-masked]>
Date: Wed, 12 May 2004 12:28:23 -0400

Tao:

1) Work item: yes

Sue

-----Original Message-----
From: sun tao [mailto:[email-masked]]
Sent: Wednesday, May 12, 2004 10:33 AM
To: [email-masked]
Subject: Re: [Idr] signalled prefix limit as an IDR WG work item

hello!
----- Original Message ----- 
From: "Pedro Roque Marques" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, May 11, 2004 1:33 AM
Subject: [Idr] signalled prefix limit as an IDR WG work item

!jz²®~?³Ãz®jjS