The MPLS WG Archive

["Brijesh Kumar" <bkumar@ennovatenetworks.com>]

Hi neil,

End-to-End has certain well understood meaning ( the closest IETF doc
explaining this term is RFC 1958 - Architectural Principles of the
Internet). There is no need to overload this term. The use of LSP
Ingress Point/Router/Node/Edge (LIP, LIR, LIN or LER) to LSP Egress
Point/Router/Node/Edge (LEP, LER, LEN or LER) will be lot better.

Cheers,

--brijesh
Ennovate Networks Inc.


> -----Original Message-----
> From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of
> neil.2.harrison@bt.com
> Sent: Tuesday, August 08, 2000 9:53 AM
> To: ewgray@mindspring.com; loa.andersson@nortelnetworks.com
> Cc: dallan@nortelnetworks.com; sbrim@cisco.com; oran@cisco.com;
> mpls@UU.NET; iesg@ietf.org; iab@isi.edu
> Subject: RE: Use of the term "end-to-end"
>
>
> 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
>
>
>