Simon Leinen wrote:
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.
If one's policy is simple so will be its documentation in RPSL[ng]. It can be as simple as in ripe-181 with the exception of explicit afi declaration. But then again, the decision has been consciously made back in March 2002 during IETF53 to make the spec more explicit (and therefore more readable by humans also) and preserve backwards compatibility as much as possible (in people's minds as well as many will default to ipv4).
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?
Not really. I think you are presenting a possible scenario of RPSL - RPSLng transition and suggest that we phase out mp- attributes. I'd rather phase out import/export attributes, as mp- attributes provide more functionality and flexibility. But in fact, such transition is not necessary. Either import/export will be phased out naturally, or it will be up to a registry to plan such transition/cleanup when they see appropriate. Regards, Andrei