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