Subject: [mpls-tp] draft-ietf-mpls-tp-framework-10

From: Curtis Villamizar <[email-masked]>
Date: Thu, 25 Mar 2010 03:47:49 -0400

It would be beneficial if we made ECMP disabled by default like PHP
rather than completely prohibited.

Please consider the following change:

  Remove:

    In normal conditions, all the packets sent over a PW or an LSP follow
    the same path through the network and those that belong to a common
    ordered aggregate are delivered in order.  For example per-packet
    equal cost multi-path (ECMP) load balancing is not applicable to
    MPLS-TP LSPs.

  Replace:

    In normal conditions, all the packets sent over a PW or an LSP follow
    the same path through the network and those that belong to a common
    ordered aggregate are delivered in order.  For example, if
    capabilities such as equal cost multi-path (ECMP) load balancing
    which would violate this are supported, it must be possible to
    enable or disable them either entirely or selectively per LSP
    through the management plane or through control signaling and such
    features must be disabled by default.

Note that per packet ECMP is one of three ECMP method that was used
(with fairly poor results) in the 1990s.  Among the other methods that
were used were hash based methods.  Just to be clear about this the
"per packet" should be dropped.  With this wording there is also some
question as to whether composite link or LAG methods could be used or
if those are considered to fall under ECMP.  I'm just mentioning this
so that it is clear that dropping the words "per packet" was
intentional.

Also consider making uniform model optional.  The text now reads:

    Only the Pipe and Short Pipe DiffServ tunnelling and TTL processing
    models described in [RFC3270] and [RFC3443] are supported in MPLS-TP.

We have one customer who insists on the uniform model because their
clients are internal to their organization.  Though I must admit that
they don't want to hear anything about MPLS-TP.  There is no harm in
making the TTL model configurable but requiring Pipe and Short Pipe
and requiring one of these be the default.  The question remains as to
which one is the default.  The existing text does not specify.

Curtis

---

From: "tom.petch" <[email-masked]>
Date: Mon, 29 Mar 2010 17:48:09 +0200

I find parts of this hard to follow, especially the crucial s3.4.1, perhaps
because I have tracked earlier discussions and am unclear what conclusions they
reached:-(

s.3.1 uses
MPLS-TP layer network
MPLS-TP network
MPLS-TP server
MPLS-TP server layer network
in a manner that suggests they are synonyms.

As s.3.3.1 says, rather stating the obvious, MPLS-TP has a client and
has a server so when eg s.3.4.1 eg uses
" between the MPLS-TP server and the client layer"
I am unclear what layer it is referencing.  I think that you need consistent
terminology for
- the MPLS-TP layer whose framework is being described,
- the server layer providing services to it
- the client layer using services of it
I would suggest that having made clear that MPLS-TP is both client and server,
then the terms client and server are never used to refer to the MPLS-TP
layer under discussion.

Just to be clear, I use layer here to mean layer, and not a layer network as in
G.805 etc sense; of course they may be layer networks but then they may not be.

Another point I find confusing is the use of 'native service'; what is the
term intended to convey?  For me it is defined in RFC3985 and
so makes sense for a PW, but not when something else is the client
of MPLS-TP.
Tom Petch