[804] in Commercialization & Privatization of the Internet
BGP masks
daemon@ATHENA.MIT.EDU (yakov@watson.ibm.com)
Mon Jun 3 09:39:11 1991
Date: Mon, 3 Jun 91 09:36:12 EDT
From: yakov@watson.ibm.com
To: ietf@isi.edu, com-priv@psi.com
Cc: hwb@sdsc.edu, almes@rice.edu, dennis@CAnet.CA, dave_katz@merit.edu
Supporting masks in BGP was discussed before within the BGP WG.
Here are the opinions of Hans-Werner Braun, Dennis Ferguson, Guy Almes
and Dave Katz on this subject that were posted to the BGP mailing
list. Please note that all the above people spend fare amount
of time looking at this issue, and are well familiar with
inter-AS routing in general, and BGP in particular.
Hans-Werner Braun:
------------------
More seriously, though, while this may be an interesting idea,
we should only require an implementation if it would at least
help a few percent of the applications (users). Now, how many
people have their net numbers distributed in a way that they
could apply super-net masks? What I am getting at is that
someone (you?) perhaps better write some guidelines for the
SRI-NIC as to how to distribute net numbers so this feature
may be useful for more than half a percent (or whatever) of
the net number users.
... but I am concerned about fixing bits and pieces without having
a higher level architecture to support it. The simplest way, perhaps,
of accomplishing an architecture would be to give SRI-NIC
guidelines of how to assign net numbers in this "new"
environment, and also to give advise to the clients of how to
use net numbers. Right now methinks it is all pretty
arbitrary. I don't think it would be more than a few page RFC
and therefore not very much effort.
I have no problems with net masks in general, but would like to see an
architecture document to design it before requiring every
protocol to support it. In the BGP case we are talking about
Inter-AS routing, likely between clusters of network numbers,
which is where my comments regarding the net number
distribution were coming from. If certain things could be
rationalized by using network number masks as a vehicle, great!
But, really, someone needs to sit down and think about the
"how," prior to possibly making mistakes in the protocol
evolution. So, it makes me a little uncomfortable to see
protocols instrumented with fields which's implications are not
well understood. I can think of other fields that would be nice
to have, but where the utility and architecture should be
investigated first for working at a global scale.
Dennis Ferguson:
----------------
I do think, however, that the important things to note about discussion
so far are that (1) variable net masks aren't necessarily simple,
(2) if you make rules which constrain them to be simple you run the
danger of throwing out the baby with the bath water, and (3) there
isn't really any wide agreement on what it is that variable net masks
should do for us other than that BGP should "support" them.
I think that if we're going to do variable net masks we should
make sure we do them "right". This is going to take some work since
it seems really unclear what "right" is at this point.
This is all fine, and in fact I'd enjoy the chance to help figure
out what "right" is since the whole topic is pretty interesting.
On the other hand, I'd object strongly to modifying BGP's packet
formats in any way to this end without having a clear idea of what
the modifications are intended to achieve. Including mechanism in
the absense of policy is not a way to do good protocol design (it's
like writing code without having a clear idea of what the program
is supposed to do). It invites people to use the mechanism in ways
which won't interoperate, and may not save you a protocol revision
in future when you finally establish the policy you wish to implement
and realize the mechanism you added in ignorance was the wrong thing
to do.
I think that BGP3 does what it is supposed to do, that is what it
was designed to do. It has been implemented, and iterated, and
implemented again, and is believed to be bug free. And it fixes
things that are broken right now. I think BGP3 is beyond the
"platform for redesigning Internet routing" stage, it really
needs to be wrapped up and moved out there. This will give the
breathing room we need to step back, set some new design goals,
and do a good job of BGP4 and any associated changes to the IGP
and/or forwarding code needed to support it.
Dave Katz:
----------
I once included myself in the group of people wondering why
BGP doesn't support masks, given Merit's experience with
having two CICnet connections. However, spending a whole lot
of time recently thinking about IDRP has convinced me that it
is a much tougher problem than people think. Part of BGP's
simplicity stems from the flat IP address space, and passing
masks around fundamentally changes the whole idea. And if you
simplify the issue by barring aggregation, then you've only
made the address space problem worse, at least for backbone
networks (just what we need--another thousand subnets to
advertise!)
My feeling is that BGP3 should go forward more or less as-is,
lest nothing ever get standardized. Dennis pointed out that
the issue of masks is much hairier than people realize, and it
is likely to add months (at least) to the process if masks are
added, not to mention that it is a significant technical
change to the protocol that should rightly throw it back to
Proposed Standard status.
Those who want masks and all that wizardry should support
dual-stack IDRP, which will do virtually everything that
people want (except for maybe healing partitioned ASs, but if
people are starting to break up their networks into
semi-autonomous subnets, then perhaps it is time to revisit
the concept of an AS again).
Or they could watch what happens with IDRP and then create an
incompatible BGP4 (at least so that the fields are word
aligned!) and have it proceed separately in the standards
track from the current BGP. But I think the time is nigh to
stop tweaking BGP so that it can be widely implemented and
deployed.
Guy Almes:
----------
I'm enjoying this discussion fo BGP-with-masks. The ideas
are interesting and the time will come when the motivation,
particularly relating to address space conservation, will be
compelling. It will take us some time to get these ideas
right, and we'll eventually *need* to have them right.
In the meantime, it's clear to me that we need to get BGP-3
(w/o masks) out the door and into the field. We will not be
able to get the mask ideas right in time to meet the BGP-3
timing. In parallel, and without slowing down the BGP-3 development,
I encourage going ahead with discussion of BGP-with-masks.
We should grow in clarity about what it's for, its
implications, and how it fits into a more general plan for
improving the IP address space.
We are likely (I conjecture) to learn some things that will
contribute to how the NSAP space is maintained.
