Subject: RE: Use of the term "end-to-end"

From: "Mohan, Ram" <[email-masked]>
Date: Mon, 7 Aug 2000 14:31:51 -0400

In the MPLS scenario, does end-to-end mean edge router-to-edge router in an
IP backbone network or customer-premise router-to-customer premise router?
My assumption is that in a service provider environment, a customer premise
router connects to an edge router or aggregation router, which is basically
a provider edge router.  If anyone could kindly clarify this, I'd really
appreciate it.  Thanks again.

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, August 07, 2000 12:51 PM
To: Loa Andersson
Cc: [email-masked]; David Allan; Scott Brim; David R. Oran; mpls;
IESG; IAB
Subject: Re: Use of the term "end-to-end" 

I have to say  that I don't see what the problem is.  Or rather, I don't see
that  there   is  a   problem  which  requires   any  modification   of  the
specifications. 

I don't think that "end-to-end" is used  in any of the MPLS documents, and I
believe  that  those documents  contain  terminology  which  is adequate  to
precisely state any necessary concepts.

In discussing MPLS, the term  "end-to-end" is sometimes used colloquially in
contexts  where it is  clear to  most that  it doesn't  mean "host-to-host".
Dave might be  right to deplore this usage.   However, increasing the number
of precisely  defined terms and acronyms  will not do anything  to stamp out
such colloquialisms.

---

From: "David Allan" <[email-masked]>
Date: Tue, 8 Aug 2000 13:13:57 -0500

Neil:

	If we accept the notion that an LER is where "foo" gets adapted to
run over an LSP (ingress) or converted back to it's non LSP format (egress),
then LER to LER is fine (and directly analagous to your TTL function, when
we are viewing it in the context of an LSP, not a box function). To me it is
self evident that most LSRs would have both adaptation and native forwarding
capability and in LER we are defining a LSP specific function, not a
specific class of LSR. Only if the consensus is that the "non-official use"
of the term LER is already overloaded to only mean a specific box in a
network, do we need "more precise" terminology.

	The other contributors are correct in suggesting that e2e has a
particular "non-subjective" meaning in the IETF context. ;-)

	regards
	Dave

> [email-masked] wrote:
> > 
> > All,
> > 
> > End-to-end is subjective since it depends on your perspective....think
> about
> > nested LSPs, we have to cater for these.  LER-to-LER is architecturally
> > restrictive being just one specific case of an LSP, and (as Eric points
> out)
> > related to 'current box names'.  I believe we need a generic term that
> > captures the essence of the LSP entity at whatever level it exists in a
> > label stacked hierarchy of LSPs.  If we borrow from functional modelling
> > terminology developed in G.805 by the ITU for SDH and ATM, I suspect
> that
> > 'trail termination points' (ie an LSP exists between them) is the
> closest
> > match to the function we are trying to describe. I attach the extracted
> > references from G.805 below for your information.
> > 3.1     trail termination sink: A "transport processing function" which
> > accepts the characteristic information of the layer network at its
> input,
> > removes the information related to "trail" monitoring and presents the
> > remaining information at its output.
> > 3.2     trail termination source: A "transport processing function"
> which
> > accepts adapted "characteristic information" from a client layer network
> at
> > its input, adds information to allow the "trail" to be monitored and
> > presents the characteristic information of the layer network at its
> output.
> > The trail termination source can operate without an input from a client
> > layer network.
> > 
> > Whilst these are not perfect matches we could start to use them I guess
> (or
> > invent our own).  Also note that as MPLS expands to cover other
> technologies
> > (eg optical networks) then we need a common architectural term for the
> LSP
> > object irrespective of the technology.
> > BTW....I understand the ITU are going to develop a functional model of
> > optical and IP/MPLS networks in due course.
> > 
> > So perhaps we could use LSP_TTP-LSP_TTP (or LTTP-LTTP, or indeed
> whatever
> > looks nice) to define this entity.....and to be honest I don't think its
> > name is that important, just so long as we agree on (functionally) what
> that
> > entity is.
> > 
> > The only thing that concerns me now is PHP......as I said in a mail
> several
> > weeks ago (wrt defect detection and consequent action, eg restoration) I
> > really don't like the idea that the LSP (sink) trail termination point
> is a
> > moveable feast.
> > 
> > Regards, Neil
> > 
> > > From: Eric Gray [SMTP:[email-masked]]
> > > Sent: Monday, August 07, 2000 4:57 AM
> > > To:   Loa Andersson
> > > Cc:   David Allan; Scott Brim; David R. Oran; mpls; IESG; IAB
> > > Loa,
> > >     I distinctly remember your proposing the term and
> > > its more-or-less being rejected.  Never-the-less, it has
> > > come to be accepted as a real term.  Many slides and
> > > charts now contain some subset of this picture:
> > >
> > >   LER -- LSR -- ... -- LSR -- LER
> > >
> > > While it is still debatable that a box which is exclusively
> > > either an LER or an LSR will be a long-term survivor
> > > in the market place, it is useful to think of LSR verses
> > > LER functionality.
> > >
> > > Loa Andersson wrote:
> > >
> > > > This is fine with me, but the last time (back in the childhood of
> MPLS)
> > > > I tried to propose the term LER as part of the MPLS vocabulary it
> was
> > > > not considered necessary. SO either we add it or use something else.
> > > >
> > > > /Loa
> > > >
> > > > David Allan wrote:
> > > > >
> > > > > Agreed
> > > > >
> > > > >      From:   Scott Brim [SMTP:[email-masked]]
> > > > >      Sent:   Thursday, August 03, 2000 11:37 AM
> > > > >      To:     David R. Oran
> > > > >      Cc:     mpls; IESG; IAB
> > > > >      LER-to-LER
> > > > >      <snip>
> > > > --
> > > > Loa Andersson
> > > > Director Routing Architecture Lab, EMEA
> > > > St Eriksgatan 115A, PO Box 6701
> > > > 113 85 Stockholm, Sweden
> > > > phone: +46 8 50 88 36 34,   mobile + 46 70 522 78 34
> > > > e-mail: [email-masked]

---

From: "G.S. Kuo" <[email-masked]>
Date: Tue, 8 Aug 2000 09:47:53 +0800 (CST)

Grenville,

I support your point.

G.S.
-----------------------------------------------
Date: Mon, 07 Aug 2000 16:15:33 -0700
From: Grenville Armitage <[email-masked]>
To: Scott Brim <[email-masked]>
CC: [email-masked], IESG <[email-masked]>, IAB <[email-masked]>
Subject: Re: Use of the term "end-to-end"

LER-to-LER makes sense because it contains the notion
of "edge" (the 'E' in LER) as opposed to "end".  Which makes
me think the better phrase is just "edge to edge" since it really
isn't a new term per se, generalizes neatly to similar concepts
in Diffserv, and captures the non-end2end nature of what we're talking
about without constraining the mental model to start/end on an
MPLS-specific functional element.

cheers,
gja

Scott Brim wrote:
        [..]
> But (1) we can do the right thing and not use "end-to-end" in a way that
> further erodes its meaning. and (2) if it's a confusing term then we
> shouldn't use it anyway.  I like LER because it's a clearly defined
> functionality, within the context of MPLS, regardless of whether the box
> that is an LER is doing other things as well.

---

From: Eric Gray <[email-masked]>
Date: Tue, 8 Aug 2000 14:17:35 -0700

Eric (Rosen) brings up a very good point.  Many
of the long-term IETFers (e.g. - Brian and Ran)
are familar with A MEANING of the term end-to-end.
RFC 1958 is absolutely rife with implied meaning, 
but no actual definition.  I guess the meaning was 
too obvious at that time to need defining.

But the implied meaning is actually "end-system-
to-end-system" which - at that time - meant host
to host.  I guess that "end-to-end" was easier to
say.  Since the advent of IP-in-IP tunneling and 
similar technological approaches (e.g. - MPLS), 
this meaning has become obsolete (no implied 
insult to long-term IETFers).  The meaning of
end-system becomes a little fuzzy when you add
the possibility of hierarchy.

So I don't think that people need to get huffy
about "misusing" the term.

However, I am perfectly happy to use LER-to-LER
(I don't think introducing additional options
- i.e. LIP, LEP, LAP, LOP, etc. - is helpful).

> Sent: Tuesday, August 08, 2000 9:49 AM
> To: Brian E Carpenter
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> (I don't know why I want to add more to this silly thread, but ...)
> 
> Could someone  quote the passage in  RFC 1958 that  defines 
> "end-to-end"?  I
> can't seem to locate it.  
> 
>

---

From: [email-masked]
Date: Wed, 9 Aug 2000 00:34:03 +0100

Brian,

This is going to be the last one from me on this topic as it is not worth
the BW.

I know the end-end tenet for old-school IP (ie host-host), and I agree with
its sentiment in that perspective..... but you are missing the architectural
point I am making.  But when one is dealing with LSPs which start/terminate
at some other 'end-to-end' points this is quite different.....and when they
are nested, clearly their start/stop points are *subjective* to the
perspective of whoever is operating them at level N.  Please try to think
more openly......if it helps consider an SDH VC4 or a WDM lamba or even an
ATM VP....these trails have their own 'end-to-end' meaning which is not
wrong from *their* perspective.  And here we are dealing with LSPs which
quite clearly fall into such a classification - how anyone could say
otherwise would defy belief.

To be more rigorous however, an LSP starts at the point at which the label
and other overhead (specific to that LSP) at level N, and it terminates at
the point at which the label and other overhead is removed at level N.  And
from that particular LSPs perspective that is end-to-end.

The-end:  Neil   

> From:	Brian E Carpenter [SMTP:[email-masked]]
> Sent:	Tuesday, August 08, 2000 3:46 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> No, end-to-end is very explicit in the Internet and not at all
> subjective. Please see RFC 1958.
> 
>    Brian
>