WG chair hat off
On 25/11/2008, at 10:29 AM, Danny McPherson wrote:
On Nov 24, 2008, at 4:13 PM, Geoff Huston wrote:
I'm confused here Danny - are you explicitly advocating that a ROA
should explicitly carry the semantics of "deny all else"?
Is that is the case, then from such a perspective of a ROA having a
"deny all else" interpretation, how should incremental use /
piecemeal deployment of ROAs be handled? Does a ROA for 10.0.0.0/8
Origin AS1 explicitly deny all other non-ROA advertisements of any
prefix that is equal to, or a more specific of 10.0.0./8 using any
other origin AS other than AS1? I'm not sure that this would be
your intention, but it seem to me that this logically follows from
a "deny everything else" semantic interpretation applied to a ROA.
No, I'm saying that if a ROA is published indicating *who* is
authorized to originate a route do I really need to fully
enumerate everyone that is NOT authorized? Part of your case
for BOAs was in case an object couldn't be accessed - increasing
the size of the database at least 3x by adding BOAs doesn't seem
entirely amenable to supporting that motivation.
So if I understand you correctly you are advocating that a ROA has an
explicit semantic intention of "deny everything else"
could you explain the precise semantics of a ROA for 10.0.0.0/8
maxlength = 9, origin AS1 as if would apply to an advertisement of
10.1.1.0/24 origin AS1 without any ROA, and to an advertisement of
10.1.1.0/24 origin AS2 without any ROA?
In an incremental deployment model an attestation as to the
authorized originator of a route accommodates the incremental
deployment model - if there's no ROA do what you want with
it - depref, tag, discard, whatever you want.
but hang on - you are not saying that Danny in your previous paragraph
- you are saying that in a deny everything else, the presence of a ROA
implicitly denies a class of other routes. I'm very confused about
what you are saying here as you seem to me to be saying two different
things at once.
regards,
Geoff
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
