--> From: bmanning@is.rice.edu (William Manning)

yakov@watson.ibm.com

...

Ref: Your note of Fri, 1 May 92 7:12:54 CDT

BGPv2 spec has the following text on the NEXT_HOP subject: "The NEXT_HOP path attribute defines the IP address of the border router that should be used as the next hop to the networks listed in the UPDATE message. This border router must belong to the same AS as the BGP peer that advertises it."

BGPv2 spec requires checking NEXT_HOP ONLY for correct syntax (i.e., NEXT_HOP should carry a syntactically valid IP address).

There is no specified timeout between consecutive BGP close and open.

Yakov.

So, let me get this straight. What is POSSIBLE in version two is prohibited in version four in regards to NEXT_HOP. The latest ANS rcp_routed started enforcing version four semantics.

Not the way I read it. "This border router MUST belong to the same AS as the BGP peer that advertises it," and the ENSS does not. On the other hand, there are admittedly much better ways to handle BGP spec. As one of the people who could have been up all night trying to figure out why this occured, I wasn't too pleased either. And believe me, this incident has made enough rain, internally and externally, that a more subtle "notification" of this particular protocol violation is on the way. I always thought the statement in the TCP RFC that said TCP code should be lenient with respect to protocol violations was pretty idiotic. As a programmer, I thought this went without saying. Maybe not...

I can not find where this was make public knowledge. Sigh...

That was indeed part of the problem.

It also seems clear that a recommendation of how to compute interval times between BGP close and open would be useful for addition to either the BGPv4 or IDPR spec. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892

Eric Bennett reb@merit.edu