IETF Logo Mail Archive

[Rps] Latest RPSLng draft

"Larry J. Blunk" <ljb@merit.edu> Fri, 21 November 2003 15:37 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18094 for <rps-archive@lists.ietf.org>; Fri, 21 Nov 2003 10:37:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDLA-0005mJ-HK; Fri, 21 Nov 2003 10:37:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDGb-0005dD-20 for rps@optimus.ietf.org; Fri, 21 Nov 2003 10:32:17 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17920 for <rps@ietf.org>; Fri, 21 Nov 2003 10:32:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDGY-0003l8-00 for rps@ietf.org; Fri, 21 Nov 2003 10:32:14 -0500
Received: from dhcp62-10.merit.edu ([198.108.62.240] helo=bliss.merit.edu) by ietf-mx with esmtp (Exim 4.12) id 1ANDGW-0003l0-00 for rps@ietf.org; Fri, 21 Nov 2003 10:32:13 -0500
Received: from bliss.merit.edu (localhost [127.0.0.1]) by bliss.merit.edu (8.12.10/8.12.10) with ESMTP id hALFW6ej000809; Fri, 21 Nov 2003 10:32:06 -0500
Received: (from ljb@localhost) by bliss.merit.edu (8.12.10/8.12.10/Submit) id hAL6M54R001134; Fri, 21 Nov 2003 01:22:05 -0500
X-Authentication-Warning: bliss.merit.edu: ljb set sender to ljb@merit.edu using -f
From: "Larry J. Blunk" <ljb@merit.edu>
Reply-To: ljb@merit.edu
To: Pekka Savola <pekkas@netcore.fi>
Cc: curtis@fictitious.org, rpslng@ripe.net, rps@ietf.org
In-Reply-To: <Pine.LNX.4.44.0309181408040.17750-100000@netcore.fi>
References: <Pine.LNX.4.44.0309181408040.17750-100000@netcore.fi>
Content-Type: multipart/mixed; boundary="=-hBt6deZdbzKC595yVR/x"
Organization: Merit Network, Inc.
Message-Id: <1069395724.1063.12.camel@localhost>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5
Subject: [Rps] Latest RPSLng draft
Sender: rps-admin@ietf.org
Errors-To: rps-admin@ietf.org
X-BeenThere: rps@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rps>, <mailto:rps-request@ietf.org?subject=unsubscribe>
List-Id: Routing Policy System <rps.ietf.org>
List-Post: <mailto:rps@ietf.org>
List-Help: <mailto:rps-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rps>, <mailto:rps-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/rps/>
Date: Fri, 21 Nov 2003 01:22:05 -0500

   I've attached the latest draft of the RPSLng spec.  I've left the
afi definition section as it was previously as I don't think there
was consensus to change the meaning of ipv4 and ipv6 to include
both unicast and multicast.   Please let me know if there are any
strong feelings about this.   One option could be to add ipv4.any
and ipv6.any types as a shorthand for ipv4.unicast,ipv4.multicast and
ipv6.unicast,ipv6.multicast.  However, I'm not sure if this doesn't
actually make things worse by creating more clutter in the spec.


   I've reduced the encapsulation types for the tunnel option in
the interface: attribute to just GRE and IPinIP.  IPinIP was
deemed sufficient since you already know the address types
of the encapsulating end-points.  DVMRP was dropped since the
protocol/encapsulation method seems to be deprecated at this point.
Should we add other encapsulation methods to this attribute?  For
example, LT2P, PPTP, or IPSec?   Would it be useful to have an
afi specification to indentify/restrict the address family types
carried across the tunnel?

 -Larry Blunk
  Merit

v2.23.0 | Report a Bug | By Email