Subject: RE: Proxy: comments on section 9.1.3

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 10:54:58 -0400

Jeff:
  I did not imply we forbid these non-FIB routes from being added to the
Loc-RIB,
just that we cover this case by saying we still knowingly advertise these
non-FIB
routes to our outbound BGP peers. Anyone with any doubt will know exactly
what we
mean. Perhaps a statement as to the impact on the topological graph in this 
scenario will be helpfull.

Ben

> -----Original Message-----
> From: Jeffrey Haas [mailto:[email-masked]]
> Sent: Friday, September 06, 2002 10:50 AM
> To: 'Mathew Richardson'
> Cc: Abarbanel, Benjamin; [email-masked]
> Subject: Re: Proxy: comments on section 9.1.3
> 
> 
> On Fri, Sep 06, 2002 at 10:41:38AM -0400, 'Mathew Richardson' wrote:
> > And what do either of these have to do with the base BGP spec?
> 
> Adding language that specifically forbidding adding routes to Loc-Rib
> when they wouldn't be added to the FIB would preclude some forms
> of route concentrators.  I don't think we really want to do that.
> 
> > mrr
> 
> -- 
> Jeff Haas 
> NextHop Technologies
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 11:19:00 -0400

Mathew:
 
> >Wrong, there is an IGP or static route to destination D in 
> the routing
> >table as the best forwarding route, the BGP route to 
> destination D that is
> >installed in the Loc-RIB with a different Next Hop router is 
> not used for
> >forwarding. That is the inconsistency I am talking about.
> 
> <snip>
> 
> I think that case must either be disallowed, or placed outside the
> scope of the base document.  How about adding to section 9.1.3,
> at the end:
> 
>   Any local-policy which results in reachability being added to an
>   Adj-RIB-Out without also being added to the local BGP speaker's
>   forwarding table, are beyond the scope of this document.
> 
>  
This is a good start. I will be happy with this, unless people want 
more definitive answer on this point.

Ben

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 6 Sep 2002 12:12:49 -0400

OK, thanks.

Then maybe:

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses."

Should be changed to

"one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with) in
   neighboring ASs only routes whose NLRIs are locally reachable."

Since currently a bgp router will advertise bgp routes that are not in the
local routing table via bgp (as long as the NLRI of the route is in the
routing table via some routing protocol, the route will/may be advertised).

Maybe some reference to [Juniper] "active route" should be added? 

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, September 06, 2002 11:29 AM
To: Natale, Jonathan
Cc: 'Abarbanel, Benjamin'; 'Jeffrey Haas'; 'Mathew Richardson';
[email-masked]

Natale,

> The confusion here is "routes".  Is it:
> Prefix + prefix length (this is what it is in my mind)
> OR
> Prefix + prefix length + protocol
> OR
> Prefix + prefix length + next hop
> OR
> Prefix + prefix length + next hop + protocol
> OR
> ???

From section 3.1:

  For the purpose of this protocol, a route is defined as a unit of
  information that pairs a set of destinations with the attributes
  of a path to those destinations.  The set of destinations are the   
  systems whose IP addresses are reported in the Network Layer
  Reachability Information (NLRI) field and the path is the information
  reported in the path attributes field of the same UPDATE message.

Yakov.

> From: Abarbanel, Benjamin [mailto:[email-masked]] 
> Sent: Friday, September 06, 2002 10:55 AM
> To: 'Jeffrey Haas'; 'Mathew Richardson'
> Subject: RE: Proxy: comments on section 9.1.3
> 
> Jeff:

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 6 Sep 2002 12:22:29 -0400

Natale:

>    neighboring ASs only routes whose NLRIs are locally reachable."

Third version:

 "one must focus on the rule that a BGP speaker advertises
  to its peers (other BGP speakers which it communicates with) in
  neighboring ASs only routes which are locally reachable. Local
  reachability can be achieved by having any protocol route to 
  the given destination in the routing table."
 
Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 9 Sep 2002 16:28:32 -0400

Curtis:
  I like simple things, I would prefer if you can condense this page long
description involving everything to a single sentence and tell us what it
is.

Thanks in advance,
Ben

> From: Curtis Villamizar [mailto:[email-masked]]
> Sent: Monday, September 09, 2002 4:23 PM
> To: Jeffrey Haas
> Cc: Abarbanel, Benjamin; 'Natale, Jonathan'; 'Mathew Richardson';
> [email-masked]
> In message <[email-masked]>, Jeffrey Haas writes:
> > IMHO:
> > A prefix implies a prefix and its associated prefix length.
> > A destination implies an associated nexthop.
> > A route is a destination for a particular protocol.  A route
> > may have additional properties that are protocol specific.
> > 
> > The base bgp document (sec 3.1) has always had the 
> unfortunate wording
> > implying that a route is a path attribute set and multiple NLRI.
> > 
> > On Fri, Sep 06, 2002 at 11:26:15AM -0400, Abarbanel, Benjamin wrote:
> > > A route is not a route, unless you have a Next Hop 
> address. How can 
> > > you get from point A to point B without a (Next Hop) 
> delivary router?
> > > 
> > > IMHO, 
> > > Ben
> > 
> > -- 
> > Jeff Haas 
> > NextHop Technologies
> 
> 
> Jeff,
> 
> I know that you know what you are talking about but maybe some on this
> thread are on thinner ice.
> 
> It was confusion over terminology that gave us some of the goofy
> acronyms (NRLI and LIS come to mind) that could be better served by
> clearly defining the common terms.
> 
> For the purpose of discussion we could use the following.  If we
> really have to (someone insists on it) we could put something like
> this in the document.
> 
>   An IP address is a 32 bit quantitiy for IPv6, the full 128 bit
>   address for IPv6.  Shorthand notations exist which may omit some
>   zero bytes.
> 
>   An IP Prefix includes both an address and a prefix length.  Bits
>   beyond the prefix length are not part of the prefix.  A common
>   notation for IP interfaces on broadcase or NBMA media lists the full
>   (32 bit significant) IP address of the interface and the prefix
>   length of the network.  This is just a shorthand notation providing
>   two peices of information, and is made possible because a correctly
>   configured numbered IP interface falls within the the prefix of
>   network to which the interface is attached (or one of the prefixes
>   if multiple the network has multiple prefixes, such as occurs during
>   renumebering).
> 
>   A route in the RIB consists of an IP prefix and the information
>   needed for forwarding.  The RIB provides a mapping in which the IP
>   prefix is the key or index field for the mapping.  In the case of
>   BGP the forwarding information would be the next hop.  In the case
>   of MPLS an MPLS label stack might serve this purpose.  A route is
>   considered unique if the prefixes match.  For the purpose of
>   discussing BGP, the case of multipath or QoS enabled route can be
>   considered to be one route formed from more than one source with
>   more complex forwarding information, such as more than one next hop
>   for a multipath route and possibly additional information such as
>   load balancing ratios or association between other qualifiers (such
>   as DHCP) and forwarding information.
> 
> In BGP-speak prefix == NRLI and prefix is the key field for a route
> (unique routes don't have the same key).  Multipath and QoS might be
> interesting (note I said might and I don't want to debate that here)
> but is outside of the scope of the BGP protocol spec and is only
> mentioned to avoid confusion that could arise from terminology that
> didn't account for multipath, and other route qualifiers.
> 
> I think I covered this accurately and completely enough.  Maybe we
> should put something in the document.  I don't care much if we use
> NRLI or prefix as the key when defining what a route is.  NRLI leaves
> open use of BGP for non-IP purposes.
> 
> Curtis
> 
> ps - I hope this shed some light rather than just added noise.
>

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 20 Sep 2002 12:15:32 -0400

Yakov:
  I hate to sound picky, but could this improve the intended meaning?

  "Any local-policy which results in routes being added to an
   Adj-RIB-Out without also being used for forwarding, is outside the 
   scope of this document."

Ben

> Sent: Friday, September 20, 2002 12:08 PM
> To: 'Mathew Richardson'
> Cc: [email-masked]
> Matt,
> > > 'Mathew Richardson' <[email-masked]> [Fri, Sep 06, 2002 
> at 11:16:06AM -040
> 0]:
> > 
> > <snip>
> > 
> > Replying to myself to correct some poor grammar:
> > 
> > The last line should read:
> > 
> >   forwarding table is beyond the scope of this document.
> 
> Accepted with a minor rewording (as follows):
> 
>  Any local-policy which results in routes being added to an
>  forwarding table, is outside the scope of this document.
> 
> Yakov.
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 20 Sep 2002 12:16:28 -0400

Yakov,

In response to your proposed text:

"Any local-policy which results in routes being added to an
 Adj-RIB-Out without also being added to the local BGP speaker's
 forwarding table, is outside the scope of this document."

I agree, it should be added. Very clear!

That's what I was trying to say:

"To characterize the set of policy decisions that can be enforced using BGP,
one must focus on the rule that a BGP speaker may advertise to other BGP
speakers only those prefixes that are eligible for use by itself - whether
or not to require the prefixes actually be used itself based on some
priority mechanism for choosing routes from independent routing processes
MAY be an administratively configurable option [N]." ... [N] RFC1812

Curtis made some good arguments on why bgp does not need to/should not do
this.

-Jonathan

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 12:08 PM
To: 'Mathew Richardson'
Cc: [email-masked]
Subject: Re: Proxy: comments on section 9.1.3 

Matt,

> > 'Mathew Richardson' <[email-masked]> [Fri, Sep 06, 2002 at 11:16:06AM
-040

Yakov.

---

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 20 Sep 2002 12:17:51 -0400

Ben,

I like Yakov's better.  Nothing personal.

:-)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Friday, September 20, 2002 12:16 PM
To: 'Yakov Rekhter'; 'Mathew Richardson'
Cc: [email-masked]
Subject: RE: Proxy: comments on section 9.1.3 

Yakov:

Ben

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Fri, 20 Sep 2002 13:43:55 -0400

Jeff:
 I knew that, I should have not used the word FIB. Again this is something
that is also implementation specific, thus your point may or may not be
totally correct. But you know what I meant. 

Anyway, I still wonder whether my correction to the text is technically
correct
or off base on what we are trying to say?

Ben

> Sent: Friday, September 20, 2002 1:41 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]
> To be picky:
> On Fri, Sep 20, 2002 at 12:27:38PM -0400, Abarbanel, Benjamin wrote:
> > My only point is if a BGP route is added to the FIB 
> (Routing Table), it does
> 
> The FIB is distinct from the Routing Table.  The Routing Table is
> used to populate one or more FIBs.
> 
> (And, if you have implementations with multiple routing instances,
> VRFs, etc, then you may have multiple Routing Tables that
> control or share access to one or more FIBs. :-)
> 
> > Ben
> 
> -- 
> Jeff Haas 
> NextHop Technologies
>