[Rps] Re: Separate attributes vs context-aware software [RE: RPS WG...]

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