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