comments on David Meyers's RPSL draft
Bob Fink LBNL
RLFink@lbl.gov
Wed, 5 Feb 1997 08:18:06 -0800
I have seen no comments on this list regarding David Meyer's "Representing
Tunnels in RPSL" internet draft.
It is one of our working group tasks to provide feedback to the RPSL folk
on this.
Can anyone tell me what might have transpired on this topic?
Thanks,
Bob
===========================================================
From: "David M. Meyer" <meyer@network-services.uoregon.edu>
Subject: RPSL extensions for tunnels
To: 6bone@isi.edu
Date: Tue, 10 Dec 1996 17:22:09 -0800 (PST)
Mime-Version: 1.0
Sender: owner-6bone@ISI.EDU
Precedence: bulk
Folks,
I didn't get a chance to present this in the BOF, so
here's the draft. Any comments appreciated.
Dave
-----------
INTERNET-DRAFT David Meyer
draft-ietf-rps-tunnels-01.txt University of Oregon
Category: Standards Track November 1996
Representing Tunnels in RPSL
Status of this Memo
This document provides extensions to the Routing Policy Specification
Language [RPSL] to provide support for tunnels of various types.
Internet Drafts
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract
This document specifies the language and set of semantics describing
tunnels in the Routing Policy Specification Language (RPSL). It
defines a new tunnel class, inet-tunnel, and a set of extensions to
the inet-rtr class. An instance of the inet-tunnel class specifies
endpoints for tunnels of various encapsulation types, including DVMRP
[DVMRP], GRE [GRE], and IPv6 [IPV6].
This memo is a product of the Routing Policy System Working Group
(RPS) in the Operational Requirements area of the Internet Engineer-
ing Task Force. Submit comments to <rps@isi.edu> or the author.
Introduction
Tunneling is a fundamental networking technology that is used in a
variety circumstances. A common use of tunneling is to incrementally
deploy a new network layer protocol. The approach is to encapsulate
("tunnel") the new protocol through the existing network layer proto-
col, usually IP. Examples of this approach include include the multi-
cast backbone [MBONE], where multicast packets are encapsulated in IP
packets using protocol 4 (IP in IP), and IPv6 backbone [6BONE], where
IPv6 packets are encapsulated in IP packets using IP protocol 41
[V6TRNS].
Another use of tunneling is to force congruence between the existing
(IP unicast) topology and some new topology. Due the special require-
ments of IP multicast routing, the MBONE is also an example of this
use of tunneling.
This document describes extensions to RPSL to support general tunnel-
ing mechanisms. The extensions support point to point and point to
multipoint tunnels of encapsulation types, including DVMRP, GRE, and
IPv6. In addition to the encapsulation, a protocol to run inside the
tunnel can also be specified.
Extensions to the inet-rtr class
The inet-rtr class' peer attribute is extended to describe tunnels by
assigning a new peer type (tunnel). The tunnel peer attribute has the
following fields:
inet-rtr: <name>
...
peer: tunnel <dest-IP1> source=<source-IP1>
encap=<encapsulation type>
name=<name1>
...
peer: tunnel <dest-IP2> source=<source-IP2>
encap=<encapsulation type>
name=<name2>
The type clause of then tunnel peer attribute describes the encapsu-
lation on the tunnel. The defined encapsulation types are DVMRP
[DVMRP], GRE [GRE], or IPv6 [IPV6]. The name clause refers to a tun-
nel object (see below). If there are multiple tunnel peer attributes
with the same name attribute, then the tunnel is a point to mul-
tipoint tunnel. Note that a router can be the source of multiple tun-
nels.
Each inet-rtr tunnel peer instance has a mandatory name, source, and
destination attributes. The tunnel source attribute must correspond
to an ifaddr attribute for the inet-rtr instance.
The inet-rtr instance below describes a DVMRP tunnel with source
204.70.32.6 and destination 204.70.158.61. The tag MBONE-TUNNEL-EUG
refers to a tunnel instance (see below). The same router has a GRE
tunnel.
inet-rtr: eugene-isp.nero.net
loacalas: AS4600
ifaddr: 204.70.32.6 masklen 30
...
peer: tunnel encap=DVMRP name=MBONE-TUNNEL-EUG 204.70.158.61 204.70.32.6
peer: tunnel encap=GRE name=GRE-TUNNEL-EUG 206.42.19.240 204.70.32.6
...
The inet-tunnel Class
A tunnel is specified by an instance of the inet-tunnel class. The
attributes of the inet-tunnel class are described below.
inet-tunnel: <name>
tunnel-source: <inet-router key>
tunnel-sink: <inet-router key 1>
...
tunnel-sink: <inet-router key n>
tunnel-protocol: <protocol>
tunnel-in: from <inet-router key1> accept <input-filter-spec1>
tunnel-in: from <inet-router key2> accept <input-filter-spec2>
...
tunnel-in: from <inet-router keyn> accept <input-filter-specn>
tunnel-out: to <inet-router key1>
[action
[scope=<ttl1>;]
[boundary=<prefixn/masklen1>;]
[dvmrp-metric=<n>;]]
announce <output-filter-spec1>
tunnel-out: to <inet-router key2>
[action
[scope=<ttl2>;]
[boundary=<prefixn/masklen2>;]
[dvmrp-metric=<n>;]]
announce <output-filter-spec2>
...
tunnel-out: to <inet-router keyn>
[action
[scope=<ttln>;]
[boundary=<prefixn/masklenn>;]
[dvmrp-metric=<n>;]]
announce <output-filter-specn>
inet-tunnel Class Attributes
inet-tunnel: mandatory, single valued
tunnel-source: mandatory, single valued, class key
tunnel-sink: mandatory, single valued, class key
tunnel-protocol: mandatory, single valued
tunnel-in: mandatory, multi-valued
tunnel-out: mandatory, multi-valued
An instance of the inet-tunnel class describes a single tunnel
(although the tunnel-source may be the source of multiple tunnels).
The name attribute is a key that is used in an inet-rtr object to
reference the tunnel object. The tunnel may be point to point or
point to multipoint. A multipoint tunnel will have more than one
tunnel-sink value. Each tunnel-sink must have corresponding tunnel-in
and tunnel-out attributes. The tunnel-protocol is the protocol to run
"inside" the tunnel. The values for tunnel-protocol include BGP,
RIPv6, DVMRP, PIM-DM, and PIM-SM. See [SSMMC] for an application that
uses BGP tunneled in GRE.
The inet-tunnel class's tunnel-out attribute includes an action
clause for which the currently defined actions include: (i). The
minimum IP time-to-live required for a packet to be forwarded to the
specified endpoint (in the case of multipoint tunnels, there may be
per endpoint scopes), (ii). A boundary attribute describes a class of
packets that will not be forwarded through the tunnel, and (iii). A
DVMRP metric. These attributes are particularly relevant to multicast
routing.
The inet-tunnel class also has routing filter specifications which
describe filters that are appropriate for the tunnel's routing proto-
col. In the case of DVMRP, the filter specification
can be the list of network prefixes accepted or advertised.
Finally, an instance of the inet-tunnel class also has all of the
administrative fields present in an aut-num class, including guar-
dian, admin-c, tech-c, notify, mnt-by, changed, and source.
Example
In this example, the inet-rtr eugene-isp.nero.net has a DVMRP tunnel
with the sink on the inet-rtr dec3800-2-fddi-0.SanFrancisco.mci.net.
The tunnel object is called MBONE-TUNNEL-EUG. eugene-isp.nero.net
will accept any routes. eugene-isp.nero.net will forward packets to
the DVMRP tunnel if the packet's time-to-live is greater than or
equal to 64. In addition, eugene-isp.nero.net will not pass any pack-
ets that match the administrative scope boundary filter (in this
case, 239.254.0.0/16).
In addition, the inet-rtr eugene-isp.nero.net has a GRE tunnel
represented by GRE-TUNNEL-EUG.
inet-tunnel: MBONE-TUNNEL-EUG
tunnel-source: 204.70.158.61
tunnel-sink: 204.70.32.6
tunnel-protocol: DVMRP
tunnel-in: from 204.70.158.61 accept ANY
tunnel-out: to 204.70.158.61
action
scope=64;
boundary={239.254.0.0/16};
dvmrp-metric=1;
announce AS-NERO-TRANSIT
guardian: meyer@ns.uoregon.edu
admin-c: DMM65
tech-c: DMM65
notify: nethelp@ns.uoregon.edu
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 961122
source: RADB
inet-tunnel: GRE-TUNNEL-EUG
tunnel-source: 204.70.158.61
tunnel-sink: 206.42.19.240
tunnel-protocol: PIM-DM
tunnel-in: from 206.42.19.240 accept ANY
tunnel-out: to 206.42.19.240
action
scope=64;
announce ANY
guardian: meyer@ns.uoregon.edu
admin-c: DMM65
tech-c: DMM65
notify: nethelp@ns.uoregon.edu
mnt-by: MAINT-AS3582
changed: meyer@ns.uoregon.edu 961122
source: RADB
Security Considerations
Security considerations are not discussed in this memo.
References
[6BONE] See http://www-6bone.lbl.gov/6bone/
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-03, September,
1996.
[GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC1701, October, 1994.
[IPV6] A. Conta and S. Deering, "Generic Packet Tunneling in
IPv6", draft-ietf-ipngwg-ipv6-tunnel-04.txt, October,
1996
[MBONE] See http://www.best.com/~prince/techinfo/misc.html
[RPSL] C. Alaettinoglu, et. al., "Routing Policy
Specification Language (RPSL)",
draft-ietf-rps-rpsl-00.txt, October, 1996.
[SSMMC] Y. Rekhter, "Auto route injection with tunnelling",
NANOG, October, 1996. For additional information, see
http://www.academ.com/nanog/oct1996/multihome.html
[V6TRNS] R. Gilligan and E. Nordmark, "Transition Mechanisms
for IPv6 Hosts and Routers", RFC 1933, April 1996.
Author's Address
David Meyer
University of Oregon
1225 Kincaid St.
Eugene, OR 97403
phone: +1 541.346.1747
email: meyer@ns.uoregon.edu
- end