Subject: Re: [Mpls-interop] next MEAD team meeting

From: David Sinicrope <[email-masked]>
Date: Thu, 19 Jun 2008 14:58:07 -0700

Hi All,
I'll be chairing a WG meeting at the IP/MPLS Forum in Vancouver at the same time as the call.
Could I impose on a volunteer to take notes for this call?
Thanks,
David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, June 19, 2008 11:00 AM
To: MEAD team
Subject: [Mpls-interop] next MEAD team meeting

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
_______________________________________________
Mpls-interop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-interop

---

From: <[email-masked]>
Date: Sun, 22 Jun 2008 08:49:18 -0400

I want to second Ben here - a dynamic control plane MUST be available for the SP to choose to use - if it is optional for implementation, then it will be left for "the next release".  

Cheers,
Andy 

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Thomas Nadeau <[email-masked]>; Sprecher, Nurit (NSN - IL/Israel - MiniMD) <[email-masked]>; Loa Andersson <[email-masked]>; MEAD team <[email-masked]>
Cc: Weingarten,Yaacov (NSN - IL/Israel - MiniMD) <[email-masked]>
Sent: Sun Jun 22 08:39:51 2008
Subject: Re: [Mpls-interop] next MEAD team meeting

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

On 22/06/2008 12:51, "Thomas Nadeau" <[email-masked]> wrote:

> 
> 
> 
> On 6/22/08 5:45 AM, "Sprecher, Nurit (NSN - IL/Israel - MiniMD)"
> <[email-masked]> wrote:
> 
>> 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.).
> 
>     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.
> 
>> 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...
> 
>     I am not arguing against static; I am arguing for dynamic to be in there
> as well.
> 
>> Transport OAM capabilities don't exist for LSP and PWE independent of
>> configuration mechanism (management plane or GMPLS or PWE control
>> 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
>> (e.g. GMPLS or, IGP, RSVP, BGP, LDP)", etc.
>> Best regards,
>> Nurit
>> 
>> 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
>> 
>> 
>> 
>> 
>> 
>> 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].
>> 
>>    MPLS is a maturing packet technology and it is already playing an
>> 
>> 
>> 
>> 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: David Sinicrope <[email-masked]>
Date: Mon, 23 Jun 2008 18:25:19 -0700

Nevermind, we rearranged the agenda so that Matthew, Andy and I can attend this call.
Thanks,
David

-----Original Message-----
From: David Sinicrope
Sent: Thursday, June 19, 2008 4:34 PM
To: [email-masked]'
Subject: RE: [Mpls-interop] next MEAD team meeting

Hi All,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa Andersson
Sent: Thursday, June 19, 2008 11:00 AM
To: MEAD team
Subject: [Mpls-interop] next MEAD team meeting

All,

/Loa

--
Loa Andersson