Greg, Thanks for your responses. You may call me Sriram - name I go by. Comments below.
Sriram >Hi Kotikalapudi, thanks for you comments. We proposing to change the first >two lines to remove the inconsistencies: >- Software MUST mark any routes from an EBGP peer as 'invalid' in the >Adj-RIB-In, if no import policy was configured. >- Software MUST NOT advertise any routes to an EBGP peer, if no export policy >was configured. >I think that policy detection, verification or undesirable operator >configurations are outside the scope of this document. Ok, sounds good. >>What about the FIB? Should the doc also say, “Software MUST NOT install >>in the FIB any routes that are marked ‘invalid’ in the Adj-RIB-In”? >I don't think this is needed. In a route is invalid in the Adj-RIB-In, it >won't be >considered in the route selection process, and will not be installed in the >FIB. Yes, agree. >>We also need to distinguish between ‘invalid’ due to RPKI/ROA origin >>validation vs. ‘invalid’ due to BGP-sans-policy. >>If ‘invalid’ due to RPKI/ROA, the route may be installed and advertised if >>there is no alternative route (for that prefix). >>(At least during the early adoption phase.) >If the route is invalid in Adj-RIB-In, it wouldn't even reach any next steps >in >the decision making process as above. So any further mechanisms such as >origin validation, >prefix filtering, or evaluating routing policies configured by the operator >would not even be reached. Let us say, all received routes were ok (i.e. not marked 'invalid') initially because ingress policy is there. Now route engine (RE) does origin validation (OV) and marks a route 'invalid' (see RFC 6811) in the RIB (i.e. saves the OV result for possible further use later) . The next time this RIB entry (route) is considered in the decision process, there may be confusion if it is policy 'invalid' or OV 'invalid'. I think the labeling of routes needs to distinguish between the two (RFC6811 vs. policy). >> o Software MUST provide protection from internal failures preventing >> the advertisement and acceptance of routes. >> >>Is this about redundancy and reliability? If so, does this belong in this >>document? >>If does belong here, providing an example or two regarding how it is done >>would be useful. >Agreed, we changed MUST to SHOULD. The idea is that the BGP speaker would >still follow >the described behavior in the event of a software failure, for example if the >implementation >has a separate policy engine process, instead of advertising and accepting >everything. Some rewording may be helpful here, such as: Internal failures elsewhere in the router SHOULD not affect this security feature. For example, ...[provide an example if you wish]. Sriram _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
