Subject: Re: Questions about "Capabilities Negotiation"
From: Enke Chen <[email-masked]>
To: "Rijsman, Bruno" <[email-masked]>
Cc: BGP exploder <[email-masked]>, IDRP exploder <[email-masked]>, [email-masked]
Date: Thu, 14 Oct 1999 12:17:47 -0700

Some comments in-lined.

> I have some questions about "Capabilities Negotiation with BGP-4
> (draft-ietf-
> idr-bgp4-cap-neg-04.txt)".
> 
> Consider the following example with BGP speakers X and Y:
> 
> X ----------- Y
>    <-OPEN--
>    --OPEN->
> 
> Let's assume that both X and Y support capability negotiation in the sense 
> that they understand the "capabilities" option in received OPEN messages.
> 
> Let's also assume that X does not support any capabilities, and that Y 
> supports two capabilities (let's call them capabilities A and B).
> 
> Given this scenario, what would be the answers to the following questions:
> 
> (1) Is X allowed to ommit the "capabilities" option from the OPEN message 
>     which it sends to Y? 

Yes. In this case it should be assumed that X has "ipv4-unicast"
capability (the default capability).

>     Or will the absence of the capabilities option 
>     cause Y to conclude that X does not support capability negotiation at 
>     all? 

No. In general capability announcement are not required to be
bi-directional. (route refresh as an example). But some capabilities
(such as address families) may not make sense if not bi-directional.

> Does it matter?

Probably :-)

> 
>     I assume that X is allowed to omit the capabilities option from its 
>     OPEN message if it doesn't have any capabilities to report. This can 
>     avoid an "unsupported optional parameter" NOTIFICATION and a subsequent 
>     re-establishment of a BGP connection if Y does not support capability 
>     negotiation.

Sending notification for "unsupported optional parameter" is a poor
concept, and certainly a broken practice.  It basically makes
"optional" as "mandatory", and makes it difficult to introduce
new options (such as the capability).

> 
> (2) I would like to verify that the following interpretation of the draft 
>     is correct:
> 
>     X receives the OPEN message from Y containing the "capabilities" option 
>     with capabilities A and B. Even though the OPEN message from Y contains 
>     two capabilities which X does not support, X MUST NOT send an 
>     "unsupported capability" option to Y. Instead, X must rely on Y to 
>     notice that X doesn't support capabilities A and B (Y knows this 
>     because of the OPEN message from X). At this point Y has two choices. 
>     Either Y continues the peering (i.e. sends a KEEP-ALIVE) but does not 
>     use capabilities A and B. Or Y insists on using capabilities A or B or 
>     both and sends an "unsupported capability" NOTIFICATION specifying 
>     which capabilities it insists on.
> 
>     Bottom line: The burden for sending an "unsupported capability" 
>     NOTIFICATION is on the BGP speaker which supports the capability and 
>     insists on using it; the burden is NOT on the BGP speaker which doesn't 
>     understand the capability.

True if you change "insists on using it" to "insists on the other side
advertising it". 

However, the only practical case that I can think of for sending
"unsupported capability" might be when both sides do not share any
address-family capabilities.

> 
>     Corollary: Node X (which supports capability negotiation but no 
>     specific capabilities) can safely ignore capabilities options in 
>     incoming OPEN messages.

Depends on your answer to the philosophical question of whether it is
ok to bring up a peer between two sides w/ disjoint address-family
capabilities.

> 
> (3) It is allowed to have multiple capabilities options in a single OPEN 
>     message? This might be necessary if the capabilities don't fit in a 255 
>     bytes, but it makes parsing the OPEN message more difficult (we must 
>     parse the whole message before we really know the complete set of 
>     proposed capabilities - see also item (2) above).

There might be different implementations out there. It is better to
be defensive in receiving (i.e., accept and deal with it).

-- Enke

> 
> Corollary of (1) and (2): a "minimal implementation" of capability 
> negotiation is as follows:
> (a) Don't include the capability option is sent OPEN messages.
> (b) Ignore the capability option in received OPEN messages.
> (c) Process received "unsupported capability" NOTIFICATIONS in the same way 
>     as the existing errors (i.e. go to the idle state).
> 
> Thanks,
> 
> Bruno Rijsman
> Unisphere
> 

From: "Rijsman, Bruno" <[email-masked]>
To: BGP exploder <[email-masked]>, IDRP exploder <[email-masked]>
Subject: Questions about "Capabilities Negotiation"
Date: Thu, 14 Oct 1999 12:59:21 -0400
Sender: [email-masked]

I have some questions about "Capabilities Negotiation with BGP-4
(draft-ietf-
idr-bgp4-cap-neg-04.txt)".

Consider the following example with BGP speakers X and Y:

X ----------- Y
   <-OPEN--
   --OPEN->

Let's assume that both X and Y support capability negotiation in the sense 
that they understand the "capabilities" option in received OPEN messages.

Let's also assume that X does not support any capabilities, and that Y 
supports two capabilities (let's call them capabilities A and B).

Given this scenario, what would be the answers to the following questions:

(1) Is X allowed to ommit the "capabilities" option from the OPEN message 
    which it sends to Y? Or will the absence of the capabilities option 
    cause Y to conclude that X does not support capability negotiation at 
    all? Does it matter?

    I assume that X is allowed to omit the capabilities option from its 
    OPEN message if it doesn't have any capabilities to report. This can 
    avoid an "unsupported optional parameter" NOTIFICATION and a subsequent 
    re-establishment of a BGP connection if Y does not support capability 
    negotiation.

(2) I would like to verify that the following interpretation of the draft 
    is correct:

    X receives the OPEN message from Y containing the "capabilities" option 
    with capabilities A and B. Even though the OPEN message from Y contains 
    two capabilities which X does not support, X MUST NOT send an 
    "unsupported capability" option to Y. Instead, X must rely on Y to 
    notice that X doesn't support capabilities A and B (Y knows this 
    because of the OPEN message from X). At this point Y has two choices. 
    Either Y continues the peering (i.e. sends a KEEP-ALIVE) but does not 
    use capabilities A and B. Or Y insists on using capabilities A or B or 
    both and sends an "unsupported capability" NOTIFICATION specifying 
    which capabilities it insists on.

    Bottom line: The burden for sending an "unsupported capability" 
    NOTIFICATION is on the BGP speaker which supports the capability and 
    insists on using it; the burden is NOT on the BGP speaker which doesn't 
    understand the capability.

    Corollary: Node X (which supports capability negotiation but no 
    specific capabilities) can safely ignore capabilities options in 
    incoming OPEN messages.

(3) It is allowed to have multiple capabilities options in a single OPEN 
    message? This might be necessary if the capabilities don't fit in a 255 
    bytes, but it makes parsing the OPEN message more difficult (we must 
    parse the whole message before we really know the complete set of 
    proposed capabilities - see also item (2) above).

Corollary of (1) and (2): a "minimal implementation" of capability 
negotiation is as follows:
(a) Don't include the capability option is sent OPEN messages.
(b) Ignore the capability option in received OPEN messages.
(c) Process received "unsupported capability" NOTIFICATIONS in the same way 
    as the existing errors (i.e. go to the idle state).

Thanks,

Bruno Rijsman
Unisphere

From: Greg Mirsky <[email-masked]>
To: Ben Abarbanel <[email-masked]>, James B <[email-masked]>
Cc: [email-masked]
Subject: RE: Update send process
Date: Wed, 6 Oct 1999 13:52:22 -0400
Sender: [email-masked]

Ben,
Routing Table Manager(RTM) should select the best route among submitted
from routing protocols, static and directly connected according to
certain rules. Routing protocols must be informed of this decision.
Thus RTM makes the last call on which route to be used.
Hope it answers your question.

	Greg

> -----Original Message-----
> From:	Ben Abarbanel [SMTP:[email-masked]]
> Sent:	Friday, October 01, 1999 12:23 PM
> To:	James B
> Cc:	[email-masked]
> Subject:	Re: Update send process
> 
> So from what you guys are saying the route selection process at the
> forwarding
> table must be synchronized with each of the routing protocols. In
> other words
> all route selection filtering done at the Routing/Forwarding table
> must be
> converged the same way it is with each individual routing protocol
> (i.e. BGP,
> OSPF, ISIS, RIP, etc.) where multiple routes exist to same destination
> from
> different protocols.
> 
> The case were I see a major problem is if all routing protocols import
> their
> routes to the forwarding table but not to each other.
> 
> I  think we hit upon a very sensitive chord here.
> 
> Ben
> 
> James B wrote:
> 
> > >Not quite.  I'm saying that if you define static routes and you run
> > >BGP, and if a static route overrides a BGP-learned route, then you
> > >should not advertise the BGP-learned route since you are not using
> it
> > >for forwarding.  It's (as they say) a matter of local policy
> whether
> > >you advertise the static route via BGP or not.  Always exporting
> > >static to BGP would be one way of doing it, but certainly not the
> > >only way.
> > >
> >
> > I tend to agree with this behaviour. It only makes sense that
> routing
> > information that you propagate across your AS and to other ASs is
> indeed
> > what you use for actually forwarding traffic. Otherwise, downstream
> routers
> > may land up making policy decisions based on path attributes that
> are not
> > necessarily the correct path attributes associated with the route
> that
> > traffic is actually forwarded on. (resulting in potential forwarding
> loops,
> > among other things).
> >
> > In addition, I don't think that mandating exporting of static routes
> to BGP
> > is the right way to go. That is a local policy decision and should
> be left
> > to the administrator. What is important however, is that in such a
> > situation, the behaviour of routers is consistent (which I think
> would be
> > accomplished by the suggested modification that John made).
> >
> > One other minor point. I think I had asked this earlier. If the
> above
> > behavior is the correct behavior, then I take it this applies to
> > redistributing to internal as well as external BGP peers? In the
> paragaph
> > that Yakov pointed out from the I-D, the reference is explicitly to
> > readvertising to neighboring ASs (implying only EBGP nbrs). Should
> the spec
> > be modified to remove this explicit reference?
> >
> > Thanks
> >
> > -Sanjay
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com
> 

From: Greg Mirsky <[email-masked]>
To: Ben Abarbanel <[email-masked]>, James B <[email-masked]>
Cc: [email-masked]
Subject: RE: Update send process
Date: Wed, 6 Oct 1999 13:52:22 -0400
Sender: [email-masked]

Ben,
Routing Table Manager(RTM) should select the best route among submitted
from routing protocols, static and directly connected according to
certain rules. Routing protocols must be informed of this decision.
Thus RTM makes the last call on which route to be used.
Hope it answers your question.

	Greg

> -----Original Message-----
> From:	Ben Abarbanel [SMTP:[email-masked]]
> Sent:	Friday, October 01, 1999 12:23 PM
> To:	James B
> Cc:	[email-masked]
> Subject:	Re: Update send process
> 
> So from what you guys are saying the route selection process at the
> forwarding
> table must be synchronized with each of the routing protocols. In
> other words
> all route selection filtering done at the Routing/Forwarding table
> must be
> converged the same way it is with each individual routing protocol
> (i.e. BGP,
> OSPF, ISIS, RIP, etc.) where multiple routes exist to same destination
> from
> different protocols.
> 
> The case were I see a major problem is if all routing protocols import
> their
> routes to the forwarding table but not to each other.
> 
> I  think we hit upon a very sensitive chord here.
> 
> Ben
> 
> James B wrote:
> 
> > >Not quite.  I'm saying that if you define static routes and you run
> > >BGP, and if a static route overrides a BGP-learned route, then you
> > >should not advertise the BGP-learned route since you are not using
> it
> > >for forwarding.  It's (as they say) a matter of local policy
> whether
> > >you advertise the static route via BGP or not.  Always exporting
> > >static to BGP would be one way of doing it, but certainly not the
> > >only way.
> > >
> >
> > I tend to agree with this behaviour. It only makes sense that
> routing
> > information that you propagate across your AS and to other ASs is
> indeed
> > what you use for actually forwarding traffic. Otherwise, downstream
> routers
> > may land up making policy decisions based on path attributes that
> are not
> > necessarily the correct path attributes associated with the route
> that
> > traffic is actually forwarded on. (resulting in potential forwarding
> loops,
> > among other things).
> >
> > In addition, I don't think that mandating exporting of static routes
> to BGP
> > is the right way to go. That is a local policy decision and should
> be left
> > to the administrator. What is important however, is that in such a
> > situation, the behaviour of routers is consistent (which I think
> would be
> > accomplished by the suggested modification that John made).
> >
> > One other minor point. I think I had asked this earlier. If the
> above
> > behavior is the correct behavior, then I take it this applies to
> > redistributing to internal as well as external BGP peers? In the
> paragaph
> > that Yakov pointed out from the I-D, the reference is explicitly to
> > readvertising to neighboring ASs (implying only EBGP nbrs). Should
> the spec
> > be modified to remove this explicit reference?
> >
> > Thanks
> >
> > -Sanjay
> >
> > ______________________________________________________
> > Get Your Private, Free Email at http://www.hotmail.com
> 

Date: Wed, 06 Oct 1999 11:00:43 -0400
From: Ben Abarbanel <[email-masked]>
To: [email-masked]
Subject: Re: Is this list working
Sender: [email-masked]

Thank You all for such a spontaneous response.

I appreciate it. I saw a bunch of messages and all of a sudden nothing. Its
good to know
we are still communicating.

Best Regards,
Ben

Srivathsan Srinivasagopalan wrote:

> Yes. I see it...Best effort sevice is working preoperly...and of course
> the list is quite active.
>
> Srivathsan Srinivasagopalan (Vathsan Sri)
>
> Router Management Lab                   ESN:     248-6057
> Nortel Networks                         Ph : 978-288-6057
> Billerica, MA 01821                     Fax: 978-670-8145
> _________________________________________________________
>
> On Wed, 6 Oct 1999, Ben Abarbanel wrote:
>
> > Testing to see if list is functional. Anybody get this message?
> >
> >
> >

Date: Wed, 6 Oct 1999 10:20:56 -0400 (EDT)
From: Srivathsan Srinivasagopalan <[email-masked]>
To: Ben Abarbanel <[email-masked]>
Cc: [email-masked]
Subject: Re: Is this list working
Sender: [email-masked]

Yes. I see it...Best effort sevice is working preoperly...and of course
the list is quite active.

Srivathsan Srinivasagopalan (Vathsan Sri)

Router Management Lab			ESN:     248-6057
Nortel Networks				Ph : 978-288-6057
Billerica, MA 01821			Fax: 978-670-8145
_________________________________________________________	

On Wed, 6 Oct 1999, Ben Abarbanel wrote:

> Testing to see if list is functional. Anybody get this message?
> 
> 
> 

Date: Wed, 06 Oct 1999 09:45:48 -0400
From: Ben Abarbanel <[email-masked]>
To: [email-masked]
Subject: Is this list working
Sender: [email-masked]

Testing to see if list is functional. Anybody get this message?

Date: Mon, 4 Oct 1999 14:18:27 -0400 (EDT)
From: Susan Hares <[email-masked]>
To: [email-masked]
Sender: [email-masked]

Forwarding Jon's Crowcroft mail.  We only allow members of idr to
post.

Sue

---------- Forwarded message ----------
Date: Mon,  4 Oct 1999 06:53:27 -0400 (EDT)
From: [email-masked]
To: [email-masked]
Subject: BOUNCE [email-masked]:    Non-member submission from [Jon Crowcroft
    <[email-masked]>]   

>From [email-masked]  Mon Oct  4 06:53:26 1999
To: David Oran <[email-masked]>
Cc: maddogs <[email-masked]>, idmr <[email-masked]>,
	idr <[email-masked]>, msdp <[email-masked]>,
	pim <[email-masked]>,
	mboned <[email-masked]>,
	malloc <[email-masked]>, rmt <[email-masked]>
Subject: Re: Maestro BoF Results
Date: Mon, 04 Oct 1999 11:53:15 +0100
From: Jon Crowcroft <[email-masked]>

...
..."One of the conclusions from the BoF
was to continue discussions on these subjects to ascertain if there is a
critical mass of support to charter one or more Working Groups to pursue
IETF standards (or other outputs) in these areas. We are therefore
resurrecting a moribund Routing Area mailing list for this purpose:
 [email-masked]"
 
so whats the conclusion vis-a-vis multicast discussion
(considering imminance of next/DC) ietf?

cheers
jon
(apols for multi-list hit, but some folks might have had a peripheral
but strong enough interest to want to know the outcome without seeing
the process)

Date: Fri, 01 Oct 1999 12:22:30 -0400
From: Ben Abarbanel <[email-masked]>
To: James B <[email-masked]>
Cc: [email-masked]
Subject: Re: Update send process
Sender: [email-masked]

So from what you guys are saying the route selection process at the forwarding
table must be synchronized with each of the routing protocols. In other words
all route selection filtering done at the Routing/Forwarding table must be
converged the same way it is with each individual routing protocol (i.e. BGP,
OSPF, ISIS, RIP, etc.) where multiple routes exist to same destination from
different protocols.

The case were I see a major problem is if all routing protocols import their
routes to the forwarding table but not to each other.

I  think we hit upon a very sensitive chord here.

Ben

James B wrote:

> >Not quite.  I'm saying that if you define static routes and you run
> >BGP, and if a static route overrides a BGP-learned route, then you
> >should not advertise the BGP-learned route since you are not using it
> >for forwarding.  It's (as they say) a matter of local policy whether
> >you advertise the static route via BGP or not.  Always exporting
> >static to BGP would be one way of doing it, but certainly not the
> >only way.
> >
>
> I tend to agree with this behaviour. It only makes sense that routing
> information that you propagate across your AS and to other ASs is indeed
> what you use for actually forwarding traffic. Otherwise, downstream routers
> may land up making policy decisions based on path attributes that are not
> necessarily the correct path attributes associated with the route that
> traffic is actually forwarded on. (resulting in potential forwarding loops,
> among other things).
>
> In addition, I don't think that mandating exporting of static routes to BGP
> is the right way to go. That is a local policy decision and should be left
> to the administrator. What is important however, is that in such a
> situation, the behaviour of routers is consistent (which I think would be
> accomplished by the suggested modification that John made).
>
> One other minor point. I think I had asked this earlier. If the above
> behavior is the correct behavior, then I take it this applies to
> redistributing to internal as well as external BGP peers? In the paragaph
> that Yakov pointed out from the I-D, the reference is explicitly to
> readvertising to neighboring ASs (implying only EBGP nbrs). Should the spec
> be modified to remove this explicit reference?
>
> Thanks
>
> -Sanjay
>
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com

Date: Fri, 01 Oct 1999 11:46:39 -0400
From: Ben Abarbanel <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: James B <[email-masked]>, [email-masked]
Subject: Re: Update send process
Sender: [email-masked]

Thanks for clarifying it.

Ben

"John G. Scudder" wrote:

> At 5:24 PM -0400 9/30/99, Ben Abarbanel wrote:
> >It sounds to me like what you and Yakov are saying is that if you define
> >static routes and you run BGP, you better make sure the static route is
> >redistributed to BGP. So it can cancel out the dynamic route to the same
> >prefix.
>
> Not quite.  I'm saying that if you define static routes and you run
> BGP, and if a static route overrides a BGP-learned route, then you
> should not advertise the BGP-learned route since you are not using it
> for forwarding.  It's (as they say) a matter of local policy whether
> you advertise the static route via BGP or not.  Always exporting
> static to BGP would be one way of doing it, but certainly not the
> only way.
>
> >Is it possible to have a transit AS relay BGP routes from one AS to the next,
> >and yet still have locally defined and used static routes that could (in the
> >transit AS only) override the relayed BGP routes to the same prefix?
>
> Not with a per-spec BGP implementation, no.  (Yes, there are endless
> variations on this that would be more or less legal if you squint at
> the spec really hard, but the straightforward answer is just "no.")
>
> Regards,
>
> --John
> --
> John Scudder                        email:  [email-masked]
> Internet Engineering Group, LLC     phone:  (734) 213-4939 x14
> 122 S. Main, Suite 280              fax:    (734) 669-8661
> Ann Arbor, MI  48104                www:    http://www.ieng.com

From: "natarajan loganathan" <[email-masked]>
To: [email-masked]
Subject: route reflection
Date: Fri, 01 Oct 1999 12:03:38 IST
Sender: [email-masked]

Hello,

   I have a question in a route reflection scenario :

             RR-31
         E         E
  RTR-18            RR-16

    I                I

  RR-10      I      RR-15

E : EBGP session
I : IBGP session
RTR-XX : RTR with id XX.XX.XX.XX
RR : Route reflector

   1. Assume a prefix 'p' learnt from RTR-31
      Assuming route selection at RR-10 and RR-15 is dependant
      on neighbour's bgp ID.

     It seems the order of arrival of route at RR-10 and RR-15
     will determine where RR-10 and RR-15 will point to.

     Consider the sequence of events :
     RR-10 learns route to 'p' via RTR-18
     RR-10 reflects the best route to RR-15
     RR-15 installs best path as via RR-10
     RR-15 then learns route to 'p' via RTR-16
     Assuming everything else remains same, RR-15
     prefers path via RR-10 over RTR-16 ( bgpid RR-10 < RTR-16)

     Alternatively,
     RR-15 learns route to 'p' via RTR-16
     RR-15 advertises route to RR-10
     RR-10 installs route to 'p' via RTR-15
     RR-10 then learns route to 'p' via RTR-18
     RR-10 prefers path via RTR-15 over RTR-18 (bgpid RR-15 < RTR-18)

     Is this OK (route direction being dependant on order of
     arrival of routes) ? (or) which is the wrong step.

   2. Also is this sequence possible?

     1. RR-15 learns path to 'p' via RTR-16 advertises it over to
        RR-10
     2. Meanwhile RR-10 learns path to 'p' via RTR-18 and advertises it
        over to RR-15.
     3. RR-15 receives path from RR-10 prefers it over RTR-16 (
        bgpId RR-10 < RTR-16), sends a withdraw for the earlier path.
     4. RR-10 receives path from RR-15 prefers it over RTR-18 (
        bgpId RR-15 < RTR-18), sends a withdraw for the earlier path.
     5. RR-15 receives the withdraw and now has the best path via
        RTR-18 advertises it to RR-10
     6. ad infinitum.

     Obviously this is not possible,
     But, could somebody clarify this please.
Thanks,
Nat.

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

From: "James B" <[email-masked]>
To: [email-masked]
Subject: Re: Update send process
Date: Thu, 30 Sep 1999 22:06:44 PDT
Sender: [email-masked]

>Not quite.  I'm saying that if you define static routes and you run
>BGP, and if a static route overrides a BGP-learned route, then you
>should not advertise the BGP-learned route since you are not using it
>for forwarding.  It's (as they say) a matter of local policy whether
>you advertise the static route via BGP or not.  Always exporting
>static to BGP would be one way of doing it, but certainly not the
>only way.
>

I tend to agree with this behaviour. It only makes sense that routing 
information that you propagate across your AS and to other ASs is indeed 
what you use for actually forwarding traffic. Otherwise, downstream routers 
may land up making policy decisions based on path attributes that are not 
necessarily the correct path attributes associated with the route that 
traffic is actually forwarded on. (resulting in potential forwarding loops, 
among other things).

In addition, I don't think that mandating exporting of static routes to BGP 
is the right way to go. That is a local policy decision and should be left 
to the administrator. What is important however, is that in such a 
situation, the behaviour of routers is consistent (which I think would be 
accomplished by the suggested modification that John made).

One other minor point. I think I had asked this earlier. If the above 
behavior is the correct behavior, then I take it this applies to 
redistributing to internal as well as external BGP peers? In the paragaph 
that Yakov pointed out from the I-D, the reference is explicitly to 
readvertising to neighboring ASs (implying only EBGP nbrs). Should the spec 
be modified to remove this explicit reference?

Thanks

-Sanjay

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

Date: Fri, 01 Oct 1999 09:41:18 +0530
From: Sumit Garg <[email-masked]>
Organization: Ficon Technology
To: Bradley Reynolds <[email-masked]>
Cc: "John G. Scudder" <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: Update send process
Sender: [email-masked]

Bradley Reynolds wrote:
> 
> > I thought that it was pretty clear that "use" means "use for
> > forwarding."  Perhaps the spec *does* need clarification after all.
> > (Yakov, how about changing the quoted sentence above to end "...uses
> > for forwarding"?)
> >
> yes, this interp of use is found somewhere else in the document.
> 
> > >route use from the id would seem to mean installation in the Loc-RIB.
> > >Loc-RIB != router RIB.  and from router RIB we derive FIB.
> >
> > "Router RIB" isn't a term of art I'm familiar with, and it's
> > certainly not used in the BGP spec.  For my part, my working
> > definition of Loc-RIB is "the thing I derive my FIB from."
> >
> 
> ok.  there is a subtle and perhaps worthless difference.  Loc-RIB from the
> draft is what you get after applying policy/selection to adj-rib-ins and
> local information.  cisco says 'once path is selected, it is installed in
> the routing table'; however, this is not quite the case.  i believe that
> once the path is selected it is installed in the routing table only iff:
> 
> 1.  no route currently exists
> 
> or
> 
> 2.  the route that currently exists was installed by BGP.
> 
> so, if you currently have a static sitting in the routing table, the route
> selected by BGP will not get installed. you will still have a route, but
> it will be installed by some other protocol.  thus, the loc-rib is not a
> subset of this 'router RIB'.

Hi,

I agree with the Loc RIB == Forwaring RIB paradigm. The discussion now
seems to be just on interpretation of the wording. But routing
information flow is mainly to ensure consistent and meaningful
forwarding. To this end the router running BGP must be seen as one box
and therefore reachablity, using the routes etc should be seen from this
view point.

I could, in theory, say that all my internal routes (static, IGP etc)
are known to BPG and in the Loc RIB, but as per my policy I would not
send them out (not installed in RIB out). So Loc RIB _is equal to_
Forwarding RIB (or router RIB or whatever) The router knows all the
routes and must present a consistent image as per policies desired.

Regards
-- 
_________________________________
Sumit Garg
Ficon Technology
E-mail :  [email-masked]
Web    :  http://www.ficon-tech.com