Moin, > I agree with others that this changes too many things at once and > might have unexpected consequences,
I would argue that this is not necessarily the essence of the prior discussion. > so I suggest it is split into multiple proposals. i.e. this is to > allow guest WiFis, this is to allow hosting, this redefines End > Sites, this is to allow larger than /48s, etc. While I do see the appeal in such an atomic approach, I would argue that the cross dependency of specific changes makes the presented set of changes the minimum consistent one. Furthermore, the step size in the examples provided is, indeed, extremely atomic, close to effectively grinding any change to a halt. > By reading the current and proposed policy I notice some confusing > usage of more/less specific, larger or shorter prefixes in the > current policy, perhaps this is something to clarify in the future. It is. Yet, below, you argue against one such specific change which, in the past in the interpretation of the policy by the NCC, was indeed interpreted in an unexpected way. > As I read it, the current version of the proposal complicates the > policy instead of clarifying, adds impossible to verify requirements, > uses new and undefined terms and has some contradictions, I would argue that, partially, that is based on an intentional reading of the policy proposal which I find myself partially challenged to purely attribute to confusing language. Please see more specific comments below. > while the clear outcome is making it easier to obtain larger than /48 > assignments based on routing requirements instead of address usage. This is indeed one of the stated purposes of the policy change. > One such contradiction is related to the aggregation as one of the > stated purposes of the proposal while the text explicitly allows > announcing separate prefixes from the assignment (de-aggregation), > and it seems phrased for a very specific and complex use-case. Aggregation of address assignment, not the GRT. Someone once said that the NCC is not the routing police. > I am surprised by the cases of assigning multiple /48s for the same > End Site that would otherwise be aggregated that were mentioned in > the thread, is there an example of such case with some more details? > I am unable to find any. This should be fixed, however I see no issue > with assigning based on usage. See above; In that context, see for example Jori's message. > A /48 is a one-size-fits-all default for End-Sites (RFC3177/6177), > except for *very large subscribers*, a /48 has 256 x /56 or 65536 x > /64, and one /64 has *a lot* of addresses available for connecting > devices. This point mixes 'end site' with 'end user holding multiple end sites'; In fact, the proposed change effectively reinforces a /48 _per end site_. > With the current proposed text I do not foresee a queue of PI holders > seeking to aggregate, but a queue of PI holders seeking single larger > assignments to de-aggregate. If these assignment holders qualify for a single larger assignment, they will currently already hold (or would be allowed to hold) one /48 per each of these end-sites. As such, there would not be a change in relation to the deaggregation of the GRT, with the difference of the database an assignment plan actually aggregating. > Perhaps some numbers from the NCC would help? Such as how many PI > assignments are there (if multiple /48s are in the same ticket this > is not necessarily visible in the DB). It is, because each /48 will be its own DB object. > xxxx /48s PI > yyyy /46s PI > zzzz multiple /48s PI in the same ticket for use at the same location > (that could be aggregated) > And maybe some reasons for multiple /48s such as "different End > Sites"? While I agree that, in general, this information would be useful, it works on a selected premise of aggregating the GRT, not assigned space. > New 2.6 > - Introduces the term "geographical End Site" that is undefined and > impossible to verify. Is my building number +/-1 the same > geographical End Site? Is the geographical limit set by the range of > the WiFi? The NCC service region? It remains more defined than current terminology. Furthermore, it is definitely clear what is _not_ the same geographical end-site. > - Allows /56 or longer to different entities without being considered > a sub-assignment This, again, is a stated purpose, as a static use of, even, a static /128, to connect, e.g., a server to a network is--per the last impact assessment of the policy change that introduced the explicit permission to use addresses for connecting servers or appliances--is not permitted. > - "using more specific prefixes from a less specific assignment for > different parts of the same infra does not constitute a sub- > assignment" > => This is already covered by the first paragraph, for me it is > expected to use more specific prefixes inside your infra, while > announcing the aggregate to the Internet, this is what the assignment > is for. Still, at the moment, this is not permitted by the policy. In fact, if you'd want to use one /48 per end-site for an infrastructure, even if both end-sites had the same routing policy, you would be forced to use two /48s that are _not_ in the same /47. Been there, done that, argued for weeks. > - "any other use of a prefix ... to connect a separate End Site of > another entity to the Internet always constitutes a prohibited > sub-assignment" > => So it is not allowed to use any prefix up to /128 to connect a > separate End Site of another entity to the Internet. But it is > allowed to "provide connectivity to another entity", not a device or > multiple devices but an "entity". It is not allowed if it is a > separate End Site. Correct. Server in your rack, fine. PPPoE connection for an end-user: not fine. > The proposed 2.9 says that a device placed at a different location > (CPE) for the purpose of providing Internet access to a single user > is not a different End Site Correct. Because otherwise you could argue that the CPE is owned by an ISP, and, hence, each customer of theirs would be a different end-site. > (is the device/CPE something you can touch or is this SDN-way?). I will leave this philosophical question out of scope. > So providing Internet access at a different location (in this case > not geographical or topological) to a single user is allowed. Is the > single user an entity? I would love to learn how you can create a 'different location' that is neither topologically not geographically different, without it being the same location. > More confusion adds up since the paragraphs above allow /64 or longer > to connect to other ISPs for the purpose of "exchanging traffic and > Internet routing information", Yes, so it needs to be a link over which internet routing information is exchanged. > and /56 or longer to different entities. > Is exchanging traffic and Internet routing information not what the > Internet is? While I am sure that some people actually speak iBGP between _all_ nodes in their network (I think Q runs a kubernetes cluster directly hooked into their iBGP), I am pretty sure not every link comes with a BGP session. > How is an ISP defined in this context? Since providing Internet to a > single user (even at a different location) is allowed but being an > ISP is not. Is not providing Internet access what an ISP does? Please provide quotes. At the moment, this reads a bit like a mix between 'stated text' and 'interpretation of text under specific premises'; > But this can go on up to the meaning of life, the universe and > everything and we will only get /42s from that point on. Again, I will leave philosophical points out of scope. > Usually when providing *services*, the ISP assigns the range for the > interconnection from their address space, not the End User (PI > holder), this change would make the PI holder an ISP while > disallowing them to be an ISP at the same time. How would two networks using only PI peer over a PNI? > I am not aware of any implicit need to use LL for interconnectivity, > could this be clarified? See RFC4291. > New 2.9 > - Introduces yet another undefined term: the "topological location" https://en.wikipedia.org/wiki/Network_topology > 2.9.2 > - Different routing policies are defined in a complicated manner as > they do not traverse other End Sites of the same assignment holder, > unless there is a loss of outbound connectivity where a prefix from > the assignment is used (so they do not traverse unless they > traverse).This explicitly allows de-aggregating the PI prefix and > using the de-aggregated sub-prefixes at different locations. Yes. > - Adds impossible to verify things such as L2s between End Sites. > Trust me, this is L2. Trust me, this is the reason why, for a PoP in Amsterdam, Duesseldorf, and Berlin each, where $nice_neighboring_transport_provider moves a vlan between Amsterdam and Dusseldorf, and Dusseldorf and Amsterdam, you are entitled to _one_ full /48, because all three pops form a single end-site due to the existing L2 connectivity. Please see my thread on requesting a /46 for reference. I.e.: "Is there L2 connectivity" is a metric _currently_ used by the NCC. > - Differentiate between End Sites in PI and allocation cases: > providing different definitions of the same term adds confusion while > the benefits of defining End Sites differently are not clear. Currently, applying reasoning clearly made in the context of PA assignments to PI leads to unintentional outcomes. PI and PA assignments are, necessarily, different. As such, they should be treated differently. > - Clarify that L2, clarify that aggregates or prepends do not merge > routing policies: These are impossible to verify claims, RIPE NCC is > not the Routing Police or L2 Police. Exactly. That is why this stops the NCC from doing that. > - Make explicit that placing a single device at another geographical > location with the main purpose of providing a single End User with > Internet access does not make that location an End Site of an > assignment holder. This suggests that using parts of the assignment > for providing Internet access to customers at different locations > from the End Site is ok, however it is prohibited by the new 2.6. Yes, and that is not so difficult: Me selling Internet access to _a_ customer, who then does their thing - > not ok. Me running an open wifi / freifunk (not a single end-user in terms of entity) -> ok. > > New 5.4 > 5.4.2 Assignments from IPv6 allocations > => In my opinion this paragraph would encourage/permit de-aggregation > of assignments from allocations (PA) based on routing requirements. > > The original version is pretty clear that it refers to assignments > "from their LIR or ISP" and there is no room for interpretation if > this is referring to PI, so no changes are required to the policy > text here. Then again, it is being applied in the context of PI. > New 7.1 > The very short, to the point, minimum assignment size of /48 is > replaced by a very long and interpretable text. Please see the APWG archives on a discussion with the NCC, where the NCC claims that this means that the smallest _prefix size_, i.e., least specific prefix, is a /48. > - Introduces a new term "special purpose PI assignment" that may > deviate from generic PI assignment criteria Yes, like, for example, IXP PI assignments, which we _already_ have, and which _already_ make provisions which are _incompatible_ with the PI assignment policy; Like: Assigning /64 PI. This change specifically canonicalizes what is already there. > - "to avoid fragmentation" the new text adds routing policies as > permitted justification for shorter prefixes and explicitly allows > more specific prefixes of PI space (de-aggregation of PI). Yes, see above. > 7.1.3 adds a reevaluation mechanism for previous assignments in order > to provide contiguous address space, however that will be de- > aggregated due to routing requirements and/or multiple End Sites. > Contiguous address space makes sense for aggregation purposes (single > prefix announced). Database, GRT, Routing Police. See above. > In my opinion this does not resolve the discussions around what > constitutes an End Site, and things such as L2 connectivity are > impossible to objectively verify by external parties. Yes, which is why L2 connectivity no longer matters. > The current policy does not in fact disagree with RIPE-451 (IPv6 > Address Space Policy For IXPs) since that is IXP address space, not > IXP PI (even though it is subject to contractual requirements similar > to PI). Funnily enough, this change was made during the preparation for publication of the policy proposal, when the PO raised the point that making the longest prefix of PI a /48 would collide with RIPE-451, and was then surprised that the /48 was--more or less--already in the old policy. > The consideration that a /44 would stop de-aggregation to /48s > contradicts the text from the proposed changes - different routing > policies are let's say hard to implement if only the aggregate is > announced, and, given that PI networks are comparatively small (as > the proposed text says) they most likely fit in the /48 default. Again, see above. Given your extensive commentary, I would deeply appreciate it, if--in case my counter arguments are in your opinion unconvincing--you could contribute text to approach the recognized underlying operational issues the proposal tries to address in a better way. With best regards, Tobias -- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M [email protected] ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
