From mrp at mrp.net Fri Jan 2 09:47:25 2004 From: mrp at mrp.net (Mark Prior) Date: Fri, 02 Jan 2004 19:17:25 +1030 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: References: Message-ID: <3FF5301D.5000701@mrp.net> Pekka Savola wrote: > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. That pretty much summarises my position. I will also comment that when we migrated from RIPE-181 to RPSL we also had a backward compatibility problem but that didn't seem to be a problem back then so I don't see why it's now suddenly a problem. Mark. From pekkas at netcore.fi Fri Jan 2 09:24:20 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 2 Jan 2004 10:24:20 +0200 (EET) Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: Message-ID: Hi, (I tailed down the Cc: list..) On Sat, 27 Dec 2003, Randy Bush wrote: > > OK, I now found that the doc did have an IETF Last Call > > in late August/Early Sept. > > and there were technical objections which have not been addressed Thanks, Randy, for reminding about that. Based on some off-list discussion, the technical objections being referred to are the comments from Mark Prior on the list, one of them copied below. I'll try to summarize the loooo-ong thread somehow. Mark believes that the current RPSLng proposition unnecessarily adds complexity to the operators' use of the language, as e.g. IPv4 and IPv6 addresses, peerings, etc. could all be facilitated by redefining the current attributes etc. -- and whichever would be returned could be evaluated based on the context. As the number of operators using the language is extremely high (and we'd like it to be higher :-) compared to the registry/tool implementations, Mark argues that optimizing for the simplicity to the operators is the most important goal. Curtis objects to this mainly based on the fact that this would break the backward compatibility for the clients which do not expect to receive IPv6 data back from their queries. This could be easily fixed e.g. in tools like IRRToolSet, but that there are a probably a number of hacks built on top of perl, telnetting to port 43, or whatever, which might not be equally fortunate. Workarounds to this seem to be adding some kind of version negotiation or inclusion to the whois protocol (in the future, maybe using CRISP), so that only the clients who signal "yes, I can process IPv6 records!" would activate the IPv6 context processing. This could also be passed to the whois server with an option, like '--use-rpslng' or '-6'. Or maybe the client would state which records it wants to get, e.g. '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or something, for "NEW", otherwise only v4 would be returned :) for both). At least RIPE database allows the use of '-Vxxx' verstion string to tell about the version of the client software. The exact details of how this method would work out would need to be fleshed out. Any takers? Personally, when I was trying to form an opinion on this subject, I found myself thinking that Mark's proposal addresses only IPv4/IPv6 case. It doesn't seem to address how one could specify different unicast/multicast policies, or how to specify different v4/v6 policies. This is also one goal of RPSLng.. even though the major operators who do have multicast or v6 often want their policies to be the same. How would this work out if a "more intelligence" model was adopted? (I'm personally a bit unsure whether a "more intelligence in the tools" -model would or would not make sense at this point, but I think I can see both sides of the argument..) Could we get some form of discussion and maybe consensus on what would seem to be the right way forward? :-) =========== Date: Tue, 23 Sep 2003 09:00:06 +0930 From: Mark Prior To: curtis at fictitious.org Cc: Pekka Savola , iesg at ietf.org, rpslng at ripe.net, rps at ietf.org Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard Curtis Villamizar wrote: > How is RPSLng not a superset of RPSL? Nothing has been removed from > RPSL. Superset is probably not the best word to describe what I want. > The issue is just how do you make transition easiest, supporting older > RPSL only clients. If you just extend import rather than rename it > mp-import and extend it, then old RPSL only clients will consider you > autnum broken. If you include mp-import but forget to reflect you > IPv4 policy in plain import then the old RPSL client will pick up a > subset of you policy. > > In either case, extending import, or adding mp-import and putting the > extensions there, it would make for a smoother transition if the > server code could recognize old clients and feed them with objects > translated into plain RPSL. I think I have been consistent in wanting the smarts to be in the software and not the language. I would prefer to overload the syntax then create new syntax and let the software work out what is required. We don't use different syntax in computer languages when we want to operate on integers rather than reals so why make the distinction in RPSL? If we have a route object that has a IPv6 address in it surely the software can work out if it wants it or not given it's current context? I know you (and others :-) keep on about the old clients but we have left them behind once before in the transition from RIPE 181 to RPSL so do it again but this time lets leave some mechanism behind so that when we need (RPSLng)ng we don't go through this pain yet again. Saying it's not part of the language is a pathetic excuse in my book for not fixing it. If we need a "shim" document to describe the interaction between a server and a client then lets do it. It would make the client software writers life a lot easier if there weren't (at least) 3 server interaction languages to deal with. Mark. ========== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From ljb at merit.edu Tue Jan 13 17:22:09 2004 From: ljb at merit.edu (Larry J. Blunk) Date: 13 Jan 2004 11:22:09 -0500 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: References: Message-ID: <1074010929.3795.45.camel@ablate.merit.edu> On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > Hi, > > (I tailed down the Cc: list..) > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > OK, I now found that the doc did have an IETF Last Call > > > in late August/Early Sept. > > > > and there were technical objections which have not been addressed > > Thanks, Randy, for reminding about that. > > Based on some off-list discussion, the technical objections being > referred to are the comments from Mark Prior on the list, one of them > copied below. > > I'll try to summarize the loooo-ong thread somehow. Mark believes > that the current RPSLng proposition unnecessarily adds complexity to > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > peerings, etc. could all be facilitated by redefining the current > attributes etc. -- and whichever would be returned could be evaluated > based on the context. As the number of operators using the language > is extremely high (and we'd like it to be higher :-) compared to the > registry/tool implementations, Mark argues that optimizing for the > simplicity to the operators is the most important goal. > > Curtis objects to this mainly based on the fact that this would break > the backward compatibility for the clients which do not expect to > receive IPv6 data back from their queries. This could be easily fixed > e.g. in tools like IRRToolSet, but that there are a probably a number > of hacks built on top of perl, telnetting to port 43, or whatever, > which might not be equally fortunate. > > Workarounds to this seem to be adding some kind of version negotiation > or inclusion to the whois protocol (in the future, maybe using CRISP), > so that only the clients who signal "yes, I can process IPv6 records!" > would activate the IPv6 context processing. This could also be passed > to the whois server with an option, like '--use-rpslng' or '-6'. Or > maybe the client would state which records it wants to get, e.g. > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > something, for "NEW", otherwise only v4 would be returned :) for > both). At least RIPE database allows the use of '-Vxxx' verstion > string to tell about the version of the client software. > > The exact details of how this method would work out would need to be > fleshed out. Any takers? I don't believe this would be particularly productive. These are implementation details which are really outside the scope of the RPSLng work. I don't see the objections to RPSLng as objective technical issues, but rather subjective preferences. > > Personally, when I was trying to form an opinion on this subject, I > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > case. It doesn't seem to address how one could specify different > unicast/multicast policies, or how to specify different v4/v6 > policies. This is also one goal of RPSLng.. even though the major > operators who do have multicast or v6 often want their policies to be > the same. > > How would this work out if a "more intelligence" model was adopted? > > (I'm personally a bit unsure whether a "more intelligence in the > tools" -model would or would not make sense at this point, but I think > I can see both sides of the argument..) It is very difficult to judge the impact of such a model without having a complete census of the various tools in use by ISP's. For example, C&W has an extensive set of in-house developed tools which interact with IRR's. Is it fair to ask them to hack up their tools to fit this model? > > Could we get some form of discussion and maybe consensus on what would > seem to be the right way forward? :-) I think we have already reached the point of "rough" consensus. Again, I view the expressed objections as subjective preferences rather than solid technical beefs with the specification. Regards, Larry > > =========== > Date: Tue, 23 Sep 2003 09:00:06 +0930 > From: Mark Prior > To: curtis at fictitious.org > Cc: Pekka Savola , iesg at ietf.org, rpslng at ripe.net, > rps at ietf.org > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > Curtis Villamizar wrote: > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > RPSL. > > Superset is probably not the best word to describe what I want. > > > The issue is just how do you make transition easiest, supporting older > > RPSL only clients. If you just extend import rather than rename it > > mp-import and extend it, then old RPSL only clients will consider you > > autnum broken. If you include mp-import but forget to reflect you > > IPv4 policy in plain import then the old RPSL client will pick up a > > subset of you policy. > > > > In either case, extending import, or adding mp-import and putting the > > extensions there, it would make for a smoother transition if the > > server code could recognize old clients and feed them with objects > > translated into plain RPSL. > > I think I have been consistent in wanting the smarts to be in the > software and not the language. I would prefer to overload the syntax > then create new syntax and let the software work out what is required. > We don't use different syntax in computer languages when we want to > operate on integers rather than reals so why make the distinction in > RPSL? If we have a route object that has a IPv6 address in it surely the > software can work out if it wants it or not given it's current context? > > I know you (and others :-) keep on about the old clients but we have > left them behind once before in the transition from RIPE 181 to RPSL so > do it again but this time lets leave some mechanism behind so that when > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > not part of the language is a pathetic excuse in my book for not fixing > it. If we need a "shim" document to describe the interaction between a > server and a client then lets do it. It would make the client software > writers life a lot easier if there weren't (at least) 3 server > interaction languages to deal with. > > Mark. > ========== From randy at psg.com Tue Jan 13 17:29:23 2004 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2004 08:29:23 -0800 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> Message-ID: then let me register my support for the issues and approaches marc raises. perhaps the system is for the benefit of operations more than the ease of registries? randy From ljb at merit.edu Tue Jan 13 18:03:24 2004 From: ljb at merit.edu (Larry J. Blunk) Date: 13 Jan 2004 12:03:24 -0500 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: References: <1074010929.3795.45.camel@ablate.merit.edu> Message-ID: <1074013404.3795.52.camel@ablate.merit.edu> On Tue, 2004-01-13 at 11:29, Randy Bush wrote: > then let me register my support for the issues and approaches > marc raises. perhaps the system is for the benefit of operations > more than the ease of registries? > > randy > There are a number of operators that run their own registries (e.g. Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal about preserving the syntax of existing RPSL attributes. -Larry From randy at psg.com Tue Jan 13 18:17:23 2004 From: randy at psg.com (Randy Bush) Date: Tue, 13 Jan 2004 09:17:23 -0800 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] References: <1074010929.3795.45.camel@ablate.merit.edu> <1074013404.3795.52.camel@ablate.merit.edu> Message-ID: >> then let me register my support for the issues and approaches >> marc raises. perhaps the system is for the benefit of operations >> more than the ease of registries? > There are a number of operators that run their own registries (e.g. > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > about preserving the syntax of existing RPSL attributes. thanks for representing operations. but i are one. and i have a (small) registry. i want the operational fix, thanks. randy From david at iprg.nokia.com Tue Jan 13 21:25:49 2004 From: david at iprg.nokia.com (David Kessens) Date: Tue, 13 Jan 2004 12:25:49 -0800 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: ; from Randy Bush on Tue, Jan 13, 2004 at 08:29:23AM -0800 References: <1074010929.3795.45.camel@ablate.merit.edu> Message-ID: <20040113122549.C2159@iprg.nokia.com> On Tue, Jan 13, 2004 at 08:29:23AM -0800, Randy Bush wrote: > then let me register my support for the issues and approaches > marc raises. perhaps the system is for the benefit of operations > more than the ease of registries? I have always agreed with Marc's comments/views on this. However, it was also my impression that we were a vocal but small minority. 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. David Kessens --- From curtis at workhorse.fictitious.org Tue Jan 13 18:03:12 2004 From: curtis at workhorse.fictitious.org (Curtis Villamizar) Date: Tue, 13 Jan 2004 12:03:12 -0500 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: Your message of "13 Jan 2004 11:22:09 EST." <1074010929.3795.45.camel@ablate.merit.edu> Message-ID: <200401131703.i0DH3CRX053524@workhorse.fictitious.org> In message <1074010929.3795.45.camel at ablate.merit.edu>, "Larry J. Blunk" writes : > On Fri, 2004-01-02 at 03:24, Pekka Savola wrote: > > Hi, > > > > (I tailed down the Cc: list..) > > > > On Sat, 27 Dec 2003, Randy Bush wrote: > > > > OK, I now found that the doc did have an IETF Last Call > > > > in late August/Early Sept. > > > > > > and there were technical objections which have not been addressed > > > > Thanks, Randy, for reminding about that. > > > > Based on some off-list discussion, the technical objections being > > referred to are the comments from Mark Prior on the list, one of them > > copied below. > > > > I'll try to summarize the loooo-ong thread somehow. Mark believes > > that the current RPSLng proposition unnecessarily adds complexity to > > the operators' use of the language, as e.g. IPv4 and IPv6 addresses, > > peerings, etc. could all be facilitated by redefining the current > > attributes etc. -- and whichever would be returned could be evaluated > > based on the context. As the number of operators using the language > > is extremely high (and we'd like it to be higher :-) compared to the > > registry/tool implementations, Mark argues that optimizing for the > > simplicity to the operators is the most important goal. > > > > Curtis objects to this mainly based on the fact that this would break > > the backward compatibility for the clients which do not expect to > > receive IPv6 data back from their queries. This could be easily fixed > > e.g. in tools like IRRToolSet, but that there are a probably a number > > of hacks built on top of perl, telnetting to port 43, or whatever, > > which might not be equally fortunate. > > > > Workarounds to this seem to be adding some kind of version negotiation > > or inclusion to the whois protocol (in the future, maybe using CRISP), > > so that only the clients who signal "yes, I can process IPv6 records!" > > would activate the IPv6 context processing. This could also be passed > > to the whois server with an option, like '--use-rpslng' or '-6'. Or > > maybe the client would state which records it wants to get, e.g. > > '-6' for only v6 records, '-4' for only v4 records, nothing (or -N (or > > something, for "NEW", otherwise only v4 would be returned :) for > > both). At least RIPE database allows the use of '-Vxxx' verstion > > string to tell about the version of the client software. > > > > The exact details of how this method would work out would need to be > > fleshed out. Any takers? > > I don't believe this would be particularly productive. These > are implementation details which are really outside the scope of > the RPSLng work. I don't see the objections to RPSLng as objective > technical issues, but rather subjective preferences. I'll agree with that. So if any comments I made having to do with transition and backwards compatibility are holding this up, comments which I beleive I made as suggestions, then please consider those to be resolved issues. > > Personally, when I was trying to form an opinion on this subject, I > > found myself thinking that Mark's proposal addresses only IPv4/IPv6 > > case. It doesn't seem to address how one could specify different > > unicast/multicast policies, or how to specify different v4/v6 > > policies. This is also one goal of RPSLng.. even though the major > > operators who do have multicast or v6 often want their policies to be > > the same. > > > > How would this work out if a "more intelligence" model was adopted? > > > > (I'm personally a bit unsure whether a "more intelligence in the > > tools" -model would or would not make sense at this point, but I think > > I can see both sides of the argument..) > > It is very difficult to judge the impact of such a model without > having a complete census of the various tools in use by ISP's. For > example, C&W has an extensive set of in-house developed tools which > interact with IRR's. Is it fair to ask them to hack up their tools > to fit this model? > > > > > Could we get some form of discussion and maybe consensus on what would > > seem to be the right way forward? :-) > > I think we have already reached the point of "rough" consensus. > Again, I view the expressed objections as subjective preferences rather > than solid technical beefs with the specification. > > Regards, > Larry I agree here too. Perhaps Mark can tell us whether he has any specific suggestions for changing the language from what is currently proposed. Curtis > > =========== > > Date: Tue, 23 Sep 2003 09:00:06 +0930 > > From: Mark Prior > > To: curtis at fictitious.org > > Cc: Pekka Savola , iesg at ietf.org, rpslng at ripe.net, > > rps at ietf.org > > Subject: Re: [Rps] Re: Last Call: 'RPSLng' to Proposed Standard > > > > Curtis Villamizar wrote: > > > > > How is RPSLng not a superset of RPSL? Nothing has been removed from > > > RPSL. > > > > Superset is probably not the best word to describe what I want. > > > > > The issue is just how do you make transition easiest, supporting older > > > RPSL only clients. If you just extend import rather than rename it > > > mp-import and extend it, then old RPSL only clients will consider you > > > autnum broken. If you include mp-import but forget to reflect you > > > IPv4 policy in plain import then the old RPSL client will pick up a > > > subset of you policy. > > > > > > In either case, extending import, or adding mp-import and putting the > > > extensions there, it would make for a smoother transition if the > > > server code could recognize old clients and feed them with objects > > > translated into plain RPSL. > > > > I think I have been consistent in wanting the smarts to be in the > > software and not the language. I would prefer to overload the syntax > > then create new syntax and let the software work out what is required. > > We don't use different syntax in computer languages when we want to > > operate on integers rather than reals so why make the distinction in > > RPSL? If we have a route object that has a IPv6 address in it surely the > > software can work out if it wants it or not given it's current context? > > > > I know you (and others :-) keep on about the old clients but we have > > left them behind once before in the transition from RIPE 181 to RPSL so > > do it again but this time lets leave some mechanism behind so that when > > we need (RPSLng)ng we don't go through this pain yet again. Saying it's > > not part of the language is a pathetic excuse in my book for not fixing > > it. If we need a "shim" document to describe the interaction between a > > server and a client then lets do it. It would make the client software > > writers life a lot easier if there weren't (at least) 3 server > > interaction languages to deal with. > > > > Mark. > > ========== > > > _______________________________________________ > Rps mailing list > Rps at ietf.org > https://www1.ietf.org/mailman/listinfo/rps From curtis at workhorse.fictitious.org Tue Jan 13 19:15:46 2004 From: curtis at workhorse.fictitious.org (Curtis Villamizar) Date: Tue, 13 Jan 2004 13:15:46 -0500 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: Your message of "Tue, 13 Jan 2004 09:17:23 PST." Message-ID: <200401131815.i0DIFkRX053871@workhorse.fictitious.org> In message , Randy Bush writes: > >> then let me register my support for the issues and approaches > >> marc raises. perhaps the system is for the benefit of operations > >> more than the ease of registries? > > There are a number of operators that run their own registries (e.g. > > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > > about preserving the syntax of existing RPSL attributes. > > thanks for representing operations. but i are one. and i have a > (small) registry. i want the operational fix, thanks. > > randy Randy, Exactly what fix is it that you want? Curtis From Frank.Bohnsack at deu.mci.com Tue Jan 13 22:41:47 2004 From: Frank.Bohnsack at deu.mci.com (Frank Bohnsack) Date: Tue, 13 Jan 2004 22:41:47 +0100 Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: <1074013404.3795.52.camel@ablate.merit.edu> Message-ID: > On Tue, 2004-01-13 at 11:29, Randy Bush wrote: > > then let me register my support for the issues and approaches > > marc raises. perhaps the system is for the benefit of operations > > more than the ease of registries? > > > > randy > > > > There are a number of operators that run their own registries (e.g. > Level3, Verio, C&W, etc.). Ping Lu (formerly of C&W) was very vocal > about preserving the syntax of existing RPSL attributes. > > -Larry We doesn't have a own registry, but a lot of own tools which deals with RPSL. >From my point of view I have to change both, my RPSL language parser and the interpreter. So I could not see a benefit of one solution. Personally, I would back Marks position but can not really give you a reason. How about a acclamation at the next RIPE meeting ? Frank From pekkas at netcore.fi Wed Jan 14 07:18:47 2004 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 14 Jan 2004 08:18:47 +0200 (EET) Subject: Separate attributes vs context-aware software [RE: RPS WG (was Re: [Rps] Re: Latest RPSLng draft)] In-Reply-To: <20040113122549.C2159@iprg.nokia.com> Message-ID: Hi, On Tue, 13 Jan 2004, David Kessens wrote: > On Tue, Jan 13, 2004 at 08:29:23AM -0800, Randy Bush wrote: > > then let me register my support for the issues and approaches > > marc raises. perhaps the system is for the benefit of operations > > more than the ease of registries? > > I have always agreed with Marc's comments/views on this. However, it > was also my impression that we were a vocal but small minority. > > 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. 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. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From simon at limmat.switch.ch Wed Jan 14 17:07:52 2004 From: simon at limmat.switch.ch (Simon Leinen) Date: Wed, 14 Jan 2004 17:07:52 +0100 Subject: Separate attributes vs context-aware software [RE: RPS WG...] In-Reply-To: (Pekka Savola's message of "Wed, 14 Jan 2004 08:18:47 +0200 (EET)") References: Message-ID: 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. From andrei at ripe.net Wed Jan 28 10:41:09 2004 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 28 Jan 2004 10:41:09 +0100 Subject: [Rps] Re: Separate attributes vs context-aware software [RE: RPS WG...] In-Reply-To: References: Message-ID: <401783B5.1000004@ripe.net> 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 From tim.streater at dante.org.uk Thu Jan 29 16:03:17 2004 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 29 Jan 2004 15:03:17 +0000 Subject: Status of RPSLng In-Reply-To: <401783B5.1000004@ripe.net> References: <401783B5.1000004@ripe.net> Message-ID: <6.0.1.1.0.20040129115803.03631878@mail.dante.org.uk> Dear All, I just recently joined this list. At DANTE we are interested in putting our v6 policy into our autnum object. Knowing there was some effort under way to make this possible, I looked at recent mails on this list and at draft-blunk-rpslng-02. As far as I can tell, we have inet6num supported in production, but everything else is under test or still under discussion. Is there some sort of roadmap or even rough estimate when everything will move into production? We are keen to start generating route filters as we do for v4. Thanks, -- Tim