Pekka Savola writes:
I rather see progress towards a pusblished standard, although it doesn't do everything exactly the way I want it, than that we reopen all the discussions again unless a lot of people changed their minds.
For what it's worth, I, as an operator, have roughly the same opinion.
Me too.
I'd like to see a standardized solution soon (I accept the current draft proposal if that's the rough consensus), but on the other hand, I'd like it to be as simple as possible to use.
Exactly. The mp-import/mp-export stuff personally doesn't bother me at all, but I heard a fellow operator complain about the expected size increase of their AS object. What about the following compromise: *) Leave both export/import and mp-export/mp-import in RPSLng (same for default/mp-default) *) Add a "mp-default-afs" attribute that defines what "import/export" means. It would default to ipv4.unicast only. That way, no existing tools break - import/export will still be used for IPv4 unicast policy like today. ISPs can add mp-{im,ex}port to document IPv6 and multicast policies. As long as "The majority of providers support IPv4 unicast only" (as Curtis pointed out, and which is still the case for our set of peers, even though we ARE an "academic" network), people just add mp- attributes for the minority of peerings that need it. Over time, Pekka's vision of congruent unicast/multicast (and/or IPv4/IPv6 unicast, but that doesn't matter) topologies may come true. At that point, people can start modifying their "mp-default-afs", and collapse many mp-{im,ex}port attributes into {im,ex}port attributes. If their peers still use non-RPSLng-compliant tools, then they will misinterpret {im,ex}port as IPv4 unicast-only, but that is probably not very relevant - IPv4 unicast is all those peers' tools can handle. In some cases it will be necessary to specifically exclude default address families, but maybe that could be done with AF-specific NOT ANY policies or something. Makes sense? -- Simon.