From: Joe Chang (changjoe@earthlink.net)
Date: Tue Feb 25 2003 - 16:17:50 GMT-3
The original question is whether split horizon is used to prevent loops in
BGP.
Short answer is no, BGP will not send a route back to the advertising AS
because BGP is aware that route has traversed that AS. This feature can be
implemented regardless of where the routing protocol sits on the OSI.
Howard, we don't care if you personally invented BGP, just give it to us
straight, please?
----- Original Message -----
From: "Howard C. Berkowitz" <hcb@gettcomm.com>
To: <ccielab@groupstudy.com>
Sent: Tuesday, February 25, 2003 1:21 PM
Subject: RE: split-horizon & BGP
> At 9:59 AM -0500 2/25/03, OhioHondo wrote:
> >Howard
> >
> >I disagree with your "BGP is not an application" statement. The fact that
it
> >uses TCP means it uses Layer 4. The fact that it uses TCP ports means
that
> >it uses Layer 5 and it creates TCP sessions (Layer 6) with a
communicating
> >partner.
> >
> >It is an entity communicating over a session and through the network. If
> >that's not a definition of a Layer 7 (application) entity I don't know
what
> >is ;)
>
> The problem is that you are probably looking at just the original OSI
> model without annexes or supplemental documents. The original model
> dealt very poorly with management functions.
>
> An annex to ISO 7498, the basic OSIRM, somewhat improves the
> definition, differentiating among user application stacks (i.e., user
> software that accesses the Application Service Interface of
> application layer protocols), system management (i.e., a layer 7
> function that doesn't talk to end users, such as SNMP), and layer
> management (e.g., routing protocols, TCP control traffic, ICMP, IGMP,
> etc.)
>
> Again, I'll emphasize: BGP is a network layer management function.
> It does not have an ASI but runs independently of user activity.
>
> The model went through further refinement with the evolution in
> B-ISDN, which identified management, control, and user planes within
> stacks.
>
> Speaking as a participant in the IETF Inter-Domain Routing working
> group (responsible for BGP), the Internet Routing Task Force (IRTF)
> Routing Research Group (looking at what comes after BGP), I can say
> from direct knowledge that BGP was not developed with particular
> reference to OSI, and no BGP architect I know considers it an
> application protocol. It's layer management, which has a different
> model.
>
> ISO 7498 really doesn't deal with routing protocols. See ISO TR 9575,
> "OSI Routeing(sic) Framework," for that part of the OSI architecture.
> The first IP reference to that, IIRC, was RFC 1136.
>
> With my coauthors, I'm finishing this week what we hope is the final
> Internet Draft before RFC of terminology for BGP control plane
> convergence. This is being done in the IETF Benchmarking Working
> Group (BMWG), but one of my coauthors, Sue Hares, is the co-chair of
> IDR. We definitely don't consider BGP as having ANYTHING to do with
> the application layer. A related draft deals with some SNMP
> applications for routing protocol, but, even there, SNMP is a system
> management protocol by OSI definition, not general application layer.
>
> Going back to strict OSI, a protocol is associated with layer (N)
> when the Protocol Data Unit payload contains layer (N) information.
> The transport mechanism does not define the payload, especially when
> you have things like recursive tunneling. Cisco courseware ]and,
> horribly, Appletalk documentation -- Sorry Alan] sometimes suggests
> that a protocol that runs on top of layer (N-1) is of layer (N), but
> that simply is not true of management protocols -- as, in this case,
> BGP of layer (N=3) running over TCP of layer (N+1 = 4).
>
> >
> >
> >-----Original Message-----
> >From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> >Howard C. Berkowitz
> >Sent: Monday, February 24, 2003 9:54 PM
> >To: ccielab@groupstudy.com
> >Subject: RE: split-horizon & BGP
> >
> >
> >At 5:20 PM -0500 2/24/03, Jerry Haverkos wrote:
> >>Howard
> >>
> >>I do not believe that the is a command to turn split-horizon on or off
> >>available for BGP, especially not one that works at layer 3.
> >
> >First, let me be clear about some terminology and OSI references,
> >which you may know.
> >
> >BGP is not an application. It is a connection-oriented network layer
> >control program. That it happens to use reliable layer 4 transport
> >is irrelevant to its payload function, which is totally network layer
> >oriented. Connection-oriented routing protocol, connection-oriented
> >transport mechanism.
> >
> >Split horizon is not a general problem of DV protocols, but of
> >connectionless transports for the routing information. Split horizon
> >also applies to routes, not link state information.
> >
> >It can be perfectly normal behavior to receive a self-originated LSA
> >or LSP at a LS interface. Split horizon isn't needed because there
> >are tiebreakers such as age.
> >
> >RIP and IGRP are multicast/broadcast and can cause loops if split
> >horizon is not enforced. Since EIGRP first forms neighbor
> >relationships and uses reliable transport, the split horizon issue is
> >not nearly as significant. In any case, EIGRP has superior loop
> >prevention mechanisms.
> >
> >Think of what the AS_PATH would look like if BGP returned an update
> >to the AS from which it received it. There would be a loop in it,
> >and it would be discarded. It definitely would be discarded at the
> >receiver, and it's an implementer choice to check for loops before
> >sending.
> >
> >
> >>My point is
> >>that BGP does not run at the layer 2 or layer 3 or even layer 4 part of
the
> >>stack.
> >
> >BGP _payloads_ do run in the management plane at layer 3, as do all
> >other routing protocols. RIP, for example, runs over UDP, but again
> >contains only layer 3 management information.
> >
> >>It is an application that exchanges data via an established BGP TCP
> >>session. It is an application to application (BGP peer to peer) decision
> >not
> >>to send routes back to a peer that it received the routes from.)
> >>
> >>I do not believe that it has anything to do with the traditional idea
that
> >>split horizon does not allow updates, received over an interface, to be
> >sent
> >>back over that interface. ;)
> >>
> >>-----Original Message-----
> >>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> >>Howard C. Berkowitz
> >>Sent: Monday, February 24, 2003 3:13 PM
> >>To: ccielab@groupstudy.com
> >>Subject: RE: split-horizon & BGP
> >>
> >>
> >>At 12:30 PM -0500 2/24/03, OhioHondo wrote:
> >>>Since BGP runs as a higher layer protocol (on top of TCP) split horizon
> >>does
> >>>not apply.
> >>
> >>Why do you think TCP would make a difference in loop detection?
> >>
> >>BGP is not strictly a DV protocol. Its primary loop detection method
> >>is examining incoming AS paths (i.e., path vectors) and rejecting
> >>those that contain the local AS number.
> >>
> >>There are additional methods, for iBGP using confederations and RR's,
> >>to reduce/eliminate transient internal loops/oscillation, but these
> >>are probably outside the CCIE scope.
> >>
> >>It isn't completely clean, as BGP/PV is provably loop-free only when
> >>additional policies are NOT used.
> >>
> >>>
> >>>-----Original Message-----
> >>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> >>>Pedro Eira
> >>>Sent: Monday, February 24, 2003 10:36 AM
> >>>To: ccielab@groupstudy.com
> >>>Subject: split-horizon & BGP
> >>>
> >>>
> >>>Hello, Would split-horizon have any effect on BGP?Should I follow the
> >>>same rules for BGP as I do for other DV routing protocols when
> >>>split-horizon is involved?
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:35 GMT-3