Hi Matthias: Thanks. My responses inline.
Sriram ________________________________________ >From: Matthias Waehlisch [[email protected]] >Sent: Wednesday, December 07, 2011 11:36 PM >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. 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. >Anyhow, for the measurements we presented last IETF, 80% of the invalid announcements are due to invalid origin ASes. The remaining 20% are due to obvious MaxLength violation (i.e., same origin AS in BGP update and ROA, but longer prefix length in BGP update). Regarding the announcements with incorrect origin AS, for approx. 85% of these BGP updates there exists at least one ROA with a longer MaxLength value compared to the prefix length announced (i.e., the ROA encloses the incorrectly announced prefix). ... Maybe it makes sense to investigate this case in more detail. For example, looking if there is a direct peering between the ROA origin AS and the origin AS within the BGP update. KS: Exactly. That is the info I was requesting. Well, it may not be just the directly peering ASs that you look for. There can be customer's customers, etc. That is, children, grand children, great grand children kind of sub-allocations each with its own AS. Please see Slide 8 of this presentation http://www.ietf.org/proceedings/82/slides/sidr-2.pdf for measurements on customer cone structure (i.e., # prefixes originated vs. their depth in AS path length) for several real ISPs. Sriram _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
