Subject: route selection and IGP synchronization
From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Date: Fri, 30 Oct 1998 01:36:07 PST

Hi,

  Suppose a IBGP prefix 'p' has a NEXTHOP which is synchronized but
  the IBGP prefix 'p' itself is not (yet) reachable through IGP
  can the route participate in BGP route selection? Is it considered 
  feasible (yet)?
  
  If the route can participate in route selection and causes a change
  in the active route, we still cannot advertise this route because
  of synchronization reasons but then the peers would have the earlier
  route until we synchronize...?

Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: Gunnar Lindberg <[email-masked]>
Date: Fri, 30 Oct 1998 10:02:53 +0100 (MET)
To: [email-masked], [email-masked], [email-masked]
Subject: BGP RFC & draft: 6.8 Connection collision detection.
Cc: [email-masked]
Sender: [email-masked]

This is an old question that a colleuage of mine brought up with
Yakov Rekhter quite some time ago. It exists both in RFC1771 and
draft-ietf-idr-bgp4-08.txt, and maybe we should get rid of it, i.e.
make the STD docs reflect reality and implementations.

It seems to us that "6.8 Connection collision detection" makes it
impossible to form parallel EBGP sessions between a pair of routers,
even if the sessions are over different interfaces/networks. E.g.

    =========================================
    =                                       =
    =              <- EBGP ->               =
    ========+=====================+==========
         ___|___       :       ___|___ 
        !       ! AS1  :  AS2 !       !
        !_______!      :      !_______!
            |          :          |
    --------+---------------------+----------
                   <- EBGP ->

What we do is set up EBGP sessions between the two routers over both
the FDDI and the Ethernet. This is for backup only, we use LocalPref
to control it and we want both connections to be up for a reasonably
fast switchover if the FDDI fails - it does not seem like a god idea
to start with TCP connect and route updates at that time; well, you
all get the picture.

In practice this works quite well (cisco equipment - we would assume
the same goes for other vendors, since this seems like a reasonable
thing to do).

But, according to "6.8 Connection collision detection", the routers
should compare the "BGP Identifier" and only keep the connection that
is initiated by the one with the highest value. See below.

This is true for multi-hop IBGP & EBGP, but not for *BGP interface-
to-interface, and the spec should clarify that. E.g:

    If the connection is over directly connected interfaces,
    connection collision is detected by comparing the IP address
    of the remote peer/connection, instead of the BGP Identifier.

Yes, I deliberatly want to allow parallel IBGP sessions interface-to-
interface as well - it is kind of weird, but I think we have a case
were it could be useful (but weird enough not to go public :-).

All of this seems to work well with existing cisco code and does not
seem to harm. I suggest an update to the spec.

	Gunnar Lindberg

------------------------------------------------------------------------
6.8 Connection collision detection.

 If a pair of BGP speakers try simultaneously to establish a TCP
 connection to each other, then two parallel connections between this
 pair of speakers might well be formed.  We refer to this situation as
 connection collision.  Clearly, one of these connections must be
 closed.

 Based on the value of the BGP Identifier a convention is established
 for detecting which BGP connection is to be preserved when a
 collision does occur. The convention is to compare the BGP
 Identifiers of the peers involved in the collision and to retain only
 the connection initiated by the BGP speaker with the higher-valued
 BGP Identifier.

 Upon receipt of an OPEN message, the local system must examine all of
 its connections that are in the OpenConfirm state.  A BGP speaker may
 also examine connections in an OpenSent state if it knows the BGP
 Identifier of the peer by means outside of the protocol.  If among
 these connections there is a connection to a remote BGP speaker whose
 BGP Identifier equals the one in the OPEN message, then the local
 system performs the following collision resolution procedure:

    1. The BGP Identifier of the local system is compared to the BGP
    Identifier of the remote system (as specified in the OPEN
    message).

    2. If the value of the local BGP Identifier is less than the
    remote one, the local system closes BGP connection that already
    exists (the one that is already in the OpenConfirm state), and
    accepts BGP connection initiated by the remote system.

    3. Otherwise, the local system closes newly created BGP connection
    (the one associated with the newly received OPEN message), and
    continues to use the existing one (the one that is already in the
    OpenConfirm state).

    Comparing BGP Identifiers is done by treating them as (4-octet
    long) unsigned integers.
 ...
------------------------------------------------------------------------

Date: Mon, 26 Oct 1998 23:50:49 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: NEXTHOP attribute requirement for aggregation
Sender: [email-masked]

|     When aggregating the prefixes that are originating in the local AS
|     the aspaths of these (routes) are empty (before propagating to 
|     EBGP neighbours)
|     So does the aspath aggregation algorithm becomes a trivial case of
|     aggregating "NULL" ASPATHS?

Yes.

|     Sorry for repeating :
|      For a route that is originating in the local AS and being 
|  redistributed into BGP there is no BGP-level NEXTHOP attribute at this 
|  time - is there? 

By definition it needs to be the box injecting the route into BGP.

|      (or) For a prefix 'p1' let's say the IGP nexthop is 'N1'
|            and a prefix 'p2' let's say the IGP nexthop is N2.
|        And consider these being  individually advertised 
|        (without aggregation )
|        let's say N1 is on the same subnet as a EBGP peer 'A'
|        So we advertise 'p1' with attribute 'N1'.
|  
|        And say N2 is on not on the same subnet as peer 'A'
|        and we advertise 'p2' with next-hop-self say N.
|  
|        Now when an aggregate of 'p1' and 'p2' takes effect
|        what nexthop do we choose? or can we aggregate 'p1' and 'p2'?

Note that it is legal to also advertise 'p1' with next-hop-self.  So the
only legal thing you can do is to adveritse the aggregate with
next-hop-self.

Tony

ps.  BTW, who do you work for?  I'd like to know where all of my training
efforts will appear...  ;-)

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: NEXTHOP attribute requirement for aggregation
Date: Mon, 26 Oct 1998 23:41:06 PST
Sender: [email-masked]

>|      (Also does the aspath aggregation apply for routes that are 
being 
>|  advertised from the local AS?)
>
>
>?  AS path aggregation as opposed to prefix aggregation?
>
>Tony
>
   I understand :
   When aggregating the prefixes that are originating in the local AS
   the aspaths of these (routes) are empty (before propagating to 
   EBGP neighbours)
   So does the aspath aggregation algorithm becomes a trivial case of
   aggregating "NULL" ASPATHS?
   
   Sorry for repeating :
    For a route that is originating in the local AS and being 
redistributed into BGP there is no BGP-level NEXTHOP attribute at this 
time - is there? 
    (or) For a prefix 'p1' let's say the IGP nexthop is 'N1'
          and a prefix 'p2' let's say the IGP nexthop is N2.
      And consider these being  individually advertised 
      (without aggregation )
      let's say N1 is on the same subnet as a EBGP peer 'A'
      So we advertise 'p1' with attribute 'N1'.

      And say N2 is on not on the same subnet as peer 'A'
      and we advertise 'p2' with next-hop-self say N.

      Now when an aggregate of 'p1' and 'p2' takes effect
      what nexthop do we choose? or can we aggregate 'p1' and 'p2'?
      
 Thanks for your time,
-Jaihari

 

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Mon, 26 Oct 1998 23:08:14 -0800 (PST)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: NEXTHOP attribute requirement for aggregation
Sender: [email-masked]

|     Section 9.2.4.2 aggregating routing information says :
|      Routes to be aggregated should have the same NEXT_HOP attribute
|  
|     Does this apply only for proxy aggregation?

No.  Note however that if the local system was going to effectively do a
next-hop-self (or similar) before aggregation, this would not apply.

The obvious problem is that if aggregation of some destination results in a
NEXT_HOP that's not viable (or not preferred, or does not have a matching
AS path) for that destination, then Bad Things (tm) would happen.

|      (Also does the aspath aggregation apply for routes that are being 
|  advertised from the local AS?)

?  AS path aggregation as opposed to prefix aggregation?

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: NEXTHOP attribute requirement for aggregation
Date: Mon, 26 Oct 1998 20:20:25 PST
Sender: [email-masked]

 Hi,
   Section 9.2.4.2 aggregating routing information says :
    Routes to be aggregated should have the same NEXT_HOP attribute

   Does this apply only for proxy aggregation?
   
   What would be the case for the routes that are originating from
   the BGP speaker's AS? (For e.g an IGP's routes that are redistributed 
into BGP carrying an origin of IGP and NULL ASPATH?)

    (Also does the aspath aggregation apply for routes that are being 
advertised from the local AS?)

Thanks,
-Jaihari.

   

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: aggregation unknown transitive attributes
Date: Thu, 15 Oct 1998 08:18:13 PDT
Sender: [email-masked]

Hi,
  How should an aggregation handle unknown transitive attributes in
  the aggregate contributors?

Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Wed, 14 Oct 1998 15:12:46 +0100
To: [email-masked]
From: Jan Sandmaier <[email-masked]>
Subject: BGP-4 Monitoring Tools
Sender: [email-masked]

Hi everybody,

i'm looking for a monitoring tool for BGP-4 routing for analyzing BGP-4
protocol
behavior, routing stability and detection of BGP-4 routing anomalies etc..

Does anybody know which tools are available and where I can get more
information
about them?

many thanks in advance,

Jan

---------------------------------------------------------------
Jan Sandmaier                  	Tel.: +49 6151 8383-61
DTAG Technology Center		Fax.: +49 6151 8344-21
Am Kavalleriesand 3			email: [email-masked]
D-64295 Darmstadt

Date: Fri, 9 Oct 1998 11:22:37 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: RFC1403 Section 4.4.6
Sender: [email-masked]

|    Section 4.4.6 says "An ASBR learning of routes with complete path 
|  info. and path length >=1 MUST wait for the BGP update from its
|  internal neighbours before advertising this route to external peers".
|    What does "before advertising *this route* to external peers" mean?

There's an English problem here.  Change 'this route' -> 'these routes'.

|    I understand :
|    We don't have an IBGP route yet.
|    And since this OSPF route was actually injected into the OSPF domain
|    by the IBGP peer, this route SHOULD not be re-exported into BGP (local 
|  speaker). 

Exactly.

|    Is *this route* here means the IBGP route?

Yes.

|    Just for clarification : Is this the reverse case of receiving an
|    IBGP route and waiting (for the prefix) to be synched with the IGP?

Yes.

Tony

To: "jaihari loganathan" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: RFC 1997 reserved communities 
Date: Fri, 09 Oct 1998 09:33:05 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date:    Fri, 09 Oct 1998 08:29:57 PDT
> From:    "jaihari loganathan" <[email-masked]>
> To:      [email-masked]

>   Folks,
> 
>   Any ideas what action to be taken when a reserved community
>   attribute appears in an incoming community list? (send a notification 
> ? )

Sending a notification would be problematic if IETF decides to
assign new well-known communities from the reserved pool. Such
a box would not be able to peer with boxes that send these
new communities.

Then the anwser is obvious, I think.  -- Enke

> 
> Thanks,
> -Jaihari
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: Please ignore previous question (RFC 1997)
Date: Fri, 09 Oct 1998 08:47:51 PDT
Sender: [email-masked]

 Bummer

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC 1997 reserved communities
Date: Fri, 09 Oct 1998 08:29:57 PDT
Sender: [email-masked]

  Folks,

  Any ideas what action to be taken when a reserved community
  attribute appears in an incoming community list? (send a notification 
? )

Thanks,
-Jaihari

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: RFC1403 Section 4.4.6
Date: Fri, 09 Oct 1998 05:39:57 PDT
Sender: [email-masked]

Hi,
  Section 4.4.6 says "An ASBR learning of routes with complete path 
info. and path length >=1 MUST wait for the BGP update from its
internal neighbours before advertising this route to external peers".
  What does "before advertising *this route* to external peers" mean?
  I understand :
  We don't have an IBGP route yet.
  And since this OSPF route was actually injected into the OSPF domain
  by the IBGP peer, this route SHOULD not be re-exported into BGP (local 
speaker). 
  
  Is *this route* here means the IBGP route?

  Just for clarification : Is this the reverse case of receiving an
  IBGP route and waiting (for the prefix) to be synched with the IGP?
Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

To: [email-masked]
Subject: draft-ietf-idr-aggregation-framework-03.txt
Date: Thu, 08 Oct 1998 13:17:12 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

I'd like to start the WG Last Call on advancing 
draft-ietf-idr-aggregation-framework-03.txt to an Informational RFC.

The deadline for commens is in two weeks (Oct 22).

Yakov.

Date: Thu, 8 Oct 1998 09:04:49 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: allowing policy to modify attributes
Sender: [email-masked]

|       Is there any constraint by the protocol in allowing attributes
|       of the outbound routes to be modified by policy.

Yes, lots.  Don't break the protocol.

|       For e.g : allowing an arbitrary as path to be prepended to 
|       the outbound route could cause looping.

Prepend cannot create loops because you never remove existing ASs from the
AS path.  

|         setting the NEXTHOP attribute wrongly could cause the routes
|         to be invalid 

Correct.  We obviously try not to do this, but can't prevent the user from,
for example, redistributing a static route that points to a black hole.

|         or set the origin to IGP for routes learnt from another EBGP
|         peer with origin set to initially to INCOMPLETE etc.

Hardly likely to cause a problem (tho might change path selection
preferences).

|       Should an implementation be cognizant of these and prevent such
|       attempts? Or does it fall outside the protocol's scope and
|       a bgp user is expected not to make such mistakes?

An implementation is simply a tool.  It cannot prevent its own misuse
without being artificially intelligent.  At the same time, it should not
gratuitously provide features which will encourage accidents that are
deleterious to global routing.

Tony

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: allowing policy to modify attributes
Date: Thu, 08 Oct 1998 01:07:01 PDT
Sender: [email-masked]

Folks,
     Is there any constraint by the protocol in allowing attributes
     of the outbound routes to be modified by policy.
     For e.g : allowing an arbitrary as path to be prepended to 
     the outbound route could cause looping.
       setting the NEXTHOP attribute wrongly could cause the routes
       to be invalid 
       or set the origin to IGP for routes learnt from another EBGP
       peer with origin set to initially to INCOMPLETE etc.

     Should an implementation be cognizant of these and prevent such
     attempts? Or does it fall outside the protocol's scope and
     a bgp user is expected not to make such mistakes?
Thanks,
-Jaihari

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Date: Thu, 8 Oct 1998 00:39:21 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: community attribute question
Sender: [email-masked]

|    Suppose for a prefix 'p' we chose a route 'r' with a community
|    attribute 'c' with value NO_ADVERTISE/NO_EXPORT
|    as the best route, and earlier we had chosen a different route
|    'r1' (as best route) which was being advertised to the peers, 
|    should we treat this like a outbound policy preventing the 
|    new route from being advertised - i.e withdraw the earlier 
|    route from the peers?

Yes.

Tony

From: Srihari Ramachandra <[email-masked]>
Subject: Re: community attribute question
To: [email-masked] (jaihari loganathan)
Date: Thu, 8 Oct 1998 00:17:17 -0700 (PDT)
Cc: [email-masked]
Sender: [email-masked]

> 
> Hi,
>   Suppose for a prefix 'p' we chose a route 'r' with a community
>   attribute 'c' with value NO_ADVERTISE/NO_EXPORT
>   as the best route, and earlier we had chosen a different route
>   'r1' (as best route) which was being advertised to the peers, 
>   should we treat this like a outbound policy preventing the 
>   new route from being advertised - i.e withdraw the earlier 
>   route from the peers?

yes.

> 
> Thanks,
> -Jaihari.
> 
> 
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
> 

From: "jaihari loganathan" <[email-masked]>
To: [email-masked]
Subject: community attribute question
Date: Thu, 08 Oct 1998 00:06:14 PDT
Sender: [email-masked]

Hi,
  Suppose for a prefix 'p' we chose a route 'r' with a community
  attribute 'c' with value NO_ADVERTISE/NO_EXPORT
  as the best route, and earlier we had chosen a different route
  'r1' (as best route) which was being advertised to the peers, 
  should we treat this like a outbound policy preventing the 
  new route from being advertised - i.e withdraw the earlier 
  route from the peers?

Thanks,
-Jaihari.

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

To: [email-masked], [email-masked]
cc: [email-masked]
Subject: bgp route advert - forwarded email
Date: Mon, 05 Oct 1998 13:38:14 -0400
From: Susan Hares <[email-masked]>
Sender: [email-masked]

------- Forwarded Message

Return-Path: [email-masked] 
Received: from merit.edu (merit.edu [198.108.1.42]) by home.merit.edu 
(8.8.8/merit-2.0) with ESMTP id OAA05693 for <[email-masked]>; Fri, 2 Oct 
1998 14:12:02 -0400 (EDT)
From: [email-masked]
Received: (from majordom@localhost)
	by merit.edu (8.8.7/8.8.5) id OAA03778;
	Fri, 2 Oct 1998 14:12:01 -0400 (EDT)
Date: Fri, 2 Oct 1998 14:12:01 -0400 (EDT)
Message-Id: <[email-masked]>
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Bradley Reynolds 
<[email-masked]>]

>From idr-owner  Fri Oct  2 14:11:55 1998
Date: Fri, 2 Oct 1998 14:06:03 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: [email-masked]
Subject: bgp route advert.  

I was reading over 1771 again and came upon something
for which I need clarification.

When I send an update to my peer, the rfc specifies
that I can one advertise one route.  Does this mean
that I can advertise multiple prefixes which have the
same route to the destination in one update message?
(same NLRI)  It seems as though the vendor implementation 
supports my advertisement of multiple prefixes with the 
same nlri but only advertises one prefix per update back
to myself (cisco).   

so, one question is for clarification of updates/routes
and advertisement of multiple prefixes.  Secondly, if you
can advert multiple prefixes, how is the determination 
made between small spurious messages which if lost
do not cause large problems, and large multiple prefix advertisements?

I am running my bgp implementation on a p200 and my neighbor
is a RSP2 (128mb ram) over uncongested links.  Neither CPU is 
touched.   When I converged on a RSP2->RSP2 the CPU is not 
touched on either side.  (note that I did not try bringing
up the full mesh but only one peer who adverted ~ 28k prefixes).  

BR

------- End of Forwarded Message

To: Alejandro Avella <[email-masked]>
cc: IDR List <[email-masked]>, [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Memory Requirements for BGP-4 (RFC-1774) 
Date: Mon, 05 Oct 1998 13:32:37 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Alejandro Avella writes:
> Hi,
> 
> I believe there is a typo on page 7 of RFC-1774, but I am not sure so
> I wanted to check with someone. Can you help me?
> 
> In the table for memory requirements it says that:
> 
> #Networks (N) = 100,000
> Mean AS Distance (M) = 20
> # AS (A) = 3,000
> # BGP Peers/per net (K) = 20
> DestMem = 4 bytes
> ASMem = 2 bytes
> Memory Requirement (MR) = 1,040,000 bytes (IS THIS CORRECT???)
> 
> I think the right value is 10,400,000 bytes ~ 10 MBytes.
> 
> Here it is the formula:
> 
> MR = [DestMem * N + ASMem * A * M ] * K
> 
> MR = [4 * N + 2 * A * M ] * K
> 
> MR = [4 * 100,000 + 2 * 20 * 3000 ] * 20
> 
> MR = 10,400,000 bytes
> 
> Am I missing something or Am I correct?
> 
> Thanks,
> 
> -Alejandro
> 
> RFC-1774 -->
> http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1774.txt
> 

Your computation is correct.  A smart implementation will recognized
that there are a small set of AS path combinations that account for
the majority of routes and keep unique AS paths in another struct and
point to it.  This requires only 4 bytes to reference AS path, 2 if
you use a table.  Gated does this (the 4 byte pointer).  You also need
a hash table or some other means to make sure you can find a specific
struct quickly.

Curtis

To: Alejandro Avella <[email-masked]>
cc: IDR List <[email-masked]>, [email-masked], [email-masked], [email-masked]
Reply-To: [email-masked]
Subject: Re: Memory Requirements for BGP-4 (RFC-1774) 
Date: Mon, 05 Oct 1998 13:32:37 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Alejandro Avella writes:
> Hi,
> 
> I believe there is a typo on page 7 of RFC-1774, but I am not sure so
> I wanted to check with someone. Can you help me?
> 
> In the table for memory requirements it says that:
> 
> #Networks (N) = 100,000
> Mean AS Distance (M) = 20
> # AS (A) = 3,000
> # BGP Peers/per net (K) = 20
> DestMem = 4 bytes
> ASMem = 2 bytes
> Memory Requirement (MR) = 1,040,000 bytes (IS THIS CORRECT???)
> 
> I think the right value is 10,400,000 bytes ~ 10 MBytes.
> 
> Here it is the formula:
> 
> MR = [DestMem * N + ASMem * A * M ] * K
> 
> MR = [4 * N + 2 * A * M ] * K
> 
> MR = [4 * 100,000 + 2 * 20 * 3000 ] * 20
> 
> MR = 10,400,000 bytes
> 
> Am I missing something or Am I correct?
> 
> Thanks,
> 
> -Alejandro
> 
> RFC-1774 -->
> http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1774.txt
> 

Your computation is correct.  A smart implementation will recognized
that there are a small set of AS path combinations that account for
the majority of routes and keep unique AS paths in another struct and
point to it.  This requires only 4 bytes to reference AS path, 2 if
you use a table.  Gated does this (the 4 byte pointer).  You also need
a hash table or some other means to make sure you can find a specific
struct quickly.

Curtis

Date: Sat, 3 Oct 1998 20:14:40 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Memory Requirements for BGP-4 (RFC-1774)
Sender: [email-masked]

You are correct.  

Tony

|  I believe there is a typo on page 7 of RFC-1774, but I am not sure so
|  I wanted to check with someone. Can you help me?
|
|  MR = 10,400,000 bytes
|  
|  Am I missing something or Am I correct?

Date: Sat, 3 Oct 1998 20:14:40 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Memory Requirements for BGP-4 (RFC-1774)
Sender: [email-masked]

You are correct.  

Tony

|  I believe there is a typo on page 7 of RFC-1774, but I am not sure so
|  I wanted to check with someone. Can you help me?
|
|  MR = 10,400,000 bytes
|  
|  Am I missing something or Am I correct?

Date: Sat, 03 Oct 1998 20:27:08 -0600
From: Alejandro Avella <[email-masked]>
To: IDR List <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Memory Requirements for BGP-4 (RFC-1774)
Sender: [email-masked]

Hi,

I believe there is a typo on page 7 of RFC-1774, but I am not sure so
I wanted to check with someone. Can you help me?

In the table for memory requirements it says that:

#Networks (N) = 100,000
Mean AS Distance (M) = 20
# AS (A) = 3,000
# BGP Peers/per net (K) = 20
DestMem = 4 bytes
ASMem = 2 bytes
Memory Requirement (MR) = 1,040,000 bytes (IS THIS CORRECT???)

I think the right value is 10,400,000 bytes ~ 10 MBytes.

Here it is the formula:

MR = [DestMem * N + ASMem * A * M ] * K

MR = [4 * N + 2 * A * M ] * K

MR = [4 * 100,000 + 2 * 20 * 3000 ] * 20

MR = 10,400,000 bytes

Am I missing something or Am I correct?

Thanks,

-Alejandro

RFC-1774 -->
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1774.txt

Date: Sat, 03 Oct 1998 20:27:08 -0600
From: Alejandro Avella <[email-masked]>
To: IDR List <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Memory Requirements for BGP-4 (RFC-1774)
Sender: [email-masked]

Hi,

I believe there is a typo on page 7 of RFC-1774, but I am not sure so
I wanted to check with someone. Can you help me?

In the table for memory requirements it says that:

#Networks (N) = 100,000
Mean AS Distance (M) = 20
# AS (A) = 3,000
# BGP Peers/per net (K) = 20
DestMem = 4 bytes
ASMem = 2 bytes
Memory Requirement (MR) = 1,040,000 bytes (IS THIS CORRECT???)

I think the right value is 10,400,000 bytes ~ 10 MBytes.

Here it is the formula:

MR = [DestMem * N + ASMem * A * M ] * K

MR = [4 * N + 2 * A * M ] * K

MR = [4 * 100,000 + 2 * 20 * 3000 ] * 20

MR = 10,400,000 bytes

Am I missing something or Am I correct?

Thanks,

-Alejandro

RFC-1774 -->
http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1774.txt

To: Tony Li <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: bgp route advert. 
Date: Fri, 02 Oct 1998 16:14:31 -0700
From: Ravi Chandra <[email-masked]>
Sender: [email-masked]

> 
> |  Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
> |  with my box and counted the number of 16 {0xff} headers and came
> |  out around 29k.  So it would seem that cisco is 1prefix/update
> |  or my program is messed up.
> 
> 
> Hmmmm oh Ravi.....  ;-)

I am here ;-)

> 

well, Brad we need to see what are the attributes that u r exchanging
ie if the attributes are different we will use different messages.

How about you sending us some more info like 'sh ver', 'sh ip bgp
summary'.. Lets see what is going on.

btw, it is preferable to handle it offline.

tnx.

--ravi

> 
> |  > Because BGP runs on top of TCP, no messages are lost.
> |  > 
> |  I was not talking about lost during the duration of the connection,
> |  but in a smaller timeslice where (assuming window size scales 
> |  with packet size.. which may be erroneous.. have to get out
> |  tcpdump to see.) it is more painful to retransmit sizeof(largeadvert).
> 
> 
> I don't follow.  TCP provides an ordered reliable transport.
> 
> Tony

To: Bradley Reynolds <[email-masked]>
cc: Enke Chen <[email-masked]>, [email-masked]
Subject: Re: bgp route advert. 
Date: Fri, 02 Oct 1998 15:21:33 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date:    Fri, 2 Oct 1998 17:55:55 +0000 (GMT)
> From:    Bradley Reynolds <[email-masked]>
> To:      Enke Chen <[email-masked]>
> CC:      [email-masked]

> > > I cleared out a cisco->cisco bgp session.  Here is what I got
> > > once all routes were re-adverted.  
> > > 
> > > Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/
PfxR
> > cd 
> > > 131.103.0.1     4  1225   29227       8    29759    0    0 00:05:34 29107
> > > 
> > > Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
> > > with my box and counted the number of 16 {0xff} headers and came
> > > out around 29k.  So it would seem that cisco is 1prefix/update
> > > or my program is messed up.
> > 
> > A simpler way to count is to compare the two "MsgRcvd" numbers (before, and
> > after).
> >
> Considering msgrecv and #prefixes recv were nearly equal, I inferred
> 1 to 1.  (i had just reset the session 5 minutes ago).
> 
> > If the result is close to 1 pfx/update, most likely it means that
> > you have huge number of attributes on the sender which makes it
> > not possible to pack prefixes. How about "sho ip bgp sum" on the
> > sender?
> > 
> I don't think so:
> 
> 29260 network entries (29260/87780 paths) using 6108204 bytes of memory
> 3904 BGP path attribute entries using 512184 bytes of memory
> 
> Which is on the router who peers with 131.103.0.1.
> 

Let me clarify.  The number of unique attribues shown in "sho ip bgp sum"
does not include the next-hop.  It is the tuple <attr, nexthop> that
would determine if prefixes can be packed into one update. Obviously if
the router is doing route reflection, or passing third party next-hop,
the number of <attr, nexthop> could increase dramatically. Also, an
outbound route-map typically would also decrease the packing efficiency.
Please check on these.

In any case, the issue does not seem to involve the BGP spec.. Let us
move this to a private discussion.

-- Enke

Date: Fri, 2 Oct 1998 17:55:55 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: Enke Chen <[email-masked]>
cc: [email-masked]
Subject: Re: bgp route advert. 
Sender: [email-masked]

> > I cleared out a cisco->cisco bgp session.  Here is what I got
> > once all routes were re-adverted.  
> > 
> > Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxR
> cd 
> > 131.103.0.1     4  1225   29227       8    29759    0    0 00:05:34 29107
> > 
> > Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
> > with my box and counted the number of 16 {0xff} headers and came
> > out around 29k.  So it would seem that cisco is 1prefix/update
> > or my program is messed up.
> 
> A simpler way to count is to compare the two "MsgRcvd" numbers (before, and
> after).
>
Considering msgrecv and #prefixes recv were nearly equal, I inferred
1 to 1.  (i had just reset the session 5 minutes ago).

> If the result is close to 1 pfx/update, most likely it means that
> you have huge number of attributes on the sender which makes it
> not possible to pack prefixes. How about "sho ip bgp sum" on the
> sender?
> 
I don't think so:

29260 network entries (29260/87780 paths) using 6108204 bytes of memory
3904 BGP path attribute entries using 512184 bytes of memory

Which is on the router who peers with 131.103.0.1.

To: Bradley Reynolds <[email-masked]>
cc: Tony Li <[email-masked]>, [email-masked], [email-masked]
Subject: Re: bgp route advert. 
Date: Fri, 02 Oct 1998 14:50:49 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date:    Fri, 2 Oct 1998 17:15:12 +0000 (GMT)
> From:    Bradley Reynolds <[email-masked]>
> To:      Tony Li <[email-masked]>
> CC:      [email-masked]

> > |  supports my advertisement of multiple prefixes with the 
> > |  same nlri but only advertises one prefix per update back
> > |  to myself (cisco).   
> > 
> > 
> > One update per NLRI from a Cisco?  I find that somewhat hard to believe.
> > 
> I cleared out a cisco->cisco bgp session.  Here is what I got
> once all routes were re-adverted.  
> 
> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxR
cd 
> 131.103.0.1     4  1225   29227       8    29759    0    0 00:05:34 29107
> 
> Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
> with my box and counted the number of 16 {0xff} headers and came
> out around 29k.  So it would seem that cisco is 1prefix/update
> or my program is messed up.

A simpler way to count is to compare the two "MsgRcvd" numbers (before, and
after).

If the result is close to 1 pfx/update, most likely it means that
you have huge number of attributes on the sender which makes it
not possible to pack prefixes. How about "sho ip bgp sum" on the
sender?

-- Enke

> 
> > |  so, one question is for clarification of updates/routes
> > |  and advertisement of multiple prefixes.  Secondly, if you
> > |  can advert multiple prefixes, how is the determination 
> > |  made between small spurious messages which if lost
> > |  do not cause large problems, and large multiple prefix advertisements?
> > 
> > 
> > Because BGP runs on top of TCP, no messages are lost.
> > 
> I was not talking about lost during the duration of the connection,
> but in a smaller timeslice where (assuming window size scales 
> with packet size.. which may be erroneous.. have to get out
> tcpdump to see.) it is more painful to retransmit sizeof(largeadvert).
> 
> 
> BR
> 

From: Srihari Ramachandra <[email-masked]>
Subject: Re: bgp route advert.
To: [email-masked] (Bradley Reynolds)
Date: Fri, 2 Oct 1998 14:42:48 -0700 (PDT)
Cc: [email-masked], [email-masked]
Sender: [email-masked]

> 
> > |  supports my advertisement of multiple prefixes with the 
> > |  same nlri but only advertises one prefix per update back
> > |  to myself (cisco).   
> > 
> > 
> > One update per NLRI from a Cisco?  I find that somewhat hard to believe.
> > 
> I cleared out a cisco->cisco bgp session.  Here is what I got
> once all routes were re-adverted.  
> 
> Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd 
> 131.103.0.1     4  1225   29227       8    29759    0    0 00:05:34 29107
> 
> Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
> with my box and counted the number of 16 {0xff} headers and came
> out around 29k.  So it would seem that cisco is 1prefix/update
> or my program is messed up.

We have not seen such a behaviour. Can you please tell us which version you
are seeing. Thanks.

srihari...

> 
> > |  so, one question is for clarification of updates/routes
> > |  and advertisement of multiple prefixes.  Secondly, if you
> > |  can advert multiple prefixes, how is the determination 
> > |  made between small spurious messages which if lost
> > |  do not cause large problems, and large multiple prefix advertisements?
> > 
> > 
> > Because BGP runs on top of TCP, no messages are lost.
> > 
> I was not talking about lost during the duration of the connection,
> but in a smaller timeslice where (assuming window size scales 
> with packet size.. which may be erroneous.. have to get out
> tcpdump to see.) it is more painful to retransmit sizeof(largeadvert).
> 
> 
> BR
> 
> 

Date: Fri, 2 Oct 1998 14:24:33 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: bgp route advert.
Sender: [email-masked]

|  Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
|  with my box and counted the number of 16 {0xff} headers and came
|  out around 29k.  So it would seem that cisco is 1prefix/update
|  or my program is messed up.

Hmmmm oh Ravi.....  ;-)

|  > Because BGP runs on top of TCP, no messages are lost.
|  > 
|  I was not talking about lost during the duration of the connection,
|  but in a smaller timeslice where (assuming window size scales 
|  with packet size.. which may be erroneous.. have to get out
|  tcpdump to see.) it is more painful to retransmit sizeof(largeadvert).

I don't follow.  TCP provides an ordered reliable transport.

Tony

Date: Fri, 2 Oct 1998 17:15:12 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: Tony Li <[email-masked]>
cc: [email-masked]
Subject: Re: bgp route advert.
Sender: [email-masked]

> |  supports my advertisement of multiple prefixes with the 
> |  same nlri but only advertises one prefix per update back
> |  to myself (cisco).   
> 
> 
> One update per NLRI from a Cisco?  I find that somewhat hard to believe.
> 
I cleared out a cisco->cisco bgp session.  Here is what I got
once all routes were re-adverted.  

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd 
131.103.0.1     4  1225   29227       8    29759    0    0 00:05:34 29107

Just to make sure that this wasn't a cisco bug, I peered 131.103.0.1
with my box and counted the number of 16 {0xff} headers and came
out around 29k.  So it would seem that cisco is 1prefix/update
or my program is messed up.

> |  so, one question is for clarification of updates/routes
> |  and advertisement of multiple prefixes.  Secondly, if you
> |  can advert multiple prefixes, how is the determination 
> |  made between small spurious messages which if lost
> |  do not cause large problems, and large multiple prefix advertisements?
> 
> 
> Because BGP runs on top of TCP, no messages are lost.
> 
I was not talking about lost during the duration of the connection,
but in a smaller timeslice where (assuming window size scales 
with packet size.. which may be erroneous.. have to get out
tcpdump to see.) it is more painful to retransmit sizeof(largeadvert).

BR

Date: Fri, 2 Oct 1998 13:58:21 -0700 (PDT)
From: Tony Li <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: bgp route advert.
Sender: [email-masked]

|  When I send an update to my peer, the rfc specifies
|  that I can one advertise one route.  Does this mean
|  that I can advertise multiple prefixes which have the
|  same route to the destination in one update message?

In particular, you can advertise as many prefixes as can fit in the update
message as long as they have the same attributes.

|  (same NLRI)  It seems as though the vendor implementation 
|  supports my advertisement of multiple prefixes with the 
|  same nlri but only advertises one prefix per update back
|  to myself (cisco).   

One update per NLRI from a Cisco?  I find that somewhat hard to believe.

|  so, one question is for clarification of updates/routes
|  and advertisement of multiple prefixes.  Secondly, if you
|  can advert multiple prefixes, how is the determination 
|  made between small spurious messages which if lost
|  do not cause large problems, and large multiple prefix advertisements?

Because BGP runs on top of TCP, no messages are lost.

Tony

Date: Fri, 2 Oct 1998 15:25:46 +0000 (GMT)
From: Bradley Reynolds <[email-masked]>
To: [email-masked]
Subject: bgp route advert.  
Sender: [email-masked]

I was reading over 1771 again and came upon something
for which I need clarification.

When I send an update to my peer, the rfc specifies
that I can one advertise one route.  Does this mean
that I can advertise multiple prefixes which have the
same route to the destination in one update message?
(same NLRI)  It seems as though the vendor implementation 
supports my advertisement of multiple prefixes with the 
same nlri but only advertises one prefix per update back
to myself (cisco).   

so, one question is for clarification of updates/routes
and advertisement of multiple prefixes.  Secondly, if you
can advert multiple prefixes, how is the determination 
made between small spurious messages which if lost
do not cause large problems, and large multiple prefix advertisements?

I am running my bgp implementation on a p200 and my neighbor
is a RSP2 (128mb ram) over uncongested links.  Neither CPU is 
touched.   When I converged on a RSP2->RSP2 the CPU is not 
touched on either side.  (note that I did not try bringing
up the full mesh but only one peer who adverted ~ 28k prefixes).  

BR