[Rps] Re: Last Call: 'RPSLng' to Proposed Standard

In message <Pine.LNX.4.44.0309101200110.30657-100000 at 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.