Subject: RE: terminology - change request

From: "Gross, Gerhard" <[email-masked]>
Date: Fri, 4 May 2001 16:13:57 -0700

I support Vishal's request for (re)defining terms 
that more clearly describe "tunnel" related issues.
Changing names in the RFCs may be out of reach
but we can still do this in the drafts, before
they get to the RFC level.

Misconceptions for me start at
section 3.27 of RFC 3031, especially 3.27.3
where "LSP tunnel" is first defined. In this
case the definition refers to an LSP where
the packets traveling through it have a label
stack greater than 1.

If we accept that definition, since it is already
RFCed, consider (as you already have) some of
the text in draft-ietf-mpls-rsvp-lsp-tunnel-08.txt.
Even in the first 4 pages of the draft
there seem to be contradictions:

(1) Sec 1, para 1: 
   "This document is a specification of
   extensions to RSVP for establishing
   label switched paths (LSPs) in
   Multi-protocol Label Switching (MPLS)
   networks."

This seems to me to be a simple, accurate
and necessary statement.

(2) Sec 1, para 6:
   "The purpose of this document is to
   describe the use of RSVP to establish
   LSP tunnels."

This is confusing in light of (1).

Implication A) The only way to make statements
   (1) and (2) true is to equate "LSP" and
   "LSP tunnel".

(3) Sec 1.2":
   a) "LSP: A Label Switched Path"

   b) "LSP Tunnel: An LSP which is used to
      tunnel below normal IP routing and/or
      filtering mechanisms."

Item (3) contradicts implication A) by implying
there is a difference between "LSP" and "LSP Tunnel".

I think the use of the term "LSP tunnel" in the
first few pages of the draft should be changed
to make it inline with how RFC 3031 defines
"LSP tunnel".

I also agree with Vishal's clear reasoning and
idea that

> the "collection of LSPs sharing
> a common SESSION object" needs a different term.

A unique name should be chosen that more
closely describes what it is (e.g. LSP Session Group).

The title of the draft should also be changed
to be more accurate, such as:

  " RSVP-TE: Extensions to RSVP for Establishing LSPs "

This covers LSPs and "LSP tunnels" as they are
defined in RFC 3031 to any label stack depth.

Gery

        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
        X                                         X
        X    Gerhard W. Gross, Ph.D.              X
        X    Intel                                X
        X    2111 NE 25th Ave                     X
        X    Hillsboro, OR 97124-5961, USA        X
        X    Internet Infrastructure Arch. Group  X
        X      - Internet and Communication Lab   X
        X    phone:    (503) 264-6389             X
        X    fax:      (503) 264-3483             X
        X    email:    [email-masked]    X
        X                                         X
        XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

> -----Original Message-----
> From: Vishal Sharma [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 4:33 PM
> To: 'David Charlap'; [email-masked]'
> Cc: [email-masked]'
> Subject: RE: terminology
> 
> 
> 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
> > 
>