Re: BGP-4+
Susan Hares <skh@merit.edu> Wed, 18 December 1996 22:08 UTC
Received: from cnri by ietf.org id aa10448; 18 Dec 96 17:08 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa25976; 18 Dec 96 17:08 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06374
for idr-outgoing; Wed, 18 Dec 1996 16:38:03 -0500 (EST)
Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by
merit.edu (8.8.4/merit-2.0) with SMTP id QAA06369 for <bgp@merit.edu>;
Wed, 18 Dec 1996 16:38:00 -0500 (EST)
Received: by interlock.ans.net id AA23361
(InterLock SMTP Gateway 3.0 for bgp@ans.net);
Wed, 18 Dec 1996 16:37:53 -0500
Received: by interlock.ans.net (Internal Mail Agent-1);
Wed, 18 Dec 1996 16:37:53 -0500
Message-Id: <199612182137.QAA06366@merit.edu>
To: Yakov Rekhter <yakov@cisco.com>
Cc: skh@merit.edu, dkatz@cisco.com, bgp@ans.net, skh@merit.edu
Subject: Re: BGP-4+
In-Reply-To: Your message of "Wed, 18 Dec 1996 12:11:14 PST."
<199612182011.MAA23562@puli.cisco.com>
Date: Wed, 18 Dec 1996 16:37:50 -0500
From: Susan Hares <skh@merit.edu>
Sender: owner-idr@merit.edu
Precedence: bulk
Yakov:
Wow! What a nice Christmas present.
A few comments on the draft:
1) From the section below and the address family,
IPv6 and IPv4 cannot point to a common next hop.
Ipv6 routes can be passed over IP v4 fabric, but the
next hop must be a "third" party hop.
ipv6---ipv4----ipv6
This can occur if all routers in above picture running bgp
are on a common subnet.
Is this a correct statement? Did I mis-understand the text below?
> One could further observe that the next hop information (the
> information provided by the NEXT_HOP attribute) is meaningful (and
> necessary) only in conjunction with the advertisements of reachable
> destinations - in conjunction with the advertisements of unreachable
> destinations (withdrawing routes from service) the next hop
> information is meaningless. This suggests that the advertisement of
> reachable destinations should be grouped with the advertisement of
> the next hop to be used for these destinations, and that the
> advertisement of reachable destinations should be segregated from the
> advertisement of unreachable destinations.
> When advertising a MP_REACH_NLRI
> attribute to an external peer, a router may use one of its own
> interface addresses in the next hop component of the attribute,
> provided the external peer to which the route is being advertised
> shares a common subnet with the next hop address. This is known as a
> "first party" next hop. A BGP speaker can advertise to an external
> peer an interface of any internal peer router in the next hop
> component, provided the external peer to which the route is being
> advertised shares a common subnet with the next hop address. This is
> known as a "third party" next hop information. A BGP speaker can
> advertise any external peer router in the next hop component,
> provided that the Network Layer address of this border router was
> learned from an external peer, and the external peer to which the
> route is being advertised shares a common subnet with the next hop
> address. This is a second form of "third party" next hop
> information.
2) Security Considerations
BGP-4++ is just as secure or un-secure as BGP-4. If bgp over transport
is OK now, this is OK. If you need additional security by
using an in-protocol transport - this needs to be added.
Is it your understanding that users need this security or is
TCP good enough?
Sue Hares
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Susan Hares
- Re: BGP-4+ Susan Hares
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Brandon Black
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Tony Bates
- BGP-4+ Dave Katz
- Re: BGP-4+ Dimitry Haskin
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ bmanning
- Re: BGP-4+ Tony Li
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Dorian R. Kim
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Curtis Villamizar
- Re: BGP-4+ Dennis Ferguson
- Re: BGP-4+ Brandon Black
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Dennis Ferguson
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ John W. Stewart III
- Re: BGP-4+ Yakov Rekhter
- Re: BGP-4+ Geert Jan de Groot
- Re: BGP-4+ Brad Smith
- Re: BGP-4+ [QOS et al] John G. Scudder
- Re: BGP-4+ Paul Traina