Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard

From: Alex Zinin <[email-masked]>
Date: Mon, 19 Apr 2004 14:53:55 -0700

Pekka,

[cc'ing IDR]

Thanks for a careful follow-up. Inline below, pls.

Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote:
> On Fri, 19 Mar 2004, Alex Zinin wrote:
>> 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

> FWIW, I looked at this when it was at WG, and I noticed two 
> operationally particularly bad things that have both bitten us a lot 
> in our network (and many other networks):

>  1) the definition of route resolvability in the presence of 
>     discard/null0/reject/etc. routes is very unfortunate.  That is, if 
>     you happen to have to have a default route or an aggregate in your 
>     iBGP, when a router goes down and the loopback matches that route, the 
>     prefixes that were advertised by the router that went down aren't 
>     considered unresolvable, but you have to wait for BGP timeout.

>     There seemed to be no consensus to change this at this point, as a 
>     DDoS tracing technique depends on that discard/null0 resolvability
>     "feature".

>     This was discussed at idr thread:

>       issue: bgp4-23: route resolvability and discard/null0 routes

If memory serves, the discussion resulted in a suggestion to put this
consideration in one of the accompanying documents. Sue, Yakov, please
check.

>  2) The definition of active route is bad.  This fails in the 
>     situation where you need to export loopbacks/point-to-points to 
>     eBGP, but you have them in youro IGP.  The specification does not
>     consider them active (not used for forwarding), and they aren't 
>     exported.

>     When the next-hop of the IGP route is the same as BGP next-hop,
>     obviously this is no problem.  Gargi Nalawade promised to submit 
>     text, but hasn't, and I think Yakov said something about being 
>     willing to incorporate that, but obviously hasn't.

>     This was discussed at idr thread:

>       issue 11.2: active route, again

> Otherwise, I think this was operationally good.

Sue, Yakov, please check if the ball was dropped re this one.

Thanks.

Alex

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

---

From: Alex Zinin <[email-masked]>
Date: Mon, 19 Apr 2004 14:53:55 -0700

Pekka,

[cc'ing IDR]

Thanks.

Alex

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Apr 2004 06:53:01 -0700

Alex,

> consideration in one of the accompanying documents. Sue, Yakov, please

The suggestion on the mailing list was *not* to put this consideration
into one of the accompanying documents, but to produce a *separate*
Internet Draft that cover this (see e-mails on 3/12/2004).
  
> Sue, Yakov, please check if the ball was dropped re this one.

First of all, the consensus of the WG (as documented in 
draft-ietf-idr-bgp-issues) is to have the following text:

   In the context of this document we assume that a BGP speaker
   advertises to its peers only those routes that it itself uses (in
   this context a BGP speaker is said to "use" a BGP route if it is the
   most preferred BGP route and is used in forwarding). All other cases
   are outside the scope of this document.

While this text does not cover the case described by Pekka, it does
not preclude it either - handling the case described by Pekka
is just outside the scope of the spec.

With this in mind I suggest that the case described by Pekka
should be covered in a separate Internet Draft.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 Apr 2004 06:53:01 -0700

Alex,

  

Yakov.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 29 Apr 2004 19:35:00 +0300 (EEST)

> should be covered in a separate Internet Draft.

I think this is operationally a rather common (or even very common)  
scenario, and it would seem very disadvantageous not to tackle it in
this specification.  Further, there's major deployment of it (maybe
even multi-vendor -- probably) so there is considerable proof that it
works.

It should be the default behaviour of BGP as that's which makes the
most sense, operationally.  "BGP route is ... used by forwarding" does
not sufficiently cover the fact that people do use IGPs and there's
often overlap with IGP and BGP :).

-- 
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: Thu, 29 Apr 2004 19:35:00 +0300 (EEST)

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Apr 2004 10:15:26 -0700

Pekka,

> often overlap with IGP and BGP :).

People do use IGPs, and there is interaction between IGPs and BGP.

It is just that the based BGP protocol spec is *not* the place to 
document the interaction between BGP and IGPs.

Yakov.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 20:18:44 +0300 (EEST)

> document the interaction between BGP and IGPs.

I have to disagree here.  BGP is useless without IGP.  Failing to
consider that would mean a specifition disconnected from the reality.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Apr 2004 10:15:26 -0700

Pekka,

Yakov.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 30 Apr 2004 20:18:44 +0300 (EEST)

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 30 Apr 2004 11:14:38 -0700 (PDT)

Pekka Savola writes:

>> > I think this is operationally a rather common (or even very
>> common) > scenario, and it would seem very disadvantageous not to
>> tackle it in > this specification.  Further, there's major
>> deployment of it (maybe > even multi-vendor -- probably) so there
>> is considerable proof that it > works.  > > It should be the
>> default behaviour of BGP as that's which makes the > most sense,
>> operationally.  "BGP route is ... used by forwarding" does > not
>> sufficiently cover the fact that people do use IGPs and there's >

> consider that would mean a specifition disconnected from the

Pekka,
BGP is only one of the miriad of components necessary in a
router. There are advantages in documenting interactions between such
components but these are typically not done in the base
specification.

One simply cannot put all the bits of information required to make bgp
"useful" in the base specification and still have a readable document.

moreever the iteraction procedures that you seem to want to document
are not something the wg has achieved consensus on. there are still
different opinions on this topic and different deployed
behaviours. Thus including this topic in the base protocol spec seems
to me to be contrary to the original goals of revising the
specification.

I would also like to point out that several outher people have
expressed the opinion that this topic should be left out of the base
spec. In fact i would claim that there is consensus on that ammong the
wg.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 30 Apr 2004 11:14:38 -0700 (PDT)

Pekka,

  Pedro.

---

From: Dinara Suleymanova <[email-masked]>
Date: Thu, 29 Apr 2004 14:00:46 -0400

Hello,

Could it be possible to UN-subscribe us/me (not sure what address was added 
on your subscription list)
from your discussion list.

Thanks a lot.

Dinara Suleymanova

---

From: Dinara Suleymanova <[email-masked]>
Date: Thu, 29 Apr 2004 14:00:46 -0400

Hello,

Thanks a lot.

Dinara Suleymanova