Re: Comments on RIP-II protocol and MIB specification.

[Fred Baker <[e-mail]>]

>> > this may be a completely silly question:  why do you not want to use
>> > BGP instead of route tags?  it sounds like you're solving the same
>> > problem.

>> You may not want to have to run IBGP on your internal routers, maybe
>> they don't support BGP, or maybe they just don't have the capacity.
>> Or you may have alot of internal routers and just a few external
>> routers.  Full-mesh IBGP connectivity is very expensive when there are
>> more than just a few routers involved.

That I'm not arguing with.  If I understand the underlying concept (and
the posting you made this morning still addresses the mechanism, not
the concept it implements), you have essentially a telco-like
application:  Bigg & Co wants to use a network provided by JeffCo; Small
Potatoes Farms wants to use the same network.  But Small Potatoes Farms
doesn't want to know about - or worry about - Bigg & Co, or for that
matter anyone else that JeffCo wants to sell service to.

Solution (a), common in gated applications, is 
   - build a network that concatenates Small Potatoes Farms and Big & Co.
   - to Small Potatoes Farms, advertise routes they own, but not Bigg & Co routes
   - to Bigg & Co, advertise routes they own, but not S. P. F. routes

Solution (b), build two (or more) networks overlaid on each other, one
belonging to Small Potatoes Farms and one belonging to Bigg & Co, and
both maintained by JeffCo on JeffCo's routers.

Agreed that the former solution (IBGP) is a big deal when the
intersecting permissions are analyzed, but the latter is a big deal
too; IMHO a much bigger one, especially if the concepts and mechanisms
are not spelled out.

I suppose you're thinking "will he ever let up? why's he so bugged
about this?" When the tags and domains were proposed, I thought you
were solving a completely different problem and doing something
completely different.  When I figured out that you and I had completely
different notions, I worked out that there might very well be a third
or fourth possible understanding and use for the mechanisms.
Interoperable? not a chance! Documented well enough for us to discuss?
Well, apparently not well enough for me to understand what you were doing.
Maybe I'm dense.

What I thought you were solving is the classic EGP problem where one
wants to advertise EGP routes into a RIP domain, perhaps propagate them
to another EGP domain, but not propagate them back to the original
domain.  That being the case, the route tag (and here's where the name
came from) would effectively be the autonomous system number the route
was learned from, and at the RIP/EGP interface one would have a simple
filter saying "it's OK to propagate routes from AS <this> to AS
<that>".

Based on that understanding, it was absolutely beyind me why you wanted
a route domain in the RIP message header or why it was in various
places that you want it in the MIB.

OK, now bear with me for a minute:  the EGP problem's solution above
has a hole in it.  The rule is that I cannot advertise into domain A
routes that I learned from domain A.  Suppose that I learn a route both
from domain A and from domain B, and the difference in metric is such
that I never bother to install the route learned from domain A.  In the
above mechanism, I *would* advertise it back to domain A, potentially
getting domain A all confused.

I am concerned that the routing domain architecture that you are
proposing has a related hole.  Imagine that I, in domain D, am
connected to routing domains A, B, and C.  RIP being what it is, it's
not obvious to me that a route to <foo> learned from domain A might not
override a route to the same place learned from domain B.  If it is OK
to leak routes from B to C but not from A to C, the route to <foo> will
not be leaked, because domain B's route was flushed.  Domain C will
therefore not have access to <foo> even though it should.

Now, maybe you've got a solution to that tucked away; if so, I'd like
it documented.  It *is* part of what you expect RIP-II to do with the
routes, and if it's not specified differing implementations will do
something different.

Fred