Last Call: 'RPSLng' to Proposed Standard
The IESG has received a request from an individual submitter to consider 'RPSLng' <draft-blunk-rpslng-01.txt> as a Proposed Standard. This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-09-23. File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt
On Tue, 26 Aug 2003, The IESG wrote:
The IESG has received a request from an individual submitter to consider 'RPSLng' <draft-blunk-rpslng-01.txt> as a Proposed Standard. This document has been reviewed in the IETF but is not the product of an IETF Working Group. [...] File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt
If I'd use the "sirs (or airs)" classification of this document review, I'd say: * This draft is on the right track but has open issues, described in the review. Below are my comments to the draft. Overall, I think the document is pretty good, and a very relevant piece of work; it's needed by IPv6 ops folks. However, there seem to be a number of (more or less) textual inaccuracies and confusion in the document, which should be settled prior to publication. I think there are the three most important issues here are: * issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what? * issue 3) -- whether ipvX should imply only unicast or both unicast and multicast? * issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect) substantial ----------- 1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", or something like that -- if for no other reason than to have a forward references in the RFC index to this document? 2) one important aspect to consider is interaction with old specification, that is: Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below. ==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words would be useful on how to effectively transition/co-exist with both RPSL and RPSLng? 3) I note that there is no way to specify "these attributes affect both multicast and unicast", you have to always include the both, in: The possible values for <afi> are: ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast ==> is this intended? Is there a particular reason why we couldn't just assume that "ipv4" includes both unicast and multicast? Where multicast is deployed, it's typically mostly congruent with unicast infrastructure, and where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" implication? Or should there be a separate value which would imply the both? 4) it seems that ipv6_address dictionary attribute (though trivial) has not been defined: In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary. ==> this should probably be something like: <ipv4_address> An IPv6 address is represented as [blah blah blah] 5) As the document is Standards Track (and not e.g. Informational, which would also be a possibility), I'm not sure whether it's appropriate to wave away some, possibly important, pieces of the specification, with like: 2.3.2 <mp-filter> The <mp-filter> expression is an extension of the RPSL <filter> expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of <mp-filter> here and refer the reader to RFC 2622 [1]. and: 4.5 inet-rtr Class The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses. 6) there seem to be a case or two where it is not clear whether including the discussion in this specification is appropriate (and just not implementation-specific issues, or issues relating to the user's RPSL user interface); in below, the last sentence seems a bit dubious: The evaluation of an <import-expression> is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} <mp-filter> or invalid <mp-peering> depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} <mp-filter> may issue a warning. 7) related to point 4), it may not be apparent what's the intent of the specification, unless done explicitly; for example: Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22} the mp-filter should be evaluated as {NOT ANY}. ==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? Note that that's very valid for IPv6 too, except perhaps due to the way it's written (should be {::/0}). I.e., I think it's very important to specify the grammar for properly so that the IPv4 and IPv6 addresses can be distinguished properly in all cases. 8) related to point 5), it is not clear whether the document is intended to be include conclusive lists of class attributes or just modified ones; for example: 3. New route6 Class member-of list of <route-set-name> optional, multi-valued aggr-bndry <as-expression> optional, single-valued aggr-mtd inbound or outbound optional, single-valued [<as-expression>] mnt-lower list of <mntner-name> optional, multi-valued ==> note that there are multiple attributes which do not seem to be referred to in this document. Is the list in the document intended as a conclusive list of attributes or just examples? Based on that, one may have to decide whether to remove non-modified ones, or whether to ensure that everything is always present [where's route-set-name or as-expression, for example?] (and possibly separate new and classic attributes). ==> similar in section 5, at least. 9) there seem to be some mismatches or missing specification; for example, in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the like, but the only similar thing in the document so far as been "<ipv6-address-prefix>": mp-members list of (<ipv4-address-prefix-range> optional, multi-valued or <ipv6-address-prefix-range> or <route-set-name> or <route-set-name><range-operator>) and: In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects. ==> it seems the document may be trying to take too many shortcuts by leaving the values undefined and to be intuitively filled in by the implementors. 10) remote-endpoint-address specifies some some encapsulations: <remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num). ==> I believe DVMRP is probably very much obsolete in this interdomain, RPSLng context and could be removed. ==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already cover that, *assuming* that one looks at the <ipvX-address> and <endpont-address> to figure out what it is. Including both in here seems redundant to me; but if that's the path, also include IPv6inIPv6 and IPv4inIPv6, please! 11) split the references to normative and informative; the first two are probably normative, and the last one informative. editorial --------- ==> the document requires Table of Contents, as it's more than 15 pages long. RPSLng draft-blunk-rpslng-01.txt ==> spell out RPSLng in the title. Abstract This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. ==> similarly, spell out RPSL here. Blunk, et al. Expires January 23, 2004 [Page 1] Internet-Draft RPSLng July 2003 ==> I note that the document does not have page breaks (^L) , so it's more difficult to read and does not print correctly. This document proposes to extend RPSL according to the following goals and requirements: Provide RPSL extensibility in the dimension of address families. Specifically, to allow users to document routing policy for IPv6 and multicast. ==> add bullets, dashes, or whatever to the list of four goals/requirements. Clarity and non-ambiguity: RPSL information is used by humans in addition to software tools. ==> s/Clarity/Maintain clarity/ Address Family Identifier, <afi>, is a RPSL list of address families ==> s/a RPSL/an RPSL/ (everywhere where applicable) ? mp-import ::= [protocol <protocol1>] [into <protocol2>] <import-expression> ==> these should probably be protocol-1 and protocol-2, to be in line with the rest of the document conventions? The <mp-filter> expression is an extension of the RPSL <filter> expression [section 5.4 of RFC 2622 [1]] s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a few other places) mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo except { afi ipv6.unicast,ipv4 from AS2 action pref = 2; accept AS226 except { afi ipv6.unicast from AS3 action pref = 3; accept {3FFE:FFFF::/35} } } ==> should probably use a some more bogus AS number in the example ==> should probably use the /32 prefix length in the example, the same in some exampler later on. Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy: ==> s/evaluation/the evaluation/ ==> s/that is/that is,/ to a particular address family using the traditional filtering mechanism in use in IRR systems today. ==> spell out IRR. mp-peer <protocol> <ipv4_address> <options> or optional, <protocol> <ipv6_address> <options> or multi-valued ==> in here, and many other places, one uses "ipv4_address" and the like. Note tha lower dash, not dash in the middle; in many other places it's "ipv4-address" and the like. Pick one approach and stick to it, please :-) In the aut-num class, the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The default when no additional set items are specified is "ANY". ==> s/They/The/. ==> s/all more specifics/any route/? (why would keyword "ANY" refer to more specifics only? that would be highly confusing) The <country-code> must be a valid two-letter ISO 3166 country code identifier. <netname> is a symbolic name for the specified IPv6 address space. ==> the country code specification is, at least, outside of the scope of this document, I guess :-) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Savola writes:
On Tue, 26 Aug 2003, The IESG wrote:
The IESG has received a request from an individual submitter to consider 'RPSLng' <draft-blunk-rpslng-01.txt> as a Proposed Standard. This document has been reviewed in the IETF but is not the product of an IETF Working Group. [...] File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-blunk-rpslng-01.txt
If I'd use the "sirs (or airs)" classification of this document review, I'd say:
* This draft is on the right track but has open issues, described in the review.
Below are my comments to the draft. Overall, I think the document is pretty good, and a very relevant piece of work; it's needed by IPv6 ops folks.
Thanks for providing the comments. I'll offer some information that may clarify some of the points you brought up, but Larry is the author and is much closer to the implementation and deployment than I am. Larry can correct me if I'm inaccurate in any of my comments. First a bit on history, just as an FYI. RPSL has been in use by RIPE to manage the European routing registry for nearly a decade and its predicessor RIPE-181 before that. There are numerous other shared RPSL repositories such as the US RADB and quite a few providers that run their own private repository. See rfc2650 "Using RPSL in Practice" for details. The existing RPSL documents how IPv4 policy was described but the RAToolSet supported syntax for IPv6. At the time we had extensive operational experience with the IPv4 subset and none at all with the IPv6 subset. Larry Blunk is the current primary developer/maintainer, having taken over from the original author, Cengiz Alaettinoglu. The IPv6 syntax has evolved and is now in use. One of the reasons this document has seen so little comment is it describes something people have been using for quite some time and it works.
However, there seem to be a number of (more or less) textual inaccuracies and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
* issue 3) -- whether ipvX should imply only unicast or both unicast and multicast?
Unicast and multicast are defined in separate statements. The document is clear on this. If you want both unicast and multicast you just specify ipvX,ipvX.multicast. The text is completely unambigous stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast (equivalent to ipv6)" under "The possible values for <afi> are:" stating "An <afi-list> is defined as a comma separated list of one or more afi values", showing where <afi-list> is used and multiple examples are given.
* issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect)
There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing <filter> accepts IPv4 addresses. The <mp-filter> allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included.
substantial -----------
1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", or something like that -- if for no other reason than to have a forward references in the RFC index to this document?
This document extends RFC-1622. If it updated RFC-1622 it would mean that it represents a change to all usage of RFC-1622.
2) one important aspect to consider is interaction with old specification, that is:
Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below.
==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words would be useful on how to effectively transition/co-exist with both RPSL and RPSLng?
See prior note. Not an issue.
3) I note that there is no way to specify "these attributes affect both multicast and unicast", you have to always include the both, in:
The possible values for <afi> are:
ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast
==> is this intended? Is there a particular reason why we couldn't just assume that "ipv4" includes both unicast and multicast? Where multicast is deployed, it's typically mostly congruent with unicast infrastructure, and where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" implication? Or should there be a separate value which would imply the both?
Yes this is intended. See prior note.
4) it seems that ipv6_address dictionary attribute (though trivial) has not been defined:
In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary.
==> this should probably be something like:
<ipv4_address> An IPv6 address is represented as [blah blah blah]
Next-hop is part of the initial RPSL Dictionary defined in RFC1622 section 7.1 and is used to define the next hop of a static route. In order to support this ipv6_address is added. The dictionary type is not defined, just at the builtin dictionary type ipv4_address is not defined in RPSL. The format is assumed to be the same as ipv4-address. Integer is also not defined. RPSL does however give the format for ipv4-address. <ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses. A similar entry should appear for ipv6-address in this draft. Though numerous examples are given, the syntax is not spelled out.
5) As the document is Standards Track (and not e.g. Informational, which would also be a possibility), I'm not sure whether it's appropriate to wave away some, possibly important, pieces of the specification, with like:
2.3.2 <mp-filter>
The <mp-filter> expression is an extension of the RPSL <filter> expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of <mp-filter> here and refer the reader to RFC 2622 [1].
and:
4.5 inet-rtr Class
The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses.
How hard is this to figure out. In RPSL peer is defined as: Each peer attribute, if present, specifies a protocol peering with another router. The value of a peer attribute has the following syntax: <protocol> <ipv4-address> <options> | <protocol> <inet-rtr-name> <options> | <protocol> <rtr-set-name> <options> | <protocol> <peering-set-name> <options> ... Just substitute ipv6-address for ipv4-address. The above definition need not be repeated in the new draft with the trivial substitution.
6) there seem to be a case or two where it is not clear whether including the discussion in this specification is appropriate (and just not implementation-specific issues, or issues relating to the user's RPSL user interface); in below, the last sentence seems a bit dubious:
The evaluation of an <import-expression> is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} <mp-filter> or invalid <mp-peering> depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} <mp-filter> may issue a warning.
This just explains a situation in which an invalid <mp-peering> can be specified or an expression can evaluate to {NOT ANY} <mp-filter>. Removing the explanation results in: If an <import-expression> evaluates to an invalid <mp-peering> then an error is returned. If an <import-expression> evaluates to {NOT ANY} <mp-filter> a warning may be issued. I think the existing content with the clarifying text is much better but could stand a little rewording.
7) related to point 4), it may not be apparent what's the intent of the specification, unless done explicitly; for example:
Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy:
aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22}
the mp-filter should be evaluated as {NOT ANY}.
And according to the above text a warning may be issued.
==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? Note that that's very valid for IPv6 too, except perhaps due to the way it's written (should be {::/0}). I.e., I think it's very important to specify the grammar for properly so that the IPv4 and IPv6 addresses can be distinguished properly in all cases.
This is why ipv6-address should be specified and 0/0 should then be distinguishable from ::/0 and there is then no ambiguity in the example you gave. Since the address format for IPv6 has been accepted for a long time it may have been overlooked. At least a reference should be made if the exact syntax is defined elsewhere.
8) related to point 5), it is not clear whether the document is intended to be include conclusive lists of class attributes or just modified ones; for example:
3. New route6 Class
member-of list of <route-set-name> optional, multi-valued aggr-bndry <as-expression> optional, single-valued aggr-mtd inbound or outbound optional, single-valued [<as-expression>] mnt-lower list of <mntner-name> optional, multi-valued
==> note that there are multiple attributes which do not seem to be referred to in this document. Is the list in the document intended as a conclusive list of attributes or just examples? Based on that, one may have to decide whether to remove non-modified ones, or whether to ensure that everything is always present [where's route-set-name or as-expression, for example?] (and possibly separate new and classic attributes).
That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 provides extensions to RFC-1622 and explicitly mentions "mnt-routes" and "mnt-lower" attributes.
==> similar in section 5, at least.
9) there seem to be some mismatches or missing specification; for example, in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the like, but the only similar thing in the document so far as been "<ipv6-address-prefix>":
mp-members list of (<ipv4-address-prefix-range> optional, multi-valued or <ipv6-address-prefix-range> or <route-set-name> or <route-set-name><range-operator>)
and:
In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects.
==> it seems the document may be trying to take too many shortcuts by leaving the values undefined and to be intuitively filled in by the implementors.
RPSL defined <ipv4-address>, <address-prefix>, and <address-prefix-range>, in consecutive entries under "RPSL Names, Reserved Words, and Representation". It should be sufficient to state that <ipv6-address-prefix> is the same as <address-prefix> except that a <ipv6-address> is used in place of a <ipv4-address> and <ipv6-address-prefix-range> is the same as <address-prefix-range> except that a <ipv6-address-prefix> is used in place of a <address-prefix>.
10) remote-endpoint-address specifies some some encapsulations:
<remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num).
==> I believe DVMRP is probably very much obsolete in this interdomain, RPSLng context and could be removed.
Whether used or not, DVMRP is supported by RPSL implementations and it does no harm to continue to mantion it until it is determined that there really is no use for DVMRP (ie: when the experiment is declared over).
==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already cover that, *assuming* that one looks at the <ipvX-address> and <endpont-address> to figure out what it is. Including both in here seems redundant to me; but if that's the path, also include IPv6inIPv6 and IPv4inIPv6, please!
Tunnels may be IPv4 in IPv4 due to incomplete native multicast deployment in the IPv4 world. If multicast were not widely deployed in IPv6, then IPv6inIPv6 might be needed. If there existed IPv4 tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is forseen.
11) split the references to normative and informative; the first two are probably normative, and the last one informative.
editorial ---------
==> the document requires Table of Contents, as it's more than 15 pages long.
RPSLng draft-blunk-rpslng-01.txt
==> spell out RPSLng in the title.
Abstract
This memo presents a new set of simple extensions to the RPSL language enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet.
==> similarly, spell out RPSL here.
Blunk, et al. Expires January 23, 2004 [Page 1]
Internet-Draft RPSLng July 2003
==> I note that the document does not have page breaks (^L) , so it's more difficult to read and does not print correctly.
This document proposes to extend RPSL according to the following goals and requirements:
Provide RPSL extensibility in the dimension of address families. Specifically, to allow users to document routing policy for IPv6 and multicast.
==> add bullets, dashes, or whatever to the list of four goals/requirements.
Clarity and non-ambiguity: RPSL information is used by humans in addition to software tools.
==> s/Clarity/Maintain clarity/
Address Family Identifier, <afi>, is a RPSL list of address families
==> s/a RPSL/an RPSL/ (everywhere where applicable) ?
mp-import ::= [protocol <protocol1>] [into <protocol2>] <import-expression>
==> these should probably be protocol-1 and protocol-2, to be in line with the rest of the document conventions?
The <mp-filter> expression is an extension of the RPSL <filter> expression [section 5.4 of RFC 2622 [1]]
s/[section 5.4 of RFC 2622 [1]]/(section 5.4 of RFC 2622 [1])/ (similar in a few other places)
mp-import: afi ipv6.unicast,ipv4 from AS1 action pref = 1; accept as-foo except { afi ipv6.unicast,ipv4 from AS2 action pref = 2; accept AS226 except { afi ipv6.unicast from AS3 action pref = 3; accept {3FFE:FFFF::/35} } }
==> should probably use a some more bogus AS number in the example ==> should probably use the /32 prefix length in the example, the same in some exampler later on.
Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy:
==> s/evaluation/the evaluation/ ==> s/that is/that is,/
to a particular address family using the traditional filtering mechanism in use in IRR systems today.
==> spell out IRR.
mp-peer <protocol> <ipv4_address> <options> or optional, <protocol> <ipv6_address> <options> or multi-valued
==> in here, and many other places, one uses "ipv4_address" and the like. Note tha lower dash, not dash in the middle; in many other places it's "ipv4-address" and the like. Pick one approach and stick to it, please :-)
In the aut-num class, the IPv6 prefix ranges may be mixed with IPv4 prefix ranges. They keyword "ANY" is also allowed which means all more specifics. The default when no additional set items are specified is "ANY".
==> s/They/The/. ==> s/all more specifics/any route/? (why would keyword "ANY" refer to more specifics only? that would be highly confusing)
The <country-code> must be a valid two-letter ISO 3166 country code identifier. <netname> is a symbolic name for the specified IPv6 address space.
==> the country code specification is, at least, outside of the scope of this document, I guess :-)
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Thanks again. You did a very thorough read of the document. Some of the issues you brought up may have been misunderstandings on your part. You point out a few ommisions such as failure to explicitly defined the syntax for <ipv6-address> and failure to point out some analogous attributes such as <ipv6-prefix> where the definition is just a matter of s/ipv4/ipv6/, some text in need of clarity, and some needed editorial changes. Regards, Curtis ps - once again, Larry, or the folks at RIPE, please feel free to point out any errors I've made.
Inline.. On Wed, 10 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Savola writes: [...]
However, there seem to be a number of (more or less) textual inaccuracies and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to cause inconsistencies in the data.
* issue 3) -- whether ipvX should imply only unicast or both unicast and multicast?
Unicast and multicast are defined in separate statements. The document is clear on this. If you want both unicast and multicast you just specify ipvX,ipvX.multicast. The text is completely unambigous stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast (equivalent to ipv6)" under "The possible values for <afi> are:" stating "An <afi-list> is defined as a comma separated list of one or more afi values", showing where <afi-list> is used and multiple examples are given.
Yes, I'm not saying the document is ambiguous; it's very clear on this. However, what I'm saying is that one perhaps should consider whether a different kind of definitions would be useful -- so that if you want to specify the topology for both unicast and multicast like, you could do it without "ipv4,ipv4.multicast" or "ipv6,ipv6.multicast".
* issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect)
There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing <filter> accepts IPv4 addresses. The <mp-filter> allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included.
I'm not sure if all those modifications are completely straightfoward.
substantial -----------
1) would it be useful to have the RPSLng document have "Updates: 2622, 2725", or something like that -- if for no other reason than to have a forward references in the RFC index to this document?
This document extends RFC-1622. If it updated RFC-1622 it would mean that it represents a change to all usage of RFC-1622.
You mean 2622, not 1622, obviously. I don't see Updates like that at all. What you're describing would seem closer to "Obsoletes". This spec DOES make changes/additions to the existing sec, e.g. at rp-attribute next-hop.
2) one important aspect to consider is interaction with old specification, that is:
Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below.
==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words would be useful on how to effectively transition/co-exist with both RPSL and RPSLng?
See prior note. Not an issue.
Not so sure on that.
3) I note that there is no way to specify "these attributes affect both multicast and unicast", you have to always include the both, in:
The possible values for <afi> are:
ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast
==> is this intended? Is there a particular reason why we couldn't just assume that "ipv4" includes both unicast and multicast? Where multicast is deployed, it's typically mostly congruent with unicast infrastructure, and where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" implication? Or should there be a separate value which would imply the both?
Yes this is intended. See prior note.
I question the intent, but this is not a critical issue for me. It would seem more obvious that "ipv6" should refer to both unicast and multicast, as they're both ipv6.
4) it seems that ipv6_address dictionary attribute (though trivial) has not been defined:
In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary.
==> this should probably be something like:
<ipv4_address> An IPv6 address is represented as [blah blah blah]
Next-hop is part of the initial RPSL Dictionary defined in RFC1622 section 7.1 and is used to define the next hop of a static route. In order to support this ipv6_address is added. The dictionary type is not defined, just at the builtin dictionary type ipv4_address is not defined in RPSL. The format is assumed to be the same as ipv4-address. Integer is also not defined.
RPSL does however give the format for ipv4-address.
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
A similar entry should appear for ipv6-address in this draft. Though numerous examples are given, the syntax is not spelled out.
Yep.
5) As the document is Standards Track (and not e.g. Informational, which would also be a possibility), I'm not sure whether it's appropriate to wave away some, possibly important, pieces of the specification, with like:
2.3.2 <mp-filter>
The <mp-filter> expression is an extension of the RPSL <filter> expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of <mp-filter> here and refer the reader to RFC 2622 [1].
and:
4.5 inet-rtr Class
The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses.
How hard is this to figure out. In RPSL peer is defined as:
Not so hard, but still not given. I'd prefer to spell things out.
Each peer attribute, if present, specifies a protocol peering with another router. The value of a peer attribute has the following syntax:
<protocol> <ipv4-address> <options> | <protocol> <inet-rtr-name> <options> | <protocol> <rtr-set-name> <options> | <protocol> <peering-set-name> <options>
...
Just substitute ipv6-address for ipv4-address. The above definition need not be repeated in the new draft with the trivial substitution.
Not the whole definition, maybe.
6) there seem to be a case or two where it is not clear whether including the discussion in this specification is appropriate (and just not implementation-specific issues, or issues relating to the user's RPSL user interface); in below, the last sentence seems a bit dubious:
The evaluation of an <import-expression> is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} <mp-filter> or invalid <mp-peering> depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} <mp-filter> may issue a warning.
This just explains a situation in which an invalid <mp-peering> can be specified or an expression can evaluate to {NOT ANY} <mp-filter>. Removing the explanation results in:
If an <import-expression> evaluates to an invalid <mp-peering> then an error is returned. If an <import-expression> evaluates to {NOT ANY} <mp-filter> a warning may be issued.
I think the existing content with the clarifying text is much better but could stand a little rewording.
Fine with me.
7) related to point 4), it may not be apparent what's the intent of the specification, unless done explicitly; for example:
Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy:
aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22}
the mp-filter should be evaluated as {NOT ANY}.
And according to the above text a warning may be issued.
==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? Note that that's very valid for IPv6 too, except perhaps due to the way it's written (should be {::/0}). I.e., I think it's very important to specify the grammar for properly so that the IPv4 and IPv6 addresses can be distinguished properly in all cases.
This is why ipv6-address should be specified and 0/0 should then be distinguishable from ::/0 and there is then no ambiguity in the example you gave.
Since the address format for IPv6 has been accepted for a long time it may have been overlooked. At least a reference should be made if the exact syntax is defined elsewhere.
right.
8) related to point 5), it is not clear whether the document is intended to be include conclusive lists of class attributes or just modified ones; for example:
3. New route6 Class
member-of list of <route-set-name> optional, multi-valued aggr-bndry <as-expression> optional, single-valued aggr-mtd inbound or outbound optional, single-valued [<as-expression>] mnt-lower list of <mntner-name> optional, multi-valued
==> note that there are multiple attributes which do not seem to be referred to in this document. Is the list in the document intended as a conclusive list of attributes or just examples? Based on that, one may have to decide whether to remove non-modified ones, or whether to ensure that everything is always present [where's route-set-name or as-expression, for example?] (and possibly separate new and classic attributes).
That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 provides extensions to RFC-1622 and explicitly mentions "mnt-routes" and "mnt-lower" attributes.
==> similar in section 5, at least.
9) there seem to be some mismatches or missing specification; for example, in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the like, but the only similar thing in the document so far as been "<ipv6-address-prefix>":
mp-members list of (<ipv4-address-prefix-range> optional, multi-valued or <ipv6-address-prefix-range> or <route-set-name> or <route-set-name><range-operator>)
and:
In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects.
==> it seems the document may be trying to take too many shortcuts by leaving the values undefined and to be intuitively filled in by the implementors.
RPSL defined <ipv4-address>, <address-prefix>, and <address-prefix-range>, in consecutive entries under "RPSL Names, Reserved Words, and Representation". It should be sufficient to state that <ipv6-address-prefix> is the same as <address-prefix> except that a <ipv6-address> is used in place of a <ipv4-address> and <ipv6-address-prefix-range> is the same as <address-prefix-range> except that a <ipv6-address-prefix> is used in place of a <address-prefix>.
maybe
10) remote-endpoint-address specifies some some encapsulations:
<remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num).
==> I believe DVMRP is probably very much obsolete in this interdomain, RPSLng context and could be removed.
Whether used or not, DVMRP is supported by RPSL implementations and it does no harm to continue to mantion it until it is determined that there really is no use for DVMRP (ie: when the experiment is declared over).
It seems irrelevant in this context, and potentially even harmful (building public interdomain DVMRP tunnels is not one of the brightest notions..).
==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP already cover that, *assuming* that one looks at the <ipvX-address> and <endpont-address> to figure out what it is. Including both in here seems redundant to me; but if that's the path, also include IPv6inIPv6 and IPv4inIPv6, please!
Tunnels may be IPv4 in IPv4 due to incomplete native multicast deployment in the IPv4 world.
Right.
If multicast were not widely deployed in IPv6, then IPv6inIPv6 might be needed.
That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels extensively.
If there existed IPv4 tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is forseen.
You keep obsolete and dangerous entries like DVMRP, but fail to add those that are really needed now, and in the future? Doesn't seem like a good practice. But my point was not that; if you read it closely, my point was that you don't have to specify the inner and outer protocols of the tunnel, necessarily. Endpoint addresses and addresses assigned on the tunnel already yield that information! [snip to the end] -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309111134070.10628-100000@netcore.fi>, Pekka Savola writes:
Inline..
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Sav
On Wed, 10 Sep 2003, Curtis Villamizar wrote: ola
writes: [...]
However, there seem to be a number of (more or less) textual inaccuracies
and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to cause inconsistencies in the data.
The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely.
* issue 3) -- whether ipvX should imply only unicast or both unicast and
multicast?
Unicast and multicast are defined in separate statements. The document is clear on this. If you want both unicast and multicast you just specify ipvX,ipvX.multicast. The text is completely unambigous stating "ipv4.unicast (equivalent to ipv4)" and "ipv6.unicast (equivalent to ipv6)" under "The possible values for <afi> are:" stating "An <afi-list> is defined as a comma separated list of one or more afi values", showing where <afi-list> is used and multiple examples are given.
Yes, I'm not saying the document is ambiguous; it's very clear on this.
However, what I'm saying is that one perhaps should consider whether a different kind of definitions would be useful -- so that if you want to specify the topology for both unicast and multicast like, you could do it without "ipv4,ipv4.multicast" or "ipv6,ipv6.multicast".
People are using this in production networks. I'd give more weight to the preferences of people using it for quite some time.
* issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect)
There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing <filter> accepts IPv4 addresses. The <mp-filter> allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included.
I'm not sure if all those modifications are completely straightfoward.
That's fine. Sometimes when something has been in use for a while the people that have been using it won't see an ambiguity or ommission because they already know how things work. Please be specific if there are instances of this.
substantial -----------
1) would it be useful to have the RPSLng document have "Updates: 2622, 27 25", or something like that -- if for no other reason than to have a forward references in the RFC index to this document?
This document extends RFC-1622. If it updated RFC-1622 it would mean that it represents a change to all usage of RFC-1622.
You mean 2622, not 1622, obviously.
Oops. Yeah.
I don't see Updates like that at all. What you're describing would seem closer to "Obsoletes". This spec DOES make changes/additions to the existing sec, e.g. at rp-attribute next-hop.
It makes additions only. For example, IPv6 changes to next-hop only apply to IPv6 static routes.
2) one important aspect to consider is interaction with old specification , that is:
Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below.
==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words wo uld be useful on how to effectively transition/co-exist with both RPSL and RPSLng?
See prior note. Not an issue.
Not so sure on that.
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
3) I note that there is no way to specify "these attributes affect both multicast and unicast", you have to always include the both, in:
The possible values for <afi> are:
ipv4 ipv4.unicast (equivalent to ipv4) ipv4.multicast ipv6 ipv6.unicast (equivalent to ipv6) ipv6.multicast
==> is this intended? Is there a particular reason why we couldn't just assume that "ipv4" includes both unicast and multicast? Where multicast
is
deployed, it's typically mostly congruent with unicast infrastructure, an d where it isn't, I guess it wouldn't hurt to have "ipv4 = ipv4.{both}" implication? Or should there be a separate value which would imply the both?
Yes this is intended. See prior note.
I question the intent, but this is not a critical issue for me. It would seem more obvious that "ipv6" should refer to both unicast and multicast, as they're both ipv6.
Quite frankly - tough luck. The people using this recognize that the vast majority of policy statements are for unicast and therefore dropping the .unicast makes the most sense to the people that are already using this.
4) it seems that ipv6_address dictionary attribute (though trivial) has n ot been defined:
In order to support IPv6 addresses specified with the next-hop rp-attribute, a new predefined dictionary type entitled ipv6_address is added to the RPSL dictionary.
==> this should probably be something like:
<ipv4_address> An IPv6 address is represented as [blah blah blah]
Next-hop is part of the initial RPSL Dictionary defined in RFC1622 section 7.1 and is used to define the next hop of a static route. In order to support this ipv6_address is added. The dictionary type is not defined, just at the builtin dictionary type ipv4_address is not defined in RPSL. The format is assumed to be the same as ipv4-address. Integer is also not defined.
RPSL does however give the format for ipv4-address.
<ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses.
A similar entry should appear for ipv6-address in this draft. Though numerous examples are given, the syntax is not spelled out.
Yep.
... Larry - it looks like you have an edit to make.
5) As the document is Standards Track (and not e.g. Informational, which would also be a possibility), I'm not sure whether it's appropriate to wa ve away some, possibly important, pieces of the specification, with like:
2.3.2 <mp-filter>
The <mp-filter> expression is an extension of the RPSL <filter> expression [section 5.4 of RFC 2622 [1]], with the inclusion of the ability to specify IPv6 address prefixes in Address-Prefix sets. For the sake of brevity, we do not include the full definition of <mp-filter> here and refer the reader to RFC 2622 [1].
and:
4.5 inet-rtr Class
The "mp-peer:" attribute is defined below. The difference between this attribute and the "peer:" attribute is the inclusion of support for IPv6 addresses.
How hard is this to figure out. In RPSL peer is defined as:
Not so hard, but still not given. I'd prefer to spell things out.
Again. Tough luck. As long as it is unambiguous it should not need to be spelled out at the cost of lots of pages that duplicate another spec and for which the other spec is still authoritative.
Each peer attribute, if present, specifies a protocol peering with another router. The value of a peer attribute has the following syntax:
<protocol> <ipv4-address> <options> | <protocol> <inet-rtr-name> <options> | <protocol> <rtr-set-name> <options> | <protocol> <peering-set-name> <options>
...
Just substitute ipv6-address for ipv4-address. The above definition need not be repeated in the new draft with the trivial substitution.
Not the whole definition, maybe.
That is the definition and it need not be repeated with the substitution.
6) there seem to be a case or two where it is not clear whether including the discussion in this specification is appropriate (and just not implementation-specific issues, or issues relating to the user's RPSL use r interface); in below, the last sentence seems a bit dubious:
The evaluation of an <import-expression> is done by evaluating all of its components. Evaluation of peering-sets and filter-sets is constrained by the address family. Such constraints may result in a {NOT ANY} <mp-filter> or invalid <mp-peering> depending on implicit or explicit definitions of the address family in the set. In the latter case an error is returned. {NOT ANY} <mp-filter> may issue a warning.
This just explains a situation in which an invalid <mp-peering> can be specified or an expression can evaluate to {NOT ANY} <mp-filter>. Removing the explanation results in:
If an <import-expression> evaluates to an invalid <mp-peering> then an error is returned. If an <import-expression> evaluates to {NOT ANY} <mp-filter> a warning may be issued.
I think the existing content with the clarifying text is much better but could stand a little rewording.
Fine with me.
7) related to point 4), it may not be apparent what's the intent of the specification, unless done explicitly; for example:
Conflicts with explicit or implicit declarations are resolved at runtime, that is during evaluation of a policy expression. For example, when evaluating the following import policy:
aut-num: AS2 mp-import: afi ipv6 from AS1 accept {193.0.0.0/22}
the mp-filter should be evaluated as {NOT ANY}.
And according to the above text a warning may be issued.
==> what if the mp-import would be "afi ipv6 from AS1 accept {0/0}" ? Note that that's very valid for IPv6 too, except perhaps due to the way i t's written (should be {::/0}). I.e., I think it's very important to specify the grammar for properly so that the IPv4 and IPv6 addresses can be distinguished properly in all cases.
This is why ipv6-address should be specified and 0/0 should then be distinguishable from ::/0 and there is then no ambiguity in the example you gave.
Since the address format for IPv6 has been accepted for a long time it may have been overlooked. At least a reference should be made if the exact syntax is defined elsewhere.
right.
... Larry - same edit - some details here.
8) related to point 5), it is not clear whether the document is intended to be include conclusive lists of class attributes or just modified ones; fo r example:
3. New route6 Class
member-of list of <route-set-name> optional, multi-valued aggr-bndry <as-expression> optional, single-valu ed aggr-mtd inbound or outbound optional, single-value d [<as-expression>] mnt-lower list of <mntner-name> optional, multi-value d
==> note that there are multiple attributes which do not seem to be refer red to in this document. Is the list in the document intended as a conclusiv e list of attributes or just examples? Based on that, one may have to deci de whether to remove non-modified ones, or whether to ensure that everything is always present [where's route-set-name or as-expression, for example?] (and possibly separate new and classic attributes).
That is perfectly fine. RFC-1622 defines aggr-bndry and aggr-mtd. RFC-2725 defines mnt-lower. Section 5. point out that RFC-2725 provides extensions to RFC-1622 and explicitly mentions "mnt-routes" and "mnt-lower" attributes.
==> similar in section 5, at least.
9) there seem to be some mismatches or missing specification; for example , in section 4.2, mp-members: refers to "ipv6-address-prefix-range" and the like, but the only similar thing in the document so far as been "<ipv6-address-prefix>":
mp-members list of (<ipv4-address-prefix-range> optional, multi-valu ed or <ipv6-address-prefix-range> or <route-set-name> or <route-set-name><range-operator>)
and:
In RPSLng, these attributes are extended to the route6 and inet6num (described below) classes. Further, the syntax of the existing mnt-routes attribute is modified to allow the optional specification of IPv6 prefix range lists when present in inet6num, route6, and aut-num class objects.
==> it seems the document may be trying to take too many shortcuts by leaving the values undefined and to be intuitively filled in by the implementors.
RPSL defined <ipv4-address>, <address-prefix>, and <address-prefix-range>, in consecutive entries under "RPSL Names, Reserved Words, and Representation". It should be sufficient to state that <ipv6-address-prefix> is the same as <address-prefix> except that a <ipv6-address> is used in place of a <ipv4-address> and <ipv6-address-prefix-range> is the same as <address-prefix-range> except that a <ipv6-address-prefix> is used in place of a <address-prefix>.
maybe
... Larry - looks to me like a second edit.
10) remote-endpoint-address specifies some some encapsulations:
<remote-endpoint-address> indicates the IPv4 or IPv6 address of the remote endpoint of the tunnel. The address family must match that of the local endpoint. <encapsulation> denotes the encapsulation used in the tunnel and is one of {GRE,IPv6inIPv4,IPinIP,DVMRP}. Routing policies for these routers should be described in the appropriate classes (eg. aut-num).
==> I believe DVMRP is probably very much obsolete in this interdomain, RPSLng context and could be removed.
Whether used or not, DVMRP is supported by RPSL implementations and it does no harm to continue to mantion it until it is determined that there really is no use for DVMRP (ie: when the experiment is declared over).
It seems irrelevant in this context, and potentially even harmful (building public interdomain DVMRP tunnels is not one of the brightest notions..).
Until DVMRP moves to historic it doesn't hurt to include it here. If it isn't used it doesn't hurt anything. I'll let Larry make that call.
==> similarly, I do not see the use of IPv6inIPv4. Doesn't IPinIP alread y cover that, *assuming* that one looks at the <ipvX-address> and <endpont-address> to figure out what it is. Including both in here seems redundant to me; but if that's the path, also include IPv6inIPv6 and IPv4inIPv6, please!
Tunnels may be IPv4 in IPv4 due to incomplete native multicast deployment in the IPv4 world.
Right.
If multicast were not widely deployed in IPv6, then IPv6inIPv6 might be needed.
That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels extensively.
OK. Then its needed. ... Larry - add one to the enumeration.
If there existed IPv4 tunnelled over IPv6, then IPv4inIPv6 might be needed. Neither need is forseen.
You keep obsolete and dangerous entries like DVMRP, but fail to add those that are really needed now, and in the future? Doesn't seem like a good practice.
Fine. If you think its needed. ... Larry - another entry.
But my point was not that; if you read it closely, my point was that you don't have to specify the inner and outer protocols of the tunnel, necessarily. Endpoint addresses and addresses assigned on the tunnel already yield that information!
You are smarter than Larry's parser. It needs the help.
[snip to the end]
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Thanks again for the comments. You've pointed to what look to be a few serious ommissions - <ipv6-address> <ipv6-address-prefix-range>, and <ipv6-address-prefix-range> are not defined. Adding IPv6inIPv6 and IPv4inIPv6 wouldn't hurt so those are good additions too. I don't think DVMRP should be deleted without consulting the users.
I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive. On Fri, 12 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309111134070.10628-100000@netcore.fi>, Pekka Savola writes:
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Sav
On Wed, 10 Sep 2003, Curtis Villamizar wrote: ola
writes: [...]
However, there seem to be a number of (more or less) textual inaccuracies
and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to cause inconsistencies in the data.
The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely.
"until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details..
* issue 5) and others-- whether the document needs to specify all the relevant modifications explicitly, or not. IMHO, Stds Track document should describe every change, not just say something like "other attributes are modified in a similar fashion" (or something to that effect)
There is no need to repeat lengthy syntax descriptions contained in the base RFC if a straightforward modification is being made. The example you gave points to text that is perfectly clear. The existing <filter> accepts IPv4 addresses. The <mp-filter> allows either IPv4 or IPv6 addresses to be specified. Perhaps this statement could be worded differently, but the syntax definitely should not be repeated. The syntax definition in RPSL remains authoritative except the additions defined here and no definitions that are not being changed should be included.
I'm not sure if all those modifications are completely straightfoward.
That's fine. Sometimes when something has been in use for a while the people that have been using it won't see an ambiguity or ommission because they already know how things work. Please be specific if there are instances of this.
I think I've already pointed out some of those. All in all, I think *at least* the document should mention which things are being changed, and how (e.g. as a list, even if not "repeating lengthy discussions").
I don't see Updates like that at all. What you're describing would seem closer to "Obsoletes". This spec DOES make changes/additions to the existing sec, e.g. at rp-attribute next-hop.
It makes additions only. For example, IPv6 changes to next-hop only apply to IPv6 static routes.
But still, it changes the rp-attribute.
2) one important aspect to consider is interaction with old specification , that is:
Keeping this in mind, the "import:", "export:", and "default:" attributes implicitly specify IPv4 unicast policy and remain as defined previously in RPSL, and new multi-protocol (prefixed with the string "mp-") attributes are introduced. These will be described below.
==> so, should one get information from both the RPSLng multiprotocol attributes and the old ones? What if they conflict? Maybe some words wo uld be useful on how to effectively transition/co-exist with both RPSL and RPSLng?
See prior note. Not an issue.
Not so sure on that.
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309151040220.27172-100000@netcore.fi>, Pekka Savola writes:
I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive.
In message <Pine.LNX.4.44.0309111134070.10628-100000@netcore.fi>, Pekka Sav
On Fri, 12 Sep 2003, Curtis Villamizar wrote: ola
writes:
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Sav
On Wed, 10 Sep 2003, Curtis Villamizar wrote: ola
writes: [...]
However, there seem to be a number of (more or less) textual inaccura cies
and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to caus e inconsistencies in the data.
The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely.
"until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
Any AS object that provides policy already has many import and export statements. Today IPv4 and IPv6 policy does not match so different statements are needed anyway. For example, AS3561 has 737 import statements and 738 export statements. I would venture to guess their IPv6 policy is a lot simpler.
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details..
I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and UUNET 1995-1998) and I had a lot to do with definition of RPSL and use of RPSL. Considering how long widespread IPv6 deployment has been "coming RSN" the IPv6 world has got nowhere by comparison. I suggest you get off your soapbox and stick with concrete comments and suggestions.
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago.
Larry could probably give you the lineage of this work better than I could. I think David Kessens was working on expressing IPv6 policy in RPSL as far back as 1997 or so. RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Curtis
On Mon, 15 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309151040220.27172-100000@netcore.fi>, Pekka Savola writes:
I'm not sure if I agree with what you call "tough luck", but I've omitted them from the response, as more arguing on those wouldn't seem to be productive.
In message <Pine.LNX.4.44.0309111134070.10628-100000@netcore.fi>, Pekka Sav
On Fri, 12 Sep 2003, Curtis Villamizar wrote: ola
writes:
In message <Pine.LNX.4.44.0309101200110.30657-100000@netcore.fi>, Pekka Sav
On Wed, 10 Sep 2003, Curtis Villamizar wrote: ola
writes: [...]
However, there seem to be a number of (more or less) textual inaccura cies
and confusion in the document, which should be settled prior to publication.
I think there are the three most important issues here are:
* issue 2) -- how to co-exist from RPSL: if RPSL and RPSL give you conflicting information about IPv4 unicast, then what?
Not an issue. If only IPv4 policy is specified by a given statement, then either the old form or the new form can be used. Currently multiple import, export, and default statements can appear. Their effects are additive. The effect of adding mp-* statements specifying ipv4 using the longer syntax is the same as adding more of the existing import, export, and default statements.
I'm not sure if I see it as the same. The user running RPSL tool must check both the traditional and RPSLng entries. This is a change. More likely than not, depending on the transition/co-existence plan, he will also have to maintain records on both old and new. This is bound to caus e inconsistencies in the data.
The transition is quite easy. The change adds mp-* but does not depricate (ever) the use of the non mp- forms. Just keep all the IPv4 unicast policy in the old form until conversion is considered complete. If it is never certain that conversion is complete, keep the IPv4 unicast in the old form indefinitely.
"until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
Any AS object that provides policy already has many import and export statements. Today IPv4 and IPv6 policy does not match so different statements are needed anyway. For example, AS3561 has 737 import statements and 738 export statements. I would venture to guess their IPv6 policy is a lot simpler.
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details..
I had a lot to do with IPv4 deployment (NSFNET 1992-1995, ANS and UUNET 1995-1998) and I had a lot to do with definition of RPSL and use of RPSL. Considering how long widespread IPv6 deployment has been "coming RSN" the IPv6 world has got nowhere by comparison. I suggest you get off your soapbox and stick with concrete comments and suggestions.
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well.
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
Being used by a few people and being used as widely as RPSL is used today are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago.
Larry could probably give you the lineage of this work better than I could. I think David Kessens was working on expressing IPv6 policy in RPSL as far back as 1997 or so.
Right.. but it has gotten nowhere in about five years if so.
RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savola w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst. As an aside, my guess is that we'll have older RPSL tools around for anywhere from 2-5 years or until IPv4 only networks become rare (which is likely to be longer the way things are going).
Its deployed so obviously it works. We're not talking about something no one has ever tried. This is documenting a set of extensions that are in use.
Being used by a few people and being used as widely as RPSL is used today
are two different things. It is obviously not being used widely if RIPE just got it's test version of the database and the tools out a month or something like that ago.
Larry could probably give you the lineage of this work better than I could. I think David Kessens was working on expressing IPv6 policy in RPSL as far back as 1997 or so.
Right.. but it has gotten nowhere in about five years if so.
The document you are reviewing is the result of the work expressing policy for IPv6, so it hasn't gone nowhere. I'm not sure whether David was working more with the IPv6 inetnum records used for address registry or policy back then.
RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable.
A lot of RPSL use is explicitly to express routing policy. While RIPE is a major user of RPSL and one of the major contributors to RPSL, their use of it is limited in this way.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Curtis
On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savola w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst.
I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think,
RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me that any statements of its wide use are quite questionable.
A lot of RPSL use is explicitly to express routing policy. While RIPE is a major user of RPSL and one of the major contributors to RPSL, their use of it is limited in this way.
Exactly. Operators in the RIPE region have, for some time now, expressed a need for a database supporting expressing IPv6 routing policies (more than anything else!). It only recently got announced (as a test version, I recall). Which seems to strongly say that the RPSLng use has been minimal at best, and there has been no real deployment. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309162130570.24960-100000@netcore.fi>, Pekka Savola writes:
On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savo la w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst.
I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think,
As far as I can tell you have made no point which has withstood strutiny. If you think there is a problem, please state the problem concisely.
RIPE uses its database mostly as a Internet address and AS registry. That you can express policy in RPSL for RIPE is just an added benefit for their customers. RIPE has had IPv6 inetnum records for a very long time for the purpose of address registry.
This is irrelevant: the fact stands that at least in the RIPE region (I don't know much of the others, but I guess the situation is pretty much the same), RPSLng has *not* been deployed at all. So, it seems to me tha t any statements of its wide use are quite questionable.
A lot of RPSL use is explicitly to express routing policy. While RIPE is a major user of RPSL and one of the major contributors to RPSL, their use of it is limited in this way.
Exactly. Operators in the RIPE region have, for some time now, expressed a need for a database supporting expressing IPv6 routing policies (more than anything else!). It only recently got announced (as a test version, I recall). Which seems to strongly say that the RPSLng use has been minimal at best, and there has been no real deployment.
Long before RPSL itself showed up on RIPE at all it was used in production by some major ISPs. For example, the server at rpsl.ra.net was used as production by some ISP while they also populated the server that returned queries as whois.ra.net. It was over a year after RPSL was in production use that RIPE officially supported it. Might even have been two years lag. That RIPE is not going to risk disrupting their IPv4 business for IPv6 needs is not surprising. I'm not in operations anymore so I don't know the extent to which RPSLng is used.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Curtis
On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309162130570.24960-100000@netcore.fi>, Pekka Savola writes:
On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savo la w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to be different anyway. I believe I gave a couple of points to consider as well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst.
I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think,
As far as I can tell you have made no point which has withstood strutiny. If you think there is a problem, please state the problem concisely.
I'll just cut-n-paste my earlier response below. There are certainly open issues on keeping IPv4 unicast and multicast data in sync. Further, it might be desirable to have IPv4 unicast in the same database, so that you could just run the IRRToolSet (or some other tool) just once, from one database to get both v4 and v6 data, but this is a smaller point. ====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right? But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach. As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features. Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only. But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure. Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng! We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. ===== -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309181408040.17750-100000@netcore.fi>, Pekka Savola writes:
In message <Pine.LNX.4.44.0309162130570.24960-100000@netcore.fi>, Pekka Sav
On Tue, 16 Sep 2003, Curtis Villamizar wrote: ola
writes:
On Tue, 16 Sep 2003, Curtis Villamizar wrote:
In message <Pine.LNX.4.44.0309160816080.5651-100000@netcore.fi>, Pekka Savo la w rites:
Did you even read what I wrote? I certainly didn't see a problem in having different IPv6 and IPv4 records, because, well, they have to b
e
different anyway. I believe I gave a couple of points to consider as
well.
If you have no issue with separate IPv6 and IPv4 records then the matter is resolved. There is no transition problem, nor is there any long term problem other than separate IPv6 and IPv4 records which may be a nuisance later at worst.
I recall that RPSLng also supports ipv4.unicast (which is supported by RPSL as well), and ipv4.multicast. The issue is clearly not settled by that, I think,
As far as I can tell you have made no point which has withstood strutiny. If you think there is a problem, please state the problem concisely.
I'll just cut-n-paste my earlier response below. There are certainly open issues on keeping IPv4 unicast and multicast data in sync. Further, it might be desirable to have IPv4 unicast in the same database, so that you could just run the IRRToolSet (or some other tool) just once, from one database to get both v4 and v6 data, but this is a smaller point.
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database. For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements. Since policy is currently quite different between unicase and multicase and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience. At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be gone because they would all need that syntax to support IPv6. So none of your objections below are valid. Curtis
====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. =====
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps
On Thu, 18 Sep 2003, Curtis Villamizar wrote:
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues.
For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements.
Right.
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same. Ours (and many others') policies are identical.
and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience.
A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful.
At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be> gone because they would all need that syntax to support IPv6.
These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng?
====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. =====
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In message <Pine.LNX.4.44.0309191015080.29158-100000@netcore.fi>, Pekka Savola writes:
On Thu, 18 Sep 2003, Curtis Villamizar wrote:
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues.
For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements.
Right.
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same.
Ours (and many others') policies are identical.
I seriously doubt this is common unless you have a small number of peers. The majority of providers support IPv4 unicast only so policy for multicast or IPv6 is meaningless. Regardless, for a transition period you have duplicate entries if the policies were identical. One entry would be in import (for IPv4) the other would be otherwise identical mp-import for ipv6,ipv4-multicast,ipv6-multicast. If the server side can recognize older clients, then the inconvenience of duplicate entries can be elimitated. See paragraph below.
and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience.
A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful.
They are similar formats.
At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be> gone because they would all need that syntax to support IPv6.
These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng?
It was just considered above. I thought that was obvious enough since this is similar to past transitions and I understand how the mp-* were intended to be used. If you want something in the spec on transition, a paragraph or two from this email message can be added. I don't think its needed but it wouldn't hurt. Curtis
====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPS L data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. =====
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
_______________________________________________ Rps mailing list Rps@ietf.org https://www1.ietf.org/mailman/listinfo/rps
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Fri, 19 Sep 2003, Curtis Villamizar wrote:
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same.
Ours (and many others') policies are identical.
I seriously doubt this is common unless you have a small number of peers. The majority of providers support IPv4 unicast only so policy for multicast or IPv6 is meaningless.
You fail to see that *we* set up the policies common to everyone we peer with; we advertise both BGP unicast and multicast routes to everybody equally. Almost nobody uses them, though, but that's not *our* problem. We just wnt to have an equal policy for everyone. [...]
and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience.
A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful.
They are similar formats.
That's good. Taking an example with IRRToolSet, I want to embed both RPSL and RPSLng format attributes or commands in a single text document, which I will pass through IRRToolSet _once_. (e.g., requiring to run the tool twice, once for each support with different command-line arguments is unreasonable.)
At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be> gone because they would all need that syntax to support IPv6.
These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng?
It was just considered above. I thought that was obvious enough since this is similar to past transitions and I understand how the mp-* were intended to be used. If you want something in the spec on transition, a paragraph or two from this email message can be added. I don't think its needed but it wouldn't hurt.
Well, I can see multiple possible ways to do so -- so this the way forward does seem to use a bit of phrasing. Something added to an appendix would likely be very useful. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Pekka Savola wrote:
On Fri, 19 Sep 2003, Curtis Villamizar wrote:
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same.
Ours (and many others') policies are identical.
I seriously doubt this is common unless you have a small number of peers. The majority of providers support IPv4 unicast only so policy for multicast or IPv6 is meaningless.
You fail to see that *we* set up the policies common to everyone we peer with; we advertise both BGP unicast and multicast routes to everybody equally. Almost nobody uses them, though, but that's not *our* problem. We just wnt to have an equal policy for everyone.
Just in case anything thinks Pekka is alone in doing that I also consider the protocol irrelevant in my policy. Whether the peer wants all of them is another matter totally unrelated to specifying my policy.
That's good. Taking an example with IRRToolSet, I want to embed both RPSL and RPSLng format attributes or commands in a single text document, which I will pass through IRRToolSet _once_. (e.g., requiring to run the tool twice, once for each support with different command-line arguments is unreasonable.)
Personally I would prefer it if RPSLng was a super set of RPSL and from my point of view RPSLng policy = RPSL policy would be really nice. I still fail to see why we need most of the mp-* stuff anyway. Mark.
In message <3F6E3574.1040300@mrp.net>, Mark Prior writes:
Personally I would prefer it if RPSLng was a super set of RPSL and from my point of view RPSLng policy = RPSL policy would be really nice. I still fail to see why we need most of the mp-* stuff anyway.
Mark.
Mark, How is RPSLng not a superset of RPSL? Nothing has been removed from RPSL. 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. Curtis
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.
In message <3F6F85FE.1020302@mrp.net>, Mark Prior writes:
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?
The default right now for the non mp-* import, export, etc is to assume ipv4-unicast. Maybe what you want is adding the option to the existing non mp-* syntax to specify other protocol. What might be better is to keep the idea of mp-* but make the default protocol ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we need an ipv4-all and ipv6-all. The ip-all or ip-everything would be shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, which is a lot to type. If a lot of providers have common policy then omitting any protocol spec could default to ip-everything.
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.
Having written plenty of small compilers I can understand why implementors would prefer to keep things simple for them. For something like an mp-import if you specify ip-everything (may that is needed) then you can mix ipv4 and ipv6 addresses and the code should figure it out. If you submit an autnum with import it would imply ipv4-unicast. If you submit an sutnum (could be the same autnum) with mp-import but no protocol specified it would be ip-everything. Does that sound like an improvement to you? My reasoning for keeping mp-* is that for import you'd want the lack of newly attributes to mean what they meant in objects submitted a long time ago (for example ipv4-unicast only), but with a new mp-import defaults can be whatever case is thought to be most common. For other objects this seems to make sense too. For mp-peer, a default of ip-everything makes sense, keeping peer to mean ipv4-unicast.
Mark.
I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it. Curtis
Curtis Villamizar wrote:
Having written plenty of small compilers I can understand why implementors would prefer to keep things simple for them.
One group writes one compiler once, many clients use that compiler, many times. I know which group I would prefer to make life easier for :-) Mark.
Curtis Villamizar wrote:
The default right now for the non mp-* import, export, etc is to assume ipv4-unicast. Maybe what you want is adding the option to the existing non mp-* syntax to specify other protocol. What might be better is to keep the idea of mp-* but make the default protocol ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we need an ipv4-all and ipv6-all. The ip-all or ip-everything would be shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, which is a lot to type. If a lot of providers have common policy then omitting any protocol spec could default to ip-everything.
I would prefer that the meaning be taken from the context of its use. If your policy is the same, irrespective of protocol, then a single import statement is sufficent and from a policy statement point of view it probably doesn't matter if it is read as ipv4 unicast or ip anything or ... It is the application of the policy statement where the intent is important and one would hope the user knows what they are doing. This would mean that the syntax of the tool using the policy might now say use the import/export policy relating to this AS number but I only need unicast IPv4 here so just get me the appropriate bits. If you do actually have different policy for different protocols then you probably want an additional mechanism that specifies that the policy fragment only applies to that protocol. In this case you could add the appropriate protocol modifier to the statement. I would expect that this is the exception rather than the rule in real life.
For something like an mp-import if you specify ip-everything (may that is needed) then you can mix ipv4 and ipv6 addresses and the code should figure it out. If you submit an autnum with import it would imply ipv4-unicast. If you submit an sutnum (could be the same autnum) with mp-import but no protocol specified it would be ip-everything. Does that sound like an improvement to you?
I don't see the point of the mp-import. I would see import implying ip everything. I would think it is rare for anyone to use someone else's autnum, or in fact rely on anyone else's sets, so I don't see the danger of using an old RPSL only tool with RPSLng data. Mark.
In message <3F6FB8BC.5000506@mrp.net>, Mark Prior writes:
Curtis Villamizar wrote:
The default right now for the non mp-* import, export, etc is to assume ipv4-unicast. Maybe what you want is adding the option to the existing non mp-* syntax to specify other protocol. What might be better is to keep the idea of mp-* but make the default protocol ip-everything ({ipv4,ipv6}-{uni,multi}cast). At the very least we need an ipv4-all and ipv6-all. The ip-all or ip-everything would be shorthand for ipv4-unicast,ipv6-unicast,ipv4-multicast,ipv6-multicast, which is a lot to type. If a lot of providers have common policy then omitting any protocol spec could default to ip-everything.
I would prefer that the meaning be taken from the context of its use. If your policy is the same, irrespective of protocol, then a single import statement is sufficent and from a policy statement point of view it probably doesn't matter if it is read as ipv4 unicast or ip anything or ... It is the application of the policy statement where the intent is important and one would hope the user knows what they are doing. This would mean that the syntax of the tool using the policy might now say use the import/export policy relating to this AS number but I only need unicast IPv4 here so just get me the appropriate bits.
If you do actually have different policy for different protocols then you probably want an additional mechanism that specifies that the policy fragment only applies to that protocol. In this case you could add the appropriate protocol modifier to the statement. I would expect that this is the exception rather than the rule in real life.
For something like an mp-import if you specify ip-everything (may that is needed) then you can mix ipv4 and ipv6 addresses and the code should figure it out. If you submit an autnum with import it would imply ipv4-unicast. If you submit an sutnum (could be the same autnum) with mp-import but no protocol specified it would be ip-everything. Does that sound like an improvement to you?
I don't see the point of the mp-import. I would see import implying ip everything. I would think it is rare for anyone to use someone else's autnum, or in fact rely on anyone else's sets, so I don't see the danger of using an old RPSL only tool with RPSLng data.
Mark.
Mark, You might be right about no one using other peoples autnum and if they are using it for some sort of analysis, they are probably sophisticated enough users to keep their tool collection up to date. Curtis
Curtis Villamizar wrote:
You might be right about no one using other peoples autnum and if they are using it for some sort of analysis, they are probably sophisticated enough users to keep their tool collection up to date.
The typical problem I found was that not all peers had the objects I wanted (AS sets) and so I had to build them anyway. No great drama for me since I had my own server to populate anyway but I did end up with quite a few stub autnum objects so the hierarchical authentication for the as sets would work :-) Mark.
On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: [...]
I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it.
The whois "protocol" does not allow the server to know if the client is RPSL-only or not. Changing the protocol to accomplish it is I think out of scope. CRISP will be the solution to this problem. -engin
Curtis
-- Engin Gunduz RIPE NCC Database Group
In message <20030923210804.GA4850@cow.ripe.net>, Engin Gunduz writes:
On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: [...]
I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it.
The whois "protocol" does not allow the server to know if the client is RPSL-only or not. Changing the protocol to accomplish it is I think out of scope. CRISP will be the solution to this problem. -engin
Curtis
-- Engin Gunduz RIPE NCC Database Group
Something like RtConfig could use a newer protocol. A common trick for the whois program has been to include flags in the whois query: whois -h rpslng.ripe.net " --use-rpsl-ng as3561" Tools such as RtConfig are better served by other protocols. It is the older tools that are perl programs or shell scripts built on top of whois, either calling the whois executable or connecting to port 43. For those you can use the trick above or something similar. In the absense of the --use-rpsl-ng only ipv4 policy would be returned, translating mp-* objects at the server on behalf of the client. Make sense? Curtis
Engin Gunduz wrote:
On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote: [...]
I'm waiting to hear if implementors think that returning an import in place of an mp-import (etc) to an RPSL-only client will be difficult or whether it doesn't sound so hard after thinking about it.
The whois "protocol" does not allow the server to know if the client is RPSL-only or not. Changing the protocol to accomplish it is I think out of scope. CRISP will be the solution to this problem.
This is true but at least one of the whois servers used for RPSL already has a mechansim to keep the session open for multiple queries and that isn't in the standard either. Expanding on that you could say that if the text string query (which is all the actual standard allows for) contains some particular token then a server will hold the session open and negotiate options with the client. This behaviour would allow a server to support RPSL, RPSLng, ... concurrently if it wished. Mark. PS I do wonder if the IESG really want to be cc'ed on these messages but I guess they wouldn't be shy in telling us to stop :-)
In message <Pine.LNX.4.44.0309211712130.7588-100000@netcore.fi>, Pekka Savola w rites:
On Fri, 19 Sep 2003, Curtis Villamizar wrote:
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same.
Ours (and many others') policies are identical.
I seriously doubt this is common unless you have a small number of peers. The majority of providers support IPv4 unicast only so policy for multicast or IPv6 is meaningless.
You fail to see that *we* set up the policies common to everyone we peer with; we advertise both BGP unicast and multicast routes to everybody equally. Almost nobody uses them, though, but that's not *our* problem. We just wnt to have an equal policy for everyone.
[...]
and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience.
A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful.
They are similar formats.
That's good. Taking an example with IRRToolSet, I want to embed both RPSL and RPSLng format attributes or commands in a single text document, which I will pass through IRRToolSet _once_. (e.g., requiring to run the tool twice, once for each support with different command-line arguments is unreasonable.)
RPSLng is a superset of RPSL. After some **testing** of the RPSLng server code, the entire database will be RPSLng. The only issue will be whether RPSL only query clients will be accommodated by 1) extracting the non mp-* RPSL from any RPSLng entries that match the queries (by the server code) or 2) non mp-* RPSL will be generated for the IPv4 part of the mp-* entries when entered into the database, or 3) whether end users will have to submit non mp-* for ipv4-unicast. The point it that there are multiple ways to accommodate older client code during transition. Which method of transition to pick is something more appropriate for a RIPE meeting, not for the language spec.
At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expresse d as mp-* entries. At some time, probably even later, it is expected tha t older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be> gone because they would all need that syntax to support IPv6.
These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone ) on what's the overall plan for deploying RPSL and RPSLng?
It was just considered above. I thought that was obvious enough since this is similar to past transitions and I understand how the mp-* were intended to be used. If you want something in the spec on transition, a paragraph or two from this email message can be added. I don't think its needed but it wouldn't hurt.
Well, I can see multiple possible ways to do so -- so this the way forward does seem to use a bit of phrasing.
Something added to an appendix would likely be very useful.
Good. The comment above about 3 ways to do the transition might also help. The draft authors should feel free to reword any of this as they see fit.
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Curtis
Pekka and Curtis, Thanks for the feedback. Sorry for not responding sooner (I've been trying to absorb everything and formulate a response). I've been updating the draft to reflect many of your comments (thanks, Pekka). On Fri, 2003-09-19 at 03:21, Pekka Savola wrote:
On Thu, 18 Sep 2003, Curtis Villamizar wrote:
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues.
I think there indeed needs to be some text to clarify the use of mp-* and non mp-* entries. Should the document recommend the use of non-mp entries to express v4 policies for existing non-RPSLng compliant tools? Should this be mandatory or optional? And perhaps more controversily, if there are mp- attributes present in an object, should the non-mp attributes be ignored by RPSLng compliant tools to reduce the possibility for conflicts. Further should there be clarification on the case where an import, export, or default attribute references a route-set/filter-set/etc. which contains mp- attributes? Should RPSLng compliant tools ignore the mp- attributes in this case (as non-RPSLng compliant tools would do).
For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements.
Right.
One option I thought about would be to change the mp-members, mp-filter, mp-peer, mp-peering, and interface attributes to be IPv6 specific. In other words, rename them to something like members6, filter6, peer6, peering6, and interface6 (well, perhaps not the interface attribute since it introduces new functionality). This would preserve explicit support for backward compatibility with IPv4 as one would need to continue to express IPv4 prefixes and policy info in the existing RPSL attributes. I think backward compatibility in these attributes is more important than the import, export, and default attributes as I believe one is more likely to reference another org's route-set, filter-set, etc., than another org's aut-num object. -Larry Blunk Merit
Since policy is currently quite different between unicase and multicase
A fatal assumption. In about all academic networks and backbone transit providers -- which are significant users of RPSLng -- multicast and unicast topologies are very much the same.
Ours (and many others') policies are identical.
and ipv4 and ipv6 this is not only not a problem, it is not even an inconvenience.
A smaller issues, yes. However, from "the use of tools" perspective, people will use both IPv4 and IPv6, and similar formats would be useful.
At some later time the server software may be able to recognize older client code and return non- mp-* entries converted from policy expressed as mp-* entries. At some time, probably even later, it is expected that older clients will disappear. At some point it may no longer be practical to run an IPv4 only network and/or run a unicast only network (though this seems not to be "on the horizon" at the moment) and then all clients which did not understand the mp-* syntax would be> gone because they would all need that syntax to support IPv6.
These are the issues I think will need *explicit* consideration before going down the path of happily adopting RPSLng. What if there are some holes in the spec or how it is implemented, or a clear view (for everyone) on what's the overall plan for deploying RPSL and RPSLng?
====== "until conversion is considered complete". Do you think this takes a year, two, or ten years? Note that for the conversion to be complete, *EVERY* user or RPSL must have upgraded to RPSLng, right?
But then again, you're advocating keeping the v4 unicast policy only in the old form RPSL. Now, many sites want to mention their multicast policies as well, or IPv6 policies. They have to maintain two different databases and records to do this, using this transition approach.
As for another approach, what might help a bit could be to have the ability of the RPSLng databases to automatically generate the old form RPSL data from the IPv4 unicast data which has possibly been entered in the RPSLng registry, for maintaining the automatic backward compatibility and minimizing the maintenance effort of all ISPs desiring to use the RPSLng features.
Another approach might be to general IPv4.unicast data to RPSLng from RPSL data, so that everyone could start "safely" to use RPSLng only.
But there are some potential "overlapping policy in RPSL or RPSLng" issue here, not sure.
Or, there could be some other approaches, I don't know. These might not even require modifications (at least major ones) in the RPSLng spec. But this seems like a subject which is non-trivial and bears some thinking about... *before* we set off to really deploying RPSLng!
We've been learning that lesson with the IPv6 transition work. Folks probably thought it would be trivial, at first, and didn't pay attention to the operational details.. =====
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Larry, Good to hear from you. Comments inline. I think we can converge on something that we can all live with by just adding a transition issue appendix and deciding what needs to go into it. Curtis In message <1063981473.3370.23.camel@ablate.merit.edu>, "Larry J. Blunk" writes :
Pekka and Curtis, Thanks for the feedback. Sorry for not responding sooner (I've been trying to absorb everything and formulate a response). I've been updating the draft to reflect many of your comments (thanks, Pekka).
On Fri, 2003-09-19 at 03:21, Pekka Savola wrote:
On Thu, 18 Sep 2003, Curtis Villamizar wrote:
You seem not to be missing something. The mp-* and non- mp-* entries will be in the same database.
Probably yes, in the longer term; that helps some scenarios but doesn't eliminate the issues.
I think there indeed needs to be some text to clarify the use of mp-* and non mp-* entries. Should the document recommend the use of non-mp entries to express v4 policies for existing non-RPSLng compliant tools? Should this be mandatory or optional? And perhaps more controversily, if there are mp- attributes present in an object, should the non-mp attributes be ignored by RPSLng compliant tools to reduce the possibility for conflicts.
This is strictly a transition issue and a strong recommendation to specify non mp-* for IPv4 should be made for initial transition purposes. See comments below about eliminating this need with better server code. Any such recommendation should be in an appendix on transition issues, not in the main body of the document.
Further should there be clarification on the case where an import, export, or default attribute references a route-set/filter-set/etc. which contains mp- attributes? Should RPSLng compliant tools ignore the mp- attributes in this case (as non-RPSLng compliant tools would do).
For backwards compatibility the ipv4 unicast policy will be in the same database but at least initially expressed as non- mp-* policy statements.
Right.
One option I thought about would be to change the mp-members, mp-filter, mp-peer, mp-peering, and interface attributes to be IPv6 specific. In other words, rename them to something like members6, filter6, peer6, peering6, and interface6 (well, perhaps not the interface attribute since it introduces new functionality). This would preserve explicit support for backward compatibility with IPv4 as one would need to continue to express IPv4 prefixes and policy info in the existing RPSL attributes.
I think backward compatibility in these attributes is more important than the import, export, and default attributes as I believe one is more likely to reference another org's route-set, filter-set, etc., than another org's aut-num object.
-Larry Blunk Merit
It would be best if old clients could be recognized. This would mean conversion to new server code only before mp-* could be freely used. At that point when an old client is recognized all mp-* attributes can be returned with s/mp-// as long as they apply to IPv4. With the server code hiding the mp- stuff a query that hits an mp-import or import that referenced an mp-filter or filter would alway be returning just a import and filter to the older client. This is not so much an issue for the spec as it is for the implementation and a transition consideration for deployment. It doesn't hurt to mention the issues in the spec, but there is no need to change the spec. There is always a need to make a smooth transition. Rather than change the spec to make mp-peer etc into peer6 etc, leave the spec as is but for early transition only accept a mp-peer if it is specifies a non-IPv4-unicast peering. When the server code is updated in enough places you can accept a mp-peer that specifies ipv4 but return a plain peering to older clients.
I've attached the latest draft of the RPSLng spec. I've left the afi definition section as it was previously as I don't think there was consensus to change the meaning of ipv4 and ipv6 to include both unicast and multicast. Please let me know if there are any strong feelings about this. One option could be to add ipv4.any and ipv6.any types as a shorthand for ipv4.unicast,ipv4.multicast and ipv6.unicast,ipv6.multicast. However, I'm not sure if this doesn't actually make things worse by creating more clutter in the spec. I've reduced the encapsulation types for the tunnel option in the interface: attribute to just GRE and IPinIP. IPinIP was deemed sufficient since you already know the address types of the encapsulating end-points. DVMRP was dropped since the protocol/encapsulation method seems to be deprecated at this point. Should we add other encapsulation methods to this attribute? For example, LT2P, PPTP, or IPSec? Would it be useful to have an afi specification to indentify/restrict the address family types carried across the tunnel? -Larry Blunk Merit
Curtis Villamizar wrote:
Any AS object that provides policy already has many import and export statements. Today IPv4 and IPv6 policy does not match so different statements are needed anyway. For example, AS3561 has 737 import statements and 738 export statements. I would venture to guess their IPv6 policy is a lot simpler.
My high level policy (ignoring encoding it in some language) is likely to be the same irrespective of whether it is IPv4 or IPv6. My _application_ of that policy to a peer may be different, ie if the peer doesn't speak IPv4 there would be no need to include any IPv4 components. Mark.
Curtis Villamizar wrote:
Larry Blunk is the current primary developer/maintainer, having taken over from the original author, Cengiz Alaettinoglu. The IPv6 syntax has evolved and is now in use. One of the reasons this document has seen so little comment is it describes something people have been using for quite some time and it works.
I don't know if that is true. I just lost interest in continuing to complain about the clunky syntax. Mark.
In message <3F607F6D.90209@mrp.net>, Mark Prior writes:
Curtis Villamizar wrote:
Larry Blunk is the current primary developer/maintainer, having taken over from the original author, Cengiz Alaettinoglu. The IPv6 syntax has evolved and is now in use. One of the reasons this document has seen so little comment is it describes something people have been using for quite some time and it works.
I don't know if that is true. I just lost interest in continuing to complain about the clunky syntax.
Mark.
Mark, Why don't you try it one more time. I don't remember seeing anything on the RPS mailing list in a long time so you must have given up quite some time ago or not copied the RPS mailing list. It would be best if you gave specific syntax changes you'd like to see and why, plus how to transition to the new syntax. Curtis
Curtis Villamizar wrote:
Why don't you try it one more time. I don't remember seeing anything on the RPS mailing list in a long time so you must have given up quite some time ago or not copied the RPS mailing list.
I was probably just using the rpslng list.
It would be best if you gave specific syntax changes you'd like to see and why, plus how to transition to the new syntax.
My argument has always been about making is easier for the poor user and pushing the complexity to the software. This meant I wanted most of the syntax to remain the same, with optional phrases for the MP bits and certainly not grow "MP" variants of import, export, etc. Also I believed that the software could work out from its context if it wanted a IPv4 address or a IPv6 one and so there only needed to be one route object. The complaints about this approach seemed to revolve around backward compatability with existing software and my approach to that was to get newer software to perform some handshake with the server to say what it wanted otherwise the server would just return data acceptable to a RPSL client. Mark.
In message <3F62A591.2070405@mrp.net>, Mark Prior writes:
Curtis Villamizar wrote:
Why don't you try it one more time. I don't remember seeing anything on the RPS mailing list in a long time so you must have given up quite some time ago or not copied the RPS mailing list.
I was probably just using the rpslng list.
It would be best if you gave specific syntax changes you'd like to see and why, plus how to transition to the new syntax.
My argument has always been about making is easier for the poor user and pushing the complexity to the software. This meant I wanted most of the syntax to remain the same, with optional phrases for the MP bits and certainly not grow "MP" variants of import, export, etc. Also I believed that the software could work out from its context if it wanted a IPv4 address or a IPv6 one and so there only needed to be one route object.
The complaints about this approach seemed to revolve around backward compatability with existing software and my approach to that was to get newer software to perform some handshake with the server to say what it wanted otherwise the server would just return data acceptable to a RPSL client.
Mark.
I wasn't part of that discussion, but if you don't mind a last minute comment on this... Transition issues are very important in a RR. You have to assume that old software will be around for quite a long time. Someone is bound to be using old code for a very long time. Curtis
Curtis Villamizar wrote:
Transition issues are very important in a RR. You have to assume that old software will be around for quite a long time. Someone is bound to be using old code for a very long time.
I'm not disputing that. What I am suggesting is that if there was a version number (say) negotiation mechanism then new code could negotiate for support of new features with a server but without this a new server would return old style data (which will avoid the old code barfing). Mark.
In message <3F66EE8E.1060104@mrp.net>, Mark Prior writes:
Curtis Villamizar wrote:
Transition issues are very important in a RR. You have to assume that old software will be around for quite a long time. Someone is bound to be using old code for a very long time.
I'm not disputing that. What I am suggesting is that if there was a version number (say) negotiation mechanism then new code could negotiate for support of new features with a server but without this a new server would return old style data (which will avoid the old code barfing).
Mark.
Since there is no version negotiation, we'd need a new set of queries with version negotiation. The old set could be assumed to be the old versions. The next issue is you'd need a reliable means to translate the new format into the old. This does constrain the syntax somewhat, but would allow ipv4,ipv6 policy to be specified and just the ipv4 part returned to the old query. This boild down to just a "small matter of code". RtConfig is open source. Would you like to contribute the changes? :-) Curtis
Curtis Villamizar wrote:
Since there is no version negotiation, we'd need a new set of queries with version negotiation. The old set could be assumed to be the old versions.
Well the obvious question to ask is why not add it (version negotiation that is). This would require some codification of the exchange between a client and a server but wouldn't this be a good thing anyway?
The next issue is you'd need a reliable means to translate the new format into the old. This does constrain the syntax somewhat, but would allow ipv4,ipv6 policy to be specified and just the ipv4 part returned to the old query.
Ah but would an organisation using an old client write new syntax objects anyway?
This boild down to just a "small matter of code". RtConfig is open source. Would you like to contribute the changes? :-)
Given my lack of C++ skills (combined with my lack of gcc v2 compiler) I'm not sure I would be too helpful in that regard :-) However I guess I would be happy to assist updating RFC 2650. Mark.
In message <3F67049B.2030403@mrp.net>, Mark Prior writes:
Curtis Villamizar wrote:
Since there is no version negotiation, we'd need a new set of queries with version negotiation. The old set could be assumed to be the old versions.
Well the obvious question to ask is why not add it (version negotiation that is). This would require some codification of the exchange between a client and a server but wouldn't this be a good thing anyway?
That's entirely an RtConfig issue but it would make RPSL transitions easier. Handling multiple protocol versions is not trivial though.
The next issue is you'd need a reliable means to translate the new format into the old. This does constrain the syntax somewhat, but would allow ipv4,ipv6 policy to be specified and just the ipv4 part returned to the old query.
Ah but would an organisation using an old client write new syntax objects anyway?
No but they may need to be able to read new objects that others have written to figure out what's going on.
This boild down to just a "small matter of code". RtConfig is open source. Would you like to contribute the changes? :-)
Given my lack of C++ skills (combined with my lack of gcc v2 compiler) I'm not sure I would be too helpful in that regard :-) However I guess I would be happy to assist updating RFC 2650.
I was kidding about writing code for RtConfig, but the point is that keeping specification acheivable has always been an IETF goal. In this case we want to keep in mind the limited staff working on the tools or we end up with nothing that works in a reasonable time.
Mark.
Curtis
Dear colleagues, We'd like to present the view of the RIPE NCC on the discussions on the RPSLng draft. Although it is not explicitly discussed in the draft, the transition issue was thought on. It was decided to use mp-* attributes to ease the transition. That way, the old clients that use the routing registry that supports RPSLng can simply ignore the new attributes and new object classes and continue to work (this is the expected behaviour of clients, RFC2622 sections 10.2 and 10.3). Thus, it is not really necessary to equip the whois server with the capability of detecting if the client is RPSLng capable or not. Perhaps what we need to do is to document these in the draft. At any rate, we think it is useful to change the protocol to allow negotiation of object format, but this is out of scope of RPSLng effort. The relevant effort to change (or, re-design) the protocol is the CRISP effort, please see http://www.ietf.org/html.charters/crisp-charter.html . On the subprotocol issue: IPv4 address family has defaulted to ipv4.unicast generally (in Cisco IOS software, for instance, which is widely used). Therefore the change of the meaning to ipv4.unicast+ipv4.multicast may cause confusion. We have been trying to come up with a solution so that the users of whois database can start using it to publish their IPv6 and multicast policies. The effort started more than a year ago and our users are getting more and more impatient to see a solution. Actually, long ago they started to "document" their IPv6 and multicast policies using alternative methods, please see aut-num: AS12702 as-name: UUNET-EMEA-IPV6 descr: WorldCom EMEA descr: IPv6 only Autonomous System remarks: detailed routingpolicy is documented at remarks: whois.6bone.net due to missing IPv6 support remarks: in the RIPE database: remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-DE remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-FR remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-NL remarks: http://whois.6bone.net/cgi-bin/whois?UUNET-UK admin-c: ABN-RIPE tech-c: ABN-RIPE mnt-by: UUNET-MNT changed: hostmaster@ripe.net 19991004 changed: ehofmann@uu.net 20021122 source: RIPE or aut-num: AS1122 as-name: UNSPECIFIED descr: UK-AS admin-c: UK6107-RIPE tech-c: UK3 import: from AS760 action pref=100; accept ANY export: to AS760 announce AS1122 remarks: ------------------------- remarks: as-in-v6: from AS760 100 accept ANY remarks: as-in-v6: from AS10566 90 accept ANY remarks: ------------------------- remarks: as-out-v6: to AS760 announce AS1122 remarks: as-out-v6: to AS10566 announce AS1122 remarks: ------------------------- mnt-by: UK-MNT mnt-by: AS1853-MNT changed: Erik-Jan.Bos@surfnet.nl 19940314 changed: ripe-dbm@ripe.net 19990701 changed: woeber@cc.univie.ac.at 19990809 changed: woeber@cc.univie.ac.at 19990912 changed: ulrich.kiermayr@univie.ac.at 20020819 source: RIPE or aut-num: AS1938 as-name: FR-RENATER-IRISA descr: Irisa/Inria Rennes remarks: BEGIN IPv4 unicast routing policy import: from AS13019 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS13019 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv4 unicast routing policy remarks: BEGIN IPv4 multicast routing policy import: from AS2200 accept ANY export: to AS2200 announce AS1938 remarks: END IPv4 multicast routing policy remarks: BEGIN IPv6 routing policy import: from AS2200 action pref=1; accept ANY import: from AS20603 action pref=2; accept ANY export: to AS2200 announce AS1938 export: to AS20603 announce AS1938 remarks: END IPv6 routing policy admin-c: GR1378-RIPE admin-c: CL4104-RIPE tech-c: DL169-RIPE tech-c: RT199-RIPE mnt-by: RENATER-MNT changed: rensvp@renater.fr 19991014 changed: er-transfer@ripe.net 20020919 changed: rensvp@renater.fr 20030620 source: RIPE so it seems like it's time come up with a solution and implement it. We think the current draft meets the needs. Best regards, -- RIPE NCC RPSLng Team Katie, Shane & Engin
participants (6)
-
Curtis Villamizar -
Engin Gunduz -
Larry J. Blunk -
Mark Prior -
Pekka Savola -
The IESG