Hi Jeff,
> > It is also important to observe here that the ultimate result of sending > overload bit = 0 with some match criteria can be accomplished today by > sending overload bit to 1 with the same match criteria and triggering > "clear bgp soft in" (request refresh). from the ORF sender side. That means > that adding "overload bit" to the spec is redundant to the currently built > in protocol mechanism. > Not quite. > > Recall that the ORF programming operation is finalized with the soft > refresh - even if the implementation is permitted in the RFC to do a soft > "diff" mode. > > It is also possible, if not probable, for an implementation of the "don't > send any more" overload behavior to track "was this in my rib-out > already"? As long as the resultant match of re-running the ORF is still > value 1 to not send any more, you simply use the prior announcement state - > if your implementation can track such things. > > If your implementation can't track such things (e.g., mine can), then your > implementation probably cannot fully support value 1. > > -- Jeff > Not this side ... I am talking about BGP speaker which is a route receiver side (ORF msg sender side). The semantics of clear soft in is pretty well defined and if my policy now prohibits to receive some routes as defined in the filter I pushed to the peer the expectations is that I will refresh my Adj Rib-In according to new filters in place irrespective on what the peer will be blasting me with. If you are talking about the case that in spite of installing some filters I now need to keep history on a per path basis and leak some paths which were received and installed prior to applying the inbound filter to me this means just pure mess. Cheers, Robert.
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
