o Software MUST mark any routes from an eBGP peer as 'invalid' in
the Adj-RIB-In, if no explicit policy was configured.
This bullet says “explicit” policy. The next bullet does not say “explicit”.
What is the definition of “explicit policy” as opposed to “policy”?
o Software MUST NOT advertise any routes to an eBGP peer without an
operator configuring a policy.
Are you proposing an automatic detection method for sensing if operator has
configured policy?
How do you sense it? Does the software sense presence or absence of lines of
code in a policy function?
What if operator has encoded a bad policy that simply says accept any route
from any neighbor?
Is the software required to attempt to catch that?
The second bullet should tie into the first bullet. It can say,
“Software MUST NOT advertise any routes that are marked ‘invalid’ in the
Adj-RIB-In to an eBGP peer.
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”?
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.)
o Software MUST NOT require a configuration directive to operate in
this mode.
Simply saying “this mode” is ambiguous. Do you mean to say “the above two
functions
(1st and 2nd bullets) are innate behavior (default) and MUST NOT require a
configuration directive”?
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.
Quoting from the intro:
“Routing leaks
[I-D.ietf-idr-route-leak-detection-mitigation] are part of the
problem,….”
RFC 7908 defines route leaks. The draft you have cited describes a solution for
route leaks. No harm citing both.
Thanks.
Regards,
Sriram
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
