[c-nsp] Growing BGP tables

[lee.e.rian at census.gov]

I missed the part about this being configured only on a nontransit AS.  If
it's only for a stub AS then it seems like the worst case would be the stub
AS losing whatever service guarantees they have with their ISPs  ... or are
there ISPs that offer service guarantees for traffic that leaves their
network?

Lee




|---------+---------------------------->
|         |           Rodney Dunn      |
|         |           <rodunn at cisco.com|
|         |           >                |
|         |                            |
|         |           12/01/2004 09:18 |
|         |           AM               |
|         |                            |
|---------+---------------------------->
  >---------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                             |
  |       To:       lee.e.rian at census.gov                                                                                                       |
  |       cc:       Rodney Dunn <rodunn at cisco.com>, "David J. Hughes" <bambi at hughes.com.au>, "'cisco-nsp'" <cisco-nsp at puck.nether.net>, Gert    |
  |        Doering <gert at greenie.muc.de>, Brian Feeny <signal at shreve.net>                                                                       |
  |       Subject:  Re: [c-nsp] Growing BGP tables                                                                                              |
  >---------------------------------------------------------------------------------------------------------------------------------------------|




No.  I was talking about this only being configured
on the RouterA/Routerb pair Where that represents
it's own nontransit AS.

That's why I asked what deployment scenarios
are most of you asking about for this.

I see this more as a benefit for a stub AS
rather than any AS that is transit.

    AS1                      AS2
> > ISPA                    ISPB
> >  |                       |
> > RouterA  --- IBGP --- RouterB
     |---------- AS3 --------|

I put in the proposal the next hop check but
are you asking that is a less specific prefix
exist in the RIB then just dont' install a more
specific regardless of how/where that less specific
was learned?

Rodney




On Wed, Dec 01, 2004 at 08:59:13AM -0500, lee.e.rian at census.gov wrote:
>
> On 11/30/2004 10:30 PM, Rodney Dunn <rodunn at cisco.com> wrote:
>
> > I'm trying to put it together in my head
> > how it would be done for dual EBGP sessions.
> >
> > ie:
> >
> > ISPA                    ISPB
> >  |                       |
> > RouterA  --- IBGP --- RouterB
> >
> > Say I get a /16 and a /24 for a prefix from ISPA with
> > the same next hop so I wouldn't want to install the
> > /24.  But what happens if I get a /16 from ISPB and
> > that gets sent to RouterA.  That prefix would have
> > a next hop of Router B or ISPB so it would be a different
> > prefix and installed in the RIB.  Now the traffic that
> > was originally flowing to the /24 would take the backup
> > path (due to a longest match lookup) rather than the
> > path it would have taken if we had installed the original
> > /24. Would that be acceptable?
>
> I think not.
>
> Say RouterA advertises a /16 and a /24 within the /16 to ISPA, RouterB
> advertises the same /16 and a different /24 within the /16 to ISPB.
>
> If I'm understanding the proposal correctly, ISPA drops the /24 since it
> has the same next hop as the /16.  ISPB also drops their /24 since it has
> the same next hop as the /16.  If the link between RouterA and RouterB
goes
> down then ISPA, and all their customers, aren't going to be able to get
to
> siteB (the /24 advertised by RouterB) while ISPB, and all their
customers,
> aren't going to be able to get to siteA (the /24 advertised by RouterA).
>
> Lee
>