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: Jeffrey Haas <[email-masked]>
Date: Mon, 10 May 2004 10:55:50 -0400

Yakov,

> ask whether there is a WG consensus to take signalled prefix limit

I haven't had the opportunity to review the merits of either of
these documents, but speaking with my hat as BGP MIB editor, one
of the most requested features out of the V2 MIB has been better
counters for prefixes on a per-AFI/SAFI basis.

A signaled prefix limit mechanism of some sort seems like it would
also help fill this need.  The MIB allows localized management
of the limits, a singalling mechanism allows one to communicate
localized policy.

Regardless of the approach, the thing that has been mentioned during
discussion of this issue has been, "Why do we care?"  Prefix limits
are similar to other elements of BGP policy almost all of which have
previously been local matters.  

The primary difference with prefix-limits has been that simply
discarding prefixes as a local matter is not as operationally
serious as one of the other mechanisms of dealing with the problem:
dropping the peering session.  Both mechanisms are operationally
disruptive, but dropping the session is probably even more so.

I think we should spend some of our time discussing the consequences
of each of these actions regardless of the fact that each practice
is currently well deployed.  Answering how we believe we should
behave in these circumstances will probably help determine our behavior
in any signalled prefix limit mechanism.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 10 May 2004 10:55:50 -0400

Yakov,

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 10 May 2004 13:31:18 -0400

At 10:55 AM -0400 5/10/04, Jeffrey Haas wrote:
...
>disruptive, but dropping the session is probably even more so.

You think so?  I'm not so sure.  Dropping routes on the floor can be 
substantially harder to debug.  Consider the differences in the 
failure modes --

If you drop the session, both parties know right away that something 
is broken.  There will be immediate attention to the problem while 
the cause is still evident.

If you drop prefixes, there's a real risk that the party whose 
prefixes are dropped won't notice until later, potentially quite a 
bit later.  By that time the session may even have fallen below the 
maximum again, while remaining unsynchronized due to the prior route 
droppage.  In any event, it's almost inevitable that diagnosing the 
problem will be more challenging.  Fundamentally, problems where 
connectivity is semi-broken are harder to debug than those where it's 
all broken.

>is currently well deployed.

I believe that the "drop the session" behavior is well deployed.  I 
have my doubts about the "drop the prefix" behavior.  This in itself 
is instructive.

>Answering how we believe we should

I think that if we were so foolish as to adopt a spec that tried to 
exclude one approach or the other, we'd just end up with nonstandard 
vendor-specific knobs anyway, since some folks will prefer one 
approach, some the other.

Regards,

--John

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 10 May 2004 10:33:54 -0700 (PDT)

> limit as a work item, please speak up now.

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
system ?

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.

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 10 May 2004 13:31:18 -0400

Regards,

--John

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 10 May 2004 10:33:54 -0700 (PDT)

Pedro.

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Mon, 10 May 2004 11:01:33 -0700

> disruptive, but dropping the session is probably even more so.

  Each deployment/network has a different notion of how/which 
  prefixes to drop when the limit is exceeded. However, all of them
  do want to eventually penalize the sender by dropping the session
  because if the sender does not keep within SLA, it should not
  disrupt the network.  Keeping the session up and dropping 'some' 
  prefixes locally produces a forwarding state from the pov of the 
  sender that is not useful at all. In fact it is in general not 
  differentiable from a situation where a bug causes an announced 
  prefix to not get into the forwarding table, imho.

  Regards,
  Chandra Appanna.

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Mon, 10 May 2004 11:01:33 -0700

Regards,
  Chandra Appanna.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 May 2004 10:18:39 -0400

> the cause is still evident.

And yet many people think that this is the wrong tool or at least too
harsh of one.

Our end goal, IMO, is survivability of the provider network in
instances where resources (prefixes learned from a peer) are
limited.  In all cases, we wish to limit this or at least we do
for the point of this discussion.

Dropping the session serves this purpose.

In some cases, dropping excess prefixes - especially with some external
knowledge as to which are more preferable than others - is less
disruptive.  In absence of that external knowledge, dropping the
peering session produces the least surprising results.

> bit later.

This presumes that there is no signalling mechanism to let this party
know that their prefixes are being dropped.

> approach, some the other.

I believe this argues for having "drop prefixes" and "drop the session"
both be in our proposed solution.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 May 2004 10:18:39 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 11 May 2004 10:53:37 -0400

...
>know that their prefixes are being dropped.

Agreed.

>both be in our proposed solution.

Wholeheartedly agreed.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 11 May 2004 10:53:37 -0400

...

Agreed.

Wholeheartedly agreed.

--John

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 11 May 2004 10:44:49 -0700 (PDT)

Jeffrey Haas writes:

> In some cases, dropping excess prefixes - especially with some
> external knowledge as to which are more preferable than others - is
> less disruptive.  In absence of that external knowledge, dropping
> the peering session produces the least surprising results.

I'm in strong agreement w. you specially when it comes to the last phrase.

Does anyone want to venture how this external knowledge would be
learned or what would it need to consist off ?

It may turn out that this external knowledge has a cost that its
higher than what is admissible.

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.

I would suggest that we need to think this through before we can
answer Yakovs question regarding should this be a WG item or not.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 11 May 2004 10:44:49 -0700 (PDT)

Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 May 2004 14:50:53 -0400

> learned or what would it need to consist off ?

[...]

> 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.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 11 May 2004 14:50:53 -0400

[...]

Perhaps.

-- 
Jeff Haas 
NextHop Technologies

---

From: Parantap Lahiri <[email-masked]>
Date: Tue, 11 May 2004 15:23:29 -0400

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

[...]

Perhaps.

-- 
Jeff Haas 
NextHop Technologies

---

From: Parantap Lahiri <[email-masked]>
Date: Tue, 11 May 2004 15:23:29 -0400

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

[...]

Perhaps.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 May 2004 07:56:43 +0300 (EEST)

Let's try to figure out the scenarios for prefix-limits a bit better..

As to where we use prefix-limits.. toward peers (but not
upstreams/customers).  For customers, we have strict prefix list; for
upstreams, we don't want to filter out anything -- so nothing needed
here.  (We dont allow the customers to advertise more specifics i.e.,
to break the aggregates -- but if you would, prefix-limits could be 
used here as well, as discussed below where I quote Parantap's note.)

For peers, however, this is slightly different.  Generating 
prefix-lists from RIPE DB for our peering sessions would take over 
20,000 lines of access lists.  That's simply unacceptable amount of 
junk to our router configurations.  So, we simply filter based on the 
AS-numbers, and use the prefix limits (the limit is about 5-10 times 
as much as they're advertising now) as a means to disconnect the peer 
if it accidentally starts advertising the whole Internet to us.

We don't need prefix-limit signalling for this kind of stuff at all, 
which is why I said in the first place that I fail to see where it's 
needed but wouldn't object to it being specified as long as it's 
simple.

A few comments about Parantap's scenario below...

> mechanism can get affected. So the price the customer pays for the mishap

I fail to see why you'd need the prefix-length checking here.  
Couldn't you do just:

 1) "what's the normal status i.e., how many prefixes are normal?" 
(e.g., 30)
 2) "decide on the pain threshold, after which you stop receiving more 
prefixes" (e.g., 50)
 3) "decide the punishment threshold, after which you drop the peer"
(e.g., 300)

If the customer ever goes to 2), he has been misbehaving, but the 
existing, less specific prefixes still get through.  If the customer 
happens to reset the session, resulting in some aggregates not getting 
through, you can just add to your instructions that you're using 
prefix-limits and if they want it to get through, they'll have to take 
out those more specifics.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Pekka Savola <[email-masked]>
Date: Wed, 12 May 2004 07:56:43 +0300 (EEST)

---

From: "sun tao" <[email-masked]>
Date: Wed, 12 May 2004 22:32:52 +0800

aGVsbG8hDQogICAgPj4gWWFrb3YgUmVraHRlciB3cml0ZXM6DQo+IA0KPiA+IFRob3NlIHdobyB0aGluayB0aGF0IHRoZSBJRFIgV0cgc2hvdWxkIG5vdCB0YWtlIHNpZ25hbGxlZCBwcmVmaXgNCj4gPiBsaW1pdCBhcyBhIHdvcmsgaXRlbSwgcGxlYXNlIHNwZWFrIHVwIG5vdy4NCiAgICBpZiBvbmx5IHRoZSBNSUIgcmVhc29uLFdlIGhhdmUgdGhlIHNhbWUgcmVxdWVzdCBmb3IgdGhlIG1pYiB0byBtb25pdG9yIHRoZSBPUkYgZXZlbnQuU28gSSB0aGluayB0aGUgT1JGIHdheSB0byBjb21wbGV0ZSB0aGUgcHJlZml4IGxpbWl0IHNob3VsZCBiZSBpbmNsdWRlIHRoZSBPUkYgZXZlbnQgbWliIHRvby5mcm9tIHRoZSAgb3BlcmF0aW9uIGNvbXBsZXgsSSB0aGluayB0aGUgZHJhZnQta2V5dXItcHJlZml4bGltaXQtb3JmLTAwLnR4dCBpcyBlYXN5IHRvIHJlYWxpemUgYW5kIGNvbmZpZ3VyZS53ZSBuZWVkbid0IGRvIG90aGVyIHRoaW5nIHRoYW4gYWRkIG5ldyBvcmYgIHR5cGUuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBiZXN0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGFvDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlBlZHJvIFJvcXVlIE1hcnF1ZXMiIDxyb3F1ZUBqdW5pcGVyLm5ldD4NClRvOiAiWWFrb3YgUmVraHRlciIgPHlha292QGp1bmlwZXIubmV0Pg0KQ2M6IDxpZHJAaWV0Zi5vcmc+DQpTZW50OiBUdWVzZGF5LCBNYXkgMTEsIDIwMDQgMTozMyBBTQ0KU3ViamVjdDogW0lkcl0gc2lnbmFsbGVkIHByZWZpeCBsaW1pdCBhcyBhbiBJRFIgV0cgd29yayBpdGVtDQoNCg0KPiBZYWtvdiBSZWtodGVyIHdyaXRlczoNCj4gDQo+ID4gVGhvc2Ugd2hvIHRoaW5rIHRoYXQgdGhlIElEUiBXRyBzaG91bGQgbm90IHRha2Ugc2lnbmFsbGVkIHByZWZpeA0KPiA+IGxpbWl0IGFzIGEgd29yayBpdGVtLCBwbGVhc2Ugc3BlYWsgdXAgbm93Lg0KPiANCj4gSXQgYWxsIGRlcGVuZHMgb24gd2hhdCBpcyB0aGUgZXhwZWN0YXRpb24uIEkgdW5kZXJ0YW5kIHRoZSBmYWN0IHRoYXQNCj4gbWFuYWdpbmcgcHJlZml4LWxpbWl0cyBvZiBjb3N0dW1lciBjb25uZWN0aW9ucyBpcyBhIHNpZ25pZmljYW50DQo+IG9wZXJhdGlvbmFsIHByb2JsZW0uDQo+IA0KPiBXaGF0IGlzIG5vdCBjbGVhciB0byBtZSBpcyB3aGF0IGlzIHRoZSBleHBlY3RlZCBzZXJ2aWNlIG1vZGVsIGZvciB0aGlzDQo+IGFmdGVyIHNpZ25hbGxlZCBwcmVmaXggbGltaXRzIGFyZSBhZ3JlZWQuDQo+IA0KPiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgZGlmZmVyZW50IHBlb3BsZSBoYXZlIGRpZmZlcmVudCBleHBlY3RhdGlvbnMNCj4gcmVnYXJkaW5nIHdoYXQgdGhlIG1lY2FuaXNtIGlzIHN1cHBvc2VkIHRvIGFjb21wbGlzaC4NCj4gDQo+IGkuZS4gaXMgdGhlIHBvaW50IHNpbXBseSB0byBnZW5lcmF0ZSBhIHdhcm5pbmcgbGltaXQgaW4gdGhlIGN1c3RvbWVyDQo+IHN5c3RlDQo+IA0KPiBvciBpcyB0aGUgZmFjdCB0aGF0IHRoZSBsaW1pdCBpcyBzaWduYWxlZCBzb21ldGhpbmcgdGhhdCBqdXN0IG1ha2VzDQo+IGxpZmUgZWFzaWVyIHRvIHRoZSBtYW5hZ2VyIG9mIHRoZSBjdXN0b21lciBib3ggPw0KPiANCj4gb3IgaXMgaXQgYSBxdWVzdGlvbiBvZiB0cmFuc2ZlciBvZiByZXNwb25zYWJpbGl0eSBmb3IgdGhlIHNlc3Npb24NCj4gcmVzZXQgPw0KPiANCj4gb3IgaXMgdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhlIHJvdXRlcnMgYmUgaW50ZWxpZ2VudCBlbm91Z2h0IHRvDQo+IHVuZGVyc3RhbmQgd2hpY2ggcHJlZml4ZXMgYXJlICJnb29kIiBhbmQgc2hvdWxkIGJlIG1haW5hdGFpbmVkIGFuZA0KPiB3aGljaCBwcmVmaXhlcyBhcmUgImJhZCIgYW5kIHNob3VsZCBiZSBkcm9wZWQuDQo+IA0KPiBUaGUgbGF0dGVyIGlzIHF1aXRlIGhhcmQgdG8gZGVmaW5lIGFuZCBub3Qgc2ltcGxlIHRvIGltcGxlbWVudCBpbiBhDQo+IGZhaWwtcHJvb2Ygd2F5Lg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIGNsZWFybHkgZGVmaW5lIHRoZSBwcm9ibGVtIGFuZCBleHBlY3RhdGlvbnMgYmVmb3JlIHdlDQo+IHNvbHZlIGl0Li4uIGtlZXAgaW4gbWluZCB0aGF0IHRoZSBtb3JlIGNvbXBsZXggdGhlIHByb2JsZW0gZGVmaW5pdGlvbg0KPiB0aGUgaGlnaGVyIHRoZSBjb3N0IG9mIGEgc29sdXRpb24gKGFuZCB0aHVzIGxlc3MgbGlrZWx5IHRvIGNvbWUNCj4gYWJvdXQpLg0KPiANCj4gICBQZWRyby4gIA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gSWRyIG1haWxpbmcgbGlzdA0KPiBJZHJAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaWRyDQo+IA0KPiANCg==_______________________________________________Idr mailing [email-masked]://www1.ietf.org/mailman/listinfo/idr

---

From: "sun tao" <[email-masked]>
Date: Wed, 12 May 2004 22:32:52 +0800

---

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

Pekka,

> needed but wouldn't object to it being specified as long as it's 

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:53:08 -0700

Jeff,

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 May 2004 09:56:53 -0400

Yakov,

> or draft-keyur-prefixlimit-orf-00.txt) would you favor.

a - I am in favor of this as a IDR WG item.
b - I am abstaining from either approach.

-- 
Jeff Haas 
NextHop Technologies

---

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

Pekka,

Yakov.

---

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

Jeff,

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 May 2004 09:56:53 -0400

Yakov,

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 May 2004 13:24:01 -0400

I have been asked for clarification of my abstention off-list especially
given previous on-list comments.

Of the two approaches, I favor chavali for two reasons:
1. Multiple prefix-limit threshholds.
2. Active signaling when a threshhold is crossed.

I do have concerns about each of the proferred signaling mechanisms
(dynamic capability vs. ORF).  I would like to see these issues
worked through before people start writing code.

So, if the question is which of the general approaches (apart from
implementation or on the wire signalling) I prefer, chavali would have
my vote.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 18 May 2004 13:24:01 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 May 2004 23:14:57 +0300 (EEST)

> or draft-keyur-prefixlimit-orf-00.txt) would you favor.

I'm against accepting prefix limit signalling at this point, though 
not strongly.

These are not strictly required, and we don't have sufficient
understanding/agreement on the different approaches yet.

Different people seem to have way too different opinions on what the
two specific approaches actually entail and what are their
differences.  Even if we chose to go for prefix limit signalling, I'd
have to object at this point to taking either as a WG work item.  We
need to clarify draft-chavali in particular a lot first, so that we
can start talking about different kinds of apples, rather than apples
and oranges.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 18 May 2004 23:14:57 +0300 (EEST)