Subject: Re: [mpls-tp] Last call coments on draft-ietf-mpls-tp-requirements-04.txt

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 09 Mar 2009 23:07:06 +0000

Adrian

On 28/02/2009 13:53, "Adrian Farrel" <[email-masked]> wrote:

> Hi,
> 
> Earlier today, some members of Old Dog Consulting's transport and
> packet teams conducted a review of draft-ietf-mpls-tp-requirements-04.

:-)

> Our requested and suggested changes are shown below.

Thanks for the comments, see below. Unless otherwise stated I have
incorporated your proposed changes.

> ===
> Requirements Language
> 
> Please delete this text. You have better language in Section 1.

I tried moving the text in section 1 to the requirements language section
but idnits complained but happy to try again.

> 1.  Introduction
> 
>    Carriers will still need to cope with legacy networks (which are
>    composed of many layers and technologies), thus the packet transport
>    network should interwork as appropriate with other packet and
>    transport networks
> 
> COMMENT: "...as appropriate..." ? Maybe just delete?

This text has been superseded with alternative text that addresses your
suggestion aswell.

> 
>    (both horizontally and vertically).  Vertical
>    interworking is also known as client/server or network interworking.
>    Horizontal interworking is also known as peer-partition or service
>    interworking.  For more details on each type of interworking and some
>    of the issues that may arise (especially with horizontal
>    interworking) see Y.1401 [ITU.Y1401.2008].
> 
> COMMENT: This section appears to announce requirements, but I don't see
> them drawn out in the document. Furthermore, I would hotly debate the
> need for horizontal interworking at a technology level.

It is not meant to be a requirement for horizontal interworking (which I
would also hotly debate whether it is required), just a statement that it is
important to ensure MPLS-TP can be smoothly introduced as a layer network in
a multi-layer network environment.

The new paragraph reads as follows FYI.

It is also important to ensure smooth interworking of the packet transport
network with other existing/legacy packet networks, and provide mappings to
enable packet transport carriage over a variety of transport network
infrastructures. The latter has been termed vertical interworking, and is
also known as client/server or network interworking. The former has been
termed horizontal interworking, and is also known as peer-partition or
service interworking. For more details on interworking and some of the
issues that may arise (especially with horizontal interworking) see G.805 &
Y.1401.
 
> ===
> 1.1.  Terminology
> 
>    Bidirectional path: A path where the forward and backward directions
>    follow the same route (links and nodes) across the network.
> COMMENT: Not comfortable with the existence of this definition.
> a. It seems redundant with  "co-routed bidirectional path"
> b. It confuses the definition of "associated bidirectional path"
> Suggest either:
> - we don't need this definition and that we need to be globally fix
>   all refs to be either co-routed or associated
> or
> - we loosen this to be a generic definition that encompasses both
>   co-routed and associated (to allow us to use the general term when
>   we don't care.

OK see your point. I have used terms co-routed bidirectional and associated
bidirectional throughout the document now.

> 1.1.  Terminology
> 
>    Co-routed bidirectional path: A bidirectional path where the forward
>    and backward directions follow the same route (links and nodes)
>    across its layer network.
> COMMENT: "...its..." ?  s/its/the same/ ?
> 
> COMMENT: This is slightly interesting because it means that if a
> bidirectional link between two adjacent nodes is made up of a
> collection (LAG, bundle, etc.) of lower layer links, there is no
> requirement for the co-routed path to use the same component links
> in both directions. Is this the intent of the definition?

The definition I have in -05 just says "across the network". I guess it
comes down to what we're defining and that's MPLS-TP. It would be sensible
for bi-directionality to be enforced down to the duct but I am not sure for
the context of this document we need to define it as such.

> 1.1.  Terminology
> 
>    could be modeled as multiple logical elements.  A layer network may
>    consist of zero or more sublayers.
> COMMENT: Trying to think of a layer that contains no sub-layers. Seems
> to me that the minimal case is that the layer is the sub-layer?

I have changed to one or more.

> 1.1.  Terminology
> 
>    Link: A physical or logical connection between a pair of LSRs that
>    are adjacent at the (sub)layer network under consideration.  A link
>    may carry zero, one or more LSPs or PWs.  A packet entering a link
>    will emerge with the same label stack entry values.
> COMMENT: Need to expand acronyms on first use. LSR, LSP, PW.

I have this covered as have now included an acronyms section above the
definitions.

> ===
> 1.1.  Terminology
> 
>    Ring Topology: In an MPLS-TP ring topology each LSR is connected to
>    exactly two other LSRs, each via a single point-to-point
>    bidirectional MPLS-TP capable data link.  A ring may also be
> COMMENT: I think, according to your definition of "link" we can strike
> the word "data".
> COMMENT: Why do we require that a ring topology is constructed from
> bidirectional links? If we allow unidirectional links, we should allow
> - unidirectional ring topology where at least one of the links is
>   unidirectional and there is connectivity around the ring in one
>   direction
> - bidirectional ring topology where all links are bidirectional and
>   there is connectivity around the ring in both directions

We could but no-one has suggested a use case for rings connected with
unidirectional links.
 
> 
> ===
> 1.1.  Terminology
> 
>    Section: A section is a server layer (which may be MPLS-TP or a
>    different technology) which provides for encapsulation and OAM of a
>    MPLS-TP transport path client layer.  A section layer may provide for
> COMMENT: "...transport path client layer..."/ ?
> "transport path in the client layer"?
> "client layer transport path"?
> "client layer"?
> "transport path"?

I have changed to client layer network.

> COMMENT: Do we mean "Section" or "Section Layer"?

We mean section layer. I have changed.

> 1.1.  Terminology
> 
>    Transport path layer: A layer network which provides point-to-point
> s/which/that/
>    or point-to-multipoint transport paths which are used to carry a
> s/which are/that may be/
>    higher (client) layer network or aggregates of higher (client) layer
>    networks, for example the transport service layer.  It provides for
>    independent OAM (of the client OAM) in the transport of the clients.
> COMMENT: Something wrong with that last sentence.

Have changed to 

It provides independent (of the client) OAM when transporting its clients.

> 1.1.  Terminology
> 
>    Transport service layer: A layer network in which transport paths are
> s/which/that/

"A layer network in that transport paths are.." doesn't make sense to me nor
does "A layer network that transport paths are..."
 
> 1.3.  Layer network overview
> 
>    A layer network will have common features in order to support the
> COMMENT: Common to what? "consistent"?
> 
>    control of forwarding, resource reservation, and OAM.  For example, a
>    layer network will have a common addressing scheme for the end points
> COMMENT: ditto

Common to itself e.g. There is no point in routing using different
addressing scheme for end points than signalling.

> ===
> 1.3.  Layer network overview
> 
>    It is sometimes useful to independently monitor a smaller domain
>    within a layer network (or the transport services as the traverse
> s/as the/that/
>    this smaller domain) but the control of forwarding or the control of
>    resource reservation involved retain their common elements.  These
>    smaller monitored domains are sublayers.
> COMMENT: Are they? Surely smaller monitored domains may be peer
> sub-domains such as routing areas, proteciotn domains, or MEs.

OK I see your point. Originally this was aimed as describing a vertical
decomposition. Can you suggest alternative text?

>    It is sometimes useful to independently control forwarding within
>    smaller domain within a layer network but the control of resource
    > s/smaller/a smaller/
>    reservation and OAM retain their common elements.  These smaller
>    domains are partitions of the layer network.
> COMMENT: That is the better definition.

Partition is horizontal to me which is fine for forwarding but doesn't also
encompass vertical decomposition for monitoring so don't think I can just
transplant sublayer for partition for your previous comment.

> ===
> 2.  MPLS-TP Requirements
> 
> COMMENT: Can you restate the scope of these requirements as applying to
> the toolkit not the implementation. I think this is repeatedly
> misunderstood, and restating it here may help it to be noticed.

OK I have inserted the following paragraph copied from the introduction

This document specifies the requirements of an MPLS Transport Profile
(MPLS-TP). The requirements are for the behavior of the protocol mechanisms
and procedures that constitute building blocks out of which the MPLS
transport profile is constructed. That is, the requirements indicate what
features are to be available in the MPLS toolkit for use by MPLS-TP. The
requirements in this document do not describe what functions an MPLS-TP
implementation supports. The purpose of this document is to identify the
toolkit and any new protocol work that is required.

> ===
> 2.1.  General requirements
> 
>    3   Mechanisms and capabilities MUST be able to interoperate, without
>        a gateway function, with existing IETF MPLS [RFC3031] and IETF
>        PWE3 [RFC3985] control and data planes where appropriate.
> COMMENT: I think it would be beneficial to expand upon "interoperate".
> It is clear to me that there is no requirement for an MPLS-TP node to
> peer (horizontally at an I-NNI) in the control plane with an MPLS node.

IMO the requirement is saying MUST have the option to apply MPLS-TP features
to existing MPLS deployed base. Also covers the case of accidental
connection of MPLS to MPLS-TP device then MPLS-TP MUST NOT be specified such
that it overloads existing control/data plane such that it breaks the
network.

Maybe replace with something like:
    3   Mechanisms and capabilities MUST be able to interoperate, without
        a gateway function, with existing IETF MPLS [RFC3031] and IETF
        PWE3 [RFC3985] control and data planes where appropriate.

        A  Mechanisms and capabilities MUST be backwardly compatible with
existing MPLS and PWE3 control and data planes where those MPLS-TP
mechanisms and capabilities are built on existing MPLS and PWE3 control/data
plane mechanisms & capabilities.

But I would like to hear others' opinion first.

> 
>    4   MPLS-TP and its interfaces, both internal and external, MUST be
>        sufficiently well-defined that interworking equipment supplied by
>        multiple vendors will be possible both within a single network,
>        and between networks.
> COMMENT: Is "network" in this context a "domain" in terms of your
> definitions?

Yes. I have s/network/domain/

>    20  A generic and extensible solution MUST be provided to support the
>        transport of one or more client layer networks (e.g.  MPLS-TP,
>        Ethernet, ATM, FR, etc.) over an MPLS-TP layer network.
> COMMENT: Are your example client layer networks delibertately packet
> technologies? Would it be valuable to list IP and MPLS in the examples?

Yes happy to include.

> 2.3.  Data plane requirements
> 
>    25  The identification of each transport path within its aggregate
>        MUST be supported.
> COMMENT: Is this *really* the requirement? It says that when you have an
> aggregate is must be possible to look inside it and identify the
> aggregated transport paths. I don't like the "deep packet inspection"
> implications! I think what you want is a reliable mechanism to perform
> deagregation back to the same transport paths with the same level of
> identification, when the end of the aggregation vessel is reached. I
> believe it is important to state our real requirements, not some
> similar requirement that might be solution-dependent.
> 
> COMMENT: "...its aggregate..." is rather non-specific. I suspect you
> are refering to an MPLS-TP aggregate, not an aggregate into another
> technology.

You are right on both counts, have changed to the following let me know if
you're happy with it

It MUST be possible for the end points of an MPLS-TP transport path that is
carrying an aggregate of client transport paths to be be able to decompose
the aggregate transport path into its component client transport paths.

>    26  A label in a particular link MUST uniquely identify the transport
>        path within that link.
> COMMENT: I think this requirement is back-to-front. We also use labels
> for other purposes on a link. That means saying something like...
> A transport path on a link MUST be uniquely identifiable by a single
> label on that link.

OK have used your text.

> COMMENT: I also think that we need to be clearer
> on which label we are refering to, and (in the context of 25) whether
> we mean the "transport path" or the "aggregate transport path", etc.

Does this still apply when using your text?

>    27  A transport path's source MUST be identifiable at its destination
>        within its layer network.
> COMMENT: This is stated as a data plane requirement. That means that
> this requirement MUST be met without recourse to the management plane or
> the control plane. I do not believe that this is a data plane
> requirement. And I think it should be removed.

Removed entirely or moved to a more appropriate section?

>    28  MPLS-TP MUST be capable of using P2MP server (sub-)layer
>        capabilities when supporting P2MP MPLS-TP transport paths (for
>        example context-specific labels [RFC5331]).
> COMMENT: I still believe that providing an example solution in the
> requirements document is wrong. Note that RFC 5331 is a solution not
> as example of a server capability. I propose to delete the example.

OK.

>    29  It MUST be possible to operate and configure the MPLS-TP data
>        (transport) plane without any IP forwarding capability in the
>        MPLS-TP data plane.
> COMMENT: I think this is a management plane and/or control plane
> requirement, not a data plane requirement. The text may be...
> The MPLS-TP data plane MUST support transmission and forwarding of
> packets with MPLS headers. No assumptions are made about the ability
> of the data plane to support forwarding of other technologies such
> as IP.

I have moved to control plane section. Management Plane is handled by Eric's
draft and should contain a similar requirement.

>    32  The intermediate nodes at each (sub-)layer MUST be aware about
>        the pairing relationship of the forward and the backward
>        directions belonging to the same bidirectional transport path.
> COMMENT: This requirement is achievable for co-routed bidirectional,
> but conflicts with the definition of associated bidirectional. Even
> if the definition were fixed, this would clearly not be achievable
> where the associated bidirecitonal LSP is diversely routed.

Have changed to only apply to co-routed bidirectional.

> 2.4.  Control plane requirements
> 
>    This section defines the requirements that apply to MPLS-TP when a
>    control plane is deployed.
> COMMENT: Suggest this has nothing to do with deployment. How about...
> 
>    This section defines the requirements that apply to an MPLS-TP
>    control plane. Note that it MUST be possible to operate an MPLS-TP
>    network without using the control plane.

OK except I used a control plane instead of the control plane.

> 2.5.  Network Management (NM) requirements
> 
>    For requirements related to NM functionality (Management Plane in
>    ITU-T terminology) for MPLS-TP, see the MPLS-TP NM requirements
>    document [I-D.gray-mpls-tp-nm-req].
> COMMENT: Have we considered that making this a normative reference means
> that this I-D cannot progrss until that one has?

What is the other option? Not include a NM section?

> 2.6.  Operation, Administration and Maintenance (OAM) requirements
> 
>    For requirements related to OAM functionality for MPLS-TP, see the
>    MPLS-TP OAM requirements document
>    [I-D.ietf-mpls-tp-oam-requirements].
> COMMENT: Ditto
> 
> ===
> 2.7.  Network performance management (PM) requirements
> 
>    For requirements related to PM functionality for MPLS-TP, see the
>    MPLS-TP OAM requirements document
>    [I-D.ietf-mpls-tp-oam-requirements].
> COMMENT: Ditto

Ditto. Ditto.

> 2.8.  Recovery & Survivability requirements
> 
>    48  MPLS-TP recovery mechanisms MUST be applicable at various levels
>        throughout the network including support for link, path segment
>        and end-to-end path, and pseudowire segment, and end-to-end
>        pseudowire recovery.
> COMMENT: Can we rewrite this in terms of the language defined in
> section 1.1? This would simplify to...
>    48  MPLS-TP recovery mechanisms MUST be applicable at various levels
>        throughout the network including support for link, segment,
>        concatenated segment, and end-to-end recovery.

Done.

>    51  The recovery mechanisms MUST operate in synergy with (including
>        coordination of timing) the recovery mechanisms present in any
>        underlying server transport network (for example, Ethernet, SDH,
>        OTN, WDM) to avoid race conditions between the layers.
> COMMENT: Isn't there a complementary requirement for recovery mechanisms
> in client networks?

I think there probably is. Have changed to "present in any client or server
transport networks"

> ===
> 2.8.1.1.  Protection
> 
>    54  MPLS-TP MUST support 1+1 protection.
> 
>        C.  Unidirectional 1+1 protection for P2P connectivity is not
>            required.
> s.not required/NOT REQUIRED/

Idnits complains at that.

>    55  MPLS-TP MUST support 1:n protection (including 1:1 protection).
> 
>        C.  Unidirectional 1:n protection for P2P connectivity is not
>            required.
> s/not required/NOT REQUIRED/
> 
>    Note: Support for extra traffic (as defined in G.870 [ITU.G870.2008])
>    is not required in MPLS-TP.
> s/not required/NOT REQUIRED/

Ditto. Ditto.

> COMMENT: I prefer that we retain the core reference within the IETF
> where possible. Extra traffic is defined in RFC4427. Is there a problem
> with that definition?

Nope have changed the reference.

> 2.8.1.3.  Sharing of protection resources
> 
>    60  MPLS-TP MUST support the sharing of protection bandwidth by
>        allowing best effort traffic.
> COMMENT: I assume that this means that the best effort traffic uses
> the proteciton resources when they are not carrying protected traffic.
> If so, how is this different from "extra traffic" that we have classed
> as "not required" in section 2.8.1.1?
> But perhaps it means that the protected traffic will only be delivered
> as best effort after a failure. If so, this is defining a protection
> class.

OK have deleted the requirement as I believe it is the former.

>    62  MPLS-TP MUST support sharing of protection resources such that
>        protection paths that are known not to be required concurrently
>        can share the same resources.
> COMMENT: How does this differ from the requirement for shared mesh
> restoration in requirement 59?

I guess it also applies to sharing of protection resources that are not
meshed.

> 2.8.2.  Triggers for protection, restoration, and reversion
> 
>    68  There MUST be a mechanism to allow administrative recovery
>        actions to be distinguished from recovery actions initiated by
>        other triggers.
> COMMENT: Distinguished where in the network, when, and by whom?

No idea. I don't recall the history of this requirement. Comments from
others?

> "The passive voice is to be avoided"

> 2.8.5.1.  Ring protection
> 
>    Within the context of recovery in MPLS-TP networks, the optimization
>    criteria considered in ring topologies are as follows:
> 
>    d.  Minimize the amount of management plane transactions during a
>        maintenance operation (e.g., ring upgrade) - less than are
>        required by other recovery mechanisms.
> COMMENT: Is there no equivalent optimization of control plane?

Have changed to "control & management plane"

>    105  Prioritization of critical services.
> COMMENT: I believe this is open to be misconstrued.
> 1. Who cares whether the service is critical?
> 2. What does "prioritization" actually mean? Is it priority of
> access to resources?

Agree. It is covered by the requirement above on support for differentiated
services so I have deleted it.

>    For a description of the security threats relevant in the context of
>    MPLS and GMPLS and the defensive techniques to combat those threats
>    see the Security Framework for MPLS & GMPLS Networks
>    [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework].
> COMMENT: Will that document be updated with specific MPLS-TP
> considerations? If so, I haven't seen any move to start that work.
> If not, we should start a separate I-D for MPLS-TP security.

No idea.

> COMMENT: The security I-D should be a normative reference if the
> requirements it contains are requirements for MPLS-TP.

OK.

> ===
> 6.2.  Informative References
> COMMENT: A good number of these references are normative as they define
> terms and ideas that are necessary to the understanding of this I-D.
> 
>    [RFC3031]
>    [RFC3985]
>    [RFC4139]
>    [RFC4258]
>    [RFC4427]
>    [I-D.draft-ietf-mpls-mpls-and-gmpls-security-framework]

OK

Ben

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Mar 2009 00:05:20 -0000

Sorry,

This got lost in an avalanche.

I believe you have addressed my points with the textual changes you 
suggested.

A few trivial clarifications below.

> addressing scheme for end points than signalling.

I think the word is "consistent"

> Removed entirely or moved to a more appropriate section?

Happy with either of those.
Or, add to this, "in coordination with the management plane or control 
plane"

> What is the other option? Not include a NM section?

Make it Informative (and hope the AD doesn't notice).

> Idnits complains at that.

Really?
Damn 2119.
We should find some suitable 2119 language.
I think it is...

        C.  Unidirectional 1+1 protection for P2P connectivity is not
            required and MAY be omitted from the MPLS-TP
            specifications.

>>    55  MPLS-TP MUST support 1:n protection (including 1:1 protection).

 Ditto.

>> requirements it contains are requirements for MPLS-TP.

I suggest *Loa* we need an MPLS-TP Security I-D.
The referenced document is great, but is on its way without waiting for 
MPLS-TP.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 16 Mar 2009 09:22:51 -0000

Adrian/Ben.....some minor comments to try and help a bit....use as you
see fit, but a bit more explanation might help others understand what is
really meant by some of the more obscure requirements that are given:

<snipped from Adrian to Ben 16 March 2009 00:05>

> Or, add to this, "in coordination with the management plane 

NH=> You are quite right Adrian that the CP/MP must know about a
connection (wrt its source, destination(s) and connection entity
identifiers per se...and other things like its survivability priority
vis-a-vis other connections in the network), but the key point here that
I think Ben is trying to make is that SA information is implicit
information that is carried by the connection entity itself in the DP
*provided* it respects the 1st rule of a connection which is 'single
source'.

This is why the (child) traffic units of a (parent) connection have no
need to carry SA information as labels...the only labels they must carry
are those that have been allocated to *uniquely identify this end-end
connection entity on each of its link connections* for *forwarding
purposes*.

This all follows because a connection is a constraining construct for
traffic (and OAM) under defect-free conditions.  However, under
misconnectivity defects the connection can no longer be assumed to be a
constraining construct, so the short-cuts one can take on normal
defect-freee labelling must now be augmented with a CV OAM flow that
does include the true (absolute) SA of the connection.

Of course, one could include this SA information in the (child) traffic
units if one wanted to (this is what PBB-TE does).  And the advantage of
this is that the network clients are now protected against leaking
traffic due to misconnectiovity defects without the operator having to
run any CV OAM flows at all (in effect one is incorporating the CV
function in all traffic units).

When the SA information is not carried in the traffic units then a CV
OAM flow *should* be run on *all* connections in the network in order to
protect clients from leaking traffic....as one cannot predict a priori
where and which connections could be affected.

<snipped>

> The referenced document is great, but is on its way without 

NH=> I think the above point on OAM is germane to any security section
on MPLS-TP requirements or indeed (and more generally)
draft-ietf-mpls-mpls-and-gmpls-security-framework.  We can have security
breaches from both malicious attack and the unfortunate effects of
misconnectivity defects.  Last time I looked at
draft-ietf-mpls-mpls-and-gmpls-security-framework it really only
considered the former.

regards, Neil

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 16 Mar 2009 09:55:05 -0000

Neil,

[SNIP]

>>>>    27  A transport path's source MUST be identifiable at
>>>>     its destination within its layer network.
>>>> COMMENT: This is stated as a data plane requirement. That
>>>> means that this requirement MUST be met without recourse
>>>> to the management plane or the control plane. I do not
>>>> believe that this is a data plane requirement. And I think it
>>>> should be removed.
>>>
>> Or, add to this, "in coordination with the management plane
>> or control plane"
>

[SNIP]

Neil, you are right. Good descrption follows on why and how this implicit 
nature is fundamental.

But what is the *requirement*? That is, what is the balck box behaviour we 
require from MPLS-TP?

BTW

> connection entity on each of its link connections* for *forwarding

Careful with that definition!
If the identification is for forwarding purposes *only* then flow merging is 
just fine. And I don't think we want that.

> draft-ietf-mpls-mpls-and-gmpls-security-framework it really only

The draft does now explicitly cover the misconfiguration/misconnection as 
well.

Cheers,
Adrian

---

From: <[email-masked]>
Date: Mon, 16 Mar 2009 10:57:20 -0000

Thanks Adrian

Snipped a little:
Adrian wrote 16 March 2009 09:55
> But what is the *requirement*? That is, what is the balck box 

NH=> I think this where a good definition of what transparency means
might be useful, as it quite generic ('black-box') in nature, and
something that a transport network should provide to its clients, ie:
-	the server layer treats all client symbols equally (in other
words it does not try and guess things like the urgency (delay) and the
Importance (survivability) requirements of each communications instance
within a possibly huge aggregate of message/file/stream applications
that reside in some ultimate top-of-stack layer network...which might
indeed be several levels up)
-	the server preserves the symbol ordering of its clients
-	the server does not try and guess the meaning of client symbols
and never changes them
-	and (from performance inheritance considerations) the server
should ensure that the traffic behaviour of client X cannot impact the
performance experienced by client Y

Do you think that might fit the bill?

> just fine. And I don't think we want that.
NH=> I think its OK as long as it is understood that link connection
forwarding labels are unique to each connection....but I do understand
what you are hinting at here.
> misconfiguration/misconnection as 
NH=> That's good to know...thanks.

regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 17 Mar 2009 00:13:37 +0000

Adrian,

> But what is the *requirement*? That is, what is the balck box behaviour we

It is useful from an operations & fault finding perspective to know what the
other end of a connection is supposed to be.

This could be from OAM protocol perspective - i.e. Router tells operator it
is receiving traffic from a source it shouldn't be.

It could also be a manual (i.e. Operator driven) perspective - i.e. Operator
knows where he thinks his connections are going and needs to know what the
network thinks and do they align, e.g. Customer says no connectivity so
operator checks egress MPLS-TP router to see what its expecting to receive
as part of fault finding.

Ben

---

From: <[email-masked]>
Date: Tue, 17 Mar 2009 08:12:49 -0000

Ben,

I think Adrian was trying to find a good technology agnostic (ie
'black-box') definition of the key requirement of a *transport

> > But what is the *requirement*? That is, what is the balck 

After some thought on this I believe the right answer is to take a
systems approach (which is exactly what Andy Reid has done in G.800) and
define what client/server transparency means (which BTW has the
requirement that a connection only have a single source implicit in its
definition).  So in my response to Adrian/yourself I offered this
definition of transparency:

Transparency is the primary service requirement of the clients of a
transport network like MPLS-TP.  Transparency is defined in G.800, but a
good working definition is:
-	the server layer treats all client symbols equally (in other
words the serving transport network does not try and guess things like
the Urgency (delay) and the Importance (survivability) requirements of
each communications instance within a possibly huge aggregate of
message/file/stream applications that reside in some ultimate
top-of-stack layer network...which might indeed be several levels up
from this transport network instance)
-	the server preserves the symbol ordering of its clients
-	the server does not try and guess the meaning of client symbols
and never changes them
-	and (from performance inheritance considerations) the server
should ensure that the traffic behaviour of client X cannot impact the
performance experienced by client Y

Do you think we can add something like this to the MPLS-TP requirements
draft?

regards, Neil

> -----Original Message-----
> From: Niven-jenkins,B,Ben,DMF R 
> Sent: 17 March 2009 00:14
> To: Adrian Farrel; Harrison,N,Neil,CXM R; [email-masked]
> Subject: Re: [mpls-tp] Last call coments 
> ondraft-ietf-mpls-tp-requirements-04.txt
> 
> Adrian,
>