Subject: Re: WG last call on -bgp-confed-rfc1965bis-00
From: Stephen Sauer <[email-masked]>
To: Tony Li <[email-masked]>, Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Date: Sat, 30 Sep 2000 14:43:04 +0200

Hi Tony,

Really yes, many customers use confederation, and for design, really, if we
have just Route-reflectors ...
Confederation is really funny to design and configure, not simple to
deploy, or migrate in an existing network. With extension of Pan European
Network, each country like to administrate its own network, confederation
is the best solution in this case, for me. Now, could you tell me if we
have confederation in an MPLS/VPN network. Actually, we can use Route
Reflector. I think confed, in this case, is similar to MP-eBGP. 
Someone has some info concerning this ?

Stephen

At 00:31 28/09/00 -0700, Tony Li wrote:
>
>
>Are folks still enamored of this solution?  Many other people seem to be
>more interested in route reflectors.  If no one is using confederations, we
>should let this die.
>
>Tony
>
>
>Yakov Rekhter writes:
> | Folks,
> | 
> | In response to the attached request I'd like to start
> | IDR WG Last Call on the document. The Last Call will
> | be closed in two weeks (oct 10).
> | 
> | Yakov.
> | ------- Forwarded Message
> | 
> | Date:    Mon, 25 Sep 2000 10:22:08 -0600
> | From:    Danny McPherson <[email-masked]>
> | To:      [email-masked]
> | Subject: BGP Confeds
> | 
> | 
> | Folks, we'd like to move this to Proposed Standard:
> | 
> | draft-ietf-idr-bgp-confed-rfc1965bis-00.txt
> | 
> | Comments?
> | 
> | - -danny
> | 
> | 
> | ------- End of Forwarded Message
> | 
> | 
> | 
> | _______________________________________________
> | Idr-external mailing list
> | [email-masked]
> | http://mailist.procket.com/mailman/listinfo/idr-external
>
>
>

Date: Sat, 30 Sep 2000 14:43:20 +0200
To: "ben abarbanel" <[email-masked]>, "Venu V." <[email-masked]>, <[email-masked]>
From: Stephen Sauer <[email-masked]>
Subject: Re: Updation of Routing tables by BGP
Sender: [email-masked]

Hello Ben,

FIB is generated, for a part, by routing table. If routing table is
updated, so, FIB will be updated with this new informations.

1. In this case, no, you just have the redistribution in the BGP table. If
you look at BGP table, you will find an entry with the IGP networks.
normally, it's a network entry with ORIGIN internal.
When you loose a network learned by IGP, you can have a problem. Indeed, if
the network disappears, IGP will suppress this network from the routing
table. If it's not suppressed from BGP table at the same time (
redistribution done later, you can have an entry to this network  in your
BGP table ). And this entry can be added to the routing table, if in your
bgp config, you have disabled synchronisation. Well, for this router, this
network is always reachable. While you dont have a withdraw for this
network, this network is "reachable" via this router.

2. This update received from an iBGP peer is stored in your BGP table. 
Now, if it's a new network, routing table will be updated. If it's an
existing network, BGP scans if this new entry is better than existing. If
this path is better, routing table is updated, else no.

Stephen

>
>> Hello Everyone,
>>
>> I have a doubt regarding updating of Routing tables or FIB(Forwading
>> information base) by BGP in the following scenarios
>>
>> 1. When IGP routes are injected into BGP, does BGP updates the Routing
>> tables? Because IGP must have already updated the Routing table.
>>
>> 2. Similarly when BGP receives a Update message from an internal BGP peer
>> does it needs to update its routing table.
>>
>> Any input on this queries is welcome!!!
>>
>> Thanks,
>> Venu
>>

From: Tony Li <[email-masked]>
Date: Thu, 28 Sep 2000 10:04:38 -0700 (PDT)
To: Erik Sherk <[email-masked]>
Cc: Tony Li <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 
Sender: [email-masked]

 | 	UUNET uses BGP confederations extensively. We have three
 | confederations, one per each of our operational areas. They really
 | help solve some scaling issues that are not strictly technical.
 | We would appreciate moving forward with this. Thanks...

Erik,

That's fine thanks.  Just as long as someone still wants 'em.

Tony

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 
Date: Thu, 28 Sep 2000 10:21:24 -0600
Sender: [email-masked]

Agreed.  I know of a number of networks (new & old) that are using 
confederations.

-danny

> Both confederations and route reflectors are still useful.  Some
> providers use confederations to provide a sepatation between regions
> and core and then use RR within the regions.  In some situations
> community based policiy is provided between confederations (affecting
> preference and in some cases aggregation).  We still have customer
> requests for confederations so it is clearly not dead.

To: Tony Li <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: WG last call on -bgp-confed-rfc1965bis-00 
Date: Thu, 28 Sep 2000 12:14:51 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Tony Li writes:
> 
> Are folks still enamored of this solution?  Many other people seem to be
> more interested in route reflectors.  If no one is using confederations, we
> should let this die.
> 
> Tony

Tony,

Both confederations and route reflectors are still useful.  Some
providers use confederations to provide a sepatation between regions
and core and then use RR within the regions.  In some situations
community based policiy is provided between confederations (affecting
preference and in some cases aggregation).  We still have customer
requests for confederations so it is clearly not dead.

Curtis

From: "vikram idrp" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: imports to IBGP peers
Date: Thu, 28 Sep 2000 15:36:12 GMT
Sender: [email-masked]

>From: "James Tsillas" <[email-masked]>
>Reply-To: <[email-masked]>
>To: "IDR" <[email-masked]>
>Subject: imports to IBGP peers
>Date: Wed, 27 Sep 2000 14:06:32 -0400
>
>Should imported routes (via cisco "network" cmd) be
>redistributed to internal peers? by default? by switch?
By default, if the "networked" prefix is also present in the FIB, it is 
announced to the internal peers.
-Vikram
>WDCD? (What Does Cisco Do?)
>
>It seems that one can either rely on IGP to import local
>routes (via redistribution) or use manual "network" cmd
>and rely on IBGP.
>
>-Jim.
>
>
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

From: Randy Bush <[email-masked]>
To: Tony Li <[email-masked]>
Cc: [email-masked]
Subject: Re: WG last call on -bgp-confed-rfc1965bis-00
Date: Thu, 28 Sep 2000 05:52:55 -0700
Sender: [email-masked]

> Are folks still enamored of this solution?

yes, very much so.

randy

Date: Thu, 28 Sep 2000 11:26:57 +0200
From: Geoffrey CRISTALLO <[email-masked]>
To: [email-masked]
Subject: Use of BGP-4 multiprotocol extensions for IPv6
Sender: [email-masked]

Hi,

Paragraph 1 of RFC 2858 (Multiprotocol extensions for BGP-4) says "This
document assumes that any BGP speaker has to have an IPv4 address". How
can this be achieved in an IPv6 network where the BGP speakers do not
have an IPv4 address ??? RFC 2545 explains how to use BGP-4
multiprotocol extensions for ipv6 inter-domain routing, but does not
treat this "problem".

Many thanks in advance

Geoffrey Cristallo

From: Tony Li <[email-masked]>
Date: Thu, 28 Sep 2000 00:31:06 -0700 (PDT)
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: WG last call on -bgp-confed-rfc1965bis-00
Sender: [email-masked]

Are folks still enamored of this solution?  Many other people seem to be
more interested in route reflectors.  If no one is using confederations, we
should let this die.

Tony

Yakov Rekhter writes:
 | Folks,
 | 
 | In response to the attached request I'd like to start
 | IDR WG Last Call on the document. The Last Call will
 | be closed in two weeks (oct 10).
 | 
 | Yakov.
 | ------- Forwarded Message
 | 
 | Date:    Mon, 25 Sep 2000 10:22:08 -0600
 | From:    Danny McPherson <[email-masked]>
 | To:      [email-masked]
 | Subject: BGP Confeds
 | 
 | 
 | Folks, we'd like to move this to Proposed Standard:
 | 
 | draft-ietf-idr-bgp-confed-rfc1965bis-00.txt
 | 
 | Comments?
 | 
 | - -danny
 | 
 | 
 | ------- End of Forwarded Message
 | 
 | 
 | 
 | _______________________________________________
 | Idr-external mailing list
 | [email-masked]
 | http://mailist.procket.com/mailman/listinfo/idr-external

Reply-To: <[email-masked]>
From: "James Tsillas" <[email-masked]>
To: "IDR" <[email-masked]>
Subject: imports to IBGP peers
Date: Wed, 27 Sep 2000 14:06:32 -0400
Importance: Normal
Sender: [email-masked]

Should imported routes (via cisco "network" cmd) be
redistributed to internal peers? by default? by switch?

WDCD? (What Does Cisco Do?)

It seems that one can either rely on IGP to import local
routes (via redistribution) or use manual "network" cmd
and rely on IBGP.

-Jim.

Reply-To: "ben abarbanel" <[email-masked]>
From: "ben abarbanel" <[email-masked]>
To: "Venu V." <[email-masked]>, <[email-masked]>
Subject: Re: Updation of Routing tables by BGP
Date: Wed, 27 Sep 2000 10:29:31 -0400
Organization: IPOptical
Sender: [email-masked]

Venu:
  To answer your question in a more global sense. You should look at the
preference test between routing protocols when updating the FDB. Clearly BGP
has lower preference than IGP, thus it will not overwrite IGP routes with
BGP routes for the same prefix.  There are other relationship between the
type of routes, so I suggest you look at the specification on how Cisco and
Juniper work.

Regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

----- Original Message -----
From: "Venu V." <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 27, 2000 7:03 AM
Subject: Updation of Routing tables by BGP

> Hello Everyone,
>
> I have a doubt regarding updating of Routing tables or FIB(Forwading
> information base) by BGP in the following scenarios
>
> 1. When IGP routes are injected into BGP, does BGP updates the Routing
> tables? Because IGP must have already updated the Routing table.
>
> 2. Similarly when BGP receives a Update message from an internal BGP peer
> does it needs to update its routing table.
>
> Any input on this queries is welcome!!!
>
> Thanks,
> Venu
>

From: "Natale, Jonathan" <[email-masked]>
To: "'Venu V.'" <[email-masked]>, [email-masked]
Subject: RE: Updation of Routing tables by BGP
Date: Wed, 27 Sep 2000 08:48:53 -0400
Sender: [email-masked]

imo:

1. no

2. not if same route is learned by ebgp or igp 

-----Original Message-----
From: Venu V. [mailto:[email-masked]]
Sent: Wednesday, September 27, 2000 7:03 AM
To: [email-masked]
Subject: Updation of Routing tables by BGP

Hello Everyone,

I have a doubt regarding updating of Routing tables or FIB(Forwading
information base) by BGP in the following scenarios

1. When IGP routes are injected into BGP, does BGP updates the Routing
tables? Because IGP must have already updated the Routing table.

2. Similarly when BGP receives a Update message from an internal BGP peer
does it needs to update its routing table.

Any input on this queries is welcome!!!

Thanks,
Venu

From: "Venu V." <[email-masked]>
To: [email-masked]
Subject: Updation of Routing tables by BGP
Date: Wed, 27 Sep 2000 07:03:26 -0400
Sender: [email-masked]

Hello Everyone,

I have a doubt regarding updating of Routing tables or FIB(Forwading
information base) by BGP in the following scenarios

1. When IGP routes are injected into BGP, does BGP updates the Routing
tables? Because IGP must have already updated the Routing table.

2. Similarly when BGP receives a Update message from an internal BGP peer
does it needs to update its routing table.

Any input on this queries is welcome!!!

Thanks,
Venu

To: [email-masked]
Subject: WG last call on -bgp-confed-rfc1965bis-00
Date: Tue, 26 Sep 2000 08:09:33 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

In response to the attached request I'd like to start
IDR WG Last Call on the document. The Last Call will
be closed in two weeks (oct 10).

Yakov.
------- Forwarded Message

Date:    Mon, 25 Sep 2000 10:22:08 -0600
From:    Danny McPherson <[email-masked]>
To:      [email-masked]
Subject: BGP Confeds

Folks, we'd like to move this to Proposed Standard:

draft-ietf-idr-bgp-confed-rfc1965bis-00.txt

Comments?

- -danny

------- End of Forwarded Message

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: BGP Confeds
Date: Mon, 25 Sep 2000 10:22:08 -0600
Sender: [email-masked]

Folks, we'd like to move this to Proposed Standard:

draft-ietf-idr-bgp-confed-rfc1965bis-00.txt

Comments?

-danny

To: [email-masked]
Subject: draft-chen-bgp-prefix-orf-00.txt
Date: Sun, 24 Sep 2000 15:05:08 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

If there are any objections to the attached request, please
send them to this list within next two week. 

Yakov.
------- Forwarded Message

Date:    Sun, 24 Sep 2000 11:59:30 -0700
From:    Enke Chen <[email-masked]>
To:      [email-masked], [email-masked]
cc:      [email-masked]
Subject: draft-chen-bgp-prefix-orf-00.txt

Hi, Yakov and Sue:
I would like to request that the draft be considered as an IDR WG
document.

Thank you in advance for your consideration. 

- -- Enke

------- End of Forwarded Message

Date: Thu, 21 Sep 2000 21:55:32 -0400
To: ming lu <[email-masked]>
From: "Mark Thompson" <[email-masked]>
Subject: Re: BGP routes generator (freeware)
Cc: IDR <[email-masked]>
Sender: [email-masked]

Take a look @ http://www.mrtd.net/ in particular BGPsim.

At 16:02 21/09/00 -0400, ming lu wrote:
>Hi:
>
>Is there any BGP routes generator out there? I am looking for freeware,
>since smartbits is just too expensive ...
>
>TIA
>
>_ming

From: "Dmitri Krioukov" <[email-masked]>
To: "truename" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Question about ISP interconnection
Date: Fri, 22 Sep 2000 01:00:37 -0400
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> truename
> Sent: Thursday, September 21, 2000 10:08 PM
> To: [email-masked]
> Subject: Question about ISP interconnection
>
>
> Hi,
>
> I am planning a ISP network. But something bothers me.

:)))

> It's known that there're two way to interconnect multiple ISP
> networks: one is public
> peering through NAP or IXP,another is private peering via direct
> connection. Which one
> is better?
> In common, NAP(IXP) provides a Routing Arbiter service. What is
> Routing Arbiter and how
> does it work?
> Are trere some prefernece about these?

All these questions are more appropriate for the NANOG mailing
list. You may start with http://www.nanog.org. Good luck.

> 			Thanks in advance
>
> Regards
> WenJian
>
> ��ӭʹ��������һ����������
> http://search.163.com
> ��������--������Ѷ������
--
dima.

Date: Fri, 22 Sep 2000 10:07:35 +0800 (CST)
From: "truename" <[email-masked]>
To: [email-masked]
Subject: Question about ISP interconnection
Sender: [email-masked]

Hi,

I am planning a ISP network. But something bothers me.
It's known that there're two way to interconnect multiple ISP networks: one is public 
peering through NAP or IXP,another is private peering via direct connection. Which one 
is better?
In common, NAP(IXP) provides a Routing Arbiter service. What is Routing Arbiter and how 
does it work?
Are trere some prefernece about these?

			Thanks in advance

Regards
WenJian

��ӭʹ��������һ����������
http://search.163.com
��������--������Ѷ������

From: Ganesan Ramu <[email-masked]>
To: "'ming lu'" <[email-masked]>, IDR <[email-masked]>
Subject: RE: BGP routes generator (freeware)
Date: Thu, 21 Sep 2000 14:04:37 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0240F.8D144880
Content-Type: text/plain;
	charset="iso-8859-1"

bgpsim, which is part of MRT from http://www.merit.edu/~mrt/ is a good
simulator.

-----Original Message-----
From: ming lu [mailto:[email-masked]]
Sent: Thursday, September 21, 2000 1:03 PM
To: IDR
Subject: BGP routes generator (freeware)

Hi:

Is there any BGP routes generator out there? I am looking for freeware,
since smartbits is just too expensive ...

TIA

_ming

------_=_NextPart_001_01C0240F.8D144880
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: BGP routes generator (freeware)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>bgpsim, which is part of MRT from <A =
HREF=3D"http://www.merit.edu/~mrt/" =
TARGET=3D"_blank">http://www.merit.edu/~mrt/</A> is a good =
simulator.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: ming lu [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, September 21, 2000 1:03 PM</FONT>
<BR><FONT SIZE=3D2>To: IDR</FONT>
<BR><FONT SIZE=3D2>Subject: BGP routes generator (freeware)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi:</FONT>
</P>

<P><FONT SIZE=3D2>Is there any BGP routes generator out there? I am =
looking for freeware,</FONT>
<BR><FONT SIZE=3D2>since smartbits is just too expensive ...</FONT>
</P>

<P><FONT SIZE=3D2>TIA</FONT>
</P>

<P><FONT SIZE=3D2>_ming</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0240F.8D144880--

Date: Thu, 21 Sep 2000 16:02:30 -0400
From: ming lu <[email-masked]>
Subject: BGP routes generator (freeware)
To: IDR <[email-masked]>
Sender: [email-masked]

Hi:

Is there any BGP routes generator out there? I am looking for freeware,
since smartbits is just too expensive ...

TIA

_ming

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: 2260 multi-homing
Date: Thu, 21 Sep 2000 13:21:20 -0600
Sender: [email-masked]

There are other issues as well.  

For example, customers ("enterprises" or "service providers") frequently only 
have a few hosts that account for the bulk of the "Internet" bandwidth 
utilization, and as such, this model provides no mechanism to perform 
load-sharing (ingress to the customer domain) .. this is especially a problem 
for "lower tier" service providers.

The most broken thing I see with this proposal relates to failure recovery.   
Not only is the customer down for N minutes while the new path is propagated 
across multiple routing domains (which is extremely undesirable, and 
reasonably unacceptable to anyone with half a clue), route oscillation could 
easily result in subsequent suppression by domains upstream from ISPs adjacent 
to the enterprise.

Not to mention the impact of changes in policies, filters, etc.. by others 
ISPs that would likely result in non-deterministic behavior (and this often 
not working at all) when failures occur.

And no way would ISPs want to deal with managing non-direct EBGP peering.  
Customers (and ISPs alike) have problems managing "normal" configurations, now 
they're expected to be able to manage and troubleshoot and provision these 
types of complex things?  And w/the non-direct EBGP peering model I now 
potentially have to maintain a peering session (and associated policies) for 
each connection my customer has to other networks...

And ISP-N the whole time has to employ prefix filtering that includes all  
these "might-be-advertised-at-some-point" routes .. and as such, [ideally] has 
to include ISP-M's IRR entries for the customer AS or AS-MACRO.

There's a whole slew of other issues that could be considered here as well.

I think the bottom line is that while this would theoretically decrease the 
number of BGP paths available to a given prefix, and as well result in a lower 
number of unique prefixes in the routing system (when in steady state), it's 
simply not worth the hassle.

Buying more memory and not dealing with this is much more efficient.  Of 
course, omitting some of the multi-protocol cruft from BGP (e.g. VPN gunk) 
would likely be just as beneficial -- if not more.

As for it's relation to optimal routing, even MEDs are broken with aggregation.

-danny

> I think I finally put my finger on what bothers me about RFC 2260.
> 
> The biggest operational issue is probably the BGP ease of use issue, or the
> ISP-trust-of-edge-network issue, that I list below.
> 
> But that all aside, I think RFC 2260 misses a case. It posits two cases, in
> this picture (taken from the RFC):
> 
>          +-------+    +-------+         +-------+    +-------+
>          (       )    (       )         (       )    (       )
>          ( ISP-A )    ( ISP-B )         ( ISP-A )    ( ISP-B )
>          (       )    (       )         (       )    (       )
>          +-------+    +-------+         +-------+    +-------+
>              |   /\       |   /\            |   /\       |
>              |   ||       |   ||            | Pref-A  (connection
>              | Pref-A     | Pref-B          | Pref-B    broken)
>              |   ||       |   ||            |   ||       |
>           +-----+      +-----+           +-----+      +-----+
>           | BR-A|------|BR-B |           | BR-A|------|BR-B |
>           +-----+ IBGP +-----+           +-----+ IBGP +-----+
> 
>            non-empty intersection         empty intersection
> 
> Ultimately, the goal of the RFC is that a host within the multihomed edge
> network has an address within Pref-A or an address within Pref-B, and that
> it can use either type of address to communicate with a device in a remote
> network, let's say within Pref-C:
> 
>                                  host-C
>                                   |
>                                 BR-C
>                                   |
>                             ISP network C
>                                   |
>                  (the Internet, who knows how it gets there)
>                            |                     |
>                      ISP Network A        ISP Network B
>                            |                     |
>                           BR-A                 BR-B
>                          /-------------------------/
>                             host-A         host-B
> 
> So we call these hosts host-A, host-B, and host-C for convenience; each is
> using an address in whichever prefix is relevant, and each needs to be able
> to talk with the other two all the time.
> 
> But suppose that the issue is not that BR-B loses its link to ISP Network B,
> but that ISP Network B stops being reachable from ISP Network C? Reasons
> could include a backhoe event, a bad confluence of policy, etc; bottom line
> is that the advertisement doesn't get into ISP Network C from ISP Network B.
> In that case, we need for Pref-B to get advertised via ISP Network A (it
> still may not arrive, if the issue is policy, but if it is a backhoe event,
> it may very well), but BR-A has no visibility of that. Often, in an edge
> network, BR-A and BR-B will not event have a direct route to Pref-C, they
> will have default routes leading into the default-free zone.
> 
> It seems to me - and if I have this wrong, please correct me and show me how
> this works - that in such a case communication is lost between host-B and
> host-C, and there is no way for BR-A to realize that it has to advertise
> Pref-B to fix it, because everything looks fine from its perspective.
> 
> >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote:
> >>What exactly is/are the reason(s) the mult-homed (to different
> >>ISPs) routing strategies suggested by RFC 2260 is not widely
> >>deployed (or not deployed at all)?
> >
> >Just a guess, but I would expect that
> >
> >(a) service providers generally prefer to decide for themselves what 
> >routes they will advertise with regard to a customer, and will do that 
> >unless given a good monetary reason not to, and
> >(b) customers are generally not savvy enough about routing to ask for the 
> >ability to advertise a different prefix on demand to the service provider, 
> >or to set it up.
> >
> >This translates as "there is no obvious reason that this would not work, 
> >but you have to ask for it, and you have to set it up, and getting BGP 
> >configurations right is not easy". The routing exchange between edge 
> >networks and their service providers is generally a default route 
> >advertised in a common IGP, or simply configured in place, not a routing 
> >exchange in BGP.
> 
> 

To: BGP mailing list <[email-masked]>
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: 2260 multi-homing 
Date: Thu, 21 Sep 2000 12:52:10 -0600
Sender: [email-masked]

There are other issues as well.  

For example, customers ("enterprises" or "service providers") frequently only 
have a few hosts that account for the bulk of the "Internet" bandwidth 
utilization, and as such, this model provides no mechanism to perform 
load-sharing (ingress to the customer domain) .. this is especially a problem 
for "lower tier" service providers.

The most broken thing I see with this proposal relates to failure recovery.  
Not only is the customer down for N minutes while the new path is propagated 
across multiple routing domains (which is extremely undesirable, and would be 
reasonably unacceptable to anyone with half a clue), route oscillation could 
easily result in suppression by domains upstream from adjacent ISPs.  Not to 
mention the impact of changes in policies, filters, etc.. by others ISPs that 
would likely result in this not working at all the greater majority of the 
time.

And no way would ISPs want to deal with managing non-direct EBGP peering.  
Much less, customers (and ISPs alike) have problems managing "normal" 
configurations, now they're expected to be able to manage and troubleshoot and 
provision these types of complex things?

And ISP-N the whole time has to employ prefix filtering that includes all 
these "might-be-advertised-at-some-point" routes .. and as such, [ideally] has 
to include ISP-M's IRR entries for the customer AS or AS-MACRO.

There's a whole slew of other less significant issues that could be dicussed.

I think the bottom line is that while this would theoretically decrease the 
number of BGP paths available to a given prefix, and as well result in a lower 
number of unique prefixes in the routing system, it's simply not worth the 
hassle.

Buying more memory and not dealing with this is much more efficient.  Of 
course, omitting some of the multi-protocol cruft from of BGP (e.g. VPN gunk) 
would likely be just as beneficial -- if not more.

-danny

> I think I finally put my finger on what bothers me about RFC 2260.
> 
> The biggest operational issue is probably the BGP ease of use issue, or the
> ISP-trust-of-edge-network issue, that I list below.
> 
> But that all aside, I think RFC 2260 misses a case. It posits two cases, in
> this picture (taken from the RFC):
> 
>          +-------+    +-------+         +-------+    +-------+
>          (       )    (       )         (       )    (       )
>          ( ISP-A )    ( ISP-B )         ( ISP-A )    ( ISP-B )
>          (       )    (       )         (       )    (       )
>          +-------+    +-------+         +-------+    +-------+
>              |   /\       |   /\            |   /\       |
>              |   ||       |   ||            | Pref-A  (connection
>              | Pref-A     | Pref-B          | Pref-B    broken)
>              |   ||       |   ||            |   ||       |
>           +-----+      +-----+           +-----+      +-----+
>           | BR-A|------|BR-B |           | BR-A|------|BR-B |
>           +-----+ IBGP +-----+           +-----+ IBGP +-----+
> 
>            non-empty intersection         empty intersection
> 
> Ultimately, the goal of the RFC is that a host within the multihomed edge
> network has an address within Pref-A or an address within Pref-B, and that
> it can use either type of address to communicate with a device in a remote
> network, let's say within Pref-C:
> 
>                                  host-C
>                                   |
>                                 BR-C
>                                   |
>                             ISP network C
>                                   |
>                  (the Internet, who knows how it gets there)
>                            |                     |
>                      ISP Network A        ISP Network B
>                            |                     |
>                           BR-A                 BR-B
>                          /-------------------------/
>                             host-A         host-B
> 
> So we call these hosts host-A, host-B, and host-C for convenience; each is
> using an address in whichever prefix is relevant, and each needs to be able
> to talk with the other two all the time.
> 
> But suppose that the issue is not that BR-B loses its link to ISP Network B,
> but that ISP Network B stops being reachable from ISP Network C? Reasons
> could include a backhoe event, a bad confluence of policy, etc; bottom line
> is that the advertisement doesn't get into ISP Network C from ISP Network B.
> In that case, we need for Pref-B to get advertised via ISP Network A (it
> still may not arrive, if the issue is policy, but if it is a backhoe event,
> it may very well), but BR-A has no visibility of that. Often, in an edge
> network, BR-A and BR-B will not event have a direct route to Pref-C, they
> will have default routes leading into the default-free zone.
> 
> It seems to me - and if I have this wrong, please correct me and show me how
> this works - that in such a case communication is lost between host-B and
> host-C, and there is no way for BR-A to realize that it has to advertise
> Pref-B to fix it, because everything looks fine from its perspective.
> 
> >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote:
> >>What exactly is/are the reason(s) the mult-homed (to different
> >>ISPs) routing strategies suggested by RFC 2260 is not widely
> >>deployed (or not deployed at all)?
> >
> >Just a guess, but I would expect that
> >
> >(a) service providers generally prefer to decide for themselves what 
> >routes they will advertise with regard to a customer, and will do that 
> >unless given a good monetary reason not to, and
> >(b) customers are generally not savvy enough about routing to ask for the 
> >ability to advertise a different prefix on demand to the service provider, 
> >or to set it up.
> >
> >This translates as "there is no obvious reason that this would not work, 
> >but you have to ask for it, and you have to set it up, and getting BGP 
> >configurations right is not easy". The routing exchange between edge 
> >networks and their service providers is generally a default route 
> >advertised in a common IGP, or simply configured in place, not a routing 
> >exchange in BGP.
> 
> 

Date: Thu, 21 Sep 2000 13:49:19 -0400
To: "Dmitri Krioukov" <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: RE: 2260 multi-homing
Cc: "BGP mailing list" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 01:32 PM 9/21/00 -0400, Dmitri Krioukov wrote:
>As you can see, the only way to solve this is that ISP-A always
>advertises Pref-B to cover all possible default-free zone problems.
>However, this is basically equivalent to customer's using a PI
>block (Pref-Z) advertised by the both ISP. And this is what
>RFC2260 is trying to mitigate (longer prefix injections).
>
>I think that multihoming (especially for longer prefixes) remains
>an open question while getting more and more frequently asked
>by the customers.

very much agree on both points. I have to say that I am thinking about 
Metro Addressing models, and expect to put together a draft on that. I'm 
aware of the past debates along those lines. My observation is that while 
geography has no bearing on topology (for which reason I have historically 
discounted it as bunk), multihoming by definition is bypassing topological 
issues.

The key point will be that the geographical region wants to be selected 
such that a large percentage of multihomed sites are in fact aggregated 
outside the region. If we are multihoming homes (recent conversation with 
Steve Deering), the geographical region probably can be something smaller 
than a country. If we are multihoming companies, it probably has to be on 
the order of countries to continents. I don't think that there is an 
obvious multihoming solution that aggregates for multinational companies, 
but that may be OK.

From: "Dmitri Krioukov" <[email-masked]>
To: "Fred Baker" <[email-masked]>, "BGP mailing list" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: 2260 multi-homing
Date: Thu, 21 Sep 2000 13:32:28 -0400
Importance: Normal
Sender: [email-masked]

I've been trying to understand myself why RFC2260 scenarios
are not widely deployed. As a result of this effort, I got
to the conclusion that the major reason they are not widely
deployed is that they are not widely known by the operators.
This conclusion looks more like impression and it may be
wrong. Also, section 5.2 in particular, involves some "non-
standard" BGP configurations and providers are usually not
willing to do that since this (even slightest) complication
does not bring them any immediate revenue increase.

I think you're right and RFC2260 addresses only local (provider-
customer) failures (but it addresses them well!) and it does not
address the backbone events, etc. In your example below, imagine
there is also ISP-D where some other potential clients reside and,
while ISP-C still does not have routes for ISP-B, ISP-D does.
Why should ISP-A advertise anything from the ISP-B address space?

As you can see, the only way to solve this is that ISP-A always
advertises Pref-B to cover all possible default-free zone problems.
However, this is basically equivalent to customer's using a PI
block (Pref-Z) advertised by the both ISP. And this is what
RFC2260 is trying to mitigate (longer prefix injections).

I think that multihoming (especially for longer prefixes) remains
an open question while getting more and more frequently asked
by the customers.
--
dima.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Fred
> Baker
> Sent: Thursday, September 21, 2000 6:42 AM
> To: BGP mailing list
> Cc: [email-masked]; [email-masked]
> Subject: Re: 2260 multi-homing
>
>
> I think I finally put my finger on what bothers me about RFC 2260.
>
> The biggest operational issue is probably the BGP ease of use
> issue, or the
> ISP-trust-of-edge-network issue, that I list below.
>
> But that all aside, I think RFC 2260 misses a case. It posits two
> cases, in
> this picture (taken from the RFC):
>
>          +-------+    +-------+         +-------+    +-------+
>          (       )    (       )         (       )    (       )
>          ( ISP-A )    ( ISP-B )         ( ISP-A )    ( ISP-B )
>          (       )    (       )         (       )    (       )
>          +-------+    +-------+         +-------+    +-------+
>              |   /\       |   /\            |   /\       |
>              |   ||       |   ||            | Pref-A  (connection
>              | Pref-A     | Pref-B          | Pref-B    broken)
>              |   ||       |   ||            |   ||       |
>           +-----+      +-----+           +-----+      +-----+
>           | BR-A|------|BR-B |           | BR-A|------|BR-B |
>           +-----+ IBGP +-----+           +-----+ IBGP +-----+
>
>            non-empty intersection         empty intersection
>
> Ultimately, the goal of the RFC is that a host within the multihomed edge
> network has an address within Pref-A or an address within Pref-B, and that
> it can use either type of address to communicate with a device in a remote
> network, let's say within Pref-C:
>
>                                  host-C
>                                   |
>                                 BR-C
>                                   |
>                             ISP network C
>                                   |
>                  (the Internet, who knows how it gets there)
>                            |                     |
>                      ISP Network A        ISP Network B
>                            |                     |
>                           BR-A                 BR-B
>                          /-------------------------/
>                             host-A         host-B
>
> So we call these hosts host-A, host-B, and host-C for convenience; each is
> using an address in whichever prefix is relevant, and each needs
> to be able
> to talk with the other two all the time.
>
> But suppose that the issue is not that BR-B loses its link to ISP
> Network B,
> but that ISP Network B stops being reachable from ISP Network C? Reasons
> could include a backhoe event, a bad confluence of policy, etc;
> bottom line
> is that the advertisement doesn't get into ISP Network C from ISP
> Network B.
> In that case, we need for Pref-B to get advertised via ISP Network A (it
> still may not arrive, if the issue is policy, but if it is a
> backhoe event,
> it may very well), but BR-A has no visibility of that. Often, in an edge
> network, BR-A and BR-B will not event have a direct route to Pref-C, they
> will have default routes leading into the default-free zone.
>
> It seems to me - and if I have this wrong, please correct me and
> show me how
> this works - that in such a case communication is lost between host-B and
> host-C, and there is no way for BR-A to realize that it has to advertise
> Pref-B to fix it, because everything looks fine from its perspective.
>
> >At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote:
> >>What exactly is/are the reason(s) the mult-homed (to different
> >>ISPs) routing strategies suggested by RFC 2260 is not widely
> >>deployed (or not deployed at all)?
> >
> >Just a guess, but I would expect that
> >
> >(a) service providers generally prefer to decide for themselves what
> >routes they will advertise with regard to a customer, and will do that
> >unless given a good monetary reason not to, and
> >(b) customers are generally not savvy enough about routing to
> ask for the
> >ability to advertise a different prefix on demand to the service
> provider,
> >or to set it up.
> >
> >This translates as "there is no obvious reason that this would not work,
> >but you have to ask for it, and you have to set it up, and getting BGP
> >configurations right is not easy". The routing exchange between edge
> >networks and their service providers is generally a default route
> >advertised in a common IGP, or simply configured in place, not a routing
> >exchange in BGP.
>

Reply-To: "ben abarbanel" <[email-masked]>
From: "ben abarbanel" <[email-masked]>
To: <[email-masked]>, "James Tsillas" <[email-masked]>
Cc: "IDR" <[email-masked]>
Subject: Re: question on route propagation
Date: Wed, 20 Sep 2000 19:59:46 -0400
Organization: IPOptical
Sender: [email-masked]

IMO,

An IBGP route must have a BGP Next-hop that has reachability in the IGP
domain. Meaning there is an IGP next hop that can get to the BGP Next-hop.
If not the route should be rejected by the adj-RIB-in processing and hence
should not make it to the Loc-RIB  or adj-RIB-out. Anybody that violates
this rule and uses and/or propagates this route will most certainly be
looking at routes that lead to black holes.

Just another opinion on the matter,

Regards,
Ben

Ben Abarbanel,  Software Engineering,

Phone:  703 456 2982
FAX:      703 456 2952

IPOptical, Inc.
11480 Sunset Hills Road
Suite #200E
Reston, VA 20190

----- Original Message -----
From: <[email-masked]>
To: "James Tsillas" <[email-masked]>
Cc: "IDR" <[email-masked]>
Sent: Wednesday, September 20, 2000 5:30 PM
Subject: Re: question on route propagation

> Advertising a route with a NH differing from that installed
> in the FIB creates some obvious potential loop situations
>
> according to 1771:
>
>
>       - Routes are stored in the Routing Information Bases (RIBs):
>       namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes
>       that will be advertised to other BGP speakers must be present in
>       the Adj-RIB-Out; routes that will be used by the local BGP speaker
>       must be present in the Loc-RIB, and the next hop for each of these
>       routes must be present in the local BGP speaker's forwarding
>       information base; and routes that are received from other BGP
>       speakers are present in the Adj-RIBs-In.
>
>
> Many vendors seem to advertise only those bgp routes installed
> in the rib as best - this can lead to problems when routes
> exist in both the IGP and iBGP, even with the same NH.
> I would consider this a bug - the bgp route should be advertised
> as long as the NH's are congruent (in order to avoid loop
> scenario).
>
> If anyone can think of a reason why this is broken, please
> let me know.
>
> IMO:
>
> Implementations should have a switch for both behaviors.
>
> 1>  BGP routes should be advertised as long as NH in Loc-RIB
> and in IGP are congruent (for strict compliance)
>
> or
>
> 2> BGP routes that make it into Loc-RIB should be elligible
> for insertion into Adj-RIB-Out regardless of NH in underlying
> protocol (most people have networks designed around BGP
> using this behavior at this point).
>
> my 2c.
>
> -ed
>
>
>
> --> James Tsillas <[email-masked]> [000920 15:25]:
>
> > What should a peer do when it receives an IBGP update
> > which doesn't agree with the IGP next hop? Should it
> > still propagate that update to its external peers? How
> > about if the next hops agree but the IGP route is still
> > preferred?
> >
> > -Jim.
> >
> >
>
> --
> Edward Crabbe
> =============
> Sr. Network Architect
> Backbone Group
> Exodus Communications
> -------------
> v0x: 408 346 1544
>

Date: Thu, 21 Sep 2000 06:42:20 -0400
To: BGP mailing list <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: 2260 multi-homing
Cc: [email-masked], [email-masked]
Sender: [email-masked]

I think I finally put my finger on what bothers me about RFC 2260.

The biggest operational issue is probably the BGP ease of use issue, or the
ISP-trust-of-edge-network issue, that I list below.

But that all aside, I think RFC 2260 misses a case. It posits two cases, in
this picture (taken from the RFC):

         +-------+    +-------+         +-------+    +-------+
         (       )    (       )         (       )    (       )
         ( ISP-A )    ( ISP-B )         ( ISP-A )    ( ISP-B )
         (       )    (       )         (       )    (       )
         +-------+    +-------+         +-------+    +-------+
             |   /\       |   /\            |   /\       |
             |   ||       |   ||            | Pref-A  (connection
             | Pref-A     | Pref-B          | Pref-B    broken)
             |   ||       |   ||            |   ||       |
          +-----+      +-----+           +-----+      +-----+
          | BR-A|------|BR-B |           | BR-A|------|BR-B |
          +-----+ IBGP +-----+           +-----+ IBGP +-----+

           non-empty intersection         empty intersection

Ultimately, the goal of the RFC is that a host within the multihomed edge
network has an address within Pref-A or an address within Pref-B, and that
it can use either type of address to communicate with a device in a remote
network, let's say within Pref-C:

                                 host-C
                                  |
                                BR-C
                                  |
                            ISP network C
                                  |
                 (the Internet, who knows how it gets there)
                           |                     |
                     ISP Network A        ISP Network B
                           |                     |
                          BR-A                 BR-B
                         /-------------------------/
                            host-A         host-B

So we call these hosts host-A, host-B, and host-C for convenience; each is
using an address in whichever prefix is relevant, and each needs to be able
to talk with the other two all the time.

But suppose that the issue is not that BR-B loses its link to ISP Network B,
but that ISP Network B stops being reachable from ISP Network C? Reasons
could include a backhoe event, a bad confluence of policy, etc; bottom line
is that the advertisement doesn't get into ISP Network C from ISP Network B.
In that case, we need for Pref-B to get advertised via ISP Network A (it
still may not arrive, if the issue is policy, but if it is a backhoe event,
it may very well), but BR-A has no visibility of that. Often, in an edge
network, BR-A and BR-B will not event have a direct route to Pref-C, they
will have default routes leading into the default-free zone.

It seems to me - and if I have this wrong, please correct me and show me how
this works - that in such a case communication is lost between host-B and
host-C, and there is no way for BR-A to realize that it has to advertise
Pref-B to fix it, because everything looks fine from its perspective.

>At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote:
>>What exactly is/are the reason(s) the mult-homed (to different
>>ISPs) routing strategies suggested by RFC 2260 is not widely
>>deployed (or not deployed at all)?
>
>Just a guess, but I would expect that
>
>(a) service providers generally prefer to decide for themselves what 
>routes they will advertise with regard to a customer, and will do that 
>unless given a good monetary reason not to, and
>(b) customers are generally not savvy enough about routing to ask for the 
>ability to advertise a different prefix on demand to the service provider, 
>or to set it up.
>
>This translates as "there is no obvious reason that this would not work, 
>but you have to ask for it, and you have to set it up, and getting BGP 
>configurations right is not easy". The routing exchange between edge 
>networks and their service providers is generally a default route 
>advertised in a common IGP, or simply configured in place, not a routing 
>exchange in BGP.

Date: Wed, 20 Sep 2000 16:30:13 -0500
From: [email-masked]
To: James Tsillas <[email-masked]>
Cc: IDR <[email-masked]>
Subject: Re: question on route propagation
Sender: [email-masked]

Advertising a route with a NH differing from that installed
in the FIB creates some obvious potential loop situations

according to 1771:

      - Routes are stored in the Routing Information Bases (RIBs):
      namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes
      that will be advertised to other BGP speakers must be present in
      the Adj-RIB-Out; routes that will be used by the local BGP speaker
      must be present in the Loc-RIB, and the next hop for each of these
      routes must be present in the local BGP speaker's forwarding
      information base; and routes that are received from other BGP
      speakers are present in the Adj-RIBs-In.

Many vendors seem to advertise only those bgp routes installed
in the rib as best - this can lead to problems when routes
exist in both the IGP and iBGP, even with the same NH.  
I would consider this a bug - the bgp route should be advertised
as long as the NH's are congruent (in order to avoid loop
scenario).

If anyone can think of a reason why this is broken, please
let me know.

IMO:

Implementations should have a switch for both behaviors.

1>  BGP routes should be advertised as long as NH in Loc-RIB
and in IGP are congruent (for strict compliance)

or

2> BGP routes that make it into Loc-RIB should be elligible 
for insertion into Adj-RIB-Out regardless of NH in underlying
protocol (most people have networks designed around BGP 
using this behavior at this point).

my 2c.

	-ed

	--> James Tsillas <[email-masked]> [000920 15:25]:

> What should a peer do when it receives an IBGP update
> which doesn't agree with the IGP next hop? Should it
> still propagate that update to its external peers? How
> about if the next hops agree but the IGP route is still
> preferred?
> 
> -Jim.
> 
> 

-- 
Edward Crabbe
=============
Sr. Network Architect  
Backbone Group
Exodus Communications
-------------
v0x: 408 346 1544

Reply-To: <[email-masked]>
From: "James Tsillas" <[email-masked]>
To: "IDR" <[email-masked]>
Subject: question on route propagation
Date: Wed, 20 Sep 2000 18:36:42 -0400
Importance: Normal
Sender: [email-masked]

What should a peer do when it receives an IBGP update
which doesn't agree with the IGP next hop? Should it
still propagate that update to its external peers? How
about if the next hops agree but the IGP route is still
preferred?

-Jim.

Date: Fri, 15 Sep 2000 01:18:00 -0400
To: BGP mailing list <[email-masked]>
From: "Mark Thompson" <[email-masked]>
Subject: Re: Error Handling in BGP multiprotocol extensions
Sender: [email-masked]

The speaker should ignore the NLRI associated with the attributes and not 
terminate the peer session.

Mark

At 14:17 14/09/00 -0700, Srinivasa Chaganti wrote:
>Hi,
>I have a question regarding Error handling when processing a BGP updates
>with multiprotocol extensions attributes. What should BGP speaker do when it
>receives an update message from a peer with MP_REACH_NLRI and/or
>MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present
>in it. Should the speaker ingnore the NLRI in the attributes or terminate
>the connection. I haven't found an answer for this specific error in RFC
>2858. Thanks in advance for any help.
>
>-Chaganti S.

From: Srinivasa Chaganti <[email-masked]>
To: BGP mailing list <[email-masked]>
Subject: SNPA fields in MP_REACH_NLRI attribute
Date: Mon, 18 Sep 2000 16:41:50 -0700
Sender: [email-masked]

Hi,
can anybody please explain me what for "Subnetwork Points of Attachment"
(SNPA) fields are used carried in MP_REACH_NLRI attribute as given in
RFC2858. For my understanding these fields carry alternative next-hop
information. What these fields should carry in the case of IPv4
unicast/multicast address families.

thanks
Chaganti S.

From: Anoop Ghanwani <[email-masked]>
To: "'Danny McPherson '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: Question on Capability 
Date: Sun, 17 Sep 2000 10:39:21 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C020CE.36A18240
Content-Type: text/plain;
	charset="iso-8859-1"

Just to add to Danny's response...

There are also some cases where the NEXT_HOP self _must_
be used such as cases where the subnet that the NEXT_HOP 
is on is not reachable directly from within the AS.
This can happen if, for instance, the subnet that the
NEXT_HOP is on is not advertised into the IGP, or 
when using ATM/Frame Relay and only a partial mesh is
implemented (i.e. no direct VC exists to the original
NEXT_HOP).

-Anoop

-----Original Message-----
From: Danny McPherson
To: [email-masked]
Sent: 9/16/2000 5:34 PM
Subject: Re: Question on Capability 

> Thanks for the input. But I was wondering, why NEXT_HOP self at
ingress is 
> used rather than proprogating the announced NEXT_HOP as-is?

Several reasons, actually.  

Primarily (IMO) because providers are converned with convergence, and as
such, rely of IGPs for this purpose (providing intra-domain BGP NEXT_HOP
reachability) rather than BGP.  That is, they set NEXT_HOP to self at
the ingress BGP router, with 'self' usually representing a 'loopback'
interface (which typically used as the 'local address' for internal
peerings).  This way, all the external networks need not be present in
the IGP .. and external instability doesn't jeopardize internal network
stability.  

It also enables an implementation to do other clever things, such as
that proposed by Alvaro on this list early this year.

There are many other reasons as well.  For example, when external
subnets are routed throughout the entire domain it's possible (and has
actually been discovered) that the 'unethical types' have the capability
to 'steal' transit services from a network (e.g. employ IP tunneling
across the network between routers on external subnets).  Of course,
most folks still fully route the nertworks in order to provide
diagnostic capabilities.

Etc, etc...

-danny

------_=_NextPart_001_01C020CE.36A18240
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RE: Question on Capability </TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Just to add to Danny's response...</FONT>
</P>

<P><FONT SIZE=2>There are also some cases where the NEXT_HOP self _must_</FONT>
<BR><FONT SIZE=2>be used such as cases where the subnet that the NEXT_HOP </FONT>
<BR><FONT SIZE=2>is on is not reachable directly from within the AS.</FONT>
<BR><FONT SIZE=2>This can happen if, for instance, the subnet that the</FONT>
<BR><FONT SIZE=2>NEXT_HOP is on is not advertised into the IGP, or </FONT>
<BR><FONT SIZE=2>when using ATM/Frame Relay and only a partial mesh is</FONT>
<BR><FONT SIZE=2>implemented (i.e. no direct VC exists to the original</FONT>
<BR><FONT SIZE=2>NEXT_HOP).</FONT>
</P>

<P><FONT SIZE=2>-Anoop</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Danny McPherson</FONT>
<BR><FONT SIZE=2>To: [email-masked]</FONT>
<BR><FONT SIZE=2>Sent: 9/16/2000 5:34 PM</FONT>
<BR><FONT SIZE=2>Subject: Re: Question on Capability </FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; Thanks for the input. But I was wondering, why NEXT_HOP self at</FONT>
<BR><FONT SIZE=2>ingress is </FONT>
<BR><FONT SIZE=2>&gt; used rather than proprogating the announced NEXT_HOP as-is?</FONT>
</P>

<P><FONT SIZE=2>Several reasons, actually.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>Primarily (IMO) because providers are converned with convergence, and as</FONT>
<BR><FONT SIZE=2>such, rely of IGPs for this purpose (providing intra-domain BGP NEXT_HOP</FONT>
<BR><FONT SIZE=2>reachability) rather than BGP.&nbsp; That is, they set NEXT_HOP to self at</FONT>
<BR><FONT SIZE=2>the ingress BGP router, with 'self' usually representing a 'loopback'</FONT>
<BR><FONT SIZE=2>interface (which typically used as the 'local address' for internal</FONT>
<BR><FONT SIZE=2>peerings).&nbsp; This way, all the external networks need not be present in</FONT>
<BR><FONT SIZE=2>the IGP .. and external instability doesn't jeopardize internal network</FONT>
<BR><FONT SIZE=2>stability.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>It also enables an implementation to do other clever things, such as</FONT>
<BR><FONT SIZE=2>that proposed by Alvaro on this list early this year.</FONT>
</P>

<P><FONT SIZE=2>There are many other reasons as well.&nbsp; For example, when external</FONT>
<BR><FONT SIZE=2>subnets are routed throughout the entire domain it's possible (and has</FONT>
<BR><FONT SIZE=2>actually been discovered) that the 'unethical types' have the capability</FONT>
<BR><FONT SIZE=2>to 'steal' transit services from a network (e.g. employ IP tunneling</FONT>
<BR><FONT SIZE=2>across the network between routers on external subnets).&nbsp; Of course,</FONT>
<BR><FONT SIZE=2>most folks still fully route the nertworks in order to provide</FONT>
<BR><FONT SIZE=2>diagnostic capabilities.</FONT>
</P>

<P><FONT SIZE=2>Etc, etc...</FONT>
</P>

<P><FONT SIZE=2>-danny</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C020CE.36A18240--

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Question on Capability 
Date: Sat, 16 Sep 2000 18:34:57 -0600
Sender: [email-masked]

> Thanks for the input. But I was wondering, why NEXT_HOP self at ingress is 
> used rather than proprogating the announced NEXT_HOP as-is?

Several reasons, actually.  

Primarily (IMO) because providers are converned with convergence, and as such, rely of IGPs for this purpose (providing intra-domain BGP NEXT_HOP reachability) rather than BGP.  That is, they set NEXT_HOP to self at the ingress BGP router, with 'self' usually representing a 'loopback' interface (which typically used as the 'local address' for internal peerings).  This way, all the external networks need not be present in the IGP .. and external instability doesn't jeopardize internal network stability.  

It also enables an implementation to do other clever things, such as that proposed by Alvaro on this list early this year.

There are many other reasons as well.  For example, when external subnets are routed throughout the entire domain it's possible (and has actually been discovered) that the 'unethical types' have the capability to 'steal' transit services from a network (e.g. employ IP tunneling across the network between routers on external subnets).  Of course, most folks still fully route the nertworks in order to provide diagnostic capabilities.

Etc, etc...

-danny

From: "vikram idrp" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Question on Capability
Date: Sun, 17 Sep 2000 00:14:11 GMT
Sender: [email-masked]

hello Danny,
Thanks for the input. But I was wondering, why NEXT_HOP self at ingress is 
used rather than proprogating the announced NEXT_HOP as-is?

Vikram

>From: Danny McPherson <[email-masked]>
>Reply-To: [email-masked]
>To: [email-masked]
>Subject: Re: Question on Capability
>Date: Fri, 15 Sep 2000 16:58:10 -0600
>
>
>Though at first it does seem like a nice optimization, typical deployment
>typically does involve employing 'NEXT_HOP self" at the ingress BGP speaker
>within the routing domain.
>
>-danny
>
> > Hello everybody,
> > I have a question about capabilities.
> > Is there a need for having a capability to withdraw routes pertaining to 
>an
> > EBGP peer by sending a withdraw message to all the IBGP peers with just 
>the
> > Next Hop withdrawl. If all the routes associated with a given Next Hop 
>are
> > chained, withdrawl of these routes can be done effectively with just a
> > single entry in the message. However, it should be done, if and only if 
>the
> > IBGP router peering with the EBGP router does not propogate some routes 
>with
> > Next Hop Self.
> > Any thoughts in this direction will be highly appreciated!
>
>
>
>

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

To: BGP mailing list <[email-masked]>
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Error Handling in BGP multiprotocol extensions 
Date: Fri, 15 Sep 2000 17:16:07 -0600
Sender: [email-masked]

Actually, this was a really good question.  I guess it depends on your 
interpretation of the word "incorrect" in RFC 2858 [MBGP], which states the 
following:

  If a BGP speaker receives from a neighbor an Update message that
  contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the
  speaker determines that the attribute is incorrect, the speaker must
  delete all the BGP routes received from that neighbor whose AFI/SAFI
  is the same as the one carried in the incorrect MP_REACH_NLRI or
  MP_UNREACH_NLRI attribute. For the duration of the BGP session over
  which the Update message was received, the speaker then should ignore
  all the subsequent routes with that AFI/SAFI received over that
  session.

As you should never receive MP_REACH_NLRI or MP_UNREACH_NLRI from a neighbor 
describing and AFI or SAFI that wasn't first advertised in Capabilities 
Optional Parameter (and subsequently [implicitly] accepted) by the peer, as 
defined in  RFC 2842 [BGPCAP]:

 A BGP speaker that supports a particular capability may use this
 capability with its peer after the speaker determines (as described
 above) that the peer supports this capability.

As such, it would seem to me that receipt of an UPDATE message that describes 
an AFI or SAFI that wasn't "agreed upon" when the session was established 
should result in NOTIFICATION message being sent to the peer with the Error 
Subcode set to "Unsupported Optional Parameter", as defined in RFC 2842.

Perhaps clarifying the wording in RFC 2842 would be of benefit.  Replacing the 
above with something like:

 A BGP speaker that supports a particular capability MUST NOT use this
 capability until the speaker determines (as described above) that the 
 peer supports this capability.

Perhaps codifying "incorrect" in RFC 2858 would be of benefit as well.

HTH,

-danny

> The speaker should ignore the NLRI associated with the attributes and not 
> terminate the peer session.
> 
> Mark
> 
> At 14:17 14/09/00 -0700, Srinivasa Chaganti wrote:
> >Hi,
> >I have a question regarding Error handling when processing a BGP updates
> >with multiprotocol extensions attributes. What should BGP speaker do when it
> >receives an update message from a peer with MP_REACH_NLRI and/or
> >MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present
> >in it. Should the speaker ingnore the NLRI in the attributes or terminate
> >the connection. I haven't found an answer for this specific error in RFC
> >2858. Thanks in advance for any help.
> >
> >-Chaganti S.
> 
> 

From: Henk Smit <[email-masked]>
Subject: Re: Question on Capability
To: [email-masked]
Date: Fri, 15 Sep 2000 16:02:56 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

  You could make it a combination of the bgp next hop and the first
 ASN in the AS path. Although that would be less useful if an eBGP speaker
 is connected to two external peers in the same AS.

        Henk.

> Though at first it does seem like a nice optimization, typical deployment 
> typically does involve employing 'NEXT_HOP self" at the ingress BGP speaker 
> within the routing domain.
> 
> -danny 
> 
> > Hello everybody,
> > I have a question about capabilities.
> > Is there a need for having a capability to withdraw routes pertaining to an 
> > EBGP peer by sending a withdraw message to all the IBGP peers with just the 
> > Next Hop withdrawl. If all the routes associated with a given Next Hop are 
> > chained, withdrawl of these routes can be done effectively with just a 
> > single entry in the message. However, it should be done, if and only if the 
> > IBGP router peering with the EBGP router does not propogate some routes with 
> > Next Hop Self.
> > Any thoughts in this direction will be highly appreciated!
> 
> 
> 
> 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: Question on Capability 
Date: Fri, 15 Sep 2000 16:58:10 -0600
Sender: [email-masked]

Though at first it does seem like a nice optimization, typical deployment 
typically does involve employing 'NEXT_HOP self" at the ingress BGP speaker 
within the routing domain.

-danny 

> Hello everybody,
> I have a question about capabilities.
> Is there a need for having a capability to withdraw routes pertaining to an 
> EBGP peer by sending a withdraw message to all the IBGP peers with just the 
> Next Hop withdrawl. If all the routes associated with a given Next Hop are 
> chained, withdrawl of these routes can be done effectively with just a 
> single entry in the message. However, it should be done, if and only if the 
> IBGP router peering with the EBGP router does not propogate some routes with 
> Next Hop Self.
> Any thoughts in this direction will be highly appreciated!

From: "vikram idrp" <[email-masked]>
To: [email-masked]
Subject: Question on Capability
Date: Fri, 15 Sep 2000 22:44:28 GMT
Sender: [email-masked]

Hello everybody,
I have a question about capabilities.
Is there a need for having a capability to withdraw routes pertaining to an 
EBGP peer by sending a withdraw message to all the IBGP peers with just the 
Next Hop withdrawl. If all the routes associated with a given Next Hop are 
chained, withdrawl of these routes can be done effectively with just a 
single entry in the message. However, it should be done, if and only if the 
IBGP router peering with the EBGP router does not propogate some routes with 
Next Hop Self.
Any thoughts in this direction will be highly appreciated!

vikram

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.

Share information about yourself, create your own public profile at 
http://profiles.msn.com.

Date: Fri, 15 Sep 2000 09:05:43 -0700
To: Chandrasekar Ramachandran <[email-masked]>
From: Fred Baker <[email-masked]>
Subject: Re: 2260 multi-homing
Cc: [email-masked], [email-masked]
Sender: [email-masked]

At 10:54 PM 9/14/00 -0500, Chandrasekar Ramachandran wrote:
>What exactly is/are the reason(s) the mult-homed (to different
>ISPs) routing strategies suggested by RFC 2260 is not widely
>deployed (or not deployed at all)?

Just a guess, but I would expect that

(a) service providers generally prefer to decide for themselves what routes 
they will advertise with regard to a customer, and will do that unless 
given a good monetary reason not to, and
(b) customers are generally not savvy enough about routing to ask for the 
ability to advertise a different prefix on demand to the service provider, 
or to set it up.

This translates as "there is no obvious reason that this would not work, 
but you have to ask for it, and you have to set it up, and getting BGP 
configurations right is not easy". The routing exchange between edge 
networks and their service providers is generally a default route 
advertised in a common IGP, or simply configured in place, not a routing 
exchange in BGP.

Date: Thu, 14 Sep 2000 22:54:22 -0500
From: Chandrasekar Ramachandran <[email-masked]>
Organization: ITTC, University of Kansas
To: [email-masked]
Cc: [email-masked]
Subject: 2260 multi-homing
Sender: [email-masked]

What exactly is/are the reason(s) the mult-homed (to different
ISPs) routing strategies suggested by RFC 2260 is not widely
deployed (or not deployed at all)?

I think there may be some commercial reasons too for this.

thanks,
Chandra.

Date: Fri, 15 Sep 2000 01:56:21 -0400
To: Srinivasa Chaganti <[email-masked]>
From: "Mark Thompson" <[email-masked]>
Subject: Re: Error Handling in BGP multiprotocol extensions
Cc: BGP mailing list <[email-masked]>
Sender: [email-masked]

The speaker should ignore the NLRI associated with the attributes and not 
terminate the peer session.

Mark

At 14:17 14/09/00 -0700, Srinivasa Chaganti wrote:
>Hi,
>I have a question regarding Error handling when processing a BGP updates
>with multiprotocol extensions attributes. What should BGP speaker do when it
>receives an update message from a peer with MP_REACH_NLRI and/or
>MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present
>in it. Should the speaker ingnore the NLRI in the attributes or terminate
>the connection. I haven't found an answer for this specific error in RFC
>2858. Thanks in advance for any help.
>
>-Chaganti S.

Date: Fri, 15 Sep 2000 01:08:56 -0400
To: "Natale, Jonathan" <[email-masked]>
From: "Mark Thompson" <[email-masked]>
Subject: Re: Split Horrizon
Cc: "Bgp Mail List (E-mail)" <[email-masked]>, "Bgp Ietf Mail List (E-mail)" <[email-masked]>
Sender: [email-masked]

Jonathan

The current spec (not including any multicast attributes) should not allow 
you to re-advertise routes back to the same logical peer (peer IP address). 
The reason being it would break the loop detection mechanism.

For EBGP peers it is effectively a split horizon.

For IBGP peers the rule is do not advertise routes learned from an iBGP 
peer onto a third iBGP peer. This rule forces the requirement for a logical 
full mesh of iBGP peers.

You are able to peer back to and readvertise back to the same physical peer 
but you would require a secondary peer relationship with the router.

Mark

At 17:14 14/09/00 -0400, Natale, Jonathan wrote:
>Is multicast peering supported? Is this what is refered to below? Is there
>any reason why routes learned from a peer should not be advertised back to
>the peer (other than the performance hit)? Is there any advantage to
>advertising learned from a peer back at that peer?
>
>RFC 1771 sec 9.1.3 says:
>For the benefit of future support of inter-AS multicast capabilities, a BGP
>speaker that participates in inter-AS multicast routing shall advertise a
>route it receives from one of its external peers and if it installs it in
>its Loc-RIB, it shall advertise it back to the peer from which the route was
>received. For a BGP speaker that does not participate in inter-AS multicast
>routing such an advertisement is optional. When doing such an advertisement,
>the NEXT_HOP attribute should be set to the address of the peer. An
>implementation may also optimize such an advertisement by truncating
>information in the AS_PATH attribute to include only its own AS number and
>that of the peer that advertised the route (such truncation requires the
>ORIGIN attribute to be set to INCOMPLETE). In addition an implementation is
>not required to pass optional or discretionary path attributes with such an
>advertisement.

Mark Thompson - Nortel Networks EMEA
IP Specialist
Advanced Technical Solutions
Tel :+44 (0)1628 437265
ESN : 560-7265
GSM :+44 (0)7710  876079
mailto:[email-masked]

From: Srinivasa Chaganti <[email-masked]>
To: BGP mailing list <[email-masked]>
Subject: RE: Error Handling in BGP multiprotocol extensions
Date: Thu, 14 Sep 2000 16:56:37 -0700
Sender: [email-masked]

Please read ASI/ASFI as AFI/SAFI in my previous mail. Apologize for the typo
error.

thanks
Chaganti S.

-----Original Message-----
From: Srinivasa Chaganti [mailto:[email-masked]]
Sent: Thursday, September 14, 2000 2:18 PM
To: BGP mailing list
Subject: Error Handling in BGP multiprotocol extensions

Hi,
I have a question regarding Error handling when processing a BGP updates
with multiprotocol extensions attributes. What should BGP speaker do when it
receives an update message from a peer with MP_REACH_NLRI and/or
MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present
in it. Should the speaker ingnore the NLRI in the attributes or terminate
the connection. I haven't found an answer for this specific error in RFC
2858. Thanks in advance for any help.

-Chaganti S.    

From: "Natale, Jonathan" <[email-masked]>
To: "Bgp Mail List (E-mail)" <[email-masked]>, "Bgp Ietf Mail List (E-mail)" <[email-masked]>
Subject: Split Horrizon
Date: Thu, 14 Sep 2000 17:14:39 -0400
Sender: [email-masked]

Is multicast peering supported? Is this what is refered to below? Is there
any reason why routes learned from a peer should not be advertised back to
the peer (other than the performance hit)? Is there any advantage to
advertising learned from a peer back at that peer?

RFC 1771 sec 9.1.3 says:
For the benefit of future support of inter-AS multicast capabilities, a BGP
speaker that participates in inter-AS multicast routing shall advertise a
route it receives from one of its external peers and if it installs it in
its Loc-RIB, it shall advertise it back to the peer from which the route was
received. For a BGP speaker that does not participate in inter-AS multicast
routing such an advertisement is optional. When doing such an advertisement,
the NEXT_HOP attribute should be set to the address of the peer. An
implementation may also optimize such an advertisement by truncating
information in the AS_PATH attribute to include only its own AS number and
that of the peer that advertised the route (such truncation requires the
ORIGIN attribute to be set to INCOMPLETE). In addition an implementation is
not required to pass optional or discretionary path attributes with such an
advertisement. 

From: Srinivasa Chaganti <[email-masked]>
To: BGP mailing list <[email-masked]>
Subject: Error Handling in BGP multiprotocol extensions
Date: Thu, 14 Sep 2000 14:17:50 -0700
Sender: [email-masked]

Hi,
I have a question regarding Error handling when processing a BGP updates
with multiprotocol extensions attributes. What should BGP speaker do when it
receives an update message from a peer with MP_REACH_NLRI and/or
MP_UNREACH_NLRI attributes and unsupported (or unkown) ASI/ASFI are present
in it. Should the speaker ingnore the NLRI in the attributes or terminate
the connection. I haven't found an answer for this specific error in RFC
2858. Thanks in advance for any help.

-Chaganti S.    

From: "Peter Lewis" <[email-masked]>
To: <[email-masked]>
Subject: IP over DWDM 2000 international conference
Date: Thu, 14 Sep 2000 11:12:41 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_004A_01C01E3C.B2C06C40
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

IP over DWDM 2000 international conference, Paris 27-30 November :

This event aims at presenting an up-to-date state of the art in the =
design of new Internet network architectures. It will be a unique =
opportunity for researchers, network operators and service providers =
from both the IP world and the optical networking world to discuss the =
potentialities of all these promising perspectives.=20

http://www.upperside.fr/badwdm.htm

------=_NextPart_000_004A_01C01E3C.B2C06C40
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT face=3DArial size=3D2>
<DIV>IP over DWDM 2000 international conference, Paris 27-30 November =
:</DIV>
<DIV>&nbsp;</DIV>
<DIV>This event aims at presenting an up-to-date state of the art in the =
design=20
of new Internet network architectures. It will be a unique opportunity =
for=20
researchers, network operators and service providers from both the IP =
world and=20
the optical networking world to discuss the potentialities of all these=20
promising perspectives. </DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/badwdm.htm">http://www.upperside.fr/badwd=
m.htm</A></FONT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_004A_01C01E3C.B2C06C40--

Date: Tue, 12 Sep 2000 09:24:38 -0400
To: Anoop Ghanwani <[email-masked]>
From: "Mark Thompson" <[email-masked]>
Subject: Re: RFC 1772
Cc: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

--=====================_1502617==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

No.

Try ftp://ftp.isi.edu/in-notes/rfc1772.txt

At 16:27 11/09/00 -0700, Anoop Ghanwani wrote:

>Has RFC 1772 been obsoleted by something else?  I couldn't
>find it in the list of RFCs on the IDR WG page.  -Anoop

--=====================_1502617==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<br>
No.<br>
<br>
Try
<a href="ftp://ftp.isi.edu/in-notes/rfc1772.txt" eudora="autourl">ftp://ftp.isi.edu/in-notes/rfc1772.</a><a href="ftp://ftp.isi.edu/in-notes/rfc1772.txt" eudora="autourl">txt<br>
<br>
</a>At 16:27 11/09/00 -0700, Anoop Ghanwani wrote:<br>
<br>
<font size=2><blockquote type=cite cite>Has RFC 1772 been obsoleted by
something else?&nbsp; I couldn't</font> <br>
<font size=2>find it in the list of RFCs on the IDR WG page.&nbsp;
-Anoop</font> </blockquote></html>

--=====================_1502617==_.ALT--

From: Anoop Ghanwani <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RFC 1772
Date: Mon, 11 Sep 2000 16:27:36 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C01C47.DE2200C0
Content-Type: text/plain;
	charset="iso-8859-1"

Has RFC 1772 been obsoleted by something else?  I couldn't
find it in the list of RFCs on the IDR WG page.  -Anoop

------_=_NextPart_001_01C01C47.DE2200C0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>RFC 1772</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>Has RFC 1772 been obsoleted by something else?&nbsp; I couldn't</FONT>
<BR><FONT SIZE=2>find it in the list of RFCs on the IDR WG page.&nbsp; -Anoop</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C01C47.DE2200C0--

From: George Matey <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: BGP Confederations
Date: Fri, 8 Sep 2000 17:28:43 -0400 
Sender: [email-masked]

Danny,

First,  I'm glad to see the banner was picked up, so this
can progress to standards track.  Thanks!

Regarding your poll, I fully expected an updated spec to
simply reverse the values.  I would rather have that then
require a knob to accommodate both scenarios ('historic' and
'updated' confederation formatting); that would serve no
useful purpose.

--
George

> -----Original Message-----
> From: Danny McPherson [mailto:[email-masked]]
> Sent: Friday, September 08, 2000 5:13 PM
> To: [email-masked]
> Subject: BGP Confederations
> 
> 
> 
> Folks,
> I'm updating the BGP Confederations spec and had a question.  
> It seems as 
> though the original code points:
> 
> Value  Segment Type
> 
>   3    AS_CONFED_SET: unordered set of ASs in the local
>        confederation that the UPDATE message has traversed
> 
>   4    AS_CONFED_SEQUENCE: ordered set of ASs in the local 
>        confederation that the UPDATE message has traversed
> 
> 
> specified in RFC 1965 were actually implemented backwards (3 = 
> AS_CONFED_SEQUENCE and 4 = AS_CONFED_SET) by several vendors, 
> and as such, 
> many newer implementations have realized this and implemented 
> them backwards 
> from RFC 1965 as well.
> 
> That being the case, I was planning to change them in the 
> upcoming revision 
> but first wanted to take a poll and see what folks feelings 
> were on this?
> 
> On a related note, I'm reviewing the archives to find other 
> bugs in the 
> current version, but if you're aware of any off the top of 
> your ahead please 
> do let me know.
> 
> Thanks!
> 
> -danny  
> 
> 

Date: Fri, 08 Sep 2000 14:22:29 -0700
From: Kunihiro Ishiguro <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: BGP Confederations
Sender: [email-masked]

>specified in RFC 1965 were actually implemented backwards (3 = 
>AS_CONFED_SEQUENCE and 4 = AS_CONFED_SET) by several vendors, and as such, 
>many newer implementations have realized this and implemented them backwards 
>from RFC 1965 as well.

I also use below definition in Zebra's source code.  It is hard to
change deployed routers to follow RFC1965 value.

#define AS_CONFED_SEQUENCE 3
#define AS_CONFED_SET      4

I think it is good think to revise RFC to deployed value.
-- 
Kunihiro Ishiguro

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: BGP Confederations
Date: Fri, 08 Sep 2000 15:12:43 -0600
Sender: [email-masked]

Folks,
I'm updating the BGP Confederations spec and had a question.  It seems as 
though the original code points:

Value  Segment Type

  3    AS_CONFED_SET: unordered set of ASs in the local
       confederation that the UPDATE message has traversed

  4    AS_CONFED_SEQUENCE: ordered set of ASs in the local 
       confederation that the UPDATE message has traversed

specified in RFC 1965 were actually implemented backwards (3 = 
AS_CONFED_SEQUENCE and 4 = AS_CONFED_SET) by several vendors, and as such, 
many newer implementations have realized this and implemented them backwards 
from RFC 1965 as well.

That being the case, I was planning to change them in the upcoming revision 
but first wanted to take a poll and see what folks feelings were on this?

On a related note, I'm reviewing the archives to find other bugs in the 
current version, but if you're aware of any off the top of your ahead please 
do let me know.

Thanks!

-danny  

To: Enke Chen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-chen-bgp-route-filter-01.txt 
Date: Tue, 05 Sep 2000 09:05:34 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Enke,

> Hi, Yakov and Sue:
> I would like to request that the draft be considered as an IDR working
> group document.

Since we didn't hear any objections, this Internet Draft is now accepted
as an IDR WG document.

Yakov.