WG Hair hat OFF
Hi Steve,
What I _think_ you describes as the "ROA use convention" is the use of
a ROA with an AS of 0 to act as an explicit denial in terms of saying
"these prefixes are bogons". I could be wrong in my understanding of
course.
I must admit that right now I don't think I understand your proposed
"ROA use convention" clearly enough to agree with your assertion
The BOA Approach:
The BOA document is coupled with the ROA validation document so that
the ROA interpretation and the BOA interpretation are explicitly
described. in this context the ROA does NOT act with a double meaning
- it is an explicit authority without any implicit negation
connotations. The presence of a ROA does not act as a form of negation
of any other form of route origination. The BOA has no max length
attribute - any more specific of any prefix described in the BOA is
encompassed in the BOA.
The "ROA use convention":
This "ROA use convention" has me confused. In particular my confusion
lies in the following areas:
1. Does a 'convention ROA' has any implicit denial associated with
it, or is it a simple positive assertion as described above?
2. How should a ROA with a AS value of 0 and a maxlength attribute
be interpreted.
Does a ROA for prefix=10.0.0.0/8 maxlength=8, AS=0 say anything
at all about 10.0.0.0/9?
So if you don't mind I'll reserve judgement on your question and
observe that while the BOA adds a further object to the repertoire of
'recognised' RPKI signed objects, it does so in a manner that makes
negation explicit, does not rely on variable interpretation of ROAs,
does not stretch the ROA semantics beyond the simple positive
authority to as AS to originate a route and allows for incremental
piecemeal deployment in the network.
Regards,
Geoff
On 02/12/2008, at 3:31 AM, Stephen Kent wrote:
Given Geoff's examples of how to use BOAs, I think the only vase
that cannot be handled by the ROA use convention I proposed is the
negative assertion about As numbers.
Geoff, do you agree?
Steve
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
