Subject: RE: terminology

From: Vishal Sharma <[email-masked]>
Date: Thu, 3 May 2001 16:33:19 -0700

David,

I agree with your characterization below. Even the paragraph quoted by
Gerhard from RFC 3031 makes sense in the context in which you've explained 
it. 

Namely, if we define a "tunnel" as being any means of making a packet
arrive at a non-directly-attached router, then an LSP may be viewed
as one realization of a tunnel. (Even in that case, however, why don't
we just settle on the term "tunnel". I guess one could argue that the
phrase "LSP tunnel" is a bit more descriptive, in that it indicates how
the tunnel in question is being realized; through an LSP.)
Although, I am not sure that any of the documents actually states things
the way you've defined them (which would make things much clearer for
us all).

I still have a problem (and have had for quite some time), however, 
with the RSVP-TE draft, since it uses the term "tunnel" in contradictory
and confusing ways.

The following is an excerpt taken directly from Section 1.0 of the RSVP-TE
draft:

   "Since the traffic that flows along a label-switched path is defined
   by the label applied at the ingress node of the LSP, these paths can
   be treated as tunnels, tunneling below normal IP routing and
   filtering mechanisms.  When an LSP is used in this way we refer to it
   as an LSP tunnel.

   LSP tunnels allow the implementation of a variety of policies related
   to network performance optimization.  For example, LSP tunnels can be
   automatically or manually routed away from network failures,
   congestion, and bottlenecks. Furthermore, multiple parallel LSP
   tunnels can be established between two nodes, and traffic between the
   two nodes can be mapped onto the LSP tunnels according to local
   policy. Although traffic engineering (that is, performance
   optimization of operational networks) is expected to be an important
   application of this specification, the extended RSVP protocol can be
   used in a much wider context.

   The purpose of this document is to describe the use of RSVP to
   establish LSP tunnels.  The intent is to fully describe all the
   objects, packet formats, and procedures required to realize
   interoperable implementations.  A few new objects are also defined
   that enhance management and diagnostics of LSP tunnels."

As one reads through this, one might conclude that this part actually
uses the term "LSP tunnel" in the same way that RFC 3031 uses it, and 
in the way that you've defined it. 

However, as you've observed yourself, later on in the same draft the
term "LSP tunnel" is applied to something quite different; a collection
of LSPs that share a common destination, or, more precisely, a common
SESSION object. This latter use is very specific and quite different
from what one is lead to believe in the Introduction, and indeed in 
much of the draft.

If we agree that the commonly accepted definition of "tunnel" is
what you've defined (and which I've paraphrased above), and, if
we agree that the term "LSP tunnel" is, in fact, merely another
term for an LSP, with the additional connotation that the LSP can
be used to realize a "tunnel," (which is a bit of a stretch, since
every LSP is after all an "LSP tunnel"),

then clearly, the "collection of LSPs sharing
a common SESSION object" needs a different term.
I don't know what yet, but a different term.

-Vishal 

> -----Original Message-----
> From: David Charlap [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 12:52 PM
> To: [email-masked]'
> Subject: Re: terminology
> 
> 
> "Gross, Gerhard" wrote:
> > 
> > The definitions "LSP tunnel" in the docs seem to be somewhat
> > misleading. For example, section 3.27.3 of RFC 3031 states:
> > 
> >     "It is possible to implement a tunnel as a LSP, and use label
> >     switching rather than network layer encapsulation to cause the
> >     packet to travel through the tunnel. ...
> >     This is called a "LSP Tunnel."
> > 
> > This is standard MPLS as far as I tell.
> > Why rename it?
> 
> The definition of "tunnel" seems to be different in different 
> documents.
> 
> In RSVP-TE, a tunnel is a collection of one or more LSPs that are all
> signaled with the same SESSION object.  (Session being defined as the
> triplet egress-address, tunnel-ID, and extended-tunnel-ID.)  
> If extended
> tunnel ID is zero, these LSPs may originate from different ingress
> routers.  The distinction is important because all LSPs in a single
> tunnel will share resources where possible, when an SE-style 
> reservation
> is used.
> 
> Colloquially, this is the definition I usually use.  I usually say
> "tunnel" when I mean a collection of LSPs that share a common
> destination.  If I mean a single LSP, I just say "LSP".
> 
> But this is not RFC 3031's definition.  RFC 3031 defines a "tunneled
> packet" as any packet that is forwarded to a not-directly-attached
> router.  A tunnel is defined as any means for making this work.
> 
> It then goes on to define three kinds of tunnels, the first two don't
> necessarily involve MPLS.
> 
> The first is a hop-by-hop routed tunnel.  The data is 
> encapsulated in a
> network-layer header that gets it to the next-hop router.  
> One possible
> non-MPLS example of this might be an IP-in-IP tunnel.
> 
> The second is an explicitly-routed tunnel.  The data is 
> encapsulated in
> a network-layer header that is explicitly routed to the next-hop
> router.  One possible non-MPLS example of this might be an ATM PVC.
> 
> The third is the LSP tunnel.  The data is labeled and forwarded using
> MPLS.
> 
> If my understanding is incorrect, hopefully one of the RFC 
> authors will
> be able to correct me.
> 
> -- David
>