Subject: Re: [Idr] comments on idr-bgp4-20

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Oct 2003 08:57:02 +0300 (EEST)

Sorry for delay in responding..

On Tue, 30 Sep 2003, Yakov Rekhter wrote:
> > Responding to two issues which seem may warrant further discussion from 
> > me..
> > 
> > On Mon, 29 Sep 2003, Yakov Rekhter wrote:
> > > >  - I got major headache when trying to read the aggregating rules
> > > > especially in section 9.2.2.2 (and that was supposed to be the _simple_
> > > > rules :-(!!!) and ended up skipping them.
> > > > 
> > > > substantial
> > > > -----------
> > > > 
> > > > 1) Section 3 on Summary of the Operations, states:
> > > > 
> > > >    In the context of this document we assume that a BGP speaker adver-
> > > >    tises 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.
> > > > 
> > > > this "usability" requirement is in conflict with section 4.3 on UPDATE
> > > > message format:
> > > > 
> > > >    An UPDATE message is used to advertise feasible routes sharing common
> > > >    path attributes to a peer, [...]
> > > > 
> > > > ==> in particular note that "feasible" is a superset of "only those route
> s
> > > > the router itself uses" (compare to "those routes the router itself _coul
> d_
> > > > use if they were the most preferred ones"), right?
> 
> Could you point me to the text in the spec that said that "feasible" is 
> a superset of "only those routes that the router itself uses" ?

Look at the two quetes above and the definition of feasible:

   Feasible route
      A route that is available for use.

Note: it says "is _available_ for use", not "is _being_ used".

So, it seems clear that "feasible" seems to include also those routes 
which could be used, but for some reason (e.g. a preferred route exists) 
aren't.

> > > > ==> also note that the former definition is (IMHO) operationally unsound.
> > > > It prevents you from advertising P-t-P addresses and loopbacks (which als
> o 
> > > > reside in IGP) using BGP, because the IGP distance is lower than BGP and 
> > > > "BGP route is never used in forwarding". (depending on how you interpret 
> > > > that).  IMHO, this really needs to be changed to be OK.
> > > 
> > > The current text reflects consensus reached by the WG.
> > 
> > Note that there are two issues here:
> >  1) the text is out-of-sync between sections 3 and 4.3, and
> >  2) that the current definition of BGP route used for forwarding is not 
> > really useful.
> > 
> > I take it that the comment 1) is still valid.
> > 
> > Has 2) -- which you were probably referring to -- been raised as an issue
> > in the spec?  Any pointers to the issue, discussion, and the conclusion
> > (the answer to the question "Why did the WG decide this way?")  I fail to
> > see why such a conclusion would be justified.. and if the relevant points 
> > haven't been raised already, I probably want to re-open that debate.
> 
> >From draft-ietf-idr-bgp-issues-01.txt:
> 
>    After some additional discussion (in the "issue 11.2" thread), we
>    have come to a consensus on this 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.
>    
>    This issue is at consensus.
> 
> So, the text in the spec represents consensus of the WG. Also note
> the last sentence in the above paragraph.

Thanks.  

There seems to have been some discussion on this, sure, but I don't see 
anything in the issue 11.2 text in the draft which would indicate why this 
definition of "use" has been adapted.

The WG mailing list archives only start recently. Is there an archive
available somewhere which documents the discussion noted in the 11.2?
When was that discussion held?

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

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

---

From: Pekka Savola <[email-masked]>
Date: Mon, 6 Oct 2003 08:57:02 +0300 (EEST)

Feasible route

Thanks.

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 6 Oct 2003 09:22:05 -0400

At 8:57 AM +0300 10/6/03, Pekka Savola wrote:
>available somewhere

ftp://ftp.merit.edu/mail.archives/idr/

Sue/Yakov, IMO it would probably be good to either migrate the old 
archives to the new and improved (?) IETF page, or add a pointer to 
the historical archives to the IDR WG page.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 6 Oct 2003 09:22:05 -0400

--John

---

From: Pekka Savola <[email-masked]>
Date: Tue, 7 Oct 2003 22:56:30 +0300 (EEST)

Hi again,

[clipping the quote down]

[...]
> the last sentence in the above paragraph.

I've looked at the several threads in the archives, which do not seem to 
address the relevant points at all.

So, I think the issue needs to be reconsidered.

For example, consider a scenario of three routers in two ASs:

 rtr1 |      | rtr2 --- rtr3
 AS1  | ---- | AS2      AS2
 -----'      '-----

rtr3 is configured to advertise prefix 1.0.0.0/8 using BGP.  It has an
IBGP session to rtr2, where it will advertise it.  The AS2 also has an 
IGP, which includes only the loopbacks and point-to-point addresses of the 
AS.

IBGP also includes the loopback addresses and point-to-point addresses.
AS2 also wants to advertise the loopback addresses and PtP's to AS1 using
specific communities marked at the routers.  (There are multiple reasons
advertising loopbacks/ptps such is desirable.. for example, our network
employs private AS numbers and eBGP sessions and this is vital.)

Now, rtr2 advertises the prefix 1.0.0.0/8 just fine using eBGP to rtr1, 
but the loopback addresses and PtP's won't get advertised because the IGP 
is more preferred, and for BGP's perspective, the BGP routes are not 
"active".

Workarounds to this issue exist:
 - use an implementation-specific clause like "advertise-inactive", 
breaking the spec, to advertise them anyway, or
 - redistribute the IGP routes to BGP at the border router rtr2, losing 
communities etc. markings of iBGP in the process.  Ugly.

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?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 7 Oct 2003 22:56:30 +0300 (EEST)

Hi again,

 rtr1 |      | rtr2 --- rtr3
 AS1  | ---- | AS2      AS2
 -----'      '-----

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 7 Oct 2003 17:58:29 -0700 (PDT)

> Are there any killer arguments why this is *NOT* a good idea?

The main objective of BGP is to make sure that there are no routing or
forwarding loops. When BGP advertises a route that is not in the
forwarding table those guarantees disapear.

The BGP specification is concerned w/ protocol correctness and needs
to present a loop free algorithm.

It is an horse which as been beaten to death many times already in
this mailing list.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Tue, 7 Oct 2003 17:58:29 -0700 (PDT)

Pedro.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Oct 2003 08:41:52 +0300 (EEST)

> forwarding table those guarantees disapear.

The route to the same prefix (and in this case, the same nexthop as well) 
_is_  in the forwarding table.

> to present a loop free algorithm.

I think it has been shown that this is not a real problem.

For example, in:

====
Date: Wed, 02 Oct 2002 14:14:34 -0700
From: Dennis Ferguson <[email-masked]>
                                                                                                 
I have this view that routing protocols should be constrained to be
basically correct (i.e. do what is necessary to prevent loops and
otherwise ensure that they can actually reach the destinations they say
they can), but that anything else is fair game.  I don't like what Cisco
does, and certainly wouldn't have wanted the original BGP spec to say
this, since it is hard to think through a theoretical assurance of basic
correctness compared to just constraining routers to advertise only the
routes they are using.  On the other hand, they did it this way anyway and
we now have a lot of experience which says that routers can behave like
this without causing any particular damage, so I don't object to a change
which makes the document more closely reflect the practical reality.
=====

> It is an horse which as been beaten to death many times already in this
> mailing list.

And every time I looked at it, the reason why this was not done was 
because of some really bogus reasons, e.g. redistributing EBGP routes to 
IGP to get partial mesh-IBGP.  I failed to see this particular, very real 
scenario ever brought up in the discussion in the archives.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 8 Oct 2003 08:41:52 +0300 (EEST)

For example, in:

====

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 8 Oct 2003 10:52:02 -0700 (PDT)

Pekka Savola writes:

>> Pekka Savola writes: > Are there any killer arguments why this is
>> *NOT* a good idea?
>> 
>> The main objective of BGP is to make sure that there are no routing
>> or forwarding loops. When BGP advertises a route that is not in the

> The route to the same prefix (and in this case, the same nexthop as
> well) _is_ in the forwarding table.

- BGP shouldn't be required to understand which next-hops other
protocols use.

- Given that it typically doesn, and actually typically a route w/
another protocol as a different next-hop, there is no way to guarantee
that you will not have routing/forwarding loops.

The spec is not geared to "this particular" case. It has to be
concerned w/ all possible cases.

  Pedro.

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 8 Oct 2003 10:52:02 -0700 (PDT)

Pedro.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Oct 2003 19:36:49 +0300 (EEST)

> - BGP shouldn't be required to understand which next-hops other

Who said it would have to?  All it has to do it to look at the forwarding 
table, which it must be able to do anyway.

> that you will not have routing/forwarding loops.

I think the practice has shown this does not occur.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 9 Oct 2003 19:36:49 +0300 (EEST)