Subject: Re: [Idr] issue 11.2: active route, again [Re: comments on idr-bgp4-20] (fwd)

From: Pedro Roque Marques <[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.

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

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 10:51:23 -0800 (PST)

outside
	|     |
      -----------
	a --- b		as x
	|     |

Generalizing:

  Pedro.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 02:08:15 +0200 (EET)

> 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:

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

> advertise the route from its peer gateway it will cause traffic to be

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.

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

> 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]>
Date: Tue, 2 Mar 2004 02:08:15 +0200 (EET)

It seems to me that:

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 16:25:18 -0800 (PST)

Pekka Savola writes:

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

> 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]>
Date: Mon, 1 Mar 2004 16:25:18 -0800 (PST)

i'll repeat it:

  Pedro.

---

From: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 00:33:14 +0000

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

> path... watch permanent forwarding loops.

Yes, and this is a not a matter for BGP to worry about.

/vijay

---

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

Pekka Savola writes:

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

> 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: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 16:34:55 -0800 (PST)

Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 16:41:58 -0800 (PST)

vijay gill 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]>
Date: Mon, 1 Mar 2004 16:41:58 -0800 (PST)

I respectfully disagree.

  Pedro.

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 18:28:43 -0800

Pedro,

> 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: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 18:28:43 -0800

Pedro,

Pekka,

-Gargi

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 06:01:32 +0200 (EET)

> breaks routing. As long as the nexthop of the 2 routes are the same,

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 :)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 06:01:32 +0200 (EET)

---

From: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 04:36:27 +0000

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

>>Yes, and this is a not a matter for BGP to worry about.

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: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 04:36:27 +0000

/vijay

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 21:12:46 -0800

> 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: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 21:12:46 -0800

-Gargi

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 07:46:12 +0200 (EET)

On Mon, 1 Mar 2004, Gargi Nalawade wrote:
> forwarding table. 

Really?  I'm having problems figuring out where this would be desired 
behaviour.

> Both behaviors are achieved today by various imple-

Yep.
 
> behavior be present or that the spec be changed to describe both

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.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 2 Mar 2004 07:46:12 +0200 (EET)

Yep.

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 21:56:16 -0800

> Really?  I'm having problems figuring out where this would be desired 

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.

> behaviour (or "modification"), also spelling out the alternative is 

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: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 21:56:16 -0800

-Gargi

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 22:45:44 -0800 (PST)

> 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: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 22:45:44 -0800 (PST)

regards,
  Pedro.

---

From: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 23:41:27 -0800

> 2) If the next-hop does match, BGP should advertise its route, even if

yes & yes.

> 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: Gargi Nalawade <[email-masked]>
Date: Mon, 01 Mar 2004 23:41:27 -0800

yes & yes.

-Gargi

---

From: vijay gill <[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: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 15:34:06 +0000

/vijay

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 2 Mar 2004 09:55:54 -0800 (PST)

Gargi Nalawade writes:

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

> 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: Pedro Roque Marques <[email-masked]>
Date: Tue, 2 Mar 2004 09:55:54 -0800 (PST)

regards,
  Pedro.

---

From: Pedro Roque Marques <[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.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 2 Mar 2004 14:47:19 -0800 (PST)

Vijay,

  Pedro.

---

From: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 23:17:11 +0000

> 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

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.

> advertisement of inactive paths. I believe CAIDA has made measurements

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

> 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: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 23:17:11 +0000

/vijay

---

From: vijay gill <[email-masked]>
Date: Mon, 01 Mar 2004 23:05:03 -0500

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.

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]>
Date: Mon, 01 Mar 2004 23:32:08 -0500

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.

/vijay

---

From: vijay gill <[email-masked]>
Date: Mon, 01 Mar 2004 23:05:03 -0500

/vijay

---

From: vijay gill <[email-masked]>
Date: Mon, 01 Mar 2004 23:32:08 -0500

/vijay

---

From: vijay gill <[email-masked]>
Date: Tue, 2 Mar 2004 00:33:14 +0000

/vijay