Re: EBGP over unnumbered serial lines

Tony Li <tli@cisco.com> Thu, 28 September 1995 21:07 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18313; 28 Sep 95 17:07 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18309; 28 Sep 95 17:07 EDT
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa21053; 28 Sep 95 17:07 EDT
Received: by interlock.ans.net id AA52731 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Thu, 28 Sep 1995 16:46:16 -0400
Message-Id: <199509282046.AA52731@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Thu, 28 Sep 1995 16:46:16 -0400
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Thu, 28 Sep 1995 16:46:16 -0400
Date: Thu, 28 Sep 1995 13:45:51 -0700
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Tony Li <tli@cisco.com>
To: dhaskin@baynetworks.com
Cc: rxg@proteon.com, bgp@ans.net
In-Reply-To: <199509281828.AA84357@interlock.ans.net> (dhaskin@BayNetworks.com)
Subject: Re: EBGP over unnumbered serial lines

   > Here is Yakov's response to my question on whether it makes sense to
   > support external BGP over unnumbered serial lines.  Yakov suggested
   > that we bring this issue up in the mailing list.  All comments are 
   > welcome.
   > 
   > > I think that the "same subnet" restriction is mostly intended to
   > > make sure that the external neighbors are one hop away from each 
   > > other (on a common Data Link subnetwork). I think the key question
   > > you need to answer is what you are going to put in the NEXT_HOP attribute,
   > > and whether what you'll put in the NEXT_HOP attribute would cause
   > > any problems to the neighbor (when the neighbor receive a route with
   > > this attribute).  I suspect (but I am not sure), that there
   > > may be some problems associated with what you put in the NEXT_HOP
   > > when you have serial line with unnumbered interfaces.

   And how would a TCP connection be handled between the unnumbered endpoints
   of a serial line?

Wow, you can do that?  ;-)

The correct answer (that Dimitry alludes to obliquely) is that if you
put your TCP peering address into the NEXT_HOP attribute that the
neighbor should accept it.  Assuming the neighbor has a clue.

Tony