Re: Graceful restart comment

[Kaarthik Sivakumar <[e-mail]>]

>>> "MB" == Manav Bhatia <[e-mail]> writes:
MB> Hi All,
MB> I am sorry for opening up this thread after so long but i am just back to
MB> work and i read these mails today itself :-)

Same here. Just read through the draft and found this.

MB> | > I can't think of any scenario where it is reasonable to discard
MB> | > packets from the neighbor while maintaining the session up...

MB> Yes there are circumstances when an implementation will drop an update
MB> while it doesn't kill the peering session. One such case is when a speaker
MB> receives an update and finds its local CLUSTER_ID in the cluster-list.

There is another case that I can think of.

>From draft-ietf-idr-bgp4-17, Section 6.3 (UPDATE message error handling)
------------------------------------------------------------------------

[Regarding NEXT_HOP attribute]
Semantic correctness applies only to the external BGP
links, and only when the sender and the receiving speaker are one IP
hop away from each other. To be semantically correct, the IP address
in the NEXT_HOP must not be the IP address of the receiving speaker,
and the NEXT_HOP IP address must either be the sender's IP address
(used to establish the BGP session), or the interface associated with
the NEXT_HOP IP address must share a common subnet with the receiving
BGP speaker. If the NEXT_HOP attribute is semantically incorrect, the
error should be logged, and the route should be ignored. In this
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
case, no NOTIFICATION message should be sent.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Kaarthik