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 - db3l@ans.net]
==============================================================================


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