Internet Draft
Internet Draft Eric Gray
<draft-gray-mpls-arch-issues-00.txt> Lucent Technologies, Inc.
Expires Oct 1998
Issues With MPLS Architecture
Status of this Memo
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 is intended to point out several issues with current
proposals for MPLS architecture as adopted by the MPLS working group.
Table of Contents
Status of this Memo ...................................... 1
Abstract ................................................. 1
Table of Contents ........................................ 2
1 Architecture Issues ...................................... 2
1.1 Excessive Complexity ..................................... 2
1.2 Lack of Flexibility/Generality ........................... 3
1.3 Lack of Multicast and Explicit Route Support ............ 5
2 References ............................................... 7
3 Author Information ....................................... 7
Appendix A - Specific Editing Changes Recommended ........ 8
Gray, et al [Page 1]
MPLS Architecture Issues - 2 - April 1998
1. Architecture Issues
1.1 Excessive Complexity
Phasing
In the familiar sense, the term architecture (in technical use)
is used to bound the set of functions which need to be included
in specifications of desirable protocol/behavior. In this way,
people working on the different pieces can see how the whole is
intended to fit together. Using the architecture as a guide, a
group of people can prioritize various functional subsets into
phases (or releases) each of which builds on pieces layed down
in one or more previous phases.
Generally, it is undesirable for an architecture to require the
completion of all phases before realizing a useful product.
With a variety of not-wholly-interoperable proprietary versions
of essentially the same technology already being offered, it is
important in our MPLS efforts for us to be able to define early
phases of a standardized label switching technology that offers
substantive functionality in as simplistic a way as possible in
a manner consistent with an ongoing architecture.
It is not clear that all of the contributors to the architecture
draft agree that this is possible in the current draft [ARCH].
In particular, issues have been raised with draft proposals that
do not address all of the functionality defined (in [ARCH]), and
this seems to imply either that phasing is not possible with the
current proposed architecture or that phasing is counter to the
goals of those contributors.
[ARCH] should indicate which pieces of the architecture are
required to support what levels of functionality.
Other elements relating to phasing of MPLS functionality are
described in sections below.
Definition
The current draft architecture [ARCH] allows multiple choices in
several key areas - providing no particular suggested priorities
or preferred solutions. In addition, there are no less than 4
areas in which major issues are noted as FFS (for further study)
- including LDP Procedures (section 4). As the first place where
people look for these choices to be documented, this is a serious
issue.
Current consensus seems to be that the architecture should allow:
Gray, et al [Page 2]
MPLS Architecture Issues - 3 - April 1998
specification of LDP including explicit routes and simple QoS,
specification for use of RSVP for label distribution, both intra-
and inter-domain, for support of QoS or best effort (including
explicit route) path setup and
specification for use of BGP to distribute inter-domain labels
within domains.
Specification for these approaches to label setup may proceed in
parallel; sufficiently well defined and implementable protocol
would be included in an initial version of MPLS. Definition of
other mechanisms for label switched path setup may be developed
but are currently not considered priorities for an initial MPLS
version.
Decription
Several of the descriptions (in [ARCH]) are - while rigorous in
a mathematical/computability sense - very difficult to follow.
While this allows implementers to determine if specifications
based on this architecture will work, it does not generally let
users, managers, etc. (in short - the people paying the bills)
understand whether or not an implementation would be useful, or
exactly what they want or need. In addition, these complicated
descriptions increase the likelyhood that implementers will not
build products that play well with each other. An example of
this is the description of LSPs in section 2.11.
Another, perhaps simpler, approach to describing an LSP of level
m would be to define "ingress", "intermediate" and "egress" LSR
behaviors from the perspective of the local LSR's handling of a
packet for that LSP and then simply stating that the LSP is made
up of these elements.
1.2 Lack of Flexibility/Generality
Terminology
What is the term for the collection of LSPs which any particular
LSR is a part of? An MPLS domain is the theoretical outer bound
for this conceptual entity, yet - at any given time - this thing
will be some subset of the MPLS domain for each LSR within it. A
may overlap MPLS domains in practice as
well - in special cases where LSPs are established between hosts
(or networks) in one MPLS domain and hosts (or networks) in some
other(s). Having a term for this would help in understanding a
few of the issues with other parts of the architecture - for
example, section 2.15.1 ("Loop Prevention") which specifies a
particular loop prevention mechanism that requires per-LSP state
maintenance (downstream LSR ID list) at each LSR.
Gray, et al [Page 3]
MPLS Architecture Issues - 4 - April 1998
Also, the terminology section defines the term LIB which appears
to be composed of the NHLFE, ILM and STN (described in sections
2.7, 2.8 and 2.9, respectively) - although nowhere is this fact
(if it is a fact) made clear. The architecture should make it
clear that the descriptions associated with these sections are
"functions" required of an LSR - not hard behavioral requirements
or specifications. (No one should assume based on this draft -
should it become an RFC - that there will be corresponding MIB
variables for the mappings described). This is crucial because
an implementation may establish tables in ways that are simpler
and more consistent with other things being done in the specific
implementation which - never-the-less - do the same things.
As an issue relating to terminology (although not necessarily to
flexibility and/or generality), the terms "LSP Tunnel" and "MPLS
Hierarchy" are introduced in section 2.6 and discussed later in
section 2.19 (and listed in the Table of Contents) but are not
included in Terminology (section 1.2). Both terms are used in
various parts of the draft.
Behavior
At least one aspect of the architecture appears to assume that a
particular type of behavior is always possible - i.e. - use of a
label by an LSR not negotiated between that LSR and a neighbor.
In section 2.11, it is possible for an egress "LSR" to have only
the ability to require its upstream neighbors to "pop" the label
stack and it is possible for one (or more) of those neighbors to
be unable to do so (both situations are described in the text).
Obviously, this is an untenable combination of implementations,
yet this issue is not made clear. This is just one example of
a situation where it is obvious that an LSR must have the ability
to refuse a label - and this may need to be an architectural
requirement.
Another section - 2.15.1 - actually specifies behavior (instead
of specifying required functions of a specification) which is
not consistent with other specifications accepted by the MPLS
working group to accomplish the same thing. This section has an
in-depth description of a loop prevention scheme which may not
be required at all (the same effect can be achieved in any of a
variety of ways using LDP - see [LDP] and [GLDP]).
Section 2.16.3 defines specific behaviors for LDP rather than the
requirements of the architecture. As an architecture, it could
suggest such behavior as an illustrative example. At present,
it implies that LSRs must announce their merge capability so that
their downstream neighbors may determine whether or not to provide
labels. What appears to be actually required of LDP is a means to
provide more than one label for each FEC to an upstream neighbor
Gray, et al [Page 4]
MPLS Architecture Issues - 5 - April 1998
- when such labels are requested/required. In fact, the draft
currently gives an example in which the merge-capability is not
useful in determining neighbor behavior (bottom of page 25).
Completeness
Section 2.16.4.1 leaves the topic of avoiding VCI collisions as
for further study. What the architecture needs to state is the
requirement on LDP to provide a means for ensuring that any VCI
collisions are detected and corrected. It is not necessary for
the architecture to select a mechanism - only state the need.
Inconsistency
Text in section 2.6 is inconsistent with text in section 2.7.
Section 2.6 states that forwarding is "based exclusively on the"
top-of-stack label. Clearly, a reasonable implementation may map
an incoming label to a pop-and-look-again instruction. This is
one way to implement use of a label stack within an LSR and may
be an essential approach in cases where a pop is required more
than once at the same LSR (such as when it is the "egress" for
more than one stacking level - or "tunnel" within a "tunnel").
Indeed, text in section 2.7 describes approximately this same
scenario (i.e. - "pop the label stack" with next hop equal to
the local LSR - which is logically the same thing).
1.3 Lack of Multicast and Explicit Route Support
Multicast
This section should at least suggest a relative priority for
support of multicast in MPLS and may be updated to reflect
work that is ongoing.
Explicit Route
Section 2.13 seems to take an architectural feasibility position
that is unjustified. As a result, it [ARCH] appears to make the
use of explicit routes a non-goal of the architecture for phases
of MPLS deployment for which this architecture might apply.
Two essentially incorrect statements are made: 1) LSRs may not
mix explicit route and hop-by-hop routes on the same LSP and 2)
all LSRs on intended LSPs must be able to support explicit routes
in order to be able to use explicit routes to establish the LSP.
These statements are not made in the form of an architecture choice
- rather they are stated as facts. What is required is that the
architecture state the issues associated with use of explicit
routes which must be dealt with in protocols (e.g. - LDP) if MPLS
is to support explicit routes in such a way that they will work
(and stay loop-free). A goal of any protocols developed for the
Gray, et al [Page 5]
MPLS Architecture Issues - 6 - April 1998
architecture should be to minimize the requirements imposed on
all implementations to support functional extensions.
Since a number of working group members feel that explicit route
support will be required (if not immediately, then eventually),
the architecture should endeavor to account for how explicit
route support will be supported in the future - with mixed MPLS
version deployment - if it is not to be supported initially.
An example of a combination of explicit and hop-by-hop routes is
when one (or more) of the routers in the list of routers in a
explicit route is a "wild card" - indicating that any available
router(s) between the previous and next specified routers on the
explicit path will work.
An example of how LDP might support explicit routes - even where
not all LSRs specified on the path support explicit routes can
be seen by simply using LDP extensions which are opaque to those
LSRs that do not support explicit routes. See [GLDP] for an
example description of required LSR behavior.
A commonly held belief is that MPLS must support explicit routes
to allow for traffic engineering - and this is acknowledged in
the architecture draft. However, [ARCH] goes further in saying
that support for explicit routes is not a requirement for every
LSR (and consequently, not a goal of MPLS) - throughout the
applicability of the architecture. In this [ARCH] is just wrong.
In section 2.16.3, the architectural requirements for merging of
explicit route LSPs is left for further study. It is simple to
define these requirements, however: LSPs established for best-
effort forwarding on an explicit route LSP may be merged (if the
specific LSR is capable of doing so both in general and as an
explicit route); an LDP may define how LSRs can determine if
stream merging is permissible in cases where it is not possible
for the local LSR to determine that the associated LSP is best-
effort - otherwise, stream-merging of explicit route LSPs is
not permitted. (Note that one consequence of not requiring LSRs
to support explicit routes is that this becomes harder - but not
impossible - to do in LDP).
Gray, et al [Page 6]
MPLS Architecture Issues - 7 - April 1998
2. References
[ARCH] "A Proposed Architecture for MPLS", E. Rosen, A. Viswanathan,
R. Callon, work in progress, draft-ietf-mpls-arch-00.txt, August,
1997.
[GLDP] "Generic Label Distribution Protocol Specification", Gray, et
al, work in progress, Internet Draft , November, 1997.
[LDP] "LDP Specification", N. Feldman, et al, work in progress,
Internet Draft <draft-feldman-ldp-spec-00.txt>, November, 1997.
3. Author Information
Eric Gray
Lucent Technologies, Inc.
1600 Osgood Street
North Andover, MA 01845
ewgray@lucent.com
Gray, et al [Page 7]
MPLS Architecture Issues - 8 - April 1998
Appendix A - Specific Editing Changes Recommended
section 2.11, description of LSP of level m #1 - should read:
1. R1, the "LSP Ingress", pushes a label, or label stack, onto P's
stack resulting in a label stack of depth m;
(required for generality)
- #2 should read:
2. For all i, 1=0) when
received by Ri and prior to popping k labels from the stack;
(required for generality, consistency with #5)
- #5 may be easier to read written as follows:
5. For all i, 10).
- Above the last paragraph on page 15 of the current (00) draft,
add the following new paragraph:
Also note that R[i+1] in the above described LSP may receive P with
a label stack of depth m+k and pop k labels off of the stack prior
to making a forwarding decision. This would happen, for example,
if some non-zero number of forwarding devices between R[i] and
R[i+1] are on a LSP of level m+k (k>0) and either penultimate hop
popping is not supported or does not reduce k to zero.
Gray, et al [Page 8]
MPLS Architecture Issues - 9 - April 1998
section 2.11 - alternative description:
A "Label Switched Path (LSP) of level m" for a particular packet P
is a sequence of LSRs,
where R1 is the LSP ingress, Rn is the LSP egress and all other
LSRs are intermediate LSRs relative to P and m.
An "LSP ingress" pushes a label, or label stack, onto P's label
stack, in this case resulting in a label stack of depth m.
An "LSP egress" receives packets labeled with distinguishable
labels assigned to the current labeling depth, for which it
assigned to an upstream LSR(s) (of depth plus one relative to
current) the well known label corresponding to penultimate hop
pop, receives packets for which it will pop k>0 labels, or both.
If an LSR is the "LSP Egress" to an LSP of level m, then:
in the first case, P is received with a labeling depth of m-1;
in the second case, P is received with a labeling depth of m
and pops k>0 labels off of the stack;
in the third case, P is received with a labeling depth of m-1
and pops k>0 labels off of the stack.
The term "intermediate LSR" has no generalizable meaning except
relative to an LSP of level m. Intermediate LSRs for an LSP of
level m are LSRs that make their forwarding decisions, relative
to P, based on the level m label. Intermediate LSRs may also
provide LSP ingress or egress to LSPs of level m+k (k>0) and
still function as intermediate LSRs for an LSP of level m.
(Above is recommended as in addition to or in place of all of the
text in section 2.11 up to but not including the final paragraph
on page 15)
Gray, et al [Page 9]
MPLS Architecture Issues - 10 - April 1998
section 2.16.3 - first paragraph
The number of labels required per FEC depends on the number of
contiguous non-merge-capable LSRs directly upstream of the LSR
relative to the FEC in question. This is true because a merge
capable LSR directly up stream will require only one label per
FEC, regardless of the number it needs to provide to upstream
neighbors itself.
- third paragraph, first sentence
Change "a single downstream streams" to "each downstream stream"
(at end of sentence).
Gray, et al [Page 10]