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

From: "Martin, Christian" <[email-masked]>
Date: Sun, 15 Sep 2002 15:14:50 -0400

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.

I know this is a late change and it hasn't been addressed before, but after
reading it in a capsule, it looks like it would be beneficial to consider
the edit.

Thanks,
-chris

> So, with this in mind I would suggest to replace
> 
>    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. This rule
>    reflects the "hop-by-hop" routing paradigm generally used
>    throughout the current Internet. Note that some policies cannot
>    be supported by the "hop-by-hop" routing paradigm and thus
>    require techniques such as source routing (aka explicit routing)
>    to enforce. For example, BGP does not enable one AS to send
>    traffic to a neighboring AS intending that the traffic take a
>    different route from that taken by traffic originating in the
>    neighboring AS. On the other hand, BGP can support any policy
>    conforming to the "hop-by-hop" routing paradigm. Since the
>    current Internet uses only the "hop-by-hop" inter-AS routing
>    paradigm and since BGP can support any policy that conforms to
>    that paradigm, BGP is highly applicable as an inter-AS routing
>    protocol for the current Internet.
> 
> with 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 to a neighboring AS
>    intending that the traffic take a different route from that
>    taken by traffic originating in the neighboring AS.  On the
>    other hand, BGP can support any policy conforming to the
>    destination-based forwarding paradigm.
> 
> Yakov.
>

---

From: Yakov Rekhter <[email-masked]>
Date: Sun, 15 Sep 2002 12:25:22 -0700

Martin,

>    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: Curtis Villamizar <[email-masked]>
Date: Wed, 18 Sep 2002 16:23:15 -0400

In message <[email-masked]>, "Mar
> reading it in a capsule, it looks like it would be beneficial to consider

Chris,

It would help if you mentioned that only the sentence starting with
"For example" differs.

I think Yakov's example is more clear and addresses the point of this
paragraph.  That is "IP + BGP != NIMROD (or any close relative)".

Curtis