Re: BGP-4+

Curtis Villamizar <curtis@ans.net> Fri, 20 December 1996 16:39 UTC

Received: from cnri by ietf.org id aa14743; 20 Dec 96 11:39 EST
Received: from merit.edu by CNRI.Reston.VA.US id aa13626; 20 Dec 96 11:39 EST
Received: (from daemon@localhost) by merit.edu (8.8.4/merit-2.0) id LAA28953 for idr-outgoing; Fri, 20 Dec 1996 11:14:53 -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 LAA28948 for <bgp@merit.edu>; Fri, 20 Dec 1996 11:14:49 -0500 (EST)
Received: by interlock.ans.net id AA28633 (InterLock SMTP Gateway 3.0 for bgp@ans.net); Fri, 20 Dec 1996 11:14:48 -0500
Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 20 Dec 1996 11:14:48 -0500
Message-Id: <199612201612.LAA28818@brookfield.ans.net>
To: Yakov Rekhter <yakov@cisco.com>
Cc: Susan Hares <skh@merit.edu>, dkatz@cisco.com, bgp@ans.net
Reply-To: curtis@ans.net
Subject: Re: BGP-4+
In-Reply-To: Your message of "Wed, 18 Dec 1996 14:59:12 PST." <199612182259.OAA20995@puli.cisco.com>
Date: Fri, 20 Dec 1996 11:12:18 -0500
From: Curtis Villamizar <curtis@ans.net>
Sender: owner-idr@merit.edu
Precedence: bulk

In message <199612182259.OAA20995@puli.cisco.com>om>, Yakov Rekhter writes:
> Sue,
> 
> > 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.
> 
> They can point to the same router. However, the next hop for IPv6 NLRI
> has to point to an IPv6 address, while the next hop for IPv4 NLRI has
> to point to an IPv4 address.

On an IPv6 router why can't you just pack IPv4 addresses into IPv6
using the prescribed IPv6 top bits and just have one routing table and
forwarding table?

> > 2) Security Considerations
> > 
> > BGP-4++ is just as secure or un-secure as BGP-4.  
> 
> To be more precise the two new attributes do not alter
> BGP-4 security properties.

That covers it.

> > Is it your understanding that users need this security or is
> > TCP good enough?
> 
> I would like to get a feedback from the WG on this question.

Not really but we have to live with it.

How about if we fixed that in a separate extension to BGP4?

Would the ability to quickly reestablish with a grace period eliminate
the RST problem be enough?  If so we already have text for an
extension that is backwards compatible with BGP and provides that.

> Yakov.

Curtis