Subject: Re: Aggregator clarification text for draft 12?
From: Alex Zinin <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Date: Thu, 31 May 2001 20:56:40 -0700

Jeffrey,

 This seems reasonable to me.
 I guess I know at least two or three more
 implementations that do the same.

-- 
Alex Zinin

Thursday, May 31, 2001, 2:20:21 PM, Jeffrey Haas wrote:

> This issue has come up as part of the bgp mib work and preparing
> for the bgp MIB v2.

> In draft-ietf-idr-bgp4-12.txt:

>          g) AGGREGATOR (Type Code 7)

>             AGGREGATOR is an optional transitive attribute of length 6.
>             The attribute contains the last AS number that formed the
>             aggregate route (encoded as 2 octets), followed by the IP
>             address of the BGP speaker that formed the aggregate route
>             (encoded as 4 octets).  Usage of this attribute is described
>             in 5.1.7

> Both this section, and 5.1.7 also refer to "IP Address".
> It is probably more proper to say "BGP Identifier".  This is how
> GateD implements this.  What about other implementations?

> Do other people believe that we should change the wording to
> BGP Identifier?

Date: Thu, 31 May 2001 17:42:53 -0500
From: [email-masked]
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

have revised opinion here:

> > Change to:
> > 
> >    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
> >    table. However, corresponding unfeasible routes MUST/SHOULD be kept
> >    in the Adj-RIBs-In.
> > 
> 
> I think 'SHOULD' is better.

It MUST be MUST

Date: Thu, 31 May 2001 17:20:21 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Aggregator clarification text for draft 12?
Sender: [email-masked]

This issue has come up as part of the bgp mib work and preparing
for the bgp MIB v2.

In draft-ietf-idr-bgp4-12.txt:

         g) AGGREGATOR (Type Code 7)

            AGGREGATOR is an optional transitive attribute of length 6.
            The attribute contains the last AS number that formed the
            aggregate route (encoded as 2 octets), followed by the IP
            address of the BGP speaker that formed the aggregate route
            (encoded as 4 octets).  Usage of this attribute is described
            in 5.1.7

Both this section, and 5.1.7 also refer to "IP Address".
It is probably more proper to say "BGP Identifier".  This is how
GateD implements this.  What about other implementations?

Do other people believe that we should change the wording to
BGP Identifier?

-- 
Jeff Haas 
NextHop Technologies

From: "ks s" <[email-masked]>
To: [email-masked]
Subject: bgp auth.
Date: Thu, 31 May 2001 18:53:26 -0000
Sender: [email-masked]

Hi

1. are there any implementations, which support the auth.
   as explained by rfc1771
2. whats the use of auth. in open packet, in lieu of rfc2385

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Thu, 31 May 2001 11:12:16 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Vivek Menezes <[email-masked]>
Cc: "'Manish Vora'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Vivek, Manish

 I agree. As I said in a previous e-mail, I'm removing
 the implementation hints from the text, including the pseudocode.

 So, from the perspective of route resolution, the only changes
 are that routes that would become unresolvable if installed
 SHOULD be considered unfeasible, and we give a new subsection with
 more info on what routes are considered resolvable, making a reservation
 that actual implementation details are left up to the coders.

 Are we in sync?

-- 
Alex Zinin

Thursday, May 31, 2001, 10:57:19 AM, Vivek Menezes wrote:

> hi Alex,

> I dont think we need to put in a solution for the problem. We should however
> at least 
> make a note of the problem in the RFC so that the reader is aware of the
> issues involved.
> What steps she might take to resolve the issue can be vendor specific.

> Cheers,
> Vivek.

>> -----Original Message-----
>> From: Manish Vora [mailto:[email-masked]]
>> Sent: Thursday, May 31, 2001 6:23 AM
>> To: Alex Zinin
>> Cc: Vivek Menezes; [email-masked]; [email-masked]
>> Subject: Re: Proposed text for 9.1.2
>> 
>> 
>> Alex,
>>     Please see comments inline ...
>> 
>> Alex Zinin wrote:
>> > 
>> > Vivek,
>> > 
>> > >> This "set" is the routing table and it is the current practice to
>> > >> get BGP routes installed there (vs IGP sync). So, how 
>> does the new
>> > >> community help?
>> > >>
>> > 
>> > > Well I was proposing a new set (or sub-set of the routing 
>> table) that only
>> > > consists of
>> > > IGP routes and "special" BGP routes only used for next 
>> hop resolution. If
>> > > you look at the
>> > > entire routing table, you are essentially colouring some 
>> routes in the
>> > > routing table. the
>> > > coloured routes are the only one used for BGP next hop 
>> resolution. System
>> > > configuration
>> > > "using the community" makes sure that there are no cycles 
>> among the coloured
>> > > nodes.
>> > 
>> > I see your point. I think it would be a bit too much
>> > for this problem, though. See below pls.
>> > 
>> > > Well you can look at it as a cycle in a graph. You can 
>> eliminate a cycle by
>> > > potentially
>> > > removing an arbitrary edge in the cycle. Unless you 
>> specify the edge
>> > > selection using  a  specified deterministic algorithm, 
>> you will run into
>> > > vendors selecting their own even
>> > > perhaps randomized algorithms for edge selection.
>> > 
>> > OK, the above is indeed possible in a generic case,
>> > where you have something like:
>> > 
>> >  x.0.0.0/8 via y.y.y.y
>> >  y.0.0.0/8 via z.z.z.z
>> >  z.0.0.0/8 via x.x.x.x
>> >  0.0.0.0/0 via a.a.a.a
>> > 
>> > Even though this is _very_ unlikely to be seen in a BGP scenario
>> > (since NHs are not arbitrary) and the real problem is different,
>> > not closing the loop and logging a message (even if it is not
>> > deterministic which prefix would be held back) is better than
>> > installing the route.
>> > 
>> > I believe that in majority of situations it will be deterministic,
>> > as the blocked route will loop to itself. It is not realistic to
>> > expect a more specific route covering some NH (most probably a
>> > route to the corresponding DMZ) to be resolved through a NH in
>> > another DMZ. However, I do not exclude other scenarios where
>> > people deploy BGP incorrectly, and the check helps there as well,
>> > actually.
>> > 
>> > Keep in mind that this mechanism is a protective measure 
>> for situations
>> > when something is _broken_. In this situation, it does not 
>> really matter
>> > which "broken" route you push back, they are all in the 
>> loop, and we are
>> > not trying to fix anything. What does matter is we do as 
>> less harm to
>> > ourselves and the network as possible and draw the admin's 
>> attention.
>> 
>> I agree that when things wrong .. any solution which avoids 
>> it is good 
>> enough. Trying to fix things in some manner is what an implementation
>> may choose to do .. based on what it can do efficiently. But should
>> the BGP standard propose a solution .. especially when its
>> non-deterministic ?
>> Thats something I am not too sure about. 
>> 
>> Thanks,
>> - Manish
>> 
>> > 
>> > > In order to make BGP
>> > > converge to the same set of routes the same route (edge) 
>> must be selected.
>> > > The deterministic algorithm would
>> > > then have to be a part of the spec.
>> > 
>> > > I'm opposed to having to deal with cycles in the first place.
>> > > Having BGP routes to resolve next hops is a very bad idea.
>> > 
>> > I guess we can't really avoid it, it is just there already.
>> > (But, conceptually, I also don't like BGP-through-BGP resolution :)
>> > 
>> > Bottom line---I'll change the text to accommodate the comments,
>> > will remove the pseudo-code and send the new text back to the list.
>> > 
>> > Thanks!
>> > 
>> > Alex.
>> 

From: Vivek Menezes <[email-masked]>
To: "'Manish Vora'" <[email-masked]>, Alex Zinin <[email-masked]>
Cc: Vivek Menezes <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed text for 9.1.2
Date: Thu, 31 May 2001 10:57:19 -0700
Sender: [email-masked]

hi Alex,

I dont think we need to put in a solution for the problem. We should however
at least 
make a note of the problem in the RFC so that the reader is aware of the
issues involved.
What steps she might take to resolve the issue can be vendor specific.

Cheers,
Vivek.

> -----Original Message-----
> From: Manish Vora [mailto:[email-masked]]
> Sent: Thursday, May 31, 2001 6:23 AM
> To: Alex Zinin
> Cc: Vivek Menezes; [email-masked]; [email-masked]
> Subject: Re: Proposed text for 9.1.2
> 
> 
> Alex,
>     Please see comments inline ...
> 
> Alex Zinin wrote:
> > 
> > Vivek,
> > 
> > >> This "set" is the routing table and it is the current practice to
> > >> get BGP routes installed there (vs IGP sync). So, how 
> does the new
> > >> community help?
> > >>
> > 
> > > Well I was proposing a new set (or sub-set of the routing 
> table) that only
> > > consists of
> > > IGP routes and "special" BGP routes only used for next 
> hop resolution. If
> > > you look at the
> > > entire routing table, you are essentially colouring some 
> routes in the
> > > routing table. the
> > > coloured routes are the only one used for BGP next hop 
> resolution. System
> > > configuration
> > > "using the community" makes sure that there are no cycles 
> among the coloured
> > > nodes.
> > 
> > I see your point. I think it would be a bit too much
> > for this problem, though. See below pls.
> > 
> > > Well you can look at it as a cycle in a graph. You can 
> eliminate a cycle by
> > > potentially
> > > removing an arbitrary edge in the cycle. Unless you 
> specify the edge
> > > selection using  a  specified deterministic algorithm, 
> you will run into
> > > vendors selecting their own even
> > > perhaps randomized algorithms for edge selection.
> > 
> > OK, the above is indeed possible in a generic case,
> > where you have something like:
> > 
> >  x.0.0.0/8 via y.y.y.y
> >  y.0.0.0/8 via z.z.z.z
> >  z.0.0.0/8 via x.x.x.x
> >  0.0.0.0/0 via a.a.a.a
> > 
> > Even though this is _very_ unlikely to be seen in a BGP scenario
> > (since NHs are not arbitrary) and the real problem is different,
> > not closing the loop and logging a message (even if it is not
> > deterministic which prefix would be held back) is better than
> > installing the route.
> > 
> > I believe that in majority of situations it will be deterministic,
> > as the blocked route will loop to itself. It is not realistic to
> > expect a more specific route covering some NH (most probably a
> > route to the corresponding DMZ) to be resolved through a NH in
> > another DMZ. However, I do not exclude other scenarios where
> > people deploy BGP incorrectly, and the check helps there as well,
> > actually.
> > 
> > Keep in mind that this mechanism is a protective measure 
> for situations
> > when something is _broken_. In this situation, it does not 
> really matter
> > which "broken" route you push back, they are all in the 
> loop, and we are
> > not trying to fix anything. What does matter is we do as 
> less harm to
> > ourselves and the network as possible and draw the admin's 
> attention.
> 
> I agree that when things wrong .. any solution which avoids 
> it is good 
> enough. Trying to fix things in some manner is what an implementation
> may choose to do .. based on what it can do efficiently. But should
> the BGP standard propose a solution .. especially when its
> non-deterministic ?
> Thats something I am not too sure about. 
> 
> Thanks,
> - Manish
> 
> > 
> > > In order to make BGP
> > > converge to the same set of routes the same route (edge) 
> must be selected.
> > > The deterministic algorithm would
> > > then have to be a part of the spec.
> > 
> > > I'm opposed to having to deal with cycles in the first place.
> > > Having BGP routes to resolve next hops is a very bad idea.
> > 
> > I guess we can't really avoid it, it is just there already.
> > (But, conceptually, I also don't like BGP-through-BGP resolution :)
> > 
> > Bottom line---I'll change the text to accommodate the comments,
> > will remove the pseudo-code and send the new text back to the list.
> > 
> > Thanks!
> > 
> > Alex.
> 

Date: Thu, 31 May 2001 09:23:12 -0400
From: Manish Vora <[email-masked]>
Organization: Laurel Networks
To: Alex Zinin <[email-masked]>
Cc: Vivek Menezes <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Alex,
    Please see comments inline ...

Alex Zinin wrote:
> 
> Vivek,
> 
> >> This "set" is the routing table and it is the current practice to
> >> get BGP routes installed there (vs IGP sync). So, how does the new
> >> community help?
> >>
> 
> > Well I was proposing a new set (or sub-set of the routing table) that only
> > consists of
> > IGP routes and "special" BGP routes only used for next hop resolution. If
> > you look at the
> > entire routing table, you are essentially colouring some routes in the
> > routing table. the
> > coloured routes are the only one used for BGP next hop resolution. System
> > configuration
> > "using the community" makes sure that there are no cycles among the coloured
> > nodes.
> 
> I see your point. I think it would be a bit too much
> for this problem, though. See below pls.
> 
> > Well you can look at it as a cycle in a graph. You can eliminate a cycle by
> > potentially
> > removing an arbitrary edge in the cycle. Unless you specify the edge
> > selection using  a  specified deterministic algorithm, you will run into
> > vendors selecting their own even
> > perhaps randomized algorithms for edge selection.
> 
> OK, the above is indeed possible in a generic case,
> where you have something like:
> 
>  x.0.0.0/8 via y.y.y.y
>  y.0.0.0/8 via z.z.z.z
>  z.0.0.0/8 via x.x.x.x
>  0.0.0.0/0 via a.a.a.a
> 
> Even though this is _very_ unlikely to be seen in a BGP scenario
> (since NHs are not arbitrary) and the real problem is different,
> not closing the loop and logging a message (even if it is not
> deterministic which prefix would be held back) is better than
> installing the route.
> 
> I believe that in majority of situations it will be deterministic,
> as the blocked route will loop to itself. It is not realistic to
> expect a more specific route covering some NH (most probably a
> route to the corresponding DMZ) to be resolved through a NH in
> another DMZ. However, I do not exclude other scenarios where
> people deploy BGP incorrectly, and the check helps there as well,
> actually.
> 
> Keep in mind that this mechanism is a protective measure for situations
> when something is _broken_. In this situation, it does not really matter
> which "broken" route you push back, they are all in the loop, and we are
> not trying to fix anything. What does matter is we do as less harm to
> ourselves and the network as possible and draw the admin's attention.

I agree that when things wrong .. any solution which avoids it is good 
enough. Trying to fix things in some manner is what an implementation
may choose to do .. based on what it can do efficiently. But should
the BGP standard propose a solution .. especially when its
non-deterministic ?
Thats something I am not too sure about. 

Thanks,
- Manish

> 
> > In order to make BGP
> > converge to the same set of routes the same route (edge) must be selected.
> > The deterministic algorithm would
> > then have to be a part of the spec.
> 
> > I'm opposed to having to deal with cycles in the first place.
> > Having BGP routes to resolve next hops is a very bad idea.
> 
> I guess we can't really avoid it, it is just there already.
> (But, conceptually, I also don't like BGP-through-BGP resolution :)
> 
> Bottom line---I'll change the text to accommodate the comments,
> will remove the pseudo-code and send the new text back to the list.
> 
> Thanks!
> 
> Alex.

Date: Wed, 30 May 2001 20:47:41 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Vivek Menezes <[email-masked]>
Cc: Manish Vora <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Vivek,

>> This "set" is the routing table and it is the current practice to
>> get BGP routes installed there (vs IGP sync). So, how does the new
>> community help?
>> 

> Well I was proposing a new set (or sub-set of the routing table) that only
> consists of
> IGP routes and "special" BGP routes only used for next hop resolution. If
> you look at the
> entire routing table, you are essentially colouring some routes in the
> routing table. the 
> coloured routes are the only one used for BGP next hop resolution. System
> configuration 
> "using the community" makes sure that there are no cycles among the coloured
> nodes.

I see your point. I think it would be a bit too much
for this problem, though. See below pls.

> Well you can look at it as a cycle in a graph. You can eliminate a cycle by
> potentially
> removing an arbitrary edge in the cycle. Unless you specify the edge
> selection using  a  specified deterministic algorithm, you will run into
> vendors selecting their own even
> perhaps randomized algorithms for edge selection.

OK, the above is indeed possible in a generic case,
where you have something like:

 x.0.0.0/8 via y.y.y.y
 y.0.0.0/8 via z.z.z.z
 z.0.0.0/8 via x.x.x.x
 0.0.0.0/0 via a.a.a.a

Even though this is _very_ unlikely to be seen in a BGP scenario
(since NHs are not arbitrary) and the real problem is different,
not closing the loop and logging a message (even if it is not
deterministic which prefix would be held back) is better than
installing the route.

I believe that in majority of situations it will be deterministic,
as the blocked route will loop to itself. It is not realistic to
expect a more specific route covering some NH (most probably a
route to the corresponding DMZ) to be resolved through a NH in
another DMZ. However, I do not exclude other scenarios where
people deploy BGP incorrectly, and the check helps there as well,
actually.

Keep in mind that this mechanism is a protective measure for situations
when something is _broken_. In this situation, it does not really matter
which "broken" route you push back, they are all in the loop, and we are
not trying to fix anything. What does matter is we do as less harm to
ourselves and the network as possible and draw the admin's attention.

> In order to make BGP
> converge to the same set of routes the same route (edge) must be selected.
> The deterministic algorithm would
> then have to be a part of the spec.

> I'm opposed to having to deal with cycles in the first place.
> Having BGP routes to resolve next hops is a very bad idea.

I guess we can't really avoid it, it is just there already.
(But, conceptually, I also don't like BGP-through-BGP resolution :)

Bottom line---I'll change the text to accommodate the comments,
will remove the pseudo-code and send the new text back to the list.

Thanks!

Alex.

From: Vivek Menezes <[email-masked]>
To: "'Alex Zinin'" <[email-masked]>, Vivek Menezes <[email-masked]>
Cc: Manish Vora <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed text for 9.1.2
Date: Wed, 30 May 2001 18:20:38 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:54 PM
> To: Vivek Menezes
> Cc: Manish Vora; [email-masked]; [email-masked]
> Subject: Re: Proposed text for 9.1.2
> 
> 
> 
> Vivek,
> 
> > I have a suggestion that might make sense. Currently if one 
> uses IGP routes
> > to resolve 
> > next hops, we dont have issues with loops in next hop 
> resolution. If one
> > needs to include
> > "some" BGP routes in the next hop resolution process, one 
> could potentially
> > tag these routes
> > with a "nh-resolve" community, and add these routes into 
> the set of routes
> > used for nh-resolution.
> 
> This "set" is the routing table and it is the current practice to
> get BGP routes installed there (vs IGP sync). So, how does the new
> community help?
> 

Well I was proposing a new set (or sub-set of the routing table) that only
consists of
IGP routes and "special" BGP routes only used for next hop resolution. If
you look at the
entire routing table, you are essentially colouring some routes in the
routing table. the 
coloured routes are the only one used for BGP next hop resolution. System
configuration 
"using the community" makes sure that there are no cycles among the coloured
nodes.

> > By eliminating nh resolution loops altogether the scheme 
> also eliminates the
> > non-deterministic route selection that Manish pointed out.
> 
> I don't see where it is non-deterministic, actually.
> 

Well you can look at it as a cycle in a graph. You can eliminate a cycle by
potentially
removing an arbitrary edge in the cycle. Unless you specify the edge
selection using  a  specified deterministic algorithm, you will run into
vendors selecting their own even
perhaps randomized algorithms for edge selection. In order to make BGP
converge to the same set of routes the same route (edge) must be selected.
The deterministic algorithm would
then have to be a part of the spec. I'm opposed to having to deal with
cycles in the
first place. Having BGP routes to resolve next hops is a very bad idea. 

My suggestion is that if you really want to use BGP for BGP next hop
resolution then
you better tag the specific route you wanna use for nh-resolution with a
community.

Cheers,
Vivek.

have  

> Thanks!
> 
> Alex.
> 
> 

From: "Shekhar, Ravi" <[email-masked]>
To: "'Vivek Menezes'" <[email-masked]>, "'Alex Zinin'" <[email-masked]>, Manish Vora <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed text for 9.1.2
Date: Wed, 30 May 2001 21:12:29 -0400
Sender: [email-masked]

Vivek,
  Its not clear to me as to what you are proposing to do with the
  "nh-resolve" community. Can you elaborate it further?

  From what I understand, in case of looped-dependency of routes, 
  for end result to be same, one would have to discard all the routes 
  involved in the loop-dependency.
  Just discarding the last route which really made the loop-dependency
  evident for the first time could end up giving different end result 
  depending on the order in which the routes were received.  
  
  - Ravi Shekhar.

> -----Original Message-----
> From: Vivek Menezes [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 5:52 PM
> To: 'Alex Zinin'; Manish Vora; [email-masked]; [email-masked]
> Subject: RE: Proposed text for 9.1.2
> 
> 
> I have a suggestion that might make sense. Currently if one 
> uses IGP routes
> to resolve 
> next hops, we dont have issues with loops in next hop 
> resolution. If one
> needs to include
> "some" BGP routes in the next hop resolution process, one 
> could potentially
> tag these routes
> with a "nh-resolve" community, and add these routes into the 
> set of routes
> used for nh-resolution. This not only gets rid of loops (Hey 
> if you get into
> a loop its a configuration
> issue, one can very easily configure BGP to form routing 
> loops in many other
> ways).
> 
> By eliminating nh resolution loops altogether the scheme also 
> eliminates the
> non-deterministic route selection that Manish pointed out.
> 
> Vivek.
> 
> 
> > -----Original Message-----
> > From: Alex Zinin [mailto:[email-masked]]
> > Sent: Wednesday, May 30, 2001 12:09 PM
> > To: Manish Vora; [email-masked]; [email-masked]
> > Subject: Re: Proposed text for 9.1.2
> > 
> > 
> > 
> > Correcting myself:
> > 
> > > Note that this is nothing new. The current BGP spec already
> > > requires BGP implementations to deal with dynamic route
> > > resolvability status, the only new thing is that now you
> > > mark unresolvable routes as unfeasible.
> > 
> > ...mark routes that would become unresolvable if installed as
> > unfeasible.
> > 
> > Alex.
> > 
> > 
> 

Date: Wed, 30 May 2001 17:53:58 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Vivek Menezes <[email-masked]>
Cc: Manish Vora <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Vivek,

> I have a suggestion that might make sense. Currently if one uses IGP routes
> to resolve 
> next hops, we dont have issues with loops in next hop resolution. If one
> needs to include
> "some" BGP routes in the next hop resolution process, one could potentially
> tag these routes
> with a "nh-resolve" community, and add these routes into the set of routes
> used for nh-resolution.

This "set" is the routing table and it is the current practice to
get BGP routes installed there (vs IGP sync). So, how does the new
community help?

> By eliminating nh resolution loops altogether the scheme also eliminates the
> non-deterministic route selection that Manish pointed out.

I don't see where it is non-deterministic, actually.

Thanks!

Alex.

From: Vivek Menezes <[email-masked]>
To: "'Alex Zinin'" <[email-masked]>, Manish Vora <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Proposed text for 9.1.2
Date: Wed, 30 May 2001 14:52:00 -0700
Sender: [email-masked]

I have a suggestion that might make sense. Currently if one uses IGP routes
to resolve 
next hops, we dont have issues with loops in next hop resolution. If one
needs to include
"some" BGP routes in the next hop resolution process, one could potentially
tag these routes
with a "nh-resolve" community, and add these routes into the set of routes
used for nh-resolution. This not only gets rid of loops (Hey if you get into
a loop its a configuration
issue, one can very easily configure BGP to form routing loops in many other
ways).

By eliminating nh resolution loops altogether the scheme also eliminates the
non-deterministic route selection that Manish pointed out.

Vivek.

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: Wednesday, May 30, 2001 12:09 PM
> To: Manish Vora; [email-masked]; [email-masked]
> Subject: Re: Proposed text for 9.1.2
> 
> 
> 
> Correcting myself:
> 
> > Note that this is nothing new. The current BGP spec already
> > requires BGP implementations to deal with dynamic route
> > resolvability status, the only new thing is that now you
> > mark unresolvable routes as unfeasible.
> 
> ...mark routes that would become unresolvable if installed as
> unfeasible.
> 
> Alex.
> 
> 

Date: Wed, 30 May 2001 12:09:11 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Manish Vora <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Correcting myself:

> Note that this is nothing new. The current BGP spec already
> requires BGP implementations to deal with dynamic route
> resolvability status, the only new thing is that now you
> mark unresolvable routes as unfeasible.

...mark routes that would become unresolvable if installed as
unfeasible.

Alex.

Date: Wed, 30 May 2001 09:18:14 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Manish Vora <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Manish,

>     I guess the point I was trying to make is that its not enough
> to offer a partial solution and a complete solution does not belong
> to the BGP spec.

After some discussion with other folks, I think I'll
just remove the pseudo-code, as the implementation of
the resolvability check is too much dependent on the
actual sw architecture.

>     I agree thats it might be nice to make a note of this in the 
> spec .. but by offering some solution .. we should not introduce
> other problems. In this case, your pseudo code introduces 
> non-deterministic behaviour.

You probably misunderstood something.
Even though that pseudo-code does not cover _all_ cases and
does not remove _all_ invalid routes from consideration, it does
address a specific problem that we initially discussed, so
it removes _some_ routes from consideration, which is better
than none.

> Infact I think if we try to take care
> of this problem just in BGP then you are bound to get non-deterministic
> behaviour. When you realize that the route which is about to be added
> will cause a loop and you do not consider that route for the decision
> process ... then your Loc-Rib and Unicast Rib will depend on the 
> order in which you receive the routes.

I don't think this is entirely correct.

Route resolvability depends on what routes you have at the moment,
but not on the order you receive them. So, while a route's
resolvability status will indeed dynamically change
while you're converging (though I doubt any implementation will
recheck it after each route), the final result will be the same.

Note that this is nothing new. The current BGP spec already
requires BGP implementations to deal with dynamic route
resolvability status, the only new thing is that now you
mark unresolvable routes as unfeasible.

Alex.

Date: Wed, 30 May 2001 09:16:11 -0400
From: Manish Vora <[email-masked]>
Organization: Laurel Networks
To: Alex Zinin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Alex,
    I guess the point I was trying to make is that its not enough
to offer a partial solution and a complete solution does not belong
to the BGP spec. 
    I agree thats it might be nice to make a note of this in the 
spec .. but by offering some solution .. we should not introduce
other problems. In this case, your pseudo code introduces 
non-deterministic behaviour. Infact I think if we try to take care
of this problem just in BGP then you are bound to get non-deterministic
behaviour. When you realize that the route which is about to be added
will cause a loop and you do not consider that route for the decision
process ... then your Loc-Rib and Unicast Rib will depend on the 
order in which you receive the routes. I don't think the standard should
offer a solution/hint which is not deterministic.

- Manish

Alex Zinin wrote:
> 
> Manish,
> 
>  First, to clarify, the pseudo-code at the end of the text
>  does not cover all recursion cases, only the case where
>  a prefix's next-hop is resolved through the prefix itself
>  if the BGP route is installed, i.e., it's the most obvious
>  case.
> 
>  Second, the route resolvability definition covers your case,
>  because both BGP routes would become mutually recursive
>  ones the IGP route is removed.
> 
>  There's no intention to any guidelines of how the checks
>  should be implemented, etc. The goal is to make sure
>  routes that invalid routes (i.e., those that won't work
>  anyways) are not considered feasible.
> 
>  Indeed, the full implementation of the check depends on
>  the details of the actual routing sw, that's why I didn't
>  try to provide a "generic" algo, but just a hint.
> 
> --
> Alex Zinin
> 
> Tuesday, May 29, 2001, 4:09:09 PM, Manish Vora wrote:
> 
> > Alex,
> >     This case illustrates the creation of a loop when adding a new BGP
> > route to the Loc-Rib and maybe the Unicast RIB. There are other cases
> > (when we have routes from other protocols) that a loop may be formed
> > due to changes in the routing table.
> 
> > For example, assume a BGP route (say 10/8) is being resolved by an
> > IGP route (say 11/8). The routing table also has a BGP route for
> > 11/8 but it was not chosen as the best route (based on preference or
> > other factors). Now its possible that when the IGP route goes away
> > and the BGP route becomes the best route ... you suddenly have a loop
> > in your routing table (Unicast RIB and FIB)
> 
> > This may have escaped your check for recursive resolving .. since the
> > existing nexthop for 10/8 or 11/8 resolved to the IGP route's nexthop.
> 
> > I can think of different ways of taking care of this case .. and I think
> > it would be specific to each implementation to ensure that it has a
> > deterministic behaviour and is efficient in handling creation and
> > subsequent destruction of loops.
> 
> > I am not so sure if this is something that should be spelled out
> > in the BGP spec...
> 
> > Thanks,
> > - Manish
> 
> > [email-masked] wrote:
> >>
> >> alex, comments in line:
> >>
> >> >    If the NEXT_HOP attribute of a BGP route depicts an address to which
> >> >    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
> >> >    route should be excluded from the Phase 2 decision function.
> >> >
> >> > /*
> >> > Change to:
> >> >
> >> >    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
> >> >    become unresolvable if the route was installed in the routing table
> >> >    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
> >> >    decision function.
> >> >
> >> > */
> >>
> >> routing table should be clarified here.  Perhaps unicast rib or
> >> fib?
> >>
> >> >    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. The local speaker MUST determine the immediate
> >> >    next hop to the address depicted by the NEXT_HOP attribute of the
> >> >    selected route by performing a lookup in the IGP and selecting one of
> >> >    the possible paths in the IGP.  This immediate next hop MUST be used
> >> >    when installing the selected route in the Loc-RIB.  If the route to
> >> >    the address depicted by the NEXT_HOP attribute changes such that the
> >> >    immediate next hop changes, route selection should be recalculated as
> >> >    specified above.
> >> >
> >> > /*
> >> > Change to:
> >> >
> >> >    The local speaker SHALL then install that route in the Loc-RIB and
> >> >    the routing table, replacing any route to the same destination that
> >>
> >> routing table is probably incorrect here;  a route may be selected as
> >> best but may not be elligible for inclusion in unicast rib.  decision
> >> process here is totally internal to bgp.
> >>
> >> >    is currently being held in the Loc-RIB. The new route should also
> >> >    replace any existing BGP route in the routing table. Whether or not
> >> >    the new route replaces an already existing non-BGP route in the routing
> >> >    table depends on the policy configured on the BGP speaker.
> >> >
> >> >    The local speaker MUST determine the immediate next hop to the address
> >> >    depicted by the NEXT_HOP attribute of the selected route by performing
> >> >    a lookup in the routing table and selecting one of the possible paths.
> >> >    If the route to the address depicted by the NEXT_HOP attribute changes
> >> >    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
> >> >    NEXT_HOP is resolved through an IGP route) changes, route selection
> >> >    should be recalculated as specified above.
> >>
> >> I think specifying 'a lookup in the routing table and selecting /one/ of
> >> the possible paths' is a little limiting here.
> >>
> >> > */
> >> >
> >> >
> >> >    Unfeasible routes shall be removed from the Loc-RIB, and
> >> >    corresponding unfeasible routes shall then be removed from the Adj-
> >> >    RIBs-In.
> >> >
> >> > /*
> >> > Change to:
> >> >
> >> >    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
> >> >    table. However, corresponding unfeasible routes MUST/SHOULD be kept
> >> >    in the Adj-RIBs-In.
> >> >
> >>
> >> I think 'SHOULD' is better.
> >>
> >> > Introduce a section on route resolvability:
> >> >
> >> >
> >> > 9.1.2.x Route Resolvability Condition
> >> >
> >> >    As indicated in Section 9.1.2, BGP routers should exclude unresolvable
> >> >    routes from the Phase 2 decision. This ensures that only valid routes
> >> >    are installed in Loc-RIB and the routing table.
> >> >
> >> >    The route resolvability condition is defined as follows.
> >> >
> >> >       1.  A route Rte1, referencing only the intermediate network address,
> >> >           is considered resolvable if the routing table contains at least
> >> >           one resolvable route Rte2 that matches Rte1's intermediate network
> >> >           address and is not recursively resolved (directly or indirectly)
> >> >           through Rte1.
> >> >
> >> >       2.  Routes referencing interfaces (with or without intermediate
> >> >           addresses) are considered resolvable if the state of the referenced
> >> >           interface is up and IP processing is enabled on this interface.
> >> >
> >> >    BGP routes do not refer to interfaces, but can be resolved through the
> >> >    routes in the routing table that can be of both types. IGP routes and
> >> >    routes to directly connected networks are expected to specify the
> >> >    outbound interface.
> >> >
> >> >    Note that a BGP route is considered unresolvable not only in situations
> >> >    where the router's routing table contains no route matching the BGP
> >> >    route's NEXT_HOP. Recursively resolved routes (routes referencing each
> >> >    other's next hops) also fail the resolvability check.
> >> >
> >> >    It is also important that implementations do not consider feasible
> >> >    routes that would become unresolvable if they were installed in
> >> >    the routing table even if their NEXT_HOPs are resolvable using the
> >> >    current contents of the routing table. This check ensures that a BGP
> >> >    speaker does not install in the routing table routes that will be
> >> >    removed and not used by the speaker. Therefore, in addition to local
> >> >    routing table stability, this check also improves behavior of
> >> >    the protocol in the network.
> >> >
> >> >    As a possible approach, implementations could use the following
> >> >    algorithm to perform the resolvability checks described above.
> >> >
> >> >     for (m = all routes still under consideration)
> >> >         begin
> >> >           nh = nexthop(m)
> >> >           if ( no matching_route(nh) )
> >> >              remove route m from consideration
> >> >           else if ( (prefix(m) matches nh) and
> >> >                     (prefix(m) is more specific than matching_route(nh)) )
> >> >                 remove route m from consideration
> >> >         end
> >>
> >> I think this section is both useful and good, but brings up another issue:
> >> this does not reflect reality for most vendors currently;  most implementations
> >> of bgp I have worked with will install the route and recurse x
> >> times in recursion loop (before marking invalid or backing off to next
> >> longest matching prefix for nh or other etc).
> >>
> >> I think adding this useful section specifying a recursion check
> >> methodology will place many impl. out of spec :/.
> >>
> >> my 2c.
> >>
> >>         -ed

Date: Tue, 29 May 2001 17:07:07 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Ed,

>> > routing table is probably incorrect here;  a route may be selected as
>> > best but may not be elligible for inclusion in unicast rib. decision
>> > process here is totally internal to bgp.
>> 
>> Why would the best route be not "eligible" (different from "installed")?
>> 
>> You see, on the one hand we don't want to dictate how a BGP speaker
>> should install a BGP route (hence the reservation below), on the
>> other hand, it is important for BGP to use what's announced and
>> announce only what's used... I guess you might have something
>> else in mind...

> this is not always the case.  there are many vendor implemenations
> which will continue to announce from loc-rib while not using the route
> in unicast rib due to local policy or degree of preference across
> protocols.  I'm mostly just saying that we should not dictate 
> route installation in urib/fib /within/ the bgp decision process
> like this.  ;)

You see, that's why I made the different btw "eligible" and "actually
installed". The best BGP route should be eligible for installation.
Whether it is installed in the RT or not depends on the local policy.
I'll change the wording to clarify this.

Alex.

Date: Tue, 29 May 2001 17:04:33 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Manish Vora <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Manish,

 First, to clarify, the pseudo-code at the end of the text
 does not cover all recursion cases, only the case where
 a prefix's next-hop is resolved through the prefix itself
 if the BGP route is installed, i.e., it's the most obvious
 case.

 Second, the route resolvability definition covers your case,
 because both BGP routes would become mutually recursive
 ones the IGP route is removed.

 There's no intention to any guidelines of how the checks
 should be implemented, etc. The goal is to make sure
 routes that invalid routes (i.e., those that won't work
 anyways) are not considered feasible.

 Indeed, the full implementation of the check depends on
 the details of the actual routing sw, that's why I didn't
 try to provide a "generic" algo, but just a hint.

-- 
Alex Zinin

Tuesday, May 29, 2001, 4:09:09 PM, Manish Vora wrote:

> Alex,
>     This case illustrates the creation of a loop when adding a new BGP
> route to the Loc-Rib and maybe the Unicast RIB. There are other cases
> (when we have routes from other protocols) that a loop may be formed
> due to changes in the routing table.

> For example, assume a BGP route (say 10/8) is being resolved by an
> IGP route (say 11/8). The routing table also has a BGP route for
> 11/8 but it was not chosen as the best route (based on preference or
> other factors). Now its possible that when the IGP route goes away
> and the BGP route becomes the best route ... you suddenly have a loop
> in your routing table (Unicast RIB and FIB)

> This may have escaped your check for recursive resolving .. since the 
> existing nexthop for 10/8 or 11/8 resolved to the IGP route's nexthop. 

> I can think of different ways of taking care of this case .. and I think
> it would be specific to each implementation to ensure that it has a
> deterministic behaviour and is efficient in handling creation and
> subsequent destruction of loops. 

> I am not so sure if this is something that should be spelled out
> in the BGP spec... 

> Thanks,
> - Manish

> [email-masked] wrote:
>> 
>> alex, comments in line:
>> 
>> >    If the NEXT_HOP attribute of a BGP route depicts an address to which
>> >    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>> >    route should be excluded from the Phase 2 decision function.
>> >
>> > /*
>> > Change to:
>> >
>> >    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
>> >    become unresolvable if the route was installed in the routing table
>> >    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
>> >    decision function.
>> >
>> > */
>> 
>> routing table should be clarified here.  Perhaps unicast rib or
>> fib?
>> 
>> >    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. The local speaker MUST determine the immediate
>> >    next hop to the address depicted by the NEXT_HOP attribute of the
>> >    selected route by performing a lookup in the IGP and selecting one of
>> >    the possible paths in the IGP.  This immediate next hop MUST be used
>> >    when installing the selected route in the Loc-RIB.  If the route to
>> >    the address depicted by the NEXT_HOP attribute changes such that the
>> >    immediate next hop changes, route selection should be recalculated as
>> >    specified above.
>> >
>> > /*
>> > Change to:
>> >
>> >    The local speaker SHALL then install that route in the Loc-RIB and
>> >    the routing table, replacing any route to the same destination that
>> 
>> routing table is probably incorrect here;  a route may be selected as
>> best but may not be elligible for inclusion in unicast rib.  decision
>> process here is totally internal to bgp.
>> 
>> >    is currently being held in the Loc-RIB. The new route should also
>> >    replace any existing BGP route in the routing table. Whether or not
>> >    the new route replaces an already existing non-BGP route in the routing
>> >    table depends on the policy configured on the BGP speaker.
>> >
>> >    The local speaker MUST determine the immediate next hop to the address
>> >    depicted by the NEXT_HOP attribute of the selected route by performing
>> >    a lookup in the routing table and selecting one of the possible paths.
>> >    If the route to the address depicted by the NEXT_HOP attribute changes
>> >    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
>> >    NEXT_HOP is resolved through an IGP route) changes, route selection
>> >    should be recalculated as specified above.
>> 
>> I think specifying 'a lookup in the routing table and selecting /one/ of
>> the possible paths' is a little limiting here.
>> 
>> > */
>> >
>> >
>> >    Unfeasible routes shall be removed from the Loc-RIB, and
>> >    corresponding unfeasible routes shall then be removed from the Adj-
>> >    RIBs-In.
>> >
>> > /*
>> > Change to:
>> >
>> >    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>> >    table. However, corresponding unfeasible routes MUST/SHOULD be kept
>> >    in the Adj-RIBs-In.
>> >
>> 
>> I think 'SHOULD' is better.
>> 
>> > Introduce a section on route resolvability:
>> >
>> >
>> > 9.1.2.x Route Resolvability Condition
>> >
>> >    As indicated in Section 9.1.2, BGP routers should exclude unresolvable
>> >    routes from the Phase 2 decision. This ensures that only valid routes
>> >    are installed in Loc-RIB and the routing table.
>> >
>> >    The route resolvability condition is defined as follows.
>> >
>> >       1.  A route Rte1, referencing only the intermediate network address,
>> >           is considered resolvable if the routing table contains at least
>> >           one resolvable route Rte2 that matches Rte1's intermediate network
>> >           address and is not recursively resolved (directly or indirectly)
>> >           through Rte1.
>> >
>> >       2.  Routes referencing interfaces (with or without intermediate
>> >           addresses) are considered resolvable if the state of the referenced
>> >           interface is up and IP processing is enabled on this interface.
>> >
>> >    BGP routes do not refer to interfaces, but can be resolved through the
>> >    routes in the routing table that can be of both types. IGP routes and
>> >    routes to directly connected networks are expected to specify the
>> >    outbound interface.
>> >
>> >    Note that a BGP route is considered unresolvable not only in situations
>> >    where the router's routing table contains no route matching the BGP
>> >    route's NEXT_HOP. Recursively resolved routes (routes referencing each
>> >    other's next hops) also fail the resolvability check.
>> >
>> >    It is also important that implementations do not consider feasible
>> >    routes that would become unresolvable if they were installed in
>> >    the routing table even if their NEXT_HOPs are resolvable using the
>> >    current contents of the routing table. This check ensures that a BGP
>> >    speaker does not install in the routing table routes that will be
>> >    removed and not used by the speaker. Therefore, in addition to local
>> >    routing table stability, this check also improves behavior of
>> >    the protocol in the network.
>> >
>> >    As a possible approach, implementations could use the following
>> >    algorithm to perform the resolvability checks described above.
>> >
>> >     for (m = all routes still under consideration)
>> >         begin
>> >           nh = nexthop(m)
>> >           if ( no matching_route(nh) )
>> >              remove route m from consideration
>> >           else if ( (prefix(m) matches nh) and
>> >                     (prefix(m) is more specific than matching_route(nh)) )
>> >                 remove route m from consideration
>> >         end
>> 
>> I think this section is both useful and good, but brings up another issue:
>> this does not reflect reality for most vendors currently;  most implementations
>> of bgp I have worked with will install the route and recurse x
>> times in recursion loop (before marking invalid or backing off to next
>> longest matching prefix for nh or other etc).
>> 
>> I think adding this useful section specifying a recursion check
>> methodology will place many impl. out of spec :/.
>> 
>> my 2c.
>> 
>>         -ed

Date: Tue, 29 May 2001 16:27:32 -0500
From: [email-masked]
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

> >> Change to:
> >> 
> >>    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
> >>    become unresolvable if the route was installed in the routing table
> >>    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
> >>    decision function.
> >> 
> >> */
> 
> > routing table should be clarified here.  Perhaps unicast rib or
> > fib?
> 
> I'll see what can be done. Most probably, we'll have to modify
> Section 3.2 as well. The term "RIB" is already associated
> with "Loc-RIB", I guess. Maybe it is better to introduce the
> term "Routing Table", say that it collects all connected, static,
> IGP and BGP routes and then use "Routing Table" consistently
> in the document.

cool.

> >>    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. The local speaker MUST determine the immediate
> >>    next hop to the address depicted by the NEXT_HOP attribute of the
> >>    selected route by performing a lookup in the IGP and selecting one of
> >>    the possible paths in the IGP.  This immediate next hop MUST be used
> >>    when installing the selected route in the Loc-RIB.  If the route to
> >>    the address depicted by the NEXT_HOP attribute changes such that the
> >>    immediate next hop changes, route selection should be recalculated as
> >>    specified above.
> >> 
> >> /*
> >> Change to:
> >> 
> >>    The local speaker SHALL then install that route in the Loc-RIB and
> >>    the routing table, replacing any route to the same destination that
> 
> > routing table is probably incorrect here;  a route may be selected as
> > best but may not be elligible for inclusion in unicast rib. decision
> > process here is totally internal to bgp.
> 
> Why would the best route be not "eligible" (different from "installed")?
> 
> You see, on the one hand we don't want to dictate how a BGP speaker
> should install a BGP route (hence the reservation below), on the
> other hand, it is important for BGP to use what's announced and
> announce only what's used... I guess you might have something
> else in mind...

this is not always the case.  there are many vendor implemenations
which will continue to announce from loc-rib while not using the route
in unicast rib due to local policy or degree of preference across
protocols.  I'm mostly just saying that we should not dictate 
route installation in urib/fib /within/ the bgp decision process
like this.  ;)

> >>    The local speaker MUST determine the immediate next hop to the address
> >>    depicted by the NEXT_HOP attribute of the selected route by performing
> >>    a lookup in the routing table and selecting one of the possible paths.
> >>    If the route to the address depicted by the NEXT_HOP attribute changes
> >>    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
> >>    NEXT_HOP is resolved through an IGP route) changes, route selection
> >>    should be recalculated as specified above.
> 
> > I think specifying 'a lookup in the routing table and selecting /one/ of 
> > the possible paths' is a little limiting here.
> 
> Note that we do not insist on using this next-hop to install the route
> anymore, so the path is used to ensure BGP NH's resolvability, MED,
> and tie-breaking, so as soon as we have ECMP, it does not really
> matter which one is used, just one is enough.

ok, I see now. :)

Date: Tue, 29 May 2001 19:09:09 -0400
From: Manish Vora <[email-masked]>
Organization: Laurel Networks
To: Alex Zinin <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Alex,
    This case illustrates the creation of a loop when adding a new BGP
route to the Loc-Rib and maybe the Unicast RIB. There are other cases
(when we have routes from other protocols) that a loop may be formed
due to changes in the routing table.

For example, assume a BGP route (say 10/8) is being resolved by an
IGP route (say 11/8). The routing table also has a BGP route for
11/8 but it was not chosen as the best route (based on preference or
other factors). Now its possible that when the IGP route goes away
and the BGP route becomes the best route ... you suddenly have a loop
in your routing table (Unicast RIB and FIB)

This may have escaped your check for recursive resolving .. since the 
existing nexthop for 10/8 or 11/8 resolved to the IGP route's nexthop. 

I can think of different ways of taking care of this case .. and I think
it would be specific to each implementation to ensure that it has a
deterministic behaviour and is efficient in handling creation and
subsequent destruction of loops. 

I am not so sure if this is something that should be spelled out
in the BGP spec... 

Thanks,
- Manish

[email-masked] wrote:
> 
> alex, comments in line:
> 
> >    If the NEXT_HOP attribute of a BGP route depicts an address to which
> >    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
> >    route should be excluded from the Phase 2 decision function.
> >
> > /*
> > Change to:
> >
> >    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
> >    become unresolvable if the route was installed in the routing table
> >    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
> >    decision function.
> >
> > */
> 
> routing table should be clarified here.  Perhaps unicast rib or
> fib?
> 
> >    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. The local speaker MUST determine the immediate
> >    next hop to the address depicted by the NEXT_HOP attribute of the
> >    selected route by performing a lookup in the IGP and selecting one of
> >    the possible paths in the IGP.  This immediate next hop MUST be used
> >    when installing the selected route in the Loc-RIB.  If the route to
> >    the address depicted by the NEXT_HOP attribute changes such that the
> >    immediate next hop changes, route selection should be recalculated as
> >    specified above.
> >
> > /*
> > Change to:
> >
> >    The local speaker SHALL then install that route in the Loc-RIB and
> >    the routing table, replacing any route to the same destination that
> 
> routing table is probably incorrect here;  a route may be selected as
> best but may not be elligible for inclusion in unicast rib.  decision
> process here is totally internal to bgp.
> 
> >    is currently being held in the Loc-RIB. The new route should also
> >    replace any existing BGP route in the routing table. Whether or not
> >    the new route replaces an already existing non-BGP route in the routing
> >    table depends on the policy configured on the BGP speaker.
> >
> >    The local speaker MUST determine the immediate next hop to the address
> >    depicted by the NEXT_HOP attribute of the selected route by performing
> >    a lookup in the routing table and selecting one of the possible paths.
> >    If the route to the address depicted by the NEXT_HOP attribute changes
> >    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
> >    NEXT_HOP is resolved through an IGP route) changes, route selection
> >    should be recalculated as specified above.
> 
> I think specifying 'a lookup in the routing table and selecting /one/ of
> the possible paths' is a little limiting here.
> 
> > */
> >
> >
> >    Unfeasible routes shall be removed from the Loc-RIB, and
> >    corresponding unfeasible routes shall then be removed from the Adj-
> >    RIBs-In.
> >
> > /*
> > Change to:
> >
> >    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
> >    table. However, corresponding unfeasible routes MUST/SHOULD be kept
> >    in the Adj-RIBs-In.
> >
> 
> I think 'SHOULD' is better.
> 
> > Introduce a section on route resolvability:
> >
> >
> > 9.1.2.x Route Resolvability Condition
> >
> >    As indicated in Section 9.1.2, BGP routers should exclude unresolvable
> >    routes from the Phase 2 decision. This ensures that only valid routes
> >    are installed in Loc-RIB and the routing table.
> >
> >    The route resolvability condition is defined as follows.
> >
> >       1.  A route Rte1, referencing only the intermediate network address,
> >           is considered resolvable if the routing table contains at least
> >           one resolvable route Rte2 that matches Rte1's intermediate network
> >           address and is not recursively resolved (directly or indirectly)
> >           through Rte1.
> >
> >       2.  Routes referencing interfaces (with or without intermediate
> >           addresses) are considered resolvable if the state of the referenced
> >           interface is up and IP processing is enabled on this interface.
> >
> >    BGP routes do not refer to interfaces, but can be resolved through the
> >    routes in the routing table that can be of both types. IGP routes and
> >    routes to directly connected networks are expected to specify the
> >    outbound interface.
> >
> >    Note that a BGP route is considered unresolvable not only in situations
> >    where the router's routing table contains no route matching the BGP
> >    route's NEXT_HOP. Recursively resolved routes (routes referencing each
> >    other's next hops) also fail the resolvability check.
> >
> >    It is also important that implementations do not consider feasible
> >    routes that would become unresolvable if they were installed in
> >    the routing table even if their NEXT_HOPs are resolvable using the
> >    current contents of the routing table. This check ensures that a BGP
> >    speaker does not install in the routing table routes that will be
> >    removed and not used by the speaker. Therefore, in addition to local
> >    routing table stability, this check also improves behavior of
> >    the protocol in the network.
> >
> >    As a possible approach, implementations could use the following
> >    algorithm to perform the resolvability checks described above.
> >
> >     for (m = all routes still under consideration)
> >         begin
> >           nh = nexthop(m)
> >           if ( no matching_route(nh) )
> >              remove route m from consideration
> >           else if ( (prefix(m) matches nh) and
> >                     (prefix(m) is more specific than matching_route(nh)) )
> >                 remove route m from consideration
> >         end
> 
> I think this section is both useful and good, but brings up another issue:
> this does not reflect reality for most vendors currently;  most implementations
> of bgp I have worked with will install the route and recurse x
> times in recursion loop (before marking invalid or backing off to next
> longest matching prefix for nh or other etc).
> 
> I think adding this useful section specifying a recursion check
> methodology will place many impl. out of spec :/.
> 
> my 2c.
> 
>         -ed

Date: Tue, 29 May 2001 16:10:30 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Ed,

 Thanks for the comments, see below, pls.

> alex, comments in line:

>>    If the NEXT_HOP attribute of a BGP route depicts an address to which
>>    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>>    route should be excluded from the Phase 2 decision function.
>> 
>> /*
>> Change to:
>> 
>>    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
>>    become unresolvable if the route was installed in the routing table
>>    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
>>    decision function.
>> 
>> */

> routing table should be clarified here.  Perhaps unicast rib or
> fib?

I'll see what can be done. Most probably, we'll have to modify
Section 3.2 as well. The term "RIB" is already associated
with "Loc-RIB", I guess. Maybe it is better to introduce the
term "Routing Table", say that it collects all connected, static,
IGP and BGP routes and then use "Routing Table" consistently
in the document.

>>    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. The local speaker MUST determine the immediate
>>    next hop to the address depicted by the NEXT_HOP attribute of the
>>    selected route by performing a lookup in the IGP and selecting one of
>>    the possible paths in the IGP.  This immediate next hop MUST be used
>>    when installing the selected route in the Loc-RIB.  If the route to
>>    the address depicted by the NEXT_HOP attribute changes such that the
>>    immediate next hop changes, route selection should be recalculated as
>>    specified above.
>> 
>> /*
>> Change to:
>> 
>>    The local speaker SHALL then install that route in the Loc-RIB and
>>    the routing table, replacing any route to the same destination that

> routing table is probably incorrect here;  a route may be selected as
> best but may not be elligible for inclusion in unicast rib. decision
> process here is totally internal to bgp.

Why would the best route be not "eligible" (different from "installed")?

You see, on the one hand we don't want to dictate how a BGP speaker
should install a BGP route (hence the reservation below), on the
other hand, it is important for BGP to use what's announced and
announce only what's used... I guess you might have something
else in mind...

>>    The local speaker MUST determine the immediate next hop to the address
>>    depicted by the NEXT_HOP attribute of the selected route by performing
>>    a lookup in the routing table and selecting one of the possible paths.
>>    If the route to the address depicted by the NEXT_HOP attribute changes
>>    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
>>    NEXT_HOP is resolved through an IGP route) changes, route selection
>>    should be recalculated as specified above.

> I think specifying 'a lookup in the routing table and selecting /one/ of 
> the possible paths' is a little limiting here.

Note that we do not insist on using this next-hop to install the route
anymore, so the path is used to ensure BGP NH's resolvability, MED,
and tie-breaking, so as soon as we have ECMP, it does not really
matter which one is used, just one is enough.

>> 9.1.2.x Route Resolvability Condition
>> 
[...]

> I think this section is both useful and good, but brings up another issue:
> this does not reflect reality for most vendors currently;  most implementations
> of bgp I have worked with will install the route and recurse x
> times in recursion loop (before marking invalid or backing off to next
> longest matching prefix for nh or other etc).

> I think adding this useful section specifying a recursion check
> methodology will place many impl. out of spec :/.

Hmmm... it's a chicken-n-egg situation, I think... I.e., we
don't want to put existing implementations in an out of spec
position, but we also don't want to prevent any improvements
because they are not implemented yet...

One approach could be not to worry and say that existing
implementations are compliant with the current spec and the
new spec defines more details... or, I guess we can always
put "soft" wording around, i.e. "it is recommended" or "should" :)

Thanks!

Alex.

Date: Tue, 29 May 2001 15:50:57 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Ben Black" <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

Ben,

Thanks for the comments.

> Alex,

> This might also be a good opportunity to clean up the definition of the
> forwarding table (variously called the routing table and the forwarding
> information base in the current draft).  I think calling it the FIB
> throughout the document might make the language more clear.

Yes, I have this in mind also :)
When I was working on this text, I browsed the text for RT/FwdT
terms and they were used inconsistently.
I'll see if there's a good way to fix it.

>>    The local speaker SHALL then install that route in the Loc-RIB and
>>    the routing table, replacing any route to the same destination that
>>    is currently being held in the Loc-RIB. The new route should also
>>    replace any existing BGP route in the routing table.

> This is slightly ambiguous as you left out "to the same destination" in the
> last
> sentence.

Agree, will change.

>> Change to:
>>
>>    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>>    table. However, corresponding unfeasible routes MUST/SHOULD be kept
>>    in the Adj-RIBs-In.
>>

> This language should either use MUST, as is, or use SHOULD with language to
> explain cases in which routes may be removed from an Adj-RIB-In (for
> instance,
> if Route Refresh has been negotiated...not that I am advocating this
> approach).

I just left it open until we have the discussion on this item
settled.

Thanks again.
Alex.

Date: Tue, 29 May 2001 15:41:35 -0500
From: [email-masked]
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposed text for 9.1.2
Sender: [email-masked]

alex, comments in line:

>    If the NEXT_HOP attribute of a BGP route depicts an address to which
>    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>    route should be excluded from the Phase 2 decision function.
> 
> /*
> Change to:
> 
>    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
>    become unresolvable if the route was installed in the routing table
>    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
>    decision function.
> 
> */

routing table should be clarified here.  Perhaps unicast rib or
fib?

>    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. The local speaker MUST determine the immediate
>    next hop to the address depicted by the NEXT_HOP attribute of the
>    selected route by performing a lookup in the IGP and selecting one of
>    the possible paths in the IGP.  This immediate next hop MUST be used
>    when installing the selected route in the Loc-RIB.  If the route to
>    the address depicted by the NEXT_HOP attribute changes such that the
>    immediate next hop changes, route selection should be recalculated as
>    specified above.
> 
> /*
> Change to:
> 
>    The local speaker SHALL then install that route in the Loc-RIB and
>    the routing table, replacing any route to the same destination that

routing table is probably incorrect here;  a route may be selected as
best but may not be elligible for inclusion in unicast rib.  decision 
process here is totally internal to bgp.

>    is currently being held in the Loc-RIB. The new route should also
>    replace any existing BGP route in the routing table. Whether or not
>    the new route replaces an already existing non-BGP route in the routing
>    table depends on the policy configured on the BGP speaker.
>
>    The local speaker MUST determine the immediate next hop to the address
>    depicted by the NEXT_HOP attribute of the selected route by performing
>    a lookup in the routing table and selecting one of the possible paths.
>    If the route to the address depicted by the NEXT_HOP attribute changes
>    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
>    NEXT_HOP is resolved through an IGP route) changes, route selection
>    should be recalculated as specified above.

I think specifying 'a lookup in the routing table and selecting /one/ of 
the possible paths' is a little limiting here. 

> */
> 
> 
>    Unfeasible routes shall be removed from the Loc-RIB, and
>    corresponding unfeasible routes shall then be removed from the Adj-
>    RIBs-In.
> 
> /*
> Change to:
> 
>    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>    table. However, corresponding unfeasible routes MUST/SHOULD be kept
>    in the Adj-RIBs-In.
> 

I think 'SHOULD' is better.

> Introduce a section on route resolvability:
> 
> 
> 9.1.2.x Route Resolvability Condition
> 
>    As indicated in Section 9.1.2, BGP routers should exclude unresolvable
>    routes from the Phase 2 decision. This ensures that only valid routes
>    are installed in Loc-RIB and the routing table.
> 
>    The route resolvability condition is defined as follows.
> 
>       1.  A route Rte1, referencing only the intermediate network address,
>           is considered resolvable if the routing table contains at least
>           one resolvable route Rte2 that matches Rte1's intermediate network
>           address and is not recursively resolved (directly or indirectly)
>           through Rte1.
> 
>       2.  Routes referencing interfaces (with or without intermediate
>           addresses) are considered resolvable if the state of the referenced
>           interface is up and IP processing is enabled on this interface.
> 
>    BGP routes do not refer to interfaces, but can be resolved through the
>    routes in the routing table that can be of both types. IGP routes and
>    routes to directly connected networks are expected to specify the
>    outbound interface.
> 
>    Note that a BGP route is considered unresolvable not only in situations
>    where the router's routing table contains no route matching the BGP
>    route's NEXT_HOP. Recursively resolved routes (routes referencing each
>    other's next hops) also fail the resolvability check.
> 
>    It is also important that implementations do not consider feasible
>    routes that would become unresolvable if they were installed in
>    the routing table even if their NEXT_HOPs are resolvable using the
>    current contents of the routing table. This check ensures that a BGP
>    speaker does not install in the routing table routes that will be
>    removed and not used by the speaker. Therefore, in addition to local
>    routing table stability, this check also improves behavior of
>    the protocol in the network.
> 
>    As a possible approach, implementations could use the following
>    algorithm to perform the resolvability checks described above.
> 
>     for (m = all routes still under consideration)
>         begin
>           nh = nexthop(m) 
>           if ( no matching_route(nh) )
>              remove route m from consideration
>           else if ( (prefix(m) matches nh) and 
>                     (prefix(m) is more specific than matching_route(nh)) )
>                 remove route m from consideration
>         end

I think this section is both useful and good, but brings up another issue:
this does not reflect reality for most vendors currently;  most implementations
of bgp I have worked with will install the route and recurse x
times in recursion loop (before marking invalid or backing off to next
longest matching prefix for nh or other etc).

I think adding this useful section specifying a recursion check
methodology will place many impl. out of spec :/.

my 2c.

	-ed

From: "Ben Black" <[email-masked]>
To: "Alex Zinin" <[email-masked]>, <[email-masked]>
Subject: RE: Proposed text for 9.1.2
Date: Tue, 29 May 2001 15:06:59 -0700
Importance: Normal
Sender: [email-masked]

Alex,

This might also be a good opportunity to clean up the definition of the
forwarding table (variously called the routing table and the forwarding
information base in the current draft).  I think calling it the FIB
throughout the document might make the language more clear.

>    The local speaker SHALL then install that route in the Loc-RIB and
>    the routing table, replacing any route to the same destination that
>    is currently being held in the Loc-RIB. The new route should also
>    replace any existing BGP route in the routing table.

This is slightly ambiguous as you left out "to the same destination" in the
last
sentence.

> Change to:
>
>    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>    table. However, corresponding unfeasible routes MUST/SHOULD be kept
>    in the Adj-RIBs-In.
>

This language should either use MUST, as is, or use SHOULD with language to
explain cases in which routes may be removed from an Adj-RIB-In (for
instance,
if Route Refresh has been negotiated...not that I am advocating this
approach).

Ben

Date: Tue, 29 May 2001 14:38:06 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Subject: Proposed text for 9.1.2
Sender: [email-masked]

Folks,

 Based on the comments from Ed and the discussion on
 the mailing list, I've put together the text that would
 incorporate all said. The "must/should" part is left open.

 Below is a very draft version of the proposed text,
 please comment.

> 9.1.2 Phase 2: Route Selection
> 
> 
>    The Phase 2 decision function shall be invoked on completion of Phase
>    1.  The Phase 2 function is a separate process which completes when
>    it has no further work to do. The Phase 2 process shall consider all
>    routes that are present in the Adj-RIBs-In, including those received
>    from both internal and external peers.
> 
>    The Phase 2 decision function shall be blocked from running while the
>    Phase 3 decision function is in process. The Phase 2 function shall
>    lock all Adj-RIBs-In prior to commencing its function, and shall
>    unlock them on completion.
> 
>    If the NEXT_HOP attribute of a BGP route depicts an address to which
>    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>    route should be excluded from the Phase 2 decision function.
> 
> /*
> Change to:
> 
>    If the NEXT_HOP attribute of a BGP route is not resolvable or it would
>    become unresolvable if the route was installed in the routing table
>    (see Section 9.1.2.x), the BGP route should be excluded from the Phase 2
>    decision function.
> 
> */
> 
>    It is critical that routers within an AS do not make conflicting
>    decisions regarding route selection that would cause forwarding loops
>    to occur.
> 
>    For each set of destinations for which a feasible route exists in the
>    Adj-RIBs-In, the local BGP speaker shall identify the route that has:
> 
>       a) the highest degree of preference of any route to the same set
>       of destinations, or
> 
>       b) is the only route to that destination, or
> 
>       c) is selected as a result of the Phase 2 tie breaking rules
>       specified in 9.1.2.1.
> 
> 
>    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. The local speaker MUST determine the immediate
>    next hop to the address depicted by the NEXT_HOP attribute of the
>    selected route by performing a lookup in the IGP and selecting one of
>    the possible paths in the IGP.  This immediate next hop MUST be used
>    when installing the selected route in the Loc-RIB.  If the route to
>    the address depicted by the NEXT_HOP attribute changes such that the
>    immediate next hop changes, route selection should be recalculated as
>    specified above.
> 
> /*
> Change to:
> 
>    The local speaker SHALL then install that route in the Loc-RIB and
>    the routing table, replacing any route to the same destination that
>    is currently being held in the Loc-RIB. The new route should also
>    replace any existing BGP route in the routing table. Whether or not
>    the new route replaces an already existing non-BGP route in the routing
>    table depends on the policy configured on the BGP speaker.
>
>    The local speaker MUST determine the immediate next hop to the address
>    depicted by the NEXT_HOP attribute of the selected route by performing
>    a lookup in the routing table and selecting one of the possible paths.
>    If the route to the address depicted by the NEXT_HOP attribute changes
>    such that the immediate next hop or the IGP cost to the NEXT_HOP (if the
>    NEXT_HOP is resolved through an IGP route) changes, route selection
>    should be recalculated as specified above.
> 
> */
> 
> 
>    Unfeasible routes shall be removed from the Loc-RIB, and
>    corresponding unfeasible routes shall then be removed from the Adj-
>    RIBs-In.
> 
> /*
> Change to:
> 
>    Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>    table. However, corresponding unfeasible routes MUST/SHOULD be kept
>    in the Adj-RIBs-In.
> 
> */
> 
> 
> 
> Introduce a section on route resolvability:
> 
> 
> 9.1.2.x Route Resolvability Condition
> 
>    As indicated in Section 9.1.2, BGP routers should exclude unresolvable
>    routes from the Phase 2 decision. This ensures that only valid routes
>    are installed in Loc-RIB and the routing table.
> 
>    The route resolvability condition is defined as follows.
> 
>       1.  A route Rte1, referencing only the intermediate network address,
>           is considered resolvable if the routing table contains at least
>           one resolvable route Rte2 that matches Rte1's intermediate network
>           address and is not recursively resolved (directly or indirectly)
>           through Rte1.
> 
>       2.  Routes referencing interfaces (with or without intermediate
>           addresses) are considered resolvable if the state of the referenced
>           interface is up and IP processing is enabled on this interface.
> 
>    BGP routes do not refer to interfaces, but can be resolved through the
>    routes in the routing table that can be of both types. IGP routes and
>    routes to directly connected networks are expected to specify the
>    outbound interface.
> 
>    Note that a BGP route is considered unresolvable not only in situations
>    where the router's routing table contains no route matching the BGP
>    route's NEXT_HOP. Recursively resolved routes (routes referencing each
>    other's next hops) also fail the resolvability check.
> 
>    It is also important that implementations do not consider feasible
>    routes that would become unresolvable if they were installed in
>    the routing table even if their NEXT_HOPs are resolvable using the
>    current contents of the routing table. This check ensures that a BGP
>    speaker does not install in the routing table routes that will be
>    removed and not used by the speaker. Therefore, in addition to local
>    routing table stability, this check also improves behavior of
>    the protocol in the network.
> 
>    As a possible approach, implementations could use the following
>    algorithm to perform the resolvability checks described above.
> 
>     for (m = all routes still under consideration)
>         begin
>           nh = nexthop(m) 
>           if ( no matching_route(nh) )
>              remove route m from consideration
>           else if ( (prefix(m) matches nh) and 
>                     (prefix(m) is more specific than matching_route(nh)) )
>                 remove route m from consideration
>         end

-- 
Alex Zinin

From: "Shekhar, Ravi" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: FW: section 9.1.2: NH recursion questions
Date: Tue, 29 May 2001 17:20:35 -0400
Sender: [email-masked]

[repost - original one didnt make it to the list]

-----Original Message-----
From: Shekhar, Ravi 
Sent: Saturday, May 26, 2001 5:18 AM
To: 'Alex Zinin '; 'Russ White '
Cc: 'Russ White '; [email-masked] '
Subject: RE: section 9.1.2: NH recursion questions

 

>To add to Russ' points here...
>
>Even if there was a possibility to request routes having
>a specific next-hop, it would mean: a) the entire routing table
>for eBGP or b) a considerable part of it for iBGP (since a lot
>of prefixes share the same next-hop).
>
...

  One could imagine route-refresh request capability not just for a 
  nexthop, but also for a set of prefixes/range of prefixes,
  which will not have all these problems.

  Before there was route-refresh, BGP would have required 
  keeping evey route before inbound policy was applied.
  But thats not necessary anymore. If there is anything we
  have learnt from this, its that its best to keep less state, 
  especially this becomes even more important as the number of 
  routes in the Internet grow larger.

  Anyhow, in all these mails to explain how BGP can work 
  without a requirement for keeping all the routes with the
  existing mechanisms (even though inefficient but it may be 
  good for achieving other optimizations), I dont want to loose 
  the original focus.

  I am not against keeping all routes. As I have already stated
  in my previous mail that probably draft should change the wording from  
  "should remove routes" and suggest that implementations "should 
  keep routes" .
  But making it a MUST (read *requirement*) seems to be too
  restrictive for future improvements and strifles any kind of
  implementation variations.
  
  Draft should ensure protocol correctness, but should not dictate
  its exact implementation.  

  Regards.
  - Ravi Shekhar.

  P.S.: As for the argument that the route-refresh should not be 
  considered in this draft, even though no sensible
  implementation would do it, an effect of route-refresh can be 
  achieved by bringing down and then bringing up the peering. Dont 
  get me wrong. I am not proposing this..;)..

> I'll agree with Alex here, and say that we should keep paths that
> fail a nh test. 

> -- There's no way to request 'all the routes that match this next
> hop' from a neighbor when you suddenly receive a route for a new
> network.

> -- You have no way of knowing if any new route in the table will
> suddenly give you some new next hop to some routes that you've
> thrown away. You'd be requesting, essentially, full updates from
> all neighbors each time there is a change in your local routing
> table. Not good.

> :-)

> Russ

> On Fri, 25 May 2001, Alex Zinin wrote:

>> 
>> Ravi,
>> 
>>   I guess we will have to disagree and see what other
>>   people say about this :)
>> 
>> -- 
>> Alex Zinin
>> 
>> Friday, May 25, 2001, 12:59:06 PM, Shekhar, Ravi wrote:
>> 
>>  
>> >> >> One has to be able to store all paths when all NHs are
reachable
>> >> 
>> >> >   Well, not really. An implementation could store only the 
>> >> best routes 
>> >> >   for a destination. And get rid of all the non-best ones 
>> >> (even though their
>> >> >   NHs are reachable) which are from peers which support 
>> >> route-refresh 
>> >> >   capability. In the event of needing it again, it could 
>> >> request it from 
>> >> >   that peer. Perhaps inefficient, but it will work. And/Or 
>> >> perhaps the
>> >> >   reason could still be saving the memory.
>> >> 
>> >> I'd encourage you to think about how this approach would
practically
>> >> affect BGP convergence and after that about whether you would
>> >> like to see such an implementation in the Internet backbone.
>> 
>> 
>> >   Alex, I was just trying to point out something which you may have
missed. 
>> >   I understand all those factors as I am working on a BGP
implementation.
>> 
>> >   First, every router does not run on Internet backbone. Besides
there
>> >   are edge routers on Internet which may have some other more
important
>> >   functionalities to support and resources to dedicate to than
optimizing 
>> >   BGP convergence, especially if they are not transit routers but
are multi 
>> >   homed for redundancy. 
>> 
>> >   Second, I just gave an example of keeping one best route. But one
could 
>> >   think of a router keeping only two or for that matter three best
routes
>> > for a 
>> >   given destination but *not all* of them. That in my opinion does
not
>> > effect 
>> >   convergence that bad unless all three of its routes go down
>> > simultaneously. 
>> 
>> >> > That would 
>> >> >   preclude someone from doing such kind of things even for 
>> >> peers which 
>> >> >   support route-refresh capability.
>> >> 
>> >> Exactly. I do believe there is a reason to preclude this. First,
>> >> because (again) route-refresh is no in the basis spec, second
>> >> (maybe even more important), because I see no reason to encourage
>> >> people to implement "optimizations" like this, and third (most
>> >> important) because this will result in incorrect implementations
>> >> if someone treats "shall/should/could" as "not necessary".
>> >> 
>> 
>> >   I tend to disagree. As I said one very good reason is that you
have 
>> >   an edge router with 5 redundant BGP peering getting all 100,000
Internet 
>> >   routes. One could choose to keep only 2 best routes and not all
of them
>> >   on such routers, thereby drastically reducing the memory
consumption.
>> 
>> >   And an implementation can be buggy even if its a MUST there.
Preventing 
>> >   possible optimizations just to make sure someone does not
mis-interpret 
>> >   the spec does not seem to be a good idea to me.
>> 
>> >   Regards.
>> >   - Ravi Shekhar. 
>> 
>> 
>> 

> _____________________________
> [email-masked] <>< Grace Alone

Date: Tue, 29 May 2001 14:22:43 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Shekhar, Ravi" <[email-masked]>
Cc: "'Russ White '" <[email-masked]>, "'Russ White '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

Ravi,

>   Draft should ensure protocol correctness, but should not dictate
>   its exact implementation.  

Fully agree with this point. And given the contents of the main
protocol spec, I am not convinced that putting "MAY" will ensure
protocol correctness.

As you indicated, resetting the sessions is the only way to reacquire
lost routes while sticking with the main spec. As you also indicated,
this is not a feasible solution.

As far as possible optimizations are concerned, people are free
to do whatever they believe is feasible on their own risk, but I don't
see a reason to introduce something that can be misinterpreted (even
if it is a bit better than what we have now) and thus can lead to
just plain wrong behavior.

Alex.

Date: Tue, 29 May 2001 15:16:09 -0500
To: [email-masked]
From: Bill Nickless <[email-masked]>
Subject: draft-nickless-safi-mcast-app-00.txt
Sender: [email-masked]

Please consider the following draft in the spirit of RFC 2545, but for IPv4 
multicast routing instead of IPv6 unicast routing.  The intent here is to 
further nail down how IPv4 Multiprotocol BGP multicast reachability shall 
be used in practice.

Thank you,
Bill Nickless

    Internet Draft                                           B. Nickless
    Document: draft-nickless-safi-mcast-app-00.txt      Argonne National
                                                              Laboratory
    Expires: October 2001                                       May 2001

        Application of Multiprotocol BGP-4 to IPv4 Multicast Routing

Status of this Memo

    This document is an Internet-Draft and is in full conformance
    with all provisions of Section 10 of RFC2026.

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

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

    The list of current Internet-Drafts can be accessed at
         http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
         http://www.ietf.org/shadow.html.

Abstract

    BGP-4 Multiprotocol Extensions [BGP-MP] defines the values for the
    Subsequent Address Family Identifier field carried in the
    MP_REACH_NLRI and MP_UNREACH_NLRI attributes.  This document defines
    how compliant systems should make use of these values for the
    purpose of routing IP multicast traffic.

Table of Contents

    Status of this Memo................................................1
    Abstract...........................................................1
    Conventions used in this document..................................2
    Introduction and Terminology.......................................2
    Application of Multiprotocol BGP-4 SAFI Field......................2
    Security Considerations............................................3
    Acknowledgements...................................................3
    References.........................................................3
    Author's Address...................................................4

    Nickless     Informational - Expires November 2001               1 
                   Application of Multiprotocol BGP-4        April 2001
                       To IPv4 Multicast Routing

Overview

    Current best practice for IPv4 multicast service provision uses four
    different protocols: Internet Group Management Protcol, Protocol
    Independent Multicast (Sparse Mode), Border Gateway Protocol with
    multiprotocol extensions, and the Multicast Source Discovery
    Protocol.  This document outlines how these protocols work together
    to provide end-to-end IPv4 multicast service.  In addition, this
    document describes best current practices for configuring these
    protocols, individually and in combination.

Conventions used in this document

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in RFC-2119
    [RFC2119].

Introduction and Terminology

    IPv4 multicast [MCAST] is an internetwork service that allows IPv4
    datagrams sent from a source to be delivered to more than one
    interested receiver.  That is, a given source sends a packet the
    network with a destination address 224/4 CIDR [CIDR] range.  The
    network transports this packet to all receivers (replicated where
    necessary) that have registered their interest in receiving these
    packets.

Application of Multiprotocol BGP-4 SAFI Field

    The topology of inter-domain IPv4 multicast forwarding is determined
    by BGPv4 [BGPV4] policy, as is IPv4 unicast forwarding.  BGP
    provides reachability information.  Reachability information for
    IPv4 Unicast and IPv4 Multicast prefixes can be advertised
    separately.  (See [MBGP] for details and the definition of Network
    Layer Reachability Information (NLRI) and Subsequent Address Family
    Information (SAFI).) The practical definition of reachability is
    different for IPv4 unicast (NLRI=unicast, SAFI=1) and IPv4 multicast
    (NLRI=Multicast, SAFI=2).

    In the case of BGP multicast advertisements (NLRI=Multicast,
    SAFI=2), reachability is defined to mean two things:

    First, IPv4 datagrams can be requested (or accepted) from sources
    within the advertised prefix range.  Such requests SHOULD be made to
    the advertised NEXT_HOP by means of the PIM Sparse Mode [PIM-SM]
    protocol.   Any other mutually agreed upon protocol that supports

    Nickless     Informational - Expires November 2001               2 
                   Application of Multiprotocol BGP-4        April 2001
                       To IPv4 Multicast Routing

    source-specific traffic requests MAY be used to support this
    requirement.

    Second, the MSDP [MSDP] speaker with the NEXT_HOP address SHOULD
    provide MSDP Source Active messages from PIM Rendevous Points within
    the advertised prefix range.  Any other mutually agreed upon
    protocol that supports the spreading of knowledge of active anycast
    sources MAY be used to support this requirement in lieu of, or in
    addition to, MSDP.

    These two definitions of BGP NLRI=Multicast flow from the original
    use of BGP to control Distance Vector Multicast Routing Protocol
    [DVMRP].  DVMRP is a "dense" routing protocol, which means traffic
    is flooded outwards from the sources to all possible receivers.  In
    this situation, an IPv4 multicast router has to decide which
    incoming interface may accept IPv4 datagrams from a given source (to
    avoid forwarding loops).  When the switch was made to use a "sparse"
    forwarding model (requiring source-specific requests for traffic to
    flow) both interpretations of BGP NLRI=Multicast became necessary
    for interoperability with the DVMRP-based model.

    Note that while MSDP is not strictly necessary for Autonomous
    Systems that only support Source Specific Multicast [SSM], MSDP
    depends on the latter interpretation of BGP NLRI=Multicast to avoid
    MSDP SA forwarding loops.  There is a real danger of causing MSDP SA
    forwarding "black holes" unless MSDP peerings are set up at the same
    time as BGP NLRI=Multicast peerings.

    MBGP also supports combined multicast and unicast advertisements
    (SAFI=3).  We define these advertisements to include the multicast
    meanings above in addition to reachability for unicast forwarding.

Security Considerations

    The extensions defined in this document allow BGP speakers to make
    use of reachability information about IPv4 multicast sources.  As
    such, no new security issues are raised beyond those that already
    exist in BGP-4, PIM-SM, and MSDP.

Acknowledgements

    This work was supported by the Mathematical, Information, and
    Computational Sciences Division subprogram of the Office of Advanced
    Scientific Computing Research, U.S. Department of Energy, under
    Contract W-31-109-Eng-38.

References

    Nickless     Informational - Expires November 2001               3 
                   Application of Multiprotocol BGP-4        April 2001
                       To IPv4 Multicast Routing

    [RFC2119] RFC 2119: Key Words for use in RFCs to Indicate
       Requirement Levels.  S. Bradner.  March 1997.

    [MCAST] RFC 1112: Host extensions for IP multicasting. S.E. Deering.
       Aug-01-1989.

    [CIDR] RFC 1519: Classless Inter-Domain Routing (CIDR): an Address
       Assignment and Aggregation Strategy. V. Fuller, T. Li, J. Yu, K.
       Varadhan. September 1993.

    [BGPV4] RFC 1771: A Border Gateway Protocol 4 (BGP-4).  Y. Rekhter,
       T. Li.  March 1995.

    [MBGP] RFC 2858: Multiprotocol Extensions for BGP-4.  T. Bates, Y.
       Rekhter, R. Chandra, D. Katz.  June 2000.

    [PIM-SM] RFC 2117: Protocol Independent Multicast-Sparse Mode (PIM-
       SM): Protocol Specification.  D. Estrin, D. Farinacci, A. Helmy,
       D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P.
       Sharma, L. Wei.  June 1997.

    [MSDP] draft-ietf-msdp-spec-09.txt: Multicast Source Discovery
       Protocol (MSDP).  D. Meyer (Editor).  March 2001.

    [DVMRP] RFC 1075: Distance Vector Multicast Routing Protocol.  D.
       Waitzman, C. Partridge, S.E. Deering.  November 1988.

Author's Address

    Bill Nickless
    Argonne National Laboratory
    9700 South Cass Avenue #221     Phone:  +1 630 252 7390
    Argonne, IL 60439               Email:  [email-masked]

    Nickless     Informational - Expires November 2001               4 

Date: Sat, 26 May 2001 19:50:11 -0400 (EDT)
From: abha ahuja <[email-masked]>
To: <[email-masked]>
Cc: Alex Zinin <[email-masked]>, "Shekhar, Ravi" <[email-masked]>, <[email-masked]>
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

> aside:
>
> list moderators:  I am not seeing ravi's email.  Apparently something
> is horked.

i'll take a look.

idr folks - keep in mind that you need to be subscribed to
[email-masked] in order to post to the mailing list.

-abha ;)

Date: Fri, 25 May 2001 22:52:06 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Russ White <[email-masked]>, "Shekhar, Ravi" <[email-masked]>, <[email-masked]>
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

To add to Russ' points here...

Even if there was a possibility to request routes having
a specific next-hop, it would mean: a) the entire routing table
for eBGP or b) a considerable part of it for iBGP (since a lot
of prefixes share the same next-hop).

It would also mean that:

 1) We introduce the feedback from the state (read "stability")
    of the IGP protocol up to the BGP level.

 2) Propagation of the new best path is delayed until the router
    receives the full info for the path that has been thrown away.

 3) This may delay BGP convergence, since the neighbors will have
    to unnecessarily start the MinRouteAdvertisementInterval for
    us and delay other updates.

 4) This is just not a right thing to do since the base spec
    has no notion of route-refresh, so people looking for basic
    BGP functionality will be mislead. (I think I've emphasized
    this enough).
    
-- 
Alex Zinin

Friday, May 25, 2001, 6:59:15 PM, Russ White wrote:

> I'll agree with Alex here, and say that we should keep paths that
> fail a nh test. 

> -- There's no way to request 'all the routes that match this next
> hop' from a neighbor when you suddenly receive a route for a new
> network.

> -- You have no way of knowing if any new route in the table will
> suddenly give you some new next hop to some routes that you've
> thrown away. You'd be requesting, essentially, full updates from
> all neighbors each time there is a change in your local routing
> table. Not good.

> :-)

> Russ

> On Fri, 25 May 2001, Alex Zinin wrote:

>> 
>> Ravi,
>> 
>>   I guess we will have to disagree and see what other
>>   people say about this :)
>> 
>> -- 
>> Alex Zinin
>> 
>> Friday, May 25, 2001, 12:59:06 PM, Shekhar, Ravi wrote:
>> 
>>  
>> >> >> One has to be able to store all paths when all NHs are reachable
>> >> 
>> >> >   Well, not really. An implementation could store only the 
>> >> best routes 
>> >> >   for a destination. And get rid of all the non-best ones 
>> >> (even though their
>> >> >   NHs are reachable) which are from peers which support 
>> >> route-refresh 
>> >> >   capability. In the event of needing it again, it could 
>> >> request it from 
>> >> >   that peer. Perhaps inefficient, but it will work. And/Or 
>> >> perhaps the
>> >> >   reason could still be saving the memory.
>> >> 
>> >> I'd encourage you to think about how this approach would practically
>> >> affect BGP convergence and after that about whether you would
>> >> like to see such an implementation in the Internet backbone.
>> 
>> 
>> >   Alex, I was just trying to point out something which you may have missed. 
>> >   I understand all those factors as I am working on a BGP implementation.
>> 
>> >   First, every router does not run on Internet backbone. Besides there
>> >   are edge routers on Internet which may have some other more important
>> >   functionalities to support and resources to dedicate to than optimizing 
>> >   BGP convergence, especially if they are not transit routers but are multi 
>> >   homed for redundancy. 
>> 
>> >   Second, I just gave an example of keeping one best route. But one could 
>> >   think of a router keeping only two or for that matter three best routes
>> > for a 
>> >   given destination but *not all* of them. That in my opinion does not
>> > effect 
>> >   convergence that bad unless all three of its routes go down
>> > simultaneously. 
>> 
>> >> > That would 
>> >> >   preclude someone from doing such kind of things even for 
>> >> peers which 
>> >> >   support route-refresh capability.
>> >> 
>> >> Exactly. I do believe there is a reason to preclude this. First,
>> >> because (again) route-refresh is no in the basis spec, second
>> >> (maybe even more important), because I see no reason to encourage
>> >> people to implement "optimizations" like this, and third (most
>> >> important) because this will result in incorrect implementations
>> >> if someone treats "shall/should/could" as "not necessary".
>> >> 
>> 
>> >   I tend to disagree. As I said one very good reason is that you have 
>> >   an edge router with 5 redundant BGP peering getting all 100,000 Internet 
>> >   routes. One could choose to keep only 2 best routes and not all of them
>> >   on such routers, thereby drastically reducing the memory consumption.
>> 
>> >   And an implementation can be buggy even if its a MUST there. Preventing 
>> >   possible optimizations just to make sure someone does not mis-interpret 
>> >   the spec does not seem to be a good idea to me.
>> 
>> >   Regards.
>> >   - Ravi Shekhar. 
>> 
>> 
>> 

> _____________________________
> [email-masked] <>< Grace Alone

Date: Fri, 25 May 2001 18:57:32 -0500
From: [email-masked]
To: Alex Zinin <[email-masked]>
Cc: "Shekhar, Ravi" <[email-masked]>, [email-masked]
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

aside:

list moderators:  I am not seeing ravi's email.  Apparently something
is horked.

	--> Alex Zinin <[email-masked]> [010525 18:26]:

> 
> Ravi,
> 
>   I guess we will have to disagree and see what other
>   people say about this :)
> 
> -- 
> Alex Zinin
> 
> Friday, May 25, 2001, 12:59:06 PM, Shekhar, Ravi wrote:
> 
>  
> >> >> One has to be able to store all paths when all NHs are reachable
> >> 
> >> >   Well, not really. An implementation could store only the 
> >> best routes 
> >> >   for a destination. And get rid of all the non-best ones 
> >> (even though their
> >> >   NHs are reachable) which are from peers which support 
> >> route-refresh 
> >> >   capability. In the event of needing it again, it could 
> >> request it from 
> >> >   that peer. Perhaps inefficient, but it will work. And/Or 
> >> perhaps the
> >> >   reason could still be saving the memory.
> >> 
> >> I'd encourage you to think about how this approach would practically
> >> affect BGP convergence and after that about whether you would
> >> like to see such an implementation in the Internet backbone.
> 
> 
> >   Alex, I was just trying to point out something which you may have missed. 
> >   I understand all those factors as I am working on a BGP implementation.
> 
> >   First, every router does not run on Internet backbone. Besides there
> >   are edge routers on Internet which may have some other more important
> >   functionalities to support and resources to dedicate to than optimizing 
> >   BGP convergence, especially if they are not transit routers but are multi 
> >   homed for redundancy. 
> 
> >   Second, I just gave an example of keeping one best route. But one could 
> >   think of a router keeping only two or for that matter three best routes
> > for a 
> >   given destination but *not all* of them. That in my opinion does not
> > effect 
> >   convergence that bad unless all three of its routes go down
> > simultaneously. 
> 
> >> > That would 
> >> >   preclude someone from doing such kind of things even for 
> >> peers which 
> >> >   support route-refresh capability.
> >> 
> >> Exactly. I do believe there is a reason to preclude this. First,
> >> because (again) route-refresh is no in the basis spec, second
> >> (maybe even more important), because I see no reason to encourage
> >> people to implement "optimizations" like this, and third (most
> >> important) because this will result in incorrect implementations
> >> if someone treats "shall/should/could" as "not necessary".
> >> 
> 
> >   I tend to disagree. As I said one very good reason is that you have 
> >   an edge router with 5 redundant BGP peering getting all 100,000 Internet 
> >   routes. One could choose to keep only 2 best routes and not all of them
> >   on such routers, thereby drastically reducing the memory consumption.
> 
> >   And an implementation can be buggy even if its a MUST there. Preventing 
> >   possible optimizations just to make sure someone does not mis-interpret 
> >   the spec does not seem to be a good idea to me.
> 
> >   Regards.
> >   - Ravi Shekhar. 
> 
> 

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

Date: Fri, 25 May 2001 21:59:15 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: "Shekhar, Ravi" <[email-masked]>, [email-masked]
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

I'll agree with Alex here, and say that we should keep paths that
fail a nh test. 

-- There's no way to request 'all the routes that match this next
hop' from a neighbor when you suddenly receive a route for a new
network.

-- You have no way of knowing if any new route in the table will
suddenly give you some new next hop to some routes that you've
thrown away. You'd be requesting, essentially, full updates from
all neighbors each time there is a change in your local routing
table. Not good.

:-)

Russ

On Fri, 25 May 2001, Alex Zinin wrote:

> 
> Ravi,
> 
>   I guess we will have to disagree and see what other
>   people say about this :)
> 
> -- 
> Alex Zinin
> 
> Friday, May 25, 2001, 12:59:06 PM, Shekhar, Ravi wrote:
> 
>  
> >> >> One has to be able to store all paths when all NHs are reachable
> >> 
> >> >   Well, not really. An implementation could store only the 
> >> best routes 
> >> >   for a destination. And get rid of all the non-best ones 
> >> (even though their
> >> >   NHs are reachable) which are from peers which support 
> >> route-refresh 
> >> >   capability. In the event of needing it again, it could 
> >> request it from 
> >> >   that peer. Perhaps inefficient, but it will work. And/Or 
> >> perhaps the
> >> >   reason could still be saving the memory.
> >> 
> >> I'd encourage you to think about how this approach would practically
> >> affect BGP convergence and after that about whether you would
> >> like to see such an implementation in the Internet backbone.
> 
> 
> >   Alex, I was just trying to point out something which you may have missed. 
> >   I understand all those factors as I am working on a BGP implementation.
> 
> >   First, every router does not run on Internet backbone. Besides there
> >   are edge routers on Internet which may have some other more important
> >   functionalities to support and resources to dedicate to than optimizing 
> >   BGP convergence, especially if they are not transit routers but are multi 
> >   homed for redundancy. 
> 
> >   Second, I just gave an example of keeping one best route. But one could 
> >   think of a router keeping only two or for that matter three best routes
> > for a 
> >   given destination but *not all* of them. That in my opinion does not
> > effect 
> >   convergence that bad unless all three of its routes go down
> > simultaneously. 
> 
> >> > That would 
> >> >   preclude someone from doing such kind of things even for 
> >> peers which 
> >> >   support route-refresh capability.
> >> 
> >> Exactly. I do believe there is a reason to preclude this. First,
> >> because (again) route-refresh is no in the basis spec, second
> >> (maybe even more important), because I see no reason to encourage
> >> people to implement "optimizations" like this, and third (most
> >> important) because this will result in incorrect implementations
> >> if someone treats "shall/should/could" as "not necessary".
> >> 
> 
> >   I tend to disagree. As I said one very good reason is that you have 
> >   an edge router with 5 redundant BGP peering getting all 100,000 Internet 
> >   routes. One could choose to keep only 2 best routes and not all of them
> >   on such routers, thereby drastically reducing the memory consumption.
> 
> >   And an implementation can be buggy even if its a MUST there. Preventing 
> >   possible optimizations just to make sure someone does not mis-interpret 
> >   the spec does not seem to be a good idea to me.
> 
> >   Regards.
> >   - Ravi Shekhar. 
> 
> 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 25 May 2001 13:13:23 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Shekhar, Ravi" <[email-masked]>
Cc: [email-masked]
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

Ravi,

  I guess we will have to disagree and see what other
  people say about this :)

-- 
Alex Zinin

Friday, May 25, 2001, 12:59:06 PM, Shekhar, Ravi wrote:

>> >> One has to be able to store all paths when all NHs are reachable
>> 
>> >   Well, not really. An implementation could store only the 
>> best routes 
>> >   for a destination. And get rid of all the non-best ones 
>> (even though their
>> >   NHs are reachable) which are from peers which support 
>> route-refresh 
>> >   capability. In the event of needing it again, it could 
>> request it from 
>> >   that peer. Perhaps inefficient, but it will work. And/Or 
>> perhaps the
>> >   reason could still be saving the memory.
>> 
>> I'd encourage you to think about how this approach would practically
>> affect BGP convergence and after that about whether you would
>> like to see such an implementation in the Internet backbone.

>   Alex, I was just trying to point out something which you may have missed. 
>   I understand all those factors as I am working on a BGP implementation.

>   First, every router does not run on Internet backbone. Besides there
>   are edge routers on Internet which may have some other more important
>   functionalities to support and resources to dedicate to than optimizing 
>   BGP convergence, especially if they are not transit routers but are multi 
>   homed for redundancy. 

>   Second, I just gave an example of keeping one best route. But one could 
>   think of a router keeping only two or for that matter three best routes
> for a 
>   given destination but *not all* of them. That in my opinion does not
> effect 
>   convergence that bad unless all three of its routes go down
> simultaneously. 

>> > That would 
>> >   preclude someone from doing such kind of things even for 
>> peers which 
>> >   support route-refresh capability.
>> 
>> Exactly. I do believe there is a reason to preclude this. First,
>> because (again) route-refresh is no in the basis spec, second
>> (maybe even more important), because I see no reason to encourage
>> people to implement "optimizations" like this, and third (most
>> important) because this will result in incorrect implementations
>> if someone treats "shall/should/could" as "not necessary".
>> 

>   I tend to disagree. As I said one very good reason is that you have 
>   an edge router with 5 redundant BGP peering getting all 100,000 Internet 
>   routes. One could choose to keep only 2 best routes and not all of them
>   on such routers, thereby drastically reducing the memory consumption.

>   And an implementation can be buggy even if its a MUST there. Preventing 
>   possible optimizations just to make sure someone does not mis-interpret 
>   the spec does not seem to be a good idea to me.

>   Regards.
>   - Ravi Shekhar. 

Date: Fri, 25 May 2001 12:32:25 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Shekhar, Ravi" <[email-masked]>
Cc: [email-masked]
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

Ravi,

>> One has to be able to store all paths when all NHs are reachable

>   Well, not really. An implementation could store only the best routes 
>   for a destination. And get rid of all the non-best ones (even though their
>   NHs are reachable) which are from peers which support route-refresh 
>   capability. In the event of needing it again, it could request it from 
>   that peer. Perhaps inefficient, but it will work. And/Or perhaps the
>   reason could still be saving the memory.

I'd encourage you to think about how this approach would practically
affect BGP convergence and after that about whether you would
like to see such an implementation in the Internet backbone.

>> anyway. A mechanism to request paths when we believe the NH is ok
>> sounds more like a trouble to me . Besides, we're talking about
>> the basis spec, that does not include the route-refresh option.

>   I guess what I am trying to arrive at is that we probably should 
>   not make it a requirement i.e "MUST" in the basic spec.

> That would 
>   preclude someone from doing such kind of things even for peers which 
>   support route-refresh capability.

Exactly. I do believe there is a reason to preclude this. First,
because (again) route-refresh is no in the basis spec, second
(maybe even more important), because I see no reason to encourage
people to implement "optimizations" like this, and third (most
important) because this will result in incorrect implementations
if someone treats "shall/should/could" as "not necessary".

Alex.

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: comments from Ed 
Date: Fri, 25 May 2001 11:55:11 -0600
Sender: [email-masked]

> From RFC2119:
> 
> 1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
>    definition is an absolute requirement of the specification.
> 
> So, I would assert the specification does preclude any other actions
> on the part of impementors.  The fact that implementations do not comply
> with this part of the specification doesn't change the wording of the
> specification.

Well, it defintely needs to be fixed then, esp. scoping to 
Loc-RIB and removing the Adj-RIB-In wording, or specifying 
that the routes SHALL remain in the Adj-RIB-In.

-danny

Date: Fri, 25 May 2001 11:33:41 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: "Shekhar, Ravi" <[email-masked]>
Cc: [email-masked]
Subject: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

Ravi,

One has to be able to store all paths when all NHs are reachable
anyway. A mechanism to request paths when we believe the NH is ok
sounds more like a trouble to me . Besides, we're talking about
the basis spec, that does not include the route-refresh option.

Alex.

>> Actually, I'd say this is a requirement. We can't just remove paths,
>> since NH resolvability may change in time, so a path can become
>> feasible and we're not receiving periodic updates from the neighbors.
>> 

>   It may not strictly be a requirement. Even though there is no periodic 
>   update, one could use route-refresh capability to take care of this.

>   For instance (to save some memory), an implementation could just keep
>   track of NH, and not keep the routes themselves which are learnt from
>   a neighbor which supports route-refresh capability. In the event of 
>   reachability to NH changing, it could use route-refresh capability 
>   to relearn the routes. 

>   Regards.
>   - Ravi Shekhar.

Date: Fri, 25 May 2001 11:14:07 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Danny McPherson <[email-masked]>
Cc: [email-masked]
Subject: Re: comments from Ed
Sender: [email-masked]

Danny,

>>  (A) vendor may want to keep routes which are considered unfeasible due to
>>  lack of valid nh to recurse to around in whatever structure set they are
>>  using as an adj-rib in equivalent.  This is obviously an implementation 
>>  detail, but it seems odd to preclude this in the spec?  

> I don't think "shall" precludes anything here.

It's just wrong, I guess ;)

>   Of course, I agree
> that it's unlikely anyone removes the routes from the Adj-RIBs-In, and 
> that portion of the text could probably just be clarified, and we 
> should probably require that they _not be removed from the Adj-RIB-In.

Right. No path should be removed from Adj-RIB-In unless the peer
goes down, we receive a withdrawal from it, or the policy requires so.

Alex.

Date: Fri, 25 May 2001 11:03:54 -0700
From: Ben Black <[email-masked]>
To: Danny McPherson <[email-masked]>
Cc: [email-masked]
Subject: Re: comments from Ed
Sender: [email-masked]

On Fri, May 25, 2001 at 08:53:28AM -0600, Danny McPherson wrote:
> 
> I don't think "shall" precludes anything here.

>From RFC2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

So, I would assert the specification does preclude any other actions
on the part of impementors.  The fact that implementations do not comply
with this part of the specification doesn't change the wording of the
specification.

Ben

Date: Fri, 25 May 2001 14:14:18 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: : Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

> I guess we may have to provide a definition of the route
> resolvability condition and then say that unresolvable routes
> should not be considered feasible.
> 
> Something like this:
> 
> > The resolvability condition is defined as follows.
> >
> > 1.    A route Rte1, referencing only the intermediate network address,
> > is considered resolvable if the routing table contains at least one
> > resolvable route Rte2 that matches Rte1's intermediate network address
> > and is not recursively resolved (directly or indirectly) through Rte1.
> >
> > 2.    Routes referencing interfaces (with or without intermediate
> > addresses) are considered resolvable if the state of the referenced
> > interface is up and IP processing is enabled on this interface.
> 
> BGP routes do not refer to interfaces, but are resolved
> through the routes in the routing table that can be of both
> types.

This sounds correct, given the rest of the conversation. :-)

> We seem to be in sync.

Yep--and the rest of the emails in the thread seem to point the
same way as well.

:-)

Russ

_____________________________
[email-masked] <>< Grace Alone

Date: Fri, 25 May 2001 11:08:41 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Russ White <[email-masked]>
Cc: Russ White <[email-masked]>, [email-masked]
Subject: Re: : Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

Russ,

>> I have another suggestion here. We should exclude the paths
>> that would fail the NH resolution if they are installed,
>> i.e., if we have a path to 20.20.20.0/24 via 20.20.20.20 and
>> the NH is resolvable through 20.0.0.0/8 or the default
>> currently installed, such path should be considered as
>> unfeasible, since it will finally be removed from the RT
>> because of the recursive route check failure.
>> 
>> The definition of such a route could be something like "if the prefix
>> resolves the NH and is more specific than the currently installed
>> best matching route for the NH." It is definitely a specific case
>> of a recursion loop with depth == 1, but it does help in practice.

> Do you think the case of the next-hop being resolved through a
> shorter prefix route already installed is more common than the
> next-hop of a shorter prefix route being resolved through a
> longer prefix route is more common? 

Definitely the situation where the NH of a shorter prefix is resolved
through an already installed longer one is perfectly valid and more
common. However, the situation I described can still be seen
under certain conditions and causes major RT churns (routes get
installed, then invalidated, installed again, etc.) One could say this
is just wrong configuration. On the other hand, the protocol (and
hence its implementations) should be smart enough to avoid
instability. This check will also improve reachability, as routes
that would cause fwd'ing table lookup failure will be considered as
unfeasible during the best path selection process, so only valid
routes play and get installed in the routing/fwd'ing tables.

> Actually, wouldn't it be easier to simply reject anything that
> resolves through a bgp-learned route currently installed in the
> routing table on the peer (not the Loc-RIB)? Or is this feasible?

Not really. People do announce DMZs through BGP. As soon as there's
a more specific route to the DMZ prefix's NH, we're fine.

I guess we may have to provide a definition of the route
resolvability condition and then say that unresolvable routes
should not be considered feasible.

Something like this:

> The resolvability condition is defined as follows.
>
> 1.    A route Rte1, referencing only the intermediate network address,
> is considered resolvable if the routing table contains at least one
> resolvable route Rte2 that matches Rte1's intermediate network address
> and is not recursively resolved (directly or indirectly) through Rte1.
>
> 2.    Routes referencing interfaces (with or without intermediate
> addresses) are considered resolvable if the state of the referenced
> interface is up and IP processing is enabled on this interface.

BGP routes do not refer to interfaces, but are resolved through the
routes in the routing table that can be of both types.

>> Also, this part:
>> 
>> > This immediate next hop MUST be used
>> >    when installing the selected route in the Loc-RIB.
>> 
>> - should be removed, I guess. It just does not reflect the reality.

> Wouldn't this imply that the paragraph above should also not
> state anything about how the speaker sets the next hop when
> installing prefixes in the Loc-RIB?

Isn't this exactly the part that I suggested to remove... or
am I missing something?

>> Actually, I'd say this is a requirement. We can't just remove paths,
>> since NH resolvability may change in time, so a path can become
>> feasible and we're not receiving periodic updates from the neighbors.

> I doubt anyone actually tosses these routes today, so this should
> be changed to fix reality.

We seem to be in sync.

Alex.

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: comments from Ed 
Date: Fri, 25 May 2001 08:53:28 -0600
Sender: [email-masked]

>  this would seem to imply that if the NH for a given prefix does /not/ 
>  exist as a selected (ie: best) _bgp_ route, the prefix shall be excluded 
>  from the decision process.  Should this not be urib?

I agree that this should be corrected.

>  IMO the term IGP was misleading here.  The nh may exist
>  as static, as direct, in an IGP, or in BGP itself.  as long as the 
>  nh is present in the unicast rib and the recursive lookup does not 
>  loop, the route should be considered feasible?

I agree that IGP doesn't encompass other possible sources, this 
should be clarified.

>     Unfeasible routes shall be removed from the Loc-RIB, and
>     corresponding unfeasible routes shall then be removed from the Adj-
>     RIBs-In.
>   
>  (A) vendor may want to keep routes which are considered unfeasible due to   
>  lack of valid nh to recurse to around in whatever structure set they are
>  using as an adj-rib in equivalent.  This is obviously an implementation 
>  detail, but it seems odd to preclude this in the spec?  

I don't think "shall" precludes anything here.  Of course, I agree
that it's unlikely anyone removes the routes from the Adj-RIBs-In, and 
that portion of the text could probably just be clarified, and we 
should probably require that they _not be removed from the Adj-RIB-In.

-danny 

To: [email-masked]
From: Danny McPherson <[email-masked]>
Reply-To: [email-masked]
Subject: Re: AS Path ORF as an IDR WG document 
Date: Fri, 25 May 2001 08:39:51 -0600
Sender: [email-masked]

IMO, it should be merged with draft-ietf-idr-route-filter-03.txt, 
and then progressed in the working group.  Unless I've missed 
something, it doesn't make much sense to progress these two 
documents independently.

Also, I'm not sure I understand the reference to "It contains 
additional Route Refresh functionality ..." below.  I'm guessing
this was just a mistake, and was meant to say that "It defines
additional cooperative route filtering capabilities ...". 

Of course, I guess one could define a similar mechanism to optimize
Route Refresh requests so that only relevant portions of a peers
Adj-RIB-Out are requested, rather than the current "send me everything" 
model, though nothing I see in the draft even remotely alludes to this.

-danny

> Please comment on the attached request. In the interest
> of making timely progress the deadline for comments is
> two weeks from today.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Wed, 23 May 2001 23:54:57 -0400
> From:    Susan Hares <[email-masked]>
> To:      [email-masked], yakov Rekhter <[email-masked]>
> cc:      [email-masked], [email-masked]
> Subject: AS Path ORF draft
> 
> 
> Yakov and working group:
> 
> We would to request that the AS Path ORF draft below be considered for an
> IDR draft.     It contains additional Route Refresh functionality for 
> portions of
> the Internet that use AS Path based filtering.
> 
> 
> 		  Aspath Based Outbound Route Filter for BGP-4
> 			draft-keyur-bgp-aspath-orf-00.txt
> 
> 
> Sue Hares and Keyur Patel
> 
> 
> ------- End of Forwarded Message
> 

Date: Thu, 24 May 2001 20:46:45 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: Fwd: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

> > 9.1.2 Phase 2: Route Selection
> >  ----------
>   
> >     If the NEXT_HOP attribute of a BGP route depicts an address to which
> >     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
> >     route should be excluded from the Phase 2 decision function.
>   
> >  this would seem to imply that if the NH for a given prefix does /not/ 
> >  exist as a selected (ie: best) _bgp_ route, the prefix shall be excluded from
> >  the decision process.  Should this not be urib?
> 
> Yes, I think this should be changed.

In fact, it's worse than implying. Back in the definitions, we
have:

> b) Loc-RIB: The Loc-RIB contains the local routing
> information that the BGP speaker has selected by applying its
> local policies to the routing information contained in its
> Adj-RIBs-In.

So the Loc-RIB is specifically BGP routes locally selected as
best.

> I have another suggestion here. We should exclude the paths
> that would fail the NH resolution if they are installed,
> i.e., if we have a path to 20.20.20.0/24 via 20.20.20.20 and
> the NH is resolvable through 20.0.0.0/8 or the default
> currently installed, such path should be considered as
> unfeasible, since it will finally be removed from the RT
> because of the recursive route check failure.
> 
> The definition of such a route could be something like "if the prefix
> resolves the NH and is more specific than the currently installed
> best matching route for the NH." It is definitely a specific case
> of a recursion loop with depth == 1, but it does help in practice.

Do you think the case of the next-hop being resolved through a
shorter prefix route already installed is more common than the
next-hop of a shorter prefix route being resolved through a
longer prefix route is more common? 

Actually, wouldn't it be easier to simply reject anything that
resolves through a bgp-learned route currently installed in the
routing table on the peer (not the Loc-RIB)? Or is this feasible?

> >     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. The local speaker MUST determine the immediate
> >     next hop to the address depicted by the NEXT_HOP attribute of the
> >     selected route by performing a lookup in it's routing table and selecting 
> >     the best path therein.
> 
> I think it is better, but we should also make it clear
> throughout the doc.
> 
> Also, this part:
> 
> > This immediate next hop MUST be used
> >    when installing the selected route in the Loc-RIB.
> 
> - should be removed, I guess. It just does not reflect the reality.

Wouldn't this imply that the paragraph above should also not
state anything about how the speaker sets the next hop when
installing prefixes in the Loc-RIB?

> >     Unfeasible routes shall be removed from the Loc-RIB, and
> >     corresponding unfeasible routes shall then be removed from the Adj-
> >     RIBs-In.
>   
> >  (A) vendor may want to keep routes which are considered unfeasible due to   
> >  lack of valid nh to recurse to around in whatever structure set they are
> >  using as an adj-rib in equivalent.  This is obviously an implementation 
> >  detail, but it seems odd to preclude this in the spec?  
> 
> Actually, I'd say this is a requirement. We can't just remove paths,
> since NH resolvability may change in time, so a path can become
> feasible and we're not receiving periodic updates from the neighbors.

I doubt anyone actually tosses these routes today, so this should
be changed to fix reality.

Russ

_____________________________
[email-masked] <>< Grace Alone

Date: Thu, 24 May 2001 10:17:39 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: AS Path ORF as an IDR WG document
Sender: [email-masked]

I think it should be a WG item.

AS_PATH-based filtering is widely used and in addition
to BW and CPU savings, as a side effect this mechanism will
somewhat improve BGP performance in a way similar to transmit
side loop detection (see Delayed BGP Convergence, Labovitz, Abha,
et al.)

-- 
Alex Zinin

Thursday, May 24, 2001, 9:19:27 AM, Yakov Rekhter wrote:

> Folks,

> Please comment on the attached request. In the interest
> of making timely progress the deadline for comments is
> two weeks from today.

> Yakov.
> ------- Forwarded Message

> Date:    Wed, 23 May 2001 23:54:57 -0400
> From:    Susan Hares <[email-masked]>
> To:      [email-masked], yakov Rekhter <[email-masked]>
> cc:      [email-masked], [email-masked]
> Subject: AS Path ORF draft

> Yakov and working group:

> We would to request that the AS Path ORF draft below be considered for an
> IDR draft.     It contains additional Route Refresh functionality for 
> portions of
> the Internet that use AS Path based filtering.

>                   Aspath Based Outbound Route Filter for BGP-4
>                         draft-keyur-bgp-aspath-orf-00.txt

> Sue Hares and Keyur Patel

> ------- End of Forwarded Message

Date: Thu, 24 May 2001 09:06:35 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: [email-masked]
Subject: Fwd: Re: section 9.1.2: NH recursion questions
Sender: [email-masked]

Apparently this message didn't get through
Alex.

This is a forwarded message
From: Alex Zinin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Monday, May 21, 2001, 11:55:04 PM
Subject: section 9.1.2: NH recursion questions

===8<==============Original message text===============

Hi, Ed

See inline, pls.

> Hello folks.  I have a few questions on the current bgp draft (and
> 1771), all having to do with the phase 2 decision process:

> 9.1.2 Phase 2: Route Selection
>  ----------
  
>     If the NEXT_HOP attribute of a BGP route depicts an address to which
>     the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
>     route should be excluded from the Phase 2 decision function.
  
>  this would seem to imply that if the NH for a given prefix does /not/ 
>  exist as a selected (ie: best) _bgp_ route, the prefix shall be excluded from
>  the decision process.  Should this not be urib?

Yes, I think this should be changed.

First, it should be consistent with the following para you quote
below. Second, none of them should talk specifically about Loc-RIB
or IGP RT because of the reasons you mention below.

I have another suggestion here. We should exclude the paths that
would fail the NH resolution if they are installed, i.e.,
if we have a path to 20.20.20.0/24 via 20.20.20.20 and the NH
is resolvable through 20.0.0.0/8 or the default currently installed,
such path should be considered as unfeasible, since it will finally be
removed from the RT because of the recursive route check failure.

The definition of such a route could be something like "if the prefix
resolves the NH and is more specific than the currently installed
best matching route for the NH." It is definitely a specific case
of a recursion loop with depth == 1, but it does help in practice.

>     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. The local speaker MUST determine the immediate
>     next hop to the address depicted by the NEXT_HOP attribute of the
>     selected route by performing a lookup in the IGP and selecting one of
>     the possible paths in the IGP.  
  
>  IMO the term IGP was misleading here.  The nh may exist
>  as static, as direct, in an IGP, or in BGP itself.  as long as the nh is
>  present in the unicast rib and the recursive lookup does not loop, the 
>  route should be considered feasible?

Agree. All three variants are feasible.

> perhaps:

>     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. The local speaker MUST determine the immediate
>     next hop to the address depicted by the NEXT_HOP attribute of the
>     selected route by performing a lookup in it's routing table and selecting 
>     the best path therein.

I think it is better, but we should also make it clear throughout the
doc.

Also, this part:

> This immediate next hop MUST be used
>    when installing the selected route in the Loc-RIB.

- should be removed, I guess. It just does not reflect the reality.

>  ----------
  
>     Unfeasible routes shall be removed from the Loc-RIB, and
>     corresponding unfeasible routes shall then be removed from the Adj-
>     RIBs-In.
  
>  (A) vendor may want to keep routes which are considered unfeasible due to   
>  lack of valid nh to recurse to around in whatever structure set they are
>  using as an adj-rib in equivalent.  This is obviously an implementation 
>  detail, but it seems odd to preclude this in the spec?  

Actually, I'd say this is a requirement. We can't just remove paths,
since NH resolvability may change in time, so a path can become
feasible and we're not receiving periodic updates from the neighbors.

Alex.

===8<===========End of original message text===========

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: AS Path ORF as an IDR WG document
Date: Thu, 24 May 2001 09:19:27 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Please comment on the attached request. In the interest
of making timely progress the deadline for comments is
two weeks from today.

Yakov.
------- Forwarded Message

Date:    Wed, 23 May 2001 23:54:57 -0400
From:    Susan Hares <[email-masked]>
To:      [email-masked], yakov Rekhter <[email-masked]>
cc:      [email-masked], [email-masked]
Subject: AS Path ORF draft

Yakov and working group:

We would to request that the AS Path ORF draft below be considered for an
IDR draft.     It contains additional Route Refresh functionality for 
portions of
the Internet that use AS Path based filtering.

		  Aspath Based Outbound Route Filter for BGP-4
			draft-keyur-bgp-aspath-orf-00.txt

Sue Hares and Keyur Patel

------- End of Forwarded Message

To: [email-masked]
Subject: comments from Ed
Date: Thu, 24 May 2001 09:13:20 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Comments/recommendations on the e-mail that Ed posted to the list
this past Monday would be greatly appreciated (for completeness I
attached the e-mail from Ed). Specifically, we need to find out if
there are any objections to the changes suggested by Ed. In the
interest of making timely progress I'd like to suggest two weeks
deadline for comments.

Yakov.

------- Forwarded Message

Date: Mon, 21 May 2001 14:27:27 -0500
From: [email-masked]
To: [email-masked]
Subject: section 9.1.2: NH recursion questions
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1us
Sender: [email-masked]
Precedence: bulk

Hello folks.  I have a few questions on the current bgp draft (and
1771), all having to do with the phase 2 decision process:

9.1.2 Phase 2: Route Selection
 ----------
  
    If the NEXT_HOP attribute of a BGP route depicts an address to which
    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
    route should be excluded from the Phase 2 decision function.
  
 this would seem to imply that if the NH for a given prefix does /not/ 
 exist as a selected (ie: best) _bgp_ route, the prefix shall be excluded from
 the decision process.  Should this not be urib?
   
 ----------
  
    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. The local speaker MUST determine the immediate
    next hop to the address depicted by the NEXT_HOP attribute of the
    selected route by performing a lookup in the IGP and selecting one of
    the possible paths in the IGP.  
  
 IMO the term IGP was misleading here.  The nh may exist
 as static, as direct, in an IGP, or in BGP itself.  as long as the nh is
 present in the unicast rib and the recursive lookup does not loop, the 
 route should be considered feasible?

perhaps:

    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. The local speaker MUST determine the immediate
    next hop to the address depicted by the NEXT_HOP attribute of the
    selected route by performing a lookup in it's routing table and selecting 
    the best path therein. 
  
 ----------
  
    Unfeasible routes shall be removed from the Loc-RIB, and
    corresponding unfeasible routes shall then be removed from the Adj-
    RIBs-In.
  
 (A) vendor may want to keep routes which are considered unfeasible due to   
 lack of valid nh to recurse to around in whatever structure set they are
 using as an adj-rib in equivalent.  This is obviously an implementation 
 detail, but it seems odd to preclude this in the spec?  

Thanks,

	-ed  

------- End of Forwarded Message

Date: Wed, 23 May 2001 22:09:31 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Test message - please ignore
Cc: [email-masked], [email-masked]
Sender: [email-masked]

test message - please

Date: Wed, 23 May 2001 23:54:57 -0400
To: [email-masked], yakov Rekhter <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: AS Path ORF draft
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Yakov and working group:

We would to request that the AS Path ORF draft below be considered for an
IDR draft.     It contains additional Route Refresh functionality for 
portions of
the Internet that use AS Path based filtering.

		  Aspath Based Outbound Route Filter for BGP-4
			draft-keyur-bgp-aspath-orf-00.txt

Sue Hares and Keyur Patel

Date: Mon, 21 May 2001 18:09:11 -0400
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: BGP MIB work 
Cc: Susan Hares <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Enke:

My recollection is Yakov had wanted to hold until a new version of the draft
was published.    I'd like to ask at that point that this draft becomes
an IDR draft and then pushes toward standards.

We are working on the MIB to push this forward prior to the new draft.

If you have any other info abouthe draft, let me know.

Sue

At 01:15 PM 5/21/2001 -0700, Enke Chen wrote:

> > Date: Mon, 21 May 2001 15:09:08 -0400
> > To: [email-masked]
> > From: Susan Hares <[email-masked]>
> > Subject: BGP MIB work
> > Cc: [email-masked]
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset="us-ascii"; format=flowed
> > Sender: [email-masked]
> > Precedence: bulk
> >
> > At the March IETF, work on the following BGP-4 MIBs work was announced:
> >
> >       BGP 4 MIBs:
> >               AS Confederations, Route Reflection, Communities
> >                       and Extended Communities, Optional Capabilities.
>                             ^^^^^^^^^^^^^^^^^^^^^
>Please note that the extended community draft is still an individual
>submission. Can we please make it an IDR WG document?
>
>Thanks. -- Enke
>
> >
> >       MPBGP related MIBs:
> >               RFC 2858 - MP BGP including multicast
> >               RFC 2547 - MPBGP for IPv6
> >
> >   Sue Hares asked for volunteers to work on these MIBs, and a few brave
> > souls joined up. A few mib-experts were encouraged to join the MIB
> > group by Bert W.    The merry band of mib writers are busily hacking
> > their MIB definitions, and hope to have initial drafts out in June.
> >
> > Anyone wishing to join this merry band of mib-ites will be applauded.
> >
> >
> > Sue Hares and Yakov Rekhter
> > [email-masked]
> > [email-masked]
> >
> >

Date: Mon, 21 May 2001 14:27:27 -0500
From: [email-masked]
To: [email-masked]
Subject: section 9.1.2: NH recursion questions
Sender: [email-masked]

Hello folks.  I have a few questions on the current bgp draft (and
1771), all having to do with the phase 2 decision process:

9.1.2 Phase 2: Route Selection
 ----------
  
    If the NEXT_HOP attribute of a BGP route depicts an address to which
    the local BGP speaker doesn't have a route in its Loc-RIB, the BGP
    route should be excluded from the Phase 2 decision function.
  
 this would seem to imply that if the NH for a given prefix does /not/ 
 exist as a selected (ie: best) _bgp_ route, the prefix shall be excluded from
 the decision process.  Should this not be urib?
   
 ----------
  
    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. The local speaker MUST determine the immediate
    next hop to the address depicted by the NEXT_HOP attribute of the
    selected route by performing a lookup in the IGP and selecting one of
    the possible paths in the IGP.  
  
 IMO the term IGP was misleading here.  The nh may exist
 as static, as direct, in an IGP, or in BGP itself.  as long as the nh is
 present in the unicast rib and the recursive lookup does not loop, the 
 route should be considered feasible?

perhaps:

    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. The local speaker MUST determine the immediate
    next hop to the address depicted by the NEXT_HOP attribute of the
    selected route by performing a lookup in it's routing table and selecting 
    the best path therein. 
  
 ----------
  
    Unfeasible routes shall be removed from the Loc-RIB, and
    corresponding unfeasible routes shall then be removed from the Adj-
    RIBs-In.
  
 (A) vendor may want to keep routes which are considered unfeasible due to   
 lack of valid nh to recurse to around in whatever structure set they are
 using as an adj-rib in equivalent.  This is obviously an implementation 
 detail, but it seems odd to preclude this in the spec?  

Thanks,

	-ed  

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

To: Susan Hares <[email-masked]>, [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: BGP MIB work 
Date: Mon, 21 May 2001 13:15:33 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date: Mon, 21 May 2001 15:09:08 -0400
> To: [email-masked]
> From: Susan Hares <[email-masked]>
> Subject: BGP MIB work
> Cc: [email-masked]
> Mime-Version: 1.0
> Content-Type: text/plain; charset="us-ascii"; format=flowed
> Sender: [email-masked]
> Precedence: bulk
> 
> At the March IETF, work on the following BGP-4 MIBs work was announced:
> 
> 	 BGP 4 MIBs:
> 	 	 AS Confederations, Route Reflection, Communities
>                 	and Extended Communities, Optional Capabilities.
                            ^^^^^^^^^^^^^^^^^^^^^
Please note that the extended community draft is still an individual
submission. Can we please make it an IDR WG document?

Thanks. -- Enke
                             
> 
> 	 MPBGP related MIBs:
> 		 RFC 2858 - MP BGP including multicast
> 		 RFC 2547 - MPBGP for IPv6
> 
>   Sue Hares asked for volunteers to work on these MIBs, and a few brave
> souls joined up. A few mib-experts were encouraged to join the MIB
> group by Bert W.    The merry band of mib writers are busily hacking
> their MIB definitions, and hope to have initial drafts out in June.
> 
> Anyone wishing to join this merry band of mib-ites will be applauded.
> 
> 
> Sue Hares and Yakov Rekhter
> [email-masked]
> [email-masked]
> 
> 

Date: Mon, 21 May 2001 15:09:08 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: BGP MIB work
Cc: [email-masked]
Sender: [email-masked]

At the March IETF, work on the following BGP-4 MIBs work was announced:

	 BGP 4 MIBs:
	 	 AS Confederations, Route Reflection, Communities
                	and Extended Communities, Optional Capabilities.

	 MPBGP related MIBs:
		 RFC 2858 - MP BGP including multicast
		 RFC 2547 - MPBGP for IPv6

  Sue Hares asked for volunteers to work on these MIBs, and a few brave
souls joined up. A few mib-experts were encouraged to join the MIB
group by Bert W.    The merry band of mib writers are busily hacking
their MIB definitions, and hope to have initial drafts out in June.

Anyone wishing to join this merry band of mib-ites will be applauded.

Sue Hares and Yakov Rekhter
[email-masked]
[email-masked]

From: "proto man" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: aggregation in a confederation environment(RFC3065)
Date: Mon, 21 May 2001 01:39:37 -0000
Sender: [email-masked]

Thanks.
What about the case where we can preserve sequences :

For e.g :
A1 (100 200 300 ) { 400 500 } 900 800 700 [ 600 601]
A2 (100 200) { 400 } 900 800 [ 600 ]
A3 (100 200 300 ) 900 800 [601]

Aggr ASPATH :
   ( 100 200 ) { 300 400 500 } 900 800 [ 600 601 700]

would this work?

I guess some rewording of ASPATH aggregation in the context of
confederation might help. Or is forming ASPATH aggregate in confederation
is not in use at all?

-Priya

>From: [email-masked]
>To: [email-masked]
>CC: [email-masked]
>Subject: Re: aggregation in a confederation environment(RFC3065)
>Date: Sat, 19 May 2001 21:41:02 -0400
>
>How about:
>
>(1) Take all unique sub-AS numbers that appear in all CONFED_SEQs and 
>CONFED_SETs and put them in a CONFED_SET
>
>(2) Take all unique AS numbers that appear in all AS_SEQs and AS_SETs and 
>pt them in an AS_SET
>
>(3) The aggregated AS-path is the resulting CONFED_SET followed by the 
>resulting AS_SET
>
>So in your example you would get:
>
>{ 400 500 600 700 } [ 800 801 900 901 ]
>
>"proto man" <[email-masked]> wrote:
> >
> > Hi,
> >   How does one aggregate ASPATHS in a confederation environment.
> >   consider following aspaths
> >    [ ] denotes AS_SET
> >    () denotes CONFED_SEQ
> >    {} denotes CONFED_SET
> >    concatenation denontes AS_SEQ
> >
> >   Suppose we have aspaths of contributors to an aggregate
> >    A1 : ( 500 400 ) { 600 700 }
> >    A2 : 900 901 [ 800 801 ]
> >    A3 : ( 500 400 )
> >    A4 : 900 901
> >
> >   How should the aspath for the aggregate computed in such cases.
> >
> > Thanks for any clarification.
> >
> > -Priya
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >
> >
>__________________________________________________________________
>Get your own FREE, personal Netscape Webmail account today at 
>http://webmail.netscape.com/

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

From: "proto man" <[email-masked]>
To: [email-masked]
Subject: aggregation in a confederation environment(RFC3065)
Date: Sun, 20 May 2001 00:47:08 -0000
Sender: [email-masked]

Hi,
  How does one aggregate ASPATHS in a confederation environment.
  consider following aspaths
   [ ] denotes AS_SET
   () denotes CONFED_SEQ
   {} denotes CONFED_SET
   concatenation denontes AS_SEQ

  Suppose we have aspaths of contributors to an aggregate
   A1 : ( 500 400 ) { 600 700 }
   A2 : 900 901 [ 800 801 ]
   A3 : ( 500 400 )
   A4 : 900 901

  How should the aspath for the aggregate computed in such cases.

Thanks for any clarification.

-Priya

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Sun, 13 May 2001 01:37:23 -0400
To: [email-masked]
From: Susan Hares <[email-masked]>
Subject: Last Call on BGP Persistent Route Oscillation Condition
Cc: yakov Rekhter <[email-masked]>, abha ahuja <[email-masked]>
Sender: [email-masked]

This is a last call on

	BGP Persistent Route Oscillation Condition
	draft-ietf-idr-route-oscillation-00.txt

This draft will be forwarded to the IESG as an Informational Draft.

Please send comments or concerns to the list.   Last call will be
closed in 1 week on 5/21/01.

Sue Hares

content-class: urn:content-classes:message
Subject: RE: Internal Update Process of BGP4
Date: Sat, 12 May 2001 21:30:50 +0530
From: "deepak_srivastava" <[email-masked]>
To: "proto man" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C0DAFC.B73F52BD
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

In your example, which routes will be there in the bgp database of I2
before E3 withdraws its route from I1.

i) According to RFC1771 both routes, one from E3(through I1) and other
from E1 (through R) should be there. This is because its not written in
RFC to withdraw routes from internal peers if its not a best phase-2
route.
      This will save bandwidth.

ii) According to draft only route from E3 should be there in bgp
database of I2 as it is the best phase-2 route which will be there in
Loc-RIB of R.
      This will save memory. =20
         But I am not able to find in RFC and Draft-12 both how can R
inform I2 that route through E1 is now not a best route. R can send
updates(and thus withdrawls) to IBGP peers only as part of INTERNAL
UPDATE PROCESS. Since internal update is sent before start of phase-2,
how can R inform I2 after phase-2 that route through E1 is no more a
best route.

-----Original Message-----
From:	proto man
Sent:	Sat 5/12/2001 12:31 AM
To:	deepak_srivastava; [email-masked]
Cc:=09
Subject:	Re: Internal Update Process of BGP4

I am probably not answering the question you had asked. But i think
this may help clarify some intent. You may want to search archives
for better answers regarding this.

1) Sending the best external route helps to avoid churn.

2) Sending the best external route does not necessarily mean you need
to withdraw it subsequently when you learn that the best external route
is not your best route.

   For e.g :
    E3 I1   R   E1
       I2       E2

     Let the local speaker be R.
     I1,I2 are IBGP peers to R
     E1,E2 are EBGP peers to R
     E3 is EBGP peer to I1

     The best external route computed at R is via E1.
     Send best-external-route to I1,I2
     The best route computed at R is via I1.
     Send best-route to E1,E2.

     Suppose E3 withdraws the route from I1.
     I1 withdraws it from R.

     R's best-route changes to E1
     R's best-external-route DOES NOT change.
     So R doesn't have to RESEND anything to I1.

3. Suppose in the above case R decides not to send best-external-route
to I1. It will need to send it to I1 when the subsequent withdrawal
happens.

-Priya

>From: "deepak_srivastava" <[email-masked]>
>To: <[email-masked]>
>Subject: Re: Internal Update Process of BGP4
>Date: Fri, 11 May 2001 17:22:02 +0530
>
>I think my first mail was a little bit lengthy. I am putting it again
in
>concise form.
>
>In draft-12 & RFC its written that a bgp speaker sends INTERNAL UPDATEs
>to its IBGP peers at end of phase-1. The neccessary condition pointed
>out in draft is that the route is sent if it "will be" there in Loc-RIB
>of local bgp speaker.
>
>How can a speaker know beforehand (ie before phase 2) that the route
>which it is sending as INTERNAL UPDATES **will be** there in its
>Loc-RIB?
>
>This could imply, that a bgp speaker should send its internal peers the
>best externally learned route FIRST. Then after phase 2 if that route
is
>not best route then withdraw it from all of them.
>
>Why first sending and then withdrawing ? why can't it send to all its
>peers after end of phase 2 only ( then it will be known which routes
are
>there in Loc-RIB)?
>
>The only reason I could think of is, this will do a faster convergence
>and the AS will get stable much earlier. But I am not able to find this
>thing anywhere in RFC or Draft 12.
>
>If that is the only reason then I would suggest to MODIFY the RFC1771
>and draft-12 both to say this explicitly.
>
>DEEPAK SRIVASTAVA,
>COMMUNICATION GROUP,
>INFOSYS TECHNOLOGIES LTD.
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

------_=_NextPart_001_01C0DAFC.B73F52BD
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C0DAFC.B73F52BD--

From: "proto man" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Internal Update Process of BGP4
Date: Fri, 11 May 2001 19:01:13 -0000
Sender: [email-masked]

I am probably not answering the question you had asked. But i think
this may help clarify some intent. You may want to search archives
for better answers regarding this.

1) Sending the best external route helps to avoid churn.

2) Sending the best external route does not necessarily mean you need
to withdraw it subsequently when you learn that the best external route
is not your best route.

   For e.g :
    E3 I1   R   E1
       I2       E2

     Let the local speaker be R.
     I1,I2 are IBGP peers to R
     E1,E2 are EBGP peers to R
     E3 is EBGP peer to I1

     The best external route computed at R is via E1.
     Send best-external-route to I1,I2
     The best route computed at R is via I1.
     Send best-route to E1,E2.

     Suppose E3 withdraws the route from I1.
     I1 withdraws it from R.

     R's best-route changes to E1
     R's best-external-route DOES NOT change.
     So R doesn't have to RESEND anything to I1.

3. Suppose in the above case R decides not to send best-external-route
to I1. It will need to send it to I1 when the subsequent withdrawal
happens.

-Priya

>From: "deepak_srivastava" <[email-masked]>
>To: <[email-masked]>
>Subject: Re: Internal Update Process of BGP4
>Date: Fri, 11 May 2001 17:22:02 +0530
>
>I think my first mail was a little bit lengthy. I am putting it again in
>concise form.
>
>In draft-12 & RFC its written that a bgp speaker sends INTERNAL UPDATEs
>to its IBGP peers at end of phase-1. The neccessary condition pointed
>out in draft is that the route is sent if it "will be" there in Loc-RIB
>of local bgp speaker.
>
>How can a speaker know beforehand (ie before phase 2) that the route
>which it is sending as INTERNAL UPDATES **will be** there in its
>Loc-RIB?
>
>This could imply, that a bgp speaker should send its internal peers the
>best externally learned route FIRST. Then after phase 2 if that route is
>not best route then withdraw it from all of them.
>
>Why first sending and then withdrawing ? why can't it send to all its
>peers after end of phase 2 only ( then it will be known which routes are
>there in Loc-RIB)?
>
>The only reason I could think of is, this will do a faster convergence
>and the AS will get stable much earlier. But I am not able to find this
>thing anywhere in RFC or Draft 12.
>
>If that is the only reason then I would suggest to MODIFY the RFC1771
>and draft-12 both to say this explicitly.
>
>DEEPAK SRIVASTAVA,
>COMMUNICATION GROUP,
>INFOSYS TECHNOLOGIES LTD.
>
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

content-class: urn:content-classes:message
Subject: Re: Internal Update Process of BGP4
Date: Fri, 11 May 2001 17:22:02 +0530
From: "deepak_srivastava" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

I think my first mail was a little bit lengthy. I am putting it again in
concise form.

In draft-12 & RFC its written that a bgp speaker sends INTERNAL UPDATEs
to its IBGP peers at end of phase-1. The neccessary condition pointed
out in draft is that the route is sent if it "will be" there in Loc-RIB
of local bgp speaker.

How can a speaker know beforehand (ie before phase 2) that the route
which it is sending as INTERNAL UPDATES **will be** there in its
Loc-RIB?

This could imply, that a bgp speaker should send its internal peers the
best externally learned route FIRST. Then after phase 2 if that route is
not best route then withdraw it from all of them.

Why first sending and then withdrawing ? why can't it send to all its
peers after end of phase 2 only ( then it will be known which routes are
there in Loc-RIB)?

The only reason I could think of is, this will do a faster convergence
and the AS will get stable much earlier. But I am not able to find this
thing anywhere in RFC or Draft 12.

If that is the only reason then I would suggest to MODIFY the RFC1771
and draft-12 both to say this explicitly.

DEEPAK SRIVASTAVA,
COMMUNICATION GROUP,
INFOSYS TECHNOLOGIES LTD.

From: Anoop Ghanwani <[email-masked]>
To: "'deepak_srivastava'" <[email-masked]>, [email-masked]
Subject: RE: Internal Update Process of BGP4
Date: Wed, 9 May 2001 10:56:37 -0700 
Sender: [email-masked]

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

------_=_NextPart_001_01C0D8B1.64AAA590
Content-Type: text/plain;
	charset="windows-1252"

> You will know that x3 is your best route for putting in Loc-RIB, ONLY
> AFTER
> phase2, but its written in draft and rfc1771 both, that 
> internal updates
> can
> be sent (after/as part of) phase 1 itself.

I think all that this is saying is that a peer should send its updates
based on its set of best (active) routes without waiting forever to 
receive an update from its neighbor...it just gets the process going.
Every active route has already been through the path selection 
criteria.  What do you think is a more approriate algorithm?

-Anoop

------_=_NextPart_001_01C0D8B1.64AAA590
Content-Type: text/html;
	charset="windows-1252"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: Internal Update Process of BGP4</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>&gt; You will know that x3 is your best route for putting in Loc-RIB, ONLY</FONT>
<BR><FONT SIZE=2>&gt; AFTER</FONT>
<BR><FONT SIZE=2>&gt; phase2, but its written in draft and rfc1771 both, that </FONT>
<BR><FONT SIZE=2>&gt; internal updates</FONT>
<BR><FONT SIZE=2>&gt; can</FONT>
<BR><FONT SIZE=2>&gt; be sent (after/as part of) phase 1 itself.</FONT>
</P>

<P><FONT SIZE=2>I think all that this is saying is that a peer should send its updates</FONT>
<BR><FONT SIZE=2>based on its set of best (active) routes without waiting forever to </FONT>
<BR><FONT SIZE=2>receive an update from its neighbor...it just gets the process going.</FONT>
<BR><FONT SIZE=2>Every active route has already been through the path selection </FONT>
<BR><FONT SIZE=2>criteria.&nbsp; What do you think is a more approriate algorithm?</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C0D8B1.64AAA590--

content-class: urn:content-classes:message
Subject: Re:Internal Update Process of BGP4
Date: Wed, 9 May 2001 13:02:00 +0530
From: "deepak_srivastava" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Anoop Ghanwani wrote:
> 
> > -----Original Message-----
> > From: deepak_srivastava [mailto:[email-masked]]
> > Sent: Tuesday, May 08, 2001 7:21 AM
> > To: [email-masked]
> > Subject: Internal Update Process of BGP4.

> > According to decision process of rfc1771, x3 having larger
> > DOP, will be
> > installed in Loc-RIB of B as best phase 2 route.
> 
> According to the draft, B should prefer the route that it
> learned from an E-BGP peer.  Therefore, considering that it has
> problems reaching the next-hop for x2, it would prefer x1.

In the above case, eBGP versus iBGP comparsion comes after the DoP 
comparison. Since x3 is having greater DoP, it will be selected.

> The answer would be (3).  You don't advertise anything other
> than your best route for a particular destination.  If you receive
> a better route from an I-BGP peer and you have previously adverstised
> some other route to your I-BGP peers, you will have to withdraw the
> one that you no longer consider to be the best.

My main point of concern was following:

> > ===================================================================
> >  The point of concern is, if the necessary condition for a route to
> >  be advertised to internal peers is that it should be present in
> >  Loc-RIB, then why rfc and draft both say that internal update can
be
> >  sent (at the end/as part of) phase 1.
> >
> >  It appears that if the above is necessary condition then internal
> >  updates should be sent after phase 2 i.e. when Loc-RIB has been
> >  modified. Whats the point in first sending the update after phase 1
> >  and then withdrawing it if that route is not there in Loc-RIB.
> >
> >
> >  ===================================================================

You will know that x3 is your best route for putting in Loc-RIB, ONLY
AFTER
phase2, but its written in draft and rfc1771 both, that internal updates
can
be sent (after/as part of) phase 1 itself.

> > NOTE: where ever I have given reference for draft, I meant
> >                <draft-ietf-idr-bgp4-12.txt>

DEEPAK SRIVASTAVA,
COMMUNICATION GROUP,
INFOSYS TECHNOLOGIES LTD.

From: Anoop Ghanwani <[email-masked]>
To: "'deepak_srivastava'" <[email-masked]>, [email-masked]
Subject: RE: Internal Update Process of BGP4.
Date: Tue, 8 May 2001 12:03:36 -0700 
Sender: [email-masked]

> -----Original Message-----
> From: deepak_srivastava [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2001 7:21 AM
> To: [email-masked]
> Subject: Internal Update Process of BGP4.
> 
> 
> Hi, 
> 
> I am looking for some clarification on BGP internal update process as
> stated in section 9.2.1 of rfc 1771. To illustrate my point let me
> explain using the example given below.
> 
> According to rfc 1771 an internal update should be sent to internal
> peers as part of phase 1 itself i.e. before start of phase 2. 
> 
>                             (x3)
>                   ----------C-----------
>              IBGP|        AS I         |IBGP
>                  |                     |
>                  |                     |     EBGP
>                  A---------------------B------------M (x2)
>                /AS I      IBGP      AS I \          AS IV
>               /                           \
>              /EBGP                         \EBGP
>             /                               \
>             H                                K (x1)     
>            AS II                            AS III
> 
> 
>         1. A, B and C are IBGP peers.
>         2. H is an EBGP peer of A.
>         3. K and M are EBGP peers of B.
>         
> 
> Consider the following scenario in which a bgp speaker, say 
> B, has three
> updates for same destination x in its Adj-RIBs-IN viz x1, x2 
> and x3 with
> degree of preference d1, d2 and d3 such that d3 >d2 >d1. Lets suppose
> that
>  
>    1. Local system B does not have Next hop reachability for 
> destination
>       x2 in its Loc-RIB. 
>    2. x3 is originated by one of the internal peers, say C.
>    3. x1 and x2 are sent by external peers K and M, respectively.
> 
> According to decision process of rfc1771, x3 having larger 
> DOP, will be
> installed in Loc-RIB of B as best phase 2 route. 

According to the draft, B should prefer the route that it 
learned from an E-BGP peer.  Therefore, considering that it has
problems reaching the next-hop for x2, it would prefer x1.

> 
> Now my questions are : 
> 
> a) Will there ever be a situation when a BGP speaker (B) 
> receive a route
>    (x2) through an EBGP update for which there is no NH reachablity in
>    its Loc_RIB.

This could happen when using partial mesh in ATM or Frame Relay
networks.  The scenario is as follows:  There is a
VC between A and B which are E-BGP peers, and between B and C
which may be OSPF peers.  A, B, and C are on the same subnet,
but because there is no VC between A and C, there is no way for
A to communicate directly with C.  However, B doesn't know this
and advertises a route to A with a BGP Next Hop of C.

>    
>    One way this could happen is if the sending speaker (M) sets some
>    policy for next hop then it may be possible for receiving speaker
>    (B) to not have NH reachability in its Loc-RIB.
>    
>    But then section 5.1.3 of <draft-ietf-idr-bgp4-12.txt> says
> 
>       When advertising a NEXT_HOP attribute to an external peer, a
>       router may use one of its own interface addresses in 
> the NEXT_HOP
>       attribute provided the external peer to which the route is
>       being advertised shares a common subnet with the 
> NEXT_HOP address.
>       This is known as a "first party" NEXT_HOP attribute.  A BGP
>       speaker can advertise to an external peer an interface of any
>       internal peer router in the NEXT_HOP attribute provided the
>       external peer to which the route is being advertised shares a
>       common subnet with the NEXT_HOP address.  This is known as a
>       "third party" NEXT_HOP attribute.
>       
>    What I understand from this is, a bgp speaker (M) can only set
>    some policy to change the NH of an update message to one of
>    its interface address provided that the receiving external
>    peer (B) shares a common subnet with that address.  
>    
>    I would appreciate if someone can enlighten this with a practical
>    scenario when such a thing can happen.
>       
>       
> b) What routes should be there in Adj-RIBs-IN of internal peer A.
> 
> 1. x3 and x2. 
>    x3 from C and x2 from B as it is the best route to send to internal
>    peers according to section 9.2.1 of rfc 1771 having larger value of
>    DOP among externally received route. 
> 
> 2. x3 and x1. (If the answer to (a) is NO ). 
> 
>    But its nowhere written in rfc 1771 or in draft that  an external
>    route for which next hop reachability is not there, should not be
>    sent to internal peers.
> 
> 3. x3 alone. 
>    As it is the route which will be selected after phase 2 to be put
>    in Loc-RIB of B, therefore B should withdraw the route x2 (or
>    x1, whichever it has advertised earlier to A as part of internal
>    update process) as according section 9.2.1 of draft:
>    
>       "When a BGP speaker receives a new route from an 
> external peer, it
>       MUST advertise that route to all other internal peers 
> by means of
>       an UPDATE message if this route will be installed in its Loc-RIB
>       according to the route selection rules in 9.1.2."
> 
>    This means that only those route should be sent to internal peers
>    which *will* be there in Loc-RIB after phase 2.
>    

The answer would be (3).  You don't advertise anything other
than your best route for a particular destination.  If you receive
a better route from an I-BGP peer and you have previously adverstised
some other route to your I-BGP peers, you will have to withdraw the
one that you no longer consider to be the best.

>   
>    ===================================================================
>    The point of concern is, if the necessary condition for a route to
>    be advertised to internal peers is that it should be present in
>    Loc-RIB, then why rfc and draft both say that internal 
> update can be
>    sent (at the end/as part of) phase 1. 
>    
>    It appears that if the above is necessary condition then internal
>    updates should be sent after phase 2 i.e. when Loc-RIB has been
>    modified. Whats the point in first sending the update after phase 1
>    and then withdrawing it if that route is not there in Loc-RIB.
>   
>   
>    ===================================================================
>    
> NOTE: where ever I have given reference for draft, I meant
>                <draft-ietf-idr-bgp4-12.txt>  
> 
> 
> DEEPAK SRIVASTAVA,
> COMMUNICATION GROUP,	
> INFOSYS TECHNOLOGIES LTD.
> 
> 
> 

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: as4bytes - 4byte speaker receiving new* attributes? 
Date: Tue, 08 May 2001 11:06:18 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date: Tue, 8 May 2001 13:40:44 -0400
> From: Jeffrey Haas <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: as4bytes - 4byte speaker receiving new* attributes?
> Message-ID: <[email-masked]>
> References: <[email-masked]> <[email-masked]>
> 
> On Tue, May 08, 2001 at 10:09:54AM -0700, Enke Chen wrote:
> > > In the current as4bytes draft (draft-ietf-idr-as4bytes-02.txt):
> > > :    The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
> > > :    carried in the updates between NEW BGP peers. A NEW BGP speaker that
> > > :    receives an UPDATE message from a NEW BGP speaker, with the
> > > :    NEW_AS_PATH attribute carried in the UPDATE message must ignore the
> > > :    attribute. The same applies to the NEW_AGGREGATOR attribute.
> 
> > There is no need to send a notification in this case as the receiver can deal with
> > the message and function properly. It is consistent with the famous protocol
> > rule: "Be conservative with what you send, and be liberal with what you accept".
> 
> I'm picturing two cases here:
> 1. The receiver gets a route containing both an as_path and a new_aspath.
>    Since both speakers are 4byte speakers, AS_PATH should contain
>    the same things as NEW_AS_PATH.  What if they don't?

Regardless, the NEW_AS_PATH is ignored.

> 2. If we simply ignore it, its still transitive. 

It was meant to be "ignored and dropped". We will clarify this in the next
revision.  Thanks. -- Enke

>    When this finally
>    gets to a 2byte boundary (possibly several AS's over), should
>    this speaker discard the NEW_AS_PATH prior to generating a new one?

> 
> It is my general impression that the NEW_* path attributes aren't
> really meant to exist within a 4byte domain and are only added
> on egress into a 2byte domain.  Perhaps I'm mistaken.
> 
> > -- Enke
> 
> -- 
> Jeff Haas 
> NextHop Technologies

Date: Tue, 8 May 2001 14:10:29 -0400
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: as4bytes - 4byte speaker receiving new* attributes?
Sender: [email-masked]

On Tue, May 08, 2001 at 11:06:18AM -0700, Enke Chen wrote:
> > 2. If we simply ignore it, its still transitive. 
> 
> It was meant to be "ignored and dropped". We will clarify this in the next
> revision.  Thanks. -- Enke

That makes more sense.  
Thanks for the clarification.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 8 May 2001 13:40:44 -0400
From: Jeffrey Haas <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: as4bytes - 4byte speaker receiving new* attributes?
Sender: [email-masked]

On Tue, May 08, 2001 at 10:09:54AM -0700, Enke Chen wrote:
> > In the current as4bytes draft (draft-ietf-idr-as4bytes-02.txt):
> > :    The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
> > :    carried in the updates between NEW BGP peers. A NEW BGP speaker that
> > :    receives an UPDATE message from a NEW BGP speaker, with the
> > :    NEW_AS_PATH attribute carried in the UPDATE message must ignore the
> > :    attribute. The same applies to the NEW_AGGREGATOR attribute.

> There is no need to send a notification in this case as the receiver can deal with
> the message and function properly. It is consistent with the famous protocol
> rule: "Be conservative with what you send, and be liberal with what you accept".

I'm picturing two cases here:
1. The receiver gets a route containing both an as_path and a new_aspath.
   Since both speakers are 4byte speakers, AS_PATH should contain
   the same things as NEW_AS_PATH.  What if they don't?
2. If we simply ignore it, its still transitive.  When this finally
   gets to a 2byte boundary (possibly several AS's over), should
   this speaker discard the NEW_AS_PATH prior to generating a new one?

It is my general impression that the NEW_* path attributes aren't
really meant to exist within a 4byte domain and are only added
on egress into a 2byte domain.  Perhaps I'm mistaken.

> -- Enke

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: as4bytes - 4byte speaker receiving new* attributes? 
Date: Tue, 08 May 2001 10:09:54 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date: Tue, 8 May 2001 10:20:07 -0400
> From: Jeffrey Haas <[email-masked]>
> To: [email-masked]
> Subject: as4bytes - 4byte speaker receiving new* attributes?
> Message-ID: <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> Sender: [email-masked]
> Precedence: bulk
> 
> In the current as4bytes draft (draft-ietf-idr-as4bytes-02.txt):
> 
> :    The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
> :    carried in the updates between NEW BGP peers. A NEW BGP speaker that
> :    receives an UPDATE message from a NEW BGP speaker, with the
> :    NEW_AS_PATH attribute carried in the UPDATE message must ignore the
> :    attribute. The same applies to the NEW_AGGREGATOR attribute.
> 
> If we are a 4byte router peering with another 4byte router
> and have mutually capability advertised a 4byte peering session, we
> should not be getting these attributes.
> 
> Would it not be better to send a NOTIFY in this case?  

"NOTIFICATION" is the last resort and it is disruptive.

There is no need to send a notification in this case as the receiver can deal with
the message and function properly. It is consistent with the famous protocol
rule: "Be conservative with what you send, and be liberal with what you accept".

-- Enke

content-class: urn:content-classes:message
Subject: Internal Update Process of BGP4.
Date: Tue, 8 May 2001 19:50:56 +0530
From: "deepak_srivastava" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi, 

I am looking for some clarification on BGP internal update process as
stated in section 9.2.1 of rfc 1771. To illustrate my point let me
explain using the example given below.

According to rfc 1771 an internal update should be sent to internal
peers as part of phase 1 itself i.e. before start of phase 2. 

                            (x3)
                  ----------C-----------
             IBGP|        AS I         |IBGP
                 |                     |
                 |                     |     EBGP
                 A---------------------B------------M (x2)
               /AS I      IBGP      AS I \          AS IV
              /                           \
             /EBGP                         \EBGP
            /                               \
            H                                K (x1)     
           AS II                            AS III

        1. A, B and C are IBGP peers.
        2. H is an EBGP peer of A.
        3. K and M are EBGP peers of B.

Consider the following scenario in which a bgp speaker, say B, has three
updates for same destination x in its Adj-RIBs-IN viz x1, x2 and x3 with
degree of preference d1, d2 and d3 such that d3 >d2 >d1. Lets suppose
that
 
   1. Local system B does not have Next hop reachability for destination
      x2 in its Loc-RIB. 
   2. x3 is originated by one of the internal peers, say C.
   3. x1 and x2 are sent by external peers K and M, respectively.

According to decision process of rfc1771, x3 having larger DOP, will be
installed in Loc-RIB of B as best phase 2 route. 

Now my questions are : 

a) Will there ever be a situation when a BGP speaker (B) receive a route
   (x2) through an EBGP update for which there is no NH reachablity in
   its Loc_RIB.
   
   One way this could happen is if the sending speaker (M) sets some
   policy for next hop then it may be possible for receiving speaker
   (B) to not have NH reachability in its Loc-RIB.
   
   But then section 5.1.3 of <draft-ietf-idr-bgp4-12.txt> says

      When advertising a NEXT_HOP attribute to an external peer, a
      router may use one of its own interface addresses in the NEXT_HOP
      attribute provided the external peer to which the route is
      being advertised shares a common subnet with the NEXT_HOP address.
      This is known as a "first party" NEXT_HOP attribute.  A BGP
      speaker can advertise to an external peer an interface of any
      internal peer router in the NEXT_HOP attribute provided the
      external peer to which the route is being advertised shares a
      common subnet with the NEXT_HOP address.  This is known as a
      "third party" NEXT_HOP attribute.
      
   What I understand from this is, a bgp speaker (M) can only set
   some policy to change the NH of an update message to one of
   its interface address provided that the receiving external
   peer (B) shares a common subnet with that address.  
   
   I would appreciate if someone can enlighten this with a practical
   scenario when such a thing can happen.

b) What routes should be there in Adj-RIBs-IN of internal peer A.

1. x3 and x2. 
   x3 from C and x2 from B as it is the best route to send to internal
   peers according to section 9.2.1 of rfc 1771 having larger value of
   DOP among externally received route. 

2. x3 and x1. (If the answer to (a) is NO ). 

   But its nowhere written in rfc 1771 or in draft that  an external
   route for which next hop reachability is not there, should not be
   sent to internal peers.

3. x3 alone. 
   As it is the route which will be selected after phase 2 to be put
   in Loc-RIB of B, therefore B should withdraw the route x2 (or
   x1, whichever it has advertised earlier to A as part of internal
   update process) as according section 9.2.1 of draft:
   
      "When a BGP speaker receives a new route from an external peer, it
      MUST advertise that route to all other internal peers by means of
      an UPDATE message if this route will be installed in its Loc-RIB
      according to the route selection rules in 9.1.2."

   This means that only those route should be sent to internal peers
   which *will* be there in Loc-RIB after phase 2.

   ===================================================================
   The point of concern is, if the necessary condition for a route to
   be advertised to internal peers is that it should be present in
   Loc-RIB, then why rfc and draft both say that internal update can be
   sent (at the end/as part of) phase 1. 
   
   It appears that if the above is necessary condition then internal
   updates should be sent after phase 2 i.e. when Loc-RIB has been
   modified. Whats the point in first sending the update after phase 1
   and then withdrawing it if that route is not there in Loc-RIB.

   ===================================================================
   
NOTE: where ever I have given reference for draft, I meant
               <draft-ietf-idr-bgp4-12.txt>  

DEEPAK SRIVASTAVA,
COMMUNICATION GROUP,	
INFOSYS TECHNOLOGIES LTD.

Date: Tue, 8 May 2001 10:20:07 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: as4bytes - 4byte speaker receiving new* attributes?
Sender: [email-masked]

In the current as4bytes draft (draft-ietf-idr-as4bytes-02.txt):

:    The new attributes, NEW_AS_PATH and NEW_AGGREGATOR should not be
:    carried in the updates between NEW BGP peers. A NEW BGP speaker that
:    receives an UPDATE message from a NEW BGP speaker, with the
:    NEW_AS_PATH attribute carried in the UPDATE message must ignore the
:    attribute. The same applies to the NEW_AGGREGATOR attribute.

If we are a 4byte router peering with another 4byte router
and have mutually capability advertised a 4byte peering session, we
should not be getting these attributes.

Would it not be better to send a NOTIFY in this case?  

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 04 May 2001 09:29:23 -0400
To: Philip Smith <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: ASN 4 octets?
Cc: Hank Nussbacher <[email-masked]>, Ben Black <[email-masked]>, [email-masked], "Barry Raveendran Greene" <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Phil and Hank:

I agree that the issues about full internet ASN and network numbers are not
covered by the 4 Byte draft.   The IESG has not approved a charter for IDR 
where
these long term topics are discussed.   I am still awaiting an approved IDR 
charter
from the IESG.   I am copying Abha Ahuja on this email and perhaps she will 
encourage the
IESG to process the IDR charter we suggested.

The 4-byte ASN draft has been implemented by a number of vendors and it is 
part of current practice.

Sue Hares

At 10:34 PM 5/2/2001 +1000, Philip Smith wrote:
>ASN announcement to the Internet is increasing non-linearly. ASN 
>allocation by the registries is increasing non-linearly. This implies that 
>we will run out sooner than we expected two or three years ago. Check 
>recent presentations by Scott Marcus, Geoff and me.
>
>Most organisations are requesting an ASN so that they can multihome. They 
>have legitimate operational reasons to do so. Maybe we need a better way 
>to multihome which doesn't need ASNs - answers please to multi6 and ptomaine...
>
>Also, who would go back and check that all the existing allocations are 
>being used according to RFC1930. The registries? Who pays? (Not being 
>negative, just being realistic.) Besides, going back is only putting a 
>stronger band aid on the problem - doesn't solve it either.
>
>philip
>--
>
>At 11:38 02/05/2001 +0200, Hank Nussbacher wrote:
>>At 00:55 02/05/01 -0700, Ben Black wrote:
>>
>>I only know of Geoff's numbers at:
>>http://www.telstra.net/ops/bgp/bgp-as-count.html
>>
>>I do not see the rapid exhaustion in those numbers.  I have heard the 
>>rumors that there is rapid growth in the multihomde area and therefore 
>>there is an increase in ASN requests.  As a LIR in Israel, I have 
>>allocated multihomed /22 blocks to 30 organizations since Jan 1, 2000 but 
>>at the same time I have revoked 7 of those allocations for not continuing 
>>to meet the qualifications (see rules at:
>>http://www.isoc.org.il/ip-nets-rules.html)
>>
>>Note that http://www.telstra.net/ops/bgp/bgp-oneas.html shows that about 
>>70% of the AS space is only visible via one AS-PATH.  There is no 
>>justification to increase ASNs to 4 octets.  What should be done is that 
>>the RIRs like ARIN and RIPE enforce the rules that they require when one 
>>requests an ASN.  I suggest those who are in favor of increasing ASNs to 
>>4 octets reread RFC1930 - Guidelines for creation, selection, and 
>>registration of an Autonomous System (AS).  What has happened is that 
>>organizations request an ASN, multihome for a short period, sometimes 
>>intentionally just to be able to justify getting a /19, and then remove 
>>one ISP and continue happily along being single-homed, with a /19 for use.
>>
>>Increasing ASN to 4 octets is not curing the problem, just putting a 
>>band-aid over it and hoping to ignore it.
>>
>>-Hank
>>
>>>The current 16 bit ASN space is being rapidly exhausted.  This change
>>>to 4 byte ASNs relieves that problem.
>>>
>>>
>>>Ben
>>>
>>>On Wed, May 02, 2001 at 10:35:17AM +0200, Hank Nussbacher wrote:
>>> > Please excuse me if this is the wrong list to bring this up since after
>>> > reviewing the IDR charter page at:
>>> > http://www.ietf.org/html.charters/idr-charter.html
>>> > I did not know if I should be sending to [email-masked], or [email-masked] or
>>> > [email-masked].
>>> >
>>> > I would specifically like to ask about:
>>> > draft-ietf-idr-as4bytes-02.txt.  Why?  I read over the draft and 
>>> could not
>>> > figure out the rational for why IDR is suggesting to increase ASN 
>>> size from
>>> > 2 to 4 octets.  Before commenting further can someone please clue me in.
>>> >
>>> > Thanks,
>>> > Hank
>>> >
>>> >
>>> >
>>
>
>

From: "proto man" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Local Pref
Date: Wed, 02 May 2001 19:34:07 -0000
Sender: [email-masked]

Are you refering to the RFC or the latest draft?
The draft12 states :
"e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a well-known mandatory attribute that is a
            four octet non-negative integer"

The RFC states :

e) LOCAL_PREF (Type Code 5):

            LOCAL_PREF is a well-known discretionary attribute that is a
            four octet non-negative integer.

Anyways accepting the absence of LOCAL_PREF from IBGP peer doesn't seem
wrong.

Thanks,
-Jaihari

>From: Sreedhar Reddy <[email-masked]>
>To: [email-masked], 'proto man' <[email-masked]>
>Subject: RE: Local Pref
>Date: Wed, 2 May 2001 15:52:54 +0530
>
>Section 4.3 states that it is a well-known discretionary attribute and used
>for updation of internal peers so as section 5.1.5 says.Its not a mandatory
>attribute. Also the RFC says that this field shall be included in IBGP but
>not a MUST.  It is well-known states that you should be able to recognise 
>it
>and discretionary states that it may or may NOT be present. So you need not
>send a notification if it's missing in an UPDATE.
>
> > ----------
> > From: 	proto man[SMTP:[email-masked]]
> > Sent: 	Tuesday, May 01, 2001 2:03 AM
> > To: 	[email-masked]
> > Subject: 	Local Pref
> >
> > Hi,
> >   Section 4.3) of update message description states
> >   Local Pref is a well-known mandatory attribute.
> >
> >   Section 5) states it is a 'required' attribute for IBGP session.
> >
> >   Section 5.1.5) state it is a well-known mandatory attribute.
> >
> >   Question : which is it or does a notification needs to be sent
> >   when LOCAL PREF is missing in an update from an IBGP peer.
> >
> > Appreciate any answer.
> > Thanks,
> > Priya Moniker.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

Date: Wed, 2 May 2001 10:20:51 -0700
From: Ben Black <[email-masked]>
To: Barry Raveendran Greene <[email-masked]>
Cc: Hank Nussbacher <[email-masked]>, [email-masked], [email-masked]
Subject: Re: ASN 4 octets?
Sender: [email-masked]

The I-D in question was given in the original email in this thread.  Both
vendors you mention have already implemented 4 byte ASNs, as have several 
others.

Ben

On Wed, May 02, 2001 at 06:31:01AM -0700, Barry Raveendran Greene wrote:
> 
> We (Cisco) got request from various sides, including the IESG and IAB to
> start work on increasing the ANSs to 4 octets. So work has started in Cisco
> (and also most likely in Juniper). I've seen a ID float around somewhere.
> Not sure if it's been checked in at IETF yet.
> 
> Barry
> 
> > -----Original Message-----
> > From: Hank Nussbacher [mailto:[email-masked]]
> > Sent: Wednesday, May 02, 2001 2:39 AM
> > To: Ben Black
> > Cc: [email-masked]; Barry Raveendran Greene; [email-masked]
> > Subject: Re: ASN 4 octets?
> >
> >
> > At 00:55 02/05/01 -0700, Ben Black wrote:
> >
> > I only know of Geoff's numbers at:
> > http://www.telstra.net/ops/bgp/bgp-as-count.html
> >
> > I do not see the rapid exhaustion in those numbers.  I have heard the
> > rumors that there is rapid growth in the multihomde area and therefore
> > there is an increase in ASN requests.  As a LIR in Israel, I have
> > allocated
> > multihomed /22 blocks to 30 organizations since Jan 1, 2000 but
> > at the same
> > time I have revoked 7 of those allocations for not continuing to meet the
> > qualifications (see rules at:
> > http://www.isoc.org.il/ip-nets-rules.html)
> >
> > Note that http://www.telstra.net/ops/bgp/bgp-oneas.html shows that about
> > 70% of the AS space is only visible via one AS-PATH.  There is no
> > justification to increase ASNs to 4 octets.  What should be done is that
> > the RIRs like ARIN and RIPE enforce the rules that they require when one
> > requests an ASN.  I suggest those who are in favor of increasing
> > ASNs to 4
> > octets reread RFC1930 - Guidelines for creation, selection, and
> > registration of an Autonomous System (AS).  What has happened is that
> > organizations request an ASN, multihome for a short period, sometimes
> > intentionally just to be able to justify getting a /19, and then
> > remove one
> > ISP and continue happily along being single-homed, with a /19 for use.
> >
> > Increasing ASN to 4 octets is not curing the problem, just putting a
> > band-aid over it and hoping to ignore it.
> >
> > -Hank
> >
> > >The current 16 bit ASN space is being rapidly exhausted.  This change
> > >to 4 byte ASNs relieves that problem.
> > >
> > >
> > >Ben
> > >
> > >On Wed, May 02, 2001 at 10:35:17AM +0200, Hank Nussbacher wrote:
> > > > Please excuse me if this is the wrong list to bring this up
> > since after
> > > > reviewing the IDR charter page at:
> > > > http://www.ietf.org/html.charters/idr-charter.html
> > > > I did not know if I should be sending to [email-masked], or
> > [email-masked] or
> > > > [email-masked].
> > > >
> > > > I would specifically like to ask about:
> > > > draft-ietf-idr-as4bytes-02.txt.  Why?  I read over the draft
> > and could not
> > > > figure out the rational for why IDR is suggesting to increase
> > ASN size
> > > from
> > > > 2 to 4 octets.  Before commenting further can someone please
> > clue me in.
> > > >
> > > > Thanks,
> > > > Hank
> > > >
> > > >
> > > >
> >
> >

Date: Wed, 02 May 2001 22:34:32 +1000
To: Hank Nussbacher <[email-masked]>
From: Philip Smith <[email-masked]>
Subject: Re: ASN 4 octets?
Cc: Ben Black <[email-masked]>, [email-masked], "Barry Raveendran Greene" <[email-masked]>, [email-masked]
Sender: [email-masked]

ASN announcement to the Internet is increasing non-linearly. ASN allocation 
by the registries is increasing non-linearly. This implies that we will run 
out sooner than we expected two or three years ago. Check recent 
presentations by Scott Marcus, Geoff and me.

Most organisations are requesting an ASN so that they can multihome. They 
have legitimate operational reasons to do so. Maybe we need a better way to 
multihome which doesn't need ASNs - answers please to multi6 and ptomaine...

Also, who would go back and check that all the existing allocations are 
being used according to RFC1930. The registries? Who pays? (Not being 
negative, just being realistic.) Besides, going back is only putting a 
stronger band aid on the problem - doesn't solve it either.

philip
-- 

At 11:38 02/05/2001 +0200, Hank Nussbacher wrote:
>At 00:55 02/05/01 -0700, Ben Black wrote:
>
>I only know of Geoff's numbers at:
>http://www.telstra.net/ops/bgp/bgp-as-count.html
>
>I do not see the rapid exhaustion in those numbers.  I have heard the 
>rumors that there is rapid growth in the multihomde area and therefore 
>there is an increase in ASN requests.  As a LIR in Israel, I have 
>allocated multihomed /22 blocks to 30 organizations since Jan 1, 2000 but 
>at the same time I have revoked 7 of those allocations for not continuing 
>to meet the qualifications (see rules at:
>http://www.isoc.org.il/ip-nets-rules.html)
>
>Note that http://www.telstra.net/ops/bgp/bgp-oneas.html shows that about 
>70% of the AS space is only visible via one AS-PATH.  There is no 
>justification to increase ASNs to 4 octets.  What should be done is that 
>the RIRs like ARIN and RIPE enforce the rules that they require when one 
>requests an ASN.  I suggest those who are in favor of increasing ASNs to 4 
>octets reread RFC1930 - Guidelines for creation, selection, and 
>registration of an Autonomous System (AS).  What has happened is that 
>organizations request an ASN, multihome for a short period, sometimes 
>intentionally just to be able to justify getting a /19, and then remove 
>one ISP and continue happily along being single-homed, with a /19 for use.
>
>Increasing ASN to 4 octets is not curing the problem, just putting a 
>band-aid over it and hoping to ignore it.
>
>-Hank
>
>>The current 16 bit ASN space is being rapidly exhausted.  This change
>>to 4 byte ASNs relieves that problem.
>>
>>
>>Ben
>>
>>On Wed, May 02, 2001 at 10:35:17AM +0200, Hank Nussbacher wrote:
>> > Please excuse me if this is the wrong list to bring this up since after
>> > reviewing the IDR charter page at:
>> > http://www.ietf.org/html.charters/idr-charter.html
>> > I did not know if I should be sending to [email-masked], or [email-masked] or
>> > [email-masked].
>> >
>> > I would specifically like to ask about:
>> > draft-ietf-idr-as4bytes-02.txt.  Why?  I read over the draft and could not
>> > figure out the rational for why IDR is suggesting to increase ASN size 
>> from
>> > 2 to 4 octets.  Before commenting further can someone please clue me in.
>> >
>> > Thanks,
>> > Hank
>> >
>> >
>> >
>
>

Date: Wed, 02 May 2001 11:38:32 +0200
To: Ben Black <[email-masked]>
From: Hank Nussbacher <[email-masked]>
Subject: Re: ASN 4 octets?
Cc: [email-masked], "Barry Raveendran Greene" <[email-masked]>, [email-masked]
Sender: [email-masked]

At 00:55 02/05/01 -0700, Ben Black wrote:

I only know of Geoff's numbers at:
http://www.telstra.net/ops/bgp/bgp-as-count.html

I do not see the rapid exhaustion in those numbers.  I have heard the 
rumors that there is rapid growth in the multihomde area and therefore 
there is an increase in ASN requests.  As a LIR in Israel, I have allocated 
multihomed /22 blocks to 30 organizations since Jan 1, 2000 but at the same 
time I have revoked 7 of those allocations for not continuing to meet the 
qualifications (see rules at:
http://www.isoc.org.il/ip-nets-rules.html)

Note that http://www.telstra.net/ops/bgp/bgp-oneas.html shows that about 
70% of the AS space is only visible via one AS-PATH.  There is no 
justification to increase ASNs to 4 octets.  What should be done is that 
the RIRs like ARIN and RIPE enforce the rules that they require when one 
requests an ASN.  I suggest those who are in favor of increasing ASNs to 4 
octets reread RFC1930 - Guidelines for creation, selection, and 
registration of an Autonomous System (AS).  What has happened is that 
organizations request an ASN, multihome for a short period, sometimes 
intentionally just to be able to justify getting a /19, and then remove one 
ISP and continue happily along being single-homed, with a /19 for use.

Increasing ASN to 4 octets is not curing the problem, just putting a 
band-aid over it and hoping to ignore it.

-Hank

>The current 16 bit ASN space is being rapidly exhausted.  This change
>to 4 byte ASNs relieves that problem.
>
>
>Ben
>
>On Wed, May 02, 2001 at 10:35:17AM +0200, Hank Nussbacher wrote:
> > Please excuse me if this is the wrong list to bring this up since after
> > reviewing the IDR charter page at:
> > http://www.ietf.org/html.charters/idr-charter.html
> > I did not know if I should be sending to [email-masked], or [email-masked] or
> > [email-masked].
> >
> > I would specifically like to ask about:
> > draft-ietf-idr-as4bytes-02.txt.  Why?  I read over the draft and could not
> > figure out the rational for why IDR is suggesting to increase ASN size 
> from
> > 2 to 4 octets.  Before commenting further can someone please clue me in.
> >
> > Thanks,
> > Hank
> >
> >
> >

Date: Wed, 2 May 2001 00:55:58 -0700
From: Ben Black <[email-masked]>
To: Hank Nussbacher <[email-masked]>
Cc: [email-masked]
Subject: Re: ASN 4 octets?
Sender: [email-masked]

The current 16 bit ASN space is being rapidly exhausted.  This change
to 4 byte ASNs relieves that problem.

Ben

On Wed, May 02, 2001 at 10:35:17AM +0200, Hank Nussbacher wrote:
> Please excuse me if this is the wrong list to bring this up since after 
> reviewing the IDR charter page at:
> http://www.ietf.org/html.charters/idr-charter.html
> I did not know if I should be sending to [email-masked], or [email-masked] or 
> [email-masked].
> 
> I would specifically like to ask about: 
> draft-ietf-idr-as4bytes-02.txt.  Why?  I read over the draft and could not 
> figure out the rational for why IDR is suggesting to increase ASN size from 
> 2 to 4 octets.  Before commenting further can someone please clue me in.
> 
> Thanks,
> Hank
> 
> 
> 

Date: Wed, 02 May 2001 10:35:17 +0200
To: [email-masked]
From: Hank Nussbacher <[email-masked]>
Subject: ASN 4 octets?
Sender: [email-masked]

Please excuse me if this is the wrong list to bring this up since after 
reviewing the IDR charter page at:
http://www.ietf.org/html.charters/idr-charter.html
I did not know if I should be sending to [email-masked], or [email-masked] or 
[email-masked].

I would specifically like to ask about: 
draft-ietf-idr-as4bytes-02.txt.  Why?  I read over the draft and could not 
figure out the rational for why IDR is suggesting to increase ASN size from 
2 to 4 octets.  Before commenting further can someone please clue me in.

Thanks,
Hank

Date: Tue, 1 May 2001 13:00:35 -0400 (EDT)
From: Dante Pacella <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, "'Ben Black'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

as each individual AS value is 2 octets in length, TTL shouldn't be a
problem.

for more on this topic, search on "that pesky AS path corruption
bug..." on nanog from last May.

On Tue, 1 May 2001, Jeffrey Haas wrote:

> On Mon, Apr 30, 2001 at 06:55:28PM -0700, Anoop Ghanwani wrote:
> > I'm trying to find out if it is possible to encode an 
> > AS_PATH attribute with a length greater than 255.  If not,
> > then we can't get such AS_PATHs because a mismatch 
> > between the attribute length and the actual attribute
> > will trigger an error on receive.  However, if we
> > do receive an update with AS_PATH attribute whose
> > length is 255, how do we advertise this to other
> > eBGP peers?  
> 
> You encode the as path using two segments.  One with a length of 255,
> the other with a length of 1.  Or two of 128, or whatever you may like.
> 
> Having a segment of type AS_SEQUENCE of length 255 would imply
> IP TTL issues as previously noted.  However, its possible to have
> AS_SETS that would take the overall length over 255.
> 
> 

Date: Tue, 1 May 2001 12:40:23 -0400 (EDT)
From: Dante Pacella <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

the fourth high-order bit of the attributes flag is the extended length
bit. if this is set to 1, the attribute length is two octets. if set to 0,
the attribute len is one octet.

with today's topology you wouldn't expect to see an AS_PATH of that
structure, but mistakes have been known to occur - as vijay indicated.

On Mon, 30 Apr 2001, Anoop Ghanwani wrote:

> 
> Although not too practical, it is possible to have an 
> AS_PATH whose length is > 255 (especially with AS padding).
> The length of the AS_PATH attribute is limited to 255
> because the length field is only one octet long.
> 
> What is the correct way to handle such a case?  I couldn't
> find anything about this in the BGP-4 draft.  
> 
> Thanks, -Anoop
> 
> 

Date: Mon, 30 Apr 2001 23:37:15 -0700
From: Ben Black <[email-masked]>
To: Vijay Gill <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

On Tue, May 01, 2001 at 01:55:36AM -0400, Vijay Gill wrote:
> On Mon, 30 Apr 2001, Ben Black wrote:
> 
> > Could you provide a plausible example of such a lengthy AS path?
> > I have never seen anything remotely close to that length in practice.
> 
> Neither had we seen an AS path that was malformed such that the actual
> length was shorter than indicated length. Till it took out most of 701.
> 
> Watch out for what should be vs. what actually is.
> 

This would seem to demand proper error handling rather than the need to
support extremely long AS paths.

Ben

Date: Tue, 1 May 2001 02:07:56 -0400
From: Jeffrey Haas <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "'Ben Black'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

On Mon, Apr 30, 2001 at 06:55:28PM -0700, Anoop Ghanwani wrote:
> I'm trying to find out if it is possible to encode an 
> AS_PATH attribute with a length greater than 255.  If not,
> then we can't get such AS_PATHs because a mismatch 
> between the attribute length and the actual attribute
> will trigger an error on receive.  However, if we
> do receive an update with AS_PATH attribute whose
> length is 255, how do we advertise this to other
> eBGP peers?  

You encode the as path using two segments.  One with a length of 255,
the other with a length of 1.  Or two of 128, or whatever you may like.

Having a segment of type AS_SEQUENCE of length 255 would imply
IP TTL issues as previously noted.  However, its possible to have
AS_SETS that would take the overall length over 255.

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 1 May 2001 01:55:36 -0400
From: Vijay Gill <[email-masked]>
To: Ben Black <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

On Mon, 30 Apr 2001, Ben Black wrote:

> Could you provide a plausible example of such a lengthy AS path?
> I have never seen anything remotely close to that length in practice.

Neither had we seen an AS path that was malformed such that the actual
length was shorter than indicated length. Till it took out most of 701.

Watch out for what should be vs. what actually is.

/vijay

> On Mon, Apr 30, 2001 at 04:39:23PM -0700, Anoop Ghanwani wrote:

> > Although not too practical, it is possible to have an
> > AS_PATH whose length is > 255 (especially with AS padding).
> > The length of the AS_PATH attribute is limited to 255
> > because the length field is only one octet long.

Date: Mon, 30 Apr 2001 19:37:33 -0700
From: Ben Black <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

I believe your example of the IP TTL may give you an answer.  Such
a lengthy AS path should not occur in practice and will cause
traffic to not be delivered as the routes will not be propogated.

Ben

On Mon, Apr 30, 2001 at 06:55:28PM -0700, Anoop Ghanwani wrote:
> 
> I don't have a plausible explanation for it other 
> than possibly padding to that length...in practice, 
> if they were all different, the packet, whose TTL is
> limited to 255, would probably never make to the 
> destination anyway. 
> 
> I'm trying to find out if it is possible to encode an 
> AS_PATH attribute with a length greater than 255.  If not,
> then we can't get such AS_PATHs because a mismatch 
> between the attribute length and the actual attribute
> will trigger an error on receive.  However, if we
> do receive an update with AS_PATH attribute whose
> length is 255, how do we advertise this to other
> eBGP peers?  
> 
> > -----Original Message-----
> > From: Ben Black [mailto:[email-masked]]
> > Sent: Monday, April 30, 2001 6:41 PM
> > To: Anoop Ghanwani
> > Cc: [email-masked]'
> > Subject: Re: AS_PATH length > 255
> > 
> > 
> > Could you provide a plausible example of such a lengthy AS path?
> > I have never seen anything remotely close to that length in practice.
> > 
> > 
> > Ben
> > 
> > On Mon, Apr 30, 2001 at 04:39:23PM -0700, Anoop Ghanwani wrote:
> > > 
> > > Although not too practical, it is possible to have an 
> > > AS_PATH whose length is > 255 (especially with AS padding).
> > > The length of the AS_PATH attribute is limited to 255
> > > because the length field is only one octet long.
> > > 
> > > What is the correct way to handle such a case?  I couldn't
> > > find anything about this in the BGP-4 draft.  
> > > 
> > > Thanks, -Anoop
> > 

Date: Mon, 30 Apr 2001 18:41:29 -0700
From: Ben Black <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: AS_PATH length > 255
Sender: [email-masked]

Could you provide a plausible example of such a lengthy AS path?
I have never seen anything remotely close to that length in practice.

Ben

On Mon, Apr 30, 2001 at 04:39:23PM -0700, Anoop Ghanwani wrote:
> 
> Although not too practical, it is possible to have an 
> AS_PATH whose length is > 255 (especially with AS padding).
> The length of the AS_PATH attribute is limited to 255
> because the length field is only one octet long.
> 
> What is the correct way to handle such a case?  I couldn't
> find anything about this in the BGP-4 draft.  
> 
> Thanks, -Anoop

From: Anoop Ghanwani <[email-masked]>
To: "'Ben Black'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: AS_PATH length > 255
Date: Mon, 30 Apr 2001 18:55:28 -0700
Sender: [email-masked]

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

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

I don't have a plausible explanation for it other 
than possibly padding to that length...in practice, 
if they were all different, the packet, whose TTL is
limited to 255, would probably never make to the 
destination anyway. 

I'm trying to find out if it is possible to encode an 
AS_PATH attribute with a length greater than 255.  If not,
then we can't get such AS_PATHs because a mismatch 
between the attribute length and the actual attribute
will trigger an error on receive.  However, if we
do receive an update with AS_PATH attribute whose
length is 255, how do we advertise this to other
eBGP peers?  

> -----Original Message-----
> From: Ben Black [mailto:[email-masked]]
> Sent: Monday, April 30, 2001 6:41 PM
> To: Anoop Ghanwani
> Cc: [email-masked]'
> Subject: Re: AS_PATH length > 255
> 
> 
> Could you provide a plausible example of such a lengthy AS path?
> I have never seen anything remotely close to that length in practice.
> 
> 
> Ben
> 
> On Mon, Apr 30, 2001 at 04:39:23PM -0700, Anoop Ghanwani wrote:
> > 
> > Although not too practical, it is possible to have an 
> > AS_PATH whose length is > 255 (especially with AS padding).
> > The length of the AS_PATH attribute is limited to 255
> > because the length field is only one octet long.
> > 
> > What is the correct way to handle such a case?  I couldn't
> > find anything about this in the BGP-4 draft.  
> > 
> > Thanks, -Anoop
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: AS_PATH length &gt; 255</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=2>I don't have a plausible explanation for it other </FONT>
<BR><FONT SIZE=2>than possibly padding to that length...in practice, </FONT>
<BR><FONT SIZE=2>if they were all different, the packet, whose TTL is</FONT>
<BR><FONT SIZE=2>limited to 255, would probably never make to the </FONT>
<BR><FONT SIZE=2>destination anyway. </FONT>
</P>

<P><FONT SIZE=2>I'm trying to find out if it is possible to encode an </FONT>
<BR><FONT SIZE=2>AS_PATH attribute with a length greater than 255.&nbsp; If not,</FONT>
<BR><FONT SIZE=2>then we can't get such AS_PATHs because a mismatch </FONT>
<BR><FONT SIZE=2>between the attribute length and the actual attribute</FONT>
<BR><FONT SIZE=2>will trigger an error on receive.&nbsp; However, if we</FONT>
<BR><FONT SIZE=2>do receive an update with AS_PATH attribute whose</FONT>
<BR><FONT SIZE=2>length is 255, how do we advertise this to other</FONT>
<BR><FONT SIZE=2>eBGP peers?&nbsp; </FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Ben Black [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, April 30, 2001 6:41 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Anoop Ghanwani</FONT>
<BR><FONT SIZE=2>&gt; Cc: [email-masked]'</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: AS_PATH length &gt; 255</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Could you provide a plausible example of such a lengthy AS path?</FONT>
<BR><FONT SIZE=2>&gt; I have never seen anything remotely close to that length in practice.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Ben</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Mon, Apr 30, 2001 at 04:39:23PM -0700, Anoop Ghanwani wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Although not too practical, it is possible to have an </FONT>
<BR><FONT SIZE=2>&gt; &gt; AS_PATH whose length is &gt; 255 (especially with AS padding).</FONT>
<BR><FONT SIZE=2>&gt; &gt; The length of the AS_PATH attribute is limited to 255</FONT>
<BR><FONT SIZE=2>&gt; &gt; because the length field is only one octet long.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; What is the correct way to handle such a case?&nbsp; I couldn't</FONT>
<BR><FONT SIZE=2>&gt; &gt; find anything about this in the BGP-4 draft.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Thanks, -Anoop</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0D1E1.CC0B18E0--