These Minutes should be considered a rough draft only - Megan 04/03/92
==============================================================================
Notes from BGP WG - San Diego IETF - 3/19/92 9am
[David Bolen -
[email protected]]
==============================================================================
* Discussion of BGP-4 Extensions
The largest portion of the BGP meeting was concerned with the discussion
of the BGP4 document authored by Vince Fuller and Tony Li. The additions
were made primarily to add the necessary support into BGP for classless
inter-domain routing (CIDR).
* IP Prefixes vs. Masks
The need for carrying some form of network masks as part of BGP
was discussed in the light of the need for classless inter-domain
routing (CIDR). The necessary information could be carried either
as a combination of network and netmask, or it could be encoded
as a prefix with a length value.
A key difference between the two proposals is that carrying an entire
mask allows the use of non-contiguous masks, while a prefix requires
that the mask be contiguous.
The general consensus of the group was that non-contiguous masks
presented several problems, especially in routing table lookups
(where multiple entries can match), and in the automatic aggregation
of such masks (which we aren't sure how to do yet, and it's critical
for CIDR). Therefore prefixes, being more deterministic, were a
better choice for BGP-4.
It was agreed that masks could prove useful later when some of the
trickier issues have been dealt with. In that case, they could
always be added to a later version of the protocol.
>> Use prefixes rather than masks.
* Aggregation rules from BGP-4 document
The group discussed the various rules presented in the BGP-4
document to handle aggregation:
* Rule 1 - always do longest match.
* Rule 2 - Inject "poison" routes to avoid loops. In a multi-homed
case, if the aggregator is the primary provider, the
aggregator must also announce the longer prefix for the
client (to override the same announcement via that client's
other provider). If the aggregator is not primary, this
additional announcement is not necessary.
* Rule 3 - Punch hole to sever old route when switching providers.
This requires an announcement withdrawal mechanism in BGP.
In particular, rule 3 was discussed in that it required the addition
of a withdrawal mechanism in BGP to withdraw a previous announcement
(along the lines of the facility provided within IDRP).
The largest concern if this wasn't provided was that packets could
flow partially down a bad path before they were either bounced or
black-holed. Also, traceroute would no longer function properly in
such a case.
The general consensus was that these problems were not critical
enough to warrant the added complexity of the withdrawal mechanism,
especially when interoperability with older implementations of BGP
that didn't have such a mechanism was taken into account.
>> Rules 1 & 2 ok - removing Rule 3.
* Support for AS sets
In order to be able to handle multi-level aggregation, the ability
to specify an AS_PATH that included AS sets rather than simply a
sequence is very important. If AS-1 and AS-2 both flow packets
through AS-3, AS-3 would like to be able to aggregate routes if
AS-1 and AS-2 fall under the same prefix. Since they represent
different AS_PATHs, that is currently not possible.
IDRP was brought up as an example of using sets. In IDRP, the
RD_PATH (like BGP's AS_PATH) is an overall sequence of elements,
where each element is either an RD sequence, or an RD set. An RD
set implies that the packets flow through one or more of the RDs
in the set, but not necessarily all of them, and no order is
specified.
IDRP also provides for the concept of routing confederations, which
is a method for aggregating several routing domains into a single
routing domain confederation (RDC) which is generally treated just
like an RD when it appears in the RD_PATH.
Using confederations was considered more powerful than just sets,
but also more complicated, and not required for the CIDR support
we want to include in BGP-4.
A possibility was just to turn BGP's AS_PATH into a set, which would
imply no particular order of AS traversal. However, this would
prevent any route filtering based on AS order. Matt Mathis suggested
having an AS_PATH that started with a sequence, and was followed
by a set.
This discussion also brought up the fact that the AS_PATHs would
probably be growing as this structure would encourage the size of an
AS to be small, which led to thinking about the assignment of AS
numbers hierarchically in order to allow them to be aggregated
as well. Finally, the discussion turned to whether AS values
should be increased to 32-bit rather than 16-bit. Some people
strongly felt it should be increased in size, especially now as we
were making these other changes.
>> General consensus for requiring sets/sequences, but not
confederations. Stick with 16-bit AS, although moving to 32-bit
at the same time as the AS set change was strongly discussed.
* Parallel BGP sessions
During the discussion, the issue of being able to run parallel BGP
sessions turned out to primarily address the problem of wanting to
filter on an AS wherever it shows up in the AS_PATH, rather than just
the first AS (as is common in current applications). This is an
implementation problem rather than one with the protocol.
The point was made that it can be dangerous to run two BGP connections
in the same host with the only exchange of information between them
being a routing table handled through a common IGP.
Therefore, it was decided that it wasn't worth changing the protocol
to handle what was essentially an implementation issue.
>> Dropped
* NEXT_HOP Handling
The NEXT_HOP discussion centered around the issue of allowing one
BGP peer to pass along the address of some other host on a common
wire as the NEXT_HOP value rather than using its own address.
The knowledge that the other host was available would commonly have
been determined via an IGP (such as OSPF), or by the fact that the
BGP peer was maintaining sessions with both hosts.
Yakov brought up IDRP as an example of this functionality but
under control of the source, which can choose to add additional
options to a NEXT_HOP announcement controlling whether the
recipient can propagate the NEXT_HOP value. This addresses the
multiple BGP session, but not the IGP case.
The concern with allowing this optimization was that the new host
was being included in the NEXT_HOP announcement without it being
aware of its involvement. Under certain circumstances this can
be very useful, but it can also easily violate policy or routing
rules. It deserved some further investigation, but for now (and
at least for BGP-4), it was decided to keep the current definition
of NEXT_HOP.
>> Keep definition/use same as is currently specified.
* BGP/OSPF Interaction Document
A short discussion of the current BGP/OSPF interaction document by
Kannan Varadhan took place. The document is nearing completion, and
only had a few changes since the previous IETF.
* Tag bits
If the upper ("trusted") bit of the tag is set, the tag was
system generated or configured, and the following 3 bits are
used to encode the completeness of the route and how it should
be handled, as follows:
pl 00 01 10 11
c 0 <EGP> <l> <EGP><l,nh> never export reserved
1 <IGP> <l> <IGP><l,nh> out of band reserved
Matt Mathis suggested that the term "trusted" may not be the
most appropriate (it could be taken to imply that the network
administrator isn't trusted). Tony Li suggested the substitution
of the term "automatic" instead.
>> Change "trusted" keyword to something like "automatic".
* NEXT_HOP handling with subnets
This issue dealt with an optimization for handling the case where
you learn a set of routes through OSPF that represented an entire
subnet for a network, and what to assign NEXT_HOP to in that case.
The optimization in question was whether or not you still had to
always place yourself in NEXT_HOP rather than the node through
which the subnets were routed.
It was agreed that this represented an implementation optimization
and should not be dictated by this document, but left to the choice
of the developer.
>> Leave optimization to developers.
A new revision of the document will be published with a fairly short
deadline for comment, so that the document can then proceed through the
standards process.
* IBGP & OSPF Discussion
Jeff Honig held a discussion about possible problems with the use of
IBGP, and how the same information might be propagated through an IGP
(specifically OSPF) rather than with IBGP connections. The main concerns
with IBGP were the need for scaling of N^2 connections, and the bandwidth
utilized for IBGP traffic.
Enhancements to OSPF that were being discussed to be used to carry the
external information included:
- OSPF Variable Tags (to allow the encoding of a complete AS_PATH)
- New OSPF Path Attribute LSA to propagate path/attribute pairs
(to send unique path/attribute information around in separate
packets that were referenced by the route announcements)
During the discussion, the general feeling was that the difference between
IBGP resource usage (N-1 TCP connection blocks on each border router (BR),
and bandwidth) and the resource required to distribute the same information
via an IGP was not significantly different. Also, trying to store external
information in internal routers could cause physical resource problems
(such as memory) for those routers.
One agreed issue with IBGP was router discovery. Using the IGP to aid
the BRs in discovering each other was considered an important feature.
At a minimum, all that would be required is a single flag bit to be
carried by the IGP to indicate that a host was a BR. Ideally several
bits to encode additional information would be useful.
>> General discussion felt that IBGP resource utilization was not
significantly more than that introduced by having the IGP carry EGP
information.
>> Agreement was reached that border router discovery was important and
that some bits (at least 1) should be requested from IGPs such as
OSPF to support this.
* BGP <-> IS-IS Interaction Document
Sharad Sanghi held a discussion on the BGP/IS-IS interaction document
that he and Atul Bansal had authored.
The general issues were similar to the BGP/OSPF interaction document.
The basic question discussed was in regards to the advantages and
disadvantages to doing route injection vs. piggybacking vs. just using
IBGP.
As with the previous IBGP vs. IGP (OSPF) discussion, the group felt
that it was not clear that the savings in resources by eliminating IBGP
and using IS-IS to carry external routing information was worth the
work to transfer the routes.
Router discover was still very useful, so adding bits to IS-IS (which
it already has room to support) is definitely desired. Using IBGP with
these bits for discovery should be fine for stub domains. For transit
systems, it could prove useful to consider the injection/piggybacking
cases, which should be studied further.
