Subject: Re: IDR WG agenda
From: Vince Fuller <[email-masked]>
To: [email-masked]
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Date: Thu, 27 Feb 97 11:22:05 PST

Isn't that MED with a BGP community to send MED no further?

Is this "BGP community" in the sense of the IRR or in the sense of the
community attribute? An IRR community isn't very useful to most of us and
while a well-known community attribute number could be defined to mean this,
none exists at present (though that might be a reasonable solution).

There was also some feeling among the large provider community that overloading
MED in this way could cause other problems, so a separate attribute may be
preferred.

Other comments from anyone familiar with the problem to be solved here?

	--Vince
- - - - - - - - - - - - - - - - -

To: Vince Fuller <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: IDR WG agenda 
Date: Thu, 27 Feb 1997 16:18:41 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Vince Fuller writes:
>     Isn't that MED with a BGP community to send MED no further?
> 
> Is this "BGP community" in the sense of the IRR or in the sense of the
> community attribute? An IRR community isn't very useful to most of us and
> while a well-known community attribute number could be defined to mean this,
> none exists at present (though that might be a reasonable solution).

I meant a yet to be defined BGP community.  Making it a well known
community would help.

> There was also some feeling among the large provider community that overloadi
> ng
> MED in this way could cause other problems, so a separate attribute may be
> preferred.

Getting the right next hop is a common use for MED.  I think what you
are asking for is something like this that is guarenteed not to be
propogated further.

> Other comments from anyone familiar with the problem to be solved here?
> 
> 	--Vince

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

Posted-Date: Thu, 27 Feb 1997 13:25:35 -0800 (PST)
Date: Thu, 27 Feb 1997 16:23:37 -0500
From: Paul Knight <[email-masked]>
Organization: Bay Networks
To: [email-masked]
Subject: Re: IDR WG agenda
Sender: [email-masked]

I believe Curtis is right about this.  

There is clearly a well-known community (NO_ADVERTISE) which looks like
it should accomplish this (allowing setting a local-pref known only at a
specific router).

from draft-ietf-idr-communities-00.txt:

Well-known Communities

   The following communities have global significance and their
   operations shall be implemented in any community-attribute-aware BGP
   speaker.
      NO_EXPORT (0xFFFFFF01)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised outside a BGP confederation
         boundary (a stand-alone autonomous system that is not part of a
         confederation should be considered a confederation itself).
      NO_ADVERTISE (0xFFFFFF02)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to other BGP peers.
      NO_EXPORT_SUBCONFED (0xFFFFFF03)
         All routes received carrying a communities attribute containing
         this value MUST NOT be advertised to external BGP peers (this
         includes peers in other members autonomous systems inside a BGP
         confederation).

Vince Fuller wrote:
>     Curtis V:
>     Isn't that MED with a BGP community to send MED no further?
> 
> Is this "BGP community" in the sense of the IRR or in the sense of the
> community attribute? An IRR community isn't very useful to most of us and
> while a well-known community attribute number could be defined to mean this,
> none exists at present (though that might be a reasonable solution).
> 
> There was also some feeling among the large provider community that overloading
> MED in this way could cause other problems, so a separate attribute may be
> preferred.
> 
> Other comments from anyone familiar with the problem to be solved here?
> 
>         --Vince

-- 
Paul Knight 			     mailto:[email-masked]
IP Engineering, Systems Test	     Office: (508) 916-7087
Bay Networks, Inc.	M/S BL2-02	Lab: (508) 670-8888, x-65404
2 Federal St., Billerica, MA 01821	Fax: (508) 670-4004
- - - - - - - - - - - - - - - - -

From: John Scudder <[email-masked]>
Subject: Re: IDR WG agenda
To: [email-masked] (Paul Knight)
Date: Thu, 27 Feb 1997 17:23:09 -0500 (EST)
Cc: [email-masked]
Sender: [email-masked]

> I believe Curtis is right about this.  

Per private e-mail in which Curtis explained himself I (sort of) agree 
with this part.

> There is clearly a well-known community (NO_ADVERTISE) which looks like
> it should accomplish this (allowing setting a local-pref known only at a
> specific router).

(I believe that MED was being discussed, not localpref, but anyway.)  The
NO_ADVERTISE attribute prevents *the entire route* from being propagated, 
not just the given attribute.  I don't think that was the desired effect.

--John
- - - - - - - - - - - - - - - - -

Date: Thu, 27 Feb 97 16:03:38 PST
From: Vince Fuller <[email-masked]>
To: [email-masked]
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Phone: (415) 528-7227
Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: IDR WG agenda
Sender: [email-masked]

    In message <[email-masked]>, Vince Fuller writes:
    >     Isn't that MED with a BGP community to send MED no further?
    > 
    > Is this "BGP community" in the sense of the IRR or in the sense of the
    > community attribute? An IRR community isn't very useful to most of us and
    > while a well-known community attribute number could be defined to mean
    > this, none exists at present (though that might be a reasonable
    > solution).

    I meant a yet to be defined BGP community.  Making it a well known
    community would help.

This would work, but there are still some situations where a new attribute
would be preferred. The specific case that occurs to me is that of a provider
who has multiple routers which are colocated with an exchange point. Right
now, those routers could believe MED and the overwrite it on iBGP output but
they still have to trust that the received MEDs aren't unreasonably high so
as to cause them to prefer an iBGP route and break shortest-exit. There is
an easy workaround if the routers at the IXP are dedicated -- always prefer
external information over external information -- and a less obvious and less
reliable general workaround -- overwrite the MED with a value larger than
anything that a peer will ever send (but how to determine that value). But
from an archtectural standpoint, having a separate "local-metric" attribute,
used as a tie-breaker if equal MEDs are encountered and only sent or received
on eBGP sessions, would be cleaner. 

    Getting the right next hop is a common use for MED.  I think what you
    are asking for is something like this that is guarenteed not to be
    propogated further.

Yes. Again, overloading MED for this purpose is doable but rather ugly.

	--Vince
- - - - - - - - - - - - - - - - -

To: Paul Knight <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: IDR WG agenda 
Date: Fri, 28 Feb 1997 10:25:56 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Paul Knight writes:
> I believe Curtis is right about this.  
> 
> There is clearly a well-known community (NO_ADVERTISE) which looks like
> it should accomplish this (allowing setting a local-pref known only at a
> specific router).
> 
> from draft-ietf-idr-communities-00.txt:
> 
> Well-known Communities
> 
>    The following communities have global significance and their
>    operations shall be implemented in any community-attribute-aware BGP
>    speaker.
>       NO_EXPORT (0xFFFFFF01)
>          All routes received carrying a communities attribute containing
>          this value MUST NOT be advertised outside a BGP confederation
>          boundary (a stand-alone autonomous system that is not part of a
>          confederation should be considered a confederation itself).
>       NO_ADVERTISE (0xFFFFFF02)
>          All routes received carrying a communities attribute containing
>          this value MUST NOT be advertised to other BGP peers.
>       NO_EXPORT_SUBCONFED (0xFFFFFF03)
>          All routes received carrying a communities attribute containing
>          this value MUST NOT be advertised to external BGP peers (this
>          includes peers in other members autonomous systems inside a BGP
>          confederation).

That's not quite it.  NO_ADVERTISE works if you are sending a more
specific route that you want propogated no further than the immediate
router.

There are some cases.  Most are covered.

  1.  You want to provide a MED solely for the purpose of choosing one
      of two routers.  You want the prefixe advertised into the
      entire world after the choice is made.  This (I think) is
      Vince's case and it is not covered.  Nothing a new community
      wouldn't fix.

  2.  You want to provide a MED for the purpose of selecting an exit
      point among many interconnect points.  This is covered.  Just
      send MED (the other end may refuse it, opting for shortest out).

  3.  You would like to send one metric to pick an interconnect and
      another to select the next hop at the preferred interconnect.
      This could be done with MED.  Multiple all link metrics by N
      (reconfigure your IGP, if you don't have some sort of MED
      algebra on your router, none do).  Then add a small offset (less
      than N) to choose among as many as N routers.

  4.  You either have 1 router, or more than 1 routers and 0 clues, or
      your routers are broken or have no practical way to configure
      MED and/or communities, or you are paranoid that someone else's
      router is broken or you don't care where traffic goes.  Don't
      send MED and/or communities.

  5.  You want to send more specifics to refine the next hop at the
      immediate router.  Set MED and NO_ADVERTISE on the more specifics.

  6.  You want to send send more specifics to refine the exit point
      among multiple interconnects.  Set MED and NO_EXPORT on the more
      specifics.

  7.  You have intimate knowledge of your peer's topology and want to
      send more specifics to choose among multiple interconnects that
      you know are within the same BGP confederation in your peer's
      topology.  Set MED and NO_EXPORT_SUBCONFED (consenting adults
      only).

  8.  You just heard about BGP and don't really understand much of this
      aggregation, loca-pref, MED, community, confederation, stuff.  You
      want to advertise everything you know to your peer and hope they
      can figure out the right thing to do with it and you can't be
      bothered registering any information about your AS or prefixes.
      Leave the planet.  :)

Did I miss any cases?  (Actually I might have one or two extras).

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

To: Vince Fuller <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: IDR WG agenda 
Date: Fri, 28 Feb 1997 14:26:33 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Vince Fuller writes:
> 
>     I meant a yet to be defined BGP community.  Making it a well known
>     community would help.
> 
> This would work, but there are still some situations where a new attribute
> would be preferred. The specific case that occurs to me is that of a provider
> who has multiple routers which are colocated with an exchange point. Right
> now, those routers could believe MED and the overwrite it on iBGP output but
> they still have to trust that the received MEDs aren't unreasonably high so
> as to cause them to prefer an iBGP route and break shortest-exit. There is
> an easy workaround if the routers at the IXP are dedicated -- always prefer
> external information over external information -- and a less obvious and less
> reliable general workaround -- overwrite the MED with a value larger than
> anything that a peer will ever send (but how to determine that value). But
> from an archtectural standpoint, having a separate "local-metric" attribute,
> used as a tie-breaker if equal MEDs are encountered and only sent or received
> on eBGP sessions, would be cleaner. 

Vince,

First of all, within an IGP, all peering to a given AS should be
configured consistently wrt incoming MED and IBGP.  If at one peering
MED is accepted and injected into IBGP, this should happen at all
peerings.  Either than or drop MED before injecting into IBGP.

In the router, MED can be considered to choose the best next hop from
any peering with an external AS and then get dropped before injecting
into IBGP and before comparing against any IBGP route.  The second
condition, drop MED from consideration before comparing against any
IBGP route is there so the border router makes the same decision as
the router one hop in from the border (so you don't get a routing
loop).  If that isn't being done, you have to ask your vendor to fix
their implementation.  No fix to BGP is needed.

I think the rewording of BGP4 is unclear about this.  An
implementation MAY compare MEDs from all EBGP peers even if the MED
will be dropped before passing into IBGP.  Perhaps that should even be
a SHOULD rather than a MAY.  If the EBGP learned MED is not being
passed into IBGP, the EBGP learned MED MUST NOT be used in the
comparison with an IBGP learned route.  To do so may cause a routing
loop.

Curtis

5.1.4   MULTI_EXIT_DISC

   The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
   links to discriminate among multiple exit or entry points to the same
   neighboring AS.  The value of the MULTI_EXIT_DISC attribute is a four
   octet unsigned number which is called a metric.  All other factors
   being equal, the exit or entry point with lower metric should be
   preferred.  If received over external links, the MULTI_EXIT_DISC
   attribute MAY be propagated over internal links to other BGP speakers
   within the same AS.  The MULTI_EXIT_DISC attribute received from a
   neighboring AS MUST NOT be propagated to other neighboring ASs.

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
   which allows the MULTI_EXIT_DISC attribute to be removed from a
   route.  This MAY be done either prior to or after determining the
   degree of preference of the route and performing route selection
   (decision process phases 1 and 2).

   An implementation MAY also (based on local configuration) alter the
   value of the MULTI_EXIT_DISC attribute received over an external
   link.  If it does so, it shall do so prior to determining the degree
   of preference of the route and performing route selection (decision
   process phases 1 and 2).

	This last two paragraphs may need to be changed to indicate a case
	where an implementation may become prone to routing loops if
	the wrong behavior is chosen.  In other words, lets constrain
	this according to the conditions above to only allow
	implementations that will remain loop free, but allow EBGP MED
	to be compared to satisfy Vince's requirement (which is what
	gated does and what we've been asking vendors to do anyway).
	Change to:

   A BGP speaker MUST IMPLEMENT a mechanism based on local
   configuration which allows the MULTI_EXIT_DISC attribute to be
   removed from a route.  An implementation MAY also (based on local
   configuration) alter the value of the MULTI_EXIT_DISC attribute
   received over an external link.

   When performing route comparisons, an altered or removed value of
   MULTI_EXIT_DISC, as specified by local configuration, MAY be used
   in external (inter-AS) routes that were learned directly (from
   external BGP peers).  When comparing a directly learned external
   route (external BGP) to a route learned from an internal BGP peer,
   the same MULTI_EXIT_DISC for the external route that will be passed
   to internal BGP peers must be used in the comparison.  All route
   comparisons will be made according to the procedures in the degree
   of preference of the route and route selection (decision
   process phases 1 and 2) described in section 9.1.

	What this does is make MED more like LOCAL-PREF in that the
	MED used in Adj-RIB-In selection need not be as constrained as
	the MED used in phase 2 of route selection.  In "9.1.1 Phase
	1: Calculation of Degree of Preference" we have:

   For each newly received or replacement feasible route, the local BGP
   speaker shall determine a degree of preference.  If the route is
   learned from an internal peer, the value of the LOCAL_PREF attribute
   shall be taken as the degree of preference.  If the route is learned
   from an external peer, then the degree of preference shall be
   computed based on preconfigured policy information and used as the
   LOCAL_PREF value in any IBGP readvertisement.  The exact nature of
   this policy information and the computation involved is a local
   matter.  The local speaker shall then run the internal update process
   of 9.2.1 to select and advertise the most preferable route.

	We could clarify by changing to:

   For each newly received or replacement feasible route, the local
   BGP speaker shall determine a degree of preference.  If the route
   is learned from an internal peer, the value of the LOCAL_PREF
   attribute shall be taken as the degree of preference and the
   MULTI_EXIT_DISC attribute shall be used in phase 2 of the selection
   process.

   If the route is learned from an external peer, then the degree of
   preference shall be computed based on preconfigured policy
   information and used as the LOCAL_PREF value in any IBGP
   readvertisement.  The exact nature of this policy information and
   the computation involved is a local matter.  If the route is
   learned from an external peer, the MULTI_EXIT_DISC may be altered
   or removed.  The MULTI_EXIT_DISC before or after alteration or
   removal may be used in Adj-RIB-In degree of preference comparisons.
   The MULTI_EXIT_DISC value used in phase 2 comparisons MUST be the
   same MULTI_EXIT_DISC value (or lack of) advertised to internal BGP
   neighbors if the route were to be selected.

   The local speaker shall then run the internal update process of
   9.2.1 as described above to select and advertise the most
   preferable route.

   Failure to ue the same LOCAL_PREF and MULTI_EXIT_DISC values in
   phase 2 comparisons as is advertised to internal BGP neighbors can
   result in routing loops and is therefore prohibited.

	Of course, I have the bad habit of using shorthand terms
	like EBGP peer.  In keeping with ISO practices of making
	sure standards bear as little resemblence as possible to
	terms used in the field, please replace any such oversights
	with the appropriately obscure and wordy BGP4 RFC-speak.  :(
	For example, can I say internal peer?
- - - - - - - - - - - - - - - - -

To: Vince Fuller <[email-masked]>
Cc: [email-masked]
Subject: Re: IDR WG agenda 
Date: Tue, 25 Feb 97 07:41:49 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Vince,

>     As we are approaching our next meeting, we need to settle
>     on the possible agenda items. Please send me the items you'd
>     like to discuss at the WG meeting asap (within a week).
> 
> Yakov-
> 
> An issue recently surface in discussion among some of the larger providers
> about the use of local-pref and how it would be Real Nice if were something
> very similar to local-pref but which is not propagated through IBGP, i.e.
> it is only used to affect the next-hop decision for the router which receives
> it. Through a variety of crude approaches, local-pref can sort of be shoehorned
> into doing this but it isn't really the right tool. A few minutes on the agenda
> to discuss this particular issue would be nice (and no, I don't have an
> internet draft nor do I think I'm ready to give a presentation about this,
> but perhaps we can figure something out...)

Ok. I'll add this to the agenda.

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

To: Vince Fuller <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: IDR WG agenda 
Date: Mon, 24 Feb 1997 22:09:44 -0500
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Vince Fuller writes:
>     As we are approaching our next meeting, we need to settle
>     on the possible agenda items. Please send me the items you'd
>     like to discuss at the WG meeting asap (within a week).
> 
> Yakov-
> 
> An issue recently surface in discussion among some of the larger providers
> about the use of local-pref and how it would be Real Nice if were something
> very similar to local-pref but which is not propagated through IBGP, i.e.
> it is only used to affect the next-hop decision for the router which receives
> it. Through a variety of crude approaches, local-pref can sort of be shoehorn
> ed
> into doing this but it isn't really the right tool. A few minutes on the agen
> da
> to discuss this particular issue would be nice (and no, I don't have an
> internet draft nor do I think I'm ready to give a presentation about this,
> but perhaps we can figure something out...)
> 
> 	--Vince

Isn't that MED with a BGP community to send MED no further?

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

Date: Mon, 24 Feb 97 16:50:55 PST
From: Vince Fuller <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Phone: (415) 528-7227
Usmail: 3801 East Bayshore Rd, Palo Alto, CA, 94303
Subject: Re: IDR WG agenda
Sender: [email-masked]

    As we are approaching our next meeting, we need to settle
    on the possible agenda items. Please send me the items you'd
    like to discuss at the WG meeting asap (within a week).

Yakov-

An issue recently surface in discussion among some of the larger providers
about the use of local-pref and how it would be Real Nice if were something
very similar to local-pref but which is not propagated through IBGP, i.e.
it is only used to affect the next-hop decision for the router which receives
it. Through a variety of crude approaches, local-pref can sort of be shoehorned
into doing this but it isn't really the right tool. A few minutes on the agenda
to discuss this particular issue would be nice (and no, I don't have an
internet draft nor do I think I'm ready to give a presentation about this,
but perhaps we can figure something out...)

	--Vince
- - - - - - - - - - - - - - - - -

To: [email-masked]
Subject: IDR WG agenda
Date: Thu, 20 Feb 97 08:54:22 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

As we are approaching our next meeting, we need to settle
on the possible agenda items. Please send me the items you'd
like to discuss at the WG meeting asap (within a week).

Thanks.

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

To: [email-masked]
Reply-To: [email-masked]
Subject: RFC 1745 - OSPF<->BGP/IDRP Interaction
Date: Fri, 07 Feb 97 10:59:51 -0500
From: "Acee Lindem" <[email-masked]>
Sender: [email-masked]

Has found good application for manually configured tags as 
described in section 4.2 of RCC 1745? 

Thanks, 
Acee 
- - - - - - - - - - - - - - - - -

From: Andrew Partan <[email-masked]>
Subject: Re: bgp4++ vs bgp5
To: [email-masked] (Yakov Rekhter)
Date: Tue, 4 Feb 1997 20:40:52 -0500 (EST)
Cc: [email-masked]
Sender: [email-masked]

> 3. What other features, besides multiprotocol and expanded AS
>    space, should go into BGP-5

I'd like something that somehow softens the AS boundary.  Right
now we have IGPs and EGPs and there is a fairly hard edge between
the two.

I'd like something that is not a trusting as an IGP and not as
globally visible as an EGP that I can use with customers - esp
customers that have multiple links to my ISP (vs customers that
have multiple links to multiple ISPs).  [I'd like something to work
for both - while it need not be the same thing in both cases, it
would be useful it is was the same.]

Cisco's bgp confederations are close, but too much on the trusting
side.

I have no real concrete suggestions of how to do this; I just have
some (more or less vague) ideas of what features I'd like.

Is there any interest of working on something like this?  Either
in this group or another?

The two boundaries that we have now - the soft not-there boundary
of an IGP and the hard, globally visible boundary of an EGP - is
just not going to scale.  We need something that has the ability
to have more boundaries, more levels of abstraction.

If you want to talk about survival of the fittest of routing
protocols, something that just adds larger AS numbers and the
ability to support longer addresses just isn't going to cut it.

We need something that can deal with multiple abstraction hierarchies.

[[Btw, I don't think that its going to be all that hard to deploy
a new EGP - I was in on the switch from EGP to BGP and BGP3 to 4.
Both went fairly quickly (once the bugs were worked out).]]
	[email-masked] (Andrew Partan)
- - - - - - - - - - - - - - - - -

Posted-Date: Tue, 4 Feb 1997 11:28:30 -0800 (PST)
Date: Tue, 4 Feb 1997 14:28:31 -0500
From: [email-masked] (Dimitry Haskin)
To: [email-masked]
Subject: Re: bgp4++ vs bgp5
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Yakov,

> To avoid confusion let me suggest that the discussion should
> focus on the following issues:
> 
> 1. Why is it necessary to couple expanding AS space with adding
>    multiprotocol capabilities to BGP ?
>
We can continue to talk past each other..  I think this has been
discussed in details already.  But if you which, the bottom line
is that by adopting a larger ASN space for v6 from start there
is no risk that v6 will need to undergo a painful transition
to a larger ASN space in future. It just has a good risk management
and planning sense.  Before we went with our proposal, we solicited
input from the IPNG and IDR working groups if a larger than 2 byte
ASN space was deemed necessary for v6.  There was a clear consensus that
it would be prudent to addopt a larger ASN space for v6 when 
the inter-domain routing is introduced to v6.  There is just no
reason whatsoever to drag 2 byte ASN into v6.

> 2. Comparison between the approach to BGP-5 suggested by Ravi and
>    the one described in draft-stewart-bgp-multiprotocol-00.txt (or
>    any other alternatives)
>
Below is my response to the Ravi mail.

> 3. What other features, besides multiprotocol and expanded AS
>    space, should go into BGP-5
>

The main goal for BGP-5 is to provide inter-domain routing
for v6 in a way that utilizes the current BGP-4 implementation
base and therefore allows quick BGP-5 deployment within v6
internet.  Another goal is to have BGP-5 backword compatible
with BGP-4 so, where possible, a single bgp session can be used
between a pair of bgp peers for both v4 and v6 routing.  IMO,
anything that jeopardizes these goals should be kept out of
BGP-5.
 
> Yakov.

Dimitry

----- Begin Included Message -----

To: "John W. Stewart III" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: bgp4++ vs bgp5 
Date: Tue, 04 Feb 97 09:59:03 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,
 
> there are currently two proposals on the table for doing inter-domain
> routing for ipv6 (and other layer 3 protocols):
> draft-bates-bgp4-multiprotocol-00.txt and
> draft-stewart-bgp-multiprotocol-00.txt.  the former uses a new attribute
> in bgp4 to carry multi-protocol NLRI, while the latter is a new version
> of the protocol and carries the multi-protocol NLRI in the UPDATE
> message's NLRI field.  the major difference between them is the length
> of the autonomous system number:  the former supports two-byte ASs only,
> while the latter supports two-byte ASs for ipv4 (for compatibility) and
> four-byte ASs for all protocols.  

There is actually a third proposal - the one that Ravi sent to the IDR
mailing list (see attached). Ravi outlined an approach to BGP5 that 
expands AS space and supports multiprotocol (not just IPv4 and IPv6). 
The modifications proposed by Ravi to accommodate larger AS space and 
multiprotocol are different from the ones proposed in 
draft-stewart-bgp-multiprotocol-00.txt.

> our contention is that the addition of
> ipv6 support to bgp4 extends its life enough such that keeping the two-
> byte ASN space is unwise; it only introduces a risk of the ipv6
> transition to a larger ASN space in future with no clear short-term
> benefits
>
> this message is a call for discussion on this issue so that we can come
> to consensus
> 

To avoid confusion let me suggest that the discussion should
focus on the following issues:

1. Why is it necessary to couple expanding AS space with adding
   multiprotocol capabilities to BGP ?

2. Comparison between the approach to BGP-5 suggested by Ravi and
   the one described in draft-stewart-bgp-multiprotocol-00.txt (or
   any other alternatives)

3. What other features, besides multiprotocol and expanded AS
   space, should go into BGP-5

Yakov.
-------------------------------------------------------------------------
 -- using template mhl.format --
Date:    Tue, 07 Jan 97 13:57:25 PST
To:      [email-masked]

From:    Ravi Chandra <[email-masked]>
Subject: BGP-5 proposal..

Return-Path: [email-masked]
Sender:  [email-masked]
Precedence: bulk

well, if we want to both (a) introduce multiprotocol capabilities in
BGP, and (b) expand AS space, then how doing the following..

1. Replace how NLRI, next hop, and withdrawn routes are presently
   carried with MP_NLRI_REACH and MP_NLRI_UNREACH attributes.

2. Resize "My Automous System" in OPEN to 4 octets.
   Resize "BGP Identifier" in OPEN to 16 octets.

3. Resize AS space in AS_PATH and AGGREGATOR to 4 octets.
   Make the address component of the aggregator variable, and include
   (as part of this information) address family.

Note that with this proposal adding multiprotocol capabilities doesn't
require different types of UPDATE messages. In fact, a single UPDATE
message could carry NLRI associated with multiple protocols.

The multiprotocol extensions defined this way are not confined to IPv4
and IPv6. 

Also note that replacing encoding of NLRI and withdrawn routes with two
attributes (MP_REACH_NLRI, MP_UNREACH_NLRI) makes the overall protocol 
design more consistent.

--ravi

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

To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: bgp4++ vs bgp5
From: "John W. Stewart III" <[email-masked]>
Date: Tue, 04 Feb 1997 12:33:05 EST
Sender: [email-masked]

there are currently two proposals on the table for doing inter-domain
routing for ipv6 (and other layer 3 protocols):
draft-bates-bgp4-multiprotocol-00.txt and
draft-stewart-bgp-multiprotocol-00.txt.  the former uses a new attribute
in bgp4 to carry multi-protocol NLRI, while the latter is a new version
of the protocol and carries the multi-protocol NLRI in the UPDATE
message's NLRI field.  the major difference between them is the length
of the autonomous system number:  the former supports two-byte ASs only,
while the latter supports two-byte ASs for ipv4 (for compatibility) and
four-byte ASs for all protocols.  our contention is that the addition of
ipv6 support to bgp4 extends its life enough such that keeping the two-
byte ASN space is unwise; it only introduces a risk of the ipv6
transition to a larger ASN space in future with no clear short-term
benefits

this message is a call for discussion on this issue so that we can come
to consensus

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

Date: Tue, 4 Feb 1997 00:35:30 -0600 (CST)
From: Brandon Black <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

On Mon, 3 Feb 1997 [email-masked] wrote:

> Brandon,
> In fact, you bring up some good points wrt problems with the current
> situation-hackers have potential to do damage via all the NAPs/
> Providers/Routers.
> So in some cases one could limit the Number of unnecessary NAPs/
> Providers/Routers that are given a route.
> 
> Even with encryption in fact,via all these
> points you are also subject to attacks such as:
> TCP SYN attacks,ping flooding, spamming,people trying to gain
> unauthorized access to your site for various purposes, etc.
> Why not limit the number of hackers to whom you advertise a
> route to you in the first place ?
>

Most likely, your network number will be available from InterNIC or one of
the Routing Registries... it could still be remote sniffed via false BGp
advertisements probably... I'm not sure though..
 
> It may also have the additional advantage that it may limit filling
> up the Global Routing table of those Routers that "need to know"
> and also anyone that doesnt need access to a particular
> destination wont see any flapping. -this may be of some use wrt
> two big problems in the Internet.
> 

Anything that would cut down flapping would be a tremendous help.

> An example, off the cuff:perhaps a company is providing a bank
> balance web server or the ablility to do stock transactions -
> it may only want to give a route to its content/server
> to specifically those who have an account and paid
> a fee that day.In fact this could be done dynamically as
> users pay their access fee.
> 

Well... I don't see this as a valid example... a bank could only advertise
its route to certain entire corporations who were doing online
transactions with them.... but you certainly aren't going to alter your
BGP advertisements based on individual users, who may have dynamic IP
addresses... the finest concievable granularity for the advertisement
would be the single AS of the user's provider.. which allows access to all
other users of that provider (in this case, by provider I mean small local
provider, not backbone provider).

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

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

From: [email-masked]
Date: Mon, 3 Feb 97 23:13:01 EST
To: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

Brandon,
In fact, you bring up some good points wrt problems with the current
situation-hackers have potential to do damage via all the NAPs/
Providers/Routers.
So in some cases one could limit the Number of unnecessary NAPs/
Providers/Routers that are given a route.

Even with encryption in fact,via all these
points you are also subject to attacks such as:
TCP SYN attacks,ping flooding, spamming,people trying to gain
unauthorized access to your site for various purposes, etc.
Why not limit the number of hackers to whom you advertise a
route to you in the first place ?

It may also have the additional advantage that it may limit filling
up the Global Routing table of those Routers that "need to know"
and also anyone that doesnt need access to a particular
destination wont see any flapping. -this may be of some use wrt
two big problems in the Internet.

An example, off the cuff:perhaps a company is providing a bank
balance web server or the ablility to do stock transactions -
it may only want to give a route to its content/server
to specifically those who have an account and paid
a fee that day.In fact this could be done dynamically as
users pay their access fee.
- - - - - - - - - - - - - - - - -

Date: Mon, 3 Feb 1997 15:15:27 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

   >It seems that what you are asking for is fairl similar to
   >DIST_LIST_INCL attribute in IDRP. Correct ?

   I believe that DIST_LIST_INCL simply
   "lists the RDIs of the routeing domains and confederations
   to which the routeing information may be distributed."
   an RDI or confederation an RDI may contain a very large number
   of routers. It does not specify or restrict which of
   thousands or more routers(along th path and attached
   to it)are provided with the information.
   Any info on the granularity that could be implemented as
   well as the action that should (/not) be taken by routers
   along the path would be appreciated.

I'd like to understand why passing this information to some routers within
an AS is acceptable and not others in the AS.  By doing this, you're
basically precluding that domain from providing you with a resilient
internal structure.  What does this buy you?

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

To: Paul Ferguson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Helpful BGP Feature 
From: "John W. Stewart III" <[email-masked]>
Date: Mon, 03 Feb 1997 16:53:40 EST
Sender: [email-masked]

another point here is that controlling the distribution of
routing information is at least as important to transit
routing domain as it is to the originator of that routing
information.  so having an all-singing and all-dancing
attribute for the originator doesn't mean squat if the
immediately adjacent domain stomps on it...

/jws

 > At 03:05 PM 2/3/97 EST, [email-masked] wrote:
 > 
 > >I dont believe current implementations provide sufficient
 > >granularity, and are defined in a static manner anyway.
 > >
 > >If you could specify what features are available in
 > >"current implementation" that you are referring to
 > >it may be helpful in understanding this.
 > 
 > Basically, I am referring to explicit (static) definition
 > of BGP peers in a configuration. I suppose I'm just being
 > thick, but could you elaborate what types of granularity
 > which statically defining peers does not provide?
 > 
 > Thanks,
 > 
 > - paul
 > 
- - - - - - - - - - - - - - - - -

Date: Mon, 3 Feb 1997 13:38:16 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked] (Brandon Black)
Cc: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

   Two, I've heard rumors of people claiming it
   is possible to "remote sniff" traffic, by sending carefully contructed BGP
   advertisements which reroute the desired traffic to the sniffer, and then
   routing it back out.  It sounds very complicated to me, but I believe
   there are people out there capable of doing it.

Yes, this is trivially doable.  Most every operator knows how.

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

Date: Mon, 03 Feb 1997 16:10:31 -0500
To: [email-masked]
From: Paul Ferguson <[email-masked]>
Subject: Re: Helpful BGP Feature
Cc: [email-masked]
Sender: [email-masked]

At 03:05 PM 2/3/97 EST, [email-masked] wrote:

>I dont believe current implementations provide sufficient
>granularity, and are defined in a static manner anyway.
>
>If you could specify what features are available in
>"current implementation" that you are referring to
>it may be helpful in understanding this.

Basically, I am referring to explicit (static) definition
of BGP peers in a configuration. I suppose I'm just being
thick, but could you elaborate what types of granularity
which statically defining peers does not provide?

Thanks,

- paul

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

Date: Mon, 3 Feb 1997 12:48:25 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

   Avoiding having to wait for Service Providers to enter the policy
   changes,which sometimes can only occur during monthly
   change windows.

Find a different ISP.

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

From: [email-masked]
Date: Mon, 3 Feb 97 15:05:22 EST
To: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

Paul,
Thank you for your reply.
>How does this differ from a current implementation where
>explicit neighbors are defined ...
I dont believe current implementations provide sufficient
granularity, and are defined in a static manner anyway.

If you could specify what features are available in
"current implementation" that you are referring to
it may be helpful in understanding this.
Thanks

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

From: [email-masked]
Date: Mon, 3 Feb 97 14:55:32 EST
To: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

Yakov,
Thank you for your reply.
>It seems that what you are asking for is fairl similar to
>DIST_LIST_INCL attribute in IDRP. Correct ?
I believe that DIST_LIST_INCL simply
"lists the RDIs of the routeing domains and confederations
to which the routeing information may be distributed."
an RDI or confederation an RDI may contain a very large number
of routers. It does not specify or restrict which of
thousands or more routers(along th path and attached
to it)are provided with the information.
Any info on the granularity that could be implemented as
well as the action that should (/not) be taken by routers
along the path would be appreciated.
Thanks, Ed Segal

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

Date: Mon, 3 Feb 1997 13:35:29 -0600 (CST)
From: Brandon Black <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: Helpful BGP Feature
Sender: [email-masked]

On Mon, 3 Feb 1997 [email-masked] wrote:

> It may be helpful to add a feature to allow for Directed Route
> announcements. The originator of a BGP Route, for example, could
> specify in an optional attribute, the desired recipient(s) of the
> Route Advertisement e.g.listing the AS numbers or IP addresses of
> the Networks or even the specific gateways that should receive
> the Route Advertisement.
> 
> This would allow for capabilities including:
> 
> Creating Virtual Private Networks. Controlling access to a
> destination.
> 
> Limiting where Route advertisements are propogated. Not all
> destinations need or want to be in all the Global Routing tables.
> Avoiding the need to get Network Service Providers to place
> complex policy statements on their Routers - which may not
> have the desired granularity anyway.
> 
> Avoiding having to wait for Service Providers to enter the policy
> changes,which sometimes can only occur during monthly
> change windows.
> Thanks, Ed Segal [email-masked] 914 784-3259
> 

Well... that might allow for "Virtual Networks", but no Private ones.
Simply not advertising your route does _NOT_ protect your traffic.  For
one, it can still be sniffed at the providers the Virtual Network uses,
and it can be sniffed at the NAP's... (do you trust every single employee
at all of those places...?).  Two, I've heard rumors of people claiming it
is possible to "remote sniff" traffic, by sending carefully contructed BGP
advertisements which reroute the desired traffic to the sniffer, and then
routing it back out.  It sounds very complicated to me, but I believe
there are people out there capable of doing it.

Point is.... encryption leads to Private networks, not obscurity.  And
most people who would give so little care to their traffic as to route it
across the current IPv4 Internet Backbone in an attempt to make a Virtual
Network, will probably want Internet access from their sites as well.. and
thus wouldn't use the feature. 

The idea probably still has merit as a useful hack for Multihomed
non-transit customers with wierd routing requirements... but I don't see
it as a tool for "Virtual Private Networks"..... just wait for IPv6, and
then (hopefully) we can make VPN's where and when we want to easily.

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

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

Date: Mon, 03 Feb 1997 14:03:12 -0500
To: [email-masked]
From: Paul Ferguson <[email-masked]>
Subject: Re: Helpful BGP Feature
Cc: [email-masked]
Sender: [email-masked]

How does this differ from a current implementation where
explicit neighbors are defined (which already accomodates
each of your points below)?

- paul

At 12:36 PM 2/3/97 EST, [email-masked] wrote:

>It may be helpful to add a feature to allow for Directed Route
>announcements. The originator of a BGP Route, for example, could
>specify in an optional attribute, the desired recipient(s) of the
>Route Advertisement e.g.listing the AS numbers or IP addresses of
>the Networks or even the specific gateways that should receive
>the Route Advertisement.
>
>This would allow for capabilities including:
>
>Creating Virtual Private Networks. Controlling access to a
>destination.
>
>Limiting where Route advertisements are propogated. Not all
>destinations need or want to be in all the Global Routing tables.
>Avoiding the need to get Network Service Providers to place
>complex policy statements on their Routers - which may not
>have the desired granularity anyway.
>
>Avoiding having to wait for Service Providers to enter the policy
>changes,which sometimes can only occur during monthly
>change windows.
>Thanks, Ed Segal [email-masked] 914 784-3259
>
>

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: Helpful BGP Feature 
Date: Mon, 03 Feb 97 10:29:49 PST
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Ed,

> It may be helpful to add a feature to allow for Directed Route
> announcements. The originator of a BGP Route, for example, could
> specify in an optional attribute, the desired recipient(s) of the
> Route Advertisement e.g.listing the AS numbers or IP addresses of
> the Networks or even the specific gateways that should receive
> the Route Advertisement.
> 
> This would allow for capabilities including:
> 
> Creating Virtual Private Networks. Controlling access to a
> destination.
> 
> Limiting where Route advertisements are propogated. Not all
> destinations need or want to be in all the Global Routing tables.
> Avoiding the need to get Network Service Providers to place
> complex policy statements on their Routers - which may not
> have the desired granularity anyway.

It seems that what you are asking for is fairly similar to
DIST_LIST_INCL attribute in IDRP. Correct ?

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

From: [email-masked]
Date: Mon, 3 Feb 97 12:36:28 EST
To: [email-masked]
Subject: Helpful BGP Feature
Sender: [email-masked]

It may be helpful to add a feature to allow for Directed Route
announcements. The originator of a BGP Route, for example, could
specify in an optional attribute, the desired recipient(s) of the
Route Advertisement e.g.listing the AS numbers or IP addresses of
the Networks or even the specific gateways that should receive
the Route Advertisement.

This would allow for capabilities including:

Creating Virtual Private Networks. Controlling access to a
destination.

Limiting where Route advertisements are propogated. Not all
destinations need or want to be in all the Global Routing tables.
Avoiding the need to get Network Service Providers to place
complex policy statements on their Routers - which may not
have the desired granularity anyway.

Avoiding having to wait for Service Providers to enter the policy
changes,which sometimes can only occur during monthly
change windows.
Thanks, Ed Segal [email-masked] 914 784-3259

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

To: [email-masked] (Tony Bates)
Cc: Dimitry Haskin <[email-masked]>, Dave Katz <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: a different proposal for ipv6 in bgp 
Date: Fri, 31 Jan 1997 22:27:23 -0800
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]

Tony,

I am way, way behind in reading mailing list stuff, but

> interesting trend you see is the growth of ASes in the global routing
> system is essentially linear. Whilst my data source is quite small (see
> http://www.employees.org/~tbates/cidr.as.plot.html) this seems to be
> growing at an average rate of 3 ASes per day. The linear growth if
> further backed in "An analysis of Internet Inter-Domain Topology and
> Route Stability" by Ramesh Govindan and Anoop Reddy from USC/ISI.
> 
> If we use this growth rate and look at a couple of scenarios:

if this (very nice, thanks!) curve were actually linear than there
must have been about 0 AS numbers in use on April 1, 1995.  Since I
am pretty sure this wasn't the case then the second derivative of this
curve must certainly be positive even though the short bit of data
doesn't look like it.  If a linear extrapolation backward in time
doesn't match reality there is no reason to suspect a linear extrapolation
forward will either.

To put this another way, even an exponential will look like a straight line
if you look at just a short segment of it.  I don't think this is enough
data to tell what one is looking at.

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