Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

From: "Martin, Christian" <[email-masked]>
Date: Sun, 15 Sep 2002 16:02:09 -0400

Yakov,

I see what you are trying to say, but it took me a few reads.  What we are
saying is that BGP policy local to an AS cannot affect a path that a
neighboring AS uses to continue downstream.  This is hard to say in any
succinct way, and the sentence is pretty long.

Maybe something like this:

    Routing information exchanged via BGP supports only the
    destination-based forwarding paradigm, which assumes that a
    router forwards a packet based solely on the destination address
    carried in the IP header of the packet. This, in turn, reflects
    the set of policy decisions that can (and can not) be enforces
    using BGP. Note that some policies cannot be supported by the
    destination-based forwarding paradigm, and thus require techniques
    such as source routing (aka explicit routing) to enforce. Such
    policies can not be enforced using BGP either. For example,
    BGP does not enable one AS to send traffic through a neighboring
    AS to some destination beyond the neighboring AS intending that 
    the traffic take a different route from that taken by traffic
    to the same destination which originates in the neighboring AS.
    In other words, the BGP policy of a local AS cannot affect the 
    downstream (aka, away from the local AS) forwarding policy of a 
    remote AS.  On the other hand, BGP can support any policy conforming 
    to the destination-based forwarding paradigm.

-chris

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]] 
> Sent: Sunday, September 15, 2002 3:25 PM
> To: Martin, Christian
> Cc: Natale, Jonathan; [email-masked]'
> Subject: Re: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive 
> 
> 
> Martin,
> 
> > Yakov,
> > 	
> > In both examples below, it would appear that BGP does not have the 
> > capability to affect asymmetric routing, which it clearly 
> does as is 
> > evidenced by traffic on the Internet today.  Perhaps it 
> would be more 
> > clear to use an example that is more congruent with the 
> > destination-based vs source-based argument you are making.
> > 
> > IE:
> > 
> >    Routing information exchanged via BGP supports only the
> >    destination-based forwarding paradigm, which assumes that a
> >    router forwards a packet based solely on the destination address
> >    carried in the IP header of the packet. This, in turn reflects
> >    the set of policy decisions that can (and can not) be enforces
> >    using BGP. Note that some policies cannot be supported by the
> >    destination-based forwarding paradigm and thus require techniques
> >    such as source routing (aka explicit routing) to enforce. Such
> >    policies can not be enforced using BGP either. For example, BGP
> >    does not enable one AS to send traffic to a neighboring AS
> >    based on prefixes originating from the local AS.  On the
> >    other hand, BGP can support any policy conforming to the
> >    destination-based forwarding paradigm.
> 
> How about the following:
> 
>     Routing information exchanged via BGP supports only the
>     destination-based forwarding paradigm, which assumes that a
>     router forwards a packet based solely on the destination address
>     carried in the IP header of the packet. This, in turn, reflects
>     the set of policy decisions that can (and can not) be enforces
>     using BGP. Note that some policies cannot be supported by the
>     destination-based forwarding paradigm, and thus require techniques
>     such as source routing (aka explicit routing) to enforce. Such
>     policies can not be enforced using BGP either. For example,
>     BGP does not enable one AS to send traffic through a neighboring
>     AS to some destination (which is outside of the neighboring
>     AS, but is reachable through the neighboring AS) intending that
>     the traffic take a different route from that taken by the traffic
>     to the same destination that originating in the neighboring AS.
>     On the other hand, BGP can support any policy conforming to
>     the destination-based forwarding paradigm.
> 
> Yakov.
>

---

From: "Natale, Jonathan" <[email-masked]>
Date: Thu, 19 Sep 2002 07:42:02 -0400

How about:
"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

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Saturday, September 14, 2002 12:06 PM
To: 'Natale, Jonathan '; [email-masked] '
Subject: RE: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

Jonathan:
  I did raise this issue before several days ago, the case that BGP only
advertises IBGP/EBGP routes to its peers, but sometimes a better route,
say IGP or static is used for forwarding. Thus making the statement not
totally true. We suggested that the statement be revised to imply that 
reachability of these routes are gauranteed by the BGP speaker not their
implied "use" in the forwarding table.

Thanks,
Ben

-----Original Message-----
From: Natale, Jonathan
To: [email-masked]
Sent: 9/13/02 6:42 PM
Subject: Review of draft-ietf-idr-bgp4-17.txt-advertise inactive

I propose changing:
"To characterize the set of policy decisions that can be enforced
   using BGP, 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."

To:
"To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertises
   to its peers (other BGP speakers which it communicates with)
   only those prefixes that it itself uses. Whether or not to require
the
prefixes be used itself by virtue of a bgp learned route MAY be an
administratively configurable option."

Since:
1) This rule applies to IBGP as well as to EBGP. 
2) The prefix need not necessarily be in the local routing table via
bgp.
3) Juniper has a advertise inactive concept, Cisco does not.
4) The term route (vs prefix) is defined to include the attributes which
means that Cisco is non-compliant (in that it will advertise a route if
the
route's prefix is installed via another protocol), and juniper may be
configured to be non-compliant (turning off advertise inactive).