Bug #3295
closed
BestRouteStrategy2 doesn't check "canForwardTo" before retransmission
Added by susmit shannigrahi about 10 years ago.
Updated about 10 years ago.
Description
BestRouteStrategy2 doesn't check forwarding eligibility by calling pit::Entry::canForwardTo on a face.
canForwardTo should return a face's eligibility depending on previous retransmission status.
- Tracker changed from Task to Bug
To expand on this: it looks like best route 2 skips the canForwardTo check because it's using the retransmission helper, which seems to conflict with canForwardTo's implementation (e.g. in record check). It's a bad idea to skip all of canForwardTo's checks like scope control and anything else that may be defined in the future. Likewise, the strategy's implementer should not have to know the specifics of canForwardTo.
Could we have some sort of interaction between canForwardTo and the retx helpers to avoid these problems?
- Description updated (diff)
- Category set to Forwarding
- Status changed from New to Rejected
This is by design.
pit::Entry::canForwardTo is a helper, whose logic is unsuitable for the needs of BestRouteStrategy2.
BestRouteStrategy2 or any other strategy is not required to use this helper in making forwarding decision, as long as it conforms to the requirements such as ScopeControl.
BestRouteStrategy2 fulfills the protocol requirements through predicate_NextHop_eligible.
If you find BestRouteStrategy2 exhibits a behavior that violates a protocol requirement, I can reopen this issue.
- Subject changed from best-route-strategy2 doesn't check "canForwardto" before retransmitting. to BestRouteStrategy2 doesn't check "canForwardto" before retransmitting.
So every strategy using retransmission needs to reimplement (or copy) predicate_NextHop_eligible or canForwardTo? This seems fragile. General eligibility should be defined in one place.
- Subject changed from BestRouteStrategy2 doesn't check "canForwardto" before retransmitting. to BestRouteStrategy2 doesn't check "canForwardTo" before retransmission
So every strategy using retransmission needs to reimplement (or copy) predicate_NextHop_eligible or canForwardTo?
Yes for now. This is exactly the problem to be solved in #2000, where eligibility check will become a building block.
That task was created a year ago.
The retx helpers are one step towards composing blocks and created this problem in the first place. So long as they exist, a solution that doesn't involve copying eligibility logic should also exist.
Also available in: Atom
PDF
Updated by Anonymous 
Updated by