Subject: was Re: issue 32.2

From: Curtis Villamizar <[email-masked]>
Date: Tue, 01 Oct 2002 20:50:16 -0400

Yakov asked my to repost my private reply to him presumably since my
name is in the middle somewhere proposing text but I think that the
final text proposed by Yakov is fine.  I also suggested that silence
since Yakov's suggestion was made may indicate consensus.  (I hope).

Curtis

------- Forwarded Message

Delivery-Date: Tue Oct  1 13:35:06 2002
To: [email-masked]
Subject: Re: issue 32.2 
Date: Mon, 30 Sep 2002 09:52:31 -0700
From: Yakov Rekhter <[email-masked]>

Curtis,

> >   
> >   32.2) BGP Desitnation-based Forwarding Paradigm
> >   -------------------------------------------------------------------------
- --
> > -
> >   Status: No Consensus
> >   Change: Potentially
> >   Summary: Proposal to clarify BGP's support for the destination-based
> >     forwarding paradigm.  There seems to be consensus that some sort of 
> >     updated text is good, but there is not yet consensus on which text
> >     that should be.
> >   
> >   Discussion:
> >   
> >   In response to these proposals, Yakov proposed that the real problem is t
ha
> > t
> >   it is not clear that BGP is build to support the destination-based
> >   forwarding paradigm.  To fix this, it was propsed that:
> >   
> >   <OLD>
> >   
> >      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.
> >   
> >   <NEW>
> >   
> >      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 enforced
> >      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.
> >   
> >   Curtis thinks the newer text here is more clear.
> >   
> >   In reponse to the new text, Christian Martin propsed a slightly different
> >   new text:
> >   
> >      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.
> >   
> >   To which Yakov replied:
> >   
> >       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.
> >   
> >   And Chris reponsed:
> >   
> >       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 conformin
> > g
> >       to the destination-based forwarding paradigm.
> >   
> >   Tom Petch prefered Yakov's second formulation, with these changes:
> >   
> >        policies can not be enforced using BGP either. For example,
> >        BGP does not enable one AS to send traffic
> >   !    to a neighboring AS for forwarding to some destination (reachable
> >   through but) beyond
> >   !    that neighboring AS intending that
> >   !    the traffic take a different route to that taken by the traffic
> >   !    originating in the neighboring AS (for that same destination).
> >   
> >        On the other hand, BGP can support any policy conforming to
> >        the destination-based forwarding paradigm.
> >   
> >   Yakov agreed to Tom's suggested changes.
> > 
> > I would suggest we change the status of this item to Consensus
> > and indicate that the following paragraph
> > 
> >      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.
> > 
> > 
> > will be replaced in -18 with the following text:
> > 
> >    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 enforced
> >    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 be enforced*.
> >    Such policies can not be enforced using BGP either. For example,
> >    BGP does not enable one AS to send traffic to a neighboring AS
> >    for forwarding to some destination (reachable through but) beyond
> >    that neighboring AS intending that the traffic take a different
> >    route to that taken by the traffic originating in the neighboring
> >    AS (for that same destination).  On the other hand, BGP can
> >    support any policy conforming to the destination-based forwarding
> >    paradigm.
> > 
> > Yakov.
> > 
> 
> 
> Looks good to me.  If silence supposed to imply agreement, we seem to
> have consensus.

Could you please repost it to the IDR mailing list.

Thanks !!!

Yakov.

------- End of Forwarded Message