Subject: Re: a different proposal for ipv6 in bgp
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Mon, 30 Dec 1996 18:41:51 -0800 (PST)

It is not my experience (probably mach more limited than yours ;).  I
   guess it depends how extensively a particular ISP uses the
   "administrative filters". 

Agreed.  As this is under human control it's essentially unbounded
anyway...  Sigh. 

Tony

- - - - - - - - - - - - - - - - -

Posted-Date: Mon, 30 Dec 1996 18:36:42 -0800 (PST)
Date: Mon, 30 Dec 1996 21:33:43 -0500
To: Tony Li <[email-masked]>, [email-masked]
From: Dimitry Haskin <[email-masked]>
Subject: Re: a different proposal for ipv6 in bgp
Cc: [email-masked]
Sender: [email-masked]

At 05:59 PM 12/30/96 -0800, Tony Li wrote:
>
>   I can't say for all, but for some ISPs the size of BGP policy database
>   way exceeds the size of all other bgp data structures including RIB and
>   hence is a real issue. 
>
>That's a very interesting claim and I'd like to understand it in more
>detail.  Could you precisely define what the "policy database" is?  Are we
>just talking about the administrative filters?

Yes, the "policy database" for me is what is the "administrative filters"
for you -- the same thing.

> Or are we talking about database of paths?

And this too.  

> If the latter, are AS path strings separated from the RIB?

In the implementation that I'm familiar with, they are (probably the
true answer depends on how we define the RIB boundaries).
Also there are the regular expression storage which clearly
sits within the policy database.

>
>In one particular implementation that I'm familiar with, the dominant
>memory consumer is the RIB, and that's by several orders of magnitude.  In
>that implementation, the AS path strings are separated from storage in the
>RIB.
>

It is not my experience (probably mach more limited than yours ;).  I guess it
depends how extensively a particular ISP uses the "administrative filters".

>Tony

Dimitry

- - - - - - - - - - - - - - - - -

Date: Mon, 30 Dec 1996 17:59:58 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: a different proposal for ipv6 in bgp
Sender: [email-masked]

   I can't say for all, but for some ISPs the size of BGP policy database
   way exceeds the size of all other bgp data structures including RIB and
   hence is a real issue. 

That's a very interesting claim and I'd like to understand it in more
detail.  Could you precisely define what the "policy database" is?  Are we
just talking about the administrative filters?  Or are we talking about
database of paths?  If the latter, are AS path strings separated from the
RIB?

In one particular implementation that I'm familiar with, the dominant
memory consumer is the RIB, and that's by several orders of magnitude.  In
that implementation, the AS path strings are separated from storage in the
RIB.

Tony

- - - - - - - - - - - - - - - - -

Posted-Date: Mon, 30 Dec 1996 17:50:57 -0800 (PST)
Date: Mon, 30 Dec 1996 20:47:58 -0500
To: Tony Li <[email-masked]>
From: Dimitry Haskin <[email-masked]>
Subject: Re: a different proposal for ipv6 in bgp
Cc: [email-masked]
Sender: [email-masked]

Tony,

At 04:22 PM 12/30/96 -0800, you wrote:
>
>One of the thoughts that we had for IDRP for IPv6 was that the domain
>identifiers (aka big AS numbers) should be easier to manage.  To do that,
>we thought that taking an IPv6 address from your assigned prefix would be
>sufficient.  This effectively eliminates administration of a number space.
>
>I'd strongly recommend that if folks wanna "fix" the AS number problem that
>they consider this solution (or something similar).
>
>Tony
>

I briefly considered this solution.  The problem is that the current BGP policy
databases, as used by ISPs, heavily relies on AS numbers and regular expressions
that operate on AS_PATH strings.  I can't say for all, but for some ISPs the
size of
BGP policy database way exceeds the size of all other bgp data structures
including RIB
and hence is a real issue. Thus increasing the size of AS number 8 times to
its current size was quite questionable to me.  But it is for the WG to decide.

Dimitry

- - - - - - - - - - - - - - - - -

Date: Mon, 30 Dec 1996 16:22:54 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked] (John W. Stewart III)
Cc: [email-masked]
Subject: Re: a different proposal for ipv6 in bgp
Sender: [email-masked]

One of the thoughts that we had for IDRP for IPv6 was that the domain
identifiers (aka big AS numbers) should be easier to manage.  To do that,
we thought that taking an IPv6 address from your assigned prefix would be
sufficient.  This effectively eliminates administration of a number space.

I'd strongly recommend that if folks wanna "fix" the AS number problem that
they consider this solution (or something similar).

Tony
- - - - - - - - - - - - - - - - -

Date: Mon, 30 Dec 1996 16:39:23 -0500 (EST)
From: Dave Wreski <[email-masked]>
To: Paul Ferguson <[email-masked]>
Cc: [email-masked]
Subject: Re: General info
Sender: [email-masked]

On Mon, 30 Dec 1996, Paul Ferguson wrote:

> For what its worth, cisco maintains a 'BGP4 Case Studies/Tutorial',
> located at:
> 
>  http://cio.cisco.com/warp/public/459/18.html

Perfect.  Just what I needed.
Thanks,
Dave

-----------------------------------------------------------------------
"The opinions expressed here are my own and do not represent the views
or opinions of United Parcel Service, Inc."
-----------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

Date: Mon, 30 Dec 1996 16:29:43 -0500
To: Dave Wreski <[email-masked]>
From: Paul Ferguson <[email-masked]>
Subject: Re: General info
Cc: [email-masked]
Sender: [email-masked]

For what its worth, cisco maintains a 'BGP4 Case Studies/Tutorial',
located at:

 http://cio.cisco.com/warp/public/459/18.html

- paul

At 04:21 PM 12/30/96 -0500, Dave Wreski wrote:

>
>Hi all.  I am interested in general info, other than the RFC's on BGP.  Is
>there a general BGP faq?  (ie, is it supported in gated, will my router
>handle it, etc).
>
>Thanks much for any info,
>Dave Wreski
>

- - - - - - - - - - - - - - - - -

Date: Mon, 30 Dec 1996 16:21:45 -0500 (EST)
From: Dave Wreski <[email-masked]>
To: [email-masked]
Subject: General info
Sender: [email-masked]

Hi all.  I am interested in general info, other than the RFC's on BGP.  Is
there a general BGP faq?  (ie, is it supported in gated, will my router
handle it, etc).

Thanks much for any info,
Dave Wreski

-----------------------------------------------------------------------
"The opinions expressed here are my own and do not represent the views
or opinions of United Parcel Service, Inc."
-----------------------------------------------------------------------
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sb20293A2058554E494Csnlbxq'|dc

- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: a different proposal for ipv6 in bgp 
Date: Mon, 30 Dec 1996 16:05:23 -0500
From: Erik Sherk <[email-masked]>
Sender: [email-masked]

> 
> attached below is a proposal for a multi-protocol (including
> ipv6) bgp
> 
> while there are a number of differences between this one and
> the bates/chandra/katz/rekhter one, one of the main motivating
> factors for this one is to support longer-than-two-byte ASs.
> it is our view that making bgp multi-protocol significantly
> extends its life.  so, although in a narrow sense the length
> of the AS is orthogonal to being multi-protocol, the logistics
> of transitions and the need to adequeately engineer the
> protocol up-front, to us, suggests the need for longer-than-
> two-byte ASs
> 
> /jws
> 
> ##################################################################
> 
> 
> Network Working Group                               Dimitry Haskin
> Internet-Draft                                        Bay Networks
> Expires June 1997                             John W. Stewart, III
>                                                                ISI
> 
> 
>                    Multiprotocol Extensions for BGP
> 
>                 draft-stewart-bgp-multiprotocol-00.txt

Hi,
	My opinion, as an operator, is that the size of the AS space
needs to be fixed rather sooner then later. We are already getting alot
of push back from the InterNic on ASs for customers. I would say that 
the figures quoted on the run rate of ASs are more a function of the
allocation policy then actual demand.

	Also, I think that the concept of an AS is kind of super-protocol.
That is, the AS remains the same across multiple protocols. I expect one
AS to advertize prefixes in multiple protocols. Also, while I'm at it, I 
don't expect IDRP to see any real deploymet; BGP has shown itself to be
very flexible. I don't see a need for a new protocol.

Erik

- - - - - - - - - - - - - - - - -

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: a different proposal for ipv6 in bgp
Date: Mon, 30 Dec 1996 14:05:41 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

attached below is a proposal for a multi-protocol (including
ipv6) bgp

while there are a number of differences between this one and
the bates/chandra/katz/rekhter one, one of the main motivating
factors for this one is to support longer-than-two-byte ASs.
it is our view that making bgp multi-protocol significantly
extends its life.  so, although in a narrow sense the length
of the AS is orthogonal to being multi-protocol, the logistics
of transitions and the need to adequeately engineer the
protocol up-front, to us, suggests the need for longer-than-
two-byte ASs

/jws

##################################################################

Network Working Group                               Dimitry Haskin
Internet-Draft                                        Bay Networks
Expires June 1997                             John W. Stewart, III
                                                               ISI

                   Multiprotocol Extensions for BGP

                draft-stewart-bgp-multiprotocol-00.txt

1. Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

2. Abstract

   This document outlines a proposal for a BGP Version 5 (BGP5)
   which has the ability to carry routing information for a variety
   of network protocols.  The proposed BGP modifications are
   intended to be simple enough to be easily added to the existing
   BGP implementations and, at the same time, provide for a longer
   than 16-bit AS number space.

   This document only describes BGP5 support for IPv4 and IPv6 networks.

3. Overview

   BGP [BGP4-RFC] is widely deployed as an inter-domain routing
   protocol for IPv4 and there is a large operational experience
   with it.  Though currently BGP can only carry routing information
   for IPv4,  the existence of the mature BGP implementation base 
   provides a strong motivation for extending it to support the Internet
   Protocol version 6 (IPv6) and possibly other network protocols. 

   This document outlines a proposal for creating a BGP Version 5 (BGP5)
   which has the ability to carry routing information for a variety
   of network protocols.  Adding this multi-protocol support to BGP 
   significantly increases its lifetime, so care should be taken for
   BGP5 to not be under-engineered.  For this reason, BGP5 supports
   longer than 2-byte ASs.  At the same time, in the authors' view,
   the proposed modifications are simple enough to be easily added
   to the existing BGP implementations as not to impede BGP5 deployment.
   As a matter of fact no changes to the BGP4 data structures are required
   to support IPv4 routing in BGP5.

   To ensure a smooth transition from BGP4 to BGP5 on IPv4 networks
   it is recommended that upgraded BGP implementations continue
   BGP4 support at least until BGP5 is universally deployed.  The BGP5
   proposal ensures that IPv4 routing information that is advertised
   with BGP5 is fully re-advertisable via BGP4 and vice versa. In this
   sense BGP4 and BGP5 are fully compatible as far as IPv4 routing is
   concerned.

   This paper presents an overview of the protocol messages used by
   BGP5.  Where details of the protocol (e.g., the state machine and
   fields of protocol messages) have the same meaning as BGP4, those
   details are left out of this outline for the sake of brevity.

4. Autonomous System Number Space
  
   This document proposes to adopt a 32-bit Autonomous System number
   space for IPv6 to accommodate for the aggressive Internet growth.
   The 32-bit number space is large enough to ensure that no future
   IPv6 transition to a larger number space will be necessary.

   In order to minimize implementation changes that are needed to
   support IPv4 routing,  16-bit AS number space will continue to
   be supported with BGP5.

   In addition BGP5 will provide a mechanism to gradually introduce
   the 32-bit AS number space to IPv4 routing.

5. Message Formats

   This section describes message formats used by BGP.

5.1 Message Header Format

   The fixed header for BGP5 is the same as BGP4, namely:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                                                               +
      |                           Marker                              |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Length               |      Type     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is as described in BGP4.

5.2 OPEN Message Format

   The OPEN message has the following format:

       +---------------------------------------+
       | Version (1 octet)                     |
       +---------------------------------------+
       | Len of My Autonomous System (1 octet) |
       +---------------------------------------+
       | My Autonomous System (variable)       |
       +---------------------------------------+
       | Hold Time (2 octets)                  |
       +---------------------------------------+
       | Router ID (4 octets)                  |
       +---------------------------------------+
       | Opt Parm Len (1 octet)                |
       +---------------------------------------+
       | Optional Parameters (variable)        |
       +---------------------------------------+

   "Version" is a one-octet unsigned integer specifying the
   protocol version.  This paper describes BGP version 5.

   "Len of My Autonomous System" is a one-octet unsigned integer
   specifying the length in octets of the "My Autonomous System"
   field.  To carry IPv4 ASs this field should be 2; to carry IPv6 ASs this
   field should be 4.  The presence of this field permits routing
   domain identifiers of any length, though this paper only discusses
   the use of 2-byte ASs and 4-byte [fixed-length] ASs.

   "My Autonomous System" identifies the AS of which the sender
   is a member.

   "Hold Time" is as described in BGP4.

   "Router ID" is a 32-bit unsigned integer identifying the
   sender.  Because the	size of	the Router ID is smaller than an IPv6
   address, it cannot be set to one of the router's IPv6 addresses (as
   is commonly done for IPv4). Possible Router ID assignment procedures
   for IPv6 include: a) assign the IPv6 Router ID as one of the router's
   IPv4 addresses or b) assign IPv6 Router IDs through some local
   administrative procedure (similar to	procedures used	by manufacturers
   to assign product serial numbers). The Router ID of 0.0.0.0 is	
   reserved, and should not be used.

   "Opt Parm Len" and "Optional Parameters" are as described in BGP4.

5.3 UPDATE Message Format

   The UPDATE message always includes the fixed-size BGP header that
   is followed by one-octet Format Type field which indicates the
   format and content of the rest of the UPDATE message.

   The following UPDATE Format Type values are defined in this document:

     1 - BGP4 compatible update with IPv4 routing information
     2 - IPv6 routing update
     3 - IPv4 routing update with the 4-octet AS numbers

   Implementations are not required to support all possible
   update formats. To allow for future enhancements, implementations
   are required to ignore UPDATES with format types that they do not
   support.

5.3.1  BGP4 Compatible Update

   This type of UPDATE message has the following format:

      +-----------------------------------------------------+
      |  Format Type (1 octet) == 1                         |
      +-----------------------------------------------------+
      |  Withdrawn Routes Length (2 octets)                 |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |  Total Path Attribute Length (2 octets)             |
      +-----------------------------------------------------+
      |  Path Attributes (variable)                         |
      +-----------------------------------------------------+
      |  Network Layer Reachability Information (variable)  |
      +-----------------------------------------------------+

   "Format Type" is a value indicating the format of
   the UPDATE message. It is 1 for the BGP4 compatible format type.

   All other fields are as described in BGP4.

5.3.2  IPv6 Routing Update

   This type of UPDATE message has the following format:

      +-----------------------------------------------------+
      |  Format Type (1 octet) == 2                         |
      +-----------------------------------------------------+
      |  Withdrawn Routes Length (2 octets)                 |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |  Total Path Attribute Length (2 octets)             |
      +-----------------------------------------------------+
      |  Path Attributes (variable)                         |
      +-----------------------------------------------------+
      |  Network Layer Reachability Information (variable)  |
      +-----------------------------------------------------+

   "Format Type" is a value indicating the format of
   the UPDATE message. It is 2 for UPDATE messages that carry
   IPv6 routes.

   "Withdrawn Routes Length" is a two-octet unsigned integer
   specifying the length in octets of the "Withdrawn Routes" field.

   "Withdrawn Routes" is a variable-length field containing a list
   of address prefixes being withdrawn from service. 
   Each address prefix is encoded as described in BGP4, except that
   the "Length" component of the tuple isn't limited to what would
   make sense for IPv4 addresses.

   "Total Path Attribute Length" is as described in BGP4.

   "Path Attributes"  field is as described in BGP4 except:

     - The NEXT-HOP attribute is interpreted as a 16-byte
       IPv6 global or site scope address.

     - The AGGREGATOR attribute contains the AS number that formed
       the aggregate route (encoded as 4 octets), followed by the
       16-byte IPv6 global or site scope address of the BGP speaker that
       formed the aggregate route.

     - The AS-PATH attribute contains four-byte ASs.  Two-byte ASs
       can be mapped to four-byte ASs with zero-padding to the left.

     - A new LINK-LOCAL-NEXT-HOP attribute.

       LINK-LOCAL-NEXT-HOP is a well-known discretionary attribute
       that contains the link-local address of the router interface
       associated with the global-scope IPv6 address specified in
       the NEXT-HOP attribute of the same UPDATE message.

       LINK-LOCAL-NEXT-HOP shall be included in all IPv6 UPDATE
       messages that a given BGP speaker sends to other BGP speakers
       located in a neighboring autonomous system.  Such a link local
       address should be used as the immediate next hop for forwarding
       packets to the destinations listed in the UPDATE message.

       A BGP speaker shall not include this attribute in IPv6 UPDATE
       messages that it sends to BGP speakers located in its own
       autonomous system.  If it is contained in an UPDATE message that
       is received from a BGP speaker which is located in the same AS
       as the receiving speaker, then this attribute shall be ignored
       by the receiving speaker.  For the routes received from a BGP
       speaker in the same AS as the receiving speaker, the link-local
       address of the immediate next hop should be based on the IGP
       route to the global-scope address provided in the NEXT-HOP 
       attribute.

   "Network Layer Reachability Information" is as described in
   BGP4, except that the "Length" component of the tuple isn't
   limited to what would make sense for IPv4 addresses.

5.3.3  IPv4 Routing Update With the 32-bit AS Numbers

   This type of UPDATE message provides support for
   a larger than 16-bit AS number space that is currently
   supported in BGP4.  Introducing this type of UPDATE
   well in advance of the 16-bit AS number space exhaustion
   will allow for smoother IPv4 transition to a larger
   AS number space.

   16-bit AS numbers can be mapped into 32-bit AS numbers by with
   zero-padding to the left.  Therefore it is expected that
   for an extended period, until BGP5 which supports this type of
   UPDATE message is universally deployed,  bacwards compatibility
   will be achieved by simply mapping 16-bit AS numbers to zero-
   extended 32-bit AS numbers and vice versa.

   This type of UPDATE message has the following format:

      +-----------------------------------------------------+
      |  Format Type (1 octet) == 3                         |
      +-----------------------------------------------------+
      |  Withdrawn Routes Length (2 octets)                 |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |  Total Path Attribute Length (2 octets)             |
      +-----------------------------------------------------+
      |  Path Attributes (variable)                         |
      +-----------------------------------------------------+
      |  Network Layer Reachability Information (variable)  |
      +-----------------------------------------------------+

   "Format Type" is a value indicating the format of
   the UPDATE message. It is 3 for this format type.

   "Withdrawn Routes Length" is as described in BGP4.

   "Withdrawn Routes" is as described in BGP4

   "Total Path Attribute Length" is as described in BGP4.

   "Path Attributes"  field is as described in BGP4 except:

     - The AGGREGATOR attribute contains the 32-bit AS number that formed
       the aggregate route (encoded as 4 octets), followed by the
       IPv4  address of the BGP speaker that formed the aggregate route.

     - The AS-PATH attribute contains 32-bit ASs.

6. Acknowledgements

   [TBA]

7. Security Considerations

   [TBA]

8. References

   [BGP4-RFC] -- RFC1771

   [ASSIGNED-NUMBERS-RFC] -- RFC1700

9. Authors' Addresses

   John W. Stewart, III
   USC/ISI
   4350 North Fairfax Drive
   Suite 620
   Arlington, VA  22203
   +1 703 812 3704
   email: [email-masked]

   Dimitry Haskin
   Bay Networks
   2 Federal St.
   Billerica, MA
   +1 508 916 8124
   email: [email-masked]

- - - - - - - - - - - - - - - - -

Date: Tue, 24 Dec 1996 11:36:07 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked] (Dimitry Haskin), [email-masked], [email-masked]
Subject: Re: (IPng 2633) Re: larger AS/RD space for v6?
Sender: [email-masked]

   I don't know if more is needed.  But preparing to implement your 8+8
   proposal I can't see more than 14bits needed for the LSID.  Then the
   rest of bits is a real lot for subscribers.  Then in the low order
   8bytes we only have 15 for the partition.  SHould someone use up that
   partition I see no reason why the subscriber could not provide some of
   the subscriber bits to the private topology if needed?  This affects how
   I would implement the transport and dns stuff fyi...

I'd like to point out that ANYTHING that "knows" about the internal
structure of the address is probably a mistake.  It constrains the future
flexibility of the system, thereby eliminating future adaptability.  Basic
engineering demands that create the absolute minimum in internal
interdependencies.  Thus, the address should be wholly opaque outside of
the routing system.

Imagine what would have happened if, for example, TCP _knew_ about Class B
addresses.

Tony

p.s.: You shouldn't even know the length of it.  Hint, hint.  ;-)
- - - - - - - - - - - - - - - - -

Date: Tue, 24 Dec 1996 21:26:29 +0200
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: BGP-4+ [QOS et al]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

One thing: being able to associate NLRI with (only) an address family seems
like an unnecessary restriction.  Instead, how about permitting the
association of NLRI with an arbitrary RIB, as qualified by <whatever>?  The
additional parameter that springs to mind is QOS, so a RIB would be
identified by <AFI, QOS>.  There isn't any particular need to restrict
things so that only AFI and QOS are usable to qualify the RIB, though.

One way to do this would be to use a more general RIB ID of some sort, and
associate a RIB with <AFI, other stuff> in a separate step.  One would want
to make the RIB establishment step sufficiently extensible that one could
(at least) associate a QOS with a RIB.  I see no particular reason to
restrict the <other stuff> part to support only QOS, though.

Alternately, I suppose you could just stick the QOS right into the
attribute each time you send it.  This would be less complicated, at the
cost of each PDU being more piggy.

For bit-counters, using a RIB ID could be useful if you assume that 256
RIBs are sufficient for a particular peer-peer association -- you can save
8 bits per PDU (compared to the current proposal) in that case by making
RIB ID a single octet instead of the two octet AFI.

Note that you can't properly support QOS by making it yet another path
attribute, for the same reason you can't support AFI by making it just a
path attribute in the obvious way -- one may want to advertise (and
withdraw) the same NLRI multiple times with different QOS.

By the way, one conceivable benefit of doing something like this is that it
moves yet another piece of IDRP functionality into BGP.

If this is considered to be a good idea, the question would be when and how
to establish the RIB ID<->RIB attribute binding.

--John

--
John Scudder                        email:  [email-masked]
Internet Engineering Group, LLC     phone:  (313) 669-8800
122 S. Main, Suite 280              fax:    (313) 669-8661
Ann Arbor, MI  48104                www:    http://www.ieng.com

- - - - - - - - - - - - - - - - -

From: [email-masked]
To: "Mike O'Dell" <[email-masked]>
Cc: [email-masked] (Dimitry Haskin), [email-masked], [email-masked]
Subject: Re: (IPng 2633) Re: larger AS/RD space for v6? 
Date: Tue, 24 Dec 96 11:30:42 -0500
Sender: [email-masked]

Mike,

I don't know if more is needed.  But preparing to implement your 8+8
proposal I can't see more than 14bits needed for the LSID.  Then the
rest of bits is a real lot for subscribers.  Then in the low order
8bytes we only have 15 for the partition.  SHould someone use up that
partition I see no reason why the subscriber could not provide some of
the subscriber bits to the private topology if needed?  This affects how
I would implement the transport and dns stuff fyi...

/jim
- - - - - - - - - - - - - - - - -

To: Geert Jan de Groot <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-4+ 
Date: Mon, 23 Dec 1996 16:47:10 PST
From: Brad Smith <[email-masked]>
Sender: [email-masked]

> I think you need to re-focus your question. What are you trying to protect?
> a. RST-attachs to BGP sessions and such, including spoofing of BGP data?
>    IPSEC-AH will fix that in an exportable manner..
> b. People knowingly and willingly injecting false routes (such as host route)
>    to play games with traffic?
>    That's a much harder problem and IMHO that would be out of scope for
>    BGP4++
> 
> I think you'll get more useful answers if you post your questions that way.
> What do others think?

I agree.  Addressing (a) is pretty straight-forward and protects you from
"outside" attackers (masquerading speakers, unauthorized speakers, and
subverted links).  Addressing (b) is non-trivial and protects you from
subverted speakers.  (a) is pretty well understood, with reasonably effective
and efficient solutions available; (b) is less well understood, and there are
no adequately efficient solutions available.

Asking if secure TCP or similar mechanisms is sufficient for addressing
the threat (a) is straight-forward (I'd answer yes; I'd also be interested
in seeing an analyisis of how IPSEC accomplishes the same goal... although
the claim that it does sounds right to me).  The same question for (b)
would be answered no.

Brad
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: non-zero total path attribute length
Date: Mon, 23 Dec 96 08:15:08 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

I'd like to poll *the folks who implemented BGP-4* to find
whether their implementations could tolerate an UPDATE
message with non-zero Total Path Attribute Length, but
with no NLRI included (another words, the message contains
some of the path attributes, but contains no NLRI at all).

Please reply directly to me - I'll summarize the replies
and post the summary to the list.

Yakov.
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
From: Geert Jan de Groot <[email-masked]>
Subject: Re: BGP-4+ 
Date: Mon, 23 Dec 1996 17:07:07 +0100
Sender: [email-masked]

On Wed, 18 Dec 96 14:59:12 PST  Yakov Rekhter wrote:
> > 2) Security Considerations
> > BGP-4++ is just as secure or un-secure as BGP-4.  
> To be more precise the two new attributes do not alter
> BGP-4 security properties.
> > Is it your understanding that users need this security or is
> > TCP good enough?
> I would like to get a feedback from the WG on this question.

I think you need to re-focus your question. What are you trying to protect?
a. RST-attachs to BGP sessions and such, including spoofing of BGP data?
   IPSEC-AH will fix that in an exportable manner..
b. People knowingly and willingly injecting false routes (such as host route)
   to play games with traffic?
   That's a much harder problem and IMHO that would be out of scope for BGP4++

I think you'll get more useful answers if you post your questions that way.
What do others think?

Geert Jan

- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Mon, 23 Dec 96 07:17:17 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> i guess i don't understand the spec completely, then.
> how do you specify no NLRI, then?  a prefix-length of
> 0 doesn't do it because that means 0.0.0.0/0, right?

No. You just don't specify NLRI at all. Means that the length of the
Network Layer Reachability Information field is 0.  We already have
cases with BGP-4 where an UPDATE message doesn't carry any NLRI - when
the message is used just to withdraw routes from service.

Yakov.
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Mon, 23 Dec 1996 10:10:04 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

i guess i don't understand the spec completely, then.
how do you specify no NLRI, then?  a prefix-length of
0 doesn't do it because that means 0.0.0.0/0, right?

/jws

 > John,
 >  
 > > i have a follow-up question to one of the things dennis asked,
 > > but i have a general question as well
 > > 
 > > the UPDATE message looks like:
 > > 
 > >       +-----------------------------------------------------+
 > >       |   Unfeasible Routes Length (2 octets)               |
 > >       +-----------------------------------------------------+
 > >       |  Withdrawn Routes (variable)                        |
 > >       +-----------------------------------------------------+
 > >       |   Total Path Attribute Length (2 octets)            |
 > >       +-----------------------------------------------------+
 > >       |    Path Attributes (variable)                       |
 > >       +-----------------------------------------------------+
 > >       |   Network Layer Reachability Information (variable) |
 > >       +-----------------------------------------------------+
 > > 
 > > let's say that i'm an implementation with these extensions and
 > > i want to advertise an IPv6 route over an ebgp session with
 > > just the mandatory well-known attributes ORIGIN="IGP",
 > > AS-PATH="3561" and NEXT-HOP="10.1.1.1".  what do i put in the
 > > "NLRI" field of the UPDATE message (not the NLRI component of
 > > the attribute)?  as i read it, the proposed extension doesn't
 > > include the ability to specify attributes within the
 > > MP_REACH_NLRI attribute, so the "Total Path Attribute Length"
 > > and "Path Attributes" fields of the UPDATE message need to be
 > > used.  the spec says:
 > > 
 > >  >>
 > >  >>   Total Path Attribute Length:
 > >  >>
 > >  >>      [...]
 > >  >>
 > >  >>      A value of 0 indicates that no Network Layer Reachability
 > >  >>      Information field is present in this UPDATE message.
 > >  >>
 > > 
 > > so conversely a non-zero value in "Total Path Attribute Length"
 > > means that NLRI *is* present.  since i need to associate
 > > attributes with the IPv6 route, "Total Path Attribute Length"
 > > needs to be non-zero, so what goes in NLRI if i don't have any
 > > IP4-related thing to do in this message?
 > 
 > The converse is not true (and perhaps this should be clarified in the
 > BGP-4 spec). That is, "Total Path Attribute Length" may be non-zero *and* 
 > no NLRI may be present. This way one could have NLRI carried only in the
 > MP_REACH_NLRI and have all the other necessary attributes as well.
 > 
 > Yakov.
- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Mon, 23 Dec 96 05:43:06 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> i have a follow-up question to one of the things dennis asked,
> but i have a general question as well
> 
> the UPDATE message looks like:
> 
>       +-----------------------------------------------------+
>       |   Unfeasible Routes Length (2 octets)               |
>       +-----------------------------------------------------+
>       |  Withdrawn Routes (variable)                        |
>       +-----------------------------------------------------+
>       |   Total Path Attribute Length (2 octets)            |
>       +-----------------------------------------------------+
>       |    Path Attributes (variable)                       |
>       +-----------------------------------------------------+
>       |   Network Layer Reachability Information (variable) |
>       +-----------------------------------------------------+
> 
> let's say that i'm an implementation with these extensions and
> i want to advertise an IPv6 route over an ebgp session with
> just the mandatory well-known attributes ORIGIN="IGP",
> AS-PATH="3561" and NEXT-HOP="10.1.1.1".  what do i put in the
> "NLRI" field of the UPDATE message (not the NLRI component of
> the attribute)?  as i read it, the proposed extension doesn't
> include the ability to specify attributes within the
> MP_REACH_NLRI attribute, so the "Total Path Attribute Length"
> and "Path Attributes" fields of the UPDATE message need to be
> used.  the spec says:
> 
>  >>
>  >>   Total Path Attribute Length:
>  >>
>  >>      [...]
>  >>
>  >>      A value of 0 indicates that no Network Layer Reachability
>  >>      Information field is present in this UPDATE message.
>  >>
> 
> so conversely a non-zero value in "Total Path Attribute Length"
> means that NLRI *is* present.  since i need to associate
> attributes with the IPv6 route, "Total Path Attribute Length"
> needs to be non-zero, so what goes in NLRI if i don't have any
> IP4-related thing to do in this message?

The converse is not true (and perhaps this should be clarified in the
BGP-4 spec). That is, "Total Path Attribute Length" may be non-zero *and* 
no NLRI may be present. This way one could have NLRI carried only in the
MP_REACH_NLRI and have all the other necessary attributes as well.

Yakov.
- - - - - - - - - - - - - - - - -

To: Dennis Ferguson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Mon, 23 Dec 96 05:32:24 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Dennis,
 
> > This is certainly one possibility. Another possibility is to allow
> > MP_REACH_NLRI and MP_UNREACH_NLRI to carry NLRI for multiple address
> > families (this would require minor changes to the proposed encoding).
> 
> This would work too.  Now that I've though about it I think I might have
> a slight preference for doing it your way.  The tradeoff seems to be that
> you have to spend a few more bytes of encoding to do it your way, but
> you get to keep all attributes-that-are-really-routes together in one spot.
> I think the latter is probably a feature.

Ok. We'll modify the document to allow for multiple address families.

> The only other issue I have relates to protocol-specific usage.  I think
> there probably needs to be a paragraph or so on IPv6-specific gorp written
> down somewhere to ensure working, interoperable implementations.  The one
> example I can think of off-hand is that of IPv6 next hop addresses.  Most
> routing protocols for IPv6 specify the exclusive use of link-local addresses
> for next hops, as the interface addresses least likely to change over the
> life of a routing protocol session, but this is probably not right for BGP
> since link-local addresses are not likely to be well-received when
> readvertised via IBGP.

Correct.
  
> Is it intended that protocol-specific (or, at least, IPv6-specific) issues
> are to be documented elsewhere (or anywhere)?  A multiprotocol specification
> by itself seems insufficient.

I would suggest to stick IPv6-specific text into the multiprotocol spec.
But I can be easily convinced otherwise (and have a separate IPv6-specific
doc).

Yakov.
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2641) Re: why do we need ASes??
To: [email-masked] (Mike O'Dell)
Date: Mon, 23 Dec 96 16:21:31 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> Yes, there are discontiguous ASes, there are also confederations
> which don't necessarily track the address-assignment topology.

OK.

> and it would be useful to have an identifier of an administrative
> system which is invariant under topology.

The problem of such an identifier is that it is totally insecure,
not even weakly secure, unless the identifier is derived from
routable part of the address.

> i'm not arguing that you absolutely cannot make it work without the AS
> as a distinguised thing, but so much of the existing infrastructure
> relies up on it it won't be deployable without it,

What I'm afrading is that with IPv6 hierarchical addressing such as
that of RFC 1887, we need hierarchical ASes perhaps as long as
16 bytes.

Or, do you think we don't need local, MAN or country level policy
control?

> and since it
> won't be a flash-cut, having the external routing policy machinery
> use the same set of structures means the conversion is arguably doable.

If we are having hierarchical ASes, it is a lot better to unify
the role of ASes and IP addresses, which is what is done with
hierarchical addressing.

> so keeping the external policy machinery relatively independent would
> seem to be at least prudent, if not theoretically necessary.

You seems to be arguing that "Don't renumber ASes, because it means
a lot of work.".

Exactly like that, people say "Don't renumebr IP addresses".

But, renumbering of ASes only affect small number of configuration
files. Note that, whatever renumbering scheme of IP addresses you
might invent, small number of configuration files, such as glue
A's for DNS, must be affected..

As a result, AS numbers are just as stable as IP address prefixes.

							Masataka Ohta
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: Dennis Ferguson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Sun, 22 Dec 1996 18:15:16 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

i have a follow-up question to one of the things dennis asked,
but i have a general question as well

the UPDATE message looks like:

      +-----------------------------------------------------+
      |   Unfeasible Routes Length (2 octets)               |
      +-----------------------------------------------------+
      |  Withdrawn Routes (variable)                        |
      +-----------------------------------------------------+
      |   Total Path Attribute Length (2 octets)            |
      +-----------------------------------------------------+
      |    Path Attributes (variable)                       |
      +-----------------------------------------------------+
      |   Network Layer Reachability Information (variable) |
      +-----------------------------------------------------+

let's say that i'm an implementation with these extensions and
i want to advertise an IPv6 route over an ebgp session with
just the mandatory well-known attributes ORIGIN="IGP",
AS-PATH="3561" and NEXT-HOP="10.1.1.1".  what do i put in the
"NLRI" field of the UPDATE message (not the NLRI component of
the attribute)?  as i read it, the proposed extension doesn't
include the ability to specify attributes within the
MP_REACH_NLRI attribute, so the "Total Path Attribute Length"
and "Path Attributes" fields of the UPDATE message need to be
used.  the spec says:

 >>
 >>   Total Path Attribute Length:
 >>
 >>      [...]
 >>
 >>      A value of 0 indicates that no Network Layer Reachability
 >>      Information field is present in this UPDATE message.
 >>

so conversely a non-zero value in "Total Path Attribute Length"
means that NLRI *is* present.  since i need to associate
attributes with the IPv6 route, "Total Path Attribute Length"
needs to be non-zero, so what goes in NLRI if i don't have any
IP4-related thing to do in this message?

 > > (2) It seems to me advantageous that IPv4 and IPv6 routes with the same pa
th
 > >     attributes are able to be advertised in the same update message, rathe
r
 > >     than replicating the same set of attributes in two messages.  The curr
ent
 > >     proposal does indeed allow this to happen.  Given that this may have e
ven
 > >     been designed in rather than happy circumstance, however, I find the
 > 
 > It was intentional - not just "happy circumstance". 
 > 
 > >     `Address Family' field a bit annoying.  There seem to be only two
 > >     possibilities for its use:
 > > 
 > >     (i) BGP-4 never carries routes from an address family other than IPv4
 > >         and IPv6.  In this case the address family field is a constant in
 > >         attributes with type codes 0x14 and 0x15, and might just as well
 > > 	have not been present since 0x14 and 0x15 always imply IPv6.
 > > 
 > >     (ii) BGP-4 is used to carry routes from address families in addition
 > > 	to IPv4 and IPv6.  In this case the address family field is a
 > > 	variable, but the constraint on a path attribute type appearing
 > > 	twice in one message now prevents you from listing all routes with
 > > 	the same attributes in the same message, independent of family.
 > > 	That is, you get to advertise IPv4 and something in the same message,
 > > 	but only one something.
 > 
 > Yes, this is an undesirable restriction.
 > 
 > >     Given that the total number of protocol families there are to carry in
 > >     BGP-4 is relatively small anyway, that type codes are not in short
 > >     supply and that the `Address Family' seems more a constraint than a
 > >     generalization, might it not be better to do away with the address
 > >     family identifier and just use different attribute type codes to
 > >     identify the x_REACH_NRLI's and x_UNREACH_NLRI's for different
 > >     protocols?
 > 
 > This is certainly one possibility. Another possibility is to allow
 > MP_REACH_NLRI and MP_UNREACH_NLRI to carry NLRI for multiple address
 > families (this would require minor changes to the proposed encoding).

given that the attributes of an advertised route will always
include AS-PATH, ORIGIN and NEXT-HOP (and LOCAL-PREF for IBGP),
and given that in practice there is a high degree of
variability of these fields (the variability of each
individually is high and in combination the variability is even
higher), is it necessary to complicate the protocol with an
optimization which would require an implementation to be very
ineffecient to take advantage of?

/jws
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Sun, 22 Dec 1996 15:07:43 -0800
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]

Yakov,

> This is certainly one possibility. Another possibility is to allow
> MP_REACH_NLRI and MP_UNREACH_NLRI to carry NLRI for multiple address
> families (this would require minor changes to the proposed encoding).

This would work too.  Now that I've though about it I think I might have
a slight preference for doing it your way.  The tradeoff seems to be that
you have to spend a few more bytes of encoding to do it your way, but
you get to keep all attributes-that-are-really-routes together in one spot.
I think the latter is probably a feature.

The only other issue I have relates to protocol-specific usage.  I think
there probably needs to be a paragraph or so on IPv6-specific gorp written
down somewhere to ensure working, interoperable implementations.  The one
example I can think of off-hand is that of IPv6 next hop addresses.  Most
routing protocols for IPv6 specify the exclusive use of link-local addresses
for next hops, as the interface addresses least likely to change over the
life of a routing protocol session, but this is probably not right for BGP
since link-local addresses are not likely to be well-received when
readvertised via IBGP.

Is it intended that protocol-specific (or, at least, IPv6-specific) issues
are to be documented elsewhere (or anywhere)?  A multiprotocol specification
by itself seems insufficient.

Dennis
- - - - - - - - - - - - - - - - -

To: Masataka Ohta <[email-masked]>
Cc: [email-masked] (Mike O'Dell), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: (IPng 2641) Re: why do we need ASes?? 
Date: Sun, 22 Dec 1996 09:41:59 -0500
From: "Mike O'Dell" <[email-masked]>
Sender: [email-masked]

Yes, there are discontiguous ASes, there are also confederations
which don't necessarily track the address-assignment topology.
and it would be useful to have an identifier of an administrative
system which is invariant under topology.

i'm not arguing that you absolutely cannot make it work without the AS
as a distinguised thing, but so much of the existing infrastructure
relies up on it it won't be deployable without it, and since it
won't be a flash-cut, having the external routing policy machinery
use the same set of structures means the conversion is arguably doable.
(this gets to the bgp++ vs idrp discussion and i'd prefer to not
stand on that ice right now as it heats up)

so keeping the external policy machinery relatively independent would
seem to be at least prudent, if not theoretically necessary.

	cheers,
	-mo
- - - - - - - - - - - - - - - - -

To: Dennis Ferguson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Sun, 22 Dec 96 06:29:18 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Dennis,

> This indeed seems like a fine hack to me.  

Thanks !!!

> Apart from the size-of-an-AS
> issue, which I think is orthogonal in any case, 

I agree that the size-of-an-AS issue is orthogonal.

> I have several minor comments:
> 
> (1) Would it be possible to specify explicitly that the MP_REACH_NLRI
>     attribute, when included in the path attributes, must always be inserted
>     at the end after everything else?  The reason is that (at least for the
>     implementation I'm familiar with) it is usually necessary that all
>     path attributes have been collected and internalized before one starts
>     to process the routes having those attributes.  If you can't rely on
>     the MP_REACH_NLRI being last in the list of attributes then you lose
>     the ability to process each message sequentially, instead having to
>     step around collecting the non-NLRI attributes before coming back
>     to process the routes.

That would be fine. We'll incorporate this in the next iteration
of the document.

> (2) It seems to me advantageous that IPv4 and IPv6 routes with the same path
>     attributes are able to be advertised in the same update message, rather
>     than replicating the same set of attributes in two messages.  The current
>     proposal does indeed allow this to happen.  Given that this may have even
>     been designed in rather than happy circumstance, however, I find the

It was intentional - not just "happy circumstance". 

>     `Address Family' field a bit annoying.  There seem to be only two
>     possibilities for its use:
> 
>     (i) BGP-4 never carries routes from an address family other than IPv4
>         and IPv6.  In this case the address family field is a constant in
>         attributes with type codes 0x14 and 0x15, and might just as well
> 	have not been present since 0x14 and 0x15 always imply IPv6.
> 
>     (ii) BGP-4 is used to carry routes from address families in addition
> 	to IPv4 and IPv6.  In this case the address family field is a
> 	variable, but the constraint on a path attribute type appearing
> 	twice in one message now prevents you from listing all routes with
> 	the same attributes in the same message, independent of family.
> 	That is, you get to advertise IPv4 and something in the same message,
> 	but only one something.

Yes, this is an undesirable restriction.

>     Given that the total number of protocol families there are to carry in
>     BGP-4 is relatively small anyway, that type codes are not in short
>     supply and that the `Address Family' seems more a constraint than a
>     generalization, might it not be better to do away with the address
>     family identifier and just use different attribute type codes to
>     identify the x_REACH_NRLI's and x_UNREACH_NLRI's for different
>     protocols?

This is certainly one possibility. Another possibility is to allow
MP_REACH_NLRI and MP_UNREACH_NLRI to carry NLRI for multiple address
families (this would require minor changes to the proposed encoding).

Yakov.
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2641) Re: why do we need ASes??
To: [email-masked] (Mike O'Dell)
Date: Sun, 22 Dec 96 17:53:19 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> because the AS identifies the injecting administrative domain and
> policy exchange is based on that.  i actually thought hard about
> this in the 8+8 proposal and you really want to keep an independent
> identifier for the administrative domain distinct from the topology.

Are there any AS which is not contiguous today?

> "different kind of thing, different kind of name"

It seems to me that the difference is in the IP version number.

							Masataka Ohta
- - - - - - - - - - - - - - - - -

To: Masataka Ohta <[email-masked]>
Cc: [email-masked] (Joel Halpern), [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: why do we need ASes??
Date: Sat, 21 Dec 1996 08:30:02 -0500
From: "Mike O'Dell" <[email-masked]>
Sender: [email-masked]

because the AS identifies the injecting administrative domain and
policy exchange is based on that.  i actually thought hard about
this in the 8+8 proposal and you really want to keep an independent
identifier for the administrative domain distinct from the topology.

"different kind of thing, different kind of name"

	-mo
- - - - - - - - - - - - - - - - -

From: Masataka Ohta <[email-masked]>
Subject: Re: (IPng 2626) Re:  larger AS/RD space for v6?
To: [email-masked] (Joel Halpern)
Date: Sat, 21 Dec 96 17:29:03 JST
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I will note that some people are concernedrelative to the 8+8 proposal
> that either 14 bits may not be enough space for the top, or that 45 bits
> may not be enough for the full provider heirarchy.  While the presence of
> heirarchy will allow some reuse of policy identification (AS) space, I
> would hate to be too heavily dependent on that.  If we need thousands
> of top level entities, and absurd numbers of "ISP"s with policy, it would
> seem likely to me that at some point we will need more than 16 bits worth
> of policy space identifier.
> When will we need that is definitely an open question.

???

I'm totally confused.

With provider based hierarchical addressing, RFC 1887 or 8+8,
the address itself identifies a group of routes.

So, why do we need things like ASes?

							Masataka Ohta
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked] (Dimitry Haskin), [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: (IPng 2620) larger AS/RD space for v6? 
Date: Sat, 21 Dec 1996 00:43:49 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, [email-masked] writes:
> > There was a discussion on the IDR list to whether a larger than a 2-byte
> > AS/RD number space is needed to for IPv6.  The discution was prompted by
> > a BGP4+ proposal for v6.  I'd like to solicit input from a larger
> > IPv6-minded audience on this subgect.
> 
> 	BGP4+ should be IDRP and use RDIs.
> -- 
> --bill

Simple solutions that work are a good thing.

IDRP has too much baggage along with the improvements and so its gone
absolutely nowhere.  Lets just forget IDRP and fix BGP4 so IPv6 can
have a deployable exterior routing protocol.

Curtis
- - - - - - - - - - - - - - - - -

To: [email-masked] (Yakov Rekhter)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Fri, 20 Dec 1996 21:41:34 -0800
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]

Yakov,

This indeed seems like a fine hack to me.  Apart from the size-of-an-AS
issue, which I think is orthogonal in any case, I have several minor
comments:

(1) Would it be possible to specify explicitly that the MP_REACH_NLRI
    attribute, when included in the path attributes, must always be inserted
    at the end after everything else?  The reason is that (at least for the
    implementation I'm familiar with) it is usually necessary that all
    path attributes have been collected and internalized before one starts
    to process the routes having those attributes.  If you can't rely on
    the MP_REACH_NLRI being last in the list of attributes then you lose
    the ability to process each message sequentially, instead having to
    step around collecting the non-NLRI attributes before coming back
    to process the routes.

(2) It seems to me advantageous that IPv4 and IPv6 routes with the same path
    attributes are able to be advertised in the same update message, rather
    than replicating the same set of attributes in two messages.  The current
    proposal does indeed allow this to happen.  Given that this may have even
    been designed in rather than happy circumstance, however, I find the
    `Address Family' field a bit annoying.  There seem to be only two
    possibilities for its use:

    (i) BGP-4 never carries routes from an address family other than IPv4
        and IPv6.  In this case the address family field is a constant in
        attributes with type codes 0x14 and 0x15, and might just as well
	have not been present since 0x14 and 0x15 always imply IPv6.

    (ii) BGP-4 is used to carry routes from address families in addition
	to IPv4 and IPv6.  In this case the address family field is a
	variable, but the constraint on a path attribute type appearing
	twice in one message now prevents you from listing all routes with
	the same attributes in the same message, independent of family.
	That is, you get to advertise IPv4 and something in the same message,
	but only one something.

    Given that the total number of protocol families there are to carry in
    BGP-4 is relatively small anyway, that type codes are not in short
    supply and that the `Address Family' seems more a constraint than a
    generalization, might it not be better to do away with the address
    family identifier and just use different attribute type codes to
    identify the x_REACH_NRLI's and x_UNREACH_NLRI's for different
    protocols?

Dennis Ferguson
- - - - - - - - - - - - - - - - -

Date: Fri, 20 Dec 1996 15:25:52 -0600 (CST)
From: Brandon Black <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Cc: Dimitry Haskin <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Sender: [email-masked]

I'm foregoing quoting this whole thread again, we've all seen the other
mail on this subject so far.....

Now this may seem silly to some who have actually followed the v6
discussions closely, I have not.  Someone please tell me if/why this is
preposterous, or if any of my presumptions are wrong...

Since the v6 address format is heirachical, then why not consider a
certain topmost portion of the v6 address the AS or RD equivalent...

i.e., a provider using AS 123 may have the prefix 12:34:56 (that may not
be the right length or numbers, but this is just theory, I don't know the
specifics) on all v6 addresses that will be used in that AS.  We could
continue to use the 16-bit AS numbers we've been using until the
transition to v6 is complete (I think that it is feasible that 16 bits
will last us until that point).  Once the whole backbone is on v6, just
discard the AS numbers, and start using the address prefixes as "Routing
Domains", which is really what they are if v6 addresses are heirarchical.

During the transition period, if AS's and prefixes pretty much have a
one-to-one relationship, then I don't see any logistics problems with
this... although certainly BGP4+ or IDRP or whatever is chosen will need
to be modified to work this way.... but the modifications would be
simple... instead of storing or transmitting network addresses with an AS,
the network address by itself would be sufficient, since it contains the
RD (prefix)... and the increased AS size of BGP4+ would be the size of
that prefix......  

The big hole I already see in this is of course the little unimportant
company networks that want AS's because they want to be multihomed.... I
don't know enough about how v6 heirarchical addresses are supposed to work
in a multihomed solution to know whether this is a problem or how to solve
it...

Just food for thought for those who know this stuff better than I do...

Brandon

- - - - - - - - - - - - - - - - -

From: [email-masked]
Posted-Date: Fri, 20 Dec 1996 13:08:30 -0800 (PST)
Subject: Re: (IPng 2621) Re:  larger AS/RD space for v6?
To: [email-masked] (Christian Huitema)
Date: Fri, 20 Dec 1996 13:08:30 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 
> Bill,
> 
> The statement that "BGP4+ should be IDRP and use RDIs" may be fine, but
> should not be related to what EGP will be used for IPv6.  One of the clear
> feed-back we received from implementors and early adopters was that "it
> has to be the same".  That is, IPv6 should be using whatever IPv4 is
> using. Which may well mean BGP4 plus minimal extensions, as long as IPv4
> has not yet started using IDRP.
> 
> Note that the rationale here is "use existing skills".  Adding a prefix of
> the type "1234:5678:9ABC//48" to an existing reachability lists does not
> require many new skills.  Switching from one numbering scheme (16 bits AS
> number) to another (RDI) does -- you have to make up a new numbering plan.
> 
> -- 
> Christian Huitema
> 

	I have heard this type of argument before... when the EGP apologists
	were attempting to temper the changes BGP brought to the table.

	Quantum state changes are actaully easier to do than analog shifts.

-- 
--bill
- - - - - - - - - - - - - - - - -

From: [email-masked]
Posted-Date: Fri, 20 Dec 1996 12:44:17 -0800 (PST)
Subject: Re: (IPng 2627) Re: larger AS/RD space for v6?
To: [email-masked] (Geert Jan de Groot)
Date: Fri, 20 Dec 1996 12:44:17 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> I'm feeling a little uncomfortable with this, certainly because it
> takes a *protocol change* to widen the number space later.
> 
> Since we have to make a protocol change anyway, I think it is wise
> to bite the bullet and go for 32 bits while we have the chance and
> it would take minimal effort.
> 
> Geert Jan
> 

	If we take this tack, we are asking to redo this discussion
	in about a decade.  If we are going to make the change, then
	lets do RDI's which are much more flexable and have a much larger
	scaling factor.

-- 
--bill
- - - - - - - - - - - - - - - - -

Date: Fri, 20 Dec 1996 12:42:36 -0800
From: Dave Katz <[email-masked]>
To: [email-masked], [email-masked]
Subject: BGP/IDRP/IPv6
Sender: [email-masked]

Our recent proposal to extend BGP4 to support multiple protocols
has raised a discussion about broader issues involving the future
of interdomain routing protocols.  The early draft we released
obviously did not touch on any of these issues.  I'm going to attempt
to lay out what I think the issues and options are.

At this point there are basically three deltas between BGP4 and IDRP:

	1) Multiprotocol support
	2) Extended AS/RD support
	3) Independent transport

There is a near-term requirement for multiprotocol support.

There is a potential need for the extended AS/RD support, although
if it is necessary it will be some time before it is needed.

Getting rid of TCP would be nice but there is little technical requirement
for doing so.

Of these, the only one that I can see being done in a truly backward
compatible fashion would be the multiprotocol support (as evidenced
by our proposal).  The others would require a new protocol/version.

The independent transport is something that can be deployed on a pairwise
basis without global impact.

Extending the RD space will require a global transition.  The obvious
transition plan is to deploy the protocol but to continue to use 16 bit
RDs;  once all vestiges of BGP4 are gone the extended space can come
into use.

(There is also a semi-delta, confederations;  there is a draft on the
table to extend BGP4 in this way, and experimental code deployed.)

Given these functional differences, there are a couple of questions that
that I can think of:

  1) Should we extend BGP4 for multiprotocol support, or should we do
     that support as part of a next generation protocol?

Making multiprotocol support an extension of BGP4 has the advantage
that it decouples the development and deployment of this functionality
from the others.  However, it has been posited that bundling the
multiprotocol support with the other changes would require only a
single transition, which could be an advantage.

  2) Should the next generation protocol be IDRP, or something that looks
     startlingly like BGP, or should there be one at all (at least one
     that smells like BGP/IDRP)?

Given that at this point there is so little difference in
functionality between IDRP (as published) and BGP (with the proposed
multiprotocol extensions), it seems fair to ask the question of
whether it is worthwhile to go forward with IDRP per se.  One
alternative would be to spin BGP one more time to bring it
semantically in line with IDRP (adding extended RDs and perhaps
changing out the transport).  Another option would be to do nothing
beyond the multiprotocol extension, with the expectation that we will
not need the extended RDs, or that we will need to do something more
radical before the extended RD feature is needed.

IMHO, the right course of action is to do the multiprotocol extension
to BGP4 quickly so that interdomain routing would not stand in the way
of IPv6 deployment.  This can be done independently of any other work.

If the extended RD is necessary, I think the minimal impact approach
is to implement XDRP, a protocol that looks remarkably like BGP in all
respects except the RD field and perhaps the transport if it is
desirable.  Developing and deploying a new protocol in order to get
1.5 features seems like an unnecessary complication.  It is worth noting
that multihomed, non-transit domains do not need AS numbers.

I'd like to hear what the ISPs (who will be the ones to deploy this
stuff) have to say about the subject.  It seems to me as though IPv6
will be easier to deploy as an incremental add-on to the existing BGP4
then if it were bundled in an incompatible (if perhaps almost-compatible)
protocol, but I'll let the ISPs speak for themselves.

--Dave
- - - - - - - - - - - - - - - - -

To: [email-masked] (Dimitry Haskin)
Cc: [email-masked], [email-masked]
From: Geert Jan de Groot <[email-masked]>
Subject: Re: larger AS/RD space for v6? 
Date: Fri, 20 Dec 1996 20:42:48 +0100
Sender: [email-masked]

On Fri, 20 Dec 1996 10:59:04 -0500  Dimitry Haskin wrote:
> There was a discussion on the IDR list to whether a larger than a 2-byte
> AS/RD number space is needed to for IPv6.  The discution was prompted by
> a BGP4+ proposal for v6.  I'd like to solicit input from a larger
> IPv6-minded audience on this subgect.
...
>   Study done by Ramesh Govindan and Anoop Reddy ([email-masked],
>   [email-masked]) shows that new domain pops up every 12 hours. That is
>   ~700 domains per year. If the consumption rate of AS space stays
>   comparable to what we have today, then ~7,000 domains per 10 years...

Another datapoint:
The RIPE NCC started issuing ASes from our latest block on May 21
Today we have issued 224 AS numbers from that block - that's more 
than one per day and the pace is increasing rather than decreasing.
Each of these requests has been evaluated according to RFC1930.

Keeping in mind that there are multiple regional registries, 
and that there's no reason not to expect the pace of this to double
every 10 months (just like the rest of the net does),
I'm feeling a little uncomfortable with this, certainly because it
takes a *protocol change* to widen the number space later.

Since we have to make a protocol change anyway, I think it is wise
to bite the bullet and go for 32 bits while we have the chance and
it would take minimal effort.

Geert Jan

- - - - - - - - - - - - - - - - -

Date: Fri, 20 Dec 1996 14:23:22 +0500
From: [email-masked] (Joel Halpern)
To: [email-masked], [email-masked]
Subject: Re: (IPng 2620) larger AS/RD space for v6?
Cc: [email-masked]
Sender: [email-masked]

I will note that some people are concernedrelative to the 8+8 proposal
that either 14 bits may not be enough space for the top, or that 45 bits
may not be enough for the full provider heirarchy.  While the presence of
heirarchy will allow some reuse of policy identification (AS) space, I
would hate to be too heavily dependent on that.  If we need thousands
of top level entities, and absurd numbers of "ISP"s with policy, it would
seem likely to me that at some point we will need more than 16 bits worth
of policy space identifier.
When will we need that is definitely an open question.

Yours,
Joel M. Halpern					[email-masked]
Newbridge Networks Inc.

- - - - - - - - - - - - - - - - -

To: [email-masked], [email-masked]
Subject: Re: (IPng 2620) larger AS/RD space for v6? 
Date: Fri, 20 Dec 1996 10:52:26 -0800
From: Eric Hollander <[email-masked]>
Sender: [email-masked]

>if we're gonna whack bgp, then making more is probably
>a Good Idea.  i know we certainly have issues with
>customers needing an AS and there being push-back.

it would really suck to go through the nightmare of an ipv6 transition, and
then find out a couple years later that we need to do another big transition
to some larger asn space.  we might as well do both at the same time, even
if this only means moving from 16 to 32 bits, instead of some more general
scheme.  maybe we could just define that all currently issued asns are 00xx,
where xx are the two bytes of the current asn.

e
- - - - - - - - - - - - - - - - -

To: [email-masked] (Dimitry Haskin)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4+ 
Date: Fri, 20 Dec 1996 13:01:19 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Dimitry Haskin writes
:
> 
> > 
> > The expansion of the AS/RD space is an orthogonal issue, and one that is
> > far more difficult to achieve in a backward compatible fashion.  I would
> > argue that this is beyond the scope of the hack on the table...
> > 
> 
> 1) Is the backward compatibility with BGP4 is really necessary or even useful
>    for v6?

Yes.  It would be a good thing is we could just set the top bits to
zero for some transition period (possible a long period) and then
start using all 32 bits after older BGP4 implementations were gone.

This way there would just be one 32 bit AS space to deal with where
for a long time the top 16 were all zero.

> 2) What are actual benefits and applicability of the proposed multiprotocol
>    capabilities of BGP4+?  Can we require that all v6 RD boundaries
>    stay the same as the v4 AS boundaries for the proposed scheme to work? 

I don't know about requiring it but those of us that want to keep
their sanity might want to do things in a simple manner.  There will
be all IPv4 AS for a long time.  If someone has a need for a different
IPv4 and IPv6 boundaries, then figuring out which routers to IBGP peer
with gets to be a problem.

> 3) Depending on the answer on 1) and 2), it may be that BGPng don't
>    have to be more a hack that BGP4 is, and to this end provide
>    a longer term solution that "the hack on the table".
> 
> 4) Not that I necessary disagree that 2-byte AS space is large enough
>    for the time being,  but, if there is any discomfort with that,
>    it is a perfect opportunity to use expanded space for v6 (to avoid
>    pain later).
> 
> Dimitry

I agree that it would be worthwhile to provide an extension mechanism
in the form of a 32 bit attribute which much match the AS in the lower
16 bits and overrides the AS and specify that NLRI can only be passed
to an older 16 bit AS implementation from an extended AS if the AS
number of the extended AS has all the top bits set to zero.  This
would prevent a routing loop after the transition due to an old
implementation at the expense of isolating the old implemenetation.

All attributes which include AS numbers would be affected, so this is
not a trivial change.  From an implementation standpoint it also means
changing a lot of data structures used internally, but then again so
does the handling of IPv6.

Curtis
- - - - - - - - - - - - - - - - -

To: [email-masked] (Dimitry Haskin)
Cc: [email-masked], [email-masked]
Subject: Re: (IPng 2620) larger AS/RD space for v6? 
Date: Fri, 20 Dec 1996 12:47:04 -0500
From: "Mike O'Dell" <[email-masked]>
Sender: [email-masked]

if we're gonna whack bgp, then making more is probably
a Good Idea.  i know we certainly have issues with
customers needing an AS and there being push-back.

	-mo
- - - - - - - - - - - - - - - - -

Date: Fri, 20 Dec 1996 12:38:22 -0500
From: [email-masked] (Christian Huitema)
To: [email-masked]
Subject: Re: (IPng 2621) Re:  larger AS/RD space for v6?
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Bill,

The statement that "BGP4+ should be IDRP and use RDIs" may be fine, but
should not be related to what EGP will be used for IPv6.  One of the clear
feed-back we received from implementors and early adopters was that "it
has to be the same".  That is, IPv6 should be using whatever IPv4 is
using. Which may well mean BGP4 plus minimal extensions, as long as IPv4
has not yet started using IDRP.

Note that the rationale here is "use existing skills".  Adding a prefix of
the type "1234:5678:9ABC//48" to an existing reachability lists does not
require many new skills.  Switching from one numbering scheme (16 bits AS
number) to another (RDI) does -- you have to make up a new numbering plan.

-- 
Christian Huitema
- - - - - - - - - - - - - - - - -

To: [email-masked] (Dimitry Haskin)
Cc: [email-masked], [email-masked]
Subject: Re: (IPng 2620) larger AS/RD space for v6? 
Date: Fri, 20 Dec 1996 11:25:32 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

this issue is probably more relevant to the IDR WG than
IPNG, but...

i think that bgp4++ should include the ability to carry
RDIs (variable-length ASs)

the bgp4++ proposal on the table includes multi-protocol
extensions.  this significantly extends the lifetime of
bgp4.  to extend the lifetime of a protocol but keep one
of the number spaces (specifically ASs) small and fixed
is, in my opinion, unwise

/jws

 > Folks,
 > 
 > There was a discussion on the IDR list to whether a larger than a 2-byte
 > AS/RD number space is needed to for IPv6.  The discution was prompted by
 > a BGP4+ proposal for v6.  I'd like to solicit input from a larger
 > IPv6-minded audience on this subgect.
 > 
 > The following are snippets from the pro-con arguments:
 > 
 > - The current 2-byte AS number space is sufficient.
 > 
 >   It doesn't look like we'll have a shortage of ASs any time soon.
 >   Currently there are only 1897 ASes in routing system.
 >   Study done by Ramesh Govindan and Anoop Reddy ([email-masked],
 >   [email-masked]) shows that new domain pops up every 12 hours. That is
 >   ~700 domains per year. If the consumption rate of AS space stays
 >   comparable to what we have today, then ~7,000 domains per 10 years...
 > 
 >   We have a lot of life yet before we need to think about introducing
 >   a larger AS/RD space and the backward compatibility issues associated
 >   with this.
 > 
 > 
 > - A larger AS/RD space is needed for IPv6
 > 
 >   Somebody (some whole group of bodies) once thought that a 32-bit IP
 >   address would hold off for a long time....
 > 
 >   Today, there are very strong incentives towards organizations becoming
 >   multi-homed, both for perceived or real increases in reliability
 >   and/or simply because it is often easier to justify "portable" address
 >   space if you're multi-homed.  Given these incentives and the
 >   proliferation of Internet exchanges, I think it is highly questionable
 >   whether a linear model is sufficient to estimate AS number consumption.
 > 
 >   The backword compatibility is not an issue for IPv6 at this point so
 >   it is an opportunity to adopt a large than a 2-byte AS/RD number space
 >   for v6.  If we underestimate IPv6 RD space consumtion rate it may actually
 >   become a painful backword compatibility issue in the future.
 > 
 > 
 > Comments?
 > 
 > Dimitry
 > ----------------------------------------------------------------------------
--
 > IETF IPng Mailing List		      FTP archive: ftp.parc.xerox.com:/
pub/ipng
 > IPng Home Page:          	      http://playground.sun.com/ipng
 > Direct all administrative requests to [email-masked]
- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Susan Hares <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4+ 
Date: Fri, 20 Dec 1996 11:22:22 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, "John W. Stewart III" writes:
> 
>  > > 2) Security Considerations
>  > > 
>  > > BGP-4++ is just as secure or un-secure as BGP-4.  
>  > 
>  > To be more precise the two new attributes do not alter
>  > BGP-4 security properties.
>  > 
>  > > Is it your understanding that users need this security or is
>  > > TCP good enough?
>  > 
>  > I would like to get a feedback from the WG on this question.
> 
> at least one Popular Router Vendor has a feature for
> enabling security for bgp.  my understanding (correct
> me if i'm wrong) is that this is done via crypto-
> checksum of the underlying tcp connection .. which has
> the nice result of protecting the bgp process as well
> as the underlying tcp connection from SYN and RST
> attacks (bgp-only security wouldn't protect the latter)

The NSS did this back in 1992 with BGP3, the auth field, and an MD4
check in each BGP packet.  Today we'd be more likely to use MD5.

> if i were a provider, then i think this would be enough
> for me right now

That's fine.  All we need now is a way to protect against RST.

> idrp provides for its own transport, right? does that
> include anything in the way of security?  i ask to know
> if any already-existing specs with alternatives exist
> 
> /jws

Use IDRP if you prefer.

This reminds me of the "abandon Unix because Mach does X better"
arguments.  Nothing wrong with Unix taking the better ideas from Mach
like copy on write VM semantics and leaving behind those things that
didn't work out as well.

Same with BGP.  There is a lot of excess baggage that needs to be
dumped from IDRP.  It might be better to take the (few) better
features of IDRP and respin BGP.  In other words, IDRP is *not* BGP5.

Curtis
- - - - - - - - - - - - - - - - -

From: [email-masked]
Posted-Date: Fri, 20 Dec 1996 08:20:12 -0800 (PST)
Subject: Re: (IPng 2620) larger AS/RD space for v6?
To: [email-masked] (Dimitry Haskin)
Date: Fri, 20 Dec 1996 08:20:12 -0800 (PST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> There was a discussion on the IDR list to whether a larger than a 2-byte
> AS/RD number space is needed to for IPv6.  The discution was prompted by
> a BGP4+ proposal for v6.  I'd like to solicit input from a larger
> IPv6-minded audience on this subgect.
> 

	BGP4+ should be IDRP and use RDIs.

-- 
--bill
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4+ 
Date: Fri, 20 Dec 1996 11:12:18 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> Sue,
> 
> > A few comments on the draft:
> > 
> > 
> > 1) From the section below and the address family,
> >    IPv6 and IPv4 cannot point to a common next hop.
> 
> They can point to the same router. However, the next hop for IPv6 NLRI
> has to point to an IPv6 address, while the next hop for IPv4 NLRI has
> to point to an IPv4 address.

On an IPv6 router why can't you just pack IPv4 addresses into IPv6
using the prescribed IPv6 top bits and just have one routing table and
forwarding table?

> > 2) Security Considerations
> > 
> > BGP-4++ is just as secure or un-secure as BGP-4.  
> 
> To be more precise the two new attributes do not alter
> BGP-4 security properties.

That covers it.

> > Is it your understanding that users need this security or is
> > TCP good enough?
> 
> I would like to get a feedback from the WG on this question.

Not really but we have to live with it.

How about if we fixed that in a separate extension to BGP4?

Would the ability to quickly reestablish with a grace period eliminate
the RST problem be enough?  If so we already have text for an
extension that is backwards compatible with BGP and provides that.

> Yakov.

Curtis
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: "John W. Stewart III" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: BGP-4+ 
Date: Fri, 20 Dec 1996 11:06:31 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Yakov Rekhter writes:
> John,
>  
> > under what circumstances does a router send SNPAs? and
> > what does a router do on receipt of SNPAs?
> 
> One possible application for SNPA is operation of BGP over NBMA (e.g.,
> ATM). Passing SNPA allows to avoid any additional mechanisms to resolve
> IP to SNPA mapping in the NBMA environment.

This is a very worthwhile addition to BGP.

Its amazing no one ever thought of this before.  :-)

> > also, from reading the draft, i'm assuming that you plan
> > to support only ASs and not RDs? did you consider typing
> > routing domains in addition to network addresses?
> 
> I am a bit confused - in my mind "RD" and "AS" describe
> pretty much similar thing. 

Its just a matter of the number of bits.

There are still more electrons in the universe than covered by the AS
number space.  :-)

Besides, on a BGP/IDRP border (in case anyone ever uses IDRP)
you'd need the additional bits to carry an IDRP RD.

> Yakov.

Curtis
- - - - - - - - - - - - - - - - -

Posted-Date: Fri, 20 Dec 1996 11:03:51 -0500 (EST)
Date: Fri, 20 Dec 1996 10:59:04 -0500
From: [email-masked] (Dimitry Haskin)
To: [email-masked]
Subject: larger AS/RD space for v6?
Cc: [email-masked]
Sender: [email-masked]

Folks,

There was a discussion on the IDR list to whether a larger than a 2-byte
AS/RD number space is needed to for IPv6.  The discution was prompted by
a BGP4+ proposal for v6.  I'd like to solicit input from a larger
IPv6-minded audience on this subgect.

The following are snippets from the pro-con arguments:

- The current 2-byte AS number space is sufficient.

  It doesn't look like we'll have a shortage of ASs any time soon.
  Currently there are only 1897 ASes in routing system.
  Study done by Ramesh Govindan and Anoop Reddy ([email-masked],
  [email-masked]) shows that new domain pops up every 12 hours. That is
  ~700 domains per year. If the consumption rate of AS space stays
  comparable to what we have today, then ~7,000 domains per 10 years...

  We have a lot of life yet before we need to think about introducing
  a larger AS/RD space and the backward compatibility issues associated
  with this.

- A larger AS/RD space is needed for IPv6

  Somebody (some whole group of bodies) once thought that a 32-bit IP
  address would hold off for a long time....

  Today, there are very strong incentives towards organizations becoming
  multi-homed, both for perceived or real increases in reliability
  and/or simply because it is often easier to justify "portable" address
  space if you're multi-homed.  Given these incentives and the
  proliferation of Internet exchanges, I think it is highly questionable
  whether a linear model is sufficient to estimate AS number consumption.

  The backword compatibility is not an issue for IPv6 at this point so
  it is an opportunity to adopt a large than a 2-byte AS/RD number space
  for v6.  If we underestimate IPv6 RD space consumtion rate it may actually
  become a painful backword compatibility issue in the future.

Comments?

Dimitry
- - - - - - - - - - - - - - - - -

To: Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-4+ 
Date: Thu, 19 Dec 1996 15:00:23 PST
From: Brad Smith <[email-masked]>
Sender: [email-masked]

>    > A comment and question.  TCP and similar peer-to-peer security does
>    > not protect against a subverted speaker.  If an intruder is able to
>    > break into a speaker, where it would get access to all TCP security
>    > related keys, it would then be able to have it's way with the protocol
>    > (e.g. fabricate, modify, and replay routing information).
> 
>    Permit me to observe here that when there is subverted speaker, change
>    to BGP protocol spec isn't good enough to contain possible damage.
> 
> True.  In fact, Radia Perlman has looked at the subverted speaker problem
> quite a bit.  It turns out that you basically need a link state protocol to
> disseminate enough information to still have a functioning network.  And
> the cost in redundancy and additional computation is non-trivial.  
> 
> It's a major architectural change, which I haven't seen any willingness to
> pay for either in the enterprise market or in the Internet backbone.

True, although Radia's goal (in her PhD thesis) of what she called
Byzantine Robustness (the ability to continue correct operation in
the presence of arbitrary nodes with Byzantine failures) is quite
high.  It may be possible that there are lower goals that are still
very useful that can be acheived with information available in current
BGP updates.  I had the beginnings of a proposal for such a solution
until I talked to Sue Hares at the IETF... she "clarified":) a few issues
that pretty much shot my proposal, although I think there's still hope.

However, I should re-lurk on this specific issue until I have something
more concrete to say.

My main point/question was that providing only peer-to-peer measures
leaves the protocol vulnerable to subverted speakers, and whether this
was considered a significant threat.  I think my question was answered
(yes, it is significant, but not worth the pain that current solutions
would incur).

Brad
- - - - - - - - - - - - - - - - -

Date: Thu, 19 Dec 1996 17:24:47 -0500 (EST)
From: "Dorian R. Kim" <[email-masked]>
To: Brad Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-4+ 
Sender: [email-masked]

On Thu, 19 Dec 1996, Brad Smith wrote:

> > Permit me to observe here that when there is subverted speaker, change to BGP
> > protocol spec isn't good enough to contain possible damage.
> 
> This is certainly the challenge; however, I think, if you take the
> perspective of minimizing or eliminating what a speaker can say
> about resources it doesn't have authority for, you can go a long
> way toward containing damage.

This seems to involve authentication AND authorization, and some manner in
which both can be independently verified. This too me is an absolutely
non-trivial set up, and I seriousl question the scalability of it. It would 
also IMO, imposes significant restrictions in routing flexibility.
Furthermore, this type of scheme is very likely to show operationally
unacceptable failure modes during network failures unless we someone come up
with completely out-of-band signaling. 

> > While this threat is not that unlikely and should not be ignored, my view on
> > this is that the prevention should take the form of speaker/host hardening
> > rather than modification of BGP transport.
> 
> Hardening involves procedures and people in addition to technology; what
> you say implies imposing significant restrictions on who can operate a
> BGP speaker to achieve any significant improvements in security.  Is this
> realistic?

Sure, you have to start from simple physical access to people to boxes and
bits. And then there is a point where you draw the line between manageability
and security. Routers can be protected better than they are currently
protected in most places without incurring too much of an overhead, human or
otherwise.

> > I especially wonder about scalability aspect of such modifications, strictly
> > from an operational perspective.
> 
> Absolutely.  This is the final measure... is the illness more painful
> than the cure.  It is certainly going to be quite painful.

I suspect that the cure's side affect will make it unpalatable.

-dorian

- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: Thu, 19 Dec 1996 17:18:17 -0500 (EST)
To: [email-masked]
Subject: Discussion on Multiprotocol Attribute
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I'd like to suggest that the multiprotocol attribute
discussion have a deadline of 1/15/97. 

So if you have comments on the draft, please send
them by that time.

Best wishes for a wonderful
and peaceful holiday season! 

Sue Hares

- - - - - - - - - - - - - - - - -

To: "Dorian R. Kim" <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-4+ 
Date: Thu, 19 Dec 1996 14:08:51 PST
From: Brad Smith <[email-masked]>
Sender: [email-masked]

> Permit me to observe here that when there is subverted speaker, change to BGP
> protocol spec isn't good enough to contain possible damage.

This is certainly the challenge; however, I think, if you take the
perspective of minimizing or eliminating what a speaker can say
about resources it doesn't have authority for, you can go a long
way toward containing damage.

> While this threat is not that unlikely and should not be ignored, my view on
> this is that the prevention should take the form of speaker/host hardening
> rather than modification of BGP transport.

Hardening involves procedures and people in addition to technology; what
you say implies imposing significant restrictions on who can operate a
BGP speaker to achieve any significant improvements in security.  Is this
realistic?

> I especially wonder about scalability aspect of such modifications, strictly
> from an operational perspective.

Absolutely.  This is the final measure... is the illness more painful
than the cure.  It is certainly going to be quite painful.

Brad
- - - - - - - - - - - - - - - - -

Date: Thu, 19 Dec 1996 14:03:35 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked] (Dorian R. Kim)
Cc: [email-masked]
Subject: Re: BGP-4+
Sender: [email-masked]

   > A comment and question.  TCP and similar peer-to-peer security does
   > not protect against a subverted speaker.  If an intruder is able to
   > break into a speaker, where it would get access to all TCP security
   > related keys, it would then be able to have it's way with the protocol
   > (e.g. fabricate, modify, and replay routing information).

   Permit me to observe here that when there is subverted speaker, change
   to BGP protocol spec isn't good enough to contain possible damage.

True.  In fact, Radia Perlman has looked at the subverted speaker problem
quite a bit.  It turns out that you basically need a link state protocol to
disseminate enough information to still have a functioning network.  And
the cost in redundancy and additional computation is non-trivial.  

It's a major architectural change, which I haven't seen any willingness to
pay for either in the enterprise market or in the Internet backbone.

Tony

- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: Thu, 19 Dec 1996 16:47:03 -0500 (EST)
To: [email-masked]
Subject: Archive mistake
Cc: [email-masked]
Sender: [email-masked]

Alison Makin pointed out the archive on the
mail list for idr/bgp is incorrect.  Here's the
correct archive pointers:

Archive:           ftp://ftp.merit.edu/mail.archives/idr
hypertext:         http://ww.merit.edu/mail.archives/html/idr         

		   (just started with current mail)

A corrected charter will be posted to the ietf-web
within a few days.

Sue Hares

- - - - - - - - - - - - - - - - -

From: [email-masked]
Posted-Date: Thu, 19 Dec 1996 13:40:51 -0800 (PST)
Subject: Re: BGP-4+
To: [email-masked] (Yakov Rekhter)
Date: Thu, 19 Dec 1996 13:40:51 -0800 (PST)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> Study done by Ramesh Govindan and Anoop Reddy ([email-masked],
> [email-masked]) shows that new domain pops up every 12 hours. That is
> ~700 domains per year. If the consumption rate of AS space stays
> comparable to what we have today, then ~7,000 domains per 10 years...
> 
> Yakov.
> 

	And where to RDIs fit into this picture?

-- 
--bill
- - - - - - - - - - - - - - - - -

Date: Thu, 19 Dec 1996 15:21:42 -0500 (EST)
From: "Dorian R. Kim" <[email-masked]>
To: Brad Smith <[email-masked]>
Cc: [email-masked]
Subject: Re: BGP-4+ 
Sender: [email-masked]

On Thu, 19 Dec 1996, Brad Smith wrote:

> A comment and question.  TCP and similar peer-to-peer security does
> not protect against a subverted speaker.  If an intruder is able to
> break into a speaker, where it would get access to all TCP security
> related keys, it would then be able to have it's way with the protocol
> (e.g. fabricate, modify, and replay routing information).

Permit me to observe here that when there is subverted speaker, change to BGP
protocol spec isn't good enough to contain possible damage.

> Is this threat considered unlikely enough that it can be ignored?

While this threat is not that unlikely and should not be ignored, my view on
this is that the prevention should take the form of speaker/host hardening
rather than modification of BGP transport.

I especially wonder about scalability aspect of such modifications, strictly
from an operational perspective.

-dorian

- - - - - - - - - - - - - - - - -

To: "Dorian R. Kim" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Susan Hares <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Thu, 19 Dec 1996 12:05:35 PST
From: Brad Smith <[email-masked]>
Sender: [email-masked]

> > > 2) Security Considerations
> > > Is it your understanding that users need this security or is
> > > TCP good enough?
> > 
> > I would like to get a feedback from the WG on this question.
> 
> While security is a concern, I don't think we need in-protocol security
> support. IMO, the best place to apply effort is in securing TCP, where we
> already have tools at our disposal.
> 
> -dorian

A comment and question.  TCP and similar peer-to-peer security does
not protect against a subverted speaker.  If an intruder is able to
break into a speaker, where it would get access to all TCP security
related keys, it would then be able to have it's way with the protocol
(e.g. fabricate, modify, and replay routing information).

Is this threat considered unlikely enough that it can be ignored?

I've been working on countermeasures to this subverted speaker threat,
and it seems that it requires changes to the protocol.

Brad Smith
Computer Sciences
UC Santa Cruz

PS - A related question.  Has anyone looked into whether IP-SEC
     mechanisms secure TCP?  I started looking at this, and it
     seemed that IP-SEC went a long way, but maybe not all the
     way to securing TCP...
- - - - - - - - - - - - - - - - -

To: Dave Katz <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Thu, 19 Dec 1996 10:46:12 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

 > The expansion of the AS/RD space is an orthogonal issue, and one that is
 > far more difficult to achieve in a backward compatible fashion.  I would
 > argue that this is beyond the scope of the hack on the table...

i understand what you're saying

but it makes me wonder what the goal is of these bgp4 extensions.
i had thought that it was mainly to make it easier for providers
to start routing ipv6:  by allowing bgp4 to do it, then we get to
use a protocol we already know very well.  by allowing bgp4 to
route ipv6 (as well as any other protocol with an Address Family
identifier) then couldn't bgp4 become even more entreanched than
it already is?  in other words, if bgp4 becomes multiprotocol,
then why would i *ever* care to switch to idrp?  and if the result
of this is an increased lifetime for bgp4, then shouldn't the
future of the AS space be addressed now?

if the authors of the draft had envisioned a different future,
then perhaps it would be useful for that to be spelled out

/jws

 > 
 >    X-Auth: NOLNET SENDMAIL AUTH
 >    Date: Wed, 18 Dec 1996 17:31:25 -0600 (CST)
 >    From: Brandon Black <[email-masked]>
 >    Mime-Version: 1.0
 >    Content-Type: TEXT/PLAIN; charset=US-ASCII
 >    Sender: [email-masked]
 >    Precedence: bulk
 > 
 >    On Wed, 18 Dec 1996, Yakov Rekhter wrote:
 > 
 >    > John,
 >    >  
 >    > >  > > also, from reading the draft, i'm assuming that you plan
 >    > >  > > to support only ASs and not RDs? did you consider typing
 >    > >  > > routing domains in addition to network addresses?
 >    > >  > 
 >    > >  > I am a bit confused - in my mind "RD" and "AS" describe
 >    > >  > pretty much similar thing. 
 >    > > 
 >    > > AS is two bytes, while RD is variable.  right? or is
 >    > > it me that's confused?
 >    > 
 >    > Ok, I got it (I was confused). 
 >    > 
 >    > To answer your question, it doesn't look like we'll have shortage of 
 >    > ASs any time soon. So, it is not clear if there is a need for variable
 >    > length RDs.
 >    > 
 >    > Yakov.
 >    > 
 > 
 >    Famous last words :)
 > 
 >    Bill Gates I think once said something along the lines of "nobody will
 >    _ever_ need more than 640 kilobytes of main memory"
 > 
 >    And somebody (some whole group of bodies) once thought that a 32-bit IP
 >    address would hold off for along time....
 > 
 >    Just food for thought...
 > 
 >    .................................             ..............
 >    : Brandon Lee Black  : [Office] :.............: [Personal] :....
 >    :....................: [email-masked] : [email-masked] :.......
 >    : "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
 >    : trademark of a     :.................:..../\: [email-masked] :
 >    : weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
 >    :....................:.....................:..:.................:
 > 
 > 
- - - - - - - - - - - - - - - - -

Posted-Date: Thu, 19 Dec 1996 10:29:57 -0500 (EST)
Date: Thu, 19 Dec 1996 10:25:11 -0500
From: [email-masked] (Dimitry Haskin)
To: [email-masked]
Subject: Re: BGP-4+
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

> 
> The expansion of the AS/RD space is an orthogonal issue, and one that is
> far more difficult to achieve in a backward compatible fashion.  I would
> argue that this is beyond the scope of the hack on the table...
> 

1) Is the backward compatibility with BGP4 is really necessary or even useful
   for v6?

2) What are actual benefits and applicability of the proposed multiprotocol
   capabilities of BGP4+?  Can we require that all v6 RD boundaries
   stay the same as the v4 AS boundaries for the proposed scheme to work? 

3) Depending on the answer on 1) and 2), it may be that BGPng don't
   have to be more a hack that BGP4 is, and to this end provide
   a longer term solution that "the hack on the table".

4) Not that I necessary disagree that 2-byte AS space is large enough
   for the time being,  but, if there is any discomfort with that,
   it is a perfect opportunity to use expanded space for v6 (to avoid
   pain later).

Dimitry
- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: Wed, 18 Dec 1996 17:26:17 -0500 (EST)
To: [email-masked]
Subject: Please send request to idr-request
Sender: [email-masked]

Sue

- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: Brandon Black <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Thu, 19 Dec 1996 12:21:05 +0900
From: "David R. Conrad" <[email-masked]>
Sender: [email-masked]

Yakov,

>Study done by Ramesh Govindan and Anoop Reddy ([email-masked],
>[email-masked]) shows that new domain pops up every 12 hours. That is
>~700 domains per year. If the consumption rate of AS space stays
>comparable to what we have today, then ~7,000 domains per 10 years...

Today, there are very strong incentives towards organizations becoming
multi-homed, both for perceived or real increases in reliability
and/or simply because it is often easier to justify "portable" address
space if you're multi-homed.  Given these incentives and the
proliferation of Internet exchanges, I think it is highly questionable
whether a linear model is sufficient to estimate AS number
consumption.

However, as currently about 13% of the AS space has either been
allocated or reserved, I agree with Tony that we have some life
left in the AS space, although I think we should start considering
ways of extending AS space in a backwards compatible fashion.

Regards,
-drc

- - - - - - - - - - - - - - - - -

Date: Wed, 18 Dec 1996 16:42:32 -0800
From: Dave Katz <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: BGP-4+ 
Sender: [email-masked]

The expansion of the AS/RD space is an orthogonal issue, and one that is
far more difficult to achieve in a backward compatible fashion.  I would
argue that this is beyond the scope of the hack on the table...

   X-Auth: NOLNET SENDMAIL AUTH
   Date: Wed, 18 Dec 1996 17:31:25 -0600 (CST)
   From: Brandon Black <[email-masked]>
   Mime-Version: 1.0
   Content-Type: TEXT/PLAIN; charset=US-ASCII
   Sender: [email-masked]
   Precedence: bulk

   On Wed, 18 Dec 1996, Yakov Rekhter wrote:

   > John,
   >  
   > >  > > also, from reading the draft, i'm assuming that you plan
   > >  > > to support only ASs and not RDs? did you consider typing
   > >  > > routing domains in addition to network addresses?
   > >  > 
   > >  > I am a bit confused - in my mind "RD" and "AS" describe
   > >  > pretty much similar thing. 
   > > 
   > > AS is two bytes, while RD is variable.  right? or is
   > > it me that's confused?
   > 
   > Ok, I got it (I was confused). 
   > 
   > To answer your question, it doesn't look like we'll have shortage of 
   > ASs any time soon. So, it is not clear if there is a need for variable
   > length RDs.
   > 
   > Yakov.
   > 

   Famous last words :)

   Bill Gates I think once said something along the lines of "nobody will
   _ever_ need more than 640 kilobytes of main memory"

   And somebody (some whole group of bodies) once thought that a 32-bit IP
   address would hold off for along time....

   Just food for thought...

   .................................             ..............
   : Brandon Lee Black  : [Office] :.............: [Personal] :....
   :....................: [email-masked] : [email-masked] :.......
   : "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
   : trademark of a     :.................:..../\: [email-masked] :
   : weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
   :....................:.....................:..:.................:

- - - - - - - - - - - - - - - - -

To: Brandon Black <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, "John W. Stewart III" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
From: Tony Bates <[email-masked]>
Date: Wed, 18 Dec 1996 16:15:37 -0800
Sender: [email-masked]

 Brandon Black <[email-masked]> writes:
  * 
  * Famous last words :)
  *
Perhaps, but just a few data points as seen on a well connected router
this morning. 

Number of ASes in routing system:                 1897

Number of ASes announcing only one prefix:         773 

So we have quite way to go yet. If you couple this with RFC1930 and
the use of private AS space when appropriate I think we have a lot of
life yet before we need to think about introducing a larger AS/RD
space and the backwards compatability issues associated with this or
introducing another protocol.

		--Tony

P.S. Some of us still believe a 32-bit address will hold us for a
while yet but this is a different issue ;-).
 
  * Bill Gates I think once said something along the lines of "nobody will
  * _ever_ need more than 640 kilobytes of main memory"
  * 
  * And somebody (some whole group of bodies) once thought that a 32-bit IP
  * address would hold off for along time....
  * 
  * Just food for thought...
  * 
  * .................................             ..............
  * : Brandon Lee Black  : [Office] :.............: [Personal] :....
  * :....................: [email-masked] : [email-masked] :.......
  * : "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
  * : trademark of a     :.................:..../\: [email-masked] :
  * : weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
  * :....................:.....................:..:.................:
  * 
- - - - - - - - - - - - - - - - -

To: Brandon Black <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 96 16:02:38 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Brandon,

> > To answer your question, it doesn't look like we'll have shortage of 
> > ASs any time soon. So, it is not clear if there is a need for variable
> > length RDs.
>  
> Famous last words :)

Yes, indeed :-)

> Bill Gates I think once said something along the lines of "nobody will
> _ever_ need more than 640 kilobytes of main memory"

Study done by Ramesh Govindan and Anoop Reddy ([email-masked],
[email-masked]) shows that new domain pops up every 12 hours. That is
~700 domains per year. If the consumption rate of AS space stays
comparable to what we have today, then ~7,000 domains per 10 years...

Yakov.
- - - - - - - - - - - - - - - - -

Date: Wed, 18 Dec 1996 18:56:52 -0500 (EST)
From: "Dorian R. Kim" <[email-masked]>
Reply-To: "Dorian R. Kim" <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Sender: [email-masked]

On Wed, 18 Dec 1996, Yakov Rekhter wrote:

> > 2) Security Considerations
> > Is it your understanding that users need this security or is
> > TCP good enough?
> 
> I would like to get a feedback from the WG on this question.

While security is a concern, I don't think we need in-protocol security
support. IMO, the best place to apply effort is in securing TCP, where we
already have tools at our disposal.

-dorian

- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 1996 18:48:33 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

 > > 2) Security Considerations
 > > 
 > > BGP-4++ is just as secure or un-secure as BGP-4.  
 > 
 > To be more precise the two new attributes do not alter
 > BGP-4 security properties.
 > 
 > > Is it your understanding that users need this security or is
 > > TCP good enough?
 > 
 > I would like to get a feedback from the WG on this question.

at least one Popular Router Vendor has a feature for
enabling security for bgp.  my understanding (correct
me if i'm wrong) is that this is done via crypto-
checksum of the underlying tcp connection .. which has
the nice result of protecting the bgp process as well
as the underlying tcp connection from SYN and RST
attacks (bgp-only security wouldn't protect the latter)

if i were a provider, then i think this would be enough
for me right now

idrp provides for its own transport, right? does that
include anything in the way of security?  i ask to know
if any already-existing specs with alternatives exist

/jws
- - - - - - - - - - - - - - - - -

Date: Wed, 18 Dec 1996 17:31:25 -0600 (CST)
From: Brandon Black <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: "John W. Stewart III" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Sender: [email-masked]

On Wed, 18 Dec 1996, Yakov Rekhter wrote:

> John,
>  
> >  > > also, from reading the draft, i'm assuming that you plan
> >  > > to support only ASs and not RDs? did you consider typing
> >  > > routing domains in addition to network addresses?
> >  > 
> >  > I am a bit confused - in my mind "RD" and "AS" describe
> >  > pretty much similar thing. 
> > 
> > AS is two bytes, while RD is variable.  right? or is
> > it me that's confused?
> 
> Ok, I got it (I was confused). 
> 
> To answer your question, it doesn't look like we'll have shortage of 
> ASs any time soon. So, it is not clear if there is a need for variable
> length RDs.
> 
> Yakov.
> 

Famous last words :)

Bill Gates I think once said something along the lines of "nobody will
_ever_ need more than 640 kilobytes of main memory"

And somebody (some whole group of bodies) once thought that a 32-bit IP
address would hold off for along time....

Just food for thought...

.................................             ..............
: Brandon Lee Black  : [Office] :.............: [Personal] :....
:....................: [email-masked] : [email-masked] :.......
: "Sanity is the     : +1.281.362.6466 .......: [email-masked] :
: trademark of a     :.................:..../\: [email-masked] :
: weak mind. . ."    : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
:....................:.....................:..:.................:

- - - - - - - - - - - - - - - - -

To: Susan Hares <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 96 14:59:12 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Sue,

> A few comments on the draft:
> 
> 
> 1) From the section below and the address family,
>    IPv6 and IPv4 cannot point to a common next hop.

They can point to the same router. However, the next hop for IPv6 NLRI
has to point to an IPv6 address, while the next hop for IPv4 NLRI has
to point to an IPv4 address.

> 2) Security Considerations
> 
> BGP-4++ is just as secure or un-secure as BGP-4.  

To be more precise the two new attributes do not alter
BGP-4 security properties.

> Is it your understanding that users need this security or is
> TCP good enough?

I would like to get a feedback from the WG on this question.

Yakov.
- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 96 14:46:34 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
>  > > also, from reading the draft, i'm assuming that you plan
>  > > to support only ASs and not RDs? did you consider typing
>  > > routing domains in addition to network addresses?
>  > 
>  > I am a bit confused - in my mind "RD" and "AS" describe
>  > pretty much similar thing. 
> 
> AS is two bytes, while RD is variable.  right? or is
> it me that's confused?

Ok, I got it (I was confused). 

To answer your question, it doesn't look like we'll have shortage of 
ASs any time soon. So, it is not clear if there is a need for variable
length RDs.

Yakov.
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 1996 17:37:52 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

 > > also, from reading the draft, i'm assuming that you plan
 > > to support only ASs and not RDs? did you consider typing
 > > routing domains in addition to network addresses?
 > 
 > I am a bit confused - in my mind "RD" and "AS" describe
 > pretty much similar thing. 

AS is two bytes, while RD is variable.  right? or is
it me that's confused?

/jws
- - - - - - - - - - - - - - - - -

To: "John W. Stewart III" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 96 14:27:54 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> under what circumstances does a router send SNPAs? and
> what does a router do on receipt of SNPAs?

One possible application for SNPA is operation of BGP over NBMA (e.g.,
ATM). Passing SNPA allows to avoid any additional mechanisms to resolve
IP to SNPA mapping in the NBMA environment.

> also, from reading the draft, i'm assuming that you plan
> to support only ASs and not RDs? did you consider typing
> routing domains in addition to network addresses?

I am a bit confused - in my mind "RD" and "AS" describe
pretty much similar thing. 

Yakov.
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 1996 17:21:15 EST
From: "John W. Stewart III" <[email-masked]>
Sender: [email-masked]

yakov,

under what circumstances does a router send SNPAs? and
what does a router do on receipt of SNPAs?

also, from reading the draft, i'm assuming that you plan
to support only ASs and not RDs? did you consider typing
routing domains in addition to network addresses?

thanks,
/jws

 > Sue,
 > 
 > > 
 > > Hi all:
 > > 
 > > 
 > > FYI - Neither Dimitry or Dave Katz have forwarded a specification
 > > for the BGP-4+.  Please encourage them to forward
 > > a description of the protocol to the idr working group.
 > > An open discussion of changes to bgp-4 is always welcome.
 > > Yakov and I both expressed interest in getting a specification
 > > before the working group.  We did not discuss it at the
 > > December meeting because there was not a specification.
 > > 
 > > [This ends my speaking as the co-chair of IDR working group.]
 > 
 > Attached is the proposal from Tony Bates, Ravi Chandra, Dave Katz
 > and myself for backward compatible multiprotocol extensions to
 > BGP-4.
 > 
 > Yakov.
 > 
 > P.S. I added [email-masked] to the cc: list.
 > --------------------------------------------------------------------
 > 
 > 
 > 
 > 
 > 
 > Network Working Group                                   Tony Bates
 > Internet Draft                                       Cisco Systems
 > Expiration Date: June  1997                           Ravi Chandra
 >                                                      Cisco Systems
 >                                                          Dave Katz
 >                                                      Cisco Systems
 >                                                      Yakov Rekhter
 >                                                      Cisco Systems
 > 
 > 
 >                    Multiprotocol Extensions for BGP-4
 > 
 >                  draft-bates-bgp4-multiprotocol-00.txt
 > 
 > 
 > 1. Status of this Memo
 > 
 >    This document is an Internet-Draft.  Internet-Drafts are working
 >    documents of the Internet Engineering Task Force (IETF), its areas,
 >    and its working groups.  Note that other groups may also distribute
 >    working documents as Internet-Drafts.
 > 
 >    Internet-Drafts are draft documents valid for a maximum of six months
 >    and may be updated, replaced, or obsoleted by other documents at any
 >    time.  It is inappropriate to use Internet-Drafts as reference
 >    material or to cite them other than as ``work in progress.''
 > 
 >    To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
 >    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
 >    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
 >    ftp.isi.edu (US West Coast).
 > 
 > 
 > 2. Abstract
 > 
 >    Currently BGP-4 [BGP-4] is capable of carrying routing information
 >    only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
 >    enable it to carry routing information for multiple Network Layer
 >    protocols (e.g., IPv6, IPX, etc...). The extensions are backward
 >    compatible - a router that supports the extensions can interoperate
 >    with a router that doesn't support the extensions.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 1]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 > 3. Overview
 > 
 >    The only three pieces of information carried by BGP-4 that are IPv4
 >    specific are (a) the NEXT_HOP attribute (expressed as an IPv4
 >    address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI
 >    (expressed as IPv4 address prefixes). This document assumes that any
 >    BGP speaker (including the one that supports multiprotocol
 >    capabilities defined in this document) will have to support IPv4 and
 >    have an IPv4 address.  Therefore, to enable BGP-4 to support routing
 >    for multiple Network Layer protocols the only two things that have to
 >    be added to BGP-4 are (a) the ability to associate a particular
 >    Network Layer protocol with the next hop information, and (b) the
 >    ability to associated a particular Network Layer protocol with NLRI.
 >    To identify individual Network Layer protocols this document uses
 >    Address Family, as defined in [RFC1700].
 > 
 >    One could further observe that the next hop information (the
 >    information provided by the NEXT_HOP attribute) is meaningful (and
 >    necessary) only in conjunction with the advertisements of reachable
 >    destinations - in conjunction with the advertisements of unreachable
 >    destinations (withdrawing routes from service) the next hop
 >    information is meaningless. This suggests that the advertisement of
 >    reachable destinations should be grouped with the advertisement of
 >    the next hop to be used for these destinations, and that the
 >    advertisement of reachable destinations should be segregated from the
 >    advertisement of unreachable destinations.
 > 
 >    To provide backward compatibility, as well as to simplify
 >    introduction of the multiprotocol capabilities into BGP-4 this
 >    document uses two new attributes, Multiprotocol Reachable NLRI
 >    (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI
 >    (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the
 >    set of reachable destinations together with the next hop information
 >    to be used for forwarding to these destinations. The second one
 >    (MP_UNREACH_NLRI) is used to carry the set of unreachable
 >    destinations.  Both of these attributes are optional and non-
 >    transitive.  This way a BGP speaker that doesn't support the
 >    multiprotocol capabilities would just ignore the information carried
 >    in these attributes, and wouldn't pass it to other BGP speakers.
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 2]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 > 4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):
 > 
 >    This is an optional non-transitive attribute that can be used for the
 >    following purposes:
 > 
 >       (a) to advertise a feasible route to a peer
 > 
 >       (b) to permit a router to advertise the Network Layer address of
 >       the router that should be used as the next hop to the destinations
 >       listed in the Network Layer Reachability Information field of the
 >       MP_NLRI attribute.
 > 
 >       (c) to allow a given router to report some or all of the
 >       Subnetwork Points of Attachment (SNPAs) that exist within the
 >       local system
 > 
 > 
 >    The attribute consists of two components, the next hop information
 >    and the list of reachable destinations.
 > 
 >    The attribute is encoded as shown below:
 > 
 > 
 >       +---------------------------------------------------+
 >       | Address Family (2 octets)                         |
 >       +---------------------------------------------------+
 >       | Length of Network Address (1 octet)               |
 >       +---------------------------------------------------+
 >       | Network Address of Next Hop (variable)            |
 >       +---------------------------------------------------+
 >       | Number of SNPAs (1 octet)                         |
 >       +---------------------------------------------------+
 >       | Length of first SNPA(1 octet)                     |
 >       +---------------------------------------------------+
 >       | First SNPA (variable)                             |
 >       +---------------------------------------------------+
 >       | Length of second SNPA (1 octet)                   |
 >       +---------------------------------------------------+
 >       | Second SNPA (variable)                            |
 >       +---------------------------------------------------+
 >       | ...                                               |
 >       +---------------------------------------------------+
 >       | Length of Last SNPA (1 octet)                     |
 >       +---------------------------------------------------+
 >       | Last SNPA (variable)                              |
 >       +---------------------------------------------------+
 >       | Network Layer Reachability Information (variable) |
 >       +---------------------------------------------------+
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 3]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 >    The use and meaning of these fields are as follows:
 > 
 >       Address Family
 > 
 >          This field carries the identity of the Network Layer protocol
 >          associated with the Network Address that follows. Presently
 >          defined values for this field are specified in RFC1700.
 > 
 >       Length of Network Address:
 > 
 >          A 1 octet field whose value expresses the length of the
 >          "Network Address of Next Hop" field as measured in octets
 > 
 >       Network Address of Next Hop:
 > 
 >          A variable length field that contains the Network Address of
 >          the next router on the path to the destination system
 > 
 >       Number of SNPAs:
 > 
 >          A 1 octet field which contains the number of distinct SNPAs to
 >          be listed in the following fields.  The value 0 may be used to
 >          indicate that no SNPAs are listed in this attribute.
 > 
 >       Length of Nth SNPA:
 > 
 >          A 1 octet field whose value expresses the length of the "Nth
 >          SNPA of Next Hop" field as measured in semi-octets
 > 
 >       Nth SNPA of Next Hop:
 > 
 >          A variable length field that contains an SNPA of the router
 >          whose Network Address is contained in the "Network Address of
 >          Next Hop" field.  The field length is an integral number of
 >          octets in length, namely the rounded-up integer value of one
 >          half the SNPA length expressed in semi-octets; if the SNPA
 >          contains an odd number of semi-octets, a value in this field
 >          will be padded with a trailing all-zero semi-octet.
 > 
 >       Network Layer Reachability Information:
 > 
 >          A variable length field that lists the destinations for the
 >          feasible routes that are being advertised in this attribute.
 >          Each NLRI is encoded as specified in the "NLRI encoding"
 >          section of this document.
 > 
 >    The next hop information carried in the MP_REACH_NLRI path attribute
 >    defines the Network Layer address of the border router that should be
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 4]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 >    used as the next hop to the destinations listed in the MP_NLRI
 >    attribute in the UPDATE message.  When advertising a MP_REACH_NLRI
 >    attribute to an external peer, a router may use one of its own
 >    interface addresses in the next hop component of the attribute,
 >    provided the external peer to which the route is being advertised
 >    shares a common subnet with the next hop address.  This is known as a
 >    "first party" next hop.  A BGP speaker can advertise to an external
 >    peer an interface of any internal peer router in the next hop
 >    component, provided the external peer to which the route is being
 >    advertised shares a common subnet with the next hop address.  This is
 >    known as a "third party" next hop information.  A BGP speaker can
 >    advertise any external peer router in the next hop component,
 >    provided that the Network Layer address of this border router was
 >    learned from an external peer, and the external peer to which the
 >    route is being advertised shares a common subnet with the next hop
 >    address.  This is a second form of "third party" next hop
 >    information.
 > 
 >    Normally the next hop information is chosen such that the shortest
 >    available path will be taken.  A BGP speaker must be able to support
 >    disabling advertisement of third party next hop information to handle
 >    imperfectly bridged media.
 > 
 >    A BGP speaker must never advertise an address of a peer to that peer
 >    as a next hop, for a route that the speaker is originating.  A BGP
 >    speaker must never install a route with itself as the next hop.
 > 
 >    When a BGP speaker advertises the route to an internal peer, the
 >    advertising speaker should not modify the next hop information
 >    associated with the route.  When a BGP speaker receives the route via
 >    an internal link, it may forward packets to the next hop address if
 >    the address contained in the attribute is on a common subnet with the
 >    local and remote BGP speakers.
 > 
 > 
 > 5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):
 > 
 >    This is an optional non-transitive attribute that can be used for the
 >    purpose of withdrawing multiple unfeasible routes from service.
 > 
 >    The attribute is encoded as shown below:
 > 
 >       +-----------------------------+
 >       | Address Family (2 octets)   |
 >       +-----------------------------+
 >       | Withdrawn Routes (variable) |
 >       +-----------------------------+
 > 
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 5]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 >    The use and the meaning of these fields are as follows:
 > 
 >       Address Family
 > 
 >          This field carries the identity of the Network Layer protocol
 >          associated with the NLRI that follows. Presently defined values
 >          for this field are specified in RFC1700.
 > 
 >       Withdrawn Routes:
 > 
 >          This is a variable length field that contains a list of NLRIs
 >          for the routes that are being withdrawn from service. Each NLRI
 >          is encoded as specified in the "NLRI encoding" section of this
 >          document.
 > 
 > 
 > 
 > 6. NLRI encoding
 > 
 >    The Network Layer Reachability information is encoded as one or more
 >    2-tuples of the form <length, prefix>, whose fields are described
 >    below:
 > 
 > 
 >       +---------------------------+
 >       |   Length (1 octet)        |
 >       +---------------------------+
 >       |   Prefix (variable)       |
 >       +---------------------------+
 > 
 > 
 > 
 >    The use and the meaning of these fields are as follows:
 > 
 >       a) Length:
 > 
 >          The Length field indicates the length in bits of the address
 >          prefix. A length of zero indicates a prefix that matches all
 >          (as specified by the address family) addresses (with prefix,
 >          itself, of zero octets).
 > 
 >       b) Prefix:
 > 
 >          The Prefix field contains address prefixes followed by enough
 >          trailing bits to make the end of the field fall on an octet
 >          boundary.  Note that the value of trailing bits is irrelevant.
 > 
 > 
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 6]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 > 7. Security Considerations
 > 
 >    Security issues are not discussed in this document.
 > 
 > 
 > 8. Acknowledgements
 > 
 >    To be supplied.
 > 
 > 
 > 9. References
 > 
 > 
 >    [BGP-4]
 > 
 >    [IPv4]
 > 
 >    [IPv6]
 > 
 >    [RFC1700]
 > 
 > 
 > 10. Author Information
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > Bates, Chandra, Katz, Rekhter                                   [Page 7]
 > 
 > 
 > 
 > 
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 > 
 >    Tony Bates
 >    Cisco Systems, Inc.
 >    170 West Tasman Drive
 >    San Jose, CA 95134
 >    email: [email-masked]
 > 
 >    Ravi Chandra
 >    Cisco Systems, Inc.
 >    170 West Tasman Drive
 >    San Jose, CA 95134
 >    email: [email-masked]
 > 
 >    Dave Katz
 >    Cisco Systems, Inc.
 >    170 West Tasman Drive
 >    San Jose, CA 95134
 >    email: [email-masked]
 > 
 >    Yakov Rekhter
 >    Cisco Systems, Inc.
 >    170 West Tasman Drive
 >    San Jose, CA 95134
 >    email: [email-masked]
 > 
 > Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > 

 > 
 > 
 > 
 > 
 > 
 > 
 > 

 > Bates, Chandra, Katz, Rekhter                                   [Page 8]
 > 
 > 
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 1996 16:37:50 -0500
From: Susan Hares <[email-masked]>
Sender: [email-masked]

Yakov:

Wow!  What a nice Christmas present.

A few comments on the draft:

1) From the section below and the address family,
   IPv6 and IPv4 cannot point to a common next hop.
   Ipv6 routes can be passed over IP v4 fabric, but the
   next hop must be a "third" party hop.

	ipv6---ipv4----ipv6

    This can occur if all routers in above picture running bgp
     are on a common subnet.

    Is this a correct statement?  Did I mis-understand the text below?

>   One could further observe that the next hop information (the
>   information provided by the NEXT_HOP attribute) is meaningful (and
>   necessary) only in conjunction with the advertisements of reachable
>   destinations - in conjunction with the advertisements of unreachable
>   destinations (withdrawing routes from service) the next hop
>   information is meaningless. This suggests that the advertisement of
>   reachable destinations should be grouped with the advertisement of
>   the next hop to be used for these destinations, and that the
>   advertisement of reachable destinations should be segregated from the
>   advertisement of unreachable destinations.

> When advertising a MP_REACH_NLRI
>   attribute to an external peer, a router may use one of its own
>   interface addresses in the next hop component of the attribute,
>   provided the external peer to which the route is being advertised
>   shares a common subnet with the next hop address.  This is known as a
>   "first party" next hop. A BGP speaker can advertise to an external
>   peer an interface of any internal peer router in the next hop
>   component, provided the external peer to which the route is being
>   advertised shares a common subnet with the next hop address.  This is
>   known as a "third party" next hop information.  A BGP speaker can
>   advertise any external peer router in the next hop component,
>   provided that the Network Layer address of this border router was
>   learned from an external peer, and the external peer to which the
>   route is being advertised shares a common subnet with the next hop
>   address.  This is a second form of "third party" next hop
>   information.

2) Security Considerations

BGP-4++ is just as secure or un-secure as BGP-4.  If bgp over transport
is OK now, this is OK.   If you need additional security by
using an in-protocol transport - this needs to be added.  

Is it your understanding that users need this security or is
TCP good enough?

Sue Hares
- - - - - - - - - - - - - - - - -

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 1996 16:20:33 -0500
From: Susan Hares <[email-masked]>
Sender: [email-masked]

Yakov:

Thanks for the document.

I will send comments on your document to the bgp/idr list
only - unless I hear comments from the 6bone list that they'd like
to receive additional mail about this.

Sue Hares
- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: BGP-4+ 
Date: Wed, 18 Dec 96 12:11:14 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Sue,

> 
> Hi all:
> 
> 
> FYI - Neither Dimitry or Dave Katz have forwarded a specification
> for the BGP-4+.  Please encourage them to forward
> a description of the protocol to the idr working group.
> An open discussion of changes to bgp-4 is always welcome.
> Yakov and I both expressed interest in getting a specification
> before the working group.  We did not discuss it at the
> December meeting because there was not a specification.
> 
> [This ends my speaking as the co-chair of IDR working group.]

Attached is the proposal from Tony Bates, Ravi Chandra, Dave Katz
and myself for backward compatible multiprotocol extensions to
BGP-4.

Yakov.

P.S. I added [email-masked] to the cc: list.
--------------------------------------------------------------------

Network Working Group                                   Tony Bates
Internet Draft                                       Cisco Systems
Expiration Date: June  1997                           Ravi Chandra
                                                     Cisco Systems
                                                         Dave Katz
                                                     Cisco Systems
                                                     Yakov Rekhter
                                                     Cisco Systems

                   Multiprotocol Extensions for BGP-4

                 draft-bates-bgp4-multiprotocol-00.txt

1. Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

2. Abstract

   Currently BGP-4 [BGP-4] is capable of carrying routing information
   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
   enable it to carry routing information for multiple Network Layer
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
   compatible - a router that supports the extensions can interoperate
   with a router that doesn't support the extensions.

Bates, Chandra, Katz, Rekhter                                   [Page 1]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

3. Overview

   The only three pieces of information carried by BGP-4 that are IPv4
   specific are (a) the NEXT_HOP attribute (expressed as an IPv4
   address), (b) AGGREGATOR (contains an IPv4 address), and (c) NLRI
   (expressed as IPv4 address prefixes). This document assumes that any
   BGP speaker (including the one that supports multiprotocol
   capabilities defined in this document) will have to support IPv4 and
   have an IPv4 address.  Therefore, to enable BGP-4 to support routing
   for multiple Network Layer protocols the only two things that have to
   be added to BGP-4 are (a) the ability to associate a particular
   Network Layer protocol with the next hop information, and (b) the
   ability to associated a particular Network Layer protocol with NLRI.
   To identify individual Network Layer protocols this document uses
   Address Family, as defined in [RFC1700].

   One could further observe that the next hop information (the
   information provided by the NEXT_HOP attribute) is meaningful (and
   necessary) only in conjunction with the advertisements of reachable
   destinations - in conjunction with the advertisements of unreachable
   destinations (withdrawing routes from service) the next hop
   information is meaningless. This suggests that the advertisement of
   reachable destinations should be grouped with the advertisement of
   the next hop to be used for these destinations, and that the
   advertisement of reachable destinations should be segregated from the
   advertisement of unreachable destinations.

   To provide backward compatibility, as well as to simplify
   introduction of the multiprotocol capabilities into BGP-4 this
   document uses two new attributes, Multiprotocol Reachable NLRI
   (MP_REACH_NLRI), and Multiprotocol Unreachable NLRI
   (MP_UNREACH_NLRI). The first one (MP_REACH_NLRI) is used to carry the
   set of reachable destinations together with the next hop information
   to be used for forwarding to these destinations. The second one
   (MP_UNREACH_NLRI) is used to carry the set of unreachable
   destinations.  Both of these attributes are optional and non-
   transitive.  This way a BGP speaker that doesn't support the
   multiprotocol capabilities would just ignore the information carried
   in these attributes, and wouldn't pass it to other BGP speakers.

Bates, Chandra, Katz, Rekhter                                   [Page 2]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

4. Multiprotocol Reachable NLRI - MP_REACH_NLRI (Type Code 14):

   This is an optional non-transitive attribute that can be used for the
   following purposes:

      (a) to advertise a feasible route to a peer

      (b) to permit a router to advertise the Network Layer address of
      the router that should be used as the next hop to the destinations
      listed in the Network Layer Reachability Information field of the
      MP_NLRI attribute.

      (c) to allow a given router to report some or all of the
      Subnetwork Points of Attachment (SNPAs) that exist within the
      local system

   The attribute consists of two components, the next hop information
   and the list of reachable destinations.

   The attribute is encoded as shown below:

      +---------------------------------------------------+
      | Address Family (2 octets)                         |
      +---------------------------------------------------+
      | Length of Network Address (1 octet)               |
      +---------------------------------------------------+
      | Network Address of Next Hop (variable)            |
      +---------------------------------------------------+
      | Number of SNPAs (1 octet)                         |
      +---------------------------------------------------+
      | Length of first SNPA(1 octet)                     |
      +---------------------------------------------------+
      | First SNPA (variable)                             |
      +---------------------------------------------------+
      | Length of second SNPA (1 octet)                   |
      +---------------------------------------------------+
      | Second SNPA (variable)                            |
      +---------------------------------------------------+
      | ...                                               |
      +---------------------------------------------------+
      | Length of Last SNPA (1 octet)                     |
      +---------------------------------------------------+
      | Last SNPA (variable)                              |
      +---------------------------------------------------+
      | Network Layer Reachability Information (variable) |
      +---------------------------------------------------+

Bates, Chandra, Katz, Rekhter                                   [Page 3]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

   The use and meaning of these fields are as follows:

      Address Family

         This field carries the identity of the Network Layer protocol
         associated with the Network Address that follows. Presently
         defined values for this field are specified in RFC1700.

      Length of Network Address:

         A 1 octet field whose value expresses the length of the
         "Network Address of Next Hop" field as measured in octets

      Network Address of Next Hop:

         A variable length field that contains the Network Address of
         the next router on the path to the destination system

      Number of SNPAs:

         A 1 octet field which contains the number of distinct SNPAs to
         be listed in the following fields.  The value 0 may be used to
         indicate that no SNPAs are listed in this attribute.

      Length of Nth SNPA:

         A 1 octet field whose value expresses the length of the "Nth
         SNPA of Next Hop" field as measured in semi-octets

      Nth SNPA of Next Hop:

         A variable length field that contains an SNPA of the router
         whose Network Address is contained in the "Network Address of
         Next Hop" field.  The field length is an integral number of
         octets in length, namely the rounded-up integer value of one
         half the SNPA length expressed in semi-octets; if the SNPA
         contains an odd number of semi-octets, a value in this field
         will be padded with a trailing all-zero semi-octet.

      Network Layer Reachability Information:

         A variable length field that lists the destinations for the
         feasible routes that are being advertised in this attribute.
         Each NLRI is encoded as specified in the "NLRI encoding"
         section of this document.

   The next hop information carried in the MP_REACH_NLRI path attribute
   defines the Network Layer address of the border router that should be

Bates, Chandra, Katz, Rekhter                                   [Page 4]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

   used as the next hop to the destinations listed in the MP_NLRI
   attribute in the UPDATE message.  When advertising a MP_REACH_NLRI
   attribute to an external peer, a router may use one of its own
   interface addresses in the next hop component of the attribute,
   provided the external peer to which the route is being advertised
   shares a common subnet with the next hop address.  This is known as a
   "first party" next hop.  A BGP speaker can advertise to an external
   peer an interface of any internal peer router in the next hop
   component, provided the external peer to which the route is being
   advertised shares a common subnet with the next hop address.  This is
   known as a "third party" next hop information.  A BGP speaker can
   advertise any external peer router in the next hop component,
   provided that the Network Layer address of this border router was
   learned from an external peer, and the external peer to which the
   route is being advertised shares a common subnet with the next hop
   address.  This is a second form of "third party" next hop
   information.

   Normally the next hop information is chosen such that the shortest
   available path will be taken.  A BGP speaker must be able to support
   disabling advertisement of third party next hop information to handle
   imperfectly bridged media.

   A BGP speaker must never advertise an address of a peer to that peer
   as a next hop, for a route that the speaker is originating.  A BGP
   speaker must never install a route with itself as the next hop.

   When a BGP speaker advertises the route to an internal peer, the
   advertising speaker should not modify the next hop information
   associated with the route.  When a BGP speaker receives the route via
   an internal link, it may forward packets to the next hop address if
   the address contained in the attribute is on a common subnet with the
   local and remote BGP speakers.

5. Multiprotocol Unreachable NLRI - MP_UNREACH_NLRI (Type Code 15):

   This is an optional non-transitive attribute that can be used for the
   purpose of withdrawing multiple unfeasible routes from service.

   The attribute is encoded as shown below:

      +-----------------------------+
      | Address Family (2 octets)   |
      +-----------------------------+
      | Withdrawn Routes (variable) |
      +-----------------------------+

Bates, Chandra, Katz, Rekhter                                   [Page 5]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

   The use and the meaning of these fields are as follows:

      Address Family

         This field carries the identity of the Network Layer protocol
         associated with the NLRI that follows. Presently defined values
         for this field are specified in RFC1700.

      Withdrawn Routes:

         This is a variable length field that contains a list of NLRIs
         for the routes that are being withdrawn from service. Each NLRI
         is encoded as specified in the "NLRI encoding" section of this
         document.

6. NLRI encoding

   The Network Layer Reachability information is encoded as one or more
   2-tuples of the form <length, prefix>, whose fields are described
   below:

      +---------------------------+
      |   Length (1 octet)        |
      +---------------------------+
      |   Prefix (variable)       |
      +---------------------------+

   The use and the meaning of these fields are as follows:

      a) Length:

         The Length field indicates the length in bits of the address
         prefix. A length of zero indicates a prefix that matches all
         (as specified by the address family) addresses (with prefix,
         itself, of zero octets).

      b) Prefix:

         The Prefix field contains address prefixes followed by enough
         trailing bits to make the end of the field fall on an octet
         boundary.  Note that the value of trailing bits is irrelevant.

Bates, Chandra, Katz, Rekhter                                   [Page 6]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

7. Security Considerations

   Security issues are not discussed in this document.

8. Acknowledgements

   To be supplied.

9. References

   [BGP-4]

   [IPv4]

   [IPv6]

   [RFC1700]

10. Author Information

Bates, Chandra, Katz, Rekhter                                   [Page 7]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

   Tony Bates
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   email: [email-masked]

   Ravi Chandra
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   email: [email-masked]

   Dave Katz
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   email: [email-masked]

   Yakov Rekhter
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134
   email: [email-masked]

Internet Draft   draft-bates-bgp4-multiprotocol-00.txt     December 1996

Bates, Chandra, Katz, Rekhter                                   [Page 8]

- - - - - - - - - - - - - - - - -

From: [email-masked]
Date: Wed, 18 Dec 1996 07:10:17 -0500 (EST)
To: [email-masked]
Reply-To: [email-masked]
Subject: Is Your Web Site A Secret?
Sender: [email-masked]

     Is your web site the best kept secret on the Internet?

     We'll promote it to 50 search engines and indexes for $85
     and complete the job in 2 business days.  Satisfaction is
     guaranteed!

If you have a great product, but are not getting many inquiries from
your Web site, you may not be adequately listed on the Web's search
engines and indexes.

Millions of viewers daily use these facilities to find the products
and services they are looking for.  But if your site is not listed, no
one will see it.

Listings on most of these services are free.  However, locating and
filling out the forms required to get a listing can take several days,
and most people just don't have the time to do it.

That is why we offer a web site promotion service.

WHAT'S THE DEAL?

We will submit your site to 50 indexes and search engines for $85.  We
will accept the return of this E-mail, with the form below filled out,
as an order.  We will bill you upon completion of the promotion.  Our
terms are net 15 days from date of invoice.  Satisfaction guaranteed!

HOW LONG WILL IT TAKE?

Generally, we complete the submissions within 48 hours of
receiving your order.  It can take any individual search engine or
index up to three weeks to process your submission, although most are
much faster.

WHAT SEARCH ENGINES AND INDEXES ARE INCLUDED IN THE
PROMOTION?

The list changes from time to time.  This is our current list:

Abaweb!, All Business Network, Alta Vista, Big Yellow, BizWeb, BizWiz,
Brian's Revised Internet Yellow Pages, Central Source Yellow Pages,
E!Net Galaxy, Enterpreneurs on the Web, Excite, Homecom's Global
Village, I-Network, I-Systems Spiral Business Directory, Infoseek,
Inktomi, Innovator's Network Yellow Pages, Internet Addressbook Yellow
Pages, Internet Mall, ISP Internet Yellow Pages, Jumpcity, Jumper Hot
Links, Linkmaster, Lycos, Magellan-McKinley Yellow Pages, NCSA What's
New, Net-Happenings, NetMall, New Virtual Yellow Pages, NTG's List,
OnLine's WWWeb Index, Open Market's Commercial Sites Index, Open Text
Web Index, Rex, Spider's Pick of the Day, Starting Point, The Source,
URL Tree, Web Central, Web Venture Hotlist, Webcrawler, Websurf, World
Wide Yellow Pages, Worldwide Announce Archive, WWW Business Yellow
Pages, WWW Worm, YelloWWWeb.

HOW WILL I KNOW THAT YOU HAVE PROMOTED MY SITE?

When we have completed the promotion, we will send you an HTML
file as an attachment to your E-mail bill.  Save this file to your
disk, and view it through your Web browser.  It provides links to the
search engine we submitted your site to, plus any comments we received
from them when we did it.

ARE THERE ANY GUARANTEES?

We do not require prepayment.  Your satisfaction is guaranteed or
you don't pay the bill.

WHO IS OWL'S EYE PRODUCTIONS?

We are a web site promotion company located at:

   Owl's Eye Productions, Inc.
   260 E. Main Street
   Brewster, NY 10509
   Phone: (914) 278-4933
   Fax:     (914) 278-4507
   Email: [email-masked]

HOW DO I ORDER?

The easiest way to order is by e-mail.  Just hit the REPLY button on
your e-mail program and fill out the following information. (This
information will be posted to the search engines/indexes):

Your name: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 
URL:  http://
Site Title: 
Description (about 25 words): 
Key words (maximum of 25, in descending order of importance):

If  billing a different address, please complete the following:

Addressee: 
Company Name:
Address:
City:              State/Prov:     Zip/Postal Code: 
Telephone: 
Fax: 
Email address: 

We will bill via Email. (6D14)

Terms:  By returning this document via Email, you agree as follows:
You have the authority to purchase this service on behalf of your
company.    Terms are net 15 days.  Accounts sent to collections will
be liable for collection costs.  You agree to protect and indemnify
Owl's Eye Productions, Inc. in any claim for libel, copyright
violations, plagiarism, or privacy and other suits or claims based on
the content or subject matter of  your site.

WHAT HAPPENS NEXT?

When we receive your order, we will input the information into
our system, and send you a proof.

After we process any corrections, we will run your promotion, capturing
any comments from search engines as we go.  We will incorporate these
into an HTML-formatted report to you, which we will attach to
your bill.
===Web Promotions=====Press Releases=====Link Exchanges=========
                 Owl's Eye Productions, Inc.
                   260 E. Main Street
                   Brewster, NY 10509
Ph: 914-278-4933  Fx: 914-278-4507  E-mail: [email-masked]
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Tue, 3 Dec 1996 15:29:31 -0500 (EST)
To: [email-masked]
From: [email-masked]
Subject: Welcome to idr
Reply-To: [email-masked]
Sender: [email-masked]

--

Welcome to the idr mailing list!

If you ever want to remove yourself from this mailing list,
you can send mail to "Majordomo" with the following command
in the body of your email message:

    unsubscribe idr [email-masked]

Here's the general information for the list you've
subscribed to, in case you don't already have it:

Project NetScarf
- - - - - - - - - - - - - - - - -

Date: Sun, 01 Dec 1996 16:44:40 -0500
To: Yakov Rekhter <[email-masked]>
From: Paul Ferguson <[email-masked]>
Subject: Re: agenda for the upcoming WG meeting
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Is draft-ferguson-ingress-filtering-01.txt appropriate for the idr wg?

- paul (trolling for a sponsor)

At 11:50 AM 12/1/96 PST, Yakov Rekhter wrote:

>Folks,
>
>So far I have only two items on the agenda for the WG meeting:
>
>1. Revised BGP-4 Internet Draft
>2. BGP-4 MIB status
>
>If there are other items, please send me an e-mail.
>
>Yakov.
>

- - - - - - - - - - - - - - - - -

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: agenda for the upcoming WG meeting
Date: Sun, 01 Dec 96 11:50:31 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

So far I have only two items on the agenda for the WG meeting:

1. Revised BGP-4 Internet Draft
2. BGP-4 MIB status

If there are other items, please send me an e-mail.

Yakov.
- - - - - - - - - - - - - - - - -