Hi Sriram,
On Thu, 8 Dec 2011, Sriram, Kotikalapudi wrote:
> >I'm not sure if I understand your quote correctly: Do you only
> consider the case where the super-block encloses the sub-allocations
> (e.g., x.y.0.0/16-32 and x.y.z.0/24)? In this case, that would be no
> MaxLength violation, right?.
>
> KS: No. I am taking about something different.
> If ISP A (with AS A) creates a ROA for its super-block x.y.0.0/16
> and its Customer B (with AS B) has a sub-allocation x.y.z.0/24 and
> has NOT created a ROA yet, then the customer's announcement will be Invalid.
> The same effect happens whether ISP A's ROA is:
> {ROA: x.y.0.0/16, AS A} (w/o maxLength; defaulted to maxLength = 16)
> or, {ROA: x.y.0.0/16, AS A, maxLength = 24}
> or, {ROA: x.y.0.0/16, AS A, maxLength = 18}.
> With any of the above ROAs, Cust. B's announcement is Invalid
> because it doesn't have a ROA yet for its sub-allocation.
>
definitely agree.
> KS: The BCP I quoted from origin-ops requires that ISP A MUST
> register its ROA only after the customer sub-allocation ROAs
> have been created (or, register all necessary ROAs simultaneously).
> In the above example: ISP A can create a ROA for Customer B
> along with its own ROA as follows:
> {ROA: x.y.0.0/16, AS A} and {ROA: x.y.z.0/24, AS B}
> That ensures that Customer B is not in trouble.
>
> This is the bottom up approach for ROA creation.
> Question is: Do the ISP's (or super-block owners) in your
> measurement data seem to be compliant with said BCP.
>
My point was that it is not too easy to decide if the ISPs are
compliant with the BCP. But I think I got your point: If the origin AS
in the Update has (somehow) a *customer* relationship with the ROA AS it
is more likely that the ISP's ROA creation is in violation of the BCP.
In our last IETF presentation, we identified for the incorrect origin
ASes that there exists a ROA Origin that is 1 hop away (ignoring
prepending) from the announced origin AS in 90% of the cases. Coming
back to your question: Yes, most of the announcements are invalid
probably due to the violation of the BCP but I will try to verify in
more detail.
Cheers
matthias
--
Matthias Waehlisch
. Freie Universitaet Berlin, Inst. fuer Informatik, AG CST
. Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email protected] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
