Subject: On BGP and VPLS

From: Pedro Roque Marques <[email-masked]>
Date: Sat, 3 May 2003 01:05:20 -0700 (PDT)

[crossposted to idr WG mailing list]

Alex Zinin writes:

>  More specifically, below I tried to put together a list of concerns
> I have about the approach described in draft-kompella-ppvpn-vpls,
> that I would like the WG to consider.

>  1. Use of the NLRI field

>    As an IP routing protocol, BGP uses the NLRI field to carry IP
> reachability information in the form of IP prefixes. Prefixes within
> the NLRI field are used for two main purposes in BGP: a) as the
> destination/mask pair in the routes installed by BGP in the routing
> table, and b) as a handle to an entry in the BGP RIBs.

>    The document in subject changes the semantics of the NLRI field
> quite substantially even when compared to 2547. First, all of its IP
> prefix-related properties are lost. There is no more IP routing, or
> any addressing information in it. Second, the notion of TLVs is
> introduced inside this field, which a) is not needed in BGP as an IP
> routing protocol, and b) because of its variable length property
> changes the nature of the NLRI contents, i.e., it's being a stable
> handle in the BGP database. To solve these problems the
> implementations would need to use only a part of the contents of the
> NLRI field as the handle used to index within the RIBs, and store
> the rest as attributes.

Alex,
This point seems to be predicated in the statement that "BGP uses the
NLRI field to carry IP reachability"...

It opens up a sort of philosophical discussion on BGP. This is of
course a highly subjective topic which is hard to quantify or to prove
by logical terms.

Allow me to present my personal view.

BGP is a particular implementation of an algorithm that performs non
looping database flooding distribution. That algorithm consists mostly
on the path vector (used both in ebgp and route reflection) plus route
advertisement rules. This is the publicly specified part of the beast.

However that ends up being about 10% of the database exchange
algorithm. Each implementation uses distinct algorithms to do the real
heavy lifting: the advertisement of database updates to its peers,
given that each peer is allowed to flow control and that the ammount
of information to be distributed is typically non-trivial compared to
the resources of the system.

None of the functions above actually do depend on the format of your
database records. As long as there is a primary key associated with
each record. Modern implementations, given that they are required to
handle 3/4 different types of records w/ different keys (ipv4, ipv6,
2547, 2547-for-ipv6, etc) will tend to treat these keys just as
database systems do: as a bit string without any semantics associated
w/ it.

Note also that the number of distinct tables exchanged in a 2547
implementation may be in the thousands. So segregation of which record
belongs to which table is necessarily a solved problem in practice.

There is one part of BGP that however interacts w/ the semantics of
the particular database being exchanged: route selection from the
Loc-RIB.

The Loc-RIB is by definition where BGP interacts w/ remaining users of
the database and it includes rules that are system specific.

As an exercise, if we take the existing spec and do:
s/route/record/g
s/IP prefix/key/g

Do we still have a document that makes sense.. ?

Except for the vague bits about aggregation, about which BGP itself
does little about, i would contend that the result would be pretty
much the same.

2547 which you cite is a particular good example, imho. A 2547 NLRI
ends up being used to create IP reachability information, but while it
is a safi 128 record, it is not IP reachability and it is not treated
as such.

>  2. Distribution of information

>    When used as an IP routing protocol, BGP distributes routes among
> all participating routers. Each router (PE or P using VPN
> terminology) is interested in _all_ routes received from its peers;
> it selects the best path for each prefix if multiple are available
> and installs it in it's routing table; the best paths are propagated
> further to other peers.

That is not the case w/ 2547. PE routers typically have interest in
only a subset of the routing information. They tend to do inbound
filtering in current network deployements but one can also do outbound
filtering in the RRs via either extended-community ORF or subsequent
improvements to ORF (draft-marques-ppvpn-rt-contrain).

P routers do not carry 2547 routing information.

>    The way BGP is used in the document results in a situation where
> information relevant only to a subset of routers (e.g. PW-specific,
> or VPLS-specific info) is sent to all PEs participating in the BGP
> domain. More than that, P routers, usually used as route reflectors
> in IP routing, end up storing all information while they are not
> using any of it locally.

RR in VPN deployments are typically not in the topology. My
understanding of the P-router term is that it is a transit node that
does not have VPN information.

>    Note also, that best path selection that is normally performed by
> BGP when it receives information about the same prefix from multiple
> peers, is not needed in the VPLS case, and (even if implementations
> decided to apply the same algo as in regular BGP) would just be an
> artifact.

Not really... i can advertise the same key from multiple sources in
L2VPNs also. All policy mechanisms do work... igp distance, etc. It is
just the semantics once the path is selected that are different.

As an example think working and protect PE for a given emulated
circuit (or lan).

>    The above exposes the difference between the routing nature of
> BGP when used for IP (where reachability info is distributed and the
> path properties are as important as the info itself), and its purely
> transport application in the proposal (where only the fact of
> information delivery is important.)

>    Interestingly enough, from the transport perspective, BGP, though
> reduces the number of sessions a given PE has to maintain (and thus
> the sender's complexity), introduces additional overhead from the
> receiver's perspective--if a PE router has multiple BGP sessions
> (which is normally the case), it will receive the same information
> more than once, while clearly a single copy is enough.

I don't know which model you have in mind but in a typical VPN
deployment scenario (l3 or l2/vpls/etc) a PE has 2 peering sessions to
a RR outside of the topology. The second copy of the information is
there for redudancy...

If a full mesh where used, only 1 copy would be present.

>  3. Aggregation of information for large-scale operation

>    When distributing information among a large number of systems, it
> is important to be able to aggregate information as it travels
> further ahead to ensure scalability of the system. In routing this
> is achieved by summarizing a set of prefixes and announcing them as
> a less specific prefix. For example, AS'es in the Internet do not
> exchange granular IP prefixes visible inside IGPs, but instead send
> each other aggregate prefixes via BGP.

>    It is not clear to me how, given the format of the NLRI field,
> VPLS information can be aggregated using the proposal in the
> document.

To give you an example, in JunOS aggregation is implemented as a
separate routing protocol... if i'm not mistaken the model is lifted
from 'gated'. Clearly the idea that aggregation may be a distinct
component from BGP has been around for a while.

VPLS doesn't really need aggregation although it does use an IGP :-)
PE to PE connectivity is performed indepently from the 'forwarding
distinguisher' advertisement (i.e. the inner label). Any or multiple
routing and singaling protocols may be used for this
functionality. Only the information exterior to the SP network
(service attachements) is carried through BGP.

>  The above gives me a very uncomfortable feeling that the proposal
> is stretching BGP to perform functions it was not designed for.

Any succesful protocol will be used for means other than it was
designed for. That is usually a sign that the designers got something
right.

Let me give you an example: BGP is currently used to block spam
propaggating networks/hosts. What this an original goal of the design
? Hardly. When used to block spam BGP does not advertise any valid
forwarding information for instance. And i'm sure it is a question of
time until we add port information to the record keys.

>  Below are some additional points that should be taken into
> consideration.
   
>  4. Backwards compatibility and SW upgrade requirements

>    Because the proposal suggests using a new AFI/SAFI combination,
> PE routers will not be able to announce VPLS information using the
> existing BGP infrastructure. All BGP speakers in a SP's network,
> including the P routers, will have to be upgraded with new SW,
> though information needs to be exchanged only among the PEs.

That is not an issue as we've seen above. The deployment model is
different from what you assume.

>  5. Coupling of VPLS and BGP SW

>    Putting VPLS-related functions in BGP leads to two unwanted
> consequences:

>     a) Lesser BGP code stability--bugs in the VPLS part of the code
> will likely affect parts of BGP used for Internet routing, thus
> increasing the chances of BGP failures in SP networks.  The same
> argument works in the opposite direction.

You have no basis to conclude that.

Any modern BGP implementation worth its salt consists of
AF-independent code + AF-specific code. The fact is that you can
implement VPLS without touching the AF-independent code.

Any line of code change that you make to an implementation as the
potential to introduce bugs... 

>     b) Potential dynamic effects--since with a BGP-based approach,
> VPLS- and routing-related processes are likely to share the same
> internal router resources (such as timers, threads, locks/mutex'es,
> queues, memory pools), dynamics of the VPLS system are likely to
> influence the dynamics of the routing- related functions and vice
> versa. The larger the overlap between the two systems, the higher
> are the chances of such interference.

I'm sorry but this is just FUD.
All router implementations do have some level of resource sharing
between completly unrelated features. In some of them, all
functionality shares all resources.

Don't want BGP sharing timers w/ X.25-over-TCP... disable one of them.

>  My recommendation would be for the WG to consider these points.

The way i see it there is an high likely-hood of this turning into an
"Yes, it is" "No, it isn't" discussion. And I'd really like to avoid
that.

A question to you and to the WG(s) in general:

- What are the main concerns that you have w/ the generic database
exchange view of BGP (Lets call it the "Basically General Purpose"
theory).

- Can we have a reasonable discussion about the best engineering
approach to provide database exchange services for
routing-related-applications without getting into a religious argument
about "2547 is evil" ? i.e. can we try to separate how highly each one
of us rates the actual application from this discussion ?

- I believe one of the preconditions for a resonable discussion is to
realise that implementors are the most interested people in not
introducing regressions to shipping code. They actually get to fix it
after being screamed at for a considerable lenght of time.
I'd really like to get past the "you can't implement a feature i don't
want because your are going to break the code" kind of discussion.

- Are we going to have a similiar discussion about LDP ? LDP is not
any less relevant for network stability nor a protocol which is any
simpler than BGP (if anything the level of complexity is higher given
that LDP has all the db exchange problem of BGP + a non trivial
ammount of issues of its own).

regards,
  Pedro.

---

From: Alex Zinin <[email-masked]>
Date: Wed, 7 May 2003 11:28:15 -0700

Pedro,

Sorry for the delay. I found your message in my IDR folder just
recently. I'll limit my involvement to this message, I think I will
have said enough for my opinion to be heard :)

> NLRI field to carry IP reachability"...

Yes, plus that "BGP is an IP routing protocol."

> advertisement rules. This is the publicly specified part of the beast.

This is where we disagree in the first place.

There's a fine line between a database distribution flooding algorithm
and a path-vector routing algorithm. BGP is clearly not the former.

> Do we still have a document that makes sense.. ?

I'm not sure :)

> does little about, i would contend that the result would be pretty

You are forgetting the parts about Loc-RIB, routing and forwarding
tables, next-hop, etc. In any case, such a beast would seize to be an
IP routing protocol, but would still perform best path selection to an
opaque key in the Internet. If you need a database distribution
mechanism as you described above, you don't need the path vector
behavior, nor per-peer state for each key, nor next-hops. I.e., you
don't need what BGP does.

> is a safi 128 record, it is not IP reachability and it is not treated

2547 augments _IP prefixes_ with route distinguishers only to make
sure that the prefix is unique when used as the key in the RIB. The
rest of the reachability/prefix semantics are preserved.

> improvements to ORF (draft-marques-ppvpn-rt-contrain).

Note that I purposely compared the approach in the document with
the base BGP, not 2547.

> P routers do not carry 2547 routing information.

Unless the SPs want to use the existing RR infrastructure.

> does not have VPN information.

Agree, they don't have to. The text should have been "More than that,
route reflectors (in some cases implemented on P routers) end up..."

> As an example think working and protect PE for a given emulated

I think you might have missed my point here. Though a BGP speaker will
receive the same key from multiple sources, and will select the best
path to it, in the VPLS case, it is not interested in the _best_ path,
it is interested in only receiving the key, regardless of where it
comes from.

> If a full mesh where used, only 1 copy would be present.

So RR and eBGP are the examples where a given BGP speaker would
receive extra copies of information. As I replied to Mark:

    Well, in the IP/BGP case, it is not necessarily the same info,
    as path attributes are likely to be different and the BGP
    speaker is interested in selecting the best among them while
    preserving others as the back-up. In the VPLS case, we don't
    need the best, just one copy is sufficient.

    This is not necessarily an issue per se, rather an interesting
    observation exposing the transport nature of this particular
    proposed application of BGP. We have similar properties (more
    than one copy received) in the flooding algorithm in IGPs, but
    we admit that flooding is a transport component very specific
    to IGPs (where every node needs all info, btw), and we don't
    keep track of where we receive PDUs from as we do in BGP.

>>  3. Aggregation of information for large-scale operation
...
> component from BGP has been around for a while.

This does not change the fact that information that BGP as an IP
routing protocol distributes is aggregateable. Also note that route
aggregation rules are part of the routing protocol specification and
definitely depend on the protocol behavior (true for BGP, OSPF, and
ISIS), so it is not a completely distinct notion, though some
implementations decouple the two.

> (service attachements) is carried through BGP.

This part should go into the thread on "Info Summarization" where one
of the questions is how we can limit the amount of state/information
that a given participating node will have to maintain.

I'd like to again highlight the difference between aggregateable
semantics of NLRI contents in BGP when used as IP routing protocols,
and non-aggregateable semantics of it in the proposal, which means
that mechanisms different from those existing in current BGP practices
would need to be used to limit the amount of maintained info.

> designed for. That is usually a sign that the designers got something

I was being mild.

> different from what you assume.

As before, unless the SPs want to use the existing RR infrastructure.

> You have no basis to conclude that.

I do :)

> implement VPLS without touching the AF-independent code.

The fact is that pieces of code in routing protocol implementations
are not only statically related via the function call tree, but also
dynamically and indirectly... but I will stop right here, because
we'll inevitably get into implementation specifics...

> I'm sorry but this is just FUD.

I hope people don't think about potential interference between large
distributed systems as FUD.

> functionality shares all resources.

Agreed, though I was talking about tighter coupling when Inet BGP and
VPLS BGP are in the same process/thread (which is very likely the
case). As I told in my answer to Mark:

   I tend to look at this more broadly--putting VPLS
   functionality in BGP increases the chances of interference.
   Some consider this a strictly implementation-specific issue.
   I think that whether or not VPLS-specific functionality is
   sufficiently decoupled from base BGP is an implementation
   aspect; while increased risk of interference is an architectural
   one.

Again, I'll stop here too.

> "Yes, it is" "No, it isn't" discussion. And I'd really like to avoid

Agreed.

> exchange view of BGP (Lets call it the "Basically General Purpose"

The fact that BGP is not a generic database exchange protocol,
and I don't think it should be positioned as such.

> of us rates the actual application from this discussion ?

I think we'll have to agree on the definition of "database exchange
services" and "routing-related-applications", but generally, yes,
sure.

> want because your are going to break the code" kind of discussion.

I think there is a generally good understanding of this. I don't think
this is something that is sufficient for the IETF to base technical
conclusions on.

> ammount of issues of its own).

I have absolutely no problem with this.

Thanks for your comments.

Alex

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 13:30:24 -0700 (PDT)

Alex Zinin writes:

> Pedro, Sorry for the delay. I found your message in my IDR folder
> just recently. I'll limit my involvement to this message, I think I
> will have said enough for my opinion to be heard :)

Alex,

>> The way i see it there is an high likely-hood of this turning into
>> an "Yes, it is" "No, it isn't" discussion. And I'd really like to
>> avoid that.

> Agreed.

It seems to me that we immediatly got into this dead-lock point. Allow
me to make a further attempt to clarify my point of view.

>> This point seems to be predicated in the statement that "BGP uses
>> the NLRI field to carry IP reachability"...

> Yes, plus that "BGP is an IP routing protocol."

That is one possible application of BGP. It does not invalidate that
possibility of other applications.

Let me rephrase my point:

It is possible to extract from the BGP specification a common set of
functionality that is independent of 'IP routing'. Such common set of
functionality consists on the ability to flood databases of
information accross multiple domains, in a distributed fashion.

Since this problem reoccurs often in networking, several other
applications have made use of this commonality to avoid reinventing
the wheel.

The 'common functionality' in question is not so much what is
documented in the BGP specification but the algorithms required to
implement it.

> There's a fine line between a database distribution flooding
> algorithm and a path-vector routing algorithm. BGP is clearly not
> the former.

"Yes, it is" :-)
Give me an argument and i'll try a more productive response.

>> s/route/record/g s/IP prefix/key/g

> tables, next-hop, etc. In any case, such a beast would seize to be
> an IP routing protocol, but would still perform best path selection
> to an opaque key in the Internet. If you need a database
> distribution mechanism as you described above, you don't need the
> path vector behavior, nor per-peer state for each key, nor
> next-hops. I.e., you don't need what BGP does.

You repeat this argument throughout your e-mail. And i'm completly
missing your point:

The path-vector algorithm is essential to the flooding of the BGP
database information. Without it flooding would eternally loop.

path-vector as in:
 o as-path and cluster-list loop detection
 o iBGP doesn't advertise iBGP

This is what makes BGP flooding work. None of this information is used
for Loc-rib purposes.

>>>  2. Distribution of information

[...]

> Unless the SPs want to use the existing RR infrastructure.

All the SPs i've worked with explicitly do not want to do this.

>> L2VPNs also. All policy mechanisms do work... igp distance, etc. It
>> is just the semantics once the path is selected that are different.

> I think you might have missed my point here. Though a BGP speaker
> will receive the same key from multiple sources, and will select the
> best path to it, in the VPLS case, it is not interested in the
> _best_ path, it is interested in only receiving the key, regardless
> of where it comes from.

That is factually incorrect. I gave you an example in the original
e-mail to illustrate the point. The same 'key' maybe advertised from
more than one source. BGP needs to select the best-path in any such
occurence.

> as path attributes are likely to be different and the BGP speaker is
> interested in selecting the best among them while preserving others
> as the back-up. In the VPLS case, we don't need the best, just one
> copy is sufficient.

That is incorrect.

PE1 advertises 'key' preference 100, label 10000 - this is working
circuit.
PE2 advertises 'key' preference 200, label 10001 - this is protect
circuit.

It works just like IP routing. All the preference mechanisms that you
use in IP routing can be used here. IGP failure to PE1 for instance,
causes a remote system to automatically reroute.

> routing protocol distributes is aggregateable.

That doesn't mean that BGP does aggregate anything either. BGP doesn't
specify any algorithm for aggregation itself. What BGP does address is
the interaction between possible aggregation and its loop detection
mechanism.

> Also note that route

BGP does not specify any rules for what routes should be aggregated or
into what they should be aggregated. It cannot since these are
operational decisions.

The statement above is false as far as i can understand it.

> I do :)

Please present a justification then.
We are back to "no, it isn't" / "yes, it is" mode.

> we'll inevitably get into implementation specifics...

This is what i call FUD...
"Uncertainty" not being backed by any argument.

The way i see it this is a central piece of your (IESG) original
"concern" statement.

> distributed systems as FUD.

You are wording it just that way: "potential interference between large
distributed systems".

No facts, no specific points. Just vague allegations.

If the above is "fair game" then i want to ask the IESG to use the
same "potential interference" criterium to, say, IPv6...

IPv6 not only involves changes to BGP to support this NLRI but changes
to all hosts and pretty much all protocols and applications. It can
"dynamically and indirectly" cause interference too.

Perhaps IPv6 is a treat to the internet stability ? Since i don't
intend to run IPv6 in the forseable future it standardization of IPv6
is going cause 'interference' with my workstation software, which
i rather not deal with.

>    I tend to look at this more broadly--putting VPLS functionality
> in BGP increases the chances of interference.  Some consider this a
> strictly implementation-specific issue.  I think that whether or not
> VPLS-specific functionality is sufficiently decoupled from base BGP
> is an implementation aspect; while increased risk of interference is
> an architectural one.

I believe that this completly confuses architecture with
implementation.

This is not an architectural consideration. This is a vague aspersion
on the competency of BGP implementors.

Your argument taken to the extreme would result in forbidding all and
any standardization of new software mechanisms.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 13:58:58 -0700 (PDT)

>> Agreed.

Following up on my own e-mail... i don't think it is in any way
productive to continue the discussion torwards this path.

Lets try to turn the discussion around to the positive side:

Ignore VPLS for now.

Lets define a problem:

1. A database consisting on entries (key, attr) needs to be propagated
accross routers of the same domain and accross different
administrative domains.

2. An given key may be originated by more than one of the
participating systems.

3. A key advertised via a given member of a domain depends on
reachability to that advertiser.

Task at hand is to find a solution to the problem above.

  Pedro.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 07 May 2003 17:06:04 -0400

Pedro,

This is the BGP4 base spec.  The interpretation of the BGP
advertisements are IP prefix aka NLRI for which routes are advertised
and not general keys mapping to general records.

If some extension of BGP4 such as VPN or PW makes some other use of
BGP flooding then that's fine but need not be reflected in the base
document.

The changes that you are only vaguely specifying (s/route/record/g
s/IP prefix/key/g) doesn't at all pertain to the use of BGP as defined
in the base spec, hasn't been interpreted as being in conflict with
any existing document, and I don't think this is a productive
discussion during last call of a very key document.

Curtis

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 7 May 2003 14:15:39 -0700 (PDT)

> advertisements are IP prefix aka NLRI for which routes are
> advertised and not general keys mapping to general records.

> s/IP prefix/key/g) doesn't at all pertain to the use of BGP as
> defined in the base spec, hasn't been interpreted as being in
> conflict with any existing document, and I don't think this is a
> productive discussion during last call of a very key document.

Curtis,
In no way i was suggesting that we change the base spec.

My argument is that the flooding algorithm in the BGP spec is
applicable to other NLRI-types. And that the document can be, and has
been sucesfully used to do so. i.e. it is still a coherent document
when you interpret it in the context of a different NLRI-type.

regards,
  Pedro.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 07 May 2003 17:20:25 -0400

In message <[email-masked]>, Pedro Roque Marqu

Pedro,

You are welcome to consider BGP for this key distribution even if the
BGP spec does not match the terminology you are looking for.  The
terminology would not be the deciding factor.  If there are technical
problems with whatever you propose, that is a separate matter.

Now please drop IDR from the Cc and go about doing the ppvpn work,
whether it is VPLS or selecting a mechanism for your hypothetical
key/attr distribution.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 07 May 2003 17:45:48 -0400

In message <[email-masked]>, Pedro Roque Marqu
> when you interpret it in the context of a different NLRI-type.

So you are not suggesting a change at all to BGP4.  If so you don't
need to involve the IDR WG in a semantic discussion.

If the issue is whether to use BGP4 for distribution of VPLS
information and the objection were along the lines of scaling, or some
other technical matter then that was not at all clear.  

Unless I missed something, IDR was added to the Cc mid discussion.  If
so, maybe you should tell us what draft you are discussing and be
clear about what the issue is.

Curtis

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 12 May 2003 09:56:37 -0400

On Wed, May 07, 2003 at 02:15:39PM -0700, Pedro Roque Marques wrote:
> applicable to other NLRI-types.

You could flood it using NNTP too.  It doesn't mean its the One True
Answer.  I think that is most of Alex's point.

> And that the document can be, and has

There comes a time when you're just distributing too much stuff
in one protocol and take too many chances at destabilizing what
sort of works well.

I'm not saying that VPLS is like this, having never read the specs.
But it'd be nice for everyone that wants to "co-opt just another little
piece of BGP because it works" that maybe you should start from
the spec, get your own TCP port and flood the stuff in parallel.

Same kind of basket, just different basket.  Hopefully fewer broken
eggs.

Now I know what the DNS folk feel like.

-- 
Jeff Haas 
NextHop Technologies

---

From: Eric Rosen <[email-masked]>
Date: Mon, 12 May 2003 14:08:41 -0400

Jeff> But  it'd be  nice for  everyone that  wants to  "co-opt  just another
Jeff> little piece of BGP because it works" that maybe you should start from
Jeff> the spec, get your own TCP port and flood the stuff in parallel.

I think a vendor would be unlikely  to "start from the spec".  A more likely
implementation strategy  would be to allow  BGP connections on  both the old
port and the  new port.  Capability advertisement or  ORF or something would
be  used  to  choose  which  kind  of  info  gets  forwarded  on  which  BGP
connections.  

Of course,  one day  someone would notice  that this might  require multiple
parallel TCP connections  where a single one might do just  as well.  So the
suggestion would probably be made that,  as an optimization, one could use a
single port,  but encode the  different kinds of  data as NLRI  of different
address families.

So saying "use a different port" doesn't really make the problem go away.

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 12 May 2003 14:25:46 -0400

Aside from noting that sctp would be a fine way to do the multiple
streams, I think all of my issues have relatively little to do with
technical issues and are really implementation/operational ones.

If its reachability you're flooding, and the information changes
on a hop-by-hop basis, BGP is fine.  If you flood more than one type
of reachability, you get to make hard choices such as which reachability
do you want to converge faster and if you start exceeding the resource
bounds of your router, which information do you toss?

The more that you cram into one package, the more rope you give people.
Feedback from several network operators often makes me think we've already
given them too many chain-lengths of rope. :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 13 May 2003 09:15:20 +0200

At 2:25 PM -0400 5/12/03, Jeffrey Haas wrote:
>If you flood more than one type

OK, but this is orthogonal to whether you carry said information in 
BGP or some other protocol, since they're all sharing the same 
resources.

By the way, I think this use of the term "flooding" is rather 
unfortunate since it already has a well understood meaning in the 
routing protocol context, and it suggests link-state.

--John