Subject: [Mpls-interop] next MEAD team meeting

From: Loa Andersson <[email-masked]>
Date: Thu, 19 Jun 2008 17:00:21 +0200

All,

the MEAD team will have the next meeting on Tuesday 24, at 6pm
i.e. 12am east coast and 9am California.

Again I plan the meeting to last an hour, and focus will be on the
document status.

Stewart will send out dial in details as usual.

/Loa

-- 
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  [email-masked]
                                            [email-masked]
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 Jun 2008 18:20:54 +0100

Colleagues,

FYI see attached for the latest draft of the MPLS-TP requirements draft.

Ben

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 19 Jun 2008 14:11:11 -0400

Colleagues,

I was thinking for the requirements we should include a sentence in the
abstract to scope the MPLS-TP work as being part of a joint ITU-IETF
effort. Not all readers (now and future) will be aware of why this is
being done. In ccamp, we had done this for our ASON work. Maybe a
similar sentence will be needed in the other documents? Should we have a
common sentence?

How about for the abstract:
This document summarizes the ITU-T requirements for MPLS-TP in order to
support capabilities and functionalities as needed by the ITU-T. It does
not address IETF protocol applicability or capabilities. This document
is a product of a joint ITU-IETF effort.

Deborah  

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Thursday, June 19, 2008 1:21 PM
To: Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] next MEAD team meeting

Colleagues,

Ben

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Thu, 19 Jun 2008 21:09:41 +0200

Hi Deborah,

I have a few comments regarding the proposed abstract:

*         I think we should say "This document specifies the
requirements for MPLS-TP in order to support capabilities and
functionalities as needed in transport environments (or networks).

*         I do not understand the sentence: It does not address IETF
protocol applicability or capabilities. Do you mean applicability or
capability of the current IETF documents? As IMO it will be of the
documents we generate for MPLS-TP. 

*         I think it is important to indicate that " This document is a
product of a joint ITU-IETF effort".

Best regards,

Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext BRUNGARD,
DEBORAH A, ATTLABS
Sent: Thursday, June 19, 2008 21:11
To: MEAD team
Subject: Re: [Mpls-interop] next MEAD team meeting

Colleagues,

common sentence?

Deborah  

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

Colleagues,

Ben

[email-masked]

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Thu, 19 Jun 2008 16:04:08 -0400

Hi Nurit,
 
I would prefer to clearly say the requirements are ITU requirements for
MPLS in a transport environment. I think among some operators the line
between transport equipment and packet equipment has already blurred.
For many operators, the preference may be to align with MPLS operations
vs. transport. I think there are many differing opinions on what
MPLS/packet transport needs to support in a transport environment. So I
prefer to clearly say these are ITU requirements, they do not
necessarily reflect the operators contributing to this document.
 
On the 2nd bullet,  the requirements document has many
statements/requirements which may be interpreted by a reader as gaps in
MPLS/IETF protocols. I was trying to say with this sentence the document
is not addressing/identifying IETF protocol applicability or lack of
capabilities e.g. the sentence:
"Quality-of-service mechanisms are required in the packet transport
   network to ensure the prioritization of critical services, to
   guarantee BW and to control jitter and delay."

QoS is not a new requirement for IETF protocols. Packet transport
networks (and this requirement document) are not the first time that QoS
mechanisms are identified as needed. This requirement is not intending
to identify a gap in the current IETF protocol set. This was what I was
trying to say.
 
Suggestions?
Deborah

________________________________

From: Sprecher, Nurit (NSN - IL/Israel - MiniMD)
[mailto:[email-masked]] 
Sent: Thursday, June 19, 2008 3:10 PM
To: BRUNGARD, DEBORAH A, ATTLABS; MEAD team
Cc: Sprecher, Nurit (NSN - IL/Israel - MiniMD)
Subject: RE: [Mpls-interop] next MEAD team meeting

Hi Deborah,

Best regards,

Nurit

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

Colleagues,

common sentence?

Deborah  

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

Colleagues,

Ben

[email-masked]

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Fri, 20 Jun 2008 10:47:52 +0200

Hi Deborah,
I understand the intention, so how about the following (as we also
indicated in the introduction):
This document specifies the ITU-T requirements for MPLS-TP in order to
support capabilities and functionalities of MPLS as needed in transport
environments. 
MPLS is a maturing packet technology and it is already playing an
important role in transport networks and services. However, not all of
MPLS's capabilities and mechnisms are needed and/or consistent with
transport network operations. This document identifies the required
capabilities for MPLS so that it can better fit a transport role.
Please advise.
Best regards,
Nurit

From: ext BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
Sent: Thursday, June 19, 2008 23:04
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); MEAD team
Subject: RE: [Mpls-interop] next MEAD team meeting

Hi Nurit,

 
Suggestions?
Deborah

Hi Deborah,

Best regards,

Nurit

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

Colleagues,

common sentence?

Deborah  

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

Colleagues,

Ben

[email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Fri, 20 Jun 2008 10:56:34 +0200

All,

just a few comments.

Sprecher, Nurit (NSN - IL/Israel - MiniMD) wrote:
> This document specifies 

I wonder if "specifies" is the right word - one way would be to say
"validates" indicating that this how we (IETF) understands these
requirements

the ITU-T requirements for MPLS-TP in order to
> support capabilities and functionalities of MPLS as needed in transport

this indicates that there is nothing but ITU-T requirements in the
document, is that true?

/Loa

> ------------------------------------------------------------------------
> 

-- 
Loa Andersson

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Fri, 20 Jun 2008 11:22:49 +0200

Hi, 
1. I agree that validates may be a good option.
2. IMO, these requirements are not only the ITU-T view. I got these
requirements from different SPs. As I indicated in the beginning of the
mail exchanges I would prefer to say: "This document specifies the
requirements for MPLS-TP in order to support capabilities and
functionalities as needed in transport environments (or networks)." But
this is something that we need the SPs to agree on. 
Please note also that in the proposal just below I forgot to include the
indication that this is a joint work of ITU-T and IETF. 
Best regards,
Nurit

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Friday, June 20, 2008 11:57
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD)
Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team
Subject: Re: [Mpls-interop] next MEAD team meeting

All,

just a few comments.

> support capabilities and functionalities of MPLS as needed in 
> transport environments.

/Loa

> I would prefer to clearly say the requirements are ITU requirements 
> for MPLS in a transport environment. I think among some operators the 
> line between transport equipment and packet equipment has already
blurred.
> For many operators, the preference may be to align with MPLS 
> operations vs. transport. I think there are many differing opinions on

> what MPLS/packet transport needs to support in a transport 
> environment. So I prefer to clearly say these are ITU requirements, 
> they do not necessarily reflect the operators contributing to this
document.
> statements/requirements which may be interpreted by a reader as gaps 
> in MPLS/IETF protocols. I was trying to say with this sentence the 
> document is not addressing/identifying IETF protocol applicability or 
> lack of capabilities e.g. the sentence:
> networks (and this requirement document) are not the first time that 
> QoS mechanisms are identified as needed. This requirement is not 
> intending to identify a gap in the current IETF protocol set. This was

> what I was trying to say.
>  
> Suggestions?
> Deborah
>  
>  
> 
> similar sentence will be needed in the other documents? Should we have

> a

--
Loa Andersson

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Fri, 20 Jun 2008 10:06:54 -0400

Hi,

Thanks Loa for the hint. My understanding of the charter was to capture
the ITU requirements?

What is the MEAD development work covering - both ITU requirements and
"other (anonymous) SPs requirements"?

Deborah 

-----Original Message-----
From: Sprecher, Nurit (NSN - IL/Israel - MiniMD)
[mailto:[email-masked]] 
Sent: Friday, June 20, 2008 5:23 AM
To: ext Loa Andersson
Cc: BRUNGARD, DEBORAH A, ATTLABS; MEAD team; Sprecher, Nurit (NSN -
IL/Israel - MiniMD)
Subject: RE: [Mpls-interop] next MEAD team meeting

Hi, 

-----Original Message-----
From: ext Loa Andersson [mailto:[email-masked]] 
Sent: Friday, June 20, 2008 11:57
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD)
Cc: ext BRUNGARD, DEBORAH A, ATTLABS; MEAD team
Subject: Re: [Mpls-interop] next MEAD team meeting

All,

just a few comments.

/Loa

blurred.

document.

--
Loa Andersson

---

From: Loa Andersson <[email-masked]>
Date: Fri, 20 Jun 2008 19:24:35 +0200

> Thanks Loa for the hint. My understanding of the charter was to capture

yes - that is true...

but we also need to capture all requirements for the MPLS-TP whether
they are in the captured by the ITU-T or not.
> "other (anonymous) SPs requirements"?

if there is "only" requirements that originates from ITU-T this is
not a problem. I am not looking for anonymous requirements, if there
is a requirement that is not from ITU-T we should make clear where it
came form

/Loa

-- 
Loa Andersson

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 20 Jun 2008 14:38:08 -0400

Comments on the document inline start with "TOM:"
In general, please review the document and put more of an emphasis on the
use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on requirements
documents that are too optional.

    --Tom

Network Working Group                              B. Niven-Jenkins, Ed.
Internet-Draft                                                        BT
Intended status: Informational                          D. Brungard, Ed.
Expires: January 2, 2009                                            AT&T
                                                           M. Betts, Ed.
                                                         Nortel Networks
                                                             N. Sprecher
                                                  Nokia Siemens Networks
                                                           July 01, 2008

                          MPLS-TP Requirements
               draft-jenkins-mpls-mplstp-requirements-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 2, 2009.

Abstract

   This document will outline the requirements for MPLS-TP.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 1]

Internet-Draft            MPLS-TP Requirements                 July 2008

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  MPLS-TP Requirements . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  General requirements . . . . . . . . . . . . . . . . . . .  5
     2.2.  Layering requirements  . . . . . . . . . . . . . . . . . .  6
     2.3.  Data plane requirements  . . . . . . . . . . . . . . . . .  7
     2.4.  Control plane requirements . . . . . . . . . . . . . . . .  8
     2.5.  Network Management (NM) requirements . . . . . . . . . . . 11
     2.6.  OAM requirements . . . . . . . . . . . . . . . . . . . . . 11
     2.7.  Network performance management (PM) requirements . . . . . 11
     2.8.  Protection & Survivability requirements  . . . . . . . . . 12
     2.9.  QoS requirements . . . . . . . . . . . . . . . . . . . . . 14
     2.10. Security requirements  . . . . . . . . . . . . . . . . . . 15
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   6.  Informative References . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 2]

Internet-Draft            MPLS-TP Requirements                 July 2008

1.  Introduction

   For many years, SONET/SDH has provided service providers with a high
   benchmark for reliability and operational simplicity.  With the
   accelerating growth of packet-based services (such as Ethernet, VoIP,
   L2/L3 VPN, IPTV, RAN backhauling, etc.), service providers are in
   need of capabilities to efficiently support packet-based services on
   their transport networks.  The need to increase their revenue while
   remaining competitive forces operators to look for the lowest network
   Total Cost of Ownership (TCO).  Investment in both Capital
   Expenditure (CAPEX) and Operational Expense (OPEX) should be minimal.

   Carriers are considering migrating to packet transport networks in
   order to reduce their costs and to improve their ability to support
   services with guaranteed SLAs.  Migrating from SONET/SDH to packet
   transport networks should not involve dramatic changes in network
   operation, should not necessitate extensive retraining, and should
   not require major changes to existing work practices.  The aim is to
   preserve the look-and-feel to which carriers have become accustomed
   in deploying their SONET/SDH networks, while providing common, multi-
   layer operations, resiliency, control and management for packet,
   circuit and lambda transport networks.

   An important attribute of a transport network is its ability to
   function independently from both its client and server (transmission
   media) layer networks.  It should be capable of transmitting over any
   media.  Another key characteristic of transport networks is the
   capability to maintain the integrity of the client signal between its
   ingress and egress ports.

TOM: I would use something other than "client signal" here. Something like
"client path" or something is what I think you mean.

A transport network must provide the means
   to commit quality of service objectives to clients.  This is achieved
   by providing a mechanism for client network service demarcation for
   the network path together with an associated network resiliency
   mechanism.  A transport network must also provide a method of service
   monitoring in order to verify the delivery of an agreed quality of
   service.  This is enabled by means of carrier-grade OAM tools.

   The connectivity service is the basic service provided by a transport
   network. 

TOM: Is it? Does the transport really provide connections or does it provide
transport paths?  I am sensitive to the terms used here. We don't want this
to become a connect-fest. Seems to me that you explain this better in the
next sentence anyhow.

 The purpose of a transport network is to transparently
   carry client signals (i.e. the stream of client PDUs or client bits)

TOM: Again, I don't like the term "signals" here. Use "client data" or
something.

   between endpoints in the network (typically over several intermediate
   nodes).  These endpoints may be service switching points or service
   terminating points.  The connectivity services offered to customers
   are aggregated into large, long-holding time pipes/trunks which

TOM: Do you really mean to call these "time pipes"?  Sounds too futuristic
even for this work. *)  I think you mean "...into relatively large,
long-lasting paths..."

   enable the efficient and reliable operation of the transport network.
   These trunks are modified infrequently.

TOM: Keep the terminology consistent here too. There is the use of "trunks",
"pipes", etc...

   Aggregation and hierarchy are beneficial for achieving scalability
   and security since:

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 3]

Internet-Draft            MPLS-TP Requirements                 July 2008

   1.  They reduce the number of provisioning and forwarding states in
       the network core.

   2.  They reduce load and the cost of implementing service assurance
       and fault management.

TOM: Do they really reduce load? This is one of those fluffy, open-ended
terms like "scaleability" that I don't like used unless it is clearly
defined. 

   3.  Client signals are completely encapsulated and isolated from each
       other.  This also allows complete isolation of customer traffic
       from carrier operations.

TOM: Does this really happen at the data or control plane or both? Or do we
care?

   Client signals are first transparently encapsulated.  These
   encapsulated client signals are then aggregated for transport through
   the network in order to optimize network management.  Server layer
   OAM is used to monitor the transport integrity of the client layer
   aggregate.  At any hop, the aggregated signals may be further
   aggregated in lower layer transport network paths for transport
   across intermediate shared links.  The encapsulated client signals
   are extracted at the edges of aggregation domains, and are either
   delivered to the client or forwarded to another domain.  In the core
   of the network, only the server layer aggregated signals are
   monitored; individual client signals are monitored at the network
   boundary in the client layer network.

TOM: I am not sure the above is appropriate for a requirements document. It
sounds like you are spelling out an algorithm for how a solution should
work.

   Quality-of-service mechanisms are required in the packet transport
   network to ensure the prioritization of critical services, to
   guarantee BW and to control jitter and delay.

TOM: Are they required everywhere the service exists, or say just at the
ingress/egress for policing/marking functions?  While we are on the subject,
do we want to be more specific about QoS requirements?

   Service providers require control and deterministic usage of network
   resources.  They need end-to-end control to engineer network paths
   and to efficiently utilize network resources.  They require
   capabilities to statically (OSS based) provision deterministic,
   protected and secured services and their associated resources as well
   as alternative control-plane options.

TOM: They also require dynamic ones. Please put that in.  I don't want to be
asking for only a completely static system.

   The transport network must be capable of transporting multiple
   services in a scalable manner.

TOM: Again, this use of "scalable" offends me. Please be more specific or
take the sentence out as it is meaningless as stated.

   Carriers will still need to cope with legacy networks (which are
   composed of many layers and technologies), thus the packet transport
   network should interwork with other packet and transport networks
   (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.

TOM: Didn't you just say that vertical interworking was client interworking
in the first sentence? How can horizontal be service interworking as well?

   For more details on each type of interworking and some of the issues
   that may arise (especially with horizontal interworking) see
   [ITU.Y1401.2008].

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 4]

Internet-Draft            MPLS-TP Requirements                 July 2008

   important role in transport networks and services.  However, not all
   of MPLS's capabilities and mechnisms are needed and/or consistent
   with transport network operations.  This document identifies the
   required capabilities for MPLS so that it can better fit a transport
   role.

TOM: I think you want to say "identifies the required sub-set of
capabilities..."  and later "potentially new ons specific for transport
networks" which it seems you say two paragraphs later.

   Combining the packet experience of MPLS with the operational
   experience of SONET/SDH constitutes a packet transport technology
   named MPLS-TP.  MPLS-TP will enable the migration of SONET/SDH
   networks to a packet-based network that will easily scale to support
   packet services in a simple and cost effective way.

   MPLS-TP needs to combine the necessary existing capabilities of MPLS
   with additional minimal mechanisms in order to meet the requirements
   described in this document.

   The requirements of an MPLS transport profile are provided below.

TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS
transport profile". That is, on the one hand you refer to a technology, but
on the other hand you are referring to a specific profile. Which is it?

2.  MPLS-TP Requirements

2.1.  General requirements

   o  MPLS-TP MUST offer as much commonality as possible with the MPLS
      user plane as defined by IETF.  When MPLS offers multiple options
      in this respect, MPLS-TP SHOULD select the minimum sub-set
      (necessary and sufficient subset) applicable to a transport
      network application.

   o  Any new functionality that is defined to fulfil the requirements
      for MPLS-TP MUST be agreed within IETF and re-use (as far as
      practically possible) existing MPLS standards.

   o  Mechanisms and capabilities MUST be able to interoperate with
      existing MPLS and PWE control and data planes where appropriate.

TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also need to
be references here to the PWE3 architecture and MPLS architectures.

   o  MPLS-TP MUST support traffic engineering capabilities that allow
      deterministic control of the use of network resources.

   o  MPLS-TP MUST support the logical separation of the control and
      management planes from the user plane.

   o  MPLS-TP SHOULD support the physical separation of the control and
      management planes from the user plane.

   o  MPLS-TP MUST support point to point (P2P) or point to multipoint
      (P2MP) connections.

TOM: Are we avoiding MP2MP consciously or was it left out?

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 5]

Internet-Draft            MPLS-TP Requirements                 July 2008

   o  MPLS-TP MUST support static provisioning of connections via an
      NMS/OSS (i.e. via the management plane).

   o  Static provisioning MUST not depend on routing or signaling
      protocols (e.g.  GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.).

   o  MPLS-TP connections MAY be able to be provisioned dynamically via
      a control plane.

TOM: I insist that we change the MAY above to MUST. I want a dynamic version
of this as much as a static one.

   o  The MPLS-TP data plane MUST be capable of functioning
      independently of the control or management plane used to operate
      the MPLS-TP layer network.  That is the MPLS-TP data plane
      operation MUST continue to operate normally if the management
      plane or control plane that configured the connections fails.

   o  MPLS-TP MUST support any network topology and be able to support
      increasing bandwidth demands, topology, number of customers or
      number of services incrementally.

TOM: I think it is imperative that although an MPLS-TP is defined to play
nicely with an MPLS one, it is imperative that one can distinguish between
both, at least at the control plane, but perhaps at the data plane as well.

2.2.  Layering requirements

   o  An MPLS-TP network MUST operate in a multiple layer network
      environment consisting of the following independent layers:

      1.  A "service layer" instance in which the connections carry the
          customer's (individual or bundled) service (may be point-to-
          point, point-to-multipoint or multipoint-to-multipoint
          services);

      2.  A "trunk layer" with point-to-point or point-to-multipoint
          connections which are used to carry aggregates of the network
          "service layer" connections; and

      3.  A "transmission media layer" which provides sections (two-port
          point-to-point connections) to carry the aggregate of network
          trunk or network service connections on various physical
          media.

TOM: This stuff belongs in the Terminology section at the top.

   MPLS-TP may provide the "service layer" (for P2P and P2MP services)
   and/or the "trunk layer" within a layer network environment.

   o  An MPLS-TP layer network MUST support the transparent transport of
      MPLS-TP and non MPLS-TP client layer networks.

   o  An MPLS-TP layer network MUST be able to be transparently carried
      over MPLS-TP and non MPLS-TP server layer networks (such as
      Ethernet, OTN, etc.)

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 6]

Internet-Draft            MPLS-TP Requirements                 July 2008

   o  It MUST be possible to operate the MPLS-TP layer network
      independently of other layer networks (either MPLS-TP or non
      MPLS-TP).

   This is not only a technology requirement, different administrative
   groups may be responsible for different layer networks (even when
   they are of the same type)), and require the capability to
   operationally support the different layers.

   o  It MUST be possible to hide MPLS-TP layer network addressing and
      other information (e.g. topology) from client layers.

2.3.  Data plane requirements

   o  The identification of each connection within its aggregate MUST be
      supported.

   o  A label in a particular section MUST uniquely identify the
      connection.

   o  A connection's source MUST be identifiable at its destination.

   Connections can be aggregated into trunks by pushing and de-
   aggregated by popping labels.  MPLS-TP labels may be swapped within a
   connection in a layer network instance when the traffic is forwarded
   from one MPLS-TP link connection to another MPLS-TP link connection.

   o  Labelling MUST make use of the MPLS label and label stack entry as
      defined in RFC3032.

   o  It MUST be possible to operate and configure the MPLS-TP data
      (transport) plane without any IP functionality.

   o  MPLS-TP MUST support both unidirectional and bi-directional point-
      to-point connections.

   o  The forward and backward directions of a bi-directional connection
      SHOULD follow the same path within the MPLS-TP network.

TOM: I am not sure if we say that they SHOULD as much as "they MUST be
capable of". 

   o  The intermediate nodes SHOULD be aware about the binding of the
      forward and the backward directions belonging to the same bi-
      directional connection.

TOM: Again, "SHOULD be capable of" seems better.

   o  MPLS-TP SHOULD support unidirectional point-to-multipoint
      connections.

   o  MPLS-TP connections MUST NOT perform merging in a way that
      prevents the unique identification of the source at the

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 7]

Internet-Draft            MPLS-TP Requirements                 July 2008

      destination (e.g. no use of LDP mp2p signaling in order to avoid
      losing LSP head-end information, no use of PHP, etc).

   o  MPLS-TP SHOULD support transport and QoS mechanisms that can
      deliver statistical multiplexing gain.  Packets exceeding the
      agreed traffic profile may be marked or discarded by the traffic
      conditioning at the ingress of the MPLS-TP network.

TOM: How about egress policing + marking?

   o  MPLS-TP MUST support connections through a single domain.

   o  MPLS-TP SHOULD support connections through multiple domains.

   o  MPLS-TP MUST be able to accommodate new traffic types.

TOM: New traffic types other than those supported by MPLS? This doesn't make
sense to me as this will result in MPLS-TP not being a subset of MPLS.

   o  MPLS-TP SHOULD support mechanisms to safeguard against the
      provisioning of connections which contain forwarding loops.

   o  MPLS-TP SHOULD support mechanisms to minimize traffic impact
      during network reconfiguration.

   o  MPLS-TP SHOULD support mechanisms which ensure the integrity of
      the adapted information.

   o  MPLS-TP MUST support an unambiguous and reliable means of
      distinguishing users' (client) packets from MPLS-TP control plane
      and management plane packets.

2.4.  Control plane requirements

   o  A distributed control plane MAY be supported to enable fast,
      dynamic and reliable service provisioning in multi-vendor and
      multi-domain environments using standardized protocols that
      guarantee interoperability.

   o  If a control plane is used for configuration of MPLS-TP
      connections then:

      *  Failure and recovery of the control plane MUST NOT impact the
         MPLS-TP forwarding plane.

TOM: This is difficult, as this really is handled in practice at both data
and control planes, depending on how this is configured/designed, and the
re-signaling can impact the data plane.

      *  It MUST support the setup, modification, and release of MPLS-TP
         connections and protection connections.

      *  It MUST support mechanisms to provide traffic engineering,
         constraint-based routing and explicit path control.

      *  It MUST provide mechanisms to address QoS and performance
         requirements (such as throughput, delay, packet loss, etc.)

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 8]

Internet-Draft            MPLS-TP Requirements                 July 2008

         while utilizing network resources efficiently and reliably.

   o  MPLS-TP SHOULD support off-path (out-of-band) control and
      management planes.

   o  The MPLS-TP control plane MUST be independent of any particular
      client or server layer control plane.

   o  The control plane SHOULD facilitate the implementation of the
      service by providing end-to-end seamless connectivity and service
      assurance.

   o  The MPLS-TP control plane MUST support establishing all the
      connectivity patterns defined for the MPLS-TP transport plane
      (e.g., uni-directional and bidirectional P2P, uni-directional
      P2MP, etc.) including configuration of protection functions and
      any associated maintenance functions.

   o  The MPLS-TP control pane must support the configuration and
      modification of OAM maintenance points as well as the activation/
      deactivation of OAM when the connection is established or
      modified.

   o  An MPLS-TP control plane MUST support topology hiding and address
      independence between domains.

   o  At the boundary of a domain an MPLS-TP control plane MUST support
      unique names or addresses identifying boundary points to be
      interconnected.

   o  At the boundary of a domain an MPLS-TP control plane must support
      group names or addresses identifying sets of boundary points to be
      interconnected.

   o  MPLS-TP layer network access points (or connection points that
      proxy for access points) SHOULD be able to be assigned names which
      are available to clients to identify endpoints in call or
      connection requests.

   o  An MPLS-TP control plane MUST support translation between
      externally visible endpoint names and internal network addresses.

   o  An MPLS-TP control plane MUST support constraint-based route
      calculation.

   o  An MPLS-TP control plane MUST support provisioning and application
      of routing constraint policies.

Niven-Jenkins, et al.    Expires January 2, 2009                [Page 9]

Internet-Draft            MPLS-TP Requirements                 July 2008

   o  An MPLS-TP control plane MUST support pre-provisioned connection
      protection.

   In some situations it is impractical to expect acceptable recovery
   performance to be achieved using dynamic recalculation of connection
   routes.  For this reason, it is necessary to allow for pre-planning
   of protection routes for selected connections.

   o  The MPLS-TP control plane MUST support fast restoration.

TOM: Define what "fast" means?

   o  An MPLS-TP control plane MUST scale gracefully to support a large
      number of connections.

TOM: Define "large" and "scale" here?

   [Include some numbers to indicate how large the CP is expected to
   scale to?]

   o  An MPLS-TP control plane MUST clearly distinguish resources
      belonging to the MPLS-TP layer network from those in other layer
      networks that may also be under control plane control.

TOM: Do you mean under the same control plane or a different one (or both)?

   o  An MPLS-TP control plane MUST support the independent
      identification of logically distinct control plane elements.

   o  It MUST be possible to identify and provision these elements
      independently, in order to reorganize the control plane components
      without impacting the data plane services and vice-versa.

   Architecturally distinct elements in a control plane include: nodes
   and links, control plane functional components, protocol controllers,
   etc.

   o  An MPLS-TP control plane SHOULD provide a common control mechanism
      for architecturally similar operations.

   o  An MPLS-TP control plane MUST support mechanisms for partitioning
      the network under control into separate peer or hierarchical
      control domains.

   o  To enable the deployment of a unified control plane aimed at
      controlling the set of transport technologies used in a transport
      network, the MPLS-TP control plane MUST also be applicable to
      other transport layer networks and provide common operations
      across multiple layers.  In order to maintain independence between
      MPLS-TP and its respective client and server layer network
      separate control plane instances SHOULD be used to control a set
      of transport layer networks.

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 10]

Internet-Draft            MPLS-TP Requirements                 July 2008

   o  MPLS-TP SHOULD detect and recover from control plane failures and
      degradations using graceful operations.

2.5.  Network Management (NM) requirements

   o  MPLS-TP MUST operate under a common operation, control and
      management paradigm with respect to other transport technologies
      (e.g.  SDH, OTN or WDM).

   o  An MPLS-TP network MUST be able to be operated with a centralized
      NMS system.

   o  An MPLS-TP network SHOULD be able to be operated by a centralized
      NMS system with the support of a distributed control plane.

TOM: I don't know what this means or the one above it, or how this
requirement would translate into anything tangible in the MPLS-TP protocol
designs.  I suggest it be removed.

   o  The MPLS-TP management plane MUST NOT depend on a specific client
      layer management plane.

TOM: This is a non-sequitur if you ask me; please strike it.

   o  The MPLS-TP management plane MUST support the configuration and
      modification of OAM maintenance points as well as the activation/
      deactivation of OAM when the connection is established or
      modified.

   For the complete set of requirements related to NM functionality for
   MPLS-TP, see the MPLS-TP NM requirements document [REF].

2.6.  OAM requirements

   o  MPLS-TP SHOULD provide a comprehensive set of capabilities (that
      are independent of and agnostic to the transmitted client
      services) to support fault management, performance monitoring (of
      the MPLS-TP network and the services), protection switching, fault
      localization, signal quality measurement, etc.

   o  A mechanism SHOULD be supported to detect, diagnose and enable
      recovery from facility and equipment failures and performance
      degradations according to the requirements of the service.

   o  MPLS-TP OAM MUST be able to operate without IP functionality and
      without relying on control and/or management planes.

   For the complete set of requirements related to OAM functionality for
   MPLS-TP, see the MPLS-TP OAM requirements document [REF].

TOM: I suggest you just remove these two sections and refer to the
OAM/Managemetn documents.

2.7.  Network performance management (PM) requirements

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 11]

Internet-Draft            MPLS-TP Requirements                 July 2008

   o  MPLS-TP MUST support traffic-engineering capabilities with
      traffic- and/or resource-oriented performance objectives.

TOM: What are performance objectives?  Do you mean traffic profiles such as
QoS/bandwidth?

   o  MPLS-TP MUST support a method to offer packet loss objectives
      comparable to those in TDM transport networks (only due to bit
      errors).

   For the complete set of requirements related to PM functionality for
   MPLS-TP, see the MPLS-TP OAM requirements document [REF].

TOM: Again, I suggest you punt on this entire section and move it to the OAM
doc.

2.8.  Protection & Survivability requirements

   Network survivability plays a critical factor in the delivery of
   reliable services.  Network availability is a significant contributor
   to revenue and profit.  Service guarantees in the form of SLAs
   require a resilient network that rapidly detects facility or node
   failures and restores network operation in accordance with the terms
   of the SLA.

   The requirements in this section use of the recovery terminology
   defined in RFC 4427[RFC4427].

   o  MPLS-TP SHOULD support transport network style protection

TOM: I would make this a MUST.

      switching mechanisms (tandem network connection protection, LSP
      protection and PW protection) to provide the sub-50ms recovery
      time required to maintain customer transparency, even when
      thousands of services are simultaneously affected by a failure.
      [Is sub-50ms really a requirement, do we want to clarify this
      further - is it sub-50ms end to end, or per link?]

   o

      *  MPLS-TP recovery mechanisms SHOULD be applicable at various
         levels throughout the network, SPAN, tandem connection and end-
         to-end. 

TOM: This sentence doesn't parse. Please re-write.

 Any recovery mechanism used in a tandem connection
         MUST be independent of other tandem connections.

      *  MPLS-TP SHOULD support mechanisms that keep traffic flowing
         while the network recovers from failures.

TOM: I would say this is a MUST.

      *  MPLS-TP SHOULD support network restoration mechanisms
         controlled by a distributed control plane and/or by a
         management plane based.

TOM: I would say this is a MUST.

      *

         +  The restoration resources MAY be pre-planned and selected a
            priori, or computed after failure occurrence.

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 12]

Internet-Draft            MPLS-TP Requirements                 July 2008

         +  MPLS-TP MAY support shared-mesh restoration.

         +  MPLS-TP SHOUD support soft LSP restoration.

         +  MPLS-TP MAY support hard LSP restoration.

         +  The restoration mechanism MUST be applicable to any
            topology.

         +  Restoration priority MAY be implemented to determine the
            order in which connections should be restored (to minimize
            service restoration time as well as to gain access to
            available spare capacity on the best paths).  Preemption
            priority MAY be used in the event that not all connections
            can be restored, in which case connections with lower
            preemption priority should be released.

         +  The restoration mechanism SHOULD operate in synergy with
            other transport network technologies (SDH, OTN, WDM).

      *  MPLS-TP SHOULD support data plane driven protection mechanisms
         (without any dependency on a control plane or IP protocols) to
         enable fast recovery from failure, and thereby to enhance the
         reliability and availability performance of MPLS-TP networks.

      *

         +  MPLS-TP protection mechanisms SHOULD be applied to LSPs and
            PWs.

         +  MPLS-TP MUST support mechanisms that rapidly detect, locate,
            notify and remedy network faults.

         +  MPLS-TP MUST support 1:1 bidirectional protection switching.
            The protection state of both ends of the protected entity
            MUST be synchronized.

         +  MPLS-TP MAY support 1+1 unidirectional protection switching.

         +  MPLS-TP protection mechanisms MUST be applicable to both
            point-to-point and point-to-multipoint connections.

         +  It SHOULD be possible to achieve protection at the MPLS-TP
            layer as fast as possible (subject to the temporal
            resolution of the defect detection mechanism).

         +  Protection ratio MUST be of 100%, i.e., 100% of impaired
            working traffic MUST be protected for a failure on a single

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 13]

Internet-Draft            MPLS-TP Requirements                 July 2008

            working LSP.

         +  Operator requests for manual control of protection switching
            such as clear, lockout of protection, forced-switch and
            manual-switch commands MUST be supported.  Prioritized
            protection between Signal Fail (SF), Signal Degradation (SD)
            and operator switch requests MUST be supported.

         +  MPLS-TP protection mechanisms MUST support revertive and
            non-revertive behaviour. o An extra traffic capability
            SHOULD be supported when possible.

         +  MPLS-TP protection switching mechanisms MUST prevent
            frequent operation of the protection switch due to an
            intermittent defect.

         +  MPLS-TP protection mechanisms MUST ensure co-ordination of
            timing of protection switches at multiple layers to avoid
            races and to allow the protection switching mechanism of the
            server layer to fix the problem before switching at the
            MPLS-TP layer.

         +  MPLS-TP MAY support mechanisms that are optimized for
            specific network topologies (Ring, Mesh) in order to handle
            protection switching in a cost-efficient manner.

2.9.  QoS requirements

   Service providers require advanced traffic management capabilities to
   enforce and guarantee the QoS parameters of customers' SLAs.

   Quality of service mechanisms are required to ensure:

   o  Support for differentiated services and different traffic types
      with traffic class separation associated with different traffic.

   o  Prioritization of critical services.

   o  Enabling the provisioning and the guarantee of Service Level
      Specifications (SLS), with support for hard and relative end-to-
      end BW guaranteed.

   o  Controlled jitter and delay.

   o  Guarantee of fair access to shared resources in an MPLS-TP
      network.

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 14]

Internet-Draft            MPLS-TP Requirements                 July 2008

   o  Ability for OAM and data to share the same fate.

TOM: This belongs in the OAM document.

   o  Resources for control and management plane packets so that user
      plane traffic, regardless of the amount, will not cause control
      and management functions to become inoperative.

   The following QoS requirements apply to MPLS-TP:

   o  MPLS-TP MUST be able to deliver the same degree of QoS that has
      been delivered by SDH/SONET systems.

TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or "MPLS-TP 
SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP bit is 
implicit I think.

   o  MPLS-TP MUST support transport bandwidth allocation to any
      granularity without any restrictions based on a circuit-switched
      multiplexing hierarchy.  This attribute will provide service
      providers with the capability to route more customer service
      demands over the MPLS-TP network.

   [Should we refer here to the requirements specified in RFC 2702?]

2.10.  Security requirements

   o  MPLS-TP MUST ensure that the network and services are secured.

   o  Traffic flows from different users MUST NOT be intermingled, but
      if this does occur then this MUST be detectable and the
      appropriate consequent actions taken.

   o  MPLS-TP MUST ensure the separation of customer (client) and
      provider (server and peer network) addressing and other
      information.

TOM: This requirement is stated above.

   o  MPLS-TP MUST ensure that the control and management planes as well
      as OAM traffic are secure from external attack.

   o  MPLS-TP MUST provide mechanisms to ensure that the MPLS-TP network
      remains secure and stable under situations of extreme stress.

   Examples of attacks and situations of extreme stress include (but are
   not limited to) classical security attacks (e.g., hijacking, privacy,
   non-repudiation, etc.) and attacks on network availability (e.g.,
   denial of service (DoS) attacks).

3.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 15]

Internet-Draft            MPLS-TP Requirements                 July 2008

   RFC.

4.  Security Considerations

   This document does not by itself raise any particular security
   considerations.

5.  Acknowledgements

   The authors wish to thank Neil Harrison and Tomonori Takeda for their
   review and enhancements to the text.

6.  Informative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4427]  Mannie, E. and D. Papadimitriou, "Recovery (Protection and
              Restoration) Terminology for Generalized Multi-Protocol
              Label Switching (GMPLS)", RFC 4427, March 2006.

   [ITU.Y1401.2008]
              International Telecommunications Union, "Principles of
              interworking", ITU-T Recommendation Y.1401, February 2008.

Authors' Addresses

   Ben Niven-Jenkins (editor)
   BT
   208 Callisto House, Adastral Park
   Ipswich, Suffolk  IP5 3RE
   UK

   Email: [email-masked]

   Deborah Brungard (editor)
   AT&T
   Rm. D1-3C22 - 200 S. Laurel Ave.
   Middletown, NJ  07748
   USA

   Email: [email-masked]

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 16]

Internet-Draft            MPLS-TP Requirements                 July 2008

   Malcolm Betts (editor)
   Nortel Networks
   3500 Carling Avenue
   Ottawa, Ontario  K2H 8E9
   Canada

   Email: [email-masked]

   Nurit Sprecher
   Nokia Siemens Networks
   3 Hanagar St. Neve Ne'eman B
   Hod Hasharon,   45241
   Israel

   Email: [email-masked]

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 17]

Internet-Draft            MPLS-TP Requirements                 July 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Niven-Jenkins, et al.    Expires January 2, 2009               [Page 18]

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Sun, 22 Jun 2008 11:45:49 +0200

Hi Thomas,
Thanks for your comments.
I still need to get into the details and meanings of your comments, but
in the meantime I have one basic concern on your comment on " MPLS-TP
connections MAY be able to be provisioned dynamically via a control
plane. TOM: I insist that we change the MAY above to MUST. I want a
dynamic version of this as much as a static one."
This is one of the fundamental principles of the MPLS-TP, that the
presence of a distributed control plane in support of network operations
is optional (as in other transport technologies, like in SDH, etc.).
This is also the trigger for the definition of OAM capabilities which
are independent of a control plane, as well as of the protection
switching, etc. 
This is also addressed by the slides of the JW: "Desire to statically
configure LSPs and PWEs via the management plane...
Transport OAM capabilities don't exist for LSP and PWE independent of
configuration mechanism (management plane or GMPLS or PWE control
plane)...With static provisioning, no dependency on routing or signaling
(e.g. GMPLS or, IGP, RSVP, BGP, LDP)", etc. 
Best regards,
Nurit

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Thomas Nadeau
Sent: Friday, June 20, 2008 21:38
To: Ben Niven-Jenkins; Loa Andersson; MEAD team
Subject: Re: [Mpls-interop] next MEAD team meeting

    Comments on the document inline start with "TOM:"
In general, please review the document and put more of an emphasis on
the use of "MUST" rather than "MAY" or "SHOULD". The IETG frowns on
requirements documents that are too optional.

    --Tom

                          MPLS-TP Requirements

Status of this Memo

Abstract

Requirements Language



Table of Contents



1.  Introduction

TOM: I would use something other than "client signal" here. Something
like "client path" or something is what I think you mean.

TOM: Is it? Does the transport really provide connections or does it
provide transport paths?  I am sensitive to the terms used here. We
don't want this to become a connect-fest. Seems to me that you explain
this better in the next sentence anyhow.

TOM: Do you really mean to call these "time pipes"?  Sounds too
futuristic even for this work. *)  I think you mean "...into relatively
large, long-lasting paths..."

TOM: Keep the terminology consistent here too. There is the use of
"trunks", "pipes", etc...



TOM: Does this really happen at the data or control plane or both? Or do
we care?

TOM: I am not sure the above is appropriate for a requirements document.
It sounds like you are spelling out an algorithm for how a solution
should work.

TOM: Are they required everywhere the service exists, or say just at the
ingress/egress for policing/marking functions?  While we are on the
subject, do we want to be more specific about QoS requirements?

TOM: They also require dynamic ones. Please put that in.  I don't want
to be asking for only a completely static system.

TOM: Again, this use of "scalable" offends me. Please be more specific
or take the sentence out as it is meaningless as stated.

TOM: Didn't you just say that vertical interworking was client
interworking in the first sentence? How can horizontal be service
interworking as well?



TOM: There is a terminology issue in the use of "MPLS-TP" or "an MPLS
transport profile". That is, on the one hand you refer to a technology,
but on the other hand you are referring to a specific profile. Which is
it?

2.  MPLS-TP Requirements

TOM: Change PWE to "IETF PWE3" and "MPLS" to "IETF MPLS". There also
need to be references here to the PWE3 architecture and MPLS
architectures.



TOM: I insist that we change the MAY above to MUST. I want a dynamic
version of this as much as a static one.

TOM: I think it is imperative that although an MPLS-TP is defined to
play nicely with an MPLS one, it is imperative that one can distinguish
between both, at least at the control plane, but perhaps at the data
plane as well.





TOM: New traffic types other than those supported by MPLS? This doesn't
make sense to me as this will result in MPLS-TP not being a subset of
MPLS.

TOM: This is difficult, as this really is handled in practice at both
data and control planes, depending on how this is configured/designed,
and the re-signaling can impact the data plane.





TOM: Do you mean under the same control plane or a different one (or
both)?



TOM: I don't know what this means or the one above it, or how this
requirement would translate into anything tangible in the MPLS-TP
protocol designs.  I suggest it be removed.

2.6.  OAM requirements



TOM: What are performance objectives?  Do you mean traffic profiles such
as QoS/bandwidth?

TOM: Again, I suggest you punt on this entire section and move it to the
OAM doc.

   o

      *



      *



            working LSP.

2.9.  QoS requirements



TOM: We can save on a lot of text and remove the "MPLS-TE MUST" or
"MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP
bit is implicit I think.

3.  IANA Considerations



   RFC.

5.  Acknowledgements

   [ITU.Y1401.2008]

Authors' Addresses

   Email: [email-masked]



   Malcolm Betts (editor)
   Nortel Networks
   3500 Carling Avenue
   Ottawa, Ontario  K2H 8E9
   Canada

   Nurit Sprecher
   Nokia Siemens Networks



Full Copyright Statement

Intellectual Property

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 22 Jun 2008 12:17:05 +0100

Tom,

We still need to go through the draft and align the language better with
that which is familiar to the IETF.  I've incorporated your comments,  also
see below for some responses.

> "client path" or something is what I think you mean.

Changed to "maintain the integrity of the client across the transport
network"

> TOM: Is it?

Yes.

> Does the transport really provide connections or does it provide
> transport paths?

It provides connections in "transport speak".  Connections have specific
attributes that the term path does not convey but for the purpose of
expressing the requirements in "IETF speak" 'transport path' is probably
sufficient.

>  I am sensitive to the terms used here. We don't want this
> to become a connect-fest.

You call it a tomayto, I call it a tomarto...

> TOM: Again, I don't like the term "signals" here. Use "client data" or

Changed to " The purpose of a transport network is to transparently carry
its clients (i.e. the stream of client PDUs or client bits)"

> even for this work. *)  I think you mean "...into relatively large,

Changed to " aggregated into large transport paths with long-holding times,
which enable"

> TOM: Keep the terminology consistent here too. There is the use of "trunks",

Changed to "transport paths"

> terms like "scaleability" that I don't like used unless it is clearly

Yes as you only have to monitor the transport path itself and not each
individual client path within the transport path.

> TOM: Does this really happen at the data or control plane or both? Or do we

Both.  All client planes are isolated from the transport plane and all the
planes of one client are isolated from the planes of any other client.

> sounds like you are spelling out an algorithm for how a solution should

This is a description of how a transport network operates.  I included it as
I assumed not all readers would be familiar with transport network operation
but if we are comfortable assuming they are I can remove it.

> do we want to be more specific about QoS requirements?

A connection has the constraint that all the link connection resources have
been reserved for a specific communication, ergo it is implicit that some
QoS is required within a transport network itself.

> asking for only a completely static system.

ITU requirement is that only static is a MUST but we can expand to make
dynamic a MUST too.

Changed to " They require capabilities to statically (OSS based) and
dynamically provision"

> take the sentence out as it is meaningless as stated.

Agreed it does not add anything and we can implicitly assume any solution
should be "scalable", I've removed it.

> in the first sentence? How can horizontal be service interworking as well?

Vertical interworking is where a client is encapsulated into a server
transparently (e.g. Ethernet over ATM), horizontal interowkring is where a
client is "interworked" with another network ala FRF.8.

TBH I am not convinced there is a real requirement for horizontal
interworking in transport networks and if we all agree that to be the case
then we can remove the above paragraph.

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 22 Jun 2008 07:51:48 -0400

> is optional (as in other transport technologies, like in SDH, etc.).

    I agree it is optional. What I want to make sure is that it is not so
optional that it is completely removed from the design.  The language in the
document now seems to be headed in that direction.

> configure LSPs and PWEs via the management plane...

    I am not arguing against static; I am arguing for dynamic to be in there
as well.

> plane)...

    It depends on how you look at what "transport OAM capabilities". From my
perspective at BT, I definitely think there is a dynamic flavor of this for
sure.  Again, I am not advocating removal of the static parts, just the
addition of the dynamic ones. And since they are already there in large
part, as part of the base MPLS specification, I don't see any harm in
specifying this.

    --Tom

> With static provisioning, no dependency on routing or signaling

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Sun, 22 Jun 2008 14:22:30 +0200

Hi Tom,
Thanks for your response.
If you agree that the control plane in MPLS-TP is optional, then we
cannot say MUST. To make it stronger, we may think of changing the "MAY"
to "SHOULD".
Best regards,
Nurit

-----Original Message-----
From: ext Thomas Nadeau [mailto:[email-masked]] 
Sent: Sunday, June 22, 2008 14:52
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa
Andersson; MEAD team
Cc: Weingarten, Yaacov (NSN - IL/Israel - MiniMD)
Subject: Re: [Mpls-interop] next MEAD team meeting

On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)"
<[email-masked]> wrote:

> I still need to get into the details and meanings of your comments, 
> but in the meantime I have one basic concern on your comment on " 
> MPLS-TP connections MAY be able to be provisioned dynamically via a 
> control plane. TOM: I insist that we change the MAY above to MUST. I 
> want a dynamic version of this as much as a static one."
> presence of a distributed control plane in support of network 
> operations is optional (as in other transport technologies, like in
SDH, etc.).

    I agree it is optional. What I want to make sure is that it is not
so optional that it is completely removed from the design.  The language
in the document now seems to be headed in that direction.

> configure LSPs and PWEs via the management plane...

    I am not arguing against static; I am arguing for dynamic to be in
there as well.

> configuration mechanism (management plane or GMPLS or PWE control 

    It depends on how you look at what "transport OAM capabilities".
>From my perspective at BT, I definitely think there is a dynamic flavor
of this for sure.  Again, I am not advocating removal of the static
parts, just the addition of the dynamic ones. And since they are already
there in large part, as part of the base MPLS specification, I don't see
any harm in specifying this.

    --Tom

> With static provisioning, no dependency on routing or signaling (e.g. 
> GMPLS or, IGP, RSVP, BGP, LDP)", etc.
> Best regards,
> Nurit
> 
> Internet-Draft
BT
>                                                            M. Betts,
Ed.
>                                                          Nortel
Networks
>                                                              N.
Sprecher
>                                                   Nokia Siemens
Networks
>                                                            July 01, 
> 2008

> futuristic even for this work. *)  I think you mean "...into 
> relatively large, long-lasting paths..."
> 
> TOM: Do they really reduce load? This is one of those fluffy, 
> open-ended terms like "scaleability" that I don't like used unless it 
> is clearly defined.
> 
> TOM: Does this really happen at the data or control plane or both? Or 
> do we care?
> 
> 
> TOM: Are they required everywhere the service exists, or say just at 
> the ingress/egress for policing/marking functions?  While we are on 
> the subject, do we want to be more specific about QoS requirements?
> 

> capabilities..."  and later "potentially new ons specific for 
> transport networks" which it seems you say two paragraphs later.
> 
> transport profile". That is, on the one hand you refer to a 
> technology, but on the other hand you are referring to a specific 
> profile. Which is it?
> 
> 
> 2.  MPLS-TP Requirements
> 
> play nicely with an MPLS one, it is imperative that one can 
> distinguish between both, at least at the control plane, but perhaps 
> at the data plane as well.
> 

> TOM: New traffic types other than those supported by MPLS? This 
> doesn't make sense to me as this will result in MPLS-TP not being a 
> subset of MPLS.
> 

> TOM: What are performance objectives?  Do you mean traffic profiles 
> such as QoS/bandwidth?
> 
> TOM: Again, I suggest you punt on this entire section and move it to 
> the OAM doc.
> 
> "MPLS-TP SHOULD" bits and simply say "MUST X" or "SHOULD Y". The 
> MPLS-TP bit is implicit I think.
>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Sun, 22 Jun 2008 13:39:51 +0100

I think the key thing is that MPLS-TP must be able to operate (including
OAM) in the absence of a control plane.

The option is then down to whether we say both static & dynamic are MUSTs
(from an implementation perspective) and the operator is then free to choose
whether they operate their network statically or dynamically.  Or whether
only static is a MUST and dynamic is optional (for implementation).

I believe the work in ITU intended to extend to dynamic at some point and
static was just a first step in the T-MPLS work.

It only take one operator to demand dynamic from their vendors for it to be
present in equipment anyway even if it is not used by other operators.

So I think we can make both static & dynamic MUSTs and then clarify that
when operating in a static mode MPLS-TP must not rely on any dynamic
protocols.

We cover this (at least to some extent) already with requirements such as "
Static provisioning MUST not depend on routing or signaling protocols (e.g.
GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)."

Ben

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Sun, 22 Jun 2008 15:05:17 +0200

I believe it may confuse the readers.  
I think we should require that static is a MUST and dynamic is optional
(for implementation).
That was also the intention in T-MPLS that argued to have the same
look-and-feel as SDH. They defined static provisioning and the intended
to have an optional control plane (based on GMPLS). 

-----Original Message-----
From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Sunday, June 22, 2008 15:40
To: Thomas Nadeau; Sprecher, Nurit (NSN - IL/Israel - MiniMD); Loa
Andersson; MEAD team

The option is then down to whether we say both static & dynamic are
MUSTs (from an implementation perspective) and the operator is then free
to choose whether they operate their network statically or dynamically.
Or whether only static is a MUST and dynamic is optional (for
implementation).

I believe the work in ITU intended to extend to dynamic at some point
and static was just a first step in the T-MPLS work.

It only take one operator to demand dynamic from their vendors for it to
be present in equipment anyway even if it is not used by other
operators.

We cover this (at least to some extent) already with requirements such
as "
Static provisioning MUST not depend on routing or signaling protocols
(e.g.
GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)."

Ben

SDH, etc.).

> so optional that it is completely removed from the design.  The 
> language in the document now seems to be headed in that direction.
> 

> From my perspective at BT, I definitely think there is a dynamic 
> flavor of this for sure.  Again, I am not advocating removal of the 
> static parts, just the addition of the dynamic ones. And since they 
> are already there in large part, as part of the base MPLS 
> specification, I don't see any harm in specifying this.
> 
>     --Tom
> 
> 
> 

BT
Ed.
Networks
Sprecher
Networks
>>    Intellectual Property and Copyright Statements . . . . . . . . . .

>> 18

>> don't want this to become a connect-fest. Seems to me that you 
>> explain this better in the next sentence anyhow.
>> 
>> TOM: Again, I don't like the term "signals" here. Use "client data" 
>> or something.
>> 

>> TOM: They also require dynamic ones. Please put that in.  I don't 
>> want to be asking for only a completely static system.
>> 
>> TOM: Again, this use of "scalable" offends me. Please be more 
>> specific or take the sentence out as it is meaningless as stated.
>> 

>> TOM: I am not sure if we say that they SHOULD as much as "they MUST 
>> be capable of".
>> 

>> data and control planes, depending on how this is 
>> configured/designed, and the re-signaling can impact the data plane.
>>

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Sun, 22 Jun 2008 16:37:14 +0200

Thanks Ben for clarifying this. 
I see the point (also reading Andy's response).

-----Original Message-----
From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Sunday, June 22, 2008 15:40
To: Thomas Nadeau; Sprecher, Nurit (NSN - IL/Israel - MiniMD); Loa
Andersson; MEAD team

Ben

SDH, etc.).

BT
Ed.
Networks
Sprecher
Networks

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 22 Jun 2008 16:50:29 -0400

> OAM) in the absence of a control plane.

    Again, I am not advocating for it to not work without a control plane.
All I am saying is that it MUST work WITH a control plane too.
 
> only static is a MUST and dynamic is optional (for implementation).

    Yes, and I think it is a MUST in both cases.
 
> when operating in a static mode MPLS-TP must not rely on any dynamic

    Agreed.
 
> GMPLS, OSPF, IS-IS, RSVP, BGP, LDP etc.)."

    Yes. What I was asking is that the other SHOULDs be changed to MUSTs.
Requirements documents that have lots of MAY or SHOULDS are not so useful
IMHO.

    --Tom

---

From: Thomas Nadeau <[email-masked]>
Date: Sun, 22 Jun 2008 16:51:09 -0400

> cannot say MUST. To make it stronger, we may think of changing the "MAY"

    I DO NOT agree that it is optional. There are two different modes if you
will, to run MPLS-TP; dynamic or static.  Both are important.

    --Tom

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Sun, 22 Jun 2008 23:40:34 +0200

Hi Tom,
Personally I agree that both are the dynamic and the static options are
important. 
You sais below:  ">     I agree it is optional. What I want to make sure
is that it is not 
> "
I think I can live with tBEn's recommendation, the one that was
supported also by Andy, that we can make both static & dynamic MUSTs and
then clarify that
when operating in a static mode MPLS-TP must not rely on any dynamic
protocols.
Best regards,
Nurit

-----Original Message-----
From: ext Thomas Nadeau [mailto:[email-masked]] 
Sent: Sunday, June 22, 2008 23:51
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Ben Niven-Jenkins; Loa
Andersson; MEAD team

> cannot say MUST. To make it stronger, we may think of changing the
"MAY"

    I DO NOT agree that it is optional. There are two different modes if
you will, to run MPLS-TP; dynamic or static.  Both are important.

    --Tom

>> explain
>> or

>> want
>> specific

>>    aggregated by popping labels.  MPLS-TP labels may be swapped 
>> within
> a
>> be

>> configured/designed,

---

From: "Italo Busi" <[email-masked]>
Date: Mon, 23 Jun 2008 10:38:21 +0200

If I understand properly the arguments in this discussion, it seems quite
important to clarify in the scope that these requirements are SP requirements as
well as the fact that the source of most of them (if not all) is ITU-T.

What about the following abstract?

"
This document specifies the requirements for an MPLS Transport Profile (MPLS-TP)
in order to support capabilities and functionalities as needed for packet
transport network services and network operations.

Unless explicitly mentioned, these requirements are derived from the set of
requirements specified by ITU-T.

This document is a product of a joint ITU-IETF effort. 
"

Thanks, Italo

> [mailto:[email-masked]] On Behalf Of Loa Andersson
> Sent: Friday, June 20, 2008 7:25 PM
> To: BRUNGARD, DEBORAH A, ATTLABS
> Cc: MEAD team
> >> *         I think it is important to indicate that " This 
> document is
> > a
> >> I was thinking for the requirements we should include a 
> sentence in 
> >> the
> >>
> >> This document summarizes the ITU-T requirements for 
> MPLS-TP in order 
> >> to
> >>
> >> support capabilities and functionalities as needed by the 
> ITU-T. It 
> >> does
> >>

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Mon, 23 Jun 2008 10:46:19 +0200

I support this.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Italo Busi
Sent: Monday, June 23, 2008 11:38
To: 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS'
Cc: 'MEAD team'
Subject: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next
MEADteam meeting)

If I understand properly the arguments in this discussion, it seems
quite
important to clarify in the scope that these requirements are SP
requirements as
well as the fact that the source of most of them (if not all) is ITU-T.

"
This document specifies the requirements for an MPLS Transport Profile
(MPLS-TP)
in order to support capabilities and functionalities as needed for
packet
transport network services and network operations.

Unless explicitly mentioned, these requirements are derived from the set
of
requirements specified by ITU-T.

Thanks, Italo

---

From: Thomas Nadeau <[email-masked]>
Date: Mon, 23 Jun 2008 09:33:48 -0400

Cool

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 24 Jun 2008 09:06:09 +0100

More responses...I will also go through the document and replace
"connection/trunk/pipe" with "transport path" and replace "user/forwarding
plane" with "data plane".

Ben

> networks" which it seems you say two paragraphs later.

I combined this para with the one two paragraphs later & did some editing to
come up with

" MPLS is a maturing packet technology and it is already playing an
important role in transport networks and services. However, not all of
MPLS's capabilities and mechanisms are needed and/or consistent with
transport network operations. MPLS-TP needs to combine the necessary
existing capabilities of MPLS with additional minimal mechanisms in order
that it can be used in a transport role."

> on the other hand you are referring to a specific profile. Which is it?

Changed to MPLS-TP

> be references here to the PWE3 architecture and MPLS architectures.

Done.  I have referenced RFC3031 & RFC3985, should I reference any others?

> TOM: Are we avoiding MP2MP consciously or was it left out?

We are consciously avoiding MP2MP, one of the attributes of a connection is
that it has a single source.  MP2MP is not a feature of transport networks.

> of this as much as a static one.

Done.  I have also added the para below to the introduction to try and
clarify the position we agreed over the weekend.

" Although both static and dynamic configuration of MPLS-TP transport paths
(including OAM) is required by this document, it MUST be possible for
operators to be able to completely operate (including OAM)  an MPLS-TP
network in the absence of any control plane or dynamic protocols. "

> both, at least at the control plane, but perhaps at the data plane as well.

Can you suggest some wording for those requirements?

> TOM: This stuff belongs in the Terminology section at the top.

Reworded to " An MPLS-TP network MUST operate in a multiple layer network
environment consisting of independent service, transport path and
transmission media layers. " and moved the 3 bullets of definition to a
terminology section.

> TOM: I am not sure if we say that they SHOULD as much as "they MUST be

Done.  Nurit - to address your comment that we should not restrict
bi-directional connections to using the same path, I don't believe changing
this to a "MUST be capable of" makes that restriction.  It states that
equipment MUST have the capability but it does not state that they must
always use that capability (e.g. We could say a piece of equipment MUST
support QoS marking but that does not mean it has to apply QoS markings to
all connections)

> TOM: Again, "SHOULD be capable of" seems better.

I can't find a way to put SHOULD be capable of in this requirement and still
parse it.  The intent of the requirement is that when a bi-directional
connection traverses an intermediate node, that intermediate node should
have knowledge that both directions belong to the same connection and aren't
in fact two independent connections running in opposite directions.

> TOM: How about egress policing + marking?

I guess this depends how you think about it.  If you think of a connection
as a regular water pipe then you can restrict the amount water that you can
put in the pipe by restricting the diameter of the pipe.  You can't however
restrict what comes out of the other end of the pipe.

IF we think egress policing & marking is important for connections I can add
it in but I am not convinced that it is as I believe in a transport network
policing is done on ingress and the egress just "spits" out what it gets.
It is then the next transport connection (or a higher layer) that does
policing of what comes out on ingress to that connection/layer.

> sense to me as this will result in MPLS-TP not being a subset of MPLS.

Two things:
1) MPLS-TP is a subset + minimal necessary additional capabilities
2) If MPLS evolves to support a new traffic type and MPLS-TP automatically
inherits that capability too as a result of being derived from MPLS then
this requirement is met.

> re-signaling can impact the data plane.

I think this is sort of hinting at NSR type functionality - e.g. Just
because your control plane has failed does not mean that your data plane
should also go down.  However as you state recovery of the control plane may
have some impact on the data plane so I've split it into two requirements as
follows (comments welcome):

" Failure of the control plane MUST NOT impact the MPLS-TP forwarding plane.

And

Recovery of the control plane MUST NOT impact the MPLS-TP forwarding plane
any more than is necessary to re-establish the control plane."

> TOM: Define what "fast" means?

I'm not convinced that including arbitrary numbers is overly useful.  I
guess the intent is that MPLS-TP needs to support mechanisms that are faster
than say IGP re-convergence.  Maybe we can reword the requirement to make it
more useful without including specific numbers.

Any suggestions for text welcomed.

> TOM: Define "large" and "scale" here?

Again I don't think arbitrary numbers are particularly useful (it is
analogous to saying 640K is all the memory a PC will ever need).  The intent
is that MPLS-TP should not be "set in stone" but capable of scaling in the
future to accommodate numbers of connections that may not be possible today.

> TOM: Do you mean under the same control plane or a different one (or both)?

I don't know TBH - what do the others think?

> designs.  I suggest it be removed.

This requirements means that it must be possible to use both control &
management planes to operate an MPLS-TP network.  An example of this would
be that the network is provisioned using only the management plane, but
under failure it uses control plane driven recovery/restoration mechanisms
giving the operator the advantage that they do not need to deploy capacity
to protect every path in their network in case of a failure.

The requirement above it is basically saying MPLS-TP must be able to be
operated in a static mode.

> TOM: This is a non-sequitur if you ask me; please strike it.

This is stating that the MPLS-TP management plane must be independent from
client management planes (in the same way the MPLS-TP data & control planes
must be independent from client data & control planes).

I have reworded it along those lines to
" The MPLS-TP management plane MUST be independent of any particular client
or server layer management plane."

> OAM/Managemetn documents.

OK.  I haven't seen either of those documents & the outline requirements
above are important so I suggest we leave them as-is for the first draft and
when we have all the requirements documents side by side we can incorprate
the above into the OAM & NM documents.
 
> TOM: What are performance objectives?  Do you mean traffic profiles such as

I'll have to refer this to the ITU folks.

> TOM: Again, I suggest you punt on this entire section and move it to the OAM

See my suggestion above.

> TOM: I would make this a MUST.

Done.

> TOM: This sentence doesn't parse. Please re-write.

I've changed it to " MPLS-TP recovery mechanisms SHOULD be applicable at
various levels throughout the network including support for span, tandem
connection and end-to-end recovery." which I hope makes more sense.  I've
also added Nurit's definitiosn of span & tandem connection to the
terminology section.

> TOM: I would say this is a MUST.

Done.

> TOM: I would say this is a MUST.

Done.  I also split it out into two requirements - one for management plane
& one for control plane.

> TOM: This belongs in the OAM document.

See suggestion above.

> SHOULD" bits and simply say "MUST X" or "SHOULD Y". The MPLS-TP bit is

Done.
 
> TOM: This requirement is stated above.

I don't believe it is.  The first is saying that data flows must not be
intermingled.  The second is saying that addresses must be independent.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 24 Jun 2008 09:30:00 +0100

I don't like this.  I'm not clear why ITU-T has to be the only organisation
drawn out as the source of the requirements and I don't like the idea of
having to somehow identify/tag all requirements that are not from the ITU-T
as I believe this to be an unnecessary editorial overhead which will only
get worse as the document evolves.

How about this?

"
This document specifies the requirements for an MPLS Transport Profile
(MPLS-TP) in order to support the capabilities and functionalities needed
for packet transport network services and packet transport network
operations.

These requirements are a combination of those derived from the set of
requirements specified by ITU-T and requirements received directly from
Service Providers.

Ben

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Tue, 24 Jun 2008 10:45:03 +0200

Even better. I support this version. 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Ben
Niven-Jenkins
Sent: Tuesday, June 24, 2008 11:30
To: Italo Busi; 'Loa Andersson'; 'BRUNGARD, DEBORAH A, ATTLABS'
Cc: 'MEAD team'
Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next
MEAD team meeting)

I don't like this.  I'm not clear why ITU-T has to be the only
organisation drawn out as the source of the requirements and I don't
like the idea of having to somehow identify/tag all requirements that
are not from the ITU-T as I believe this to be an unnecessary editorial
overhead which will only get worse as the document evolves.

How about this?

"
This document specifies the requirements for an MPLS Transport Profile
(MPLS-TP) in order to support the capabilities and functionalities
needed for packet transport network services and packet transport
network operations.

Ben

On 23/06/2008 09:38, "Italo Busi" <[email-masked]> wrote:

> quite important to clarify in the scope that these requirements are SP

> requirements as well as the fact that the source of most of them (if 
> not all) is ITU-T.
> 
> packet transport network services and network operations.
> 
> Unless explicitly mentioned, these requirements are derived from the 
> set of requirements specified by ITU-T.
> 

>> ---------------------------------------------------------------------
>> -
>>>> --
>>>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 24 Jun 2008 10:34:45 +0100

Folks,

See attached for the latest spin of the MPLS-TP requirements document.  I
think I've incorporated all the comments received so far.

I haven't included the boiler plate IETF-ITU joint effort text as we haven't
reached consensus on what it should say yet.

Ben

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 24 Jun 2008 06:59:57 -0400

On Jun 24, 2008, at 4:30 AM, Ben Niven-Jenkins wrote:

> organisation
> needed

	I totally agree with you. I would say that the last statement is the  
only
place to spell out the ITU (or IETF for that matter), and of course,  
the reference
to the ITU document at the end.

	--Tom

>> as

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 24 Jun 2008 08:34:45 -0400

The OAM Analysis Team (Nurit, Huub and myself) met today and agreed on
the following:

    1) The goals of the team are to analyze the OAM requirements and
existing solutions and map them to each other.

    2) Indicate the gaps where they exist in the document.

    3) Feed the gaps back into the existing solution/requirements work.

    4) Work via email on a TOC and fill in as much of this as possible by
the deadline. We will publish whatever is ready at that point.

    Open questions were:

    1) MPLS-TP Chairs: Do we need to produce any slides for the next IETF
meeting?
 
    --Tom

---

From: David Ward <[email-masked]>
Date: Tue, 24 Jun 2008 08:18:54 -0500

I'd expect that you do.

-DWard

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 24 Jun 2008 10:21:19 -0400

Ben, much better, I suggest rewording the second paragraph as below:

"
> (MPLS-TP) in order to support the capabilities and 
> functionalities needed for packet transport network services 
> and packet transport network operations.
> 
> This document incorporates requirements identified by ITU-T.
> 

The current text implies that only ITU-T and service provider
requirements are included.  Maybe we should just delete the second
paragraph since we do not need to identify the source of the
requirements as long as the connection to the work in the ITU is clear.

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

Confidentiality Notice:  This message and any attachments may contain
information that is privileged and confidential. If you have reason to
believe that you are not the intended recipient or a person responsible
for delivering this message to an intended recipient, you are hereby
notified that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have reason to believe that
you are not the intended recipient or a person responsible for
delivering this message to an intended recipient, please contact the
sender immediately by reply email and destroy all copies of the original
message.

> Sent: Tuesday, June 24, 2008 4:30 AM
> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract 
> (was RE: next MEAD team meeting)
> 
> I don't like this.  I'm not clear why ITU-T has to be the 
> only organisation drawn out as the source of the requirements 
> and I don't like the idea of having to somehow identify/tag 
> all requirements that are not from the ITU-T as I believe 
> this to be an unnecessary editorial overhead which will only 
> (MPLS-TP) in order to support the capabilities and 
> functionalities needed for packet transport network services 
> and packet transport network operations.
> 
> These requirements are a combination of those derived from 
> the set of requirements specified by ITU-T and requirements 
> received directly from Service Providers.
>

---

From: "George Swallow (swallow)" <[email-masked]>
Date: Tue, 24 Jun 2008 10:21:11 -0400

Yes!  Please do so.

...George

-----Original Message-----
From: [email-masked] on behalf of David Ward
Sent: Tue 6/24/2008 9:18 AM
To: Thomas Nadeau
Cc: [email-masked]; David Ward (wardd); MEAD team
Subject: Re: [Mpls-interop] MPLS OAM Analysis Document
 
I'd expect that you do.

-DWard

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 24 Jun 2008 15:26:32 +0100

Good point.  I'm fine with the text you propose.  Ben

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Tue, 24 Jun 2008 17:08:30 +0200

Agree (and we get to the point where we started :-)) 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of ext Ben
Niven-Jenkins
Sent: Tuesday, June 24, 2008 17:27
To: Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A,
ATTLABS
Cc: MEAD team
Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next
MEAD team meeting)

> believe that you are not the intended recipient or a person 
> responsible for delivering this message to an intended recipient, you 
> are hereby notified that any review, dissemination, distribution, or 
> copying of this message is strictly prohibited. If you have reason to 
> believe that you are not the intended recipient or a person 
> responsible for delivering this message to an intended recipient, 
> please contact the sender immediately by reply email and destroy all 
> copies of the original message.
>  
> 
>> Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: 
>> next MEAD team meeting)
>> 

>> are not from the ITU-T as I believe this to be an unnecessary 
>> editorial overhead which will only get worse as the document evolves.
>> 
>> How about this?
>> 
>> "

>> requirements specified by ITU-T and requirements received directly 
>> from Service Providers.
>>

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 24 Jun 2008 16:10:59 +0100

I might not have been completely clear on what I was agreeing with.  I agree
the 2nd paragraph seems redundant and so we only need the first and third
paragraphs.  Ben

---

From: "Sprecher, Nurit (NSN - IL/Israel - MiniMD)" <[email-masked]>
Date: Tue, 24 Jun 2008 17:12:58 +0200

You were clear. 
I said we got to the starting point where we did not indicate explicitly
the source of the requirements.  

-----Original Message-----
From: ext Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 18:11
To: Sprecher, Nurit (NSN - IL/Israel - MiniMD); Malcolm Betts; Italo
Busi; Loa Andersson; BRUNGARD, DEBORAH A, ATTLABS
Cc: MEAD team
Subject: Re: [Mpls-interop] MPLS-TP Requirements Abstract (was RE: next
MEAD team meeting)

I might not have been completely clear on what I was agreeing with.  I
agree the 2nd paragraph seems redundant and so we only need the first
and third paragraphs.  Ben

>>>>>>> FYI see attached for the latest draft of the MPLS-TP 
>>>>>>> requirements
>>>>>> draft.
>>>>>>>  
>>>>>>> 
>>>>>>> Ben
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>> 
>>>>>>>  
>>>>>>>

---

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 24 Jun 2008 11:26:39 -0400

Hi,

The sentences now seem to have lost the traceability to ITU's MPLS-TP
(formerly TMPLS). Are we doing requirements for G8110 (TMPLS) series of
Recommendations or some other "packet transport network" technology e.g.
G800 (completed in 2007) networks? Is the technology "packet transport
network" viewed as ITU-based or "not necessarily ITU" technology?

If it's for ITU technology, the sentence should at least provide a
pointer:
"This document specifies the requirements for an MPLS Transport Profile
(MPLS-TP) in order to support the capabilities and functionalities of
packet transport networks as defined by ITU-T."

And then, can skip both of the other sentences.

Deborah

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Tuesday, June 24, 2008 10:27 AM
To: Malcolm Betts; Italo Busi; Loa Andersson; BRUNGARD, DEBORAH A,
ATTLABS
Cc: MEAD team

> believe that you are not the intended recipient or a person
responsible