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

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Sep 2003 13:14:27 +0300 (EEST)

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

_______________________________________________
Rps mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rps

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Sep 2003 13:14:27 +0300 (EEST)

[...]

 

substantial
-----------

                                                                                                       
      ipv4

2.3.2 <mp-filter>

and:

4.5 inet-rtr Class

                                                                                                       
   aut-num: AS2

 
 3. New route6 Class

and:

editorial
---------

                                 RPSLng

Abstract

                                                                                                       

                                                                                                       

 

   mp-import ::=

==> spell out IRR.

In the aut-num class,

==> s/They/The/.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 10 Sep 2003 20:33:25 -0400

In message <[email-masked]>, Pekka Savola 
> pretty good, and a very relevant piece of work; it's needed by IPv6 ops 

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.

> 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 

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.

> attributes are modified in a similar fashion" (or something to that 

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

This document extends RFC-1622.  If it updated RFC-1622 it would mean
that it represents a change to all usage of RFC-1622.

> be useful on how to effectively transition/co-exist with both RPSL and

See prior note.  Not an issue.

> implication?  Or should there be a separate value which would imply the

Yes this is intended.  See prior note.

>    <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.

>    this attribute and the "peer:" attribute is the inclusion of support

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.

>    latter case an error is returned. {NOT ANY} <mp-filter> may issue a

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.

>    the mp-filter should be evaluated as {NOT ANY}.

And according to the above text a warning may be issued.

> 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.

 3. New route6 Class
> (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.

> leaving the values undefined and to be intuitively filled in by the

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>.

> 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).

> redundant to me; but if that's the path, also include IPv6inIPv6 and

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.

> this document, I guess :-)

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 10 Sep 2003 20:33:25 -0400

...

 3. New route6 Class

Regards,

Curtis

---

From: Mark Prior <[email-masked]>
Date: Thu, 11 Sep 2003 23:28:05 +0930

> 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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Sep 2003 11:53:54 +0300 (EEST)

Inline..

[...]
> 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.
 
> more afi values", showing where <afi-list> is used and multiple

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".
 
> additions defined here and no definitions that are not being changed

I'm not sure if all those modifications are completely straightfoward.

> 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.

> See prior note.  Not an issue.

Not so sure on that.

> 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.

> numerous examples are given, the syntax is not spelled out.

Yep.
 
> 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.
 
> need not be repeated in the new draft with the trivial substitution.

Not the whole definition, maybe.
 
> but could stand a little rewording.

Fine with me.
 
> exact syntax is defined elsewhere.

right.
 
> except that a <ipv6-address-prefix> is used in place of a

maybe
 
> there really is no use for DVMRP (ie: when the experiment is declared

It seems irrelevant in this context, and potentially even harmful
(building public interdomain DVMRP tunnels is not one of the brightest
notions..).
 
> 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

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]

---

From: Mark Prior <[email-masked]>
Date: Thu, 11 Sep 2003 23:28:05 +0930

Mark.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 11 Sep 2003 11:53:54 +0300 (EEST)

Inline..

[...]

 

Not so sure on that.

Yep.

 

Fine with me.

right.

maybe

 

Right.

[snip to the end]

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 12 Sep 2003 13:23:21 -0400

In message <[email-masked]>, Pekka Savola 
> 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.

> 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.

> 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

Oops.  Yeah.

> 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.

> > See prior note.  Not an issue.

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.

> seem more obvious that "ipv6" should refer to both unicast and multicast, 

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.

> > numerous examples are given, the syntax is not spelled out.

... Larry - it looks like you have an edit to make.

> 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.

> Not the whole definition, maybe.

That is the definition and it need not be repeated with the
substitution.

> > exact syntax is defined elsewhere.

... Larry - same edit - some details here.

> > except that a <ipv6-address-prefix> is used in place of a

... Larry - looks to me like a second edit.

> (building public interdomain DVMRP tunnels is not one of the brightest

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.

> That's the case today; our IPv6 multicast infra uses v6-over-v6 tunnels

OK.  Then its needed.

... Larry - add one to the enumeration.

> that are really needed now, and in the future?  Doesn't seem like a good 

Fine.  If you think its needed.

... Larry - another entry.

> already yield that information!

You are smarter than Larry's parser.  It needs the help.

> [snip to the end]

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.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 12 Sep 2003 13:23:21 -0400

Oops.  Yeah.

OK.  Then its needed.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 12 Sep 2003 13:27:45 -0400

> complain about the clunky syntax.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 12 Sep 2003 13:27:45 -0400

Mark,

Curtis

---

From: Mark Prior <[email-masked]>
Date: Sat, 13 Sep 2003 14:35:21 +0930

> some time ago or not copied the RPS mailing list.
I was probably just using the rpslng list.

> 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.

---

From: Mark Prior <[email-masked]>
Date: Sat, 13 Sep 2003 14:35:21 +0930

Mark.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Sep 2003 11:00:22 +0300 (EEST)

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.

> 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..

> 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").

> apply to IPv6 static routes.

But still, it changes the rp-attribute.

> no one has ever tried.  This is documenting a set of extensions that

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.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 15 Sep 2003 11:00:22 +0300 (EEST)

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 15 Sep 2003 15:30:56 -0400

In message <[email-masked]>, Pekka Savola 
writes:
> > > > In message <[email-masked]>, Pekka
>  Sav
> > > ola 
> > > > writes:
> > > [...]

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.

> 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.

> just got it's test version of the database and the tools out a month or 

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.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 15 Sep 2003 15:31:25 -0400

> wanted otherwise the server would just return data acceptable to a RPSL 

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 15 Sep 2003 15:31:25 -0400

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 15 Sep 2003 15:30:56 -0400

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Sep 2003 08:19:49 +0300 (EEST)

> you get off your soapbox and stick with concrete comments and

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.

> RPSL as far back as 1997 or so.

Right.. but it has gotten nowhere in about five years if so.
 
> 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.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Sep 2003 08:19:49 +0300 (EEST)

---

From: Mark Prior <[email-masked]>
Date: Tue, 16 Sep 2003 20:35:50 +0930

> 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.

---

From: Mark Prior <[email-masked]>
Date: Tue, 16 Sep 2003 20:35:50 +0930

Mark.

---

From: Mark Prior <[email-masked]>
Date: Tue, 16 Sep 2003 20:39:43 +0930

> 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.

---

From: Mark Prior <[email-masked]>
Date: Tue, 16 Sep 2003 20:39:43 +0930

Mark.

---

From: Mark Prior <[email-masked]>
Date: Tue, 16 Sep 2003 22:09:55 +0930

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.

---

From: Mark Prior <[email-masked]>
Date: Tue, 16 Sep 2003 22:09:55 +0930

Mark.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 07:46:52 -0400

In message <[email-masked]>, Pekka Savola w
> different anyway.  I believe I gave a couple of points to consider as 

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).

> 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.

> 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.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 07:46:52 -0400

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 07:53:30 -0400

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 07:53:30 -0400

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Sep 2003 21:34:37 +0300 (EEST)

> 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,
 
> 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.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 16 Sep 2003 21:34:37 +0300 (EEST)

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 16:09:36 -0400

> 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.

> Ah but would an organisation using an old client write new syntax 

No but they may need to be able to read new objects that others have
written to figure out what's going on.

> 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.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 16:09:36 -0400

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 16:36:33 -0400

In message <[email-masked]>, Pekka Savola 
> RPSL as well), and ipv4.multicast.  The issue is clearly not settled by 

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.

> 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.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 16 Sep 2003 16:36:33 -0400

Curtis

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Sep 2003 14:11:24 +0300 (EEST)

> strutiny.  If you think there is a problem, please state the problem

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.

======

=====

---

From: Pekka Savola <[email-masked]>
Date: Thu, 18 Sep 2003 14:11:24 +0300 (EEST)

======

---

From: "Larry J. Blunk" <[email-masked]>
Date: 19 Sep 2003 10:24:33 -0400

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?
> 
> > > ======

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Sep 2003 10:21:58 +0300 (EEST)

Right.

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 18 Sep 2003 14:18:30 -0400

In message <[email-masked]>, Pekka Savola 
writes:
> > > > In message <[email-masked]>, Pekka 
> Savo
> > > la w
> > > > rites:
> > > > > 

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

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 19 Sep 2003 09:24:33 -0400

In message <[email-masked]>, Pekka Savola 
> 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.

> people will use both IPv4 and IPv6, and similar formats would be useful.

They are similar formats.

> 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

---

From: Pekka Savola <[email-masked]>
Date: Fri, 19 Sep 2003 10:21:58 +0300 (EEST)

Right.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 19 Sep 2003 09:24:33 -0400

Curtis

---

From: "Larry J. Blunk" <[email-masked]>
Date: 19 Sep 2003 10:24:33 -0400

Pekka and Curtis,

 -Larry Blunk
  Merit

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 19 Sep 2003 15:07:03 -0400

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 <[email-masked]>, "Larry J. Blunk" writes
> 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.

> filter-set, etc., than another org's aut-num object.

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.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 21 Sep 2003 17:18:52 +0300 (EEST)

> 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.

[...]
> 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.)

> 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.

---

From: Pekka Savola <[email-masked]>
Date: Sun, 21 Sep 2003 17:18:52 +0300 (EEST)

[...]

---

From: Mark Prior <[email-masked]>
Date: Mon, 22 Sep 2003 09:04:12 +0930

> 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.

> twice, once for each support with different command-line arguments is 

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.

---

From: Mark Prior <[email-masked]>
Date: Mon, 22 Sep 2003 09:04:12 +0930

Mark.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 12:24:42 -0400

In message <[email-masked]>, Pekka Savola w
> twice, once for each support with different command-line arguments is 

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.

> 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.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 12:24:42 -0400

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 12:40:16 -0400

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 12:40:16 -0400

Mark,

Curtis

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 09:00:06 +0930

> How is RPSLng not a superset of RPSL?  Nothing has been removed from

Superset is probably not the best word to describe what I want.

> translated into plain RPSL.

I think I have been consistent in wanting the smarts to be in the 
software and not the language. I would prefer to overload the syntax 
then create new syntax and let the software work out what is required. 
We don't use different syntax in computer languages when we want to 
operate on integers rather than reals so why make the distinction in 
RPSL? If we have a route object that has a IPv6 address in it surely the 
software can work out if it wants it or not given it's current context?

I know you (and others :-) keep on about the old clients but we have 
left them behind once before in the transition from RIPE 181 to RPSL so 
do it again but this time lets leave some mechanism behind so that when 
we need (RPSLng)ng we don't go through this pain yet again. Saying it's 
not part of the language is a pathetic excuse in my book for not fixing 
it. If we need a "shim" document to describe the interaction between a 
server and a client then lets do it. It would make the client software 
writers life a lot easier if there weren't (at least) 3 server 
interaction languages to deal with.

Mark.

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 09:00:06 +0930

Mark.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 22:12:09 -0400

> 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.

> 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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 22:12:09 -0400

Curtis

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 12:20:41 +0930

> 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.

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 12:20:41 +0930

Mark.

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 12:36:36 +0930

> 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.

> 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.

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 12:36:36 +0930

Mark.

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 23:35:13 -0400

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

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 22 Sep 2003 23:35:13 -0400

Mark,

Curtis

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 13:19:41 +0930

> 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.

---

From: Mark Prior <[email-masked]>
Date: Tue, 23 Sep 2003 13:19:41 +0930

Mark.

---

From: Engin Gunduz <[email-masked]>
Date: Tue, 23 Sep 2003 23:08:04 +0200

On 2003-09-22 22:12:09 -0400, Curtis Villamizar wrote:
[...]
> 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

-- 
Engin Gunduz
RIPE NCC Database Group

---

From: Engin Gunduz <[email-masked]>
Date: Tue, 23 Sep 2003 23:08:04 +0200

-- 
Engin Gunduz
RIPE NCC Database Group

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 23 Sep 2003 19:22:11 -0400

> out of scope.  CRISP will be the solution to this problem.

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 23 Sep 2003 19:22:11 -0400

Make sense?

Curtis

---

From: Mark Prior <[email-masked]>
Date: Wed, 24 Sep 2003 09:04:22 +0930

> 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 :-)

---

From: Mark Prior <[email-masked]>
Date: Wed, 24 Sep 2003 09:04:22 +0930

Mark.

---

From: Engin Gunduz <[email-masked]>
Date: Tue, 30 Sep 2003 10:41:17 +0200

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:      [email-masked] 19991004
changed:      [email-masked] 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:      [email-masked] 19940314
changed:      [email-masked] 19990701
changed:      [email-masked] 19990809
changed:      [email-masked] 19990912
changed:      [email-masked] 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:      [email-masked] 19991014
changed:      [email-masked] 20020919
changed:      [email-masked] 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

---

From: Engin Gunduz <[email-masked]>
Date: Tue, 30 Sep 2003 10:41:17 +0200

Dear colleagues,

aut-num:      AS12702
as-name:      UUNET-EMEA-IPV6
descr:        WorldCom EMEA

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

or

aut-num:      AS1938

Best regards,

--
RIPE NCC RPSLng Team
Katie, Shane & Engin