Subject: [Mpls-interop] Comments on MPLS-TP-Requirements

From: George Swallow <[email-masked]>
Date: Thu, 15 Jan 2009 16:32:21 -0500

I have some comments on the requirements draft.

Terminology. 

Layer network

>From G.805 - layer network: A "topological component" that represents the
complete set of access groups of the same type which may be associated for
the purpose of transferring information (see 5.2.1.1).

Now if this applies to the entire MPLS-TP nework of a single provider, then
this is fine, but we need to add the clarification.

But in reading through G.805 it is not clear to me whether applying this
term to MPLS-TP applies to the whole network or to the set of tunnels that
are stacked to a particular depth.

This term seems to date back to the well defined hierarchies of PDH/SDH/ATM.
See section 6 of G.805. For example VC/VP are two layers in ATM.  In MPLS-TP
the layering is only defined by how deeply nested
otherwise-identical-elements are.  Every node operates on the top-of-stack
label (perhaps pushing or popping and then operating on a new top-of-stack
label).  Since most any node could handle many different layers, I fail to
see the identifiable "topological component".  The only thing that is
readily identifiable here is the number of labels in the MPLS stack and
which of those labels are being processed at a given node on a given
connection(s).

I find the term unintuitive and misleading.  I would like to see it
clarified or eliminated.

Requirement 9 - It is not clear what this requirement actually requires.
Particularly for those of us who have limited experience with other
transport networks.  This req. needs to be expanded or removed.

Requirement 13 - s/taken/taking

Requirement 16 - I agree with note on D.

Requirement 17 - Pretty vacuous - ought to be dropped.

Requirement 20 - is this talking about carrier's carrier or nested tunnels?

Requirement 22 - this should be limited to non-shared-media networks.

Requirement 25 - does this, taken with req 20, imply that we need to allow
for separate addresses depending where in the label-stack we are?

Requirement 29 -  it is not clear to me what this requirement is for.  For
statically configured things, there is really no concept of upstream or
downstream assigned.  For things that are signaled in may in some cases be
useful to allow upstream assignment.  Would this requirement mean that for
the cases where upstream assignment was natural, that we would Require a
second solution that used downstream instead?  I suggest removing the
requirement.

Requirement 32 - Why is this "MUST require" congruency?  Isn't "MUST
support" enough?

Requirement 39 - this is a little vague.

Requirement 47 - vague, unmeasureable, (and probably harmless).

Requirement 55, 56 - do we have two default behaviors???  Or is 56 A a
copy/paste error?

Requirement 61 - does not apply to uni P2MP.  Does this rule out UPSR for
P2P? (Or is UPSR considered a higher layer construct).

Requirement 76 - please add definitions for these four terms

_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 16 Jan 2009 09:51:14 -0600

George,

	See somments in-line below... 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of George Swallow
Sent: Thursday, January 15, 2009 4:32 PM
To: [email-masked]; Ben Niven-Jenkins
Subject: [Mpls-interop] Comments on MPLS-TP-Requirements

Terminology. 

Layer network

>From G.805 - layer network: A "topological component" that represents
the
complete set of access groups of the same type which may be associated
for
the purpose of transferring information (see 5.2.1.1).

Now if this applies to the entire MPLS-TP nework of a single provider,
then
this is fine, but we need to add the clarification.

But in reading through G.805 it is not clear to me whether applying this
term to MPLS-TP applies to the whole network or to the set of tunnels
that
are stacked to a particular depth.

This term seems to date back to the well defined hierarchies of
PDH/SDH/ATM.
See section 6 of G.805. For example VC/VP are two layers in ATM.  In
MPLS-TP
the layering is only defined by how deeply nested
otherwise-identical-elements are.  Every node operates on the
top-of-stack
label (perhaps pushing or popping and then operating on a new
top-of-stack
label).  Since most any node could handle many different layers, I fail
to
see the identifiable "topological component".  The only thing that is
readily identifiable here is the number of labels in the MPLS stack and
which of those labels are being processed at a given node on a given
connection(s).

====================================BEGIN===============================
==
EG

For MPLS networks in general, the notion of a layer network as defined
by
G.805 is very abstract.  For use of MPLS as a transport in the sense of 
PDH/SDH/SONET/ATM, however, this is an important concept to come to
grips
with.

If we're going to define a "transport profile" for use of MPLS as a form
of replacement technology, then we need this concept because - in that
context - services are defined over a particular network layer.  A lower
layer may provide services to a higher layer, but all services for any
given service context are defined for a single layer (which I believe is
exactly the concept that the term "Layer Network" is trying to address).

Clarification is a good idea; elimination is not.
=====================================END================================
==

====================================BEGIN===============================
==
EG

If you are referring to General Requirement number 9, the meaning is 
fairly clear.  To paraphrase, the logical/abstract entities that are
defined in an MPLS-TP context to satisfy roles corresponding to like
entities in a Generic Transport context, would ideally be manageable
in a manner that does not require a complete paradigm shift for those
people who are already managing Transport Networks (i.e. - via the
same or similar management systems, using similar management objects,
interacting in a similar way). 
=====================================END================================
==

====================================BEGIN===============================
==
EG

Again, clarification might be in order but elimnation is a bad idea.

Scaling requirements are an essential part of defining protocols and
interactions that will not require fork-lift system replacements as
the character, usage and mix of services gets more complicated.  If
we do not define scaling requirements, then we are missing important
criteria for determining the suitability of the transport profile.

However, as is, this requirement is a little like motherhood, apple
pie and puppies.
=====================================END================================
==

Requirement 20 - is this talking about carrier's carrier or nested
tunnels?

====================================BEGIN===============================
==
EG

If it were me you were asking, the answer would be "yes."
=====================================END================================
==

====================================BEGIN===============================
==
EG

Why?
=====================================END================================
==

Requirement 25 - does this, taken with req 20, imply that we need to
allow
for separate addresses depending where in the label-stack we are?

====================================BEGIN===============================
==
EG

This seems intuitively obvious to me, so I must be missing something. If

you view a transport network as service layers, isn't it obvious that we
need to define separation of addressing at each layer?  Is this not the
very reason why we define the concept of layer networks?
=====================================END================================
==

Requirement 29 -  it is not clear to me what this requirement is for.
For
statically configured things, there is really no concept of upstream or
downstream assigned.  For things that are signaled in may in some cases
be
useful to allow upstream assignment.  Would this requirement mean that
for
the cases where upstream assignment was natural, that we would Require a
second solution that used downstream instead?  I suggest removing the
requirement.

====================================BEGIN===============================
==
EG

I don't see how this requirement implies that downstream label
assignment
is the only allowed approach.  The requirement simply says that MPLS-TP
(as a solution) MUST support it.  The requirement is silent on what else
should be, could be, or might be supported in terms of label assignment.

The requirement goes on to say that MPLS-TP MAY also support labels that
are context specific, but neither requires this nor implies that another
approach might not also be used.

Note that your comment about static configuration would be good, if we
had
any serious intention of proposing an MPLS-TP solution that only
supports
static configuration.
=====================================END================================
==

====================================BEGIN===============================
==
EG

Not really.  The solution should allow the operator to compel
congruency.

I agree that there may be cases in which both operators and vendors
might
find desirable advantages of asymmetric paths, but the transport network
operator must be able to force MPLS-TP compliant equipment to establish
symmetric (congruent) paths.  And it seems to me that this should be a
feature that must be explicitly turned off if it is unwanted.
=====================================END================================
==

====================================BEGIN===============================
==
EG

That is probably because the term "integrity" carries well known freight

in many contexts, including transport networks.  This should be expanded
to clarify the meaning of the requirement.
=====================================END================================
==

====================================BEGIN===============================
==
EG

This directly relates to requirement 9.  In the same sense that it is an
important goal to not require a new paradigm for management, it's
equally
important not to require a new paradigm for control of transport
networks
(this could be clarified quite a bit).
=====================================END================================
==

====================================BEGIN===============================
==
EG

These requirements are not defining default behavior; they define what
the MPLS-TP MUST support.  What an operator elects to use is up to them
and may not even be consistent on a per-operator or per-network basis.
However, the capabilities need to be supported by the MPLS-TP solution
if the operator is to have the choice at all.
=====================================END================================
==

Requirement 61 - does not apply to uni P2MP.  Does this rule out UPSR
for
P2P? (Or is UPSR considered a higher layer construct).

====================================BEGIN===============================
==
EG

What this requirement is about is maintaining path congruency.  Perhaps
it
would be best worded accordingly?  In other words, if protection
activity
preserves path congruency, then restoration should as well.  Again, for
a
majority of cases, preserving path congruency is a goal and a decision
to
not do so should be an explicit one.
=====================================END================================
==

====================================BEGIN===============================
==
EG

These are extremely well understood terms in transport networking.  Like
many cases where tersm have been used consistently in an industry for a
very long time, it may be difficult to find a formal definition in one 
place that everyone agrees is authoritative.

But their meaning is intuitive.  Lockout means making a path
operationally
unavailable, the difference between forced and manual switchover is
manual 
depends on the actual availability of the path to which a service is
being 
switched, and a simulated fault is a means for manually inducing a fault

indication as a means of testing protection.

There is a pretty good discussion of the meaning of (most of) these
terms 
at: 

http://www.ciscosystems.co.nz/univercd/cc/td/doc/product/mels/15530/12_2
_sv/config2/hcg_aps.htm#wp1032650

You may have seen it before.  :-)

I suggest adding them to the terminology section and capitalizing them
in
this requirement.
=====================================END================================
==

---

From: "Malis, Andrew G. (Andy)" <[email-masked]>
Date: Fri, 16 Jan 2009 12:15:14 -0500

I have some additional comments on both George and Eric's comments, also
inline. I edited out comments where I did not have anything additional
to add.

Cheers,
Andy

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Friday, January 16, 2009 10:51 AM
To: George Swallow; [email-masked]; Ben Niven-Jenkins
Subject: Re: [Mpls-interop] Comments on MPLS-TP-Requirements

George,

-----Original Message-----

Terminology. 

Layer network

Grips with.

>Andy: I agree with Eric. Perhaps we can define Layer Network as Eric
suggests in terms of the services provided to a higher layer. Thus (to
respond to George's point), a particular physical network element may
topologically belong to more than one layer network, depending on the
actions it takes on the label stack, and thus could be modeled as
multiple logical elements.

Andy> I also agree with Eric here, although I think I would have used
the word "similar" rather than "coherent".

Andy> The genesis of this requirement is obvious - previous generations
of transport specs (especially involving rings) weren't sufficient to
ensure multi-vendor interoperability. So perhaps this requirement could
be re-written as a general requirement (and moved out of 16D to a
top-level requirement) that MPLS-TP needs to be sufficiently well
specified to ensure multi-vendor interoperability. While that also seems
like motherhood and apple pie (like the next requirement), obviously it
wasn't sufficiently obvious in previous transport specs.

Andy> Again, I agree that motherhood and apple pie are good things and
it certainly doesn't hurt to spell out what may be obvious to us but
perhaps not to all readers.

Andy> I agree. Just as an editorial comment, this requirement needs to
ended with a ".".

Why?

Andy> Vendors have been beginning to ask Verizon to list the media
networks where we would like to see MPLS-TP supported. So to make life
easier for everyone, we may wish to actually enumerate the required
media networks in this requirement. For Verizon, this list starts with
OTN G.709, SONET/SDH GFP, and point-to-point Ethernet. We don't see a
general requirement for MPLS-TP transported over shared Ethernet or
other shared media networks, but that's just us. I would like to hear
from other providers here as well, and I could perhaps be persuaded to
consider shared networks as well, but as this time I don't see the
requirement.

Andy> Verizon absolutely requires that bidirectional paths be congruent.
If we don't care about congruency, we'll use unidirectional paths in
each direction.

Andy> For VZ, this means that the MPLS-TP layer network must be able to
support end-to-end integrity - it must not depend on the media network
and physical switches.

Cheers,
Andy

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 19 Jan 2009 15:38:53 +0000

George,

> this is fine, but we need to add the clarification.

It applies to an entire MPLS-TP network.  That network may consist of a
single provider or multiple providers.  E.g. The Internet is a single layer
network consisting of multiple sub-networks operated by different providers.

> are stacked to a particular depth.

Yes, this can get a bit confusing.  Label stack depth in MPLS is
sub-layering in G.805 terminology.  In other words each set of tunnels that
are stacked to a particular depth do not form their own MPLS-TP layer
network, they form part of an overall MPLS-TP layer network that consists of
all LSP at any depth within the MPLS-TP layer network.

In more understandable (I hope) but oversimplified terms.  If each set of
tunnels at a given stack depth were a separate layer network then they would
need to be functionality independent of the other stack depths, e.g. They
would require their own MP & CP at that depth. MPLS does not do that it uses
a common CP/MP across all stack depths within a single MPLS layer network.

> I find the term unintuitive and misleading.  I would like to see it

Let's try ad clarify this week along with your other comments.

Ben