Subject: [Idr] draft-chen-bgp-group-path-update-00.txt

From: Enke Chen <[email-masked]>
Date: Tue, 29 Jun 2004 11:06:16 -0700

Hi, folks:

Here is another attempt to tackle the issue of persistent IBGP
route oscillation. Please let us know if you have any comments
on the draft.

Thanks.  -- Enke

------- Forwarded Message

To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jun 2004 15:27:53 -0400
Subject: I-D ACTION:draft-chen-bgp-group-path-update-00.txt
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Advertisement of the Group Best Paths in BGP
	Author(s)	: E. Chen
	Filename	: draft-chen-bgp-group-path-update-00.txt
	Pages		: 12
	Date		: 2004-6-28
	
   In this document we first identify and qualify the Group Best Paths
   for an address prefix as in general the necessary and sufficient
   subset of paths that need to be advertised by a BGP route reflector
   or a BGP confederation ASBR in order to eliminate the MED-type route
   oscillations and to achieve consistent routing in a network.  We then
   propose a mechanism for BGP that would allow a route reflector or a
   confederation ASBR to advertise the Group Best Paths.  The proposed
   mechanism is designed such that the vast majority of the BGP speakers
   in a network need only minor software changes in order to deploy the
   mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-group-path-update-00.txt

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Tue, 29 Jun 2004 11:06:16 -0700
From: Enke Chen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [Idr] draft-chen-bgp-group-path-update-00.txt
Sender: [email-masked]

Hi, folks:

Here is another attempt to tackle the issue of persistent IBGP
route oscillation. Please let us know if you have any comments
on the draft.

Thanks.  -- Enke

------- Forwarded Message

To: [email-masked]
From: [email-masked]
Date: Mon, 28 Jun 2004 15:27:53 -0400
Subject: I-D ACTION:draft-chen-bgp-group-path-update-00.txt
Sender: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Advertisement of the Group Best Paths in BGP
	Author(s)	: E. Chen
	Filename	: draft-chen-bgp-group-path-update-00.txt
	Pages		: 12
	Date		: 2004-6-28
	
   In this document we first identify and qualify the Group Best Paths
   for an address prefix as in general the necessary and sufficient
   subset of paths that need to be advertised by a BGP route reflector
   or a BGP confederation ASBR in order to eliminate the MED-type route
   oscillations and to achieve consistent routing in a network.  We then
   propose a mechanism for BGP that would allow a route reflector or a
   confederation ASBR to advertise the Group Best Paths.  The proposed
   mechanism is designed such that the vast majority of the BGP speakers
   in a network need only minor software changes in order to deploy the
   mechanism.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-group-path-update-00.txt

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "Andr s Cs sz r \(ETH/RL\)" <[email-masked]>
Subject: Re: [Idr] IGP and BGP 
Date: Fri, 25 Jun 2004 11:06:28 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"Andr s Cs sz r \(ETH/RL\)" writes:
>  
> > BGP routes are not given to the IGP at all.  IBGP is used to pass the
> > routing information to thw interior of an AS and acrosss the AS.
>  
> Well, that's interesting. iBGP across AS, sure; that is, between edge
> nodes (which nodes probably also use eBGP to communicate with
> neighbour AS router(s)). But iBGP to the interior... To every single
> router... Does this mean that typically every router is a BGP speaker
> inside an AS? In practice there are really no interior routers which
> only run IGP?

Yes that is exactly how it is used.  Although route reflectors are
typically used to avoid a full mesh of BGP speakers.

> iBGP requires full mesh interconnection between iBGP speakers, and if
> every single router inside an AS runs BGP, then this full mesh would
> be pretty hard to maintain. So, route reflectors are then really used
> in practice by operators in order to avoid this full mesh?

Exactly.

Quite a bit of efficiency consideration in the BGP implementation is
required for this to work.  This is why naive BGP implementations in
the mid to late 90s failed so miserably in the ISP lab before even
getting to the field (and occasionally new ones continue to do so if
they even get that far).

> Thanks,
> András

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" <[email-masked]>
To: <[email-masked]>
Date: Fri, 25 Jun 2004 10:24:17 +0200
Organization: TrafficLab, Ericsson R&D Division
Subject: [Idr] IGP and BGP
Sender: [email-masked]

> BGP routes are not given to the IGP at all.  IBGP is used to pass the
> routing information to thw interior of an AS and acrosss the AS.

Well, that's interesting. iBGP across AS, sure; that is, between edge nodes
(which nodes probably also use eBGP to communicate with neighbour AS
router(s)). But iBGP to the interior... To every single router... Does this
mean that typically every router is a BGP speaker inside an AS? In practice
there are really no interior routers which only run IGP?

iBGP requires full mesh interconnection between iBGP speakers, and if every
single router inside an AS runs BGP, then this full mesh would be pretty
hard to maintain. So, route reflectors are then really used in practice by
operators in order to avoid this full mesh?

Thanks,
András

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "Andr s Cs sz r \(ETH/RL\)" <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In 
Date: Thu, 24 Jun 2004 18:51:59 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"Andr s Cs sz r \(ETH/RL\)" writes:
>  
> Sure, yes, I maybe was not precise enough when asking my question. I did not
> mean full BGP routes, but only the available destination prefixes (maybe
> after route aggregation) reachable through a given BGP egress router. (I
> mean interior routers (running IGP only) have to be able to forward traffic
> to external prefixes as well, and I'm considering here either a mult-homed
> stub or any AS with multiple providers or peering relations.)
>  
> I think reachable prefixes are given to the IGP after they are installed
> into Loc-RIB (or even to Adj-RIB-Out?), and only if the given BGP speaker
> received the reachable destination prefix UPDATE message through eBGP.
>  
> Am I right?
>  
> András

BGP routes are not given to the IGP at all.  IBGP is used to pass the
routing information to thw interior of an AS and acrosss the AS.

The next hop for all BGP routes are looked up in the IGP and the
forwarding entry is created based on those two peices of information.

Implementation details vary with some optimizations done to reduce the
work when the IGP changes (trading off space for a time gain) but the
above description is otherwise accurate.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 24 Jun 2004 13:38:09 -0400 (EDT)
From: Jennifer Rexford <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] IGP upcall to BGP?
Cc: [email-masked]
Sender: [email-masked]

> y question: how (and how fast) does BGP learn about IGP cost change? Sure,
> IGP link state advertisements at some point reach the given BGP speaker, but
> how does this info get to the BGP module?
> 
> Anyway, could you please suggest me good articles/papers about the interface
> between IGP (IS-IS/OSPF) and BGP? What timers and processing delays are
> involved in both directions? 

For a recent study of this issue, see

  Renata Teixeira, Aman Shaikh, Tim Griffin, and Jennifer Rexford,
  "Dynamics of hot-potato routing in IP networks," Proc. ACM 
  SIGMETRICS, June 2004.
    http://www.research.att.com/~jrex/papers/sigmetrics04.pdf
    http://www.research.att.com/~jrex/talks/ima04.ppt
    http://www.nanog.org/mtg-0402/teixeira.html

-- Jen

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" <[email-masked]>
To: <[email-masked]>
Date: Wed, 23 Jun 2004 09:53:15 +0200
Organization: TrafficLab, Ericsson R&D Division
Subject: [Idr] IGP upcall to BGP?
Sender: [email-masked]

draft-ietf-idr-bgp4-24 writes:

The local speaker MUST determine the immediate next-hop address from the
NEXT_HOP attribute of the selected route (see Section 5.1.3). If either the
immediate next hop or the IGP cost to the NEXT_HOP (where the NEXT_HOP is
resolved through an IGP route) changes, Phase 2 Route Selection MUST be
performed again.
<<

Sure, yes, that makes sense since if you have multiple alternative
inter-domain routes to a given destination, than it might be possible that
the router decided for one of them based on the lowest IGP cost tie breaking
rule.

So far, so good. But, what happens if there is a fault inside the AS, and
the connectivity remains after IGP re-routing but the IGP cost changes.
According to the above citation, BGP could then, of course, select a new
route.

My question: how (and how fast) does BGP learn about IGP cost change? Sure,
IGP link state advertisements at some point reach the given BGP speaker, but
how does this info get to the BGP module?

Anyway, could you please suggest me good articles/papers about the interface
between IGP (IS-IS/OSPF) and BGP? What timers and processing delays are
involved in both directions? I mean what happens if a BGP speaker receives
an UPDATE of a newly reachable destination prefix in an AS which has
multiple providers. This info has to get into interior routers via IGP. (For
a moment, let's forget about default IGP routes...)

Thanks,
András

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "=?iso-8859-2?Q?Andr=E1s_Cs=E1sz=E1r_\=28ETH/RL\=29?=" <[email-masked]>
To: <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In
Date: Wed, 23 Jun 2004 09:41:11 +0200
Organization: TrafficLab, Ericsson R&D Division
Sender: [email-masked]

Sure, yes, I maybe was not precise enough when asking my question. I did not
mean full BGP routes, but only the available destination prefixes (maybe
after route aggregation) reachable through a given BGP egress router. (I
mean interior routers (running IGP only) have to be able to forward traffic
to external prefixes as well, and I'm considering here either a mult-homed
stub or any AS with multiple providers or peering relations.)

I think reachable prefixes are given to the IGP after they are installed
into Loc-RIB (or even to Adj-RIB-Out?), and only if the given BGP speaker
received the reachable destination prefix UPDATE message through eBGP.

Am I right?

András

----Original Message----
From: Curtis Villamizar [mailto:[email-masked]]
Sent: 2004. június 22. 21:58
To: Andras Csaszar (ETH/RL)
Cc: [email-masked]
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In

> In message <[email-masked]>
> "Andras Csaszar \(ETH/RL\)" writes:
>> 
>> I would like to ask a related question. When do BGP routes get
>> advertised into OSPF?
> 
> 
> When you want to bring down the network since that's what advertising
> anywhere close to full BGP routes into OSPF will do for you.
> 
> Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Kaliraj V - CTD, Chennai." <[email-masked]>
To: Jeffrey Haas <[email-masked]>, "Kaliraj V - CTD, Chennai." <[email-masked]>
Subject: RE: [Idr] Loc-Rib and Adj-Rib-In
Date: Wed, 23 Jun 2004 13:01:21 +0530
Cc: [email-masked]
Sender: [email-masked]

>This would only be misleading if the MIB stated in its Adj-Rib-Out that it
was using a given BGP route.
I agree. I guess this is clear. LocRIB is the protocol's view of the
best-route. Adj-RIB-out gives the results of policy too(redistribution
but-not outbound-routemaps asper MIBv2).

SO, in MIBv2 terms: a redistributed route will get into Adj-RIB-In
(NLRItable) and will override the LocRIB(bestroute asper LocRIB) to directly
enter Adj-RIB-Out (be pointed to by the Rowpointer-object
bgpM2AdjRibsOutRoute) for that NLRI prefix.

>However, I've recently become aware of a MIB TC that may let us reflect
what protocol the route came from.  
This feels like Good to have information, though not really needed for BGP
to know-about.

>It really seems that what you want is a Routing Table MIB.
Not really, I'm happy with presence of Adj-RIB-Out to tell me what BGP
actually used.:)

Thanks,
Kaliraj.
-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Wednesday, June 23, 2004 4:57 AM
To: Kaliraj V - CTD, Chennai.
Cc: [email-masked]
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In

On Tue, Jun 22, 2004 at 09:40:55PM +0530, Kaliraj V - CTD, Chennai. wrote:
> Jeff, from your expln I understand LocRIB is viewed as comprising of only
> BGP-learnt routes.
> 
> From the MIB view point, the best route is the one in the Loc-Rib.
> 
> But this should be really confusing. Assuming a BGP speaker has, for a
> prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route
> R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using
R2
> and not R1 as reachablity-information for P. Now, if the MIB shows as
> best-route the route in the Loc-RIB i.e. R1, then this seems misleading to
> me as the speaker is not using this route. 

This would only be misleading if the MIB stated in its Adj-Rib-Out that
it was using a given BGP route.

Note that the v2 MIB has added an Adj-Rib-Out table.  The contents
of this table was contentious when it was added and we have not
received consensus as to the contents.

> I suggest either R2 be considered part of Loc-RIB or the MIB view-point be
> altered so that it is not confined to Loc-RIB.

Loc-Rib will contain the BGP Best route.  The MIB must reflect this
since this is what the BGP specification indicates.  This route is
then installed in the Routing Table.

It is at this point that implementation specific magic happens.

As a for example, you could consider your Routing Table as having
the ability to learn multiple routes from each protocol that is
going to install routes there.  Through an internal policy mechanism,
the multiple candidate routes will become the Routing Table's active
route and that route will presumably be installed in the FIB.

This active Routing Table route, when not the same as the Loc-Rib
route, is available to BGP for redistribution (and technically
origination).

The details of how this works and model by which the Routing Table
is modeled, is outside the scope of the IDR working group.  To do
more than to reflect what was sent in BGP via the Adj-Rib-Out
table as a BGP route is probably out of scope.  However, I've recently
become aware of a MIB TC that may let us reflect what protocol the route
came from.  This will like show up in the next draft of the MIB.

It really seems that what you want is a Routing Table MIB.

> Kaliraj.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 22 Jun 2004 19:38:22 -0400
From: Jeffrey Haas <[email-masked]>
To: "Andras Csaszar (ETH/RL)" <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In
Cc: [email-masked]
Sender: [email-masked]

On Tue, Jun 22, 2004 at 09:36:17AM +0200, Andras Csaszar (ETH/RL) wrote:
> I would like to ask a related question. When do BGP routes get advertised
> into OSPF?
> 
> - When received in an UPDATE message? That is, when it gets into Adj-RIB-In?
> Or,
> - when it gets selected as best-route? That is, when it is put into the
> Loc-RIB?

Answer number 3: When it becomes the active route in the Routing Table,
or some implementation equivalent of this abstraction.

> In the second case there is an scenario where a multi-homed stub network
> prefers to use one outgoing link with BGP, therefore does not advertise the
> other route via OSPF's AS_External_LSA. Now consider that an interor node
> looses connectivity to the preferred egress router but otherwise would have
> connectivity to the other egress node, but it won't forward traffic to this
> egress node since it doesn't know that it accepts outgoing traffic.

In a given BGP Autonomous System, each BGP speaker may have a distinct
BGP route as the best BGP route.  When this is the case, if each of
these BGP speakers is an OSPF speaker and these routes are injected
into OSPF, you will have multiple candidate AS External routes.

There are multiple reasons why a given BGP route may be selected
as the best BGP route on multiple BGP speakers.  The BGP tie
breaking process will show many of them.

> Andras

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 22 Jun 2004 19:27:16 -0400
From: Jeffrey Haas <[email-masked]>
To: "Kaliraj V - CTD, Chennai." <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In
Cc: [email-masked]
Sender: [email-masked]

On Tue, Jun 22, 2004 at 09:40:55PM +0530, Kaliraj V - CTD, Chennai. wrote:
> Jeff, from your expln I understand LocRIB is viewed as comprising of only
> BGP-learnt routes.
> 
> From the MIB view point, the best route is the one in the Loc-Rib.
> 
> But this should be really confusing. Assuming a BGP speaker has, for a
> prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route
> R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2
> and not R1 as reachablity-information for P. Now, if the MIB shows as
> best-route the route in the Loc-RIB i.e. R1, then this seems misleading to
> me as the speaker is not using this route. 

This would only be misleading if the MIB stated in its Adj-Rib-Out that
it was using a given BGP route.

Note that the v2 MIB has added an Adj-Rib-Out table.  The contents
of this table was contentious when it was added and we have not
received consensus as to the contents.

> I suggest either R2 be considered part of Loc-RIB or the MIB view-point be
> altered so that it is not confined to Loc-RIB.

Loc-Rib will contain the BGP Best route.  The MIB must reflect this
since this is what the BGP specification indicates.  This route is
then installed in the Routing Table.

It is at this point that implementation specific magic happens.

As a for example, you could consider your Routing Table as having
the ability to learn multiple routes from each protocol that is
going to install routes there.  Through an internal policy mechanism,
the multiple candidate routes will become the Routing Table's active
route and that route will presumably be installed in the FIB.

This active Routing Table route, when not the same as the Loc-Rib
route, is available to BGP for redistribution (and technically
origination).

The details of how this works and model by which the Routing Table
is modeled, is outside the scope of the IDR working group.  To do
more than to reflect what was sent in BGP via the Adj-Rib-Out
table as a BGP route is probably out of scope.  However, I've recently
become aware of a MIB TC that may let us reflect what protocol the route
came from.  This will like show up in the next draft of the MIB.

It really seems that what you want is a Routing Table MIB.

> Kaliraj.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Tue, 22 Jun 2004 13:45:56 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] IDR WG meeting agenda.
Sender: [email-masked]

Folks,

Please forward any agenda item requests to Sue and myself.

Thanks,

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "Andras Csaszar \(ETH/RL\)" <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In 
Date: Tue, 22 Jun 2004 15:57:45 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
"Andras Csaszar \(ETH/RL\)" writes:
>  
> I would like to ask a related question. When do BGP routes get advertised
> into OSPF?

When you want to bring down the network since that's what advertising
anywhere close to full BGP routes into OSPF will do for you.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Tue, 22 Jun 2004 15:57:57 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-05.txt
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-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-05.txt
	Pages		: 20
	Date		: 2004-6-22
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-bgp-analysis-05.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-bgp-analysis-05.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-bgp-analysis-05.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--

To: [email-masked]
Date: Tue, 22 Jun 2004 10:57:40 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] Re: WG Last Call on BGP Graceful Restart
Sender: [email-masked]

Folks,

Just to add to the attached, the implementation report
is in draft-ietf-idr-bgp-gr-survey-01.txt.

Yakov.
------- Forwarded Message

Date:    Thu, 17 Jun 2004 11:36:14 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] WG Last Call on BGP Graceful Restart

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-restart-10.txt
to a Proposed Standard. Since the the previous version of this document
already went through the WG Last Call, the main focus of this Last
Call is the new text on Finite State Machine.

The Last Call ends July 1, 2004.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Kaliraj V - CTD, Chennai." <[email-masked]>
To: Jeffrey Haas <[email-masked]>, "Kaliraj V - CTD, Chennai." <[email-masked]>
Subject: RE: [Idr] Loc-Rib and Adj-Rib-In
Date: Tue, 22 Jun 2004 21:40:55 +0530
Cc: [email-masked]
Sender: [email-masked]

Jeff, from your expln I understand LocRIB is viewed as comprising of only
BGP-learnt routes.

>From the MIB view point, the best route is the one in the Loc-Rib.

But this should be really confusing. Assuming a BGP speaker has, for a
prefix P: a BGP-best route R1(LocRIB) and a redistributed non-BGP route
R2(result-of-Policy); R2 by policy overrides R1. So the speaker is using R2
and not R1 as reachablity-information for P. Now, if the MIB shows as
best-route the route in the Loc-RIB i.e. R1, then this seems misleading to
me as the speaker is not using this route. 

I suggest either R2 be considered part of Loc-RIB or the MIB view-point be
altered so that it is not confined to Loc-RIB.

Thanks,
Kaliraj.
-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Tuesday, June 22, 2004 6:48 PM
To: Kaliraj V - CTD, Chennai.
Cc: [email-masked]
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In

On Tue, Jun 22, 2004 at 02:23:16PM +0530, Kaliraj V - CTD, Chennai. wrote:
> I feel for all practical-puposes a redistributed-route is Best-BGP route,
so
> it should be seen in the Loc-RIB too.

There are two issues with this, IMO:

1. A route that is redistributed into BGP, potentially in preference to
   a route that is the "best BGP route", is not a BGP route until it
   is sent to the neighboring BGP peer.  The local system will simply
   treat it as a route from whatever protocol (OSPF, IS-IS, etc.) it came
   from.
2. While the clarity of getting non-BGP information injected into BGP
   is a little vague, the processing of BGP routes into the Loc-Rib
   is quite clear:

   [draft -24, 9.1.2]
   : The local speaker SHALL then install that route in the Loc-RIB,
   : replacing any route to the same destination that is currently being
   : held in the Loc-RIB. 

   See also draft -24 3.2.2.b

> For eg. from the BGP MIB view-point,
> we'd like to see the redistributed-BGP route as the Best-BGP route for the
> corresponding prefix, even if it has not been advertised to any peers i.e.
> not present in Adj-RIB-Out of any peer. Please correct me if wrong.

>From the MIB view point, the best route is the one in the Loc-Rib.
This probably should have been clarified in the v1 MIB but it can
go into the v2 MIB.  I don't think we need to backout of last call
on the MIB for this clarification.

> May be we can imagine a pseudo-RIB-In for these routes, which will not
take
> part in the BGP-path-selection-process but any competitor available in
this
> pseudo-RIB-In will override the best-bgp-route selected by the
> selection-process.  

The general problem is that the RIB model is reasonably well suited
for BGP-only information with some vagaries as to how information from
other protocols is redistributed into BGP.  To clarify this, we would
need to discuss the details of the Policy Information Base and 
the Routing Table and that would take us into implementation details
we really don't want to have done by IDR.

The problem with your suggestion of "any competitor available [...] will
overide" is that this is a matter of policy, which is dealt with in the
section from my original paste.

> Kaliraj.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 22 Jun 2004 09:18:05 -0400
From: Jeffrey Haas <[email-masked]>
To: "Kaliraj V - CTD, Chennai." <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In
Cc: [email-masked]
Sender: [email-masked]

On Tue, Jun 22, 2004 at 02:23:16PM +0530, Kaliraj V - CTD, Chennai. wrote:
> I feel for all practical-puposes a redistributed-route is Best-BGP route, so
> it should be seen in the Loc-RIB too.

There are two issues with this, IMO:

1. A route that is redistributed into BGP, potentially in preference to
   a route that is the "best BGP route", is not a BGP route until it
   is sent to the neighboring BGP peer.  The local system will simply
   treat it as a route from whatever protocol (OSPF, IS-IS, etc.) it came
   from.
2. While the clarity of getting non-BGP information injected into BGP
   is a little vague, the processing of BGP routes into the Loc-Rib
   is quite clear:

   [draft -24, 9.1.2]
   : The local speaker SHALL then install that route in the Loc-RIB,
   : replacing any route to the same destination that is currently being
   : held in the Loc-RIB. 

   See also draft -24 3.2.2.b

> For eg. from the BGP MIB view-point,
> we'd like to see the redistributed-BGP route as the Best-BGP route for the
> corresponding prefix, even if it has not been advertised to any peers i.e.
> not present in Adj-RIB-Out of any peer. Please correct me if wrong.

>From the MIB view point, the best route is the one in the Loc-Rib.
This probably should have been clarified in the v1 MIB but it can
go into the v2 MIB.  I don't think we need to backout of last call
on the MIB for this clarification.

> May be we can imagine a pseudo-RIB-In for these routes, which will not take
> part in the BGP-path-selection-process but any competitor available in this
> pseudo-RIB-In will override the best-bgp-route selected by the
> selection-process.  

The general problem is that the RIB model is reasonably well suited
for BGP-only information with some vagaries as to how information from
other protocols is redistributed into BGP.  To clarify this, we would
need to discuss the details of the Policy Information Base and 
the Routing Table and that would take us into implementation details
we really don't want to have done by IDR.

The problem with your suggestion of "any competitor available [...] will
overide" is that this is a matter of policy, which is dealt with in the
section from my original paste.

> Kaliraj.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "Kaliraj V - CTD, Chennai." <[email-masked]>
To: Jeffrey Haas <[email-masked]>, John Smith <[email-masked]>
Subject: RE: [Idr] Loc-Rib and Adj-Rib-In
Date: Tue, 22 Jun 2004 14:23:16 +0530
Cc: [email-masked]
Sender: [email-masked]

>IMO, this would imply that a redistributed route enters directly into
>the Adj-Rib-Out of a peer potentially in preference to the best selected
>bgp route.

I feel for all practical-puposes a redistributed-route is Best-BGP route, so
it should be seen in the Loc-RIB too. For eg. from the BGP MIB view-point,
we'd like to see the redistributed-BGP route as the Best-BGP route for the
corresponding prefix, even if it has not been advertised to any peers i.e.
not present in Adj-RIB-Out of any peer. Please correct me if wrong.

> The routes that we receive from our peers are placed in the "Adj-Rib-In".
What about the
> routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP?

May be we can imagine a pseudo-RIB-In for these routes, which will not take
part in the BGP-path-selection-process but any competitor available in this
pseudo-RIB-In will override the best-bgp-route selected by the
selection-process.  

Kaliraj.
-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Monday, June 21, 2004 10:02 PM
To: John Smith
Cc: [email-masked]
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In

On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote:
> Consider an instance where BGP is redistributing OSPF routes in it. BGP
runs its decision
> process and finds that these are the best routes and that it needs to
announce them to
> its peers. From a purist's language, will these routes now be placed in
the "Loc-Rib" ?
> 
> The routes that we receive from our peers are placed in the "Adj-Rib-In".
What about the
> routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP?

It is intentionally hand-waved in the specification.  The closest
reference you will find to such a thing (from draft -23):

   All routes in the Loc-RIB are processed into Adj-RIBs-Out according
   to configured policy. This policy MAY exclude a route in the Loc-RIB
   from being installed in a particular Adj-RIB-Out. A route SHALL NOT
   be installed in the Adj-Rib-Out unless the destination and NEXT_HOP
   described by this route may be forwarded appropriately by the Routing
   Table. If a route in Loc-RIB is excluded from a particular Adj-RIB-
   Out the previously advertised route in that Adj-RIB-Out MUST be with-
   drawn from service by means of an UPDATE message (see 9.2).

IMO, this would imply that a redistributed route enters directly into
the Adj-Rib-Out of a peer potentially in preference to the best selected
bgp route.

>From the BGP MIB standpoint, just because a route is the best bgp route
doesn't mean we expect to see it in the adj-rib-out.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "=?us-ascii?Q?Andras_Csaszar_\=28ETH/RL\=29?=" <[email-masked]>
To: <[email-masked]>
Subject: RE: [Idr] Loc-Rib and Adj-Rib-In
Date: Tue, 22 Jun 2004 09:36:17 +0200
Organization: TrafficLab, Ericsson R&D Division
Sender: [email-masked]

Hi!

I would like to ask a related question. When do BGP routes get advertised
into OSPF?

- When received in an UPDATE message? That is, when it gets into Adj-RIB-In?
Or,
- when it gets selected as best-route? That is, when it is put into the
Loc-RIB?

In the first case, I think it's hard to ensure that OSPF uses the same
routes as BGP thinks.  Although it might be possible by setting the OSPF
metrics appropriately. (?)

In the second case there is an scenario where a multi-homed stub network
prefers to use one outgoing link with BGP, therefore does not advertise the
other route via OSPF's AS_External_LSA. Now consider that an interor node
looses connectivity to the preferred egress router but otherwise would have
connectivity to the other egress node, but it won't forward traffic to this
egress node since it doesn't know that it accepts outgoing traffic. Anyway,
in this case how will this interior node ever learn about this route? (I
mean, the two egress nodes running BGP still prefer the first egress link,
even though some interior nodes can't access it any longer.)

Am I missing something, or which one is right?

Thanks,
Andras

----Original Message----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jeffrey Haas Sent: 2004. junius 21. 18:32
To: John Smith
Cc: [email-masked]
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In

> On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote:
>> Consider an instance where BGP is redistributing OSPF routes in it.
>> BGP runs its decision process and finds that these are the best
>> routes and that it needs to announce them to its peers. From a
>> purist's language, will these routes now be placed in the "Loc-Rib"
>> ?  
>> 
>> The routes that we receive from our peers are placed in the
>> "Adj-Rib-In". What about the routes that are redistributed
>> (static/RIP/ISIS/OSPF/etc) in BGP? 
> 
> It is intentionally hand-waved in the specification.  The closest
> reference you will find to such a thing (from draft -23):
> 
>    All routes in the Loc-RIB are processed into Adj-RIBs-Out according
>    to configured policy. This policy MAY exclude a route in the
>    Loc-RIB from being installed in a particular Adj-RIB-Out. A route
>    SHALL NOT be installed in the Adj-Rib-Out unless the destination
>    and NEXT_HOP described by this route may be forwarded
>    appropriately by the Routing Table. If a route in Loc-RIB is
>    excluded from a particular Adj-RIB- Out the previously advertised
>    route in that Adj-RIB-Out MUST be with- drawn from service by
> means of an UPDATE message (see 9.2). 
> 
> IMO, this would imply that a redistributed route enters directly into
> the Adj-Rib-Out of a peer potentially in preference to the best
> selected 
> bgp route.
> 
>> From the BGP MIB standpoint, just because a route is the best bgp
>> route 
> doesn't mean we expect to see it in the adj-rib-out.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Mon, 21 Jun 2004 12:32:17 -0400
From: Jeffrey Haas <[email-masked]>
To: John Smith <[email-masked]>
Subject: Re: [Idr] Loc-Rib and Adj-Rib-In
Cc: [email-masked]
Sender: [email-masked]

On Fri, Jun 18, 2004 at 10:29:59AM +0100, John Smith wrote:
> Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision
> process and finds that these are the best routes and that it needs to announce them to
> its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ?
> 
> The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the
> routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP?

It is intentionally hand-waved in the specification.  The closest
reference you will find to such a thing (from draft -23):

   All routes in the Loc-RIB are processed into Adj-RIBs-Out according
   to configured policy. This policy MAY exclude a route in the Loc-RIB
   from being installed in a particular Adj-RIB-Out. A route SHALL NOT
   be installed in the Adj-Rib-Out unless the destination and NEXT_HOP
   described by this route may be forwarded appropriately by the Routing
   Table. If a route in Loc-RIB is excluded from a particular Adj-RIB-
   Out the previously advertised route in that Adj-RIB-Out MUST be with-
   drawn from service by means of an UPDATE message (see 9.2).

IMO, this would imply that a redistributed route enters directly into
the Adj-Rib-Out of a peer potentially in preference to the best selected
bgp route.

>From the BGP MIB standpoint, just because a route is the best bgp route
doesn't mean we expect to see it in the adj-rib-out.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Fri, 18 Jun 2004 08:09:21 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] draft-ietf-idr-bgp4-24.txt
Sender: [email-masked]

Folks,

In response to the comments received during the IESG Last Call 
here is the list of changes:

1. Added missing text to 5.1.2 (see my e-mail on Thu, 03 Jun 2004
06:50:19 PDT).

2. Added new text to the Security Consideration section (see my
e-mail on Mon, 24 May 2004 07:32:55 PDT)

3. Fix text in 9.1.4 (see e-mail from Andrew Lange on Mon, 23 Feb
2004 09:22:37 PST)

4. Replace normative text with non-normative text in Appendix F
(see my e-mail on Sun, 22 Feb 2004 11:56:49 PST) 

5. Make all references to events as "Event NN" (in the -23 version
some events have been referenced as "Event NN" while others as "EventNN").
Care was taken to avoid splitting "Event NN" across multiple lines.

Yakov.
------- Forwarded Message

Date:    Thu, 17 Jun 2004 11:18:46 -0400
From:    [email-masked]
To:      [email-masked]
cc:      [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-24.txt

- --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, S. Hares
	Filename	: draft-ietf-idr-bgp4-24.txt
	Pages		: 99
	Date		: 2004-6-17
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protoco
l.
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the list of
Autonomous Systems (ASs) that reachability information traverses.
This information is sufficient to construct a graph of AS
connectivity for this reachability from which routing loops may be
pruned and some policy decisions at the AS level may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix, and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.
Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforced using BGP. BGP can
support only the policies conforming to the destination-based
forwarding paradigm.
This specification covers only the exchange of IP version 4 network
reachability information.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-24.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-24.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-24.txt

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

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

- --OtherAccess--

- --NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

- --NextPart--

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Fri, 18 Jun 2004 10:29:59 +0100 (BST)
From: =?iso-8859-1?q?John=20Smith?= <[email-masked]>
To: [email-masked]
Subject: [Idr] Loc-Rib and Adj-Rib-In
Sender: [email-masked]

Hi,

Consider an instance where BGP is redistributing OSPF routes in it. BGP runs its decision
process and finds that these are the best routes and that it needs to announce them to
its peers. From a purist's language, will these routes now be placed in the "Loc-Rib" ?

The routes that we receive from our peers are placed in the "Adj-Rib-In". What about the
routes that are redistributed (static/RIP/ISIS/OSPF/etc) in BGP?

Thanks,
Smith

___________________________________________________________ALL-NEW Yahoo! Messenger - sooooo many all-new ways to express yourself http://uk.messenger.yahoo.com

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Thu, 17 Jun 2004 11:36:14 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] WG Last Call on BGP Graceful Restart
Sender: [email-masked]

Folks,

This is to start the WG Last Call on advancing draft-ietf-idr-restart-10.txt
to a Proposed Standard. Since the the previous version of this document
already went through the WG Last Call, the main focus of this Last
Call is the new text on Finite State Machine.

The Last Call ends July 1, 2004.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Thu, 17 Jun 2004 11:18:46 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-24.txt
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, S. Hares
	Filename	: draft-ietf-idr-bgp4-24.txt
	Pages		: 99
	Date		: 2004-6-17
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the list of
Autonomous Systems (ASs) that reachability information traverses.
This information is sufficient to construct a graph of AS
connectivity for this reachability from which routing loops may be
pruned and some policy decisions at the AS level may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix, and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.
Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforced using BGP. BGP can
support only the policies conforming to the destination-based
forwarding paradigm.
This specification covers only the exchange of IP version 4 network
reachability information.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-24.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-24.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-24.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--

To: [email-masked], [email-masked]
Date: Wed, 16 Jun 2004 05:45:04 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [Idr] rfc1863 to historic
Sender: [email-masked]

Alex and Bill,

The IDR WG would like to ask the IESG to publish
draft-ietf-idr-rfc1863-historic-00.txt as an Informational RFC.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Sun, 13 Jun 2004 19:35:46 +0200
From: Loa Andersson <[email-masked]>
To: [email-masked]
Subject: [Idr] MPLS2004 Conference Call for Presentations
Sender: [email-masked]

The MPLS2004 Conference will be held in Washington DC, from October 17
to October 19, 2004. This year's conference will include, but will not
be limited, to the following topics:

- Network Consolidation and Service Convergence
- Traffic engineering and QoS
- MPLS network operation, administration, and maintenance
- OSS Systems for MPLS-based networks
- MPLS Multicast
- Service Provisioning
- MPLS in multi-AS networks
- L2VPNs (pseudo-wire emulation, VPWS, VPLS, and others)
- L3VPNs (BGP/MPLS, IPSec interworking, virtual routers, and others)
- Voice, video, and real-time services over MPLS networks
- Scalability and performance of MPLS protocols and networks
- Network processor architectures for next generation MPLS networks
- MPLS certification, verification, and conformance testing
- MPLS network security
- MPLS reliability and survivability (fast reroute, graceful restart,
   and restoration techniques)
- IP Optical Integration
- Multilayer control, management, and optimization
- MPLS deployment case studies: Service Provider operational experience

The Program Committee for MPLS2004 is soliciting presentation proposals
for this conference. If you wish to propose a particular topic for
consideration, please send a one page summary, including speaker's name,
affiliation, and contact information to the Technical Program
Committee at: [email-masked]

All proposals must be received by June 18, 2004. See
http://www.mpls2004.com for more details.

The program committee is looking for original and unpublished work to
continue the tradition of addressing cutting-edge topics that was
initiated by this conference in 1998. Presentations from the vendor,
service provider, research, and user communities covering technology
evolution and operational experience are solicited.
-- 

Loa Andersson

mobile +46 739 81 21 64

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
From: [email-masked]
Date: Wed, 09 Jun 2004 15:34:20 -0400
Cc: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-10.txt
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		: Graceful Restart Mechanism for BGP
	Author(s)	: S. Sangli, et al.
	Filename	: draft-ietf-idr-restart-10.txt
	Pages		: 11
	Date		: 2004-6-9
	
This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information.  A new BGP capability, termed 'Graceful Restart
Capability', is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP transport reset.
The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this
document).

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-restart-10.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-restart-10.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-restart-10.txt

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

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

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

--NextPart--

To: Tony Li <[email-masked]>
Subject: Re: [Idr] pref-limit - one more update 
Date: Tue, 08 Jun 2004 23:30:33 -0400
From: Curtis Villamizar <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Tony Li writes:
>  
>  
> I agree that it's very rough, especially when you factor out the
> authors.
>  
> So, a couple of other suggestions: a) consult the "routing
> directorate" or b) consult the AD's "subject area expert".
>  
> Tony

Tony,

Think about how that statement would have sounded 10 years ago.  The
answer would have been an immediate "go write some code and come back
here when/if someone deploys it".  If this is provider driven even if
driven by a subset of providers, it won't matter that the IETF has to
say the implementations will happen.  If this is a big yawn to most
providers, it also won't matter what the IETF has to say because the
implementations if they happen at all won't be deployed.

Curtis

> On Jun 8, 2004, at 6:36 PM, Curtis Villamizar wrote:
>  
> >
> > In message <[email-masked]>
> > Yakov Rekhter writes:
> >>
> >> Folks,
> >>
> >> One more correction - attached is the updated list.
> >>
> >> Yakov.
> >
> >
> > Yakov,
> >
> > Consensus looks a bit too rough.  In the old days we used to wait for
> > running code in this situation and factor that in.  Just a suggestion.
> > Saves a lot of arguing.
> >
> > Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Tony Li <[email-masked]>
Subject: Re: [Idr] pref-limit - one more update 
Date: Tue, 8 Jun 2004 20:03:33 -0700
To: [email-masked]
Cc: Yakov Rekhter <[email-masked]>, [email-masked]
Sender: [email-masked]

I agree that it's very rough, especially when you factor out
the authors.

So, a couple of other suggestions:  a) consult the "routing directorate"
or b) consult the AD's "subject area expert".

Tony

On Jun 8, 2004, at 6:36 PM, Curtis Villamizar wrote:

>
> In message <[email-masked]>
> Yakov Rekhter writes:
>>
>> Folks,
>>
>> One more correction - attached is the updated list.
>>
>> Yakov.
>
>
> Yakov,
>
> Consensus looks a bit too rough.  In the old days we used to wait for
> running code in this situation and factor that in.  Just a suggestion.
> Saves a lot of arguing.
>
> Curtis
>
>
>
> -----------------------------------------------------------------
> Accept Signalled Pref-limit as work item:
>
> 	Yes:
> 		Vincent Gillet
> 		Jeffrey Haas
> 		Enke Chen
> 		Eric Rosen
> 		Curtis Villamizar
> 		Sun Tao
> 		Gerald Ash
> 		Robert Raszuk
> 		Srikanth Chavali (author)
>       		Vasile Radoaca (author)
>       		Mo Miri (author)
>       		Luyuan Fan (author)
>       		Susan Hares (author)
>       		Keyur Patel (author)
>       		Chandra Appanna (author)
>       		John Scudder (author)
>
>       No:
> 		Vivek Menezes
> 		Pekka Savola
> 		Parantap Lahiri
> 		Tony Li
> 		Enrico Salazar
> 		Pedro Roque Marques
> 		Kurt Erik Lindqvist
>
> Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes:
>
> 		Vincent Gillet
> 		Gerald Ash
> 		Srikanth Chavali (author)
>       		Vasile Radoaca (author)
>       		Mo Miri (author)
>       		Luyuan Fan (author)
>       		Susan Hares (author)
>
> Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes:
>
> 		Enke Chen
> 		Eric Rosen
> 		Sun Tao
> 		Robert Raszuk
>       		Keyur Patel (author)
>       		Chandra Appanna (author)
>       		John Scudder (author)
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/idr
>

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] pref-limit - one more update 
Date: Tue, 08 Jun 2004 21:36:44 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>
Yakov Rekhter writes:
>  
> Folks,
>  
> One more correction - attached is the updated list.
>  
> Yakov.

Yakov,

Consensus looks a bit too rough.  In the old days we used to wait for
running code in this situation and factor that in.  Just a suggestion.
Saves a lot of arguing.

Curtis

-----------------------------------------------------------------
Accept Signalled Pref-limit as work item:

	Yes:
		Vincent Gillet
		Jeffrey Haas
		Enke Chen
		Eric Rosen
		Curtis Villamizar
		Sun Tao
		Gerald Ash
		Robert Raszuk
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

      No:
		Vivek Menezes
		Pekka Savola
		Parantap Lahiri
		Tony Li
		Enrico Salazar
		Pedro Roque Marques
		Kurt Erik Lindqvist

Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes:

		Vincent Gillet
		Gerald Ash
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)

Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes:

		Enke Chen
		Eric Rosen
		Sun Tao
		Robert Raszuk
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Tue, 08 Jun 2004 16:43:01 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] pref-limit - one more update
Sender: [email-masked]

Folks,

One more correction - attached is the updated list.

Yakov.
-----------------------------------------------------------------
Accept Signalled Pref-limit as work item: 

	Yes:
		Vincent Gillet
		Jeffrey Haas
		Enke Chen
		Eric Rosen
		Curtis Villamizar
		Sun Tao
		Gerald Ash 
		Robert Raszuk
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

      No:
		Vivek Menezes
		Pekka Savola
		Parantap Lahiri
		Tony Li
		Enrico Salazar
		Pedro Roque Marques
		Kurt Erik Lindqvist

Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes:

		Vincent Gillet
		Gerald Ash
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)

Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes:

		Enke Chen
		Eric Rosen
		Sun Tao
		Robert Raszuk
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Tue, 08 Jun 2004 14:32:00 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] pref-limit comments
Sender: [email-masked]

Folks,

In the list I sent earlier today I missed one person. Here
is the updated list:

Accept Signalled Pref-limit as work item: 

	Yes:
		Vincent Gillet
		Jeffrey Haas
		Enke Chen
		Eric Rosen
		Curtis Villamizar
		Sun Tao
		Gerald Ash 
		Robert Raszuk
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

      No:
		Vivek Menezes
		Pekka Savola
		Parantap Lahiri
		Tony Li
		Enrico Salazar
		Pedro Roque Marques

Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes:

		Vincent Gillet
		Gerald Ash
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)

Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes:

		Enke Chen
		Eric Rosen
		Sun Tao
		Robert Raszuk
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Tue, 08 Jun 2004 10:19:16 -0700
From: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: [Idr] IDR WG meeting agenda
Sender: [email-masked]

Folks,

If you'd like some time on the agenda in San Diego
please let me and Sue know (the sooner the better).

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Subject: [Idr] extending deadline for pref-limit comments
Date: Tue, 08 Jun 2004 09:44:18 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

The deadline for comments on the attached is over. The following
summarizes the feedback received. Please check for correctness.

In the summary I assume that (a) all the authors of a particular
proposal are in favor of accepting this proposal as WG item (if
this is incorrect, please let me know asap), and (b) all the authors
of both of the proposals are in favor of accepting signalled prefix
limit as an IDR WG item (if this is incorrect, please let me know
asap).

Accept Signalled Pref-limit as work item: 

	Yes:
		Vincent Gillet
		Jeffrey Haas
		Enke Chen
		Eric Rosen
		Curtis Villamizar
		Sun Tao
		Gerald Ash 
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

      No:
		Vivek Menezes
		Pekka Savola
		Parantap Lahiri
		Tony Li
		Enrico Salazar
		Pedro Roque Marques

Accept draft-chavali-bgp-prefixlimit-02.txt as an IDR WG document Yes:

		Vincent Gillet
		Gerald Ash
		Srikanth Chavali (author)
      		Vasile Radoaca (author)
      		Mo Miri (author)
      		Luyuan Fan (author)
      		Susan Hares (author)

Accept draft-keyur-prefixlimit-orf-00.txt as an IDR WG document Yes:

		Enke Chen
		Eric Rosen
		Sun Tao
      		Keyur Patel (author)
      		Chandra Appanna (author)
      		John Scudder (author)

------- Forwarded Message

Date:    Mon, 24 May 2004 08:07:04 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] extending deadline for pref-limit comments

Folks,

As requested by authors of both of the proposals on the table,
we are going to extend the deadline for comments for another
2 weeks (until Jun 7). 

To remind, the questions on the table are the following:

1. whether to take signalled prefix limit as a WG item

2. whether to accept draft-chavali-bgp-prefixlimit-02.txt as an IDR
   WG document

3. whether to accept draft-keyur-prefixlimit-orf-00.txt as an IDR
   WG document

In your e-mails please *clearly* indicate your preferences. Providing
rationale for your preferences would be extremely useful as well.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 8 Jun 2004 09:45:30 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] revised draft
Sender: [email-masked]

All of my previous concerns were addressed.  It looks good to me.

On Mon, Jun 07, 2004 at 01:09:53PM -0700, Yakov Rekhter wrote:
> Folks,
> 
> Please check if the attached reflects the comments received during 
> the IDR WG Last Call. In the absence of any objections we'll submit it to
> the IESG Jun 14, 2004.
> 
> Yakov

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 8 Jun 2004 08:25:28 -0400
From: Jeffrey Haas <[email-masked]>
To: Tulip Rasputin <[email-masked]>
Subject: Re: [Idr] Atomic Aggregate
Cc: [email-masked]
Sender: [email-masked]

On Tue, Jun 08, 2004 at 06:56:57AM -0400, Tulip Rasputin wrote:
> What would happen if it advertises 128/8 with AS Path Seq "XXX 6000"  and AS Set "[6120]"? In this
> case its advertising all the AS Path information. Is it required to attach the ATOMIC_AGGREGATE
> path attribute in this case?

All of the AS's are present, even if not attached to their original
sequences.  Since BGP uses the presence of the AS, regardless of its
type (sequence, set, etc) for loop detection, this is enough. 

ATOMIC_AGGREGATE doesn't need to be attached.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 8 Jun 2004 06:56:57 -0400 (EDT)
From: Tulip Rasputin <[email-masked]>
To: [email-masked]
Subject: [Idr] Atomic Aggregate
Sender: [email-masked]

Hi,

Section 5.1.6 (ATOMIC_AGGREGATE) of the draft-ietf-idr-bgp4-23.txt states that "If an aggregate
excludes at least some of the AS numbers present in the AS_PATH of the routes that are aggregated
as a result of dropping the AS_SET, the aggregated route, when advertised to the peer, SHOULD  
include the ATOMIC_AGGREGATE attribute."

Now suppose a BGP speaker (in AS say XXX) has the following routes:

[1] 128.1/16, AS Path Sequence 6000 6120
[2] 128.2/16, AS Path Seq 6000 

This BGP speaker is configured to advertise an aggregate route of 128/8 to one of its EBGP Peer.

If this BGP speaker advertises 128/8 with AS Path "XXX 6000", then IMO it should attach the
ATOMIC_AGGREGATE path attribute, warning its peer that some of the AS numbers are not present in
this AS Path.

What would happen if it advertises 128/8 with AS Path Seq "XXX 6000"  and AS Set "[6120]"? In this
case its advertising all the AS Path information. Is it required to attach the ATOMIC_AGGREGATE
path attribute in this case?

I understand that it will attach the AGREGATOR path attribute in both the above cases to let
others know who and where did the aggregation took place?

Regards,
Rasputin

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Mon, 07 Jun 2004 13:09:53 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] revised draft
Sender: [email-masked]

Folks,

Please check if the attached reflects the comments received during 
the IDR WG Last Call. In the absence of any objections we'll submit it to
the IESG Jun 14, 2004.

Yakov.
------- Forwarded Message

Date:    Mon, 07 Jun 2004 15:42:12 -0400
From:    [email-masked]
To:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc1863-historic-00.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Reclassification of RFC 1863 to Historic
	Author(s)	: P. Savola
	Filename	: draft-ietf-idr-rfc1863-historic-00.txt
	Pages		: 4
	Date		: 2004-6-7
	
This memo reclassifies RFC 1863, A BGP/IDRP Route Server alternative
   to a full mesh routing, to Historic status.  This memo also Obsoletes
   RFC 1863.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rfc1863-historic-00.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-rfc1863-historic-00.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-rfc1863-historic-00.txt

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

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

- --OtherAccess--

- --NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

- --NextPart--

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 4 Jun 2004 15:33:48 -0700
To: [email-masked]
Subject: [Idr] Question about RFC 3107 Carrying label in bgp-4 
Cc: [email-masked]
Sender: [email-masked]

qning  writes:

> Hi, I will use 192.168.0.0/16 as an ip prefix, and 0x102031 as an
> mpls label in the following questions.

> RFC 3107 (Carrying Label Information in BGP-4) Section 3 states
> 0x102031:192.168.0.0/16 can be advertised in a MP_REACH_NLRI.  It
> can be withdrawn by either a) a new route with a new label:
> 0xB1B2B3:192.168.0.0/16 in MP_REACG_NLRI or b)
> 0x800000:192.168.0.0/16 in a MP_UNREACH_NLRI.

Not commenting on the spec...

The implementations i'm aware of treat the IP prefix as the NLRI key
for safi-4 and the label as a per nlri attribute.

As such an update for a given IP prefix implicitly withdrawn the
previously advertised label.

Another area to be concerned in terms of interoperability is the fact
that some implementations seem to consider a SAFI=1 update/withdrawl
for the same prefix to update the safi=4 information...
Not JunOS implementation, however...

JunOS considers a safi=4 update and a safi=1 update to refer to
different routing databases...

You may want to verify some of these details if you are concerned w/
interoperability...

  Pedro.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] A question on longest match
Date: Fri, 04 Jun 2004 15:50:20 +0000
Cc: [email-masked]
Sender: [email-masked]

Sorry for being rude Curtis,

As I said it was an opinion, and I shared it,

It is for the WG to decide.

>From: Curtis Villamizar <[email-masked]>
>Reply-To: [email-masked]
>To: "john smith" <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Idr] A question on longest match Date: Fri, 04 Jun 2004 
>11:44:43 -0400
>
>In message <[email-masked]>, "john smith" writes:
> >
> >
> > >Back then this idea was known as "FIB compression" and if you like you
> > >can search the archives for a lot of discussion on the issue and quite
> > >a bit of measurement done at that time.
> > >
> >
> > It certainly is better than entring a "split brain" with NO_EXPORT :)
>
>
>We're talking about two different things.  Automatic aggregation of
>the FIB is safe to do under all circumstances.  Automatice aggregation
>and reannouncement is not always safe.
>
>
> > > > Or we are saying BGP is specifically meant only for vendors and
> > >operators
> > > > who can cater to such hardware?
> > >
> > >
> > >Providers can aggregate better but it requires better coordination
> > >among providers.
> > >
> >
> > How has this got *anything* to do with coordination among providers?
>
>
>If provider A has a aggregate and some customers are dual homed to
>provider B, then provider B or downstream can't safely aggregate those
>routes.  If any of those dual homed customers loosed connection to A
>and most providers rightfully send traffic for the A aggregate to A,
>then those customers don't have backup through B.
>
>See 10 year old discussion on "hostile aggregation".
>
>The modern twist on this is that the "provider coordination" these
>days can be as simple as adding a BGP community.  We now have a BGP
>communitity that can work across any number of AS crossings, the
>NOPEER.  The classic example where this is a problem is the
>non-aggregation of Australian routes in the US and Europe.
>Unfortunately the NOPEER isn't being used enough so you need to use
>the "clue club" (as someone who has contributed a lot to operations
>has called it, or was it the "clue bat") with the provider origination
>the route.  That too is a form of interprovider coordination, but not
>one easily standardized.
>
>That's what PTOMANE and GROW are all about.  Or a big part of it.
>
>In the case of 4/8, there were a very small number of more specific.
>In all likelyhood these are only the ones that really needed to be
>there (or at least most of them) so you shouldn't touch them.
>
>
> > It is upto the IETF to make the providers cordinate. Eitherways if the 
>IETF
> > thinks the idea makes *any sense* then they should take a step in that
> > direction rather than say "too late".
> >
> > If people can build terabit routers which can switch millions of packets 
>and
> > have a huge FIB, they can figure out ways to reduce the FIB size too. It 
>is
> > a matter of what the "specs" say.
> >
> > Are specs *not* made for scalaibilty? To quote someone from another 
>list, is
> > it not the job of the *specs* to say what is *techincally correct*?
>
>
>Not to be rude but I chopped off the rest of your response.  I
>responded the first time off list because I didn't want to get into an
>extended thread on this.
>
>You are not telling the IETF something that the IETF is not aware of
>or hasn't thought about.  If you want to see what the IETF WGs have
>had to say about this topic, look in the archives.  In particular you
>want to look at the PTOMAINE and GROW WG, more PTOMAINE.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "john smith" <[email-masked]>
Subject: Re: [Idr] A question on longest match 
Date: Fri, 04 Jun 2004 11:44:43 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>, "john smith" writes:
> 
> 
> >Back then this idea was known as "FIB compression" and if you like you
> >can search the archives for a lot of discussion on the issue and quite
> >a bit of measurement done at that time.
> >
> 
> It certainly is better than entring a "split brain" with NO_EXPORT :)

We're talking about two different things.  Automatic aggregation of
the FIB is safe to do under all circumstances.  Automatice aggregation
and reannouncement is not always safe.

> > > Or we are saying BGP is specifically meant only for vendors and 
> >operators
> > > who can cater to such hardware?
> >
> >
> >Providers can aggregate better but it requires better coordination
> >among providers.
> >
> 
> How has this got *anything* to do with coordination among providers?

If provider A has a aggregate and some customers are dual homed to
provider B, then provider B or downstream can't safely aggregate those
routes.  If any of those dual homed customers loosed connection to A
and most providers rightfully send traffic for the A aggregate to A,
then those customers don't have backup through B.

See 10 year old discussion on "hostile aggregation".

The modern twist on this is that the "provider coordination" these
days can be as simple as adding a BGP community.  We now have a BGP
communitity that can work across any number of AS crossings, the
NOPEER.  The classic example where this is a problem is the
non-aggregation of Australian routes in the US and Europe.
Unfortunately the NOPEER isn't being used enough so you need to use
the "clue club" (as someone who has contributed a lot to operations
has called it, or was it the "clue bat") with the provider origination
the route.  That too is a form of interprovider coordination, but not
one easily standardized.

That's what PTOMANE and GROW are all about.  Or a big part of it.

In the case of 4/8, there were a very small number of more specific.
In all likelyhood these are only the ones that really needed to be
there (or at least most of them) so you shouldn't touch them.

> It is upto the IETF to make the providers cordinate. Eitherways if the IETF 
> thinks the idea makes *any sense* then they should take a step in that 
> direction rather than say "too late".
> 
> If people can build terabit routers which can switch millions of packets and 
> have a huge FIB, they can figure out ways to reduce the FIB size too. It is 
> a matter of what the "specs" say.
> 
> Are specs *not* made for scalaibilty? To quote someone from another list, is 
> it not the job of the *specs* to say what is *techincally correct*?

Not to be rude but I chopped off the rest of your response.  I
responded the first time off list because I didn't want to get into an
extended thread on this.

You are not telling the IETF something that the IETF is not aware of
or hasn't thought about.  If you want to see what the IETF WGs have
had to say about this topic, look in the archives.  In particular you
want to look at the PTOMAINE and GROW WG, more PTOMAINE.

Thanks for the advice.  :-)

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] A question on longest match
Date: Fri, 04 Jun 2004 06:22:29 +0000
Cc: [email-masked]
Sender: [email-masked]

Hi Curtis,

> >
> > Please check the specific examples I emailed you offline. Or for that 
>matter
> > please check any node on the internet. In most cases the reduction is 
>quite
> > a bit.
>
>
>Yes I did.  You pointed to the 4/8 prefix and some more specific, none
>of which were contiguous.  You also pointed to a block that started at
>x.x.211/24 and fell under a /16 but I pointed out that a block
>starting at .211 doesn't compress well unless you fill the holes and
>then you just need the /16.
>

exactly.

>
> > >At this point there is no problem in doing so but the cost of FIB
> > >storage isn't that great and the slow down in route insertion/deletion
> > >would be a bad thing for the space reduction.  The time lookup is no
> > >issue either with modern hardware.
> > >
> >
> > So we are saying that we will not have more routes?
>
>
>There will be more routes.  I did the analysis when there were less
>than 20,000 routes.  There are now 300,000 routes or more depending on
>who you talk to.
>
Agreed.
The point is that other than BGP no other protocol has to rely so heavily on 
the paradigm of longest match. Mainly as BGP has to carry that information.

It really is not a problem to find a route-server equivalent PC which can 
store a considerable amount of routes without adding an expense to it.

The problem is that out of those 300,000 routes, a lot of them are very 
redundant and I certainly do not appreciate vendors coming out with "1 
million routes in the forwarding table" models for no rhyme or reason.

Even if we add up the existing deployment of routers, most of them are 
sufficient to handle the existing prefixes when aggregated for a 
considerable amount of time.

>Back then this idea was known as "FIB compression" and if you like you
>can search the archives for a lot of discussion on the issue and quite
>a bit of measurement done at that time.
>

It certainly is better than entring a "split brain" with NO_EXPORT :)

>
> > Or we are saying BGP is specifically meant only for vendors and 
>operators
> > who can cater to such hardware?
>
>
>Providers can aggregate better but it requires better coordination
>among providers.
>

How has this got *anything* to do with coordination among providers?

It is upto the IETF to make the providers cordinate. Eitherways if the IETF 
thinks the idea makes *any sense* then they should take a step in that 
direction rather than say "too late".

If people can build terabit routers which can switch millions of packets and 
have a huge FIB, they can figure out ways to reduce the FIB size too. It is 
a matter of what the "specs" say.

Are specs *not* made for scalaibilty? To quote someone from another list, is 
it not the job of the *specs* to say what is *techincally correct*?

>It is up to providers to decide how they configure their routers.
>Having worked very closely with many router vendors over the last 12
>years, and working at one now, I can tell you that the RIB with lots
>of peers is a much bigger problem than the size of the FIB.
>

Is that the reason why they want to prefix limit?

For that matter, may I be bold enough to ask what *high speed FIB* the merit 
route servers were using?

>There is nothing to stop a vendor from compressing the FIB if they
>think that will make a better routers.  It just happens that none do
>it an IMHO it would not be a good idea to do so.
>
You contradict the statement below :) where you say you thought of it first.

You could probably do a quick search on google and you will find lots of 
folks who have asked for summarization feature of BGP routes.

>
> > >When you do packet filtering (all core routers need to be able to do
> > >this on all interface types because private peerings can be over
> > >OC192c POS) you have to keep a FIB for the router and then you have to
> > >apply the packet filtering rules per interface.  That already
> > >increases the work (the same card can have one processor but more than
> > >one interface, even OC192c or 10GbE).
> >
> >
> > I think most people tend to do:
> > ip route <RFC1918> null0
> >
> > and if they want to use *some RFC 1918 address space* internally, they 
>put a
> > route to pass that space as a more specific. That definately is not an 
>issue
> > which hampers this.
> >
> > Eitherways this is definately *not* packet filtering.
>
>
>At peer and most customer boundaries, most providers also do things
>like block all traffic destined to port numbers for OSPF, BGP, SNMP,
>and a few others except their EBGP peerings.  Some put other packet
>filters in place, many on source address to prevent spoofing.  It to
>some extent depends on what their routers can do.
>

agreed. The answer was specific to your question.

>Filtering is often applied on a per interface basis.  It is at least
>different for outward facing interfaces (connected to peers or
>customers) than inward facing (connected to the core).  For a router
>with lots of interfaces this is added work.  It is not an important
>point though but it does affect convergence a little if there is lot
>of filtering that has to be applied after the RP sends the FIB.
>

?? How has that got anything to do with the question?

>
> > >Anything which further multiplies the change to the FIB makes route
> > >convergence slower and that is a big issue today.  Its not the size of
> > >the FIB that matters today its trying to process the amount of change
> > >that can occur in the "well under 1 second" time frame that providers
> > >are looking for.
> > >
> >
> > So can we have something to the effect of:
> > "if there is a terrible impact in performance such a feature should be
> > turned off but if not, it makes sense" ?
> >
> > How it is done can be an implementation issue.
>
>
>Its up to the providers to decide which trafeoff is more important.
>No provider has been telling me that they want their routers to do
>more computation and eat more memory in the RP to compress the FIB
>such that the line cards can have less entries.  If you are a
>provider, talk to your router vendor if you think that's a good
>tradeoff.  If you are a vendor, talk to providers and see it they are
>interested.  AFAIK there is not interest in FIB compression.
>

As i said, please do a google on the same. The question is simple, does the 
WG intend to scale in a suitable manner or not?

>
>ps - but if FIB compression takes off I can claim to have thought of
>the idea first.  :-)  But I honestly don't think it will.

:-) how many providers did you speak to?
Eitherways, I believe it can be specified in the draft, how it is handled 
can be an implementation issue.

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "john smith" <[email-masked]>
Subject: Re: [Idr] A question on longest match 
Date: Thu, 03 Jun 2004 17:55:53 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

John,

I dropped the IDR Cc but I see you added it back.

Comments inline.

Curtis

In message <[email-masked]>, "john smith" writes:
> Hello Curtis,
> 
> 
> > > Hello Curtis,
> > >
> > > That is strange indeed.
> > >
> > > I have seen very different results when doing the same.
> > >
> > > I am not talking about aggregating over holes at all.
> > >
> > > I am simply saying,
> > >
> > > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the
> > > other.
> > >
> > > Most of these as far as I can see can be aggregated, but are still
> > > advertised as they are due to the presence of longest match paradigm
> > >
> > > However, I guess this is specific to my view,
> > >
> > > Though, why is there a problem in doing so?
> >
> >
> >The issue is really what gains can be made for the router with 300,000
> >prefixes in the FIB.  I did the analysis when the number of global
> >routes was well under 20,000 and the gains where not all that great
> >unless you aggregated over the holes.
> >
> 
> Please check the specific examples I emailed you offline. Or for that matter 
> please check any node on the internet. In most cases the reduction is quite 
> a bit.

Yes I did.  You pointed to the 4/8 prefix and some more specific, none
of which were contiguous.  You also pointed to a block that started at
x.x.211/24 and fell under a /16 but I pointed out that a block
starting at .211 doesn't compress well unless you fill the holes and
then you just need the /16.

> >At this point there is no problem in doing so but the cost of FIB
> >storage isn't that great and the slow down in route insertion/deletion
> >would be a bad thing for the space reduction.  The time lookup is no
> >issue either with modern hardware.
> >
> 
> So we are saying that we will not have more routes?

There will be more routes.  I did the analysis when there were less
than 20,000 routes.  There are now 300,000 routes or more depending on
who you talk to.

Back then this idea was known as "FIB compression" and if you like you
can search the archives for a lot of discussion on the issue and quite
a bit of measurement done at that time.

> Or we are saying BGP is specifically meant only for vendors and operators 
> who can cater to such hardware?

Providers can aggregate better but it requires better coordination
among providers.

It is up to providers to decide how they configure their routers.
Having worked very closely with many router vendors over the last 12
years, and working at one now, I can tell you that the RIB with lots
of peers is a much bigger problem than the size of the FIB.

There is nothing to stop a vendor from compressing the FIB if they
think that will make a better routers.  It just happens that none do
it an IMHO it would not be a good idea to do so.

> >When you do packet filtering (all core routers need to be able to do
> >this on all interface types because private peerings can be over
> >OC192c POS) you have to keep a FIB for the router and then you have to
> >apply the packet filtering rules per interface.  That already
> >increases the work (the same card can have one processor but more than
> >one interface, even OC192c or 10GbE).
> 
> 
> I think most people tend to do:
> ip route <RFC1918> null0
> 
> and if they want to use *some RFC 1918 address space* internally, they put a 
> route to pass that space as a more specific. That definately is not an issue 
> which hampers this.
> 
> Eitherways this is definately *not* packet filtering.

At peer and most customer boundaries, most providers also do things
like block all traffic destined to port numbers for OSPF, BGP, SNMP,
and a few others except their EBGP peerings.  Some put other packet
filters in place, many on source address to prevent spoofing.  It to
some extent depends on what their routers can do.

Filtering is often applied on a per interface basis.  It is at least
different for outward facing interfaces (connected to peers or
customers) than inward facing (connected to the core).  For a router
with lots of interfaces this is added work.  It is not an important
point though but it does affect convergence a little if there is lot
of filtering that has to be applied after the RP sends the FIB.

> >Anything which further multiplies the change to the FIB makes route
> >convergence slower and that is a big issue today.  Its not the size of
> >the FIB that matters today its trying to process the amount of change
> >that can occur in the "well under 1 second" time frame that providers
> >are looking for.
> >
> 
> So can we have something to the effect of:
> "if there is a terrible impact in performance such a feature should be 
> turned off but if not, it makes sense" ?
> 
> How it is done can be an implementation issue.

Its up to the providers to decide which trafeoff is more important.
No provider has been telling me that they want their routers to do
more computation and eat more memory in the RP to compress the FIB
such that the line cards can have less entries.  If you are a
provider, talk to your router vendor if you think that's a good
tradeoff.  If you are a vendor, talk to providers and see it they are
interested.  AFAIK there is not interest in FIB compression.

ps - but if FIB compression takes off I can claim to have thought of
the idea first.  :-)  But I honestly don't think it will.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: RE: [Idr] Question about RFC 3107 Carrying label in bgp-4
Date: Thu, 03 Jun 2004 20:24:50 +0000
Sender: [email-masked]

>In Section 4, it states that multiple routes to the
>same destination, but different labels can be
>maintained and advertised.

As if one route was not enough :)...........

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Thu, 3 Jun 2004 16:06:41 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] missing text
Sender: [email-masked]

On Thu, Jun 03, 2004 at 06:50:19AM -0700, Yakov Rekhter wrote:
> So, to fix this I'd like to propose to add at the end of the above
> text the following:
> 
>          3) if the AS_PATH is empty, the local system creates
>          a path segment of type AS_SEQUENCE, places its own AS
>          into that segment, and places that segment into the AS_PATH.

This looks fine to me.

-- 
Jeff Haas 
NextHop Technologies

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] A question on longest match
Date: Thu, 03 Jun 2004 16:53:13 +0000
Cc: [email-masked]
Sender: [email-masked]

Hello Curtis,

> > Hello Curtis,
> >
> > That is strange indeed.
> >
> > I have seen very different results when doing the same.
> >
> > I am not talking about aggregating over holes at all.
> >
> > I am simply saying,
> >
> > I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the
> > other.
> >
> > Most of these as far as I can see can be aggregated, but are still
> > advertised as they are due to the presence of longest match paradigm
> >
> > However, I guess this is specific to my view,
> >
> > Though, why is there a problem in doing so?
>
>
>The issue is really what gains can be made for the router with 300,000
>prefixes in the FIB.  I did the analysis when the number of global
>routes was well under 20,000 and the gains where not all that great
>unless you aggregated over the holes.
>

Please check the specific examples I emailed you offline. Or for that matter 
please check any node on the internet. In most cases the reduction is quite 
a bit.

>At this point there is no problem in doing so but the cost of FIB
>storage isn't that great and the slow down in route insertion/deletion
>would be a bad thing for the space reduction.  The time lookup is no
>issue either with modern hardware.
>

So we are saying that we will not have more routes?

Or we are saying BGP is specifically meant only for vendors and operators 
who can cater to such hardware?

>When you do packet filtering (all core routers need to be able to do
>this on all interface types because private peerings can be over
>OC192c POS) you have to keep a FIB for the router and then you have to
>apply the packet filtering rules per interface.  That already
>increases the work (the same card can have one processor but more than
>one interface, even OC192c or 10GbE).

I think most people tend to do:
ip route <RFC1918> null0

and if they want to use *some RFC 1918 address space* internally, they put a 
route to pass that space as a more specific. That definately is not an issue 
which hampers this.

Eitherways this is definately *not* packet filtering.

>
>Anything which further multiplies the change to the FIB makes route
>convergence slower and that is a big issue today.  Its not the size of
>the FIB that matters today its trying to process the amount of change
>that can occur in the "well under 1 second" time frame that providers
>are looking for.
>

So can we have something to the effect of:
"if there is a terrible impact in performance such a feature should be 
turned off but if not, it makes sense" ?

How it is done can be an implementation issue.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: [email-masked]
Content-Class: urn:content-classes:message
Date: Thu, 3 Jun 2004 11:21:03 -0500
To: <[email-masked]>
Subject: [Idr] Question about RFC 3107 Carrying label in bgp-4 
Sender: [email-masked]

Hi,

I will use 
  192.168.0.0/16   as an ip prefix, and
  0x102031         as an mpls label
in the following questions.

RFC 3107 (Carrying Label Information in BGP-4) 
Section 3 states 
0x102031:192.168.0.0/16 can be advertised in a
MP_REACH_NLRI. 
It can be withdrawn by either 
 a) a new route with a new label:
    0xB1B2B3:192.168.0.0/16 in MP_REACG_NLRI
or
 b) 0x800000:192.168.0.0/16 in a MP_UNREACH_NLRI.

In Section 4, it states that multiple routes to the
same destination, but different labels can be
maintained and advertised. 

This seams to contradict to Section 3 a).
If Section 3 a) is used, both routes would have
been kept by peer, instead of deleting
  0x102031:192.168.0.0/16 and keeping
  0xB1B2B3:192.168.0.0/16.

Section 4 also states that
  a peer would keep both
  192.168.0.0/16 and 0x102031:192.168.0.0/16 
  if 192.168.0.0/16 is advertised with 
   (AFI=1, SAFI=1) and
  0x102031:192.168.0.0/16 is advertised with
   (AFI=1, SAFI=4).

Does this contradicts to BGP's general principle that
only one route from a peer is kept?

Does this also implicitly mean that
0x102031:192.168.0.0/16 cannot be used for regular
ipv4 unicast routing?

It looks to me that the entire Section 4 is
contradictory.

--
Qi Ning

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Thu, 03 Jun 2004 06:50:19 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] missing text
Sender: [email-masked]

Folks,

As John Scudder pointed recently the following text in 5.1.2 is 
incomplete, as it does not cover the case when the route that
is to be advertised was received with empty AS_PATH attribute
(this could happen if the route was originated elsewhere in the AS 
and received via IBGP):

    b) When a given BGP speaker advertises the route to an external
       peer, then the advertising speaker updates the AS_PATH attribute
       as follows:

          1) if the first path segment of the AS_PATH is of type
          AS_SEQUENCE, the local system prepends its own AS number as the
          last element of the sequence (put it in the leftmost position
          with respect to the position of octets in the protocol mes-
          sage). If the act of prepending will cause an overflow in the
          AS_PATH segment, i.e. more than 255 ASs, it SHOULD prepend a
          new segment of type AS_SEQUENCE and prepend its own AS number
          to this new segment.

          2) if the first path segment of the AS_PATH is of type AS_SET,
          the local system prepends a new path segment of type
          AS_SEQUENCE to the AS_PATH, including its own AS number in that
          segment.

So, to fix this I'd like to propose to add at the end of the above
text the following:

         3) if the AS_PATH is empty, the local system creates
         a path segment of type AS_SEQUENCE, places its own AS
         into that segment, and places that segment into the AS_PATH.

Please comment on this. The deadline for comments is June 17, 2004.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: [email-masked]
Date: Thu, 03 Jun 2004 06:24:43 -0700
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] proposed additional text in the Security Section
Sender: [email-masked]

Folks,

Based on the feedback we received so far the text in the attached
will be added "as is" to the Security Considerations section of
the BGP spec (and the Reference section will be updated as appropriate).

Yakov.
------- Forwarded Message

Date:    Mon, 24 May 2004 07:32:55 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] proposed additional text

Folks,

Steve Kent proposed the following replacement for the text he suggested
earlier (the text I posted on 5/17/2004). 

   BGP makes use of TCP for reliable transport of its traffic between
   peer routers. To provide connection-oriented integrity and data
   origin authentication, on a point-to-point basis, BGP specifies
   use of the mechanism defined in RFC 2385. These services are intended
   to detect and reject active wiretapping attacks against the
   inter-router TCP connections. Absent use of mechanisms that effect
   these security services, attackers can disrupt these TCP connections
   and/or masquerade as a legitimate peer router. Because the mechanism
   defined in the RFC does not provide peer-entity authentication,
   these connections may be subject to some forms of replay attacks
   that will not be detected at the TCP layer. Such attacks might
   result in delivery (from TCP) of "broken" or "spoofed" BGP messages.
   
   The mechanism defined in RFC 2385 augments the normal TCP checksum
   with a 16-byte message authentication code (MAC) that is computed
   over the same data as the TCP checksum. This MAC is based on a
   one-way hash function (MD5) and use of a secret key. The key is
   shared between peer routers and is used to generate MAC values that
   are not readily computed by an attacker who does not have access
   to the key. A compliant implementation must support this mechanism,
   and must allow a network administrator to activate it on a per-peer
   basis.
   
   RFC 2385 does not specify a means of managing (e.g., generating,
   distributing, and replacing) the keys used to compute the MAC. RFC
   3562 (an informational document) provides some guidance in this
   area, and provides rationale to support this guidance. It notes
   that a distinct key should be used for communication with each
   protected peer. If the same key is used for multiple peers, the
   offered security services may be degraded, e.g., due to increased
   risk of compromise at one router adversely affecting other routers.
   
   The keys used for MAC computation should be changed periodically,
   to minimize the impact of a key compromise or successful cryptanalytic
   attack. RFC 3562 suggest a crypto period (the interval during which
   a key is employed) of at most 90 days. More frequent key changes
   reduce the likelihood that replay attacks (as described above) will
   be feasible. However, absent a standard mechanism for effecting
   such changes in a coordinated fashion between peers, one cannot
   assume that BGP-4 implementations complying with this RFC will
   support frequent key changes.
   
   Obviously, each  key also should be chosen so as to be hard for an
   attacker to guess.  The techniques specified in RFC 1750 for random
   number generation provide a guide for generation of values that
   could be used as keys. RFC 2385 calls for implementations to support
   keys "composed of a string of printable ASCII of 80 bytes or less."
   RFC 3562 suggests keys used in this context be 12 to 24 bytes
   of random (pseudo-random) bits. This is fairly consistent with
   suggestions for analogous MAC algorithms, which typically employ
   keys in the range of 16-20 bytes. RFC 3562 also observes that, to
   provide enough random bits at the low end of this range, a typical
   ACSII text string would have to be close to the upper bound for
   key length specified in RFC 2385.

Please review and comment. The deadline for comments is 6/2/2004.

Yakov.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

------- End of Forwarded Message

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] A question on longest match
Date: Thu, 03 Jun 2004 08:16:44 +0000
Sender: [email-masked]

>Its not worth it to aggregate the FIB.  There is very little gain if
>you don't aggregate over holes.

Curtis, the nodes where the holes occur are way down in the network.

Infact the places where they do occur happen to be places where /24 networks 
may actually be connected.

The offset for the same is the fact that the rest of the internet as seen 
from that point is "coniguous".  So it offsets the same.
This has been my observation.

>
>If you aggregate over holes you'd need to include more specific reject
>routes.
>

I do not aggregate over holes. I suggest aggregate "what one can as long as 
the next-hop is the same" and populate the FIB.
I agree it makes more sense to aggregate and propogate, but if not that, can 
we atleast aggregate what goes into the FIB?

>If you aggregate the FIB and a withdraw occurs you need to add a
>reject.  You then need to be concerned about aggregating the rejects
>that you are adding.
>

I could also break the aggregate at that point of time.

I still have the specifics in the RIB rememeber?

>Gain is small.  There is an increase in completity.
>

It can be the same for *all protocols* Gain can be immense I think.

>Disallowing longest to allow automatic aggregation was discussed on
>BGP, BGPD, CIDR, or CIDRD more than 10 years ago.  We didn't go that
>way and its way too late to turn back.
>

:)

>Curtis

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] A question on longest match
Date: Thu, 03 Jun 2004 06:16:26 +0000
Cc: [email-masked]
Sender: [email-masked]

Hello Curtis,

That is strange indeed.

I have seen very different results when doing the same.

I am not talking about aggregating over holes at all.

I am simply saying,

I receive 20 prefixes of say /19 from 1 link and 40 of say /20 from the 
other.

Most of these as far as I can see can be aggregated, but are still 
advertised as they are due to the presence of longest match paradigm

However, I guess this is specific to my view,

Though, why is there a problem in doing so?

>
>Its not worth it to aggregate the FIB.  There is very little gain if
>you don't aggregate over holes.
>
>If you aggregate over holes you'd need to include more specific reject
>routes.
>
>If you aggregate the FIB and a withdraw occurs you need to add a
>reject.  You then need to be concerned about aggregating the rejects
>that you are adding.
>
>Gain is small.  There is an increase in completity.
>
>Disallowing longest to allow automatic aggregation was discussed on
>BGP, BGPD, CIDR, or CIDRD more than 10 years ago.  We didn't go that
>way and its way too late to turn back.
>
>Curtis

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

To: "john smith" <[email-masked]>
Subject: Re: [Idr] A question on longest match 
Date: Wed, 02 Jun 2004 15:34:21 -0400
From: Curtis Villamizar <[email-masked]>
Cc: [email-masked], [email-masked]
Reply-To: [email-masked]
Sender: [email-masked]

In message <[email-masked]>, "john smith" writes:
> Thanks Howard,
> 
> My question is more specific to the paradigm of longest match.
> 
> In most cases, we have:
> 
> (Routing protocols)-->Best 
> routes_based_on_metric/prefix_size/protocol_metric/foobar-->RIB-->FIB
> 
> My question specifically is that do most vendors aggregate the entries when 
> they go from the RIB to the FIB?
> 
> The problem specifically cropped up when I realised that some peers were 
> sending multiple /24s (even though they were contiguous) to a node I was 
> working on though the next-hop was the same.
> 
> I was wondering if there is an "aggregation" performed based on next-hop 
> when putting routes into the FIB.
> 
> Of course a more pragmatic approach is ofcourse to enforce aggregation 
> rather than have a prefix range propogation.
> 
> However, I assume the biggest problem is the population of the FIB and hence 
> the need for prefix range filtering.
> 
> Would it not be easier, for starters, to simply aggregate routes based on 
> next-hop when populating the FIB?
> 
> this would not even break the longest match method used to balance links, 
> but would solve the FIB explosion problem.
> 
> -John

Its not worth it to aggregate the FIB.  There is very little gain if
you don't aggregate over holes.

If you aggregate over holes you'd need to include more specific reject
routes.

If you aggregate the FIB and a withdraw occurs you need to add a
reject.  You then need to be concerned about aggregating the rejects
that you are adding.

Gain is small.  There is an increase in completity.

Disallowing longest to allow automatic aggregation was discussed on
BGP, BGPD, CIDR, or CIDRD more than 10 years ago.  We didn't go that
way and its way too late to turn back.

Curtis

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [Idr] A question on longest match
Date: Wed, 02 Jun 2004 05:53:18 +0000
Cc: 
Sender: [email-masked]

Thanks Howard,

My question is more specific to the paradigm of longest match.

In most cases, we have:

(Routing protocols)-->Best 
routes_based_on_metric/prefix_size/protocol_metric/foobar-->RIB-->FIB

My question specifically is that do most vendors aggregate the entries when 
they go from the RIB to the FIB?

The problem specifically cropped up when I realised that some peers were 
sending multiple /24s (even though they were contiguous) to a node I was 
working on though the next-hop was the same.

I was wondering if there is an "aggregation" performed based on next-hop 
when putting routes into the FIB.

Of course a more pragmatic approach is ofcourse to enforce aggregation 
rather than have a prefix range propogation.

However, I assume the biggest problem is the population of the FIB and hence 
the need for prefix range filtering.

Would it not be easier, for starters, to simply aggregate routes based on 
next-hop when populating the FIB?

this would not even break the longest match method used to balance links, 
but would solve the FIB explosion problem.

-John

>From: "Howard C. Berkowitz" <[email-masked]>
>To: [email-masked]
>Subject: RE: [Idr] A question on longest match
>Date: Tue, 1 Jun 2004 14:43:01 -0400
>
>At 8:19 AM +0000 6/1/04, john smith wrote:
>>Hello Big Brother,
>>
>>It is specifically releated to BGP.
>>
>>Aggregation in non DV protocols is not a possibility unless one goes 
>>across Area/Level boundarys.
>
>Maybe I'm missing something, but I wouldn't make that claim. Hierarchical 
>topology and multiple levels are not a requirement of routing protocols. 
>Many large ISPs run very big single ISIS areas. So, there very well may not 
>be Area/Level boundaries to cross.
>
>Hierarchical information hiding MAY be a useful deployment technique in LS 
>protocols to reduce the computational load of the Dijkstra algorithm, but 
>it's perfectly reasonable and plausible to build hierarchical networks in 
>protocols as simple as RIPv1 -- start with Class C (usually private space) 
>at the edge and work up, eventually going to Class B.
>
>>
>>This is due to their inherent nature of sending advertisements of "all 
>>connected networks" to "all nodes in the same level or area".
>>
>>Now you do believe aggregation is good, do you not? I am sure you do!
>>
>>Now to further that assumption, if aggregation is good, and one was to 
>>make a forwarding device which would not do Layer 3 lookup based on the 
>>bit aligned boundaries, but on ranges, would it be considered bad or good?
>>
>>Also please let me know if this is not an item to dicuss on idr, or should 
>>the be specifically targetted to the routing-discussion mailing list? In 
>>that case I shall not cc the list further on these queries.
>>
>>--
>>(&)
>>Little John.
>>
>>>From: "John Smith" <[email-masked]>
>>>To: <[email-masked]>
>>>Subject: RE: [Idr] A question on longest match
>>>Date: Tue, 1 Jun 2004 13:43:25 +0530
>>>
>>>Is your question related to BGP or is it related to general routing
>>>(networking) principles?
>>>
>>>If its the latter then you need to start with a good book on basic
>>>networking principles (unless ofcourse i am missing your point 
>>>altogether!)
>>>and if its the latter, then it doesn't make much sense to me ! Care to
>>>elaborate?
>>>
>>>--
>>>(&)
>>>Big brother John
>>>
>>>----- Original Message -----
>>>From: "john smith" <[email-masked]>
>>>To: <[email-masked]>
>>>Sent: Tuesday, June 01, 2004 1:19 PM
>>>Subject: [Idr] A question on longest match
>>>
>>>
>>>>  Hello,
>>>>
>>>>  Is there any specific reason why the BGP algorithm relies on the 
>>>>longest
>>>>  match paradigm?
>>>>
>>>>  Is there any reason why one cannot simply propogate the "range of
>>>addresses"
>>>>  and use different metrics?
>>>>  For example one could say "address numbers 100000 - 212123 are here 
>>>>and
>>>>  212124 - 312127 are there?
>>>>
>>>>  Would this not lead to considerable reduction of the size of the
>>>forwarding
>>>>  table?
>>>>
>>>>  --
>>>>  (&)
>>>>  Little John.
>>>>
>>>>  _________________________________________________________________
>>>>  Add photos to your messages with MSN 8. Get 2 months FREE*.
>>>>  http://join.msn.com/?page=features/featuredemail
>>>>
>>>>
>>>>  _______________________________________________
>>>>  Idr mailing list
>>>>  [email-masked]
>>>>  https://www1.ietf.org/mailman/listinfo/idr
>>>>
>>>
>>
>>_________________________________________________________________
>>The new MSN 8: advanced junk mail protection and 2 months FREE* 
>>http://join.msn.com/?page=features/junkmail
>>
>>
>>_______________________________________________
>>Idr mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/idr
>
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 1 Jun 2004 14:43:01 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: RE: [Idr] A question on longest match
Sender: [email-masked]

At 8:19 AM +0000 6/1/04, john smith wrote:
>Hello Big Brother,
>
>It is specifically releated to BGP.
>
>Aggregation in non DV protocols is not a possibility unless one goes 
>across Area/Level boundarys.

Maybe I'm missing something, but I wouldn't make that claim. 
Hierarchical topology and multiple levels are not a requirement of 
routing protocols. Many large ISPs run very big single ISIS areas. 
So, there very well may not be Area/Level boundaries to cross.

Hierarchical information hiding MAY be a useful deployment technique 
in LS protocols to reduce the computational load of the Dijkstra 
algorithm, but it's perfectly reasonable and plausible to build 
hierarchical networks in protocols as simple as RIPv1 -- start with 
Class C (usually private space) at the edge and work up, eventually 
going to Class B.

>
>This is due to their inherent nature of sending advertisements of 
>"all connected networks" to "all nodes in the same level or area".
>
>Now you do believe aggregation is good, do you not? I am sure you do!
>
>Now to further that assumption, if aggregation is good, and one was 
>to make a forwarding device which would not do Layer 3 lookup based 
>on the bit aligned boundaries, but on ranges, would it be considered 
>bad or good?
>
>Also please let me know if this is not an item to dicuss on idr, or 
>should the be specifically targetted to the routing-discussion 
>mailing list? In that case I shall not cc the list further on these 
>queries.
>
>--
>(&)
>Little John.
>
>>From: "John Smith" <[email-masked]>
>>To: <[email-masked]>
>>Subject: RE: [Idr] A question on longest match
>>Date: Tue, 1 Jun 2004 13:43:25 +0530
>>
>>Is your question related to BGP or is it related to general routing
>>(networking) principles?
>>
>>If its the latter then you need to start with a good book on basic
>>networking principles (unless ofcourse i am missing your point altogether!)
>>and if its the latter, then it doesn't make much sense to me ! Care to
>>elaborate?
>>
>>--
>>(&)
>>Big brother John
>>
>>----- Original Message -----
>>From: "john smith" <[email-masked]>
>>To: <[email-masked]>
>>Sent: Tuesday, June 01, 2004 1:19 PM
>>Subject: [Idr] A question on longest match
>>
>>
>>>  Hello,
>>>
>>>  Is there any specific reason why the BGP algorithm relies on the longest
>>>  match paradigm?
>>>
>>>  Is there any reason why one cannot simply propogate the "range of
>>addresses"
>>>  and use different metrics?
>>>  For example one could say "address numbers 100000 - 212123 are here and
>>>  212124 - 312127 are there?
>>>
>>>  Would this not lead to considerable reduction of the size of the
>>forwarding
>>>  table?
>>>
>>>  --
>>>  (&)
>>>  Little John.
>>>
>>>  _________________________________________________________________
>>>  Add photos to your messages with MSN 8. Get 2 months FREE*.
>>>  http://join.msn.com/?page=features/featuredemail
>>>
>>>
>>>  _______________________________________________
>>>  Idr mailing list
>>>  [email-masked]
>>>  https://www1.ietf.org/mailman/listinfo/idr
>>>
>>
>
>_________________________________________________________________
>The new MSN 8: advanced junk mail protection and 2 months FREE* 
>http://join.msn.com/?page=features/junkmail
>
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

Date: Tue, 1 Jun 2004 12:44:38 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: RE: [Idr] A question on longest match
Sender: [email-masked]

At 8:19 AM +0000 6/1/04, john smith wrote:
>Hello Big Brother,
>
>It is specifically releated to BGP.
>
>Aggregation in non DV protocols is not a possibility unless one goes 
>across Area/Level boundarys.

Maybe I'm missing something, but I wouldn't make that claim. 
Hierarchical topology and multiple levels are not a requirement of 
routing protocols. Many large ISPs run very big single ISIS areas. 
So, there very well may not be Area/Level boundaries to cross.

Hierarchical information hiding MAY be a useful deployment technique 
in LS protocols to reduce the computational load of the Dijkstra 
algorithm, but it's perfectly reasonable and plausible to build 
hierarchical networks in protocols as simple as RIPv1 -- start with 
Class C (usually private space) at the edge and work up, eventually 
going to Class B.

>
>This is due to their inherent nature of sending advertisements of 
>"all connected networks" to "all nodes in the same level or area".
>
>Now you do believe aggregation is good, do you not? I am sure you do!
>
>Now to further that assumption, if aggregation is good, and one was 
>to make a forwarding device which would not do Layer 3 lookup based 
>on the bit aligned boundaries, but on ranges, would it be considered 
>bad or good?
>
>Also please let me know if this is not an item to dicuss on idr, or 
>should the be specifically targetted to the routing-discussion 
>mailing list? In that case I shall not cc the list further on these 
>queries.
>
>--
>(&)
>Little John.
>
>>From: "John Smith" <[email-masked]>
>>To: <[email-masked]>
>>Subject: RE: [Idr] A question on longest match
>>Date: Tue, 1 Jun 2004 13:43:25 +0530
>>
>>Is your question related to BGP or is it related to general routing
>>(networking) principles?
>>
>>If its the latter then you need to start with a good book on basic
>>networking principles (unless ofcourse i am missing your point altogether!)
>>and if its the latter, then it doesn't make much sense to me ! Care to
>>elaborate?
>>
>>--
>>(&)
>>Big brother John
>>
>>----- Original Message -----
>>From: "john smith" <[email-masked]>
>>To: <[email-masked]>
>>Sent: Tuesday, June 01, 2004 1:19 PM
>>Subject: [Idr] A question on longest match
>>
>>
>>>  Hello,
>>>
>>>  Is there any specific reason why the BGP algorithm relies on the longest
>>>  match paradigm?
>>>
>>>  Is there any reason why one cannot simply propogate the "range of
>>addresses"
>>>  and use different metrics?
>>>  For example one could say "address numbers 100000 - 212123 are here and
>>>  212124 - 312127 are there?
>>>
>>>  Would this not lead to considerable reduction of the size of the
>>forwarding
>>>  table?
>>>
>>>  --
>>>  (&)
>>>  Little John.
>>>
>>>  _________________________________________________________________
>>>  Add photos to your messages with MSN 8. Get 2 months FREE*.
>>>  http://join.msn.com/?page=features/featuredemail
>>>
>>>
>>>  _______________________________________________
>>>  Idr mailing list
>>>  [email-masked]
>>>  https://www1.ietf.org/mailman/listinfo/idr
>>>
>>
>
>_________________________________________________________________
>The new MSN 8: advanced junk mail protection and 2 months FREE* 
>http://join.msn.com/?page=features/junkmail
>
>
>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: RE: [Idr] A question on longest match
Date: Tue, 01 Jun 2004 08:19:09 +0000
Cc: [email-masked]
Sender: [email-masked]

Hello Big Brother,

It is specifically releated to BGP.

Aggregation in non DV protocols is not a possibility unless one goes across 
Area/Level boundarys.

This is due to their inherent nature of sending advertisements of "all 
connected networks" to "all nodes in the same level or area".

Now you do believe aggregation is good, do you not? I am sure you do!

Now to further that assumption, if aggregation is good, and one was to make 
a forwarding device which would not do Layer 3 lookup based on the bit 
aligned boundaries, but on ranges, would it be considered bad or good?

Also please let me know if this is not an item to dicuss on idr, or should 
the be specifically targetted to the routing-discussion mailing list? In 
that case I shall not cc the list further on these queries.

--
(&)
Little John.

>From: "John Smith" <[email-masked]>
>To: <[email-masked]>
>Subject: RE: [Idr] A question on longest match
>Date: Tue, 1 Jun 2004 13:43:25 +0530
>
>Is your question related to BGP or is it related to general routing
>(networking) principles?
>
>If its the latter then you need to start with a good book on basic
>networking principles (unless ofcourse i am missing your point altogether!)
>and if its the latter, then it doesn't make much sense to me ! Care to
>elaborate?
>
>--
>(&)
>Big brother John
>
>----- Original Message -----
>From: "john smith" <[email-masked]>
>To: <[email-masked]>
>Sent: Tuesday, June 01, 2004 1:19 PM
>Subject: [Idr] A question on longest match
>
>
> > Hello,
> >
> > Is there any specific reason why the BGP algorithm relies on the longest
> > match paradigm?
> >
> > Is there any reason why one cannot simply propogate the "range of
>addresses"
> > and use different metrics?
> > For example one could say "address numbers 100000 - 212123 are here and
> > 212124 - 312127 are there?
> >
> > Would this not lead to considerable reduction of the size of the
>forwarding
> > table?
> >
> > --
> > (&)
> > Little John.
> >
> > _________________________________________________________________
> > Add photos to your messages with MSN 8. Get 2 months FREE*.
> > http://join.msn.com/?page=features/featuredemail
> >
> >
> > _______________________________________________
> > Idr mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/idr
> >
>
>

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

From: "john smith" <[email-masked]>
To: [email-masked]
Date: Tue, 01 Jun 2004 07:49:42 +0000
Subject: [Idr] A question on longest match
Sender: [email-masked]

Hello,

Is there any specific reason why the BGP algorithm relies on the longest 
match paradigm?

Is there any reason why one cannot simply propogate the "range of addresses" 
and use different metrics?
For example one could say "address numbers 100000 - 212123 are here and 
212124 - 312127 are there?

Would this not lead to considerable reduction of the size of the forwarding 
table?

--
(&)
Little John.

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr