Subject: Re: Update send process
From: Bradley Reynolds <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Date: Fri, 1 Oct 1999 02:23:37 +0000 (GMT)

> I thought that it was pretty clear that "use" means "use for 
> forwarding."  Perhaps the spec *does* need clarification after all. 
> (Yakov, how about changing the quoted sentence above to end "...uses 
> for forwarding"?)
> 
yes, this interp of use is found somewhere else in the document.

> >route use from the id would seem to mean installation in the Loc-RIB.
> >Loc-RIB != router RIB.  and from router RIB we derive FIB.
> 
> "Router RIB" isn't a term of art I'm familiar with, and it's 
> certainly not used in the BGP spec.  For my part, my working 
> definition of Loc-RIB is "the thing I derive my FIB from."
> 

ok.  there is a subtle and perhaps worthless difference.  Loc-RIB from the 
draft is what you get after applying policy/selection to adj-rib-ins and
local information.  cisco says 'once path is selected, it is installed in
the routing table'; however, this is not quite the case.  i believe that
once the path is selected it is installed in the routing table only iff:

1.  no route currently exists

or 

2.  the route that currently exists was installed by BGP.  

so, if you currently have a static sitting in the routing table, the route
selected by BGP will not get installed. you will still have a route, but
it will be installed by some other protocol.  thus, the loc-rib is not a
subset of this 'router RIB'.

BR  

Date: Thu, 30 Sep 1999 21:57:48 -0400
To: Bradley Reynolds <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: Update send process
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

At 9:46 PM +0000 9/30/99, Bradley Reynolds wrote:
...
>   To characterize the set of policy decisions that can be enforced
>   using BGP, one must focus on the rule that a BGP speaker advertise to
>   its peers (other BGP speakers which it communicates with) in
>   neighboring ASs only those routes that it itself uses.
>
>Now, you have to interpret what route use means.

I thought that it was pretty clear that "use" means "use for 
forwarding."  Perhaps the spec *does* need clarification after all. 
(Yakov, how about changing the quoted sentence above to end "...uses 
for forwarding"?)

>route use from the id would seem to mean installation in the Loc-RIB.
>Loc-RIB != router RIB.  and from router RIB we derive FIB.

"Router RIB" isn't a term of art I'm familiar with, and it's 
certainly not used in the BGP spec.  For my part, my working 
definition of Loc-RIB is "the thing I derive my FIB from."

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

Date: Thu, 30 Sep 1999 22:05:21 -0400
To: Ben Abarbanel <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: Update send process
Cc: James B <[email-masked]>, [email-masked]
Sender: [email-masked]

At 5:24 PM -0400 9/30/99, Ben Abarbanel wrote:
>It sounds to me like what you and Yakov are saying is that if you define
>static routes and you run BGP, you better make sure the static route is
>redistributed to BGP. So it can cancel out the dynamic route to the same
>prefix.

Not quite.  I'm saying that if you define static routes and you run 
BGP, and if a static route overrides a BGP-learned route, then you 
should not advertise the BGP-learned route since you are not using it 
for forwarding.  It's (as they say) a matter of local policy whether 
you advertise the static route via BGP or not.  Always exporting 
static to BGP would be one way of doing it, but certainly not the 
only way.

>Is it possible to have a transit AS relay BGP routes from one AS to the next,
>and yet still have locally defined and used static routes that could (in the
>transit AS only) override the relayed BGP routes to the same prefix?

Not with a per-spec BGP implementation, no.  (Yes, there are endless 
variations on this that would be more or less legal if you squint at 
the spec really hard, but the straightforward answer is just "no.")

Regards,

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

Date: Thu, 30 Sep 1999 21:55:28 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Update send process
Sender: [email-masked]

> you could have a situation like this:
> 
> null0 hold on 10.0.0.0/8
> 
> igp carrying reachability internal to the AS for 10.0.0.0/8 to some
> other pop.  
> 
this example doesn't illustrate the problem :)

BR

Date: Thu, 30 Sep 1999 21:46:23 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Update send process
Sender: [email-masked]

On Thu, 30 Sep 1999, John G. Scudder wrote:

> Easiest fix I've ever seen.  Thanks.  That also clears up the answer 
> to the previous question.  (The correct answer is "no.")
> 
not necessarily.. it said this:
  
   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertise to
   its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses.
  
Now, you have to interpret what route use means.
  
route use from the id would seem to mean installation in the Loc-RIB.
Loc-RIB != router RIB.  and from router RIB we derive FIB.      
  
if route use means being installed in the loc-rib, then that would be a
'yes' to the question about whether the BGP selected path should be
readvertised in the event that it was superceded in precedence by the 
some other route in the router RIB.
  
you could have a situation like this:

null0 hold on 10.0.0.0/8

igp carrying reachability internal to the AS for 10.0.0.0/8 to some
other pop.  

BR          

From: "James B" <[email-masked]>
To: [email-masked]
Subject: Re: Update send process
Date: Thu, 30 Sep 1999 13:36:41 PDT
Sender: [email-masked]

Thanks. That clears up some of the confusion I had. However, one minor issue 
remains. And that is, the paragraph below is explicit about only advertising 
routes that a router is using, to neighboring EBGP peers. Is there any 
reason for not including IBGP peers in this?

Thanks

-Sanjay

>
>It is already there:
>
>    To characterize the set of policy decisions that can be enforced
>    using BGP, one must focus on the rule that a BGP speaker advertise to
>    its peers (other BGP speakers which it communicates with) in
>    neighboring ASs only those routes that it itself uses.
>
>Yakov.
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Thu, 30 Sep 1999 16:29:32 -0400
To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: Update send process
Cc: [email-masked]
Sender: [email-masked]

At 1:22 PM -0700 9/30/99, Yakov Rekhter wrote:
>It is already there:

Easiest fix I've ever seen.  Thanks.  That also clears up the answer 
to the previous question.  (The correct answer is "no.")

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

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Subject: Re: Update send process 
Date: Thu, 30 Sep 1999 13:22:38 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

John,

[clipped...]

> I'd be in favor of updating the I-D to say that you mustn't (or at least
> shouldn't) advertise a route which you are not using for forwarding.

It is already there:

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertise to
   its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses. 

Yakov.

From: "John G. Scudder" <[email-masked]>
Subject: Re: Update send process
To: [email-masked] (James B)
Date: Thu, 30 Sep 1999 16:02:47 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]

James B (or is it Sanjay?) wrote:
...
> In such a scenario, the static route will be 
> used for forwarding. However, if the static route is not redistributed,
> should the BGP route get readvertised to internal/external nbrs?

With a quick skim of the I-D I didn't find any verbiage thad said "no."
However, doing so is, at best, a matter of poor taste.  (Which isn't to
say that some implementations won't do so anyway.)

If you advertise a route you're not using for forwarding, the path
attributes will be wrong.  However, having extra ASes in the path doesn't
violate the loop-free property.  Only removing ASes would do that.

If you advertise a route you're not using for forwarding, you also
risk forming forwarding loops (not routing information loops).  This is
clearly a Bad Thing.  Of course, it's trivially easy to form forwarding
loops with static routes anyway, but at least you have to screw up *two*
routers in order for it to happen.

I'd be in favor of updating the I-D to say that you mustn't (or at least
shouldn't) advertise a route which you are not using for forwarding.
(Those whose implementations do so may disagree; ideally I would like
to hear arguments from them as to why advertising such a route is safe,
or failing that, some other compelling argument why it is a good idea
anyway.)

Editors?

--John

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

Date: Thu, 30 Sep 1999 09:33:17 -0400
From: "Ramana V Gollamudi" <[email-masked]>
Organization: Newbridge Networks
To: [email-masked]
Subject: Question on bgp4-09 draft
Sender: [email-masked]

I have a question on section 3 paragraph 4 of
draft-ietf-idr-bgp4-09.txt. In a similar place in RFC 1771 there is
statement as follows "Using a common set of policies, the BGP speakers
arrive at an agreement as to which border routers will serve as
exit/entry points for particular destinations outside the AS". This
draft does not include such a statement.  I am curious to know the
reasons for the removal of this statement and what are the implications.

I was told that the designers of BGP4 considered it important that all
routers in an AS advertise the same route to a destination to their
external peers. I am not sure if this was really a requirement but if it
was, is it no longer needed? Second, does the lack of such a statement
imply that if different eBGP speakers in an AS choose different exit
points for a given destination there are no problems? Or is this stated
somewhere else that I missed?

Thanks,

Ramana

Date: Wed, 29 Sep 1999 20:51:55 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: Micah Bartell <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: question or origin
Sender: [email-masked]

> Sean,
> 
> 
> If you are redistributing from an IGP protocol ( ospf/isis/static etc
> ), then the route is entering bgp from an IGP ( obviously ).  Hence it
> satisfies the requirement to be automatically tagged with the IGP
> Origin.  Which is that the route is interior to the originating AS.  
> Any particular mechanism that will give you the ability to bring only
> interior routes into BGP would be candidates for automatically setting
> the IGP origin.  The Incomplete attribute would be used if there is
> the possibility of ambiguity in regards to the source of the route.
> 
i think you are getting the term IGP from the draft confused with the
common definition of IGP.  

note that the snippet says:  

---
ORIGIN is a well-known mandatory attribute that defines the
            origin of the path information.   
---

from the current id section 5.1.1 we see:

---
   ORIGIN is a well-known mandatory attribute.  The ORIGIN attribute
   shall be generated by the autonomous system that originates the
   associated routing information. It shall be included in the UPDATE
   messages of all BGP speakers that choose to propagate this
   information to other BGP speakers.
---

so only set this when the path is internal to your AS.  on the originator
of this path, check for the reachability of the path.  if the nlri 
is known to bgp (i.e. this was injected via 'network' command) then
set origin to IGP, if it is injected from some other routing protocol
(i.e. static, ospf etc) then you are not certain as to the path
origin and it is set to incomplete.

also, make sure to look at the current ID and not some old RFC

BR

> /mpb
> 
> 
> 
> 
> At 11:48 AM 9/29/1999 -0400, [email-masked] wrote:
> 
> 
> 
> 
> >RFC 1654 has the following description for the
> >ORIGIN code:
> >
> > >a)   ORIGIN (Type Code 1):
> > >
> > >      ORIGIN is a well-known mandatory attribute that defines the
> > >      origin of the path information.   The data octet can assume
> > >      the following values:
> > >
> > >
> > >            Value      Meaning
> > >
> > >            0         IGP - Network Layer Reachability Information
> > >                      is interior to the originating AS
> > >
> > >            1         EGP - Network Layer Reachability Information
> > >                      learned via EGP
> > >
> > >            2         INCOMPLETE - Network Layer Reachability
> > >                      Information learned by some other means
> >
> >
> >If a route is redistributed from another protocol, such as
> >static, OSPF, etc, into BGP, what should the origin of the
> >route be?   IGP or incomplete?
> >
> >It seems like different vendors are interpreting this in
> >different ways.
> >
> >Thanks,
> >Sean
> >___________________________________
> >Sean Butler, CCIE #3897
> >AT&T Global Services -- OpenNet Support
> >Phone: 727-533-8830
> >Fax:       813-878-5475
> >Internet email:  [email-masked]
> 
> 
> --
> Micah Bartell, CCIE #5069			[email-masked]
> Network Consulting Engineer, NSA		Phone: 972.364.8829
> Cisco Systems, Inc				Fax: 972.364.8829
> --
> The Network Works, No Excuses
> 

Date: Wed, 29 Sep 1999 12:00:23 -0500
To: [email-masked], [email-masked]
From: Micah Bartell <[email-masked]>
Subject: Re: question or origin
Sender: [email-masked]

Sean,

If you are redistributing from an IGP protocol ( ospf/isis/static etc ), then the
route is entering bgp from an IGP ( obviously ).  Hence it satisfies the 
requirement to be automatically tagged with the IGP Origin.  Which is that
the route is interior to the originating AS.  Any particular mechanism that will
give you the ability to bring only interior routes into BGP would be candidates
for automatically setting the IGP origin.  The Incomplete attribute would be used
if there is the possibility of ambiguity in regards to the source of the
route.

/mpb

At 11:48 AM 9/29/1999 -0400, [email-masked] wrote:

>RFC 1654 has the following description for the
>ORIGIN code:
>
> >a)   ORIGIN (Type Code 1):
> >
> >      ORIGIN is a well-known mandatory attribute that defines the
> >      origin of the path information.   The data octet can assume
> >      the following values:
> >
> >
> >            Value      Meaning
> >
> >            0         IGP - Network Layer Reachability Information
> >                      is interior to the originating AS
> >
> >            1         EGP - Network Layer Reachability Information
> >                      learned via EGP
> >
> >            2         INCOMPLETE - Network Layer Reachability
> >                      Information learned by some other means
>
>
>If a route is redistributed from another protocol, such as
>static, OSPF, etc, into BGP, what should the origin of the
>route be?   IGP or incomplete?
>
>It seems like different vendors are interpreting this in
>different ways.
>
>Thanks,
>Sean
>___________________________________
>Sean Butler, CCIE #3897
>AT&T Global Services -- OpenNet Support
>Phone: 727-533-8830
>Fax:       813-878-5475
>Internet email:  [email-masked]

--
Micah Bartell, CCIE #5069			[email-masked]
Network Consulting Engineer, NSA		Phone: 972.364.8829
Cisco Systems, Inc				Fax: 972.364.8829
--
The Network Works, No Excuses

From: [email-masked]
To: [email-masked]
Date: Wed, 29 Sep 1999 11:48:25 -0400
Subject: question or origin
Sender: [email-masked]

RFC 1654 has the following description for the
ORIGIN code:

>a)   ORIGIN (Type Code 1):
>
>      ORIGIN is a well-known mandatory attribute that defines the
>      origin of the path information.   The data octet can assume
>      the following values:
>
>
>            Value      Meaning
>
>            0         IGP - Network Layer Reachability Information
>                      is interior to the originating AS
>
>            1         EGP - Network Layer Reachability Information
>                      learned via EGP
>
>            2         INCOMPLETE - Network Layer Reachability
>                      Information learned by some other means

If a route is redistributed from another protocol, such as
static, OSPF, etc, into BGP, what should the origin of the
route be?   IGP or incomplete?

It seems like different vendors are interpreting this in
different ways.

Thanks,
Sean
___________________________________
Sean Butler, CCIE #3897
AT&T Global Services -- OpenNet Support
Phone: 727-533-8830
Fax:       813-878-5475
Internet email:  [email-masked]

Date: Wed, 15 Sep 1999 06:53:52 -0400 (EDT)
From: Susan Hares <[email-masked]>
To: [email-masked]
Subject: forwarding ietf drafts information
Sender: [email-masked]

From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-route-reflect-v2-02.txt
Date: Thu, 09 Sep 1999 06:56:03 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: BGP Route Reflection An alternative to full mesh IBGP
	Author(s)	: T. Bates,  R. Chandra,  E. Chen
	Filename	: draft-ietf-idr-route-reflect-v2-02.txt
	Pages		: 10
	Date		: 08-Sep-99
	
The Border Gateway Protocol [1] is an inter-autonomous system routing
protocol designed for TCP/IP internets. Currently in the Internet BGP
deployments are configured such that that all BGP speakers within a
single AS must be fully meshed so that any external routing
information must be re-distributed to all other routers within that
AS. This represents a serious scaling problem that has been  well
documented with several alternatives proposed [2,3].
This document describes the use and design of a method known as
'Route Reflection' to alleviate the the need for 'full mesh' IBGP.
This document describes the use and design of a method known as
'Route Reflection' to alleviate the the need for 'full mesh' IBGP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-reflect-v2-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-route-reflect-v2-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-route-reflect-v2-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-reflect-v2-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-route-reflect-v2-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 15 Sep 1999 06:52:24 -0400 (EDT)
From: Susan Hares <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: forwarding non-member query
Sender: [email-masked]

>From [email-masked]  Sat Sep  4 16:38:09 1999
Date: Sat, 4 Sep 1999 16:31:39 -0400 (EDT)
From: Bradley Reynolds <[email-masked]>
To: Naveen Seth <[email-masked]>
Cc: [email-masked]
 Subject: Re: Query: Overlapping routes.

On Sat, 4 Sep 1999, Naveen Seth wrote:

> Hi, 
> I have certain queries regarding overlapping routes in BGP-4.
> 
> 1. If a more specific route exists in the Adj_RIB_In as well as
> Loc_RIB and a less specific route arrives in the same Adj_RIB_In, then
> what action will BGP-4 take?
> 
if there is no route in the adj_rib_in matching the new route,
it is installed in the loc_rib.  

9.1.2 in the current id illustrates this.

BR

From: "Chantal Ladouce" <[email-masked]>
To: "chantal" <[email-masked]>
Subject: From Firewall to IPSec VPNs
Date: Tue, 14 Sep 1999 12:26:36 +0200
Organization: upperside

This is a multi-part message in MIME format.

------=_NextPart_000_0072_01BEFEAC.637FC320
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Security services and protection mechanisms
IPv6 promises regarding IPSec
Certification infrastructure
Standardization update
Case Studies: ISPs, carriers, private networks
AH and ESP protocols description
Possible future extensions and modifications of the IKE protocol
Complementarity between IPSec and firewalls
Global Site-to-Site IPSec VPN's with End-to-End SLA's
Managing widespread IPSEC virtual private networks
Solving IPSec VPNs scalability
Results of some interoperability tests
IPSec architectures and non-standardized aspects of IPSec
Adding IPSec VPN functions in an existing router network
Impact of fragmentation on the performance of IPSec coding

IPSEC 99 Conference
>From Firewall to IPSec VPNs

October 26, 27, 28, 29, 1999
Paris - France

More infos: www.upperside.fr/baipsec.htm

------=_NextPart_000_0072_01BEFEAC.637FC320
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>
<DIV><FONT size=3D2>Security services and protection mechanisms<BR>IPv6 =
promises=20
regarding IPSec<BR>Certification infrastructure<BR>Standardization=20
update<BR>Case Studies: ISPs, carriers, private networks<BR>AH and ESP =
protocols=20
description<BR>Possible future extensions and modifications of the IKE=20
protocol<BR>Complementarity between IPSec and firewalls<BR>Global =
Site-to-Site=20
IPSec VPN's with End-to-End SLA's<BR>Managing widespread IPSEC virtual =
private=20
networks<BR>Solving IPSec VPNs scalability<BR>Results of some =
interoperability=20
tests<BR>IPSec architectures and non-standardized aspects of =
IPSec<BR>Adding=20
IPSec VPN functions in an existing router network<BR>Impact of =
fragmentation on=20
the performance of IPSec coding<BR><BR>IPSEC 99 Conference<BR>From =
Firewall to=20
IPSec VPNs<BR><BR>October 26, 27, 28, 29, 1999<BR>Paris - =
France<BR><BR>More=20
infos: <A=20
href=3D"http://www.upperside.fr/baipsec.htm">www.upperside.fr/baipsec.htm=
</A></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV>
<DIV>&nbsp;</DIV></FONT></DIV></FONT></DIV></FONT></DIV></FONT></DIV></FO=
NT></DIV></FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0072_01BEFEAC.637FC320--

From: "Peter lewis" <[email-masked]>
To: <[email-masked]>
Subject: QoS Summit
Date: Thu, 9 Sep 1999 17:49:37 +0200
Sender: [email-masked]

QoS Summit: key requirements for advanced applications running on future
networks. Technologies (MPLS, ATM, IntSev/DiffServ, Frame Relay).
Managing, policing, billing, charging QoS. The annual rendez-vous with
top senior specialists.
Paris, France, 16-19 November 1999

Please see details at the following web address:
http://www.upperside.fr/baqos.htm

Date: Wed, 08 Sep 1999 09:42:16 +0530
From: Sumit Garg <[email-masked]>
Organization: Ficon Technology
To: Naveen Seth <[email-masked]>
Cc: [email-masked], Sumit Garg <[email-masked]>
Subject: Re: Query: BGP-4 Connection Collision
Sender: [email-masked]

> Naveen Seth wrote:
> 
> Hi
> I have a query regarding Connection Collision and Resolution in BGP-4.
> 
> Whenever connection collision takes place, the BGP retains one of the
> connections, closes the other one and sends a Notification Message
> with the Error Code set to cease.
> The rfc-1771 also states that whenever a Notification message is
> received, the system changes its state to Idle.
> 
> Won't there be a contradiction in terms of the Finite State Machine
> model for BGP-4?
> 
> How should the system handle the receiving of a Notification Message
> with the Error Code Cease in case a Connection Collision has taken
> place?
> 
> Looking forward to a reply...
> Naveen

Hi,

Well there is no conradiction really. There are two connections. FSM for
one transitions to IDLE. The other connection continues with the FSM in
the OPEN SENT/ OPEN RECVD states. Hope this helps and clarifies ...

Regards
-- 
_________________________________
Sumit Garg
Ficon Technology
E-mail :  [email-masked]
Web    :  http://www.ficon-tech.com

From: "Naveen Seth" <[email-masked]>
To: <[email-masked]>
Subject: Query: BGP-4 Connection Collision
Date: Tue, 7 Sep 1999 19:15:20 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_00B3_01BEF965.53C4C490
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi
I have a query regarding Connection Collision and Resolution in BGP-4.

Whenever connection collision takes place, the BGP retains one of the =
connections, closes the other one and sends a Notification Message with =
the Error Code set to cease.
The rfc-1771 also states that whenever a Notification message is =
received, the system changes its state to Idle.

Won't there be a contradiction in terms of the Finite State Machine =
model for BGP-4?

How should the system handle the receiving of a Notification Message =
with the Error Code Cease in case a Connection Collision has taken =
place?

Looking forward to a reply...
Naveen

------=_NextPart_000_00B3_01BEF965.53C4C490
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000>Hi</FONT></DIV>
<DIV><FONT color=3D#000000></FONT>I have a query regarding Connection =
Collision=20
and Resolution in BGP-4.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Whenever connection collision takes place, the BGP retains one of =
the=20
connections, closes the other one and sends a Notification Message with =
the=20
Error Code set to cease.</DIV>
<DIV>The rfc-1771 also states that whenever a Notification message is =
received,=20
the system changes its state to Idle.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Won't there be a contradiction in terms of the Finite State Machine =
model=20
for BGP-4?</DIV>
<DIV>&nbsp;</DIV>
<DIV>How should the system handle the receiving of a Notification =
Message with=20
the Error Code Cease in case a Connection Collision has taken =
place?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Looking forward to a reply...</DIV>
<DIV><FONT color=3D#000000>Naveen</FONT></DIV></BODY></HTML>

------=_NextPart_000_00B3_01BEF965.53C4C490--

Date: Sat, 4 Sep 1999 21:18:36 -0700
From: Ben Black <[email-masked]>
To: Naveen Seth <[email-masked]>
Cc: [email-masked]
Subject: Re: Query: Overlapping routes.
Sender: [email-masked]

Both routes will be installed in Loc_RIB (assuming there are no other
networks with the same prefix and length).  There is no conflict.

On Sat, Sep 04, 1999 at 11:23:43AM +0100, Naveen Seth wrote:
> Hi, 
> I have certain queries regarding overlapping routes in BGP-4.
> 
> 1. If a more specific route exists in the Adj_RIB_In as well as Loc_RIB and a less specific route arrives in the same Adj_RIB_In, then what action will BGP-4 take?
> 
> Naveen

-- 
 --b

From: "Naveen Seth" <[email-masked]>
To: <[email-masked]>
Subject: Query: Overlapping routes.
Date: Sat, 4 Sep 1999 11:23:43 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01BEF6C7.F27FF730
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,=20
I have certain queries regarding overlapping routes in BGP-4.

1. If a more specific route exists in the Adj_RIB_In as well as Loc_RIB =
and a less specific route arrives in the same Adj_RIB_In, then what =
action will BGP-4 take?

Naveen

------=_NextPart_000_0038_01BEF6C7.F27FF730
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000>Hi, </FONT></DIV>
<DIV><FONT color=3D#000000></FONT>I have certain queries regarding =
overlapping=20
routes in BGP-4.</DIV>
<DIV>&nbsp;</DIV>
<DIV>1. If a more specific route exists in the Adj_RIB_In as well as =
Loc_RIB and=20
a less specific route arrives in the same Adj_RIB_In, then what action =
will=20
BGP-4 take?</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000>Naveen</FONT></DIV></BODY></HTML>

------=_NextPart_000_0038_01BEF6C7.F27FF730--

Date: Thu, 2 Sep 1999 08:25:10 -0400 (EDT)
From: Susan Hares <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [[email-masked]]    (fwd)
Sender: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-multiprotocol-v2-03.txt
Date: Thu, 02 Sep 1999 07:07:45 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Multiprotocol Extensions for BGP-4
	Author(s)	: T. Bates, R. Chandra, D. Katz, Y. Rekhter
	Filename	: draft-ietf-idr-bgp4-multiprotocol-v2-03.txt
	Pages		: 10
	Date		: 01-Sep-99
	
Currently BGP-4 [BGP-4] is capable of carrying routing information
only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
enable it to carry routing information for multiple Network Layer
protocols (e.g., IPv6, IPX, etc...). The extensions are backward
compatible - a router that supports the extensions can interoperate
with a router that doesn't support the extensions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-multiprotocol-v2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-multiprotocol-v2-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-multiprotocol-v2-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 2 Sep 1999 08:24:28 -0400 (EDT)
From: Susan Hares <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [[email-masked]]    (fwd)
Sender: [email-masked]

	by segue.merit.edu (Postfix) with ESMTP id E8A0C4440C
	for <[email-masked]>; Thu,  2 Sep 1999 07:07:40 -0400 (EDT)
To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-cap-neg-04.txt
Date: Thu, 02 Sep 1999 07:07:38 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: Capabilities Negotiation with BGP-4
	Author(s)	: R. Chandra, J. Scudder
	Filename	: draft-ietf-idr-bgp4-cap-neg-04.txt
	Pages		: 4
	Date		: 01-Sep-99
	
Currently BGP-4 [BGP-4] requires that when a BGP speaker receives an
OPEN message with one or more unrecognized Optional Parameters, the
speaker must terminate BGP peering. This complicates introduction of
new capabilities in BGP.
This document defines new Optional Parameter, called Capabilities,
that is expected to facilitate introduction of new capabilities in
BGP by providing graceful capability negotiation without requiring
that BGP peering be terminated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-cap-neg-04.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-cap-neg-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-cap-neg-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-cap-neg-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 2 Sep 1999 08:24:13 -0400 (EDT)
From: Susan Hares <[email-masked]>
To: [email-masked]
Sender: [email-masked]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-09.txt
Date: Thu, 02 Sep 1999 07:07:25 -0400
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, T. Li
	Filename	: draft-ietf-idr-bgp4-09.txt
	Pages		: 60
	Date		: 01-Sep-99
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.  It is built on experience gained with EGP as
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
described in RFC 1092 [2] and RFC 1093 [3].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-09.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-09.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-09.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-09.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--