Subject: Re: [Idr] Question on MinASOrig Timer

From: BGP Guru <[email-masked]>
Date: Mon, 1 Mar 2004 10:27:12 +0000 (GMT)

--- Curtis Villamizar
<[email-masked]> wrote: > 
> In message
> <[email-masked]>,
> Pedro Roque Mar
> ques writes:
> > Curtis Villamizar writes:
> > 
> > > If withdraws propogate faster first the
> unfeasible AS paths are
> > > removed, then the feasible ones start
> propogating.  The result is
> > > some withdraw followed by add but much less AS
> path change in the
> > > presence of cycles.
> > 
> > The point in which we differ is that you equate
> withdraws and updates
> > w/ unfeasible and feasible paths. I don't believe
> one can make that
> > assumption.
> > 
> > For a given AS, if you have as input an withdraw
> that can result in an
> > update being generated or vice-versa, depending on
> the policy.
> > 
> > You can have a link up event result in withdrawns
> being generated, and
> > a link down event result in updates. In other
> words the addition of
> > feasible paths, can result via policy, in
> withdrawls.
> > 
> > > Providing separate timers allows us to defer the
> question of which
> > > is preferable.
> > 
> > Providing separate timers, imho, will just further
> confuse the issue
> > :-). It has already been showen that there is no
> single choice of MRAI
> > timer that is appropriate for all situations. Now
> you propose an
> > additional one. That is two parameters nobody
> knows what the optimal
> > setting should be.
> > 
> > Furthermore, i believe that, due to the meshed
> nature of internet
> > connectivity, using different delays may increase
> the duration of
> > transients.
> > 
> > Lets say that you start w/ a current path through
> as3 and
> > you have a link up event (a) that brings up a
> prefered path.
> > 
> > 	      as 3
> > 	      |
> > 	--a-> as 1 --> as 4
> >           
> > 	--a-> as 2 --> as 4 
> > 
> > If a is a peer route for as 1 but a customer route
> for as 2, then by
> > propagating the withdrawl faster you are
> increasing the transient time
> > and causing increase connectivity to create a
> blackhole for as4.
> > 
> > imho, currently there is only one good known value
> for MRAI for both
> > updates and withdrawls, and that is 0. Let BGP
> speakers propagate
> > updates as fast as they can, taking into account
> that BGP itself
> > already has embedded flow control mechanisms that
> allow a receiver to
> > pace a sender appropriatly.
> > 
> > Unfortunatly, even that setting (0) has its
> drawbacks. One is that
> > values should probably be consistent within an as,
> and there are very
> > different interpretations of MRAI between
> different vendors. The
> > second is that in case of MED oscillations, MRAI
> helps reduce the
> > ammount of churn.  
> > 
> > regards,
> >   Pedro.
> 
> 
> Pedro,
> 
> If you have separate timers for route
> origination/advertisement and
> up/down and the best solution is to set them all the
> same then it is
> possible to set them all the same.
> 
> If you specify that they must be the same and that
> doesn't turn out to
> be the best way to do things you are stuck.
> 
> Its clear that there isn't agreement on the best
> solution, so for the
> time being flexibility is needed.
> 

As everyone may know, Cisco SWs have the same MRAI of
30sec for both Advertised as well as Withdrawn NLRIs
since IOS 12S and ISPs, including our NWs in Asia,
dont seem to be having issues with this. I guess
Juniper's implementation is the same, need to check
(JUNOS guys please pitch in).

IMO, the default configuration on the SWs should be
good enough and capable of handling over 95% of
deployment senarios. ISPs would like to play with
knobs as little as possible on live NWs. 30sec is a
good approx of transient link flaps and time-staggered
Withdrawals do reduce traffic on the wire due to
transient flaps. One would be more worried about
loosing 150-200 peerings due to excessive control
traffic rather than a few data-flows being black-holed
for a few seconds. Hence it would be better to keep
the MRAI/MAOI for withdrawals as well. One comment
here, Cisco's 5sec MAOI seems far to frequent -
desirable would be 15sec atleast.

Also, I think per-peer MRAI/MAOI timers are a bit too
excessive. I shudder at the thought that a
Route-reflector/route-collector with 500 peerings will
have 500 timers popping every 5secs. Is this standard
and common-practise in implementations or can this be
bettered?

___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

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

---

From: BGP Guru <[email-masked]>
Date: Mon, 1 Mar 2004 10:27:12 +0000 (GMT)

--- Curtis Villamizar

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 09:54:34 -0800 (PST)

Yakov Rekhter writes:

> Curtis, [clipped...]
 
>> Pedro,
>> 
>> If you have separate timers for route origination/advertisement and
>> up/down and the best solution is to set them all the same then it
>> is possible to set them all the same.
>> 
>> If you specify that they must be the same and that doesn't turn out
>> to be the best way to do things you are stuck.
>> 
>> Its clear that there isn't agreement on the best solution, so for
>> the time being flexibility is needed.

> One point to keep in mind is that since we are moving the spec to a
> Draft Standard, a *necessary* condition for relaxing the spec to
> support the flexibility you mentioned above would be more than one
> implementation that supports such flexibility.

Just for the record...

Regardless of the ietf process I'm opposed to modifying the spec.

imho, the propagating withdrawls faster than updates is detrimental in
a significant number of realistic scenarios. Also, it doesn't seem to
me that the proponents of such change have considered the potential
drawbacks that are inherent to any change in behaviour.

Implementations are always free to and expected to have functionality
that is beyond what the standard specifies. Curtis can still add the
flexibility he believes necessary... while other implementors can make
their own judgement based on what they consider the best interest of
their users.

This is also not by far the most confusing aspect regarding
interoperability in MRAI.

I belive the WG as decided previously that we agree not to agree on
MRAI. But if we are going to discuss the topic then we should discuss
not what timer values but what do the timer values mean exactly.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 09:54:34 -0800 (PST)

Just for the record...

  Pedro.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 01 Mar 2004 14:19:24 -0500

In message <[email-masked]>, Pedro Roque Mar
> their own judgement based on what they consider the best interest of

Ultimately it is up to the operators whether to use such a feature or
not.  It does no harm to code it in and allow the operator the choice.

I'm also fine with the idea of leaving the spec alone (which I'm sure
will make Yakov and Sue a bit relieved).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 01 Mar 2004 14:19:24 -0500

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 27 Feb 2004 02:22:57 -0500

In message <[email-masked]>, Pedro Roque Mar
ques writes:
> > If withdraws propogate faster first the unfeasible AS paths are
> > removed, then the feasible ones start propogating.  The result is
> > some withdraw followed by add but much less AS path change in the
> > presence of cycles.
> 
> The point in which we differ is that you equate withdraws and updates
> w/ unfeasible and feasible paths. I don't believe one can make that
> assumption.
> 
> For a given AS, if you have as input an withdraw that can result in an
> update being generated or vice-versa, depending on the policy.
> 
> You can have a link up event result in withdrawns being generated, and
> a link down event result in updates. In other words the addition of
> feasible paths, can result via policy, in withdrawls.
> 
> > Providing separate timers allows us to defer the question of which
> > is preferable.
> 
> Providing separate timers, imho, will just further confuse the issue
> :-). It has already been showen that there is no single choice of MRAI
> timer that is appropriate for all situations. Now you propose an
> additional one. That is two parameters nobody knows what the optimal
> setting should be.
> 
> Furthermore, i believe that, due to the meshed nature of internet
> connectivity, using different delays may increase the duration of
> transients.
> 
> Lets say that you start w/ a current path through as3 and
> you have a link up event (a) that brings up a prefered path.
> 
> 	      as 3
> 	      |
> 	--a-> as 1 --> as 4
>           
> 	--a-> as 2 --> as 4 
> 
> If a is a peer route for as 1 but a customer route for as 2, then by
> propagating the withdrawl faster you are increasing the transient time
> and causing increase connectivity to create a blackhole for as4.
> 
> imho, currently there is only one good known value for MRAI for both
> updates and withdrawls, and that is 0. Let BGP speakers propagate
> updates as fast as they can, taking into account that BGP itself
> already has embedded flow control mechanisms that allow a receiver to
> Unfortunatly, even that setting (0) has its drawbacks. One is that
> values should probably be consistent within an as, and there are very
> different interpretations of MRAI between different vendors. The
> second is that in case of MED oscillations, MRAI helps reduce the
> ammount of churn.  
> 
> regards,
>   Pedro.

Pedro,

If you have separate timers for route origination/advertisement and
up/down and the best solution is to set them all the same then it is
possible to set them all the same.

If you specify that they must be the same and that doesn't turn out to
be the best way to do things you are stuck.

Its clear that there isn't agreement on the best solution, so for the
time being flexibility is needed.

Curtis

To: "Bob Arthurs" <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Mon, 29 Mar 2004 07:27:11 -0800

Bob,

> hello
> 
> i am doing some research on bgp and i wonder if someone can confirm a point 
> or two on bgp extended communities (specifically route targets in 
> draft-ietf-idr-bgp-ext-communities-06.txt).
> 
> many thanks for any help in advance.
> 
> are the following points true?
> 
> 1. a route target has an extended Type field which is 2 octets long.

correct.

> 2. when the low order octet in the Type field is 0x02 this means that it is 
> a Route Target.

>From the spec:

  The value of the high-order octet of the Type field for the Route
  Target Community can be 0x00, 0x01 or 0x02. The value of the
  low-order octet of the Type field for this community is 0x02.

> 3. When the high order octect in the Type field is 0x00 or 0x02 then the 
> Global Administrator in the Value field is 2 or 4 octets respectively 
> (depending on high order Type value being 0x00 or 0x02). The Local 
> Administrator in this case is 4 or 2 octets respectively.

correct.

> 4. If the high order octet in the Type field is 0x00 or 0x02 then an AS 
> number (either 2 or 4 bytes) is carried in the Global Administrator.

correct.

> 5. If the high order octet in the Type field is 0x01 then an IP address is 
> carried in the Global Administrator part of the Value field. The Global 
> Administrator and Local Administrator in this case are 4 and 2 octets 
> respectively.

correct.

Yakov.

From: "Bob Arthurs" <[email-masked]>
To: [email-masked]
Subject: [Idr] Question on draft-ietf-idr-bgp-ext-communities-06
Sender: [email-masked]
Date: Fri, 26 Mar 2004 20:41:24 +0000

hello

i am doing some research on bgp and i wonder if someone can confirm a point 
or two on bgp extended communities (specifically route targets in 
draft-ietf-idr-bgp-ext-communities-06.txt).

many thanks for any help in advance.

are the following points true?

1. a route target has an extended Type field which is 2 octets long.

2. when the low order octet in the Type field is 0x02 this means that it is 
a Route Target.

3. When the high order octect in the Type field is 0x00 or 0x02 then the 
Global Administrator in the Value field is 2 or 4 octets respectively 
(depending on high order Type value being 0x00 or 0x02). The Local 
Administrator in this case is 4 or 2 octets respectively.

4. If the high order octet in the Type field is 0x00 or 0x02 then an AS 
number (either 2 or 4 bytes) is carried in the Global Administrator.

5. If the high order octet in the Type field is 0x01 then an IP address is 
carried in the Global Administrator part of the Value field. The Global 
Administrator and Local Administrator in this case are 4 and 2 octets 
respectively.

thanks again,

bob

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess

To: [email-masked]
Cc: [email-masked]
From: Enke Chen <[email-masked]>
Subject: [Idr] Implementation survey for BGP Cease Subcodes
Sender: [email-masked]
Date: Thu, 25 Mar 2004 13:59:43 -0800

Hi, folks:

In order to progress the BGP Cease Subcodes, we need an implementation
report. For folks that have implemented the draft, could you please
fill out the simple survey (attached), and send to me by April 9, 2004?

Thanks.  -- Enke

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

           Implementation Report for BGP Cease Subcodes
               (draft-ietf-idr-cease-subcode-05.txt)

  Organization:

  Person filling out this form:

  Does your implementation recognize all the subcodes defined in
  the document?  (If not, list the subcodes that your implementation
  recognizes.)

  List the subcodes that your implementation may send as part
  of a NOTIFICATION message.

  Does your implementation include the Address Family information
  and the upper bound in the "Data" field of a NOTIFICATION message
  for the subcode "maximum number of prefixes reached"?

  Does your implementation implement a backoff mechanism in re-trying
  a BGP connection, as recommended in the document?

  List other implementations that you have tested for BGP Cease
  Subcodes interoperability.

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

Cc: [email-masked]
From: Benjamin Black <[email-masked]>
Subject: Re: [Idr] IBGP to replace IGP
To: "john smith" <[email-masked]>
Sender: [email-masked]
Date: Tue, 23 Mar 2004 14:11:40 -0800

a) scheduling is a minor concern.

b) certainly carrying a default helps reduce the size of the table, but 
that is orthogonal to the question.  it is not common practice to carry 
much in the igp (meaning bgp is not redistributed into the igp), so 
carrying a default really is reducing the size of your bgp ribs which 
is something you can do regardless of whether you have a second 
protocol for the igp.

c) yes, flapping routes are a problem regardless of protocol, so you 
generally want one that converges very quickly.  a good link-state 
protocol like ospf converges in seconds vs minutes for bgp in a 
reasonably complex network.  again, the igp is only carrying limited 
information (links and loops being a very common scenario) and has very 
detailed knowledge of the network (handling per-link metrics in bgp 
would get very ugly very fast) so it can do things that are 
inconvenient or impossible with bgp.

d) i don't know what benefits you mean.  decoupling the churn of the 
"global view" from the stability of your internal network supports 
using an independent igp.

e) if they can't understand ospf they shouldn't be touching the routers 
anyway.

f) i'm not suggesting the use of a default route.

your questions (and name) seem more like someone lost from nanog 
looking to do some trolling than someone interested in discussing 
protocols, but i could be wrong.

ben

On Mar 22, 2004, at 7:22 PM, john smith wrote:

> Hi Ben,
>
> It would be great if you could share some more information on the 
> "issues" of convergence time, CPU loads, and RP overloads.
>
> From my understanding
> a. it makes more sense to have 1 routing protocol as we dont have 
> multiple daemons scheduled on the CPU. (which ofcourse is not a 
> problem but then so is the point you mentioned below)
>
> b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we 
> inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest 
> BGP node.So does that help reduce the size of your routing table?
>
> c. The cases u mention of changes, I presume you mean route-flaps. 
> Well in that case, we eitherways have issues when IGP flaps, we 
> eitherways wait for IGP to converge for BGP to converge etc? (I am 
> sure "real traffic" operators do that)
>
> d. We have the benefits of not having the "global view" dependent on 1 
> protocol while the internal topology dependent on another
>
> e. all i need to teach the network admins is BGP :)
>
> f. Based on c, how would you say that it makes things more complicated 
> to run iBGP only compared to IGP+0.0.0.0/0 (default originate and 
> originate always) and all those things taken into consideration?
>
> would be great if you could help clarify this.
>
> -Smith
>
>
>
>
>
>
> You could certainly run BGP and statics without another protocol for 
> the IGP, but why would you want to? Convergence times, CPU load on 
> RPs, etc., during changes would be rather unsatisfactory. If you want 
> to run one dynamic protocol at all costs, then what you describe below 
> will work, and has worked for some, but people with real traffic don't 
> waste their time with it.
>
>
> Ben
>
> On Mar 15, 2004, at 8:24 PM, John Smith wrote:
>
>
> Hi,
>
> I am very clear with the concept that IGPs cannot be used to carry the 
> entire BGP feed as
> they cant be scaled to carry so many prefixes (even assuming we add 
> enough TLVs to make
> them carry the BGP attributes).
>
> What is not very clear to me is, why cant we use IBGP inside an AS to 
> completely do away
> with IGPs. IGPs compute the best path to reach a particular neighbor 
> based on the link
> metric. This can be achieved in BGP also, if we include a TLV to carry 
> the link cost.
> Moreover, it is *mandatory* to run BGP on all the routers if we are 
> transiting traffic,
> because if a router isnt speaking BGP then it cant forward BGP traffic.
>
> Cant we do away with IGPs (say in some small networks) and run only 
> IBGP there?
>
> Any help/clues/pointers in this regard will be really appreciated.
>
> Regards,
> Smith
>
> _________________________________________________________________
> Tired of spam? Get advanced junk mail protection with MSN 8. 
> http://join.msn.com/?page=features/junkmail
>
>

Cc: [email-masked], [email-masked]
From: Benjamin Black <[email-masked]>
Subject: Re: [Idr] IBGP to replace IGP
To: "john smith" <[email-masked]>
Sender: [email-masked]
Date: Tue, 23 Mar 2004 15:01:43 -0800

from the sound of things you don't need bgp at all, except to announce 
routes to your upstreams.  rejecting all routes from a peer tends to 
limit the size of adj-rib-in as well as reduce the cpu load of route 
flaps.  handle the rest with an igp and a default and you are done (and 
your network admins need know almost nothing about bgp).

ben

On Mar 23, 2004, at 2:43 PM, john smith wrote:

> Check my reply to Ben, it covers a lot of commong ground
>
> I think you missed out the point that I was planning to put 0.0.0.0/0 
> in the intermediate nodes to cover the internet.
>
> It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that 
> being considered for intermediate nodes.
>
> Route flaps are a result of "actualy flaps somewhere" and if you were 
> to follow the 0.0.0.0/0 principal neither would your intermediate 
> nodes give a problem.
>
> The loops would abound in case of any IGP too when u inject 0.0.0.0/0 
> into the IGP, so maybe I didnt quite get that point
>
>> From: "Martin, Christian" <[email-masked]>
>> To: 'john smith' <[email-masked]>, "[email-masked]'" 
>> <[email-masked]>
>> Subject: RE: [Idr] IBGP to replace IGP
>> Date: Tue, 23 Mar 2004 17:35:58 -0500
>>
>> Smith,
>>
>> Comments inline, as I have been following this thread.
>>
>>
>> >It would be great if you could share some more information on
>> >the "issues"
>> >of convergence time, CPU loads, and RP overloads.
>>
>> Convergence is typically nonlienearly proportionate to CPU load, and
>> vice-versa, and they often feed off each other in a negative way.  
>> Network
>> meltdowns are typically the result of routing loads disrupting 
>> topology
>> maintenance mechanisms, thereby causing adjacency loss, which causes 
>> more
>> routing load, which inhibits adjacency recreation, etc.  I've seen 
>> networks
>> stay in persistent "ditches" because the
>> convergence-adjacency-divergence-adjaceny-...loop stayed closed due to
>> loading.  Not fun to have to rebuild all of your routers or reattach 
>> them to
>> the network one by one...
>>
>> >From my understanding
>> >a. it makes more sense to have 1 routing protocol as we dont
>> >have multiple
>> >daemons scheduled on the CPU. (which ofcourse is not a problem
>> >but then so
>> >is the point you mentioned below)
>>
>> In either case, BGP will consume the vast majority of CPU cycles.  
>> IGPs that
>> are properly tuned in stable environments hardly tickle the CPU, let 
>> alone
>> heat it up.  Take LSA/P refresh out of the picture, and all the IGP 
>> does is
>> send hellos and occasionally flood an LSA/P and compute an SPT once 
>> in a
>> rare while.  In the Internet, BGP is constantly processing updates and
>> withdrawals, all day, every day.  Sometimes, we see 100s of updates 
>> per
>> minute, sometimes just a few, but they are always there.
>>
>> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like 
>> we
>> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the
>> >nearest BGP
>> >node.So does that help reduce the size of your routing table?
>>
>> Large SPs must run a full BGP load, at a minimum, to give routes to 
>> their
>> customers.  Unless you are talking about enterprise routing, we 
>> should avoid
>> discussions of default routes...
>>
>> >c. The cases u mention of changes, I presume you mean
>> >route-flaps. Well in
>> >that case, we eitherways have issues when IGP flaps, we
>> >eitherways wait for
>> >IGP to converge for BGP to converge etc? (I am sure "real
>> >traffic" operators
>> >do that)
>>
>> Modern IGPs, properly tuned, converge way faster than BGP.  BGP 
>> convergence
>> is designed to be slow, so as not to place too much load on the global
>> routing system.  Since BGP carries so many routes, and since the 
>> topological
>> density of the Internet Autonomous System graph increases every day, 
>> BGP can
>> often take minutes to converge.  IGPs take seconds, partly because 
>> they are
>> usually lightweight.
>>
>> >d. We have the benefits of not having the "global view" dependent on 
>> 1
>> >protocol while the internal topology dependent on another
>>
>> This is actually a sound design.  Think of the IGP as a topology 
>> discovery
>> mechanism.  All BGP routes have a next-hop.  The goal of BGP is to 
>> take
>> traffic to and from the "edges" of the network.  Sometimes, the edge 
>> is
>> within your network, like a server farm.  IGPs are very good at 
>> discovering
>> a topology and identifying the shortest path to each edge.  BGP is not
>> designed for this, and to make it do so requires considerable 
>> planning and
>> lots of policy.
>>
>> >e. all i need to teach the network admins is BGP :)
>>
>> It is much easier to learn simple IS-IS and OSPF than BGP.  Link 
>> State IGPs,
>> when employed for topology discovery, are exceedingly simple 
>> (particularly
>> IS-IS in a single area).  BGP, on the otherhand, is a much bigger 
>> protocol
>> that requires a lot of policy engineering in order for it to be 
>> effective.
>>
>> >f. Based on c, how would you say that it makes things more
>> >complicated to
>> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and
>> >originate
>> >always) and all those things taken into consideration?
>>
>> Are you talking about running in an enterprise?  Default routes will 
>> not
>> work in any large environment for next-hop discovery of your iBGP 
>> peer IP's.
>> Loops would abound...
>>
>>
>> One of the problems with your proposal, and the primary reason this 
>> is not
>> done, is that iBGP does not provide for transitive route 
>> dissemination in a
>> network.  All 'other' IGPs do this.  This means your network topology 
>> must
>> be highly symmetrical and/or fully meshed at layer 3 (at least in
>> subsections) to allow for end-to-end route propagation.  Unless you 
>> can
>> employ lots of confeds (ie, each router in a confed subAS), lots of
>> route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if 
>> you
>> consider multiaccess networks fully-meshed), then this approach is not
>> possible.
>>
>> BGP also has race-condition mitigation rules that prevent a BGP route 
>> from
>> being learned from a next-hop that is known via BGP, so injecting 
>> routes
>> into BGP and hoping to bootstrap the next-hops would be problematic.  
>> This
>> restriction is subtle and perhaps vendor specific, but usually, the 
>> next-hop
>> is recursed through an IGP or connected interface.  If this were 
>> possible,
>> in any event, it would be slow-converging, as iBGP updates are 
>> typically
>> spaced at 5 second intervals (depending on the event type).  Also, 
>> you will
>> have to peer with every interface on the device, thus forcing traffic 
>> to
>> take certain paths that may not be the best path available, as most 
>> BGP
>> attributes are non-accumulating (ie, u have to statically increase, 
>> say,
>> local-pref via policy as routes propagate along a set of routers in 
>> your
>> AS).
>>
>> The reality is that even if such an approach _were_ possible, the 
>> drawbacks
>> are much more severe than simply turning on an IGP and having it 
>> discover
>> your topology.  Then, you may do what you with with iBGP.
>>
>> The best philosophy, IMO, is to place loopbacks and links in your 
>> IGP, and
>> carry externals (either self-originated or from another AS) in your 
>> iBGP.
>> Route-reflectors are useful if regionalized, as they make best path
>> decisions before reflecting (so u want to be careful who peers with 
>> what to
>> ensure path selection optimality).  Confeds afford more control, TE, 
>> etc.,
>> but at what some claim to be a higher admin cost.  Use them based on 
>> what
>> you are trying to do.
>>
>> HTH,
>> Chris
>>
>> >would be great if you could help clarify this.
>> >
>> >-Smith
>> >
>>
>>
>>
>>
>>
>>
>> >
>> >
>> >
>> >
>> >You could certainly run BGP and statics without another
>> >protocol for the
>> >IGP, but why would you want to? Convergence times, CPU load on
>> >RPs, etc.,
>> >during changes would be rather unsatisfactory. If you want to run one
>> >dynamic protocol at all costs, then what you describe below
>> >will work, and
>> >has worked for some, but people with real traffic don't waste
>> >their time
>> >with it.
>> >
>> >
>> >Ben
>> >
>> >On Mar 15, 2004, at 8:24 PM, John Smith wrote:
>> >
>> >
>> >Hi,
>> >
>> >I am very clear with the concept that IGPs cannot be used to carry 
>> the
>> >entire BGP feed as
>> >they cant be scaled to carry so many prefixes (even assuming
>> >we add enough
>> >TLVs to make
>> >them carry the BGP attributes).
>> >
>> >What is not very clear to me is, why cant we use IBGP inside an AS to
>> >completely do away
>> >with IGPs. IGPs compute the best path to reach a particular
>> >neighbor based
>> >on the link
>> >metric. This can be achieved in BGP also, if we include a TLV
>> >to carry the
>> >link cost.
>> >Moreover, it is *mandatory* to run BGP on all the routers if we are
>> >transiting traffic,
>> >because if a router isnt speaking BGP then it cant forward BGP 
>> traffic.
>> >
>> >Cant we do away with IGPs (say in some small networks) and run
>> >only IBGP
>> >there?
>> >
>> >Any help/clues/pointers in this regard will be really appreciated.
>> >
>> >Regards,
>> >Smith
>> >
>> >_________________________________________________________________
>> >Tired of spam? Get advanced junk mail protection with MSN 8.
>> >http://join.msn.com/?page=features/junkmail
>> >
>> >
> _________________________________________________________________
> MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
> http://join.msn.com/?page=features/virus
>
>

From: "john smith" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 23 Mar 2004 23:10:54 +0000

I am not saying that you do not need BGP "at all".

The default route to a node "with complete information"  only covers the 
case where you have intermediate nodes which cannot handle the complete 
routing table due to certain limitations highlighted by you.

The reason we use BGP today is the very reason we still need to use BGP.

Some one"has to be the *upstream*". There has to be a point in the network 
where you decide if A or B is the best way to send traffic outside your AS.

All I am asking is why do we need IGP when the same things that are done by 
IGP can be done within BGP.

If you plan to extend an IGP like OSPF (LinkState) to do the same things 
that BGP does today (provides a point in the network which has complete and 
accurate information), and you believe the performance will be better, I 
would be really curious to see the results and would be thankful if you 
could share the same.

>From: Benjamin Black <[email-masked]>
>To: "john smith" <[email-masked]>
>CC: [email-masked], [email-masked]
>Subject: Re: [Idr] IBGP to replace IGP
>Date: Tue, 23 Mar 2004 15:01:43 -0800
>
>from the sound of things you don't need bgp at all, except to announce 
>routes to your upstreams.  rejecting all routes from a peer tends to limit 
>the size of adj-rib-in as well as reduce the cpu load of route flaps.  
>handle the rest with an igp and a default and you are done (and your 
>network admins need know almost nothing about bgp).
>
>
>ben
>
>On Mar 23, 2004, at 2:43 PM, john smith wrote:
>
>>Check my reply to Ben, it covers a lot of commong ground
>>
>>I think you missed out the point that I was planning to put 0.0.0.0/0 in 
>>the intermediate nodes to cover the internet.
>>
>>It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being 
>>considered for intermediate nodes.
>>
>>Route flaps are a result of "actualy flaps somewhere" and if you were to 
>>follow the 0.0.0.0/0 principal neither would your intermediate nodes give 
>>a problem.
>>
>>The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into 
>>the IGP, so maybe I didnt quite get that point
>>
>>>From: "Martin, Christian" <[email-masked]>
>>>To: 'john smith' <[email-masked]>, "[email-masked]'" 
>>><[email-masked]>
>>>Subject: RE: [Idr] IBGP to replace IGP
>>>Date: Tue, 23 Mar 2004 17:35:58 -0500
>>>
>>>Smith,
>>>
>>>Comments inline, as I have been following this thread.
>>>
>>>
>>> >It would be great if you could share some more information on
>>> >the "issues"
>>> >of convergence time, CPU loads, and RP overloads.
>>>
>>>Convergence is typically nonlienearly proportionate to CPU load, and
>>>vice-versa, and they often feed off each other in a negative way.  
>>>Network
>>>meltdowns are typically the result of routing loads disrupting topology
>>>maintenance mechanisms, thereby causing adjacency loss, which causes more
>>>routing load, which inhibits adjacency recreation, etc.  I've seen 
>>>networks
>>>stay in persistent "ditches" because the
>>>convergence-adjacency-divergence-adjaceny-...loop stayed closed due to
>>>loading.  Not fun to have to rebuild all of your routers or reattach them 
>>>to
>>>the network one by one...
>>>
>>> >From my understanding
>>> >a. it makes more sense to have 1 routing protocol as we dont
>>> >have multiple
>>> >daemons scheduled on the CPU. (which ofcourse is not a problem
>>> >but then so
>>> >is the point you mentioned below)
>>>
>>>In either case, BGP will consume the vast majority of CPU cycles.  IGPs 
>>>that
>>>are properly tuned in stable environments hardly tickle the CPU, let 
>>>alone
>>>heat it up.  Take LSA/P refresh out of the picture, and all the IGP does 
>>>is
>>>send hellos and occasionally flood an LSA/P and compute an SPT once in a
>>>rare while.  In the Internet, BGP is constantly processing updates and
>>>withdrawals, all day, every day.  Sometimes, we see 100s of updates per
>>>minute, sometimes just a few, but they are always there.
>>>
>>> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we
>>> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the
>>> >nearest BGP
>>> >node.So does that help reduce the size of your routing table?
>>>
>>>Large SPs must run a full BGP load, at a minimum, to give routes to their
>>>customers.  Unless you are talking about enterprise routing, we should 
>>>avoid
>>>discussions of default routes...
>>>
>>> >c. The cases u mention of changes, I presume you mean
>>> >route-flaps. Well in
>>> >that case, we eitherways have issues when IGP flaps, we
>>> >eitherways wait for
>>> >IGP to converge for BGP to converge etc? (I am sure "real
>>> >traffic" operators
>>> >do that)
>>>
>>>Modern IGPs, properly tuned, converge way faster than BGP.  BGP 
>>>convergence
>>>is designed to be slow, so as not to place too much load on the global
>>>routing system.  Since BGP carries so many routes, and since the 
>>>topological
>>>density of the Internet Autonomous System graph increases every day, BGP 
>>>can
>>>often take minutes to converge.  IGPs take seconds, partly because they 
>>>are
>>>usually lightweight.
>>>
>>> >d. We have the benefits of not having the "global view" dependent on 1
>>> >protocol while the internal topology dependent on another
>>>
>>>This is actually a sound design.  Think of the IGP as a topology 
>>>discovery
>>>mechanism.  All BGP routes have a next-hop.  The goal of BGP is to take
>>>traffic to and from the "edges" of the network.  Sometimes, the edge is
>>>within your network, like a server farm.  IGPs are very good at 
>>>discovering
>>>a topology and identifying the shortest path to each edge.  BGP is not
>>>designed for this, and to make it do so requires considerable planning 
>>>and
>>>lots of policy.
>>>
>>> >e. all i need to teach the network admins is BGP :)
>>>
>>>It is much easier to learn simple IS-IS and OSPF than BGP.  Link State 
>>>IGPs,
>>>when employed for topology discovery, are exceedingly simple 
>>>(particularly
>>>IS-IS in a single area).  BGP, on the otherhand, is a much bigger 
>>>protocol
>>>that requires a lot of policy engineering in order for it to be 
>>>effective.
>>>
>>> >f. Based on c, how would you say that it makes things more
>>> >complicated to
>>> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and
>>> >originate
>>> >always) and all those things taken into consideration?
>>>
>>>Are you talking about running in an enterprise?  Default routes will not
>>>work in any large environment for next-hop discovery of your iBGP peer 
>>>IP's.
>>>Loops would abound...
>>>
>>>
>>>One of the problems with your proposal, and the primary reason this is 
>>>not
>>>done, is that iBGP does not provide for transitive route dissemination in 
>>>a
>>>network.  All 'other' IGPs do this.  This means your network topology 
>>>must
>>>be highly symmetrical and/or fully meshed at layer 3 (at least in
>>>subsections) to allow for end-to-end route propagation.  Unless you can
>>>employ lots of confeds (ie, each router in a confed subAS), lots of
>>>route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you
>>>consider multiaccess networks fully-meshed), then this approach is not
>>>possible.
>>>
>>>BGP also has race-condition mitigation rules that prevent a BGP route 
>>>from
>>>being learned from a next-hop that is known via BGP, so injecting routes
>>>into BGP and hoping to bootstrap the next-hops would be problematic.  
>>>This
>>>restriction is subtle and perhaps vendor specific, but usually, the 
>>>next-hop
>>>is recursed through an IGP or connected interface.  If this were 
>>>possible,
>>>in any event, it would be slow-converging, as iBGP updates are typically
>>>spaced at 5 second intervals (depending on the event type).  Also, you 
>>>will
>>>have to peer with every interface on the device, thus forcing traffic to
>>>take certain paths that may not be the best path available, as most BGP
>>>attributes are non-accumulating (ie, u have to statically increase, say,
>>>local-pref via policy as routes propagate along a set of routers in your
>>>AS).
>>>
>>>The reality is that even if such an approach _were_ possible, the 
>>>drawbacks
>>>are much more severe than simply turning on an IGP and having it discover
>>>your topology.  Then, you may do what you with with iBGP.
>>>
>>>The best philosophy, IMO, is to place loopbacks and links in your IGP, 
>>>and
>>>carry externals (either self-originated or from another AS) in your iBGP.
>>>Route-reflectors are useful if regionalized, as they make best path
>>>decisions before reflecting (so u want to be careful who peers with what 
>>>to
>>>ensure path selection optimality).  Confeds afford more control, TE, 
>>>etc.,
>>>but at what some claim to be a higher admin cost.  Use them based on what
>>>you are trying to do.
>>>
>>>HTH,
>>>Chris
>>>
>>> >would be great if you could help clarify this.
>>> >
>>> >-Smith
>>> >
>>>
>>>
>>>
>>>
>>>
>>>
>>> >
>>> >
>>> >
>>> >
>>> >You could certainly run BGP and statics without another
>>> >protocol for the
>>> >IGP, but why would you want to? Convergence times, CPU load on
>>> >RPs, etc.,
>>> >during changes would be rather unsatisfactory. If you want to run one
>>> >dynamic protocol at all costs, then what you describe below
>>> >will work, and
>>> >has worked for some, but people with real traffic don't waste
>>> >their time
>>> >with it.
>>> >
>>> >
>>> >Ben
>>> >
>>> >On Mar 15, 2004, at 8:24 PM, John Smith wrote:
>>> >
>>> >
>>> >Hi,
>>> >
>>> >I am very clear with the concept that IGPs cannot be used to carry the
>>> >entire BGP feed as
>>> >they cant be scaled to carry so many prefixes (even assuming
>>> >we add enough
>>> >TLVs to make
>>> >them carry the BGP attributes).
>>> >
>>> >What is not very clear to me is, why cant we use IBGP inside an AS to
>>> >completely do away
>>> >with IGPs. IGPs compute the best path to reach a particular
>>> >neighbor based
>>> >on the link
>>> >metric. This can be achieved in BGP also, if we include a TLV
>>> >to carry the
>>> >link cost.
>>> >Moreover, it is *mandatory* to run BGP on all the routers if we are
>>> >transiting traffic,
>>> >because if a router isnt speaking BGP then it cant forward BGP traffic.
>>> >
>>> >Cant we do away with IGPs (say in some small networks) and run
>>> >only IBGP
>>> >there?
>>> >
>>> >Any help/clues/pointers in this regard will be really appreciated.
>>> >
>>> >Regards,
>>> >Smith
>>> >
>>> >_________________________________________________________________
>>> >Tired of spam? Get advanced junk mail protection with MSN 8.
>>> >http://join.msn.com/?page=features/junkmail
>>> >
>>> >
>>_________________________________________________________________
>>MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
>>http://join.msn.com/?page=features/virus
>>
>>

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

From: "Martin, Christian" <[email-masked]>
To: "'john smith'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 23 Mar 2004 18:00:54 -0500

John,

We are drifting off topic for this list here.  Perhaps you should take this
up on a list that covers fundamental routing concepts.  Contact me privately
if you wish to engage further.

Thanks,
chris

>Check my reply to Ben, it covers a lot of commong ground
>
>I think you missed out the point that I was planning to put 
>0.0.0.0/0 in the 
>intermediate nodes to cover the internet.

From: "john smith" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 23 Mar 2004 22:43:10 +0000

Check my reply to Ben, it covers a lot of commong ground

I think you missed out the point that I was planning to put 0.0.0.0/0 in the 
intermediate nodes to cover the internet.

It is nothing buy my IGP replaced with BGP. 0.0.0.0/0 and all that being 
considered for intermediate nodes.

Route flaps are a result of "actualy flaps somewhere" and if you were to 
follow the 0.0.0.0/0 principal neither would your intermediate nodes give a 
problem.

The loops would abound in case of any IGP too when u inject 0.0.0.0/0 into 
the IGP, so maybe I didnt quite get that point

>From: "Martin, Christian" <[email-masked]>
>To: 'john smith' <[email-masked]>, "[email-masked]'" 
><[email-masked]>
>Subject: RE: [Idr] IBGP to replace IGP
>Date: Tue, 23 Mar 2004 17:35:58 -0500
>
>Smith,
>
>Comments inline, as I have been following this thread.
>
>
> >It would be great if you could share some more information on
> >the "issues"
> >of convergence time, CPU loads, and RP overloads.
>
>Convergence is typically nonlienearly proportionate to CPU load, and
>vice-versa, and they often feed off each other in a negative way.  Network
>meltdowns are typically the result of routing loads disrupting topology
>maintenance mechanisms, thereby causing adjacency loss, which causes more
>routing load, which inhibits adjacency recreation, etc.  I've seen networks
>stay in persistent "ditches" because the
>convergence-adjacency-divergence-adjaceny-...loop stayed closed due to
>loading.  Not fun to have to rebuild all of your routers or reattach them 
>to
>the network one by one...
>
> >From my understanding
> >a. it makes more sense to have 1 routing protocol as we dont
> >have multiple
> >daemons scheduled on the CPU. (which ofcourse is not a problem
> >but then so
> >is the point you mentioned below)
>
>In either case, BGP will consume the vast majority of CPU cycles.  IGPs 
>that
>are properly tuned in stable environments hardly tickle the CPU, let alone
>heat it up.  Take LSA/P refresh out of the picture, and all the IGP does is
>send hellos and occasionally flood an LSA/P and compute an SPT once in a
>rare while.  In the Internet, BGP is constantly processing updates and
>withdrawals, all day, every day.  Sometimes, we see 100s of updates per
>minute, sometimes just a few, but they are always there.
>
> >b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we
> >inject 0.0.0.0/0 into IGP to make unknown prefixes go to the
> >nearest BGP
> >node.So does that help reduce the size of your routing table?
>
>Large SPs must run a full BGP load, at a minimum, to give routes to their
>customers.  Unless you are talking about enterprise routing, we should 
>avoid
>discussions of default routes...
>
> >c. The cases u mention of changes, I presume you mean
> >route-flaps. Well in
> >that case, we eitherways have issues when IGP flaps, we
> >eitherways wait for
> >IGP to converge for BGP to converge etc? (I am sure "real
> >traffic" operators
> >do that)
>
>Modern IGPs, properly tuned, converge way faster than BGP.  BGP convergence
>is designed to be slow, so as not to place too much load on the global
>routing system.  Since BGP carries so many routes, and since the 
>topological
>density of the Internet Autonomous System graph increases every day, BGP 
>can
>often take minutes to converge.  IGPs take seconds, partly because they are
>usually lightweight.
>
> >d. We have the benefits of not having the "global view" dependent on 1
> >protocol while the internal topology dependent on another
>
>This is actually a sound design.  Think of the IGP as a topology discovery
>mechanism.  All BGP routes have a next-hop.  The goal of BGP is to take
>traffic to and from the "edges" of the network.  Sometimes, the edge is
>within your network, like a server farm.  IGPs are very good at discovering
>a topology and identifying the shortest path to each edge.  BGP is not
>designed for this, and to make it do so requires considerable planning and
>lots of policy.
>
> >e. all i need to teach the network admins is BGP :)
>
>It is much easier to learn simple IS-IS and OSPF than BGP.  Link State 
>IGPs,
>when employed for topology discovery, are exceedingly simple (particularly
>IS-IS in a single area).  BGP, on the otherhand, is a much bigger protocol
>that requires a lot of policy engineering in order for it to be effective.
>
> >f. Based on c, how would you say that it makes things more
> >complicated to
> >run iBGP only compared to IGP+0.0.0.0/0 (default originate and
> >originate
> >always) and all those things taken into consideration?
>
>Are you talking about running in an enterprise?  Default routes will not
>work in any large environment for next-hop discovery of your iBGP peer 
>IP's.
>Loops would abound...
>
>
>One of the problems with your proposal, and the primary reason this is not
>done, is that iBGP does not provide for transitive route dissemination in a
>network.  All 'other' IGPs do this.  This means your network topology must
>be highly symmetrical and/or fully meshed at layer 3 (at least in
>subsections) to allow for end-to-end route propagation.  Unless you can
>employ lots of confeds (ie, each router in a confed subAS), lots of
>route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you
>consider multiaccess networks fully-meshed), then this approach is not
>possible.
>
>BGP also has race-condition mitigation rules that prevent a BGP route from
>being learned from a next-hop that is known via BGP, so injecting routes
>into BGP and hoping to bootstrap the next-hops would be problematic.  This
>restriction is subtle and perhaps vendor specific, but usually, the 
>next-hop
>is recursed through an IGP or connected interface.  If this were possible,
>in any event, it would be slow-converging, as iBGP updates are typically
>spaced at 5 second intervals (depending on the event type).  Also, you will
>have to peer with every interface on the device, thus forcing traffic to
>take certain paths that may not be the best path available, as most BGP
>attributes are non-accumulating (ie, u have to statically increase, say,
>local-pref via policy as routes propagate along a set of routers in your
>AS).
>
>The reality is that even if such an approach _were_ possible, the drawbacks
>are much more severe than simply turning on an IGP and having it discover
>your topology.  Then, you may do what you with with iBGP.
>
>The best philosophy, IMO, is to place loopbacks and links in your IGP, and
>carry externals (either self-originated or from another AS) in your iBGP.
>Route-reflectors are useful if regionalized, as they make best path
>decisions before reflecting (so u want to be careful who peers with what to
>ensure path selection optimality).  Confeds afford more control, TE, etc.,
>but at what some claim to be a higher admin cost.  Use them based on what
>you are trying to do.
>
>HTH,
>Chris
>
> >would be great if you could help clarify this.
> >
> >-Smith
> >
>
>
>
>
>
>
> >
> >
> >
> >
> >You could certainly run BGP and statics without another
> >protocol for the
> >IGP, but why would you want to? Convergence times, CPU load on
> >RPs, etc.,
> >during changes would be rather unsatisfactory. If you want to run one
> >dynamic protocol at all costs, then what you describe below
> >will work, and
> >has worked for some, but people with real traffic don't waste
> >their time
> >with it.
> >
> >
> >Ben
> >
> >On Mar 15, 2004, at 8:24 PM, John Smith wrote:
> >
> >
> >Hi,
> >
> >I am very clear with the concept that IGPs cannot be used to carry the
> >entire BGP feed as
> >they cant be scaled to carry so many prefixes (even assuming
> >we add enough
> >TLVs to make
> >them carry the BGP attributes).
> >
> >What is not very clear to me is, why cant we use IBGP inside an AS to
> >completely do away
> >with IGPs. IGPs compute the best path to reach a particular
> >neighbor based
> >on the link
> >metric. This can be achieved in BGP also, if we include a TLV
> >to carry the
> >link cost.
> >Moreover, it is *mandatory* to run BGP on all the routers if we are
> >transiting traffic,
> >because if a router isnt speaking BGP then it cant forward BGP traffic.
> >
> >Cant we do away with IGPs (say in some small networks) and run
> >only IBGP
> >there?
> >
> >Any help/clues/pointers in this regard will be really appreciated.
> >
> >Regards,
> >Smith
> >
> >_________________________________________________________________
> >Tired of spam? Get advanced junk mail protection with MSN 8.
> >http://join.msn.com/?page=features/junkmail
> >
> >

_________________________________________________________________
MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. 
http://join.msn.com/?page=features/virus

To: Pekka Savola <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Tue, 23 Mar 2004 17:38:20 -0500

In message <[email-masked]>, Pekka Savola w
rites:
> There were no follow-ups to this and the spec has entered IETF Last 
> Call.
> 
> So, let me ask again; is there opposition for adding a clarification
> like:
> 
>    If a route's (Rte1) next-hop (Rte2) or next-hop interface would
>    lead to packets being discarded by the same router, the route
>    (Rte1) SHOULD be considered unresolvable.
> 
> or:
> 
>    When considering resolvable routes or referenced interfaces,
>    if packets through the route would be discarded by the router,
>    the route SHOULD be considered unresolvable.
> 
> in 9.1.2.1, after the two points about the route resolvability 
> condition (as justified by below) ?

There was plenty of response to your repeated messages on this topic.

There is no need to change the BGP spec.  If you want more details
look at the long threads on list and the threads off list.

Curtis

From: "Martin, Christian" <[email-masked]>
To: "'john smith'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 23 Mar 2004 17:35:58 -0500

Smith, 

Comments inline, as I have been following this thread.

>It would be great if you could share some more information on 
>the "issues" 
>of convergence time, CPU loads, and RP overloads.

Convergence is typically nonlienearly proportionate to CPU load, and
vice-versa, and they often feed off each other in a negative way.  Network
meltdowns are typically the result of routing loads disrupting topology
maintenance mechanisms, thereby causing adjacency loss, which causes more
routing load, which inhibits adjacency recreation, etc.  I've seen networks
stay in persistent "ditches" because the
convergence-adjacency-divergence-adjaceny-...loop stayed closed due to
loading.  Not fun to have to rebuild all of your routers or reattach them to
the network one by one...

>From my understanding
>a. it makes more sense to have 1 routing protocol as we dont 
>have multiple 
>daemons scheduled on the CPU. (which ofcourse is not a problem 
>but then so 
>is the point you mentioned below)

In either case, BGP will consume the vast majority of CPU cycles.  IGPs that
are properly tuned in stable environments hardly tickle the CPU, let alone
heat it up.  Take LSA/P refresh out of the picture, and all the IGP does is
send hellos and occasionally flood an LSA/P and compute an SPT once in a
rare while.  In the Internet, BGP is constantly processing updates and
withdrawals, all day, every day.  Sometimes, we see 100s of updates per
minute, sometimes just a few, but they are always there.

>b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we 
>inject 0.0.0.0/0 into IGP to make unknown prefixes go to the 
>nearest BGP 
>node.So does that help reduce the size of your routing table?

Large SPs must run a full BGP load, at a minimum, to give routes to their
customers.  Unless you are talking about enterprise routing, we should avoid
discussions of default routes...

>c. The cases u mention of changes, I presume you mean 
>route-flaps. Well in 
>that case, we eitherways have issues when IGP flaps, we 
>eitherways wait for 
>IGP to converge for BGP to converge etc? (I am sure "real 
>traffic" operators 
>do that)

Modern IGPs, properly tuned, converge way faster than BGP.  BGP convergence
is designed to be slow, so as not to place too much load on the global
routing system.  Since BGP carries so many routes, and since the topological
density of the Internet Autonomous System graph increases every day, BGP can
often take minutes to converge.  IGPs take seconds, partly because they are
usually lightweight.

>d. We have the benefits of not having the "global view" dependent on 1 
>protocol while the internal topology dependent on another

This is actually a sound design.  Think of the IGP as a topology discovery
mechanism.  All BGP routes have a next-hop.  The goal of BGP is to take
traffic to and from the "edges" of the network.  Sometimes, the edge is
within your network, like a server farm.  IGPs are very good at discovering
a topology and identifying the shortest path to each edge.  BGP is not
designed for this, and to make it do so requires considerable planning and
lots of policy.

>e. all i need to teach the network admins is BGP :)

It is much easier to learn simple IS-IS and OSPF than BGP.  Link State IGPs,
when employed for topology discovery, are exceedingly simple (particularly
IS-IS in a single area).  BGP, on the otherhand, is a much bigger protocol
that requires a lot of policy engineering in order for it to be effective.

>f. Based on c, how would you say that it makes things more 
>complicated to 
>run iBGP only compared to IGP+0.0.0.0/0 (default originate and 
>originate 
>always) and all those things taken into consideration?

Are you talking about running in an enterprise?  Default routes will not
work in any large environment for next-hop discovery of your iBGP peer IP's.
Loops would abound...

One of the problems with your proposal, and the primary reason this is not
done, is that iBGP does not provide for transitive route dissemination in a
network.  All 'other' IGPs do this.  This means your network topology must
be highly symmetrical and/or fully meshed at layer 3 (at least in
subsections) to allow for end-to-end route propagation.  Unless you can
employ lots of confeds (ie, each router in a confed subAS), lots of
route-reflectors, or a full-mesh topology at layer 3 (and layer 2 if you
consider multiaccess networks fully-meshed), then this approach is not
possible.

BGP also has race-condition mitigation rules that prevent a BGP route from
being learned from a next-hop that is known via BGP, so injecting routes
into BGP and hoping to bootstrap the next-hops would be problematic.  This
restriction is subtle and perhaps vendor specific, but usually, the next-hop
is recursed through an IGP or connected interface.  If this were possible,
in any event, it would be slow-converging, as iBGP updates are typically
spaced at 5 second intervals (depending on the event type).  Also, you will
have to peer with every interface on the device, thus forcing traffic to
take certain paths that may not be the best path available, as most BGP
attributes are non-accumulating (ie, u have to statically increase, say,
local-pref via policy as routes propagate along a set of routers in your
AS).

The reality is that even if such an approach _were_ possible, the drawbacks
are much more severe than simply turning on an IGP and having it discover
your topology.  Then, you may do what you with with iBGP.

The best philosophy, IMO, is to place loopbacks and links in your IGP, and
carry externals (either self-originated or from another AS) in your iBGP.
Route-reflectors are useful if regionalized, as they make best path
decisions before reflecting (so u want to be careful who peers with what to
ensure path selection optimality).  Confeds afford more control, TE, etc.,
but at what some claim to be a higher admin cost.  Use them based on what
you are trying to do.

HTH,
Chris

>would be great if you could help clarify this.
>
>-Smith
>

>
>
>
>
>You could certainly run BGP and statics without another 
>protocol for the 
>IGP, but why would you want to? Convergence times, CPU load on 
>RPs, etc., 
>during changes would be rather unsatisfactory. If you want to run one 
>dynamic protocol at all costs, then what you describe below 
>will work, and 
>has worked for some, but people with real traffic don't waste 
>their time 
>with it.
>
>
>Ben
>
>On Mar 15, 2004, at 8:24 PM, John Smith wrote:
>
>
>Hi,
>
>I am very clear with the concept that IGPs cannot be used to carry the 
>entire BGP feed as
>they cant be scaled to carry so many prefixes (even assuming 
>we add enough 
>TLVs to make
>them carry the BGP attributes).
>
>What is not very clear to me is, why cant we use IBGP inside an AS to 
>completely do away
>with IGPs. IGPs compute the best path to reach a particular 
>neighbor based 
>on the link
>metric. This can be achieved in BGP also, if we include a TLV 
>to carry the 
>link cost.
>Moreover, it is *mandatory* to run BGP on all the routers if we are 
>transiting traffic,
>because if a router isnt speaking BGP then it cant forward BGP traffic.
>
>Cant we do away with IGPs (say in some small networks) and run 
>only IBGP 
>there?
>
>Any help/clues/pointers in this regard will be really appreciated.
>
>Regards,
>Smith
>
>_________________________________________________________________
>Tired of spam? Get advanced junk mail protection with MSN 8. 
>http://join.msn.com/?page=features/junkmail
>
>

From: "john smith" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 23 Mar 2004 22:33:55 +0000

Hi Ben,

Thank you for your reply,
>
>a) scheduling is a minor concern.
>

I thought as much. CPU overload was something you mentioned. If you consider 
the point that OSPF carries only your IGP routes and BGP carries a lot more 
than that, the CPU overload problem will definately be there with BGP.

But then assume we were to do away with BGP what would be the problem? would 
an IGP like OSPF be able to do a better job with the whole routing table?

>b) certainly carrying a default helps reduce the size of the table, but 
>that is orthogonal to the question.  it is not common practice to carry 
>much in the igp (meaning bgp is not redistributed into the igp), so 
>carrying a default really is reducing the size of your bgp ribs which is 
>something you can do regardless of whether you have a second protocol for 
>the igp.

Exactly, so why add one more "protocol" to the network? What was wrong with 
just one?

As you see, 2 can load the RP and the CPU and lead to convergence issues a 
lot more :) that one (but that apparently now is hardly a concern?)
>
>c) yes, flapping routes are a problem regardless of protocol, so you 
>generally want one that converges very quickly.  a good link-state protocol 
>like ospf converges in seconds vs minutes for bgp in a reasonably complex 
>network.  again, the igp is only carrying limited information (links and 
>loops being a very common scenario) and has very detailed knowledge of the 
>network (handling per-link metrics in bgp would get very ugly very fast) so 
>it can do things that are inconvenient or impossible with bgp.

That is beause of the size of the routes handled by the protocol. What else 
do you think makes BGP slower? On the other hand, link state would have a 
lot more LSAs to compute the SPF against.
So if my "intermediate" nodes did not have the complete table but I was to 
use 0.0.0.0/0 just like I do for OSPF (seems like thats what was your 
intended IGP) Would not BGP on the intermediate nodes (the part that was 
covering my IGP) converge equally fast?

Incase you have a difference of opinion, please do tell me the reason.

>
>d) i don't know what benefits you mean.  decoupling the churn of the 
>"global view" from the stability of your internal network supports using an 
>independent igp.

which *may( work out if one was to use the same principals of IGP when using 
BGP as the IGP (0.0.0.0/0 to eBGP nodes etc?)
>
>e) if they can't understand ospf they shouldn't be touching the routers 
>anyway.
>

(Fine, I shall tell them that.)

>f) i'm not suggesting the use of a default route.
>

I am considering that as a possibility.

-Smith

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

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 23 Mar 2004 03:22:22 +0000

Hi Ben,

It would be great if you could share some more information on the "issues" 
of convergence time, CPU loads, and RP overloads.

>From my understanding
a. it makes more sense to have 1 routing protocol as we dont have multiple 
daemons scheduled on the CPU. (which ofcourse is not a problem but then so 
is the point you mentioned below)

b. We can use 0.0.0.0/0 to cover default gateways in iBGP just like we 
inject 0.0.0.0/0 into IGP to make unknown prefixes go to the nearest BGP 
node.So does that help reduce the size of your routing table?

c. The cases u mention of changes, I presume you mean route-flaps. Well in 
that case, we eitherways have issues when IGP flaps, we eitherways wait for 
IGP to converge for BGP to converge etc? (I am sure "real traffic" operators 
do that)

d. We have the benefits of not having the "global view" dependent on 1 
protocol while the internal topology dependent on another

e. all i need to teach the network admins is BGP :)

f. Based on c, how would you say that it makes things more complicated to 
run iBGP only compared to IGP+0.0.0.0/0 (default originate and originate 
always) and all those things taken into consideration?

would be great if you could help clarify this.

-Smith

You could certainly run BGP and statics without another protocol for the 
IGP, but why would you want to? Convergence times, CPU load on RPs, etc., 
during changes would be rather unsatisfactory. If you want to run one 
dynamic protocol at all costs, then what you describe below will work, and 
has worked for some, but people with real traffic don't waste their time 
with it.

Ben

On Mar 15, 2004, at 8:24 PM, John Smith wrote:

Hi,

I am very clear with the concept that IGPs cannot be used to carry the 
entire BGP feed as
they cant be scaled to carry so many prefixes (even assuming we add enough 
TLVs to make
them carry the BGP attributes).

What is not very clear to me is, why cant we use IBGP inside an AS to 
completely do away
with IGPs. IGPs compute the best path to reach a particular neighbor based 
on the link
metric. This can be achieved in BGP also, if we include a TLV to carry the 
link cost.
Moreover, it is *mandatory* to run BGP on all the routers if we are 
transiting traffic,
because if a router isnt speaking BGP then it cant forward BGP traffic.

Cant we do away with IGPs (say in some small networks) and run only IBGP 
there?

Any help/clues/pointers in this regard will be really appreciated.

Regards,
Smith

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

To: Pekka Savola <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd) 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Tue, 23 Mar 2004 08:31:32 -0800

Hi, Pekka:

Your proposed text does not reflect the deployed code, and prohibits
certain practice in use. So I do not seem it is appropriate for the
base spec..

-- Enke

> From: Pekka Savola <[email-masked]>
> To: [email-masked]
> Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
>  routes (fwd)
> Message-ID: <[email-masked]>
> 
> There were no follow-ups to this and the spec has entered IETF Last 
> Call.
> 
> So, let me ask again; is there opposition for adding a clarification
> like:
> 
>    If a route's (Rte1) next-hop (Rte2) or next-hop interface would
>    lead to packets being discarded by the same router, the route
>    (Rte1) SHOULD be considered unresolvable.
> 
> or:
> 
>    When considering resolvable routes or referenced interfaces,
>    if packets through the route would be discarded by the router,
>    the route SHOULD be considered unresolvable.
> 
> in 9.1.2.1, after the two points about the route resolvability 
> condition (as justified by below) ?
> 
> ---------- Forwarded message ----------
> Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET)
> From: Pekka Savola <[email-masked]>
> To: [email-masked]
> Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
>     routes
> 
> On Fri, 12 Mar 2004, Jeffrey Haas wrote:
> > On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote:
> > > I think the best way to handle this (from the standards standpoint) is
> > > to write a separate draft.  The draft would provide a better "BGP next
> > > hop resolvable test" but does not match any current implementation so
> > > it does not belong in the BGP spec.  If changes are made to any
> > > implementations they would remain fully interoperable with those that
> > > go by the letter of the spec without any "better resolvable test".
> > 
> > I would agree with Curtis.  This is an operational/deployment issue
> > and a draft covering such issues - and not just this one - may
> > be a Good Thing.
> 
> There was already an off-list discussion about this, but I think I 
> should clarify the issue here:
> 
>   The local router knows that route R2 is a discard/null0 route, and
>   the nexthop of route R1 goes through R2 after the more specific
>   route has been withdrawn from IGP.  Route R1 is considered valid 
>   even though the router knows it goes through a discard route.
> 
> Many consider this an implementation bug; some have already said
> they'd fix this, so the argument "there is no implementation" does not
> hold.
> 
> What I want is that this gets fixed in the spec, because the spec can
> be read both ways.  I want to avoid "local optimizations" by
> implementations, and fix this in the specification.  It would be
> irresponsible to have purposely ambiguous specifications.
> 
> One possible way to fix this could be, in 9.1.2.1:
> 
> ----
>    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 indi-
>       rectly) through Rte1. If multiple matching routes are available,
>       only the longest matching route SHOULD be considered.
> 
>       2. Routes referencing interfaces (with or without intermediate
>       addresses) are considered resolvable if the state of the refer-
>       enced interface is up and IP processing is enabled on this inter-
>       face.
> ----
> 
> Add a clarifying paragraph afterwards:
> 
>    If a route's (Rte1) next-hop (Rte2) or next-hop interface would 
>    lead to packets being discarded by the same router, the route 
>    (Rte1) SHOULD be considered unresolvable.
> 
> or:
>  
>    When considering resolvable routes or referenced interfaces,
>    if packets through the route would be discarded by the router,
>    the route SHOULD be considered unresolvable.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 
> 

To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0  routes (fwd)
Sender: [email-masked]
Date: Tue, 23 Mar 2004 10:01:57 -0500

I'd object to either of those since they would have the effect of 
forbidding certain DoS mitigation techniques, as we've already 
discussed.

Either option is not a clarification, but a spec change.

--John

At 4:42 PM +0200 3/23/04, Pekka Savola wrote:
>There were no follow-ups to this and the spec has entered IETF Last
>Call.
>
>So, let me ask again; is there opposition for adding a clarification
>like:
>
>    If a route's (Rte1) next-hop (Rte2) or next-hop interface would
>    lead to packets being discarded by the same router, the route
>    (Rte1) SHOULD be considered unresolvable.
>
>or:
>
>    When considering resolvable routes or referenced interfaces,
>    if packets through the route would be discarded by the router,
>    the route SHOULD be considered unresolvable.
>
>in 9.1.2.1, after the two points about the route resolvability
>condition (as justified by below) ?
...

From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes (fwd)
Sender: [email-masked]
Date: Tue, 23 Mar 2004 16:42:36 +0200 (EET)

There were no follow-ups to this and the spec has entered IETF Last 
Call.

So, let me ask again; is there opposition for adding a clarification
like:

   If a route's (Rte1) next-hop (Rte2) or next-hop interface would
   lead to packets being discarded by the same router, the route
   (Rte1) SHOULD be considered unresolvable.

or:

   When considering resolvable routes or referenced interfaces,
   if packets through the route would be discarded by the router,
   the route SHOULD be considered unresolvable.

in 9.1.2.1, after the two points about the route resolvability 
condition (as justified by below) ?

---------- Forwarded message ----------
Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
    routes

On Fri, 12 Mar 2004, Jeffrey Haas wrote:
> On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote:
> > I think the best way to handle this (from the standards standpoint) is
> > to write a separate draft.  The draft would provide a better "BGP next
> > hop resolvable test" but does not match any current implementation so
> > it does not belong in the BGP spec.  If changes are made to any
> > implementations they would remain fully interoperable with those that
> > go by the letter of the spec without any "better resolvable test".
> 
> I would agree with Curtis.  This is an operational/deployment issue
> and a draft covering such issues - and not just this one - may
> be a Good Thing.

There was already an off-list discussion about this, but I think I 
should clarify the issue here:

  The local router knows that route R2 is a discard/null0 route, and
  the nexthop of route R1 goes through R2 after the more specific
  route has been withdrawn from IGP.  Route R1 is considered valid 
  even though the router knows it goes through a discard route.

Many consider this an implementation bug; some have already said
they'd fix this, so the argument "there is no implementation" does not
hold.

What I want is that this gets fixed in the spec, because the spec can
be read both ways.  I want to avoid "local optimizations" by
implementations, and fix this in the specification.  It would be
irresponsible to have purposely ambiguous specifications.

One possible way to fix this could be, in 9.1.2.1:

----
   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 indi-
      rectly) through Rte1. If multiple matching routes are available,
      only the longest matching route SHOULD be considered.

      2. Routes referencing interfaces (with or without intermediate
      addresses) are considered resolvable if the state of the refer-
      enced interface is up and IP processing is enabled on this inter-
      face.
----

Add a clarifying paragraph afterwards:

   If a route's (Rte1) next-hop (Rte2) or next-hop interface would 
   lead to packets being discarded by the same router, the route 
   (Rte1) SHOULD be considered unresolvable.

or:
 
   When considering resolvable routes or referenced interfaces,
   if packets through the route would be discarded by the router,
   the route SHOULD be considered unresolvable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt
Sender: [email-masked]
Date: Wed, 17 Mar 2004 11:09:02 -0500

--NextPart

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

	Title		: BGP Graceful Restart - Implementation Survey
	Author(s)	: J. Scudder
	Filename	: draft-ietf-idr-bgp-gr-survey-01.txt
	Pages		: 10
	Date		: 2004-3-12
	
This document provides a survey of BGP-4 Graceful Restart
implementations.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt
Sender: [email-masked]
Date: Fri, 12 Mar 2004 15:29:23 -0500

--NextPart

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

	Title		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-06.txt
	Pages		: 0
	Date		: 2004-3-12
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt

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

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

--OtherAccess--

--NextPart--

Cc: [email-masked]
From: Benjamin Black <[email-masked]>
Subject: Re: [Idr] IBGP to replace IGP
To: John Smith <[email-masked]>
Sender: [email-masked]
Date: Mon, 15 Mar 2004 22:09:48 -0800

You could certainly run BGP and statics without another protocol for 
the IGP, but why would you want to?  Convergence times, CPU load on 
RPs, etc., during changes would be rather unsatisfactory.  If you want 
to run one dynamic protocol at all costs, then what you describe below 
will work, and has worked for some, but people with real traffic don't 
waste their time with it.

Ben

On Mar 15, 2004, at 8:24 PM, John Smith wrote:

> Hi,
>
> I am very clear with the concept that IGPs cannot be used to carry the 
> entire BGP feed as
> they cant be scaled to carry so many prefixes (even assuming we add 
> enough TLVs to make
> them carry the BGP attributes).
>
> What is not very clear to me is, why cant we use IBGP inside an AS to 
> completely do away
> with IGPs. IGPs compute the best path to reach a particular neighbor 
> based on the link
> metric. This can be achieved in BGP also, if we include a TLV to carry 
> the link cost.
> Moreover, it is *mandatory* to run BGP on all the routers if we are 
> transiting traffic,
> because if a router isnt speaking BGP then it cant forward BGP traffic.
>
> Cant we do away with IGPs (say in some small networks) and run only 
> IBGP there?
>
> Any help/clues/pointers in this regard will be really appreciated.
>
> Regards,
> Smith
>
>
>
> 	
> 	
> 		

To: IETF-Announce :;
Cc: [email-masked];[email-masked];;
From: The IESG <[email-masked]>
Reply-to: [email-masked]
Subject: [Idr] Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard
Sender: [email-masked]
Date: Tue, 16 Mar 2004 16:29:24 -0500

The IESG has received a request from the Inter-Domain Routing WG to consider
the following set of documents updating the Border Gateway Protocol 4
specification.

BGP4 protocol-related documents:

- 'A Border Gateway Protocol 4 (BGP-4) '
   <draft-ietf-idr-bgp4-23.txt> as a Draft Standard
- 'BGP Security Vulnerabilities Analysis '
   <draft-ietf-idr-bgp-vuln-00.txt> as an Informational RFC
- 'BGP-4 Protocol Analysis '
   <draft-ietf-idr-bgp-analysis-04.txt> as an Informational RFC
- 'Experience with the BGP-4 Protocol '
   <draft-ietf-idr-bgp4-experience-protocol-03.txt> as an Informational RFC

BGP4 MIB-related documents:

- 'Definitions of Managed Objects for the Fourth Version of Border Gateway 
   Protocol (BGP-4) '
   <draft-ietf-idr-bgp4-mib-13.txt> as a Proposed Standard

Implementation reports:

- 'BGP 4 Implementation Report '
   <draft-ietf-idr-bgp-implementation-00.txt> as an Informational RFC
- 'BGP MIB V1 implementation survey '
   <draft-ietf-idr-bgp-mibagent-survey-00.txt> as an Informational RFC

The documents above satisfy the standardization criteria for Routing 
Protocols described in RFC 1264.

Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC
2385), which is a Proposed Standard, as the mandatory to implement
authentication mechanism, the IESG is planning to apply the variance 
procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft
Standard level to have a normative reference to RFC 2385. The variance 
prodedure request is documented in the following document:

- 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 
   2385) and the BGP-4 Specification '
   <draft-iesg-tcpmd5app-00.txt> as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-04-13.

The files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-
03.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt
http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt

Implementation Reports can be accessed at
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-gr-survey-01.txt
Sender: [email-masked]
Date: Fri, 12 Mar 2004 15:29:29 -0500

--NextPart

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

	Title		: BGP Graceful Restart - Implementation Survey
	Author(s)	: J. Scudder
	Filename	: draft-ietf-idr-bgp-gr-survey-01.txt
	Pages		: 10
	Date		: 2004-3-12
	
This document provides a survey of BGP-4 Graceful Restart
implementations.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-gr-survey-01.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2858bis-04.txt
Sender: [email-masked]
Date: Tue, 16 Mar 2004 16:00:24 -0500

--NextPart

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

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

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-rfc2858bis-04.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-aspath-orf-06.txt
Sender: [email-masked]
Date: Wed, 17 Mar 2004 11:08:46 -0500

--NextPart

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

	Title		: Aspath Based Outbound Route Filter for BGP-4
	Author(s)	: K. Patel, S. Hares
	Filename	: draft-ietf-idr-aspath-orf-06.txt
	Pages		: 0
	Date		: 2004-3-12
	
This document defines a new Outbound Router Filter type for BGP,
termed 'Aspath Outbound Route Filter', that can be used to perform 
aspath based route filtering. This ORF-type supports aspath based 
route filtering as well as regular expression based matching, for 
address groups.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-aspath-orf-06.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-as4bytes-08.txt
Sender: [email-masked]
Date: Tue, 16 Mar 2004 16:00:19 -0500

--NextPart

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

	Title		: BGP support for four-octet AS number space
	Author(s)	: Q. Vohra, E. Chen
	Filename	: draft-ietf-idr-as4bytes-08.txt
	Pages		: 7
	Date		: 2004-3-16
	
Currently the Autonomous System number is encoded in BGP [BGP] as a
two-octets field. This document describes extensions to BGP to carry
the Autonomous System number as a four-octets field.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-as4bytes-08.txt

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

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

--OtherAccess--

--NextPart--

Cc: [email-masked]
From: Benjamin Black <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
To: Pekka Savola <[email-masked]>
Sender: [email-masked]
Date: Fri, 12 Mar 2004 10:05:44 -0800

Which one of your options leads to "this isn't something that concerns 
BGP"?

Ben

On Mar 12, 2004, at 1:13 AM, Pekka Savola wrote:

> Hello, it's me again :)..
>
> Now that the on-list thread has apparently died, and the off-list
> discussions as well, I think it would be important to understand how
> to move forward, and to try to gauge whether everyone is aware of
> which issue we're talking about.
>
> As there was a lot of confusion at first on the actual problem, I
> won't try to summarize the thread, because at different times, people
> probably had entirely different assumptions of the problem.
>
> The bottom line is this: in very many cases you cannot avoid having to
> insert some some kind of discard/reject or null0 route for a specific
> prefix on a router (e.g., to generate a default route to some peers).
> When the next-hop of some other router, on that *same* router, goes
> through that "discard" route, the next-hop is still considered valid.
> This causes rather obvious BGP timeout problems.
>
> The non-problem is when you have to redistribute that discard route in
> your routing system, whether in IGP or BGP, and the other routers
> cannot tell that's it's a discard route as it's learned through a
> routing protocol.  This can be rather easily avoided by configuring
> the discard routes everywhere, so I don't think this needs to be
> solved at this point.
>
> Now.. what do people think about this problem -- what should we do
> (pick one or multiple):
>
>  1) try to specify some behaviour in the bgp spec to avoid this issue;
>    for example:
>   1.a) state that if the route towards the next-hop leads to packets
> being discarded by the router, SHOULD consider the next-hop ineligible
>   1.b) state that the implementation SHOULD support being able to
> configure which routes to use in in the next-hop eligibility detection
> process
>   1.c) to be worked out later..
>   1.d) something else -- what?
>
>  2) defer the solution until later
>
>  3) clarify the operational problem, to make the reader/implementer
> aware of it
>   3.a) in this revision of bgp spec
>   3.b) in some other documents(s)
>
>  4) other -- what ?
>
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard
Sender: [email-masked]
Date: Fri, 19 Mar 2004 11:30:30 -0800

Folks-

Below is the IETF LC announcement that should have made it to several
lists and hasn't yet

http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html

-- 
Alex
http://www.psg.com/~zinin/

>     * To: IETF-Announce :;
>     * Subject: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard
>     * From: The IESG <iesg-secretary at ietf.org>
>     * Date: Tue, 16 Mar 2004 16:29:24 -0500
>     * Cc: idr at ietf.org;rtg-dir at ietf.org;
>     * Reply-to: iesg at ietf.org
>     * Sender: owner-ietf-announce at ietf.org
> 
> The IESG has received a request from the Inter-Domain Routing WG to consider
> the following set of documents updating the Border Gateway Protocol 4
> specification.
> 
> BGP4 protocol-related documents:
> 
> - 'A Border Gateway Protocol 4 (BGP-4) '
>    <draft-ietf-idr-bgp4-23.txt> as a Draft Standard
> - 'BGP Security Vulnerabilities Analysis '
>    <draft-ietf-idr-bgp-vuln-00.txt> as an Informational RFC
> - 'BGP-4 Protocol Analysis '
>    <draft-ietf-idr-bgp-analysis-04.txt> as an Informational RFC
> - 'Experience with the BGP-4 Protocol '
>    <draft-ietf-idr-bgp4-experience-protocol-03.txt> as an Informational RFC
> 
> BGP4 MIB-related documents:
> 
> - 'Definitions of Managed Objects for the Fourth Version of Border Gateway 
>    Protocol (BGP-4) '
>    <draft-ietf-idr-bgp4-mib-13.txt> as a Proposed Standard
> 
> Implementation reports:
> 
> - 'BGP 4 Implementation Report '
>    <draft-ietf-idr-bgp-implementation-00.txt> as an Informational RFC
> - 'BGP MIB V1 implementation survey '
>    <draft-ietf-idr-bgp-mibagent-survey-00.txt> as an Informational RFC
> 
> The documents above satisfy the standardization criteria for Routing 
> Protocols described in RFC 1264.
> 
> Since draft-ietf-idr-bgp4-23.txt specifies the TCP MD5 Signature Option (RFC
> 2385), which is a Proposed Standard, as the mandatory to implement
> authentication mechanism, the IESG is planning to apply the variance 
> procedure per RFC 2026 to allow the BGP4 protocol specification at the Draft
> Standard level to have a normative reference to RFC 2385. The variance 
> prodedure request is documented in the following document:
> 
> - 'Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 
>    2385) and the BGP-4 Specification '
>    <draft-iesg-tcpmd5app-00.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send any comments to the
> [email-masked] or [email-masked] mailing lists by 2004-04-13.
> 
> The files can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-23.txt
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-vuln-00.txt
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.txt
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-
> 03.txt
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-13.txt
> http://www.ietf.org/internet-drafts/draft-iesg-tcpmd5app-00.txt
> 
> Implementation Reports can be accessed at
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-implementation-00.txt
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.tx

To: Hunju Park <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] BGP Marker in the Header 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Thu, 18 Mar 2004 13:20:38 -0500

In message <[email-masked]>, Hunju Park wri
tes:
> Hi,
> What is the need for the BGP Marker (16 bytes) containing all FFs. It is said
>  that it was used at
> times for security but i dont think its valid anymore. If anybody wants secur
> ity then he can use
> TCP-MD5.
> 
> Any clues,
> Park
> 
> P.S.
> I went through the IDR archives before posting this and couldnt find any expl
> anation for this!
> Infact,this question was raised a long time back, but nobody answered this.

It is used to detect a horrible bug in either the sending or receiving
implementation in which packet alignment has been lost.  Those sort of
bugs are much less common that they were a decade or more ago, but it
might not hurt to keep the check in place anyway.  You can't tell what
sort of code you will be BGP peering with, including someone's kludged
together test or monitoring code.

Curtis

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Subject: [Idr] FW: BGP MIB v1 Review
Sender: [email-masked]
Date: Thu, 18 Mar 2004 10:07:23 -0500

-----Original Message-----
From: Chisholm, Sharon [CAR:0S00:EXCH] 
Sent: Wednesday, March 17, 2004 3:25 PM
To: 'Wijnen, Bert (Bert)'
Cc: 'Susan Hares'; 'Jeffrey Haas'
Subject: BGP MIB v1 Review

hi

I focused more of my energy into reviewing the delta from the previous
version as appose to the older content. I figured we should focus our
efforts on getting version 2 of the MIB correct.

Issues
------

1. Need to update copyright dates to 2004

2. In the description of bgpPeerIdentifier and bgpPeerNegotiatedVersion the
"should" should be "MUST". 

3. The second occurrences of 'should' in bgpPeerNegotiatedVersion is an
interesting case as the value was never restricted in the initial version of
the MIB, yet you are trying to define what a legal value is in the text.
Clarifying where the 'legal' definition is coming from might be helpful.

4. The description for bgp4PathAttrAtomicAggregate is worrisome, but I
suspect we are not actually changing the behaviour as drastically as it
sounds. I am assuming that the NLRI stuff does not have anything to do with
the MIB and this behaviour is described elsewhere. I would suggest rewording
it to say:

                    "This object indicates whether or not a system has 
                     selected a less specific route without
                     selecting a more specific route.

                     If the ATOMIC_AGGREGATE attribute is present
                     in the Path Attributes then this object
                     MUST have a  value of 'lessSpecificRouteNotSelected'.
                     If the ATOMIC_AGGREGATE attribute is missing
                     in the Path Attributes then this object MUST have
                     a value of 'lessSpecificRouteSelected'.

                     Note that ATOMIC_AGGREGATE has been
                     deprecated in the BGP specification."
Note we should also add a REFERENCE clause to the BGP specification.

5. In the definitions of the Notifications, we should replace "This object
deprecates <foo>" with "This Notification replaces the <foo> Notification."
On the other end, replace "This object has been deprecated in favor of
<foo>" with "This Notification has been replaced by the <foo> Notification.

6. There is a line "--- XXX TODO ..." within the reference section that
looks like it should be removed or replaced with an RFC editor instruction.

7. There are no references in the text to RFC1901, RFC2574, RFC2576,
RFC3411, RFC3413, RFC3415, RFC3416 or RFC3417 within the text. These need to
be removed. 

Non-gating Issues
----------

1. I'm assuming the fact that the behaviour of several counters has changed
has been discussed and is considered acceptable. I'm personally not sure it
is the right thing to do.

2. The text describing behaviour of bgpPeerHoldTimer and bgpPeerKeepAlive is
rather passive. This should definitely changed in version 2 or the MIB, but
is probable ok for this version. Example 

                    "If the value is
                     zero (0), the Hold Timer has either not been
                     established with the peer, or, the value of
                     bgpPeerHoldTimeConfigured is zero (0)." versus
			"  If the Hold Timer has not been established with 
                     the peer this object MUST have a value of (0).
                     If the bgpPeerHoldTimeConfigured has a value of
                     (0), then this object MUST have a value of (0)."

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada

From: Hunju Park <[email-masked]>
To: [email-masked]
Subject: [Idr] BGP Marker in the Header
Sender: [email-masked]
Date: Thu, 18 Mar 2004 06:26:33 -0500 (EST)

Hi,
What is the need for the BGP Marker (16 bytes) containing all FFs. It is said that it was used at
times for security but i dont think its valid anymore. If anybody wants security then he can use
TCP-MD5.

Any clues,
Park

P.S.
I went through the IDR archives before posting this and couldnt find any explanation for this!
Infact,this question was raised a long time back, but nobody answered this.

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

From: Pekka Savola <[email-masked]>
To: =?iso-8859-1?q?John=20Smith?= <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 16 Mar 2004 07:59:24 +0200 (EET)

On Tue, 16 Mar 2004, John Smith wrote:
> Cant we do away with IGPs (say in some small networks) and run only IBGP there?

How do you route point-to-point and loopback addresses if not with 
IGP?  Using static routes? :)

Otherwise, yes, IBGP has mostly replaced IGP especially wrt. external
prefixes and that's a good thing.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: =?iso-8859-1?q?John=20Smith?= <[email-masked]>
Subject: RE: [Idr] IBGP to replace IGP
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]
Date: Tue, 16 Mar 2004 05:58:39 +0000 (GMT)

Michel,

> Where does this come from? I have configured transit networks with an
> IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at
> the edge. What about this animal called NLRI?

Say your edge BGP speaker (R1) learns 10.0.0.0/8 from some other EBGP router (NH1). It
advertises the same to the other edge (R2) BGP router (which resides in the other corner
of the same AS) with the NEXT_HOP NH1. Now you have IGPs running in the core so all the
routers are aware of how they can reach NH1. When data traffic comes on the BGP router
R2, it looks at its FIB and determines that it needs to forward the packet to one of your
core routers in between the path to reach NH1. When the packet comes to that core router,
there isnt any information about 10.0.0.0/8 on that router. How is then that packet
forwarded.

One can use default routes on the core IGP speaking routers, but that isnt a good
solution and can easily lead to routing loops/black holes.

Hope i made my case clear.

Regards,
Smith

Content-class: urn:content-classes:message
Subject: RE: [Idr] IBGP to replace IGP
From: "Michel Py" <[email-masked]>
To: "John Smith" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Mon, 15 Mar 2004 21:44:33 -0800

> John Smith wrote:
> Moreover, it is *mandatory* to run BGP on all the routers
> if we are transiting traffic, because if a router isn't
> speaking BGP then it cant forward BGP traffic. 

Where does this come from? I have configured transit networks with an
IGP (OSPF in my case, but some will prefer IS-IS) in the core and BGP at
the edge. What about this animal called NLRI?

Michel.

From: =?iso-8859-1?q?John=20Smith?= <[email-masked]>
To: [email-masked]
Subject: [Idr] IBGP to replace IGP
Sender: [email-masked]
Date: Tue, 16 Mar 2004 04:24:12 +0000 (GMT)

Hi,

I am very clear with the concept that IGPs cannot be used to carry the entire BGP feed as
they cant be scaled to carry so many prefixes (even assuming we add enough TLVs to make
them carry the BGP attributes).

What is not very clear to me is, why cant we use IBGP inside an AS to completely do away
with IGPs. IGPs compute the best path to reach a particular neighbor based on the link
metric. This can be achieved in BGP also, if we include a TLV to carry the link cost.
Moreover, it is *mandatory* to run BGP on all the routers if we are transiting traffic,
because if a router isnt speaking BGP then it cant forward BGP traffic. 

Cant we do away with IGPs (say in some small networks) and run only IBGP there?

Any help/clues/pointers in this regard will be really appreciated.

Regards,
Smith

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] BGP Extended Communities implementation report
Sender: [email-masked]
Date: Mon, 15 Mar 2004 08:47:18 -0800

Folks,

Those who participated in the BGP Extended Communities implementation
report please let me know if you'd like me to make any updates.

Those who did not participate in the report, but would like to be
added to the report, please send me the info in a format similar
to the one used in the report.

The deadline is March 28, 2004.

Yakov.
------- Forwarded Message

Date:    Thu, 11 Mar 2004 15:18:35 -0500
From:    [email-masked]
To:      IETF-Announce: ;
Subject: I-D ACTION:draft-rekhter-ext-communities-survey-02.txt

- --NextPart

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

	Title		: BGP Extended Communities Attribute - Implementation S
urvey
	Author(s)	: Y. Rekhter
	Filename	: draft-rekhter-ext-communities-survey-02.txt
	Pages		: 13
	Date		: 2004-3-11
	
This document provides a survey of BGP-4 Extended Communities
implementations.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-rekhter-ext-communities-survey-02.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-rekhter-ext-communities-survey-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Sat, 13 Mar 2004 09:57:15 +0200 (EET)

On Fri, 12 Mar 2004, Jeffrey Haas wrote:
> On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote:
> > I think the best way to handle this (from the standards standpoint) is
> > to write a separate draft.  The draft would provide a better "BGP next
> > hop resolvable test" but does not match any current implementation so
> > it does not belong in the BGP spec.  If changes are made to any
> > implementations they would remain fully interoperable with those that
> > go by the letter of the spec without any "better resolvable test".
> 
> I would agree with Curtis.  This is an operational/deployment issue
> and a draft covering such issues - and not just this one - may
> be a Good Thing.

There was already an off-list discussion about this, but I think I 
should clarify the issue here:

  The local router knows that route R2 is a discard/null0 route, and
  the nexthop of route R1 goes through R2 after the more specific
  route has been withdrawn from IGP.  Route R1 is considered valid 
  even though the router knows it goes through a discard route.

Many consider this an implementation bug; some have already said
they'd fix this, so the argument "there is no implementation" does not
hold.

What I want is that this gets fixed in the spec, because the spec can
be read both ways.  I want to avoid "local optimizations" by
implementations, and fix this in the specification.  It would be
irresponsible to have purposely ambiguous specifications.

One possible way to fix this could be, in 9.1.2.1:

----
   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 indi-
      rectly) through Rte1. If multiple matching routes are available,
      only the longest matching route SHOULD be considered.

      2. Routes referencing interfaces (with or without intermediate
      addresses) are considered resolvable if the state of the refer-
      enced interface is up and IP processing is enabled on this inter-
      face.
----

Add a clarifying paragraph afterwards:

   If a route's (Rte1) next-hop (Rte2) or next-hop interface would 
   lead to packets being discarded by the same router, the route 
   (Rte1) SHOULD be considered unresolvable.

or:
 
   When considering resolvable routes or referenced interfaces,
   if packets through the route would be discarded by the router,
   the route SHOULD be considered unresolvable.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Jeffrey Haas <[email-masked]>
To: Curtis Villamizar <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 12 Mar 2004 14:13:18 -0500

On Fri, Mar 12, 2004 at 04:55:04AM -0500, Curtis Villamizar wrote:
> I think the best way to handle this (from the standards standpoint) is
> to write a separate draft.  The draft would provide a better "BGP next
> hop resolvable test" but does not match any current implementation so
> it does not belong in the BGP spec.  If changes are made to any
> implementations they would remain fully interoperable with those that
> go by the letter of the spec without any "better resolvable test".

I would agree with Curtis.  This is an operational/deployment issue
and a draft covering such issues - and not just this one - may
be a Good Thing.

-- 
Jeff Haas 
NextHop Technologies

From: Pekka Savola <[email-masked]>
To: Robert Raszuk <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 12 Mar 2004 12:20:55 +0200 (EET)

On Fri, 12 Mar 2004, Robert Raszuk wrote:
> So all you are asking here is faster next hop state detection and fast 
> route validatation. Very valid request, but again I fail to see why BGP 
> spec should mandate how fast one wishes to validate his next hops. All 
> major implementations I am aware about do it fast enough or allow one to 
> configure how fast you want to validate the next hops.

No, the validation time (i.e., how often you check whether a nexthop
has become ineligible) is not the point.  The point is that the
validation process, no matter how often or seldom is run, reports
"valid!" for these routes which go through a discard next-hop.  
Rigging the timers changes nothing.

> Btw .. bgp session timeout does not have to be only triggered by BGP 
> keepalives :) If you monitor some other work in the IETF BFD could be 
> one trigger, IGP another etc ... so it could be very fast indeed ;)

FWIW, Multi-hop case is currently basically out of scope for BFD.  
But that's a separate topic.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Pekka Savola <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 12 Mar 2004 02:09:47 -0800

Pekka,

>> > When the next-hop of some other router, on that *same* router, goes
>> > through that "discard" route, the next-hop is still considered valid.
>> > This causes rather obvious BGP timeout problems.
>>
>>Well I would say that this is rather not so obvious to have next hops 
>>for the routes causing any BGP timeouts. I have not see anyone opening a 
>>BGP session or configuring update src to a null0 route. I am not even 
>>sure what you are trying to say above.
> 
> 
> Sorry for bad wording.  The intent was to say that when another router
> fails, and the next-hop points to that router, if the next-hop is not
> made ineligible, the routes going through that router will only be
> removed when the BGP timeout expires... causing very long
> unavailability.

So all you are asking here is faster next hop state detection and fast 
route validatation. Very valid request, but again I fail to see why BGP 
spec should mandate how fast one wishes to validate his next hops. All 
major implementations I am aware about do it fast enough or allow one to 
configure how fast you want to validate the next hops.

Anyhow you can for sure propose the text and min timers this should 
happen and send to the list for review.

Btw .. bgp session timeout does not have to be only triggered by BGP 
keepalives :) If you monitor some other work in the IETF BFD could be 
one trigger, IGP another etc ... so it could be very fast indeed ;)

Cheers,
R.

From: Pekka Savola <[email-masked]>
To: Robert Raszuk <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 12 Mar 2004 11:56:46 +0200 (EET)

On Fri, 12 Mar 2004, Robert Raszuk wrote:
>  > Now that the on-list thread has apparently died, and the off-list
>  > discussions as well, I think it would be important to understand how
>  > to move forward, and to try to gauge whether everyone is aware of
>  > which issue we're talking about.
> 
> The problem did not died but was solved. The solution was that this is 
> implementation detail what next hops are used for route resolution as a 
> matter of the protocol owner as well as what mask length is desired. 

First, if it was decided that this is an implementation detail, it 
must IMHO be explicitly called out as such.

Second, I disagree with this being an "implementation detail".  This
has significant operational implications, and the behaviour must be as 
consistent as possible.

Dusting this off under the carpet doesn't seem to be reasonable.

>  > When the next-hop of some other router, on that *same* router, goes
>  > through that "discard" route, the next-hop is still considered valid.
>  > This causes rather obvious BGP timeout problems.
> 
> Well I would say that this is rather not so obvious to have next hops 
> for the routes causing any BGP timeouts. I have not see anyone opening a 
> BGP session or configuring update src to a null0 route. I am not even 
> sure what you are trying to say above.

Sorry for bad wording.  The intent was to say that when another router
fails, and the next-hop points to that router, if the next-hop is not
made ineligible, the routes going through that router will only be
removed when the BGP timeout expires... causing very long
unavailability.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

To: Pekka Savola <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Fri, 12 Mar 2004 04:55:04 -0500

In message <[email-masked]>, Pekka Savola w
rites:
> Hello, it's me again :)..
> 
> Now that the on-list thread has apparently died, and the off-list
> discussions as well, I think it would be important to understand how
> to move forward, and to try to gauge whether everyone is aware of
> which issue we're talking about.
> 
> As there was a lot of confusion at first on the actual problem, I 
> won't try to summarize the thread, because at different times, people 
> probably had entirely different assumptions of the problem.
> 
> The bottom line is this: in very many cases you cannot avoid having to
> insert some some kind of discard/reject or null0 route for a specific
> prefix on a router (e.g., to generate a default route to some peers).  
> When the next-hop of some other router, on that *same* router, goes
> through that "discard" route, the next-hop is still considered valid.
> This causes rather obvious BGP timeout problems.
> 
> The non-problem is when you have to redistribute that discard route in
> your routing system, whether in IGP or BGP, and the other routers
> cannot tell that's it's a discard route as it's learned through a 
> routing protocol.  This can be rather easily avoided by configuring 
> the discard routes everywhere, so I don't think this needs to be 
> solved at this point.
> 
> Now.. what do people think about this problem -- what should we do 
> (pick one or multiple):
> 
>  1) try to specify some behaviour in the bgp spec to avoid this issue; 
>    for example:
>   1.a) state that if the route towards the next-hop leads to packets 
> being discarded by the router, SHOULD consider the next-hop ineligible
>   1.b) state that the implementation SHOULD support being able to 
> configure which routes to use in in the next-hop eligibility detection 
> process
>   1.c) to be worked out later..
>   1.d) something else -- what?
> 
>  2) defer the solution until later
> 
>  3) clarify the operational problem, to make the reader/implementer 
> aware of it
>   3.a) in this revision of bgp spec
>   3.b) in some other documents(s)
> 
>  4) other -- what ?
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

In this ongoing discussion, we should be clear about what the
consequence is.

IBGP learned routes from a peer that has gone down do not get
withdrawn on the IGP route withdraw due to the coverage of the next
hop by an aggregate.  Those IBGP learned routes are withdrawn after
the BGP session times out which is rather a long time by today's
standards.

This is mostly a usage issue which arises when a provider's
infrastructure is covered by an aggregate that is advertised within
that provider's infrastructure.  This problem is easily avoided,
except in providers (or other BGP usage) where a default route is
made available or where address space of the provider is taken from a
larger aggregate of another provider.

With some optional configuration a router can exclude routes from
consideration in matching the BGP next-hop resolvable test.  If the
router does so, the provider doesn't need to work around the problem.

I think the best way to handle this (from the standards standpoint) is
to write a separate draft.  The draft would provide a better "BGP next
hop resolvable test" but does not match any current implementation so
it does not belong in the BGP spec.  If changes are made to any
implementations they would remain fully interoperable with those that
go by the letter of the spec without any "better resolvable test".

Curtis

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: Pekka Savola <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Fri, 12 Mar 2004 01:48:48 -0800

Pekka,

 > Now that the on-list thread has apparently died, and the off-list
 > discussions as well, I think it would be important to understand how
 > to move forward, and to try to gauge whether everyone is aware of
 > which issue we're talking about.

The problem did not died but was solved. The solution was that this is 
implementation detail what next hops are used for route resolution as a 
matter of the protocol owner as well as what mask length is desired. It 
was also clearly concluded by a few that BGP spec is not the place to 
add this and that you may rather issue a standalone draft describing 
operational implications on discard next hops and possibly recommend to 
implementations some new functionality.

 > When the next-hop of some other router, on that *same* router, goes
 > through that "discard" route, the next-hop is still considered valid.
 > This causes rather obvious BGP timeout problems.

Well I would say that this is rather not so obvious to have next hops 
for the routes causing any BGP timeouts. I have not see anyone opening a 
BGP session or configuring update src to a null0 route. I am not even 
sure what you are trying to say above.

Cheers,
R.

 > Pekka Savola wrote:
 >
> Hello, it's me again :)..
> 
> Now that the on-list thread has apparently died, and the off-list
> discussions as well, I think it would be important to understand how
> to move forward, and to try to gauge whether everyone is aware of
> which issue we're talking about.
> 
> As there was a lot of confusion at first on the actual problem, I 
> won't try to summarize the thread, because at different times, people 
> probably had entirely different assumptions of the problem.
> 
> The bottom line is this: in very many cases you cannot avoid having to
> insert some some kind of discard/reject or null0 route for a specific
> prefix on a router (e.g., to generate a default route to some peers).  
> When the next-hop of some other router, on that *same* router, goes
> through that "discard" route, the next-hop is still considered valid.
> This causes rather obvious BGP timeout problems.
> 
> The non-problem is when you have to redistribute that discard route in
> your routing system, whether in IGP or BGP, and the other routers
> cannot tell that's it's a discard route as it's learned through a 
> routing protocol.  This can be rather easily avoided by configuring 
> the discard routes everywhere, so I don't think this needs to be 
> solved at this point.
> 
> Now.. what do people think about this problem -- what should we do 
> (pick one or multiple):
> 
>  1) try to specify some behaviour in the bgp spec to avoid this issue; 
>    for example:
>   1.a) state that if the route towards the next-hop leads to packets 
> being discarded by the router, SHOULD consider the next-hop ineligible
>   1.b) state that the implementation SHOULD support being able to 
> configure which routes to use in in the next-hop eligibility detection 
> process
>   1.c) to be worked out later..
>   1.d) something else -- what?
> 
>  2) defer the solution until later
> 
>  3) clarify the operational problem, to make the reader/implementer 
> aware of it
>   3.a) in this revision of bgp spec
>   3.b) in some other documents(s)
> 
>  4) other -- what ?
> 

From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
Sender: [email-masked]
Date: Fri, 12 Mar 2004 11:13:31 +0200 (EET)

Hello, it's me again :)..

Now that the on-list thread has apparently died, and the off-list
discussions as well, I think it would be important to understand how
to move forward, and to try to gauge whether everyone is aware of
which issue we're talking about.

As there was a lot of confusion at first on the actual problem, I 
won't try to summarize the thread, because at different times, people 
probably had entirely different assumptions of the problem.

The bottom line is this: in very many cases you cannot avoid having to
insert some some kind of discard/reject or null0 route for a specific
prefix on a router (e.g., to generate a default route to some peers).  
When the next-hop of some other router, on that *same* router, goes
through that "discard" route, the next-hop is still considered valid.
This causes rather obvious BGP timeout problems.

The non-problem is when you have to redistribute that discard route in
your routing system, whether in IGP or BGP, and the other routers
cannot tell that's it's a discard route as it's learned through a 
routing protocol.  This can be rather easily avoided by configuring 
the discard routes everywhere, so I don't think this needs to be 
solved at this point.

Now.. what do people think about this problem -- what should we do 
(pick one or multiple):

 1) try to specify some behaviour in the bgp spec to avoid this issue; 
   for example:
  1.a) state that if the route towards the next-hop leads to packets 
being discarded by the router, SHOULD consider the next-hop ineligible
  1.b) state that the implementation SHOULD support being able to 
configure which routes to use in in the next-hop eligibility detection 
process
  1.c) to be worked out later..
  1.d) something else -- what?

 2) defer the solution until later

 3) clarify the operational problem, to make the reader/implementer 
aware of it
  3.a) in this revision of bgp spec
  3.b) in some other documents(s)

 4) other -- what ?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-implementation-00.txt
Sender: [email-masked]
Date: Thu, 11 Mar 2004 15:19:26 -0500

--NextPart

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

	Title		: BGP 4 Implementation Report
	Author(s)	: S. Hares
	Filename	: draft-ietf-idr-bgp-implementation-00.txt
	Pages		: 81
	Date		: 2004-3-11
	
This document provides a survey of the BGP-4 implementation draft-
   ietf-idr-bgp4-23.txt.  After a brief summary, each response is 
   listed. The editor makes no claim as to the accuracy of the 
   information provided.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp-implementation-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-route-filter-10.txt
Sender: [email-masked]
Date: Wed, 10 Mar 2004 15:42:03 -0500

--NextPart

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

	Title		: Cooperative Route Filtering Capability for BGP-4
	Author(s)	: E. Chen, Y. Rekhter
	Filename	: draft-ietf-idr-route-filter-10.txt
	Pages		: 11
	Date		: 2004-3-10
	
This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of route filters that the peer would
use to constrain/filter its outbound routing updates to the speaker.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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

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

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

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-route-filter-10.txt

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

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

--OtherAccess--

--NextPart--

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: [Idr] Experimental code-points
Sender: [email-masked]
Date: Wed, 10 Mar 2004 15:27:02 -0500

hi

I'd prefer something more explicit, but I guess I can live with the current
text.

Sharon

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]] 
Sent: Wednesday, March 10, 2004 2:03 AM
To: Wijnen, Bert (Bert)
Cc: Chisholm, Sharon [CAR:0S00:EXCH]; [email-masked]
Subject: Re: [Idr] Experimental code-points

OK.

Sharon, would this work for you?

-- 
Alex
http://www.psg.com/~zinin/

Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote:
> Yes.... I wonder why I did not see that ??
> Maybve I was too tired at end of IETF week.

> Thanks,
> Bert

>> -----Original Message-----
>> From: Alex Zinin [mailto:[email-masked]]
>> Sent: woensdag 10 maart 2004 7:45
>> To: Wijnen, Bert (Bert)
>> Cc: Sharon Chisholm; [email-masked]
>> Subject: Re: [Idr] Experimental code-points
>> 
>> 
>> Bert,
>> 
>>  Seems that the text already has it:
>> 
>> >    a) The code points must be from a space designated as "Standards
>> >       Action", amended by IESG approval to permit Early Allocation.
>>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>>  Does it do the job?
>> 
>> --
>> Alex
>> http://www.psg.com/~zinin/
>> 
>> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote:
>> > Aha ... good. For me that Covers it.
>> > But... it might be good to add that "IESG approval"
>> > into the list of "conditions" in sect 2 as well. 
>> > I bet people will often skip the intro and go straight to
>> > the "what are the conditions" section to see if they can
>> > request an early registration.
>> 
>> > Thanks,
>> > Bert
>> 
>> >> -----Original Message-----
>> >> From: Alex Zinin [mailto:[email-masked]]
>> >> Sent: woensdag 3 maart 2004 21:55
>> >> To: Wijnen, Bert (Bert)
>> >> Cc: Sharon Chisholm; [email-masked]
>> >> Subject: Re: [Idr] Experimental code-points
>> >> 
>> >> 
>> >> Bert, Sharon-
>> >> 
>> >>  The doc says:
>> >> 
>> >> >    This memo only addresses the early allocation of code
>> points from
>> >> >    spaces whose allocation policy is "Standards Action"
>> >> [2434] AND have
>> >> >    been amended to permit early allocation.  This
>> permission must be
>> >> >    granted by the IESG, and code spaces with permission for early
>> >> >    allocation must be marked as such in the IANA registry.
>> >> 
>> >>  In other words, it doesn't apply to an existing registry
>> >> unless IESG approves
>> >>  that this process is applicable. This leaves existing 
>> >> registries, OID included,
>> >>  intact unless someone takes an action.
>> >> 
>> >>  Is this good enough?
>> >>  
>> >> --
>> >> Alex
>> >> http://www.psg.com/~zinin/
>> >> 
>> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote:
>> >> > Good point. They can get an OID assigned in the
>> >> experimental branch though.
>> >>  
>> >> 
>> >> > Thanks,
>> >> > Bert
>> >> 
>> >> > -----Original Message-----
>> >> > From: Sharon Chisholm [mailto:[email-masked]]
>> >> > Sent: dinsdag 2 maart 2004 9:30
>> >> > To: [email-masked]
>> >> > Cc: Wijnen, Bert (Bert)
>> >> > Subject: RE: [Idr] Experimental code-points
>> >> 
>> >> 
>> >> 
>> >> > hi
>> >> 
>> >> > In looking through
>> >> >         
>> > 
> http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat
> ion-00.txt 
> <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-alloca
> tion-00.txt>

>>> I would suggest the following change to address my concern that it 
>>> inappropriately sets the expectation that MIB OIDs will be 
>>> pre-allocated.

>>> In either the 'Introduction' or in the section 'Conditions for Early 
>>> Allocation' the following text needs to be added.

>>> 'Note that under no condition will MIB Object Identifiers (OIDs) be 
>>> allocated before the RFC is published.'

>>> Sharon

>>> -----Original Message-----
>>> From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
>>> Sent: Monday, March 01, 2004 3:11 AM 
>>> To: [email-masked] 
>>> Subject: [Idr] Experimental code-points 

>>> As I mentioned, RFC 3692 described experimental allocations. Please
check if it's applicable. 

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: Sharon Chisholm <[email-masked]>, [email-masked]
Subject: Re: [Idr] Experimental code-points
Sender: [email-masked]
Date: Tue, 9 Mar 2004 23:02:52 -0800

OK.

Sharon, would this work for you?

-- 
Alex
http://www.psg.com/~zinin/

Tuesday, March 9, 2004, 6:54:03 PM, Wijnen, Bert (Bert) wrote:
> Yes.... I wonder why I did not see that ?? 
> Maybve I was too tired at end of IETF week.

> Thanks,
> Bert 

>> -----Original Message-----
>> From: Alex Zinin [mailto:[email-masked]]
>> Sent: woensdag 10 maart 2004 7:45
>> To: Wijnen, Bert (Bert)
>> Cc: Sharon Chisholm; [email-masked]
>> Subject: Re: [Idr] Experimental code-points
>> 
>> 
>> Bert,
>> 
>>  Seems that the text already has it:
>> 
>> >    a) The code points must be from a space designated as "Standards
>> >       Action", amended by IESG approval to permit Early Allocation.
>>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> 
>>  Does it do the job?
>> 
>> -- 
>> Alex
>> http://www.psg.com/~zinin/
>> 
>> Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote:
>> > Aha ... good. For me that Covers it.
>> > But... it might be good to add that "IESG approval" 
>> > into the list of "conditions" in sect 2 as well. 
>> > I bet people will often skip the intro and go straight to
>> > the "what are the conditions" section to see if they can
>> > request an early registration.
>> 
>> > Thanks,
>> > Bert 
>> 
>> >> -----Original Message-----
>> >> From: Alex Zinin [mailto:[email-masked]]
>> >> Sent: woensdag 3 maart 2004 21:55
>> >> To: Wijnen, Bert (Bert)
>> >> Cc: Sharon Chisholm; [email-masked]
>> >> Subject: Re: [Idr] Experimental code-points
>> >> 
>> >> 
>> >> Bert, Sharon-
>> >> 
>> >>  The doc says:
>> >> 
>> >> >    This memo only addresses the early allocation of code 
>> points from
>> >> >    spaces whose allocation policy is "Standards Action" 
>> >> [2434] AND have
>> >> >    been amended to permit early allocation.  This 
>> permission must be
>> >> >    granted by the IESG, and code spaces with permission for early
>> >> >    allocation must be marked as such in the IANA registry.
>> >> 
>> >>  In other words, it doesn't apply to an existing registry 
>> >> unless IESG approves
>> >>  that this process is applicable. This leaves existing 
>> >> registries, OID included,
>> >>  intact unless someone takes an action.
>> >> 
>> >>  Is this good enough?
>> >>  
>> >> -- 
>> >> Alex
>> >> http://www.psg.com/~zinin/
>> >> 
>> >> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote:
>> >> > Good point. They can get an OID assigned in the 
>> >> experimental branch though.
>> >>  
>> >> 
>> >> > Thanks,
>> >> > Bert 
>> >> 
>> >> > -----Original Message-----
>> >> > From: Sharon Chisholm [mailto:[email-masked]]
>> >> > Sent: dinsdag 2 maart 2004 9:30
>> >> > To: [email-masked]
>> >> > Cc: Wijnen, Bert (Bert)
>> >> > Subject: RE: [Idr] Experimental code-points
>> >> 
>> >> 
>> >> 
>> >> > hi 
>> >> 
>> >> > In looking through 
>> >> >         
>> > 
> http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt>  

>>> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

>>> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 

>>> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' 

>>> Sharon 

>>> -----Original Message----- 
>>> From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
>>> Sent: Monday, March 01, 2004 3:11 AM 
>>> To: [email-masked] 
>>> Subject: [Idr] Experimental code-points 

>>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. 

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: Sharon Chisholm <[email-masked]>, [email-masked]
Subject: Re: [Idr] Experimental code-points
Sender: [email-masked]
Date: Tue, 9 Mar 2004 15:44:33 -0800

Bert,

 Seems that the text already has it:

>    a) The code points must be from a space designated as "Standards
>       Action", amended by IESG approval to permit Early Allocation.
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 Does it do the job?

-- 
Alex
http://www.psg.com/~zinin/

Saturday, March 6, 2004, 5:01:34 AM, Wijnen, Bert (Bert) wrote:
> Aha ... good. For me that Covers it.
> But... it might be good to add that "IESG approval" 
> into the list of "conditions" in sect 2 as well. 
> I bet people will often skip the intro and go straight to
> the "what are the conditions" section to see if they can
> request an early registration.

> Thanks,
> Bert 

>> -----Original Message-----
>> From: Alex Zinin [mailto:[email-masked]]
>> Sent: woensdag 3 maart 2004 21:55
>> To: Wijnen, Bert (Bert)
>> Cc: Sharon Chisholm; [email-masked]
>> Subject: Re: [Idr] Experimental code-points
>> 
>> 
>> Bert, Sharon-
>> 
>>  The doc says:
>> 
>> >    This memo only addresses the early allocation of code points from
>> >    spaces whose allocation policy is "Standards Action" 
>> [2434] AND have
>> >    been amended to permit early allocation.  This permission must be
>> >    granted by the IESG, and code spaces with permission for early
>> >    allocation must be marked as such in the IANA registry.
>> 
>>  In other words, it doesn't apply to an existing registry 
>> unless IESG approves
>>  that this process is applicable. This leaves existing 
>> registries, OID included,
>>  intact unless someone takes an action.
>> 
>>  Is this good enough?
>>  
>> -- 
>> Alex
>> http://www.psg.com/~zinin/
>> 
>> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote:
>> > Good point. They can get an OID assigned in the 
>> experimental branch though.
>>  
>> 
>> > Thanks,
>> > Bert 
>> 
>> > -----Original Message-----
>> > From: Sharon Chisholm [mailto:[email-masked]]
>> > Sent: dinsdag 2 maart 2004 9:30
>> > To: [email-masked]
>> > Cc: Wijnen, Bert (Bert)
>> > Subject: RE: [Idr] Experimental code-points
>> 
>> 
>> 
>> > hi 
>> 
>> > In looking through 
>> >         
> http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt>  

>> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

>> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 

>> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' 

>> Sharon 

>> -----Original Message----- 
>> From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
>> Sent: Monday, March 01, 2004 3:11 AM 
>> To: [email-masked] 
>> Subject: [Idr] Experimental code-points 

>> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. 

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Susan Hares" <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] FW: IDR minutes
Sender: [email-masked]
Date: Tue, 9 Mar 2004 15:13:26 -0800

Sue-

Some corrections below, please.

Monday, March 1, 2004, 7:40:23 PM, Susan Hares wrote:
[...]
> 4) BGP Peer Restart Backoff Mechanisms [10 minutes]

>         document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update)

>         Author: Susan Hares
>         Presentation    Sue Hares

>         - Alex:         draft should say informational

Change to "the draft says it's an RFC, shouldn't do that"

>                         achieve functionality using existing states?

>         - Sue:          no... can't use existing states; already
>                         investigated that option

> 5) Deterministic Route Redistribution into BGP [10 minutes]

>         document: draft-chen-bgp-redist-00.txt

>         Authors: Jenny Yuan, Enke Chen
>         Enke Chen

>         - Andrew Lang:  used to use configured localpref tweaking; not
>                         management intensive... unsure if this is needed

>         - Enke:         timing dependent non-deterministic problem so
>                         current knobs cannot be used reliably; does not
>                         break anything... backwards compatible

>         - Andrew Lang:  better to educate people about localpref

>         - Barry Friedman:       lacks generality too narrow a problem
>                                 space... only addresses RIP/iBGP interaction

>         - Enke:         tweaking of admin distance defines a baseline

>         -               need per route granularity to solve for all cases? 
>                         Possibility of adding more configuration conflicts.

>         - Alex:         this problem only occurs if there's a consistancy
>                         issue between two places...  May not be an issue for
>                         a single selection point.

Change to:

the problem occurs if a router has to select best routes in two places: as in
the draft--once in BGP and once in the routing table, and the decisions are not
consistent. wonder if the problem still exists if an implementation selects best
paths in one place only, e.g. gated?. if so, is the problem
implementation-specific, not to mean it shouldn't resolved. Alex sent an e-mail
to the list with more details.

> 8) BGP Attribute Codes and Suggested Procedures

>         Document: draft-kompella-zinin-early-allocation-00.txt

>         Author: Alex Zinin, Kireeti Kompella
>         Presentation    Alex Zinin

>         - Sharon:       talking about protocols and not OIDs preallocation? 
>                         bad to preallocate in the MIB... different from what
>                         other WGs; exclude MIB OIDs

>         - Kireeti:      not suggesting that everyone use this

>         -               It would have been nicer to have had OIDs
>                         preallocated so as not to reimpliment the MIB
        
>         - Sharon:       OIDs not allocated to drafts because if the drafts
>                         goes away then you've wasted numbers

>         - Lou Berger:   allocation with 1 year with 1 renewal is too short;
>                         alterntate policy: as long as draft or version is
>                         alive, expire in 3 to 6 months

>         - Alex:         that suggestion ties validity with ability of author
>                         to submit the draft; suggestion: once document is
>                         submitted to IESG then we freeze.  Don't want to
>                         allocate codepoints too early.

>         - Dave Meyer:   Are you sure that IANA can time anything out

>         - Alex:         No

Change to:
No, that's why the drafts asks the WG chairs to keep track of the timers.

>         - Dave Meyer:   WG chair needs to manage this?

I think Dave asked if the WG chairs will need to maintain their own, parallel
registry to maintain this.

Alex: if IANA registry includes all info necessary, such as time of allocation,
responsible WG, etc., then it should be a matter of periodically looking through
the IANA registries.

>         -               What happens if the allocation is not renewed and
>                         code is using it still?

>         - Alex:         Add provision to document to deprecate but not return

Change to: the document allows to deprecate, but not return

>         - Kireeti:      Deprecate for a period of time to give people time
>                         to remove.  Formal process to do early allocations
>                         and if it goes through then stick with it but if it
>                         doesn't go through then people must take this out.

>         - Dino:         Allocate experimental codepoints and once
>                         standardised, then adopt standard codepoint for
>                         sending but accept both.

>         - Sue:          Good for SAFIs as well as AFIs?

>         - Dino:         All well known IANA values

>         - Fenner:       RFC already documents a process for transitioning
>                         codepoints

Thanks.
Alex

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Alex Zinin <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
Cc: Sharon Chisholm <[email-masked]>, [email-masked]
Subject: RE: [Idr] Experimental code-points
Sender: [email-masked]
Date: Sat, 6 Mar 2004 14:01:34 +0100

Aha ... good. For me that Covers it.
But... it might be good to add that "IESG approval" 
into the list of "conditions" in sect 2 as well. 
I bet people will often skip the intro and go straight to
the "what are the conditions" section to see if they can
request an early registration.

Thanks,
Bert 

> -----Original Message-----
> From: Alex Zinin [mailto:[email-masked]]
> Sent: woensdag 3 maart 2004 21:55
> To: Wijnen, Bert (Bert)
> Cc: Sharon Chisholm; [email-masked]
> Subject: Re: [Idr] Experimental code-points
> 
> 
> Bert, Sharon-
> 
>  The doc says:
> 
> >    This memo only addresses the early allocation of code points from
> >    spaces whose allocation policy is "Standards Action" 
> [2434] AND have
> >    been amended to permit early allocation.  This permission must be
> >    granted by the IESG, and code spaces with permission for early
> >    allocation must be marked as such in the IANA registry.
> 
>  In other words, it doesn't apply to an existing registry 
> unless IESG approves
>  that this process is applicable. This leaves existing 
> registries, OID included,
>  intact unless someone takes an action.
> 
>  Is this good enough?
>  
> -- 
> Alex
> http://www.psg.com/~zinin/
> 
> Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote:
> > Good point. They can get an OID assigned in the 
> experimental branch though.
>  
> 
> > Thanks,
> > Bert 
> 
> > -----Original Message-----
> > From: Sharon Chisholm [mailto:[email-masked]]
> > Sent: dinsdag 2 maart 2004 9:30
> > To: [email-masked]
> > Cc: Wijnen, Bert (Bert)
> > Subject: RE: [Idr] Experimental code-points
> 
> 
> 
> > hi 
> 
> > In looking through 
> >         
http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt>  

> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 

> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' 

> Sharon 

> -----Original Message----- 
> From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, March 01, 2004 3:11 AM 
> To: [email-masked] 
> Subject: [Idr] Experimental code-points 

> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. 

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: [Idr] Experimental code-points
Sender: [email-masked]
Date: Wed, 3 Mar 2004 19:17:39 -0500

hi

My concern is that this is opening us up to even more queries for premature
OID assignment, for which we are most likely going to say they need to wait
for the RFC. It's a matter of cutting off a frequently asked question by
having clear text in the draft that properly sets expectations. People may
reason that if Foo qualifies then the Foo MIB does, so I'd like to see some
text in the document that will make it more clear that this isn't the case. 

Perhaps a middle ground would be to add text indicating that early
allocation of code points for the protocol is independent of the MIB OID
allocation, or something along those lines.

Sharon

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]] 
Sent: Wednesday, March 03, 2004 7:55 AM
To: Wijnen, Bert (Bert)
Cc: Chisholm, Sharon [CAR:0S00:EXCH]; [email-masked]
Subject: Re: [Idr] Experimental code-points

Bert, Sharon-

 The doc says:

>    This memo only addresses the early allocation of code points from
>    spaces whose allocation policy is "Standards Action" [2434] AND have
>    been amended to permit early allocation.  This permission must be
>    granted by the IESG, and code spaces with permission for early
>    allocation must be marked as such in the IANA registry.

 In other words, it doesn't apply to an existing registry unless IESG
approves  that this process is applicable. This leaves existing registries,
OID included,  intact unless someone takes an action.

 Is this good enough?
 
-- 
Alex
http://www.psg.com/~zinin/

Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote:
> Good point. They can get an OID assigned in the experimental branch 
> though.

> Thanks,
> Bert

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: dinsdag 2 maart 2004 9:30
> To: [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: [Idr] Experimental code-points

> hi

> In looking through 
>         
> http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocat
> ion-00.txt 
> <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-alloca
> tion-00.txt>

> I would suggest the following change to address my concern that it 
> inappropriately sets the expectation that MIB OIDs will be 
> pre-allocated.

> In either the 'Introduction' or in the section 'Conditions for Early 
> Allocation' the following text needs to be added.

> 'Note that under no condition will MIB Object Identifiers (OIDs) be 
> allocated before the RFC is published.'

> Sharon

> -----Original Message-----
> From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, March 01, 2004 3:11 AM 
> To: [email-masked] 
> Subject: [Idr] Experimental code-points 

> As I mentioned, RFC 3692 described experimental allocations. Please check
if it's applicable. 

To: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20]
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Wed, 03 Mar 2004 14:08:35 -0800

Folks,

Let me propose that those who think that the base spec should be
changed please get together and propose a *specific* replacement
text, *taking into account* all the comments on this topic
that have been posted to the list over the last few days (as well
as the past discussion on this topic).

Yakov.

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
CC: Sharon Chisholm <[email-masked]>, [email-masked]
Subject: Re: [Idr] Experimental code-points
Sender: [email-masked]
Date: Wed, 3 Mar 2004 21:54:38 +0900

Bert, Sharon-

 The doc says:

>    This memo only addresses the early allocation of code points from
>    spaces whose allocation policy is "Standards Action" [2434] AND have
>    been amended to permit early allocation.  This permission must be
>    granted by the IESG, and code spaces with permission for early
>    allocation must be marked as such in the IANA registry.

 In other words, it doesn't apply to an existing registry unless IESG approves
 that this process is applicable. This leaves existing registries, OID included,
 intact unless someone takes an action.

 Is this good enough?
 
-- 
Alex
http://www.psg.com/~zinin/

Wednesday, March 3, 2004, 2:38:26 PM, Wijnen, Bert (Bert) wrote:
> Good point. They can get an OID assigned in the experimental branch though.

> Thanks,
> Bert 

> -----Original Message-----
> From: Sharon Chisholm [mailto:[email-masked]]
> Sent: dinsdag 2 maart 2004 9:30
> To: [email-masked]
> Cc: Wijnen, Bert (Bert)
> Subject: RE: [Idr] Experimental code-points

> hi 

> In looking through 
>         http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt>  

> I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

> In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 

> 'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' 

> Sharon 

> -----Original Message----- 
> From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
> Sent: Monday, March 01, 2004 3:11 AM 
> To: [email-masked] 
> Subject: [Idr] Experimental code-points 

> As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. 

From: "Wijnen, Bert (Bert)" <[email-masked]>
To: Sharon Chisholm <[email-masked]>, [email-masked]
Cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: [Idr] Experimental code-points
Sender: [email-masked]
Date: Wed, 3 Mar 2004 06:38:26 +0100

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_01C400E1.BFB30A80
Content-Type: text/plain

Good point. They can get an OID assigned in the experimental branch though.

Thanks,
Bert 

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]]
Sent: dinsdag 2 maart 2004 9:30
To: [email-masked]
Cc: Wijnen, Bert (Bert)
Subject: RE: [Idr] Experimental code-points

hi 

In looking through 
        http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt <http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt>  

I would suggest the following change to address my concern that it inappropriately sets the expectation that MIB OIDs will be pre-allocated.

In either the 'Introduction' or in the section 'Conditions for Early Allocation' the following text needs to be added. 

'Note that under no condition will MIB Object Identifiers (OIDs) be allocated before the RFC is published.' 

Sharon 

-----Original Message----- 
From: Alex Zinin [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Monday, March 01, 2004 3:11 AM 
To: [email-masked] 
Subject: [Idr] Experimental code-points 

As I mentioned, RFC 3692 described experimental allocations. Please check if it's applicable. 

-- 
Alex 
http://www.psg.com/~zinin/ <http://www.psg.com/~zinin/>  

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

------_=_NextPart_001_01C400E1.BFB30A80
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>RE: [Idr] Experimental code-points</TITLE>

<META content="MSHTML 6.00.2800.1106" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=880263904-03032004><FONT face=Arial color=#0000ff size=2>Good 
point. They can get an OID assigned in the experimental branch 
though.</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT size=2>Thanks,<BR>Bert </FONT></P>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Sharon Chisholm 
  [mailto:[email-masked]]<BR><B>Sent:</B> dinsdag 2 maart 2004 
  9:30<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> Wijnen, Bert 
  (Bert)<BR><B>Subject:</B> RE: [Idr] Experimental 
  code-points<BR><BR></FONT></DIV>
  <P><FONT size=2>hi</FONT> </P>
  <P><FONT size=2>In looking through</FONT> 
  <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT size=2><A 
  href="http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt" 
  target=_blank>http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00.txt</A></FONT> 
  </P>
  <P><FONT size=2>I would suggest the following change to address my concern 
  that it inappropriately sets the expectation that MIB OIDs will be 
  pre-allocated.</FONT></P>
  <P><FONT size=2>In either the 'Introduction' or in the section 'Conditions for 
  Early Allocation' the following text needs to be added.</FONT> </P>
  <P><FONT size=2>'Note that under no condition will MIB Object Identifiers 
  (OIDs) be allocated before the RFC is published.'</FONT> </P>
  <P><FONT size=2>Sharon</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Alex 
  Zinin [<A href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent: Monday, March 01, 2004 3:11 AM</FONT> <BR><FONT 
  size=2>To: [email-masked]</FONT> <BR><FONT size=2>Subject: [Idr] Experimental 
  code-points</FONT> </P><BR><BR>
  <P><FONT size=2>As I mentioned, RFC 3692 described experimental allocations. 
  Please check if it's applicable.</FONT> </P>
  <P><FONT size=2>-- </FONT><BR><FONT size=2>Alex</FONT> <BR><FONT size=2><A 
  href="http://www.psg.com/~zinin/" 
  target=_blank>http://www.psg.com/~zinin/</A></FONT> </P><BR>
  <P><FONT size=2>_______________________________________________</FONT> 
  <BR><FONT size=2>Idr mailing list</FONT> <BR><FONT size=2>[email-masked]</FONT> 
  <BR><FONT size=2><A href="https://www1.ietf.org/mailman/listinfo/idr" 
  target=_blank>https://www1.ietf.org/mailman/listinfo/idr</A></FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C400E1.BFB30A80--

content-class: urn:content-classes:message
Subject: RE: [Idr] FW: IDR minutes
From: "Susan Hares" <[email-masked]>
To: "Sharon Chisholm" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Wed, 3 Mar 2004 02:57:17 -0500

we'll add that.  We certainly did
talk about that!

sue

-----Original Message-----
From: Sharon Chisholm [mailto:[email-masked]]
Sent: Tuesday, March 02, 2004 8:31 PM
To: [email-masked]
Subject: RE: [Idr] FW: IDR minutes

hi

I believe we also briefly discussed setting up a call to discuss the v2 MIB
and that interested parties should contact either Sue or myself.

Sharon

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Monday, March 01, 2004 10:40 PM
To: [email-masked]
Subject: [Idr] FW: IDR minutes

Minutes for 3/1/04 session

-----Original Message-----
From: Jake Khuon 
Sent: Monday, March 01, 2004 3:18 AM
To: Susan Hares; [email-masked]
Subject: IDR minutes

Inter-Domain Routing WG (idr)

Monday, March 1 at 1530-1730
==================================

CHAIRS: Sue Hares ([email-masked])
	Yakov Rekhter ([email-masked])

AGENDA:

1) Agenda Bashing

	Agenda Slides

2) Document status [5 minutes]

	- Bundle went to IESG

	BGP-4 draft-23		draft-ietf-idr-bgp4-23.txt

	BGP-4 V1 MIB		draft-ietf-idr-bgp4-mib-13.txt

	BGP-4 Protocol Analysis		draft-ietf-idr-bgp-analysis-04.txt

	BGP Security Vulnerabilities Analysis
	draft-ietf-idr-bgp-vuln-00.txt

	Experience with the BGP-4 Protocol
	draft-ietf-idr-bgp4-experience-protocol-03.txt

	BGP 4 Implementation Report
	draft-ietf-idr-bgp-implementation-00.txt

	BGP-4 V1 MIB implementation report
	draft-ietf-idr-bgp-mibagent-survey-01.txt
	Presentation

3) Implementation Reports and FSM issues for current drafts [10 minutes]

	document: None, presentation only
	Presentation	Sue Hares

	- Yakov:	route-reflector update status?

	- Enke:		route-reflector update (4 weeks)

	- Enke:		prefix-orf was not added to charter

	- Sue:		yes it was added, administrative error in listing

4) BGP Peer Restart Backoff Mechanisms [10 minutes]

	document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update)

	Author: Susan Hares
	Presentation	Sue Hares

	- Alex:		draft should say informational
			achieve functionality using existing states?

	- Sue:		no... can't use existing states; already
			investigated that option

5) Deterministic Route Redistribution into BGP [10 minutes]

	document: draft-chen-bgp-redist-00.txt

	Authors: Jenny Yuan, Enke Chen
	Enke Chen

	- Andrew Lang: 	used to use configured localpref tweaking; not
			management intensive... unsure if this is needed

	- Enke:		timing dependent non-deterministic problem so
			current knobs cannot be used reliably; does not
			break anything... backwards compatible

	- Andrew Lang:	better to educate people about localpref

	- Barry Friedman:	lacks generality too narrow a problem
				space... only addresses RIP/iBGP interaction

	- Enke:		tweaking of admin distance defines a baseline

	- 		need per route granularity to solve for all cases? 
			Possibility of adding more configuration conflicts.

	- Alex:		this problem only occurs if there's a consistency
			issue between two places...  May not be an issue for
			a single selection point.

			Introduction of new step will effect current
			deployment traffic selection?

	- Enke:		This will happen regardless.

			Should not effect current deployments and if there's
			a change, the change will be for the better.

	-		By definition, it does change behavior.

	- Alex:		Will this be applicable to only situations where
			there is a problem?

	- Yakov:	Is this an implementation method?

	- Alex:		Is this informational or standards-track?

	- Enke:		Either is fine

	- 		It can't be a local matter because it must be
			consistent throughout the entire system

	- Enke:		Decision on redistributed routes is made locally in
			each router

	-		Behavior is changed because new code now uses admin
			distance over localpref?

	- Enke:		If only localpref is used then things should not
change

	- Cengiz:	If route-reflector is used?

	- Enke:		I need to think about it further

6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes]

	document: draft-hlmu-l2vpn-bgp-discovery-00.txt

	authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares
	Presentation	Sue Hares, P. Unbehagen

	-		Already a L2VPN draft that addresses this in a
defined
			NLRI with label information

	- Paul:		This draft is meant to provide LDP pseudowire config
			information

	- 		Other spec can do same thing [autodiscovery] without
label
			information

	- Kireeti:	Would like to be able to use this AFI with different
			SAFI [65] and NLRI format

	- 		Would the two SAFIs be solving similar problems

	- Kireeti:	My SAFI solves different problems

7) BGP Assignment of AFI/SAFI address [10 minutes]

	Document: draft-hares-bgp-assign-afisafi-00.txt 

	Author: Susan Hares
	Presentation	Sue Hares

8) BGP Attribute Codes and Suggested Procedures

	Document: draft-kompella-zinin-early-allocation-00.txt

	Author: Alex Zinin, Kireeti Kompella
	Presentation	Alex Zinin

	- Sharon:	talking about protocols and not OIDs preallocation? 
			bad to preallocate in the MIB... different from what
			other WGs; exclude MIB OIDs

	- Kireeti:	not suggesting that everyone use this

	- 		It would have been nicer to have had OIDs
			preallocated so as not to reimpliment the MIB
	
	- Sharon:	OIDs not allocated to drafts because if the drafts
			goes away then you've wasted numbers

	- Lou Berger:	allocation with 1 year with 1 renewal is too short;
			alterntate policy: as long as draft or version is
			alive, expire in 3 to 6 months

	- Alex:		that suggestion ties validity with ability of author
			to submit the draft; suggestion: once document is
			submitted to IESG then we freeze.  Don't want to
			allocate codepoints too early.

	- Dave Meyer:	Are you sure that IANA can time anything out

	- Alex:		No

	- Dave Meyer:	WG chair needs to manage this?

	-		What happens if the allocation is not renewed and
			code is using it still?

	- Alex:		Add provision to document to deprecate but not
return

	- Kireeti:	Deprecate for a period of time to give people time
			to remove.  Formal process to do early allocations
			and if it goes through then stick with it but if it
			doesn't go through then people must take this out.

	- Dino:		Allocate experimental codepoints and once
			standardised, then adopt standard codepoint for
			sending but accept both.

	- Sue:		Good for SAFIs as well as AFIs?

	- Dino:		All well known IANA values

	- Fenner:	RFC already documents a process for transitioning
			codepoints

9) Charter Discussion [20 minutes]

	Thanks to all implementers who send in reports on the base
	specification, we will be opening the charter. This section of the
meeting
	will discuss what items will be added to the charter.
	Presentation

	-		Top three most important; maybe ECMP little higher
than Fault Isolation
--
/*==================[ Jake Khuon <[email-masked]> ]=====================+
 | Field App. Engineer    http://www.nexthop.com/  /\  /~ E  X  T  H  O  P |
 | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772  /  \/  Technologies, Inc.|
+==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/

From: Andrew Lange <[email-masked]>
To: [email-masked]
Subject: [Idr] Charter Add - Flexible BGP Communities
Sender: [email-masked]
Date: Tue, 02 Mar 2004 23:18:52 -0800

--==========F9F1C055D554AA970B14==========
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Hello all,

I'd like to add the attached BGP Flexible Communities draft as a wg draft 
(it should show up in the drafts repository after the meeting).  I 
presented on this at both Yokohama and San Francisco.  The feedback was 
generally that this was an idea that should be adopted by the wg and 
considered further.

Thanks,

Andrew
--==========F9F1C055D554AA970B14==========
Content-Type: text/plain; charset=us-ascii;
 name="draft-lange-flexible-bgp-communities-02.txt"
Content-Disposition: attachment;
 filename="draft-lange-flexible-bgp-communities-02.txt"; size=36430
Content-Transfer-Encoding: 7bit

Internet Engineering Task Force                                 A. Lange
INTERNET DRAFT                                                   Alcatel
                                                              March 2004
                                                  Expires September 2004

                        Flexible BGP Communities
             <draft-lange-flexible-bgp-communities-02.txt>

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

   This document defines a new attribute for BGP called the Flexible
   Community attribute.  Flexible Communities build on the experience
   and utility of the standard BGP community, and the extended BGP
   community attributes.  This attribute allows operators to associate
   structured information with a route or set of routes.  This
   information can be then be used to execute routing policy.  An
   enhanced version of communities is necessary to accommodate IPv6,
   4-byte ASN's, and introduce a more extensible and flexible policy
   expression.  This document also introduces the concept of Neighbor
   Classes.  A Neighbor Class is applied to a group of BGP neighbors who
   share certain attributes.  For example, the PEER Neighbor Class could
   be applied to BGP sessions between ASN X and other networks with
   which ASN X has a non-transit peering relationship.

Lange                                                           [Page 1]

INTERNET DRAFT                                             December 2002

Table of Contents
   Status of this Memo.........................................   1
   Abstract....................................................   1
   1.  Introduction............................................   2
   2.  The BGP Flexible Community Attribute....................   3
   2.1  Transitivity Field.....................................   4
   2.2  Structure Field........................................   4
   2.3  Type Field.............................................   5
   2.4  Originating ASN Field..................................   5
   2.5  Length Field...........................................   6
   3.  Locally Defined Structures and Types....................   6
   4.  Neighbor Classes........................................   6
   4.1  Locally Defined Neighbor Classes.......................   7
   4.2  Defined Neighbor Classes...............................   8
   5.  Defined Flexible BGP Community Structures...............   9
   6.  Base BGP Flexible Community Type (Opaque Type)..........  10
   7.  Defined Flexible BGP Community Types....................  10
   7.1  NO_EXPORT..............................................  10
   7.2  ONLY_EXPORT............................................  11
   7.3  ANNOUNCE_WITH..........................................  12
   7.4  PREPEND................................................  13
   7.5  The BGP VPN Communities................................  13
   8.  New Capability Code for Flexible Communities............  14
   9.  Aggregation.............................................  14
   10. Operations..............................................  15
   11. Security Considerations.................................  15
   12. IANA Considerations.....................................  16
   13. References..............................................  16
   14. Acknowledgements........................................  17
   15. Author's Address........................................  17

Specification of Requirements

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

1. Introduction

   This attribute represents the third generation of the BGP community
   attribute.  The first generation is documented in RFC1997 [RFC1997].
   The second generation, the extended community, is documented in EX-
   COMM [EX-COMM].

   The Flexible Community Attribute provides a number of important
   enhancements over the existing BGP Community Attribute and BGP
   Extended Community Attribute.  These enhancements are:

Lange                                                           [Page 2]

INTERNET DRAFT                                             December 2002

     - Support for IPv6.
     - More efficient encoding of lists of data, for example, a list of
     ASN's.
     - Clean support for a broad range of future data field structures
     and interpretations.
     - Support for locally defined community structures, and
     interpretations.
     - Easy extensibility for a range of future applications.

   The continuation and expansion of the structure introduced with
   Extended Communities allows for policy based on the application where
   the community is being used.  The separation of structure and
   interpretation allows for easier machine and human parsing of
   community types which do the same thing with slightly different
   input.

   This attribute continues the use of the Transitivity community bit,
   first introduced in the Extended Community Attribute.

   We also define a set of well-known values for this attribute which
   can be used to replicate and extend the functionality of the existing
   well-known community values.

   The concept of Neighbor Classes is introduced.  A Neighbor Class is
   defined on a BGP peering session.  It allows neighbors that share a
   set of administrative attributes to be easily grouped together.
   Policy can then be defined through Flexible Communities in reference
   to these groupings.

2. The BGP Flexible Community Attribute

   The Flexible Community Attribute is a transitive optional BGP
   attribute with a Type Code of <TBD>.  The attribute consists of a
   list of "flexible communities."

   Each Flexible Community is encoded as a variable length quantity.
   The encoding scheme is:

     - Transitivity Field: 1 bit
     - Structure Field: 7 bits
     - Type Field: 2 octets
     - Length Field: 1 octet
     - Value Field: 0-255 octets

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|   Struct.   |             Type              |  Originating  |

Lange                                                           [Page 3]

INTERNET DRAFT                                             December 2002

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      ASN                      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Value Field  (0-255 octets)                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1. Transitivity Field:

   The Transitivity Field is one bit.  It can take the following values:

   Value 0: The community is transitive across ASes

   Value 1: The community is non-transitive across ASes

   It is important to note that the transitivity defined by this field
   is different from the general transitivity of a BGP attribute.  A
   single Flexible Community Attribute, can contain multiple Flexible
   Communities, each of which may or may not be transitive.  If a route
   originates in an AS with the transitivity bit set, indicating that
   the community is non-transitive, then that AS MUST NOT propagate that
   community to its peers.  However, if a community with the transitive
   bit set is applied on an outbound policy expression (e.g., a route-
   map), the community will be conveyed to the immediately adjacent
   peer.  That peer, in turn, will NOT propagate the community to its
   peers.  The one exception to this is as-confederations.  For the
   purposes of this attribute, confederation boundaries should be
   treated the same as IBGP.     In other words, non-transitive flexible
   communities should be propagated to other members of the as-
   confederation, unless overridden by local policy.

   If the community is transitive, then the Value Field MUST contain the
   originating ASN.  This ASN is encoded as a 4-octet value, occupying
   the first 4 octets of the Value Field.  Two-octet ASN numbers are
   padded out to 4 octets.  Any additional information in the Value
   Field comes after this origin ASN data.

2.2. Structure Field:

   The Structure Field's contents modify the Type Field.  For example, a
   Flexible Community which specifies SPECIFIC_NO_EXPORT in its Type
   Field, can be modified by the contents of the Structure Field to let
   the receiver know if the list of data on which it must act is a list
   of 2 octet or 4 octet ASNs.  A set of commonly used Structure values
   is defined later in this document.

   The Structure field is the latter 7 bits of the first octet.  It is
   split into two sub-fields.

Lange                                                           [Page 4]

INTERNET DRAFT                                             December 2002

        0
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |T|L|  Struct.  |
       +-+-+-+-+-+-+-+-+

   L - Local bit

   The Local bit can take two values:

     Value 0: The Structure is Locally Defined.

     Value 1: The Structure is Well Known.

2.3. Type Field:

   The Type Field is two octets.  This contents of this field are used
   to define an action for the recipient to take on the route, or to
   define and attribute that is related to that route.  An example of
   the former would be a Type which requests that a route be
   ONLY_EXPORTed to a specific set of peers.  An example of the latter
   would be a Type that defines the LINK_BANDWIDTH associated with a
   certain NLRI.

   Like the Structure Field the Type Field is split into two Sub-Fields:

            1                   2
        8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|            Type             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Local bit can take two values:

       Value 0: The Type is Locally Defined.

       Value 1: The Type is Well Known.

   An implementation MUST allow an operator to filter out entire Types
   of Flexible Communities from their peering sessions if they so
   choose.

2.4 Originating ASN Field:

   This field contains the ASN that added the flexible community to the
   route.  It is 4 octets long.  In the case of a 2-byte ASN, the first
   2 octets are set to zero, as padding.

Lange                                                           [Page 5]

INTERNET DRAFT                                             December 2002

2.5. Length Field:

   The Length Field specifies the length, in octets, of the Value Field.

3. Locally Defined Structures and Types

   The Local bit allows the operator of the network to define Structures
   and Types that are relevant only within that ASN's boundaries.  The
   definition the term "local" used throughout this document is: "A
   value used by ad hoc agreement or convention outside the scope of
   standardization, which has meaning only between the parties using the
   Flexible Community in question."  This typically means that the Local
   value only has meaning within an AS or set of ASes controlled by a
   single entity.

   A Locally Defined Structure or Type will have a syntax for
   interpretation defined on the routers that need to interpret it.  If
   a router receives a community with a Locally Defined Structure or
   Type that it does not recognize, then it should ignore the contents
   and process the route based on the information in the route that it
   does understand.  This includes obeying the transitivity bit, in the
   Flexible Community.  If the community is set to non-transitive, even
   if the router does not understand the rest of the Structure or Type
   of the community, that community should not be forwarded outside the
   AS.

   In order to prevent collisions with other operators' Locally Defined
   values, Flexible Communities containing Locally Defined Structures or
   Types MUST be non-transitive (have their Transitivity Field set to
   1).

4. Neighbor Classes

   A Neighbor Class is a value which represents a certain class, or
   group, of BGP neighbors.  Each BGP peering session can be configured
   with zero or more Neighbor Classes.  This value will allow a general
   classification of what sort of relationship the BGP session
   represents.  With the sort of session defined, it becomes easier to
   apply policy to only that class of neighbors.  Neighbor Classes make
   the expression of policy through flexible communities much easier.
   There are a number of examples in the sections on defined values.

   Neighbor Classes can be used in two main ways.  First they can be
   used in a passive manner, where the configuration acts as a policy
   expression for communities matching it.  An example of this would be
   configuring a neighbor with the PEER neighbor class, and having a
   community that, say is set to NO_EXPORT for the NEIGHBOR CLASS PEER.
   In this configuration, all the neighbors that are configured as PEERs

Lange                                                           [Page 6]

INTERNET DRAFT                                             December 2002

   would match and filter out the route carrying the NO_EXPORT, NEIGHBOR
   CLASS PEER community.  This is the standard way of using neighbor
   classes.

   A second, optional, way to use Neighbor Classes would be to allow
   inbound community tagging.  In this usage, routes traversing the
   session would be automatically tagged with a flexible community with
   the appropriate neighbor class value.  This eases configuration.  To
   extend the example above, our neighbor designated PEER would add a
   community with NEIGHBOR CLASS PEER to routes traversing the BGP
   session.  This community could then be used further down the line to
   just announce PEER routes to a particular customer.  This usage is
   configurable on a per-neighbor basis.

   A Neighbor Class is encoded as a 2-octet value with 2 parts:

        0                   1
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |L|       Neighbor Class        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Local bit can take two values:

       Value 0: The Neighbor Class is Locally Defined.

       Value 1: The Neighbor Class is Well Known.

4.1. Locally Defined Neighbor Classes

   If a router receives a Flexible Community containing a Neighbor Class
   that it does not recognize, then it should ignore the contents and
   process the route based on the information in the route that it does
   understand.  If the Transitivity Field of the Flexible Community with
   the Locally Defined Structure or Type is set to 1 (the community is
   non-transitive) then the router MUST NOT forward the Flexible
   Community.  Similarly, if the Transitivity Field is set to 0 (the
   community is transitive) the router MUST forward the community along
   with the NLRI.

   Using Locally Defined Neighbor Classes an operator could easily
   define a set that is locally useful.  This set could be used in a
   flat name space, for example, one could say that "31" would be "Asian
   Public Peers", and "34" would be European Private Peers.

   Also, a given BGP Neighbor can be part of multiple Neighbor Classes.
   This would allow for a hierarchical or additive name space. For
   example, a neighbor could be part of both "PEER", and locally defined

Lange                                                           [Page 7]

INTERNET DRAFT                                             December 2002

   "ASIAN" and "PUBLIC PEER" Classes.  The logical matching
   functionality available is left implementation-dependent.  However,
   the default in such as case is logical OR functionality for matching
   this neighbor class.  In the case where routes are being tagged
   inbound, then by default a single community with all configured
   neighbor classes in a list is added.  Implementation dependent knobs
   are suggested to allow more fine grained control.

4.2. Defined Neighbor Classes

   This document defines Neighbor Class values for common BGP neighbor
   groupings:

   ALL NEIGHBORS

     This class is the default Neighbor Class for all BGP peers.

     This class is represented by a value of 0 (0x8000).

   PEER

     This class is typically applied to sessions where a transit-free
     relationship exists between the two providers.

     This class is represented by a value of 1 (0x8001).

   CUSTOMER

     This class is typically applied to sessions where the remote end of
     the session is operated by a customer.

     This class is represented by a value of 2 (0x8002).

   UPSTREAM

     This class is typically applied to sessions where the remote end of
     the session is operated by a network from which you receive transit
     routes.

     This class is represented by a value of 3 (0x8003).

   CONFEDERATION PEER

     This class is typically applied to sessions where the remote end of
     the session is part of a confederation.

     This class is represented by a value of 4 (0x8004).

Lange                                                           [Page 8]

INTERNET DRAFT                                             December 2002

5. Defined Flexible BGP Community Structures

   This section defines a number of Structure values which different
   Type values can inherit.

   Summary of the Defined Values:

    - opaque/variable (0x40 or 0xC0)
    - list of ASN's (0x41 or 0xC1)
    - list of IPv4 addresses (0x42 or 0xC2)
    - list of IPv6 addresses (0x43 or OxC3)
    - list of neighbor_classes (0x44 or 0xC4)

   Defined Structure can be transitive or non-transitive, they are well
   known.

   Opaque/Variable Structure

     This sort of structure defers interpretation of the community and
     value field to the Type value.  Typically this structure value will
     be used when the Type value does not have a lot of variations, but
     rather one structure for the Value Field.

     This structure is represented by the value 0x00.

   List of ASN's

     This structure value means that the Type Field's action is
     qualified by a list of ASN's, contained in the Value Field.  In the
     case of 2 byte ASN's the value is padded to 4 bytes by inserting 2
     octets worth of zeros in the leftmost portion of the value.

     This structure is represented by the value 0x01.

   List of IPv4 Addresses

     This structure value means that the Type Field's action is
     qualified by a list of IPv4 addresses, contained in the Value
     Field.

     This structure is represented by the value 0x02.

   List of IPv6 Addresses

     This structure value means that the Type Field's action is
     qualified by a list of IPv6 addresses, contained in the Value
     Field.

Lange                                                           [Page 9]

INTERNET DRAFT                                             December 2002

     This structure is represented by the value 0x03.

   List of Neighbor Classes

     This structure value means that the Type Field's action is
     qualified by a list of neighbor classes, contained in the Value
     Field.

     This structure is represented by the value 0x04.

6. Base BGP Flexible Community Type (Opaque Type)

   This section defines the base BGP community specification.  Since the
   root value of communities is the ability to tag a route with
   arbitrary information, and then create a system to give that
   information meaning, the base flexible community type (type 0), is
   very simple.  This base type could also be described as the "opaque
   type."  All actions can be replicated with a well-thought out,
   provider dependent, implementation of a scheme using this opaque
   type.

   Like all flexible communities, this type can be transitive or non-
   transitive.  This is a well known type.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   0x00,0xC0   |             0x0000            |  Originating  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      ASN                      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Value Field  (0-255 octets)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7. Defined Flexible BGP Community Types

   The Type Field specifies the subgroup that a set of communities
   belongs to.  Typically this subgroup represents an action to be taken
   on the data.  A variety of well-known Type Values follow.

7.1. NO_EXPORT

   This grouping of well-known communities specify a list of ASNs, Peer
   IPs, or Neighbor Classes NOT to announce a route to.

   Name: NO_EXPORT
   Type Code: 0x0001

Lange                                                          [Page 10]

INTERNET DRAFT                                             December 2002

   Can Take Structures:
     Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class)
   Transitive: Non-Transitive
   Min Length of Value Field: 2 octets
   Max Length of Value Field: 254 octets
   Behavior:
     All routes received with this community MUST NOT be advertised to
     the list of ASNs, Peer IPs, or Neighbor Classes contained in the
     Value Field.
   Notes:
     GLOBAL_NO_EXPORT is accomplished by sending a NO_EXPORT Flexible
     Community with the Neighbor Class of 0x00 (ALL NEIGHBORS).

     GLOBAL_NO_EXPORT's NO_EXPORT behavior is defined as:
       All routes received with this community MUST NOT be advertised
       outside a BGP confederation boundary (a stand-alone autonomous
       system that is not part of a confederation should be considered a
       confederation itself.)    [RFC1997]

     This is analogous to the NO_EXPORT community defined in [RFC1997].

7.2. ONLY_EXPORT

   This grouping of well-known communities specify a list of ASNs, Peer
   IPs, or Neighbor Classes to announce a route to.

   Name: ONLY_EXPORT
   Type Code: 0x0002
   Can Take Structures:
     Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class)
   Transitive: Non-Transitive
   Min Length of Value Field: 0 octets
   Max Length of Value Field: 254 octets
   Behavior:
     The Value Field contains a list of ASNs, neighbor IP addresses, or
     Neighbor Classes to which the route should be advertised.

     The default behavior of a route carrying this community is the same
     as the GLOBAL_NO_EXPORT behavior, except for the ASNs, IPs, or
     Neighbor Classes listed in the Value Field.
   Notes:
     This community can be used to replicate the NO_ADVERTISE
     functionality from [RFC1997].  To do so, simply announce
     ONLY_EXPORT with a Structure of 0x03 or 0x04 (one of the IP address
     Structures), but with no IP address in the list.  This will tell
     the receiving router that you wish to ONLY_EXPORT this route to NO
     peer IPs.

Lange                                                          [Page 11]

INTERNET DRAFT                                             December 2002

     This community can also be use to replicate the NO_EXPORT_SUBCONFED
     functionality from [RFC1997].  To do so, simply announce
     ONLY_EXPORT with a Neighbor Class of CONFEDERATION PEER (4,
     0x8004).  This will tell the receiving router that you wish to
     ONLY_EXPORT this route to Confederation Peers.

7.3. ANNOUNCE_WITH

   This group of well-known communities allows a network to announce a
   community to an ASN beyond those that it directly peers with,
   assuming its direct peers allow it to transit the community value.
   This community group has a lot of flexibility, and could be used to
   nest another ANNOUNCE_WITH community to gain reach greater than 2
   ASN-hops away.  If this is a good idea or not is unknown and is left
   to further study. The only theoretical restriction to the amount of
   nesting is that the community cannot exceed the maximum size for the
   Value Field.

   Since true transitivity can be obtained by simply setting a bit, this
   community is mainly useful for propagating NO_EXPORT or ONLY_EXPORT
   (which are non-transitive) to your neighbor's neighbors.

   In effect, this community, if allowed by the BGP neighbors in the
   chain, can be used for an originating network to very specifically
   control the distribution of its routes.  This community type does
   contain a LOT of rope, and should be used with care.  In the end,
   though, a mistake should only effect the person originating the
   route.

   Name: ANNOUNCE_WITH
   Type Code: 0x0003
   Can Take Structures:
     Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class)
   Transitive: Non-Transitive
   Min Length of Value Field: 8 octets
   Max Length of Value Field: 254 octets
   Behavior:
     This community's Value Field is split into two sections.
     - The first section is a variable length field that contains the
     full community value that you wish to announce.
     - The second section is a variable length field that contains the
     list of, ASN's, IP addresses, or neighbor_classes you wish to
     propagate this community to.  If you wish to propagate to all
     peers, use the ALL NEIGHBORS neighbor class.

     When a router receives this community value, it should strip the
     ANNOUNCE_WITH community and announce the underlying community value
     to its neighbor.

Lange                                                          [Page 12]

INTERNET DRAFT                                             December 2002

7.4. PREPEND

   This community can be used to ask a BGP peer to prepend its own ASN
   to its peers.

   Name: PREPEND
   Type Code: 0x0004
   Can Take Structures:
     Ox01 (ASN), 0x02 (IPv4), 0x03 (IPv6), 0x04 (neighbor-class)
   Transitive: Non-Transitive
   Min Length of Value Field: 3 octets
   Max Length of Value Field: 254 octets
   Behavior:
     This community has 2 sections:
     The first section:
       Is a one-octet value which specifies the number of times that the
       ASN should prepend its ASN.  It is recommended that operators
       constrain this value to no more than 3.  Implementations MUST
       offer the ability for an operator to set a maximum bound for this
       field.  The suggested default is also 3.
     The second section:
       Contains a list of ASNs, peer IPs, or Neighbor Classes to which
       the originator of this community wishes its peer to prepend its
       ASN.

7.5. The BGP VPN Communities

   These communities are used mostly for BGP MPLS VPN's.  Please see
   RFC2547 [RFC2547] for more detail on how these VPNs are constructed.

   Name: ROUTE_TARGET
   Type Code: 0x0005
   Can Take Structures:
     0x02 (IPv4), 0x03 (IPv6)
   Transitive: Transitive or Non-Transitive
   Min Length of Value Field: 4 octets
   Max Length of Value Field: 254 octets
   Behavior:
     The Value Field of this community represents a list of the IP
     addresses where this route is to be announced.

   Name: ROUTE_ORIGIN
   Type Code: 0x0006
   Can Take Structures:
     0x02 (IPv4), 0x03 (IPv6)
   Transitive: Transitive or Non-Transitive
   Min Length of Value Field: 4 octets
   Max Length of Value Field: 16 octets

Lange                                                          [Page 13]

INTERNET DRAFT                                             December 2002

   Behavior:
     The Value Field of this community represents a list of the IP
     address where this route is originated.  This community can only
     contain one IP address.

   Name: LINK_BANDWIDTH
   Type Code: 0x0007
   Can Take Structures:
     0x00 (opaque), Ox01 (ASN)
   Transitive: Transitive or Non-Transitive
   Min Length of Value Field: 4 octets
   Max Length of Value Field: 6 octets
   Behavior:
     This community consists of two parts:
     The first part represents the bandwidth of the link in bits-per-
     second, encoded in IEEE floating point format.     This part is 4
     octets long.

     The second part consists of a list of ASNs of the peer whose link
     bandwidth you wish to propagate.

8. New Capability Code for Flexible Communities

To ensure compatibility between implementations that may or may not
implement this protocol extension, this document defines a new
capability.

     Capability Code: TBD
     Capability Length: 1
     Capability Value: 0x00 for unsupported
                       0x01 for supported

   Capability negotiation is especially important for this attribute
   because we are creating a transitivity action within an optional,
   transitive attribute.  If an implementation sends a flexible
   community with the non-transitive bit set within the community to a
   router that does not support flexible communities, that router will
   send the community on to its peers when it should not do so.

9. Aggregation

   Aggregation behaves the same as with other community types.

   By default if a range of routes is to be aggregated and the resultant
   aggregates path attributes do not carry the ATOMIC_AGGREGATE
   attribute, then the resulting aggregate should have an Flexible
   Communities path attribute which contains the set union of all the
   Flexible Communities from all of the aggregated routes. The default

Lange                                                          [Page 14]

INTERNET DRAFT                                             December 2002

   behavior could be overridden via local configuration, in which case
   handling the Flexible Communities attribute in the presence of route
   aggregation becomes a matter of the local policy of the BGP speaker
   that performs the aggregation.

10. Operations

   Flexible Communities are handled operationally in a manner very
   similar to other community values.

   A BGP speaker may use the Flexible Communities attribute to control
   which routing information it accepts or distributes to its peers.

   The Flexible Community attribute MUST NOT be used to modify the BGP
   best path selection algorithm in a way that leads to forwarding
   loops.

   A BGP speaker receiving a route that doesn't have the Flexible Commu-
   nities attribute MAY append this attribute to the route when
   propagating it to its peers.

   A BGP speaker receiving a route with the Flexible Communities
   attribute MAY modify this attribute according to the local policy.
   If a route has a non-transitivity flexible community, then before
   advertising the route across the Autonomous system boundary the
   community SHOULD be removed from the route. However, the community
   SHOULD NOT be removed when advertising the route across the BGP
   Confederation boundary.

   A route may carry the BGP Communities attribute as defined in
   [RFC1997]), the Extended BGP Communities attribute as defined in [EX-
   COMM], and the Flexible Communities attribute. In this case the BGP
   Communities attribute is handled as specified in [RFC1997], the
   Extended BGP Communities attribute is handled as specified in [EX-
   COMM], and the Flexible Communities attribute is handled as specified
   in this document.

   If older community types are present in addition to the flexible
   community there is the possibility that the information contained may
   be redundant.  Although effort should be made to avoid this
   situation, if it does occur the BGP Speaker shall prefer the flexible
   community first, then the extended community second and then the base
   community.

11. Security Considerations

   This extension to BGP does not change the underlying security issues.

Lange                                                          [Page 15]

INTERNET DRAFT                                             December 2002

12. IANA Considerations

   The values for the Transitivity Field (1 or 0) are completely defined
   in this document.

   The assignment policy for the Structure Field is:
     o The "L" bit's usage is completely defined in this document.
     o Values of the Structure Field where the "L" bit is "0" are to be
     assigned in accordance with the Private Use policy outlined in
     RFC2434 [RFC2434].
     o Values of the Structure Field where the "L" bit is "1" defined in
     this document are: 0-4 (0x40-0x44 and 0xC1-0xC4).  Remaining values
     in this range are to be assigned using the IETF Consensus policy
     outlined in RFC2434 [RFC2434].

   The assignment policy for the Type Field is:
     o The "L" bit's usage is completely defined in this document.
     o Values of the Type Field where the "L" bit is "0" are to be
     assigned in accordance with the Private Use policy outlined in
     RFC2434 [RFC2434].
     o Values of the Type Field where the "L" but is "1" defined in this
     document are: 0-7 (0x0000-0x0007).  Remaining values in this range
     are to be assigned using the IETF Consensus policy outlined in
     RFC2434 [RFC2434].

   The assignment policy for Neighbor Classes is:
     o The "L" bit's usage is completely defined in this document.
     o Values of the Type Field where the "L" bit is "0" are to be
     assigned in accordance with the Private Use policy outlined in
     RFC2434 [RFC2434].
     o Values of the Type Field where the "L" but is "1" defined in this
     document are: 0-4 (0x8000-0x8004).  Remaining values in this range
     are to be assigned using the IETF Consensus policy outlined in
     RFC2434 [RFC2434].

13. References

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

   [RFC1997] Chandra, R., Traina, P., Li, T., "BGP Communities
   Attribute", RFC 1997, August 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an IANA
   Considerations Section in RFCs", RFC 2434, October 1998

Lange                                                          [Page 16]

INTERNET DRAFT                                             December 2002

   [RFC2547] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March
   1999.

   [RFC2842] Chandra, R., Scudder, J., "Capabilities Advertisement with
   BGP-4", RFC 2842, May 2000.

   [EX-COMM] Sangli, S., Tappan, D., Rekhter, Y., "BGP Extended
   Communities Attribute", draft-ietf-idr-bgp-ext-communities-05.txt,
   work-in-progress, expires November, 2002.

   [NOPEER] Huston, G., "NOPEER community for BGP route scope control",
   draft-ietf-ptomaine-nopeer-00.txt, work-in-progress, expires October,
   2002.

   [REDIST] Bonaventure, O., et. al., "Controlling the redistribution of
   BGP routes", draft-ietf-ptomaine-redistribution-01.txt, work-in-
   progress, expires February, 2003.

14. Acknowledgements
   I would like to thank Tom Barron, Dave Ward and especially Hal
   Peterson for their valuable comments and feedback.

15. Author's  Address:

   Andrew Lange
   Alcatel
   274 Ferguson Drive
   Mountain View, CA  94043
   [email-masked]

Lange                                                          [Page 17]


--==========F9F1C055D554AA970B14==========--

From: vijay gill <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 01 Mar 2004 23:05:03 -0500

--On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques 
<[email-masked]> wrote:

> vijay gill writes:
>
>> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote:
>>> Pekka Savola writes:
>>>
>>> i'll repeat it: - How can you prove that a given path that is
>>> learned by BGP is loop free ?  - That can only be done if
>>> forwarding follows routing.
>
>> I feel that BGP should only be concerned about creating loop free
>> topologies. If the user then has a mechanism where the forwarding
>> does not follow the routing properly and causes a loop (this is an
>> important distinction), then this is their problem. I can always
>> point a static back up a link if I so want and nothing bgp can do
>> about it.
>
> Your argument assumes that the user always knows that is configuring a
> situation that may create forwarding loops...
>
> That may not be the case. It may come from a configuration
> mistake...
>
> imho, the default approach for the protocol spec is to choose the most
> graceful failure model possible torwards loop-free forwarding...

Pedro, I still don't understand why BGP must care about statics or other 
protocols that may or may not be misconfigured. For some reason I may want 
to create a forwarding loop (for example, in my lab) to see what the router 
does. Actually, to be more specific, there are valid operational reasons 
for sometimes routing information away from where BGP points you, load 
balancing on congested peerings for example. Not very elegant, but these 
cases do exist. If a vendors BGP implementation does not allow me to have 
the final say as to where I want to place traffic, I _will_ be extremely 
irate.

>
>>>  Proof: configure a static route for a given prefix in a border
>>> router that points to a BGP neighbor that selects this router as
>>> best path... watch permanent forwarding loops.
>
>> Yes, and this is a not a matter for BGP to worry about.
>
> I respectfully disagree.

that is fine. but as we all know, the final arbiter of features is the 
account team, back up by P.O.s

/vijay

From: vijay gill <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 01 Mar 2004 23:32:08 -0500

--On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques 
<[email-masked]> wrote:

> vijay gill writes:
>
>> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote:
>>> Pekka Savola writes:
>>>
>>> i'll repeat it: - How can you prove that a given path that is
>>> learned by BGP is loop free ?  - That can only be done if
>>> forwarding follows routing.
>
>> I feel that BGP should only be concerned about creating loop free
>> topologies. If the user then has a mechanism where the forwarding
>> does not follow the routing properly and causes a loop (this is an
>> important distinction), then this is their problem. I can always
>> point a static back up a link if I so want and nothing bgp can do
>> about it.
>
> Your argument assumes that the user always knows that is configuring a
> situation that may create forwarding loops...
>
> That may not be the case. It may come from a configuration
> mistake...
>
> imho, the default approach for the protocol spec is to choose the most
> graceful failure model possible torwards loop-free forwarding...
>imho, the default approach for the protocol spec is to choose the most
>graceful failure model possible torwards loop-free forwarding...

Pedro, I still don't understand why BGP must care about statics or other
protocols that may or may not be misconfigured. For some reason I may want
to create a forwarding loop (for example, in my lab) to see what the router
does. Actually, to be more specific, there are valid operational reasons
for sometimes routing information away from where BGP points you, load
balancing on congested peerings for example. Not very elegant, but these
cases do exist. If a vendors BGP implementation does not allow me to have
the final say as to where I want to place traffic, I _will_ be extremely
irate.
If you only consider BGP, then it should do loop-free routing, absolutely. 
I just do not want BGP to be looking into static configurations and trying 
to do my thinking for me. This leads to anger and anger leads to the dark 
side. etc etc.

>
>>> Proof: configure a static route for a given prefix in a border
>>>router that points to a BGP neighbor that selects this router as
>>>best path... watch permanent forwarding loops.
>
>>Yes, and this is a not a matter for BGP to worry about.
>
>I respectfully disagree.

that is fine. but as we all know, the final arbiter of features is the
account team, backed up by P.O.s no matter what the IETF would like to 
believe.

/vijay

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Subject: RE: [Idr] FW: IDR minutes
Sender: [email-masked]
Date: Tue, 2 Mar 2004 20:31:14 -0500

hi

I believe we also briefly discussed setting up a call to discuss the v2 MIB
and that interested parties should contact either Sue or myself.

Sharon

-----Original Message-----
From: Susan Hares [mailto:[email-masked]] 
Sent: Monday, March 01, 2004 10:40 PM
To: [email-masked]
Subject: [Idr] FW: IDR minutes

Minutes for 3/1/04 session

-----Original Message-----
From: Jake Khuon 
Sent: Monday, March 01, 2004 3:18 AM
To: Susan Hares; [email-masked]
Subject: IDR minutes

Inter-Domain Routing WG (idr)

Monday, March 1 at 1530-1730
==================================

CHAIRS: Sue Hares ([email-masked])
	Yakov Rekhter ([email-masked])

AGENDA:

1) Agenda Bashing

	Agenda Slides

2) Document status [5 minutes]

	- Bundle went to IESG

	BGP-4 draft-23		draft-ietf-idr-bgp4-23.txt

	BGP-4 V1 MIB		draft-ietf-idr-bgp4-mib-13.txt

	BGP-4 Protocol Analysis		draft-ietf-idr-bgp-analysis-04.txt

	BGP Security Vulnerabilities Analysis
	draft-ietf-idr-bgp-vuln-00.txt

	Experience with the BGP-4 Protocol
	draft-ietf-idr-bgp4-experience-protocol-03.txt

	BGP 4 Implementation Report
	draft-ietf-idr-bgp-implementation-00.txt

	BGP-4 V1 MIB implementation report
	draft-ietf-idr-bgp-mibagent-survey-01.txt
	Presentation

3) Implementation Reports and FSM issues for current drafts [10 minutes]

	document: None, presentation only
	Presentation	Sue Hares

	- Yakov:	route-reflector update status?

	- Enke:		route-reflector update (4 weeks)

	- Enke:		prefix-orf was not added to charter

	- Sue:		yes it was added, administrative error in listing

4) BGP Peer Restart Backoff Mechanisms [10 minutes]

	document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update)

	Author: Susan Hares
	Presentation	Sue Hares

	- Alex:		draft should say informational
			achieve functionality using existing states?

	- Sue:		no... can't use existing states; already
			investigated that option

5) Deterministic Route Redistribution into BGP [10 minutes]

	document: draft-chen-bgp-redist-00.txt

	Authors: Jenny Yuan, Enke Chen
	Enke Chen

	- Andrew Lang: 	used to use configured localpref tweaking; not
			management intensive... unsure if this is needed

	- Enke:		timing dependent non-deterministic problem so
			current knobs cannot be used reliably; does not
			break anything... backwards compatible

	- Andrew Lang:	better to educate people about localpref

	- Barry Friedman:	lacks generality too narrow a problem
				space... only addresses RIP/iBGP interaction

	- Enke:		tweaking of admin distance defines a baseline

	- 		need per route granularity to solve for all cases? 
			Possibility of adding more configuration conflicts.

	- Alex:		this problem only occurs if there's a consistancy
			issue between two places...  May not be an issue for
			a single selection point.

			Introduction of new step will effect current
			edployment traffic selection?

	- Enke:		This will happen regardless.

			Should not effect current deployments and if there's
			a change, the change will be for the better.

	-		By definition, it does change behaviour.

	- Alex:		Will this be applicable to only situations where
			there is a problem?

	- Yakov:	Is this an implimentation method?

	- Alex:		Is this informational or standards-track?

	- Enke:		Either is fine

	- 		It can't be a local matter because it must be
			consistant throughout the entire system

	- Enke:		Decision on redistributed routes is made locally in
			each router

	-		Behaviour is changed because new code now uses admin
			distance over localpref?

	- Enke:		If only localpref is used then things should not
change

	- Cengiz:	If route-reflector is used?

	- Enke:		I need to think about it further

6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes]

	document: draft-hlmu-l2vpn-bgp-discovery-00.txt

	authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares
	Presentation	Sue Hares, P. Unbehagen

	-		Already a L2VPN draft that addresses this in a
defined
			NLRI with label information

	- Paul:		This draft is meant to provide LDP pseudowire config
			information

	- 		Other spec can do same thing [autodiscovery] without
label
			information

	- Kireeti:	Would like to be able to use this AFI with different
			SAFI [65] and NLRI format

	- 		Would the two SAFIs be solving similar problems

	- Kireeti:	My SAFI solves different problems

7) BGP Assignment of AFI/SAFI address [10 minutes]

	Document: draft-hares-bgp-assign-afisafi-00.txt 

	Author: Susan Hares
	Presentation	Sue Hares

8) BGP Attribute Codes and Suggested Procedures

	Document: draft-kompella-zinin-early-allocation-00.txt

	Author: Alex Zinin, Kireeti Kompella
	Presentation	Alex Zinin

	- Sharon:	talking about protocols and not OIDs preallocation? 
			bad to preallocate in the MIB... different from what
			other WGs; exclude MIB OIDs

	- Kireeti:	not suggesting that everyone use this

	- 		It would have been nicer to have had OIDs
			preallocated so as not to reimpliment the MIB
	
	- Sharon:	OIDs not allocated to drafts because if the drafts
			goes away then you've wasted numbers

	- Lou Berger:	allocation with 1 year with 1 renewal is too short;
			alterntate policy: as long as draft or version is
			alive, expire in 3 to 6 months

	- Alex:		that suggestion ties validity with ability of author
			to submit the draft; suggestion: once document is
			submitted to IESG then we freeze.  Don't want to
			allocate codepoints too early.

	- Dave Meyer:	Are you sure that IANA can time anything out

	- Alex:		No

	- Dave Meyer:	WG chair needs to manage this?

	-		What happens if the allocation is not renewed and
			code is using it still?

	- Alex:		Add provision to document to deprecate but not
return

	- Kireeti:	Deprecate for a period of time to give people time
			to remove.  Formal process to do early allocations
			and if it goes through then stick with it but if it
			doesn't go through then people must take this out.

	- Dino:		Allocate experimental codepoints and once
			standardised, then adopt standard codepoint for
			sending but accept both.

	- Sue:		Good for SAFIs as well as AFIs?

	- Dino:		All well known IANA values

	- Fenner:	RFC already documents a process for transitioning
			codepoints

9) Charter Discussion [20 minutes]

	Thanks to all implementers who send in reports on the the base
	specification, we will be opening the charter. This section of the
meeting
	will discuss what items will be added to the charter.
	Presentation

	-		Top three most important; maybe ECMP little higher
than Fault Isolation
--
/*==================[ Jake Khuon <[email-masked]> ]=====================+
 | Field App. Engineer    http://www.nexthop.com/  /\  /~ E  X  T  H  O  P |
 | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772  /  \/  Technologies, Inc.|
+==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/

From: vijay gill <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Organization: vijay gill global logistics
Sender: [email-masked]
Date: Tue, 2 Mar 2004 23:17:11 +0000

On Tue, Mar 02, 2004 at 02:47:19PM -0800, Pedro Roque Marques wrote:

> When you receive a BGP advertisement from a neighbor, do you expect 
> traffic sent to that neighbor to follow the ASes that are present in
> the corresponding routing advertisement ?

Yes, but right now, nothing prevents that person from putting
a static up that points any traffic I send to that AS right back
out the current pipe. I am saying is that you are trying to
solve a problem which a) isn't a huge thing in practice and
b) _cannot_ be solved.

> Is it a 'feature' or a 'bug' if traffic doesn't follow the path
> advertised by routing...

it is a bug obviously, but insofar as BGP knows, it is setting
up a correct loop-free graph and it really should
restrict itself to doing that, as opposed to trying to figure out
all the myriad ways traffic can go wrong.

> This is an issue that exists today... and not strictly related to the
> advertisement of inactive paths. I believe CAIDA has made measurements
> of such inconsistencies.

I think we need more results from randy's happy packets research.

> But while it is easy for all of us to say "i'd like to be able to do
> whatever i want" a more interesting question is "what i would like
> others to contrain themselfs to"...

But I don't worry how say, my bgp peers AS routes traffic internally.
It is not within my bailiwick to worry about it, they could be using
statics for all I care.  my concern is that they send me an accurate
prefix set that they are transiting and I give them traffic
for that prefix set.

I think we are starting to loop here. 

/vijay

From: Pedro Roque Marques <[email-masked]>
To: vijay gill <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Tue, 2 Mar 2004 14:47:19 -0800 (PST)

vijay gill writes:

> What BGP does should be separate from anything else. You have the
> bgp database, operate on the BGP database. Pick routes, only look to
> see if you have a valid next-hop, and then continue on.

Vijay,
I'm sure that your view as its merits... but we also need to consider
the question the other way around.

When you receive a BGP advertisement from a neighbor, do you expect 
traffic sent to that neighbor to follow the ASes that are present in
the corresponding routing advertisement ?

Do you make any assumptions based on the contents of such as-path
attribute ?

Is it a 'feature' or a 'bug' if traffic doesn't follow the path
advertised by routing...

This is an issue that exists today... and not strictly related to the
advertisement of inactive paths. I believe CAIDA has made measurements
of such inconsistencies.

But while it is easy for all of us to say "i'd like to be able to do
whatever i want" a more interesting question is "what i would like
others to contrain themselfs to"...

Disabling the advertisement of inactive routes is not a panacea that
will address all inconsistencies, assuming one does care about
those...

  Pedro.

To: Pedro Roque Marques <[email-masked]>
cc: Pekka Savola <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Tue, 02 Mar 2004 10:42:03 -0500

In message <[email-masked]>, Pedro Roque Mar
ques writes:
> Pekka Savola writes:
> 
> > My interpretation of the spec (and a vendor's, as well) is that this
> > is not considered at all in the current spec.  And if we disagree,
> > it calls for EVEN MORE LOUDLY for a clarification!
> 
> [...]
> 
> > No -- the current spec is just looking up a route -- it takes no
> > stance what kind of 'route' that is.
> 
> By your own admission the spec doesn't require clarification. It is
> clear that it doesn't understand the next-hop type of a route.
> 
> > This needs to be specified.
> 
> What you mean by this is that you believe that the current behaviour
> should be modified...
> 
> Even if we where to agree that the behaviour you and Curtis propose is
> more desirable than the current one, it isn't feasible to modify the
> behaviour of current systems.
> 
> The modification you propose also isn't suficient to address the
> problem that you point out whenever your aggregate route has a
> reachable next-hop.
> 
> Examples where this could happen:
> 
> - User wants to forward all traffic that hits the default route to a
> remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic
> collector.

That's a default route that forwards traffic, not a discard route.

> - Network is divided in areas but has global IGP. Each area border
> generates a summary of address in the are that is propagated across
> the network. i.e. outside the area you see an aggregate via BGP and
> more specific /32s.

That route also forwards traffic.  It is not a discard route.  On the
aggregator itself, there had better be a more specific route or if not
the routes should be considered infeasible.

If the aggregator which also happens to be an EIBGP router where
confederations are used then the aggregator is also passing the BGP
routes from the border router that went down.  When the hole in the
aggregate occurs if the discard route is allowed to pass the
reachability test, then the BGP routes remain in the rest of the AS
until the BGP session times out - a very long time.  This quite
obviously is bad for SLAs and if some of those routes had alternates
there might be some unhappy customers (you could also argue that if
they didn't have alternates they'd be even more unhappy).  If the
discard does not cause the reachability test to pass, then the BGP
routes advertised by the border router that went down go down in IGP
time (seconds and possibly sub-second - YMMV).  An occasional fault
and recovery in seconds doesn't violate most SLAs and customers also
don't see substantial impact.

If the IGP aggregates, as it does in OSPF areas, but the aggregators
are not either RRs or confed boundaries, then the test for
reachability does not occur on the aggregator and that can be a
problem.  The only current solution is to not aggregate the addresses
used for the infrastructure within the AS, but aggregate those
prefixes outside the AS.  There really is not alternative.  Once the
aggregate is formed information is lost that is needed to quickly
withdraw the routes due to the reachability change.

This is certainly a topic for a BCP but we don't need to put anything
in the BGP spec.

... that said, I think I'll go back and check our implementation.

Curtis

From: Pedro Roque Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Tue, 2 Mar 2004 09:55:54 -0800 (PST)

Gargi Nalawade writes:

>> 
>> My time to ask for a clarification...
>> 
>> It seems that you are saying that:
>> 
>> 1) when the nexthop of a BGP route doesn't match the forwarding
>> nexthop selected in the routing table that BGP should not advertise
>> the route. In your words "it breaks routing", or it has the
>> potential to do so.
>> 
>> 2) If the next-hop does match, BGP should advertise its route, even
>> if less preferred.

> yes & yes.

Thanks. You should probably write an Internet-Draft that describes
that behaviour then.

>> A second question would be how do you define 'next-hop matching' in
>> the context of an iBGP route vs an IGP route.

> Am I missing what you are trying to say?

You have two routes for the same prefix.

i.e.	10.0.1/24 OSPF nexthop 1
	10.0.1/24 iBGP nexthop 2

What do you consider nexthop to be...

i.e. in terms of iBGP is 'next-hop' the NEXT_HOP BGP attribute as
advertised by the remote peer ? Or is this a directly connected
next-hop obtained via route resolution.

It would be nice to have the answer to that question, in case you do
decide to write an I-D.

regards,
  Pedro.

From: vijay gill <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Organization: vijay gill global logistics
Sender: [email-masked]
Date: Tue, 2 Mar 2004 15:34:06 +0000

What BGP does should be separate from anything else. You
have the bgp database, operate on the BGP database. Pick routes,
only look to see if you have a valid next-hop, and then continue on.

If you have an identical route that is more preferred by whatever
mechanism that does the 'pick what route to install in the forwarding
table' why does this affect bgp. This leads to things like
advertise-inactive and each time there is a new install of a juniper
box, you have to write a paragraph on advertise-inactive and why it
is needed. I've done this for too many jnx qual docs and it is 
starting to annoy the @#$# out of me.

I am fully willing to change my opinion but I've long maintained
that each routing protocol should have its own tables and it is 
up to the user to ensure that they are topologically sane.

/vijay

From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Tue, 2 Mar 2004 10:15:44 -0500

On Mon, Mar 01, 2004 at 08:40:52PM -0500, Curtis Villamizar wrote:
> If A installs the discard route but not both components, then A's
> implementation of aggregation is broken.

The installation of the more specifics was presumed.  
I was talking about BGP aggregation.

-- 
Jeff Haas 
NextHop Technologies

From: Gargi Nalawade <[email-masked]>
Reply-To: [email-masked]
To: Pedro Roque Marques <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 01 Mar 2004 23:41:27 -0800

Pedro Roque Marques wrote:
> Gargi Nalawade writes:
> 
> 
>>Now that I understand your request for modification & clarification
>>better, I think it makes sense. It would be good to clarify in the
>>spec.
> 
> 
>>If there is no operator here who can think of a reason why  they may
>>want to explicitly prohibit BGP from advertising a route it doesnt own,
>>even when the nexthop matches that in the forwarding table, we should
>>make the other behavior (i.e. advertise even if BGP doesnt own the route 
>>when the nexthop matches) the recommended one, stating the currently
>>stated but least used behavior as an optional alternative.
> 
> 
> My time to ask for a clarification...
> 
> It seems that you are saying that:
> 
> 1) when the nexthop of a BGP route doesn't match the forwarding
> nexthop selected in the routing table that BGP should not advertise
> the route. In your words "it breaks routing", or it has the potential
> to do so.
> 
> 2) If the next-hop does match, BGP should advertise its route, even if
> less preferred.

yes & yes.

> A second question would be how do you define 'next-hop matching' in
> the context of an iBGP route vs an IGP route.

Why should iBGP vs IGP come into play? The BGP bestpath calculation
would have already given us the best BGP route. If this BGP route (BGP's 
bestpath) loses to an IGP route with a lower admin-distance then BGP
decides whether or not advertise this BGP route. But a BGP bestpath
cannot lose to an iBGP route in the routing-table. Because that iBGP
route wont be the BGP bestpath.  Then why does losing to an iBGP route
come into play when it comes to advertising a BGP bestpath? Am I missing
what you are trying to say?

-Gargi

From: Pedro Roque Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 1 Mar 2004 22:45:44 -0800 (PST)

Gargi Nalawade writes:

> Now that I understand your request for modification & clarification
> better, I think it makes sense. It would be good to clarify in the
> spec.

> If there is no operator here who can think of a reason why  they may
> want to explicitly prohibit BGP from advertising a route it doesnt own,
> even when the nexthop matches that in the forwarding table, we should
> make the other behavior (i.e. advertise even if BGP doesnt own the route 
> when the nexthop matches) the recommended one, stating the currently
> stated but least used behavior as an optional alternative.

My time to ask for a clarification...

It seems that you are saying that:

1) when the nexthop of a BGP route doesn't match the forwarding
nexthop selected in the routing table that BGP should not advertise
the route. In your words "it breaks routing", or it has the potential
to do so.

2) If the next-hop does match, BGP should advertise its route, even if
less preferred.

A second question would be how do you define 'next-hop matching' in
the context of an iBGP route vs an IGP route.

regards,
  Pedro.

From: Gargi Nalawade <[email-masked]>
Reply-To: [email-masked]
To: Pekka Savola <[email-masked]>
CC: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 01 Mar 2004 21:56:16 -0800

Pekka Savola wrote:
> On Mon, 1 Mar 2004, Gargi Nalawade wrote:
> 
>>For this case - there is no problem. Some implementations can already
>>do this. But again there are operators who want the opposite behavior
>>as well. i.e. BGP should not advertise a route if it is not the owner
>>even if the BGP nexthop is the same as that of the route in the
>>forwarding table. 
> 
> 
> Really?  I'm having problems figuring out where this would be desired 
> behaviour.

Im trying to hunt for the usage if this as well. So if anyone knows of
a reason, let us know. I have only heard 3rd & 4th hand requirements so
far  where the source has either moved on or no longer exists.

>>Both behaviors are achieved today by various imple-
>>mentations even though the default may vary from vendor to vendor.
> 
> 
> Yep.
>  
> 
>>Again - time for a clarification. :) Are you asking for that the
>>behavior be present or that the spec be changed to describe both
>>behaviors?
> 
> 
> I think the specification should, very clearly, state just one
> recommended behaviour, and possibly describe an optional other
> behaviour.  I think the recommended behaviour should be what I
> proposed, and you also described.  Because that's actually what
> happens very often.
> 
> But if there is strong objection to this very clear statement of 
> behaviour (or "modification"), also spelling out the alternative is 
> important.

Now that I understand your request for modification & clarification
better, I think it makes sense. It would be good to clarify in the
spec.

If there is no operator here who can think of a reason why  they may
want to explicitly prohibit BGP from advertising a route it doesnt own,
even when the nexthop matches that in the forwarding table, we should
make the other behavior (i.e. advertise even if BGP doesnt own the route 
when the nexthop matches) the recommended one, stating the currently
stated but least used behavior as an optional alternative.

-Gargi

From: Pekka Savola <[email-masked]>
To: Gargi Nalawade <[email-masked]>
cc: Pedro Roque Marques <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Tue, 2 Mar 2004 07:46:12 +0200 (EET)

On Mon, 1 Mar 2004, Gargi Nalawade wrote:
> For this case - there is no problem. Some implementations can already
> do this. But again there are operators who want the opposite behavior
> as well. i.e. BGP should not advertise a route if it is not the owner
> even if the BGP nexthop is the same as that of the route in the
> forwarding table. 

Really?  I'm having problems figuring out where this would be desired 
behaviour.

> Both behaviors are achieved today by various imple-
> mentations even though the default may vary from vendor to vendor.

Yep.
 
> Again - time for a clarification. :) Are you asking for that the
> behavior be present or that the spec be changed to describe both
> behaviors?

I think the specification should, very clearly, state just one
recommended behaviour, and possibly describe an optional other
behaviour.  I think the recommended behaviour should be what I
proposed, and you also described.  Because that's actually what
happens very often.

But if there is strong objection to this very clear statement of 
behaviour (or "modification"), also spelling out the alternative is 
important.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Gargi Nalawade <[email-masked]>
Reply-To: [email-masked]
To: Pekka Savola <[email-masked]>
CC: Pedro Roque Marques <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 01 Mar 2004 21:12:46 -0800

Pekka Savola wrote:
> On Mon, 1 Mar 2004, Gargi Nalawade wrote:
> 
>>Are you asking that BGP advertise a route even if the nexthop of the
>>route in the forwarding table is different? If so, this definitely
>>breaks routing. As long as the nexthop of the 2 routes are the same,
>>there is no problem.
> 
> 
> Thanks for asking for clarification; I think this is very useful, and 
> a point which has not been spelled out clearly enough.
> 
> I'm only interested of the case where the next-hop interface is the
> same for both protocols. (Obviously, there is no 1-to-1 mapping,
> because IGP gives an interface, but BGP an address.)

For this case - there is no problem. Some implementations can already
do this. But again there are operators who want the opposite behavior
as well. i.e. BGP should not advertise a route if it is not the owner
even if the BGP nexthop is the same as that of the route in the
forwarding table. Both behaviors are achieved today by various imple-
mentations even though the default may vary from vendor to vendor.

Again - time for a clarification. :) Are you asking for that the
behavior be present or that the spec be changed to describe both
behaviors?

-Gargi

From: vijay gill <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Organization: vijay gill global logistics
Sender: [email-masked]
Date: Tue, 2 Mar 2004 04:36:27 +0000

--On Monday, March 1, 2004 16:41 -0800 Pedro Roque Marques
<[email-masked]> wrote:

> vijay gill writes:
>
>> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote:
>>> Pekka Savola writes:
>>>
>>> i'll repeat it: - How can you prove that a given path that is
>>> learned by BGP is loop free ?  - That can only be done if
>>> forwarding follows routing.
>
>> I feel that BGP should only be concerned about creating loop free
>> topologies. If the user then has a mechanism where the forwarding
>> does not follow the routing properly and causes a loop (this is an
>> important distinction), then this is their problem. I can always
>> point a static back up a link if I so want and nothing bgp can do
>> about it.
>
> Your argument assumes that the user always knows that is configuring a
> situation that may create forwarding loops...
>
> That may not be the case. It may come from a configuration
> mistake...
>
> imho, the default approach for the protocol spec is to choose the most
> graceful failure model possible torwards loop-free forwarding...
>imho, the default approach for the protocol spec is to choose the most
>graceful failure model possible torwards loop-free forwarding...

Pedro, I still don't understand why BGP must care about statics or other
protocols that may or may not be misconfigured. For some reason I may
want
to create a forwarding loop (for example, in my lab) to see what the
router
does. Actually, to be more specific, there are valid operational reasons
for sometimes routing information away from where BGP points you, load
balancing on congested peerings for example. Not very elegant, but these
cases do exist. If a vendors BGP implementation does not allow me to
have
the final say as to where I want to place traffic, I _will_ be extremely
irate.
If you only consider BGP, then it should do loop-free routing,
absolutely. I just do not want BGP to be looking into static
configurations and trying to do my thinking for me. This leads to anger
and anger leads to the dark side. etc etc.

>
>>> Proof: configure a static route for a given prefix in a border
>>>router that points to a BGP neighbor that selects this router as
>>>best path... watch permanent forwarding loops.
>
>>Yes, and this is a not a matter for BGP to worry about.
>
>I respectfully disagree.

that is fine. but as we all know, the final arbiter of features is the
account team, backed up by P.O.s no matter what the IETF would like to
believe.

/vijay

From: Pekka Savola <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
Sender: [email-masked]
Date: Tue, 2 Mar 2004 06:15:51 +0200 (EET)

On Mon, 1 Mar 2004, Pedro Roque Marques wrote:
> 
> > No -- the current spec is just looking up a route -- it takes no
> > stance what kind of 'route' that is.
> 
> By your own admission the spec doesn't require clarification. It is
> clear that it doesn't understand the next-hop type of a route.

Some people seem to disagree.  I personally am of the opinion that the
spec can be read both ways, but *seems* to indicate that the intent is
to be "route -type agnostic".

> What you mean by this is that you believe that the current behaviour
> should be modified...

Modified (if the WG thinks your interpretation is correct) is
preferable.  Clarified is required.

> The modification you propose also isn't suficient to address the
> problem that you point out whenever your aggregate route has a
> reachable next-hop.

As stated, that can be avoided by operational procedures (by putting
the discard routes in every box).  This really can't.

> Examples where this could happen:
> 
> - User wants to forward all traffic that hits the default route to a
> remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic
> collector.

Of course, this can happen.  Then the BGP nexthops matching the 
default remain 'resolvable'.  But that seems quite obvious: if you 
have a "working" default route, it will be considered by the 
resolvability process.

Of course, in the long run, there is a need to specify the 
resolvability in a more fine-grained manner, but the "discard route" 
scenario seems to be a non-obvious problem which must be fixed 
quickly.

I don't have many preferences on the way it's solved, as long as it
gets fixed soon.  And if fixing would take time, and it's for any
purpose delayed from the bgp4-xx spec for now, we must clearly specify
the expected behaviour in the spec.

> - Network is divided in areas but has global IGP. Each area border
> generates a summary of address in the are that is propagated across
> the network. i.e. outside the area you see an aggregate via BGP and
> more specific /32s.

"Don't do that". :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Pekka Savola <[email-masked]>
To: Gargi Nalawade <[email-masked]>
cc: Pedro Roque Marques <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Tue, 2 Mar 2004 06:01:32 +0200 (EET)

On Mon, 1 Mar 2004, Gargi Nalawade wrote:
> Are you asking that BGP advertise a route even if the nexthop of the
> route in the forwarding table is different? If so, this definitely
> breaks routing. As long as the nexthop of the 2 routes are the same,
> there is no problem.

Thanks for asking for clarification; I think this is very useful, and 
a point which has not been spelled out clearly enough.

I'm only interested of the case where the next-hop interface is the
same for both protocols. (Obviously, there is no 1-to-1 mapping,
because IGP gives an interface, but BGP an address.)

But this is natural, as the BGP next-hop information is quite often, 
when it matters, calculated based on IGP :)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Subject: [Idr] FW: IDR minutes
Sender: [email-masked]
Date: Mon, 1 Mar 2004 22:40:23 -0500

Minutes for 3/1/04 session

-----Original Message-----
From: Jake Khuon 
Sent: Monday, March 01, 2004 3:18 AM
To: Susan Hares; [email-masked]
Subject: IDR minutes

Inter-Domain Routing WG (idr)

Monday, March 1 at 1530-1730
==================================

CHAIRS: Sue Hares ([email-masked])
	Yakov Rekhter ([email-masked])

AGENDA:

1) Agenda Bashing

	Agenda Slides

2) Document status [5 minutes]

	- Bundle went to IESG

	BGP-4 draft-23		draft-ietf-idr-bgp4-23.txt

	BGP-4 V1 MIB		draft-ietf-idr-bgp4-mib-13.txt

	BGP-4 Protocol Analysis		draft-ietf-idr-bgp-analysis-04.txt

	BGP Security Vulnerabilities Analysis
	draft-ietf-idr-bgp-vuln-00.txt

	Experience with the BGP-4 Protocol
	draft-ietf-idr-bgp4-experience-protocol-03.txt

	BGP 4 Implementation Report
	draft-ietf-idr-bgp-implementation-00.txt

	BGP-4 V1 MIB implementation report
	draft-ietf-idr-bgp-mibagent-survey-01.txt
	Presentation

3) Implementation Reports and FSM issues for current drafts [10 minutes]

	document: None, presentation only
	Presentation	Sue Hares

	- Yakov:	route-reflector update status?

	- Enke:		route-reflector update (4 weeks)

	- Enke:		prefix-orf was not added to charter

	- Sue:		yes it was added, administrative error in listing

4) BGP Peer Restart Backoff Mechanisms [10 minutes]

	document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update)

	Author: Susan Hares
	Presentation	Sue Hares

	- Alex:		draft should say informational
			achieve functionality using existing states?

	- Sue:		no... can't use existing states; already
			investigated that option

5) Deterministic Route Redistribution into BGP [10 minutes]

	document: draft-chen-bgp-redist-00.txt

	Authors: Jenny Yuan, Enke Chen
	Enke Chen

	- Andrew Lang: 	used to use configured localpref tweaking; not
			management intensive... unsure if this is needed

	- Enke:		timing dependent non-deterministic problem so
			current knobs cannot be used reliably; does not
			break anything... backwards compatible

	- Andrew Lang:	better to educate people about localpref

	- Barry Friedman:	lacks generality too narrow a problem
				space... only addresses RIP/iBGP interaction

	- Enke:		tweaking of admin distance defines a baseline

	- 		need per route granularity to solve for all cases? 
			Possibility of adding more configuration conflicts.

	- Alex:		this problem only occurs if there's a consistancy
			issue between two places...  May not be an issue for
			a single selection point.

			Introduction of new step will effect current
			edployment traffic selection?

	- Enke:		This will happen regardless.

			Should not effect current deployments and if there's
			a change, the change will be for the better.

	-		By definition, it does change behaviour.

	- Alex:		Will this be applicable to only situations where
			there is a problem?

	- Yakov:	Is this an implimentation method?

	- Alex:		Is this informational or standards-track?

	- Enke:		Either is fine

	- 		It can't be a local matter because it must be
			consistant throughout the entire system

	- Enke:		Decision on redistributed routes is made locally in
			each router

	-		Behaviour is changed because new code now uses admin
			distance over localpref?

	- Enke:		If only localpref is used then things should not change

	- Cengiz:	If route-reflector is used?

	- Enke:		I need to think about it further

6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes]

	document: draft-hlmu-l2vpn-bgp-discovery-00.txt

	authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares
	Presentation	Sue Hares, P. Unbehagen

	-		Already a L2VPN draft that addresses this in a defined
			NLRI with label information

	- Paul:		This draft is meant to provide LDP pseudowire config
			information

	- 		Other spec can do same thing [autodiscovery] without label
			information

	- Kireeti:	Would like to be able to use this AFI with different
			SAFI [65] and NLRI format

	- 		Would the two SAFIs be solving similar problems

	- Kireeti:	My SAFI solves different problems

7) BGP Assignment of AFI/SAFI address [10 minutes]

	Document: draft-hares-bgp-assign-afisafi-00.txt 

	Author: Susan Hares
	Presentation	Sue Hares

8) BGP Attribute Codes and Suggested Procedures

	Document: draft-kompella-zinin-early-allocation-00.txt

	Author: Alex Zinin, Kireeti Kompella
	Presentation	Alex Zinin

	- Sharon:	talking about protocols and not OIDs preallocation? 
			bad to preallocate in the MIB... different from what
			other WGs; exclude MIB OIDs

	- Kireeti:	not suggesting that everyone use this

	- 		It would have been nicer to have had OIDs
			preallocated so as not to reimpliment the MIB
	
	- Sharon:	OIDs not allocated to drafts because if the drafts
			goes away then you've wasted numbers

	- Lou Berger:	allocation with 1 year with 1 renewal is too short;
			alterntate policy: as long as draft or version is
			alive, expire in 3 to 6 months

	- Alex:		that suggestion ties validity with ability of author
			to submit the draft; suggestion: once document is
			submitted to IESG then we freeze.  Don't want to
			allocate codepoints too early.

	- Dave Meyer:	Are you sure that IANA can time anything out

	- Alex:		No

	- Dave Meyer:	WG chair needs to manage this?

	-		What happens if the allocation is not renewed and
			code is using it still?

	- Alex:		Add provision to document to deprecate but not return

	- Kireeti:	Deprecate for a period of time to give people time
			to remove.  Formal process to do early allocations
			and if it goes through then stick with it but if it
			doesn't go through then people must take this out.

	- Dino:		Allocate experimental codepoints and once
			standardised, then adopt standard codepoint for
			sending but accept both.

	- Sue:		Good for SAFIs as well as AFIs?

	- Dino:		All well known IANA values

	- Fenner:	RFC already documents a process for transitioning
			codepoints

9) Charter Discussion [20 minutes]

	Thanks to all implementers who send in reports on the the base
	specification, we will be opening the charter. This section of the meeting
	will discuss what items will be added to the charter.
	Presentation

	-		Top three most important; maybe ECMP little higher than Fault Isolation
--
/*==================[ Jake Khuon <[email-masked]> ]=====================+
 | Field App. Engineer    http://www.nexthop.com/  /\  /~ E  X  T  H  O  P |
 | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772  /  \/  Technologies, Inc.|
 +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/

From: Gargi Nalawade <[email-masked]>
Reply-To: [email-masked]
To: Pedro Roque Marques <[email-masked]>
CC: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 01 Mar 2004 18:28:43 -0800

Pedro,

> The issue is "what are the drawbacks of advertising a route that is
> not used for forwarding".

I agree that BGP should not advertise a route not used for forwarding,
to the extent that the route used for forwarding means same nexthop.
If BGP is not the owner of the route, but the BGP nexthop matches the
nexthop of the route in the forwarding table, there is no forwarding
loop if BGP advertises the route. Things work perfectly fine.

Pekka,

Are you asking that BGP advertise a route even if the nexthop of the
route in the forwarding table is different? If so, this definitely
breaks routing. As long as the nexthop of the 2 routes are the same,
there is no problem.

-Gargi

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
Sender: [email-masked]
Date: Mon, 1 Mar 2004 17:56:09 -0800 (PST)

Pekka Savola writes:

> My interpretation of the spec (and a vendor's, as well) is that this
> is not considered at all in the current spec.  And if we disagree,
> it calls for EVEN MORE LOUDLY for a clarification!

[...]

> No -- the current spec is just looking up a route -- it takes no
> stance what kind of 'route' that is.

By your own admission the spec doesn't require clarification. It is
clear that it doesn't understand the next-hop type of a route.

> This needs to be specified.

What you mean by this is that you believe that the current behaviour
should be modified...

Even if we where to agree that the behaviour you and Curtis propose is
more desirable than the current one, it isn't feasible to modify the
behaviour of current systems.

The modification you propose also isn't suficient to address the
problem that you point out whenever your aggregate route has a
reachable next-hop.

Examples where this could happen:

- User wants to forward all traffic that hits the default route to a
remote box that analyzes traffic... i.e. 0/0 to an LSP to a traffic
collector.

- Network is divided in areas but has global IGP. Each area border
generates a summary of address in the are that is propagated across
the network. i.e. outside the area you see an aggregate via BGP and
more specific /32s.

  Pedro.

From: Pekka Savola <[email-masked]>
To: Jeffrey Haas <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Tue, 2 Mar 2004 03:37:35 +0200 (EET)

On Mon, 1 Mar 2004, Jeffrey Haas wrote:
> > Yep -- there two flavors here:
> >  1) looking from A's perspective -- the route to C is known to be a 
> > reject route by A.
> 
> We're fine here.

We'll, not sure what you mean.  I don't think "we're fine here" is a 
good choice of words, because that's the actual problem I was 
reporting -- one which is not covered by the specification!

> >  2) looking from B's perspective -- the route to C goes to A, where 
> > the packets are rejected. B does not, in BGP, know that the route is a 
> > reject route at A.
> 
> And thus packets that arrive at B will be propagated to A and be
> consumed by the reject route.
> 
> And this is not fine how?

I can accept this behaviour, but 1), above is unacceptable.

> The ideal scenario is that each core router within the AS knows all
> of the routes to networks within an AS.  Once a packet hits one of
> these routers, that router will generate ICMP destination unreachable.

Agreed.

> In our scenario above, we provide a routing sink that attracts packets
> that otherwise would be generating ICMP further into the network,
> but the right thing continues to happen.  If we're being clever,
> we may be doing this intentionally with a default sink as an attempt
> to collect statistics about packets being sent to hosts within our
> network that appear outside advertised aggregates for purposes of 
> intrusion detection or something else.

But such a packet sink breaks route resolvability -- all the routers
which do not have the reject route -- assuming that problem 1) above
will be fixed -- will continue to have their iBGP sessions up.  This 
is, AFAICS, in conflict with two of your goals below.
 
> At no time does this break routing.  What the above scenario indicates
> is that the network isn't being configured well.

I think you're assuming that 1) is a non-problem.  It is a real 
problem.  But assuming it isn't..
 
> Ideally (and please feel to shoot this down based on operational 
> experience):
> o Aggregation happens at your AS border routers.  Every single one of them.
> o You do not inject your aggregates into your iBGP.

These are desirable goals, yes.  Actually, they are just one goal,
worded differently -- if you don't aggregate everywhere, you have to
have the aggregates in your iBGP, no question about it.  Excluding
misconfigurations (such as unintentional aggregate advertisement to
iBGP unnecesarily), practically, either you break zero or you break
both.

Practically, these are not always feasible.  E.g., we use private ASns
in access networks, so each core router connecting to an access
network has EBGP and would have to aggregate (we're just advertising
the default).  This is "aggregation in all of the borders" is a bit
cumbersome, but we could add it if that would make the network "more
correct" and make it work better.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Pekka Savola <[email-masked]>
To: [email-masked]
cc: Parantap Lahiri <[email-masked]>, "'John G. Scudder'" <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
Sender: [email-masked]
Date: Tue, 2 Mar 2004 03:18:40 +0200 (EET)

On Mon, 1 Mar 2004, Curtis Villamizar wrote:
> Yes I was following.  You just didn't read the paragraph that was
> immediately above this one, which you also conveniently chopped off.
> The paragraph you omitted said:
> 
>    Then the aggregate is locally generated and it is very easy to
>    exclude the parts of an aggregate that you generated but are not
>    covered by more specific from the reachability test and it makes
>    perfectly good sense to do so.  If other prefixes in the AS match
>    that aggregate then the aggregate is generated but locally it is
>    installed as a discard route.
> 
> I'm agreeing with the original point just mentioning that the original
> point wasn't clear.

It was (or _is_) not clear whether you consider this to be the status 
quo or not.

My interpretation of the spec (and a vendor's, as well) is that this 
is not considered at all in the current spec.  And if we disagree, it 
calls for EVEN MORE LOUDLY for a clarification!

> > > No need to modify the spec.  If you've installed a special type of
> > > route in the kernel that is there explicitly to indicate
> > > non-reachability, then that route should not be allowed to indicate
> > > reachability.  I dont' think we really need to say that.
> > 
> > You would think so, but the current spec does not say so.  
> 
> The bgp3-23 test just mentions route.  If you interpret that to
> include discard routes you simply have a bug in your implementation.
> It is quite easy to just look for something in the FIB radix trie and
> if you find something declare that is satisfied the reachability
> criteria without looking at what it was you found (a discard route).

No -- the current spec is just looking up a route -- it takes no 
stance what kind of 'route' that is.  This needs to be specified.  

Of course, it'd be nice to fix the implementation I'm having problems 
with.  But being altruistic, and wanting to fix this problem for 
others as well, this needs to be specified, somehow, in the spec to 
avoid this issue being misinterpreted.

My assumption is that the implementation must work properly, if
implemented to the letter of the spec.  That's not the case now.  
Anything that requires the implementor to "use non-obvious
interpretation of the spec" is a potential missing (or badly written)
item from the spec.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Jeffrey Haas <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Mon, 1 Mar 2004 20:09:14 -0500

Please excuse the long citation.

On Tue, Mar 02, 2004 at 02:52:57AM +0200, Pekka Savola wrote:
> >   C
> >  /|
> > A |
> >  \|
> >   B
> > 
> > B has prefix D1 - 192/17
> > C has prefix D2 - 192.128/17
> > 
> > B and C advertises these routes with loopback addresses.  (next-hop-self)
> > 
> > A synthesizes an aggregate, 192/16 using B and C's routes as contributors.
> > A thus installs 192/16 in it's FIB as a reject route per accepted
> > practice.
> 
> We're doing "manual aggregation" by adding the 192/16 manually as a 
> discard route, and filtering out the more specifics when advertising 
> to peers, but the end result is the same.

A, B and C are all within a given AS.
Regardless of whether A propagates B and C's more specifics to peers
outside of this AS isn't important to this particular scenario.

To be clear, we may consider A, B and C to be egress routers for this
AS and B and C will propagate the aggregate synthesized by A and learned
via iBGP.  Note that as has been mentioned multiple times, this is not
common practice - C and B should be configured to synthesize the aggregate
as well, but this will work "ok" without it.

> > C is nuked from space in a green fireball.
> > 
> > Prior to BGP figuring out that C has gone away, C's loopback is no longer
> > advertised, leaving B to use the aggregate from A to calculate the
> > resolved nexthop for D2.  Thus, B has a route to D2 via A, which will
> > eventually reach a reject route.
> > 
> > Is this your scenario?
> 
> Yep -- there two flavors here:
>  1) looking from A's perspective -- the route to C is known to be a 
> reject route by A.

We're fine here.

>  2) looking from B's perspective -- the route to C goes to A, where 
> the packets are rejected. B does not, in BGP, know that the route is a 
> reject route at A.

And thus packets that arrive at B will be propagated to A and be
consumed by the reject route.

And this is not fine how?

The ideal scenario is that each core router within the AS knows all
of the routes to networks within an AS.  Once a packet hits one of
these routers, that router will generate ICMP destination unreachable.

In our scenario above, we provide a routing sink that attracts packets
that otherwise would be generating ICMP further into the network,
but the right thing continues to happen.  If we're being clever,
we may be doing this intentionally with a default sink as an attempt
to collect statistics about packets being sent to hosts within our
network that appear outside advertised aggregates for purposes of 
intrusion detection or something else.

At no time does this break routing.  What the above scenario indicates
is that the network isn't being configured well.

Ideally (and please feel to shoot this down based on operational 
experience):
o Aggregation happens at your AS border routers.  Every single one of them.
o You do not inject your aggregates into your iBGP.
o You do not advertised more specifics covered by an announced
  aggregate unless you are doing intentional traffic engineering.
  If you are, you're preferably working with your upstream ISPs to
  make sure those routes aren't propagated "too far" in attempt to keep
  the Internet routing table clean.  One example is tagging the routes
  with the NO_EXPORT community.

However, if you fail in one of the above, routing will still work.

-- 
Jeff Haas 
NextHop Technologies

From: Pekka Savola <[email-masked]>
To: Jeffrey Haas <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Tue, 2 Mar 2004 02:52:57 +0200 (EET)

On Mon, 1 Mar 2004, Jeffrey Haas wrote:
> On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote:
> > I guess you weren't following.  Discard routes are set up because
> > folks want to announce that aggregate route to their peers.  That's
> > not a "very unusual circumstance".
> 
> If I'm following you correctly, here's an example of the condition that
> you're talking about.
> 
>   C
>  /|
> A |
>  \|
>   B
> 
> B has prefix D1 - 192/17
> C has prefix D2 - 192.128/17
> 
> B and C advertises these routes with loopback addresses.  (next-hop-self)
> 
> A synthesizes an aggregate, 192/16 using B and C's routes as contributors.
> A thus installs 192/16 in it's FIB as a reject route per accepted
> practice.

We're doing "manual aggregation" by adding the 192/16 manually as a 
discard route, and filtering out the more specifics when advertising 
to peers, but the end result is the same.
 
> C is nuked from space in a green fireball.
> 
> Prior to BGP figuring out that C has gone away, C's loopback is no longer
> advertised, leaving B to use the aggregate from A to calculate the
> resolved nexthop for D2.  Thus, B has a route to D2 via A, which will
> eventually reach a reject route.
> 
> Is this your scenario?

Yep -- there two flavors here:
 1) looking from A's perspective -- the route to C is known to be a 
reject route by A.
 2) looking from B's perspective -- the route to C goes to A, where 
the packets are rejected. B does not, in BGP, know that the route is a 
reject route at A.

1) is the root cause; 2) can be worked around by installing "reject"  
routes on all boxes.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Mon, 1 Mar 2004 19:44:27 -0500

On Mon, Mar 01, 2004 at 03:44:45PM -0500, Curtis Villamizar wrote:
> Then the aggregate is locally generated and it is very easy to exclude
> the parts of an aggregate that you generated but are not covered by
> more specific from the reachability test and it makes perfectly good
> sense to do so.  If other prefixes in the AS match that aggregate then
> the aggregate is generated but locally it is installed as a discard
> route.  
> 
> I suppose this is the original reason that the discard route was
> mentioned, but with a failure to mention the entire context.

It took me a second to remember, but to dredge up the ghost from
the last time this thread came around:

rfc 1519, section 4.2.2:

:   4.2.  Rules for route advertisement
: 
[...]
:       2.   A routing domain which performs summarization of multiple
:            routes must discard packets which match the summarization but
:            do not match any of the explicit routes which makes up the
:            summarization. This is necessary to prevent routing loops in
:            the presence of less-specific information (such as a default
:            route).  Implementation note - one simple way to implement
:            this rule would be for the border router to maintain a "sink"
:            route for each of its aggregations. By the rule of longest
:            match, this would cause all traffic destined to components of
:            the aggregation which are not explicitly known to be
:            discarded.

-- 
Jeff Haas 
NextHop Technologies

From: Pedro Roque Marques <[email-masked]>
To: vijay gill <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 1 Mar 2004 16:41:58 -0800 (PST)

vijay gill writes:

> On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote:
>> Pekka Savola writes:
>> 
>> i'll repeat it: - How can you prove that a given path that is
>> learned by BGP is loop free ?  - That can only be done if
>> forwarding follows routing.

> I feel that BGP should only be concerned about creating loop free
> topologies. If the user then has a mechanism where the forwarding
> does not follow the routing properly and causes a loop (this is an
> important distinction), then this is their problem. I can always
> point a static back up a link if I so want and nothing bgp can do
> about it.

Your argument assumes that the user always knows that is configuring a
situation that may create forwarding loops...

That may not be the case. It may come from a configuration
mistake...

imho, the default approach for the protocol spec is to choose the most
graceful failure model possible torwards loop-free forwarding...

>>  Proof: configure a static route for a given prefix in a border
>> router that points to a BGP neighbor that selects this router as
>> best path... watch permanent forwarding loops.

> Yes, and this is a not a matter for BGP to worry about.

I respectfully disagree.

  Pedro.

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 1 Mar 2004 16:34:55 -0800 (PST)

Pekka Savola writes:

> [I don't quickly see how this is related to this specific issue, but
> I'm still grasping to understand the specific scenario and the
> failure model you're describing.]

The issue is "what are the drawbacks of advertising a route that is
not used for forwarding".

> If a link has failed but rerouting is not possible (i.e.: a and b
> become isolated from each other, or both a and b become isolated
> from the route originator), the internal consistency has failed.
> But as they have configured a discard route, this is an intended
> consequence -- the routers by its definition are supposed to know
> everything in the area.

In such scenario, w/ one choice of behaviour a blackhole route is
advertised, w/ is not so w/ another choice of behaviour.

Which means that your original question as to there being instances
where this behaviour is desirable has been answered.

It may not be desirable in your network. And i find it perfectly
reasonable if you require implementations to support the behaviour
that is desirable in your network.

  Pedro.

From: "Sharon Chisholm" <[email-masked]>
To: [email-masked]
Cc: "Wijnen, Bert (Bert)" <[email-masked]>
Subject: RE: [Idr] Experimental code-points
Sender: [email-masked]
Date: Mon, 1 Mar 2004 19:29:47 -0500

hi

In looking through
	
http://www.ietf.org/internet-drafts/draft-kompella-zinin-early-allocation-00
.txt

I would suggest the following change to address my concern that it
inappropriately sets the expectation that MIB OIDs will be pre-allocated.

In either the 'Introduction' or in the section 'Conditions for Early
Allocation' the following text needs to be added.

'Note that under no condition will MIB Object Identifiers (OIDs) be
allocated before the RFC is published.'

Sharon

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]] 
Sent: Monday, March 01, 2004 3:11 AM
To: [email-masked]
Subject: [Idr] Experimental code-points

As I mentioned, RFC 3692 described experimental allocations. Please check if
it's applicable.

-- 
Alex
http://www.psg.com/~zinin/

To: Parantap Lahiri <[email-masked]>
cc: [email-masked], "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Mon, 01 Mar 2004 15:44:45 -0500

In message <[email-masked]>, Parantap Lahiri writes
:
> Not to beat a dead horse here but in some major vendor implementations, you
> can't send an "aggregate" if it is not in your routing table. And it defeats
> the purpose.

Then the aggregate is locally generated and it is very easy to exclude
the parts of an aggregate that you generated but are not covered by
more specific from the reachability test and it makes perfectly good
sense to do so.  If other prefixes in the AS match that aggregate then
the aggregate is generated but locally it is installed as a discard
route.  

I suppose this is the original reason that the discard route was
mentioned, but with a failure to mention the entire context.  You can
manually configure discard routes but that is generally only done in
very unusual circumstances, such as a DoS attack to a specific
destination.  Even then it doesn't make a whole lot of sense to allow
such a discard route to be used in the resolvability test.

No need to modify the spec.  If you've installed a special type of
route in the kernel that is there explicitly to indicate
non-reachability, then that route should not be allowed to indicate
reachability.  I dont' think we really need to say that.

Curtis

> -----Original Message-----
> From: Curtis Villamizar [mailto:[email-masked]] 
> Sent: Monday, March 01, 2004 3:02 PM
> To: Parantap Lahiri
> Cc: [email-masked]; 'Pekka Savola'; 'John G. Scudder'; [email-masked]
> Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
> routes
> 
> 
> In message <[email-masked]>, Parantap Lahiri
> writes
> :
> > If you aggregate the prefixes just towards EBGP neighbors it definitely
> does
> > solve the problem, but the issue is you will have to touch all your ebgp
> > sessions once you get a new block to aggregate. Operator motto is have a
> > design which requires least touching. Of course that can be equated to
> > laziness, but it depends on which side of fence you are on.
> 
> 
> How many different blocks of addresses do you put your IBGP loopbacks
> in?  Last I counted it was one.  You don't have to treat your customer
> aggregates this way if you don't want to, just the aggregate that
> covers your backbone.  And btw - with machine generated configs there
> is no problem generating aggregates on each EBGP speaking router - its
> only when you try to hand configure your 1,000+ routers (or whatever).
> 
> Anyway, we already seemed to agree that this at most ends up in a
> separate new document.
> 
> Curtis
> 
> 

To: Parantap Lahiri <[email-masked]>
cc: [email-masked], "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Mon, 01 Mar 2004 15:02:13 -0500

In message <[email-masked]>, Parantap Lahiri writes
:
> If you aggregate the prefixes just towards EBGP neighbors it definitely does
> solve the problem, but the issue is you will have to touch all your ebgp
> sessions once you get a new block to aggregate. Operator motto is have a
> design which requires least touching. Of course that can be equated to
> laziness, but it depends on which side of fence you are on.

How many different blocks of addresses do you put your IBGP loopbacks
in?  Last I counted it was one.  You don't have to treat your customer
aggregates this way if you don't want to, just the aggregate that
covers your backbone.  And btw - with machine generated configs there
is no problem generating aggregates on each EBGP speaking router - its
only when you try to hand configure your 1,000+ routers (or whatever).

Anyway, we already seemed to agree that this at most ends up in a
separate new document.

Curtis

From: vijay gill <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: Pekka Savola <[email-masked]>, [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Organization: vijay gill global logistics
Sender: [email-masked]
Date: Tue, 2 Mar 2004 00:33:14 +0000

On Mon, Mar 01, 2004 at 04:25:18PM -0800, Pedro Roque Marques wrote:
> Pekka Savola writes:
> 
> i'll repeat it:
> - How can you prove that a given path that is learned by BGP is loop
> free ?
> - That can only be done if forwarding follows routing.

I feel that BGP should only be concerned about creating loop
free topologies. If the user then has a mechanism where
the forwarding does not follow the routing properly and causes
a loop (this is an important distinction), then
this is their problem. I can always point a static back
up a link if I so want and nothing bgp can do about it.

> 
> Proof: configure a static route for a given prefix in a border router
> that points to a BGP neighbor that selects this router as best
> path... watch permanent forwarding loops.

Yes, and this is a not a matter for BGP to worry about.

/vijay

From: Jeffrey Haas <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Mon, 1 Mar 2004 19:27:32 -0500

Pekka,

On Tue, Mar 02, 2004 at 01:41:41AM +0200, Pekka Savola wrote:
> I guess you weren't following.  Discard routes are set up because
> folks want to announce that aggregate route to their peers.  That's
> not a "very unusual circumstance".

If I'm following you correctly, here's an example of the condition that
you're talking about.

  C
 /|
A |
 \|
  B

B has prefix D1 - 192/17
C has prefix D2 - 192.128/17

B and C advertises these routes with loopback addresses.  (next-hop-self)

A synthesizes an aggregate, 192/16 using B and C's routes as contributors.
A thus installs 192/16 in it's FIB as a reject route per accepted
practice.

C is nuked from space in a green fireball.

Prior to BGP figuring out that C has gone away, C's loopback is no longer
advertised, leaving B to use the aggregate from A to calculate the
resolved nexthop for D2.  Thus, B has a route to D2 via A, which will
eventually reach a reject route.

Is this your scenario?

-- 
Jeff Haas 
NextHop Technologies

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 1 Mar 2004 16:25:18 -0800 (PST)

Pekka Savola writes:

> On Mon, 1 Mar 2004, Pedro Roque Marques wrote:
>> What is the #1 goal of BGP ?  The establishment of *loop free*
>> paths between autonomous systems. How can you guarantee loop free
>> properties ? via the as-path loop detection mechanism... This means
>> that you can only gurantee no forwarding loops if traffic always
>> follows routing.

> This is IMHO a bogus argument in this case.  BGP already relies on
> the consistency of the AS in its operations.  This is just a matter
> of the IGP and BGP in the AS being consistent.

> As stated earlier, there is ample operational experience that this
> modification works.

> The operators, with or without this modification, can shoot
> themselves in the foot and discard packets.

It seems that you did not understand my argument...

i'll repeat it:
- How can you prove that a given path that is learned by BGP is loop
free ?
- That can only be done if forwarding follows routing.

Proof: configure a static route for a given prefix in a border router
that points to a BGP neighbor that selects this router as best
path... watch permanent forwarding loops.

Protocol correctness matters. The point of the BGP spec is not how to
deal w/ implementation quirks... but it is about protocol
correctness.

Implementations may feel free to disregard safety rules... and allow uses
"to shoot themselfs in the foot"... but it must be clear what the
risks are and the BGP spec should be as conservative as possible.

  Pedro.

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
Sender: [email-masked]
Date: Mon, 1 Mar 2004 16:17:14 -0800 (PST)

Pekka Savola writes:

> You would think so, but the current spec does not say so.

> Maybe a problem is that a discard route should not fail the
> resolvability check when propagated as a DDoS prevention hack,
> referred earlier.

> IMHO, excluding these routes seems obvious to me

And to me it seems obvious that a route is a route, regardless of
next-hop type. The later being an implementation specific concept and
not something to be addressed at the spec level...

It is clear that what 'seems obvious' is highly subjective to the
person in question.

>, but as it wasn't
> obvious to the implementors and they hadn't done it, it MUST be in
> the spec in one form or another.

imho, it MUST NOT be in the BGP specification in one way or
another. The BGP specification deals w/ the protocol definition, not
with how to implement it. 

  Pedro.

From: Pekka Savola <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Tue, 2 Mar 2004 02:08:15 +0200 (EET)

On Mon, 1 Mar 2004, Pedro Roque Marques wrote:
> What is the #1 goal of BGP ?
> The establishment of *loop free* paths between autonomous
> systems. How can you guarantee loop free properties ? via the as-path
> loop detection mechanism... This means that you can only gurantee no
> forwarding loops if traffic always follows routing.

This is IMHO a bogus argument in this case.  BGP already relies on the 
consistency of the AS in its operations.  This is just a matter of the 
IGP and BGP in the AS being consistent.

As stated earlier, there is ample operational experience that this 
modification works.

The operators, with or without this modification, can shoot themselves 
in the foot and discard packets.

> But there are more mundane practical consequences:
> 
>         outside
> 	|     |
>       -----------
> 	a --- b		as x
> 	|     |
> 
> A and B are border gateways for a stub as (x). Both are configured to
> originate a given prefix 10.0.1/24 whenever that prefix is reachable
> throught its IGP.
> 
> Additionally, they are configured w/ a discard route to 10.0.1/24,
> which discard traffic whenever the IGP route is not present.
> 
> In case of failure, one likely gets one of the exit points w/ a
> discard route as its forwarding state, while the other exit point has
> a valid IGP route.

[I don't quickly see how this is related to this specific issue, but 
I'm still grasping to understand the specific scenario and the failure 
model you're describing.]

I don't see this happening.  Which specific failure are you talking
about?

It seems to me that:
 - either the router (a/b) is down making the point moot (the other is 
in IGP)
 - either a link has failed (e.g., between a and b), but then the IGP 
redundancy fixes this problem by rerouting through the stub area (by 
your description I get that the prefix is learned from some other 
router in the area).  

If a link has failed but rerouting is not possible (i.e.: a and b
become isolated from each other, or both a and b become isolated from
the route originator), the internal consistency has failed.  But as
they have configured a discard route, this is an intended consequence
-- the routers by its definition are supposed to know everything in
the area.

> If the gateway that has a discard route in the forwarding table does
> advertise the route from its peer gateway it will cause traffic to be
> dropped.

I didn't quite follow this description, but if the stub had a discard 
route configured, but the IGP is inconsistent, this should definitely 
be the expected behaviour.

> Generalizing:
> - whenever BGP advertises a route that it doesn't use for forwarding,
> traffic can easily end up getting dropped.

Spelling out the root cause:
 - having an inconsistent/wrong IGP configuration can cause easily
traffic to be dropped -- nothing new there.

> Would there be a kind soul that volunteers to keep a FAQ of this WG
> list ? That way we wouldn't need to rehash this discussion and the
> MRAI discussion every 6 months.

No objection to having such a FAQ, as long as such a FAQ is not based 
on bogus arguments.  Issue 11 was covered in the BGP issues list, for 
example, but with incorrect assumptions.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

From: Pekka Savola <[email-masked]>
To: [email-masked]
cc: Parantap Lahiri <[email-masked]>, "'John G. Scudder'" <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
Sender: [email-masked]
Date: Tue, 2 Mar 2004 01:41:41 +0200 (EET)

On Mon, 1 Mar 2004, Curtis Villamizar wrote:
> I suppose this is the original reason that the discard route was
> mentioned, but with a failure to mention the entire context.  You can
> manually configure discard routes but that is generally only done in
> very unusual circumstances, such as a DoS attack to a specific
> destination.

I guess you weren't following.  Discard routes are set up because
folks want to announce that aggregate route to their peers.  That's
not a "very unusual circumstance".

> No need to modify the spec.  If you've installed a special type of
> route in the kernel that is there explicitly to indicate
> non-reachability, then that route should not be allowed to indicate
> reachability.  I dont' think we really need to say that.

You would think so, but the current spec does not say so.  

Maybe a problem is that a discard route should not fail the 
resolvability check when propagated as a DDoS prevention hack, 
referred earlier.

IMHO, excluding these routes seems obvious to me, but as it wasn't 
obvious to the implementors and they hadn't done it, it MUST be in the 
spec in one form or another.  Whether it should be discussed at more 
length in some other document (Targeting BCP or PS, I don't know).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] WG Last Call on draft-ietf-idr-cease-subcode-04.txt
Sender: [email-masked]
Date: Mon, 01 Mar 2004 14:48:48 -0800

Folks

THis is to start the WG Last Call on advancing
draft-ietf-idr-cease-subcode-04.txt to Proposed Standard.

The Last Call ends March 21. 

Please send comments to the list.

Yakov.

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
To: [email-masked]
Cc: "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Importance: Normal
Sender: [email-masked]
Date: Mon, 01 Mar 2004 15:30:18 -0500

Not to beat a dead horse here but in some major vendor implementations, you
can't send an "aggregate" if it is not in your routing table. And it defeats
the purpose.

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, March 01, 2004 3:02 PM
To: Parantap Lahiri
Cc: [email-masked]; 'Pekka Savola'; 'John G. Scudder'; [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

In message <[email-masked]>, Parantap Lahiri
writes
:
> If you aggregate the prefixes just towards EBGP neighbors it definitely
does
> solve the problem, but the issue is you will have to touch all your ebgp
> sessions once you get a new block to aggregate. Operator motto is have a
> design which requires least touching. Of course that can be equated to
> laziness, but it depends on which side of fence you are on.

How many different blocks of addresses do you put your IBGP loopbacks
in?  Last I counted it was one.  You don't have to treat your customer
aggregates this way if you don't want to, just the aggregate that
covers your backbone.  And btw - with machine generated configs there
is no problem generating aggregates on each EBGP speaking router - its
only when you try to hand configure your 1,000+ routers (or whatever).

Anyway, we already seemed to agree that this at most ends up in a
separate new document.

Curtis

content-class: urn:content-classes:message
Subject: RE: [Idr] BGP-based VPLS
From: "Susan Hares" <[email-masked]>
To: "Kireeti Kompella" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Mon, 1 Mar 2004 15:17:03 -0500

Kireeti:

Just to make sure, I understand you.
You are suggesting:
	SAFI = 1,2,3 per draft
	SAFI = 65 per your draft

Same afi, same BGP mechanisms in draft?

Sue

-----Original Message-----
From: Kireeti Kompella [mailto:[email-masked]]
Sent: Monday, March 01, 2004 3:31 AM
To: [email-masked]
Subject: [Idr] BGP-based VPLS

Following up on the discussion regarding BGP for L2VPN auto-discovery,
draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for
VPLS.  Of special interest to this WG is section 3, where the NLRI
format for this AFI/SAFI (*) pair, and other topics are described.

(*) SAFI = 65; AFI not yet allocated.  It seems sensible to use the
AFI allocated for auto-discovery.

Kireeti.
-------

To: Parantap Lahiri <[email-masked]>
cc: [email-masked], "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Mon, 01 Mar 2004 11:46:06 -0500

In message <[email-masked]>, Parantap Lahiri writes
:
> Curtis,
> 
> I was referring to a complete separate address space for the secondary
> loopbacks and the idea was not to aggregate that space. It would be only in
> IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus
> immediately invalidating the routes originated by it. The rest of the world
> could still reach the box using the primary loopback address, which would be
> aggregated and would be in BGP. 
> 
> Anyway, my initial message was delayed by the moderator and I found John
> Scudder referring to this option in one of his later mails. So I think its
> covered. 
> 
> -Parantap   

The way we did this when I was doing operations was we aggregated and
sent the aggregate to EBGP peers.  Since we didn't have the aggregate
for our own address allocation within our AS this never came up.  This
also was not a problem because the loopback by definition cannot
become unreachable, only interface addresses can become unreachable.

IBGP peers should be announcing their loopback, which can never go
down unless the router becomes completely unreachable.  If the
provider's aggregate is only sent outside the AS, then this is fine.
I personally felt as an operator that if another provider is to *lazy*
to configure the aggregate statement on each EBGP peer, and instead
chooses to announce that aggreate into IBGP, then they get what they
deserve.  Working for a vendor now, I have to take the position that
the customer can be as arbitrarily lazy as they like and thats just
fine.

This isn't a problem with the BGP protocol.  Its a problem with the
way some providers configure their networks (incorrectly) that is
easily solved by not doing it that way, or can be solved by adding a
config knob to the router to exclude aggreates from this AS from
consideration in the reachability test or exclude specific prefixes.
This is certainly something that can be addressed in a separate
document.

Curtis

To: Pedro Roque Marques <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Mon, 01 Mar 2004 14:19:24 -0500

Curtis

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
To: [email-masked]
Cc: "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Importance: Normal
Sender: [email-masked]
Date: Mon, 01 Mar 2004 12:25:27 -0500

If you aggregate the prefixes just towards EBGP neighbors it definitely does
solve the problem, but the issue is you will have to touch all your ebgp
sessions once you get a new block to aggregate. Operator motto is have a
design which requires least touching. Of course that can be equated to
laziness, but it depends on which side of fence you are on.

>This isn't a problem with the BGP protocol.  Its a problem with the
>way some providers configure their networks (incorrectly) that is
>easily solved by not doing it that way, or can be solved by adding a
>config knob to the router to exclude aggregates from this AS from
>consideration in the reachability test or exclude specific prefixes.
>This is certainly something that can be addressed in a separate
>document.

This is exactly what I suggested in the 2nd paragraph of my original mail.

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Monday, March 01, 2004 11:46 AM
To: Parantap Lahiri
Cc: [email-masked]; 'Pekka Savola'; 'John G. Scudder'; [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

In message <[email-masked]>, Parantap Lahiri
writes
:
> Curtis,
> 
> I was referring to a complete separate address space for the secondary
> loopbacks and the idea was not to aggregate that space. It would be only
in
> IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus
> immediately invalidating the routes originated by it. The rest of the
world
> could still reach the box using the primary loopback address, which would
be
> aggregated and would be in BGP. 
> 
> Anyway, my initial message was delayed by the moderator and I found John
> Scudder referring to this option in one of his later mails. So I think its
> covered. 
> 
> -Parantap   

The way we did this when I was doing operations was we aggregated and
sent the aggregate to EBGP peers.  Since we didn't have the aggregate
for our own address allocation within our AS this never came up.  This
also was not a problem because the loopback by definition cannot
become unreachable, only interface addresses can become unreachable.

IBGP peers should be announcing their loopback, which can never go
down unless the router becomes completely unreachable.  If the
provider's aggregate is only sent outside the AS, then this is fine.
I personally felt as an operator that if another provider is to *lazy*
to configure the aggregate statement on each EBGP peer, and instead
chooses to announce that aggreate into IBGP, then they get what they
deserve.  Working for a vendor now, I have to take the position that
the customer can be as arbitrarily lazy as they like and thats just
fine.

This isn't a problem with the BGP protocol.  Its a problem with the
way some providers configure their networks (incorrectly) that is
easily solved by not doing it that way, or can be solved by adding a
config knob to the router to exclude aggreates from this AS from
consideration in the reachability test or exclude specific prefixes.
This is certainly something that can be addressed in a separate
document.

Curtis

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
To: [email-masked]
Cc: "'Pekka Savola'" <[email-masked]>, "'John G. Scudder'" <[email-masked]>, [email-masked]
Importance: Normal
Sender: [email-masked]
Date: Mon, 01 Mar 2004 10:33:11 -0500

Curtis,

I was referring to a complete separate address space for the secondary
loopbacks and the idea was not to aggregate that space. It would be only in
IGP as discrete /32s, and if the node is gone, the /32 will be gone, thus
immediately invalidating the routes originated by it. The rest of the world
could still reach the box using the primary loopback address, which would be
aggregated and would be in BGP. 

Anyway, my initial message was delayed by the moderator and I found John
Scudder referring to this option in one of his later mails. So I think its
covered. 

-Parantap   

-----Original Message-----
From: Curtis Villamizar [mailto:[email-masked]] 
Sent: Saturday, February 28, 2004 1:24 PM
To: Parantap Lahiri
Cc: 'Pekka Savola'; 'John G. Scudder'; [email-masked]
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

In message <[email-masked]>, Parantap Lahiri
writes
:
> The problem Pekka is describing is definitely a very valid problem which
> exists. I am not sure though if the fix is in some design modifications or
> in fixing the spec itself. 
> 
> The ways to fix it by design modification would be ...
> 
> The router R1 in question resets the BGP next-hop to some secondary
loopback
> address which is different from the primary loopback (part of the
prefix/16)
> and the secondary loopback address range is only in IGP as discrete /32s,
> this problem might be mitigated. Though it's going to load the IGP with a
> new set of IP prefixes and may be problematic in some situations since
some
> IGP protocols have limited capability to carry large number of IP
prefixes. 
> 
> The other way to solve it might be a vendor implemented knob, where a
> particular address range (like prefix/16) is never considered while doing
> BGP next hop resolution. Though, I am not sure if this knob would be a
part
> of the spec.
> -Parantap

I'm not sure what that has to do with discard routes unless you are
talking about generating an aggregate and the next hop falling into
the unused portion of the aggregate.  If you allow the next hop to
resolved to the unused portion of an aggregated, your implementation
is simply broken.  You can't forward on a aggregate you generate, you
can only forward on the components that make up the aggregate and if
you miss this distinction in your BGP implementation, that is just an
implementation mistake.

If OTOH, some other router did the aggregation and sent the aggregate
into the IGP or IBGP, then the problem is not one that needs to be
fixed in the spec.  If allowing BGP learned routes to resolve BGP next
hops, which is commonly configured, another knob that can be added is
to exclude routes in which the aggregator is in the same AS.  If that
was not sufficient you'd need a knob to exclude specific prefixes.
This is clearly outside of the BGP spec.  It seems to me to be more a
case of adding configuration knobs to cover up the problems caused by
misconfiguration.

Curtis

To: Alex Zinin <[email-masked]>
cc: [email-masked]
Reply-To: [email-masked]
Subject: Re: [Idr] Comments on draft-chen-bgp-redist-00.txt 
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]
Date: Mon, 01 Mar 2004 11:18:31 -0500

In message <[email-masked]>, Alex Zinin writes:
> Comments I brought up today:
> 
>  1. The problem appears because there are two points within the router where
>     two routes are compared. The draft suggests that the BGP path selection
>     process is made consistent with the selection process in the routing
>     table (AdminDist-based).
> 
>     The question is whether the problem statement is applicable for the
>     implementations where BGP path selection and AD comparison happens
>     at the same time (from what I remember, gated did that). In other words,
>     the question is whether the problem is implementations specific or not,
>     and hence whether a change to the protocol is appropriate.
> 
>  2. Suggestion: seems that the problem can be solved without changing the
>     best path selection process.
> 
>     The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. ta
> ke
>     the AD value and use it as LOCAL_PREF value when importing (redistributin
> g)
>     routes to BGP, and use the LOCAL_PREF value as the AD when installing rou
> tes
>     in the routing table. The advantage is it automagically makes the route
>     selection decisions consistent not only within a single router, but
>     throughout the iBGP mesh too.
> 
>     Food for thoughts...
>     
> -- 
> Alex
> http://www.psg.com/~zinin/

Sounds like this could go in a follow up internet-draft.  It is
outside of BGP itself.

Curtis

content-class: urn:content-classes:message
Subject: RE: [Idr] FW: Here's the bundle for BGP to go to the IESG
From: "Susan Hares" <[email-masked]>
To: "Alex Zinin" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]
Date: Mon, 1 Mar 2004 14:07:10 -0500

http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-mibagent-survey-00.txt

We'll make sure the -00.txt , -01.txt gets loaded next week.

Sue

-----Original Message-----
From: Alex Zinin [mailto:[email-masked]]
Sent: Sunday, February 29, 2004 11:16 PM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] FW: Here's the bundle for BGP to go to the IESG

For information, the following two documents are not in the IETF draft
repository--

> 6) BGP 4 Implementation Report             draft-ietf-idr-bgp-implementation-00.txt
> 7) BGP-4 V1 MIB implementation report      draft-ietf-idr-bgp-mibagent-survey-01.txt

--we'll have to wait until they are available before we can put them in the
bundle and start the IETF LC on the whole group.

Alex

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)
Sender: [email-masked]
Date: Mon, 1 Mar 2004 10:51:23 -0800 (PST)

Pekka Savola writes:

> What I'm arguing here that there seem to be very clear operational
> reasons why the "BGP route must be used for forwarding" is very
> counterproductive and we should fix/clarify the spec to have a more
> useful definition for it.

> Are there any killer arguments why this is *NOT* a good idea?

What is the #1 goal of BGP ?
The establishment of *loop free* paths between autonomous
systems. How can you guarantee loop free properties ? via the as-path
loop detection mechanism... This means that you can only gurantee no
forwarding loops if traffic always follows routing.

So advertising routes that are not used for forwarding breaks the BGP
algorithm. And it means that you can no longer prove of trust the loop
free property.

But there are more mundane practical consequences:

        outside
	|     |
      -----------
	a --- b		as x
	|     |

A and B are border gateways for a stub as (x). Both are configured to
originate a given prefix 10.0.1/24 whenever that prefix is reachable
throught its IGP.

Additionally, they are configured w/ a discard route to 10.0.1/24,
which discard traffic whenever the IGP route is not present.

In case of failure, one likely gets one of the exit points w/ a
discard route as its forwarding state, while the other exit point has
a valid IGP route.

If the gateway that has a discard route in the forwarding table does
advertise the route from its peer gateway it will cause traffic to be
dropped.

Generalizing:
- whenever BGP advertises a route that it doesn't use for forwarding,
traffic can easily end up getting dropped.

Would there be a kind soul that volunteers to keep a FAQ of this WG
list ? That way we wouldn't need to rehash this discussion and the
MRAI discussion every 6 months.

Please file under: "Issues the WG as agreed not to agree".

  Pedro.

Reply-To: "Tom Petch" <[email-masked]>
From: "Tom Petch" <[email-masked]>
To: "Pekka Savola" <[email-masked]>, "idr" <[email-masked]>
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0 routes
Sender: [email-masked]
Date: Mon, 1 Mar 2004 18:10:44 -0000

It's a fair point but sounds more like
draft-ietf-idr-bgp4-experience-protocol-03.txt
than
draft-ietf-idr-bgp4-23.txt

Tom Petch

-----Original Message-----
From: Pekka Savola <[email-masked]>
To: [email-masked] <[email-masked]>
Date: 29 February 2004 06:24
Subject: Re: [Idr] issue: bgp4-23: route resolvability and discard/null0
routes

>After some off-list iteration, a revamped version of the possible text
>could be:
>
>In certain common deployment scenarios, the next-hop addresses are
>supposed to be valid only if resolved via routes of a specific type
>(e.g., IGP, connected or local).  There are likely less specific
>routes from other sources (e.g., static or BGP) which may resolve the
>next-hops as well, but such resolvability typically leads to problems
>when the less specific route actually can't be used to reach the
>next-hop, and the BGP routes are not invalidated even though their
>next-hop is, for all intents and purposes, unroutable.  Therefore, it
>is advisable that the implementations allow the operator to specify
>which routes should yield a positive result if they covered the the
>next-hop.
>
>.. thoughts?  This doesn't have any MAY/SHOULD etc. terminology, at
>least yet -- maybe it should.
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>

From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Question on MinASOrig Timer 
Sender: [email-masked]
Date: Mon, 1 Mar 2004 09:54:34 -0800 (PST)

 

Just for the record...

  Pedro.

From: =?iso-8859-1?q?BGP=20Guru?= <[email-masked]>
Subject: Re: [Idr] Question on MinASOrig Timer 
To: [email-masked], Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]
Date: Mon, 1 Mar 2004 10:27:12 +0000 (GMT)

 --- Curtis Villamizar

	

From: Kireeti Kompella <[email-masked]>
To: [email-masked]
Subject: [Idr] BGP-based VPLS
Sender: [email-masked]
Date: Mon, 1 Mar 2004 00:30:35 -0800 (PST)

Following up on the discussion regarding BGP for L2VPN auto-discovery,
draft-ietf-l2vpn-vpls-bgp-01.txt does auto-discovery and signaling for
VPLS.  Of special interest to this WG is section 3, where the NLRI
format for this AFI/SAFI (*) pair, and other topics are described.

(*) SAFI = 65; AFI not yet allocated.  It seems sensible to use the
AFI allocated for auto-discovery.

Kireeti.
-------

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [Idr] Experimental code-points
Sender: [email-masked]
Date: Mon, 1 Mar 2004 17:11:27 +0900

As I mentioned, RFC 3692 described experimental allocations.
Please check if it's applicable.

-- 
Alex
http://www.psg.com/~zinin/

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [Idr] Comments on draft-chen-bgp-redist-00.txt
Sender: [email-masked]
Date: Mon, 1 Mar 2004 17:12:51 +0900

Comments I brought up today:

 1. The problem appears because there are two points within the router where
    two routes are compared. The draft suggests that the BGP path selection
    process is made consistent with the selection process in the routing
    table (AdminDist-based).

    The question is whether the problem statement is applicable for the
    implementations where BGP path selection and AD comparison happens
    at the same time (from what I remember, gated did that). In other words,
    the question is whether the problem is implementations specific or not,
    and hence whether a change to the protocol is appropriate.

 2. Suggestion: seems that the problem can be solved without changing the
    best path selection process.

    The idea is to establish a 1:1 mapping between LOCAL_RPEF and AD, i.e. take
    the AD value and use it as LOCAL_PREF value when importing (redistributing)
    routes to BGP, and use the LOCAL_PREF value as the AD when installing routes
    in the routing table. The advantage is it automagically makes the route
    selection decisions consistent not only within a single router, but
    throughout the iBGP mesh too.

    Food for thoughts...
    
-- 
Alex
http://www.psg.com/~zinin/