Subject: [PWE3] Doc Shepherd's review of draft-ietf-pwe3-eth-oam-iwk-04

From: "Bocci, Matthew (Matthew)" <[email-masked]>
Date: Thu, 16 Jun 2011 12:12:43 +0200

Authors,

I am the document shepherd for draft-ietf-pwe3-mpls-eth-oam-iwk-04. I have the reviewed the draft, and have some comments, prefixed by **Matthew>, below.

In general the draft is well written, but I would appreciate if you could address the comments below and also those from Yaakov Stein in a new revision of the draft prior to progressing this to AD review.

Best regards,

Matthew

Internet-Draft                           D. Mohan (Editor), Nortel
PWE3 Working Group                      N. Bitar (Editor), Verizon
Intended status: Standards Track          P. Niger, France Telecom
Date Created: March 02, 2011                    S. Delord, Telstra
Expiration Date: September 02, 2011     A. Sajassi (Editor), Cisco
                                                    R. Qiu, Huawei

              MPLS and Ethernet OAM Interworking
             draft-ietf-pwe3-mpls-eth-oam-iwk-04.txt

Abstract

This document specifies the mapping of defect states between
Ethernet Attachment Circuits (ACs) and associated Ethernet
Pseudowires (PWs) connected in accordance to the PWE3 architecture
[RFC3985] to realize an end-to-end emulated Ethernet service. This
document augments the mapping of defect states between a PW and
associated AC of the end-to-end emulated service in [PW-OAM-MSG-
MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack
of Ethernet OAM maturity. However, since then, [Y.1731] and
[802.1ag] have been completed, and this document specifies the
mapping of defect states between Ethernet ACs and corresponding
Ethernet PWs.

**Matthew> The history is not required in the RFC. I suggest removing
the 2nd half of the penultimate sentence and the last sentence.
Also, please remove any references in the abstract, e.g. [RFC3985].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 in September 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Mohan, et. al.       Expires: September 2011               [Page 1]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Conventions used in this document

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 RFC 2119.

Table of Contents

Status of this Memo................................................1
Conventions used in this document..................................2
1. Introduction....................................................3
1.1. Reference Model and Defect Locations..........................4
1.2. Abstract Defect States........................................4
2. Terminology.....................................................6
3. PW Status and Defects...........................................6
3.1 Use of Native Service notification.............................6
3.2 Use of PW Status notification for MPLS PSNs....................7
3.3 Use of BFD Diagnostic Codes....................................7
4. Ethernet AC Defect States Entry or Exit Criteria................8
4.1 AC Receive Defect State Entry or Exit..........................8
4.2 AC Transmit Defect State Entry or Exit.........................8
5. Ethernet AC and PW Defect States Interworking...................9
5.1 PW Receive Defect Entry Procedures.............................9
5.2 PW Receive Defect Exit Procedures.............................10
5.3 PW Transmit Defect Entry Procedures...........................11
5.4 PW Transmit Defect Exit Procedures............................11
5.5 AC Receive Defect Entry Procedures............................12
5.6 AC Receive Defect Exit Procedures.............................12
5.7 AC Transmit Defect Entry Procedures...........................12
5.8 AC Transmit Defect Exit Procedures............................13
6. Acknowledgments................................................13
7. IANA Considerations............................................13
8. Security Considerations........................................13
9. References.....................................................13
9.1 Normative References..........................................13
9.2 Informative References........................................14
Appendix A: Ethernet Native Service Management....................14
Intellectual Property Statement...................................15
Authors' Addresses................................................16

Mohan, et. al.       Expires: September 2011               [Page 2]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

1. Introduction

This document specifies the mapping of defect states between
Ethernet Attachment Circuits (ACs) and associated Ethernet
Pseudowires (PWs) connected in accordance to the PWE3 architecture
[RFC3985] to realize an end-to-end emulated Ethernet service. This
document augments the mapping of defect states between a PW and
associated AC of the end-to-end emulated service in [PW-OAM-MSG-
MAP]. In [PW-OAM-MSG-MAP], Ethernet OAM was not covered due to lack
of Ethernet OAM maturity. However, since then, [Y.1731] and
[802.1ag] have been completed, and this document specifies the
mapping of defect states between Ethernet ACs and corresponding
Ethernet PWs.

**Matthew> See comment above about the document history.

**Matthew> For the sake of clarity, the authors might want to
call out the Ethernet OAM mechanisms covered by this document
as a bulleted list, along with references.

Ethernet Link OAM [802.3] allows some Link defect states to be
detected and communicated across an Ethernet Link. When an Ethernet
AC is an Ethernet PHY, there may be some application of Ethernet
Link OAM [802.3]. Further, E-LMI [MEF16] also allows for some EVC
defect states to be communicated across an Ethernet UNI where
Ethernet UNI constitutes a single hop Ethernet Link (i.e. without
any 802.1Q/.1ad compliant bridges in between). There may be some
application of E-LMI [MEF16] for failure notification across single
hop Ethernet AC in certain deployments that specifically do not
support [802.1ag] and/or [Y.1731]. [Y.1731] and [802.1ag] based
mechanisms are applicable in all types of Ethernet ACs.

Link OAM [802.3] and E-LMI [MEF16] are optional and their
applicability is called out, where applicable.

Native Service (NS) OAM may be transported transparently over the
corresponding PW as user data. For Ethernet, as an example, 802.1ag
continuity check messages (CCMs) between two Maintenance End Points
(MEPs) can be transported transparently as user data over the
corresponding PW. At MEP locations, service failure is detected when
a number of consecutive CCMs are missed.

**Matthew> It might be worth clarifying that various CCM defect
conditions may be raised, including a timeout condition that is
detected after 3.5times the local CCM interval.

MEP locations can be the
PE, the CE or both with different Maintenance Domain Levels.

**Matthew> I think this might be clearer if you rephrase this as:
"MEP peers can exist between CE pairs (MEP of a given MEG reside
on the CEs), PE pairs (the MEPs of a given MEG reside on the PEs),
or even peering between the CE-PE (the MEPs of a given MEG reside
on the PE and CE), as long as the domain nesting rules are maintained."

However, when interworking two networking domains, such as native
Ethernet and PWs to provide an end-to-end emulated service, there is
need to identify the failure domain and location even when a PE
supports both the NS OAM mechanisms and the PW OAM mechanisms. In
addition, scalability constraints may not allow running proactive
monitoring, such as CCMs with transmission on, at a PE to detect the
failure of an Ethernet Virtual circuit (EVC) across the PW domain.
Thus, network driven alarms generated upon failure detection in the
NS or PW domain and their mappings to the other domain are needed.
There are also cases where a PE may not be able to process NS OAM
messages received on the PW even when such messages are defined, as
in Ethernet case, necessitating the need for fault notification
message mapping between the PW domain and the Client domain.

For Multi-Segment PWs (MS-PWs) [RFC5659], Switching PEs (S-PEs)
are not aware of the NS. Thus failure detection and notification at
S-PEs will be based on PW OAM mechanisms. Mapping between PW OAM and

Mohan, et. al.       Expires: September                    [Page 3]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

NS OAM will be required at the Terminating PEs (T-PEs) to propagate
the failure notification to the EVC endpoints.

Similar to [PW-OAM-MSG-MAP], the intent of this document is to
standardize the behavior of PEs with respect to failures on Ethernet
ACs and PWs, so that there is no ambiguity about the alarms
generated and consequent actions undertaken by PEs in response to
specific failure conditions.

1.1.          Reference Model and Defect Locations

Figure 1 is the same as used in [PW-OAM-MSG-MAP] and is reproduced
in this document as a reference to highlight defect locations.

        ACs             PSN tunnel               ACs
                +----+                  +----+
+----+          | PE1|==================| PE2|          +----+
|    |---(a)---(b)..(c)......PW1..(d)..(c)..(f)---(e)---|    |
| CE1|   (N1)   |    |                  |    |    (N2)  |CE2 |
|    |----------|............PW2.............|----------|    |
+----+          |    |==================|    |          +----+
    ^           +----+                  +----+          ^
    |      Provider Edge 1         Provider Edge 2     |
    |                                                  |
    |<-------------- Emulated Service ---------------->|

Customer                                                Customer
Edge 1                                                  Edge 2

             Figure 1: PWE3 Network Defect Locations

**Matthew> I think that the reference architecture for Ethernet is
more complicated than this model, which served us well for other
technologies. Can you illustrate where the NTE is? I think this is
important because it impacts how service provider and customer MEGs
are overlaid on this, and where the MEPs reside. It would also be
worth illustrating in a figure how these MEGs are overlaid.

Customer                                                Customer
Edge 1                                                  Edge 2

1.2.          Abstract Defect States

Abstract Defect States are also introduced in [PW-OAM-MSG-MAP]. This
document uses the same conventions, as shown in Figure 2 from [PW-
OAM-MSG-MAP]. It may be noted however that CE devices, shown in
Figure 2, do not necessarily have to be end customer devices; these
are essentially devices in client network segments that are
connecting to PSN network for the emulated services.

                       +-----+
  ----AC receive ----->|     |-----PW transmit---->
CE1                    | PE1 |                       PE2/CE2
  <---AC transmit------|     |<----PW receive-----
                       +-----+

(arrows indicate direction of user traffic impacted by a defect)

Figure 2: Transmit and Receive Defect States and Notifications

**Matthew> For the 1731/802.1ag case, can you show the possible MEP
 locations on a similar diagram? You should also call out the case
where there are no SP MEPs on the PEs, in which case any faults in
the PW would be detected by the PEs but not mapped to any Ethernet
indications on the ACs. It would be up to CCM between the CEs (of NTEs)
to detect a failure. Here is an example of the kind of diagram I am
referring to, for the case of a simple AC failure. Of course, feel free
To make a proposal:

                          +-------+
                          |       |----PW transmit---->
CE1 ===NID==AC============|  PE1  |                       PE2/CE2
                 |       |<----PW receive-----
                          +-------+
        MEP=L2<----->MEP=L2
       UP|DOwn        DOWN

     MEP=L4----------------NID to NID-----------------MEP=L4
       UP                                               UP

 MEP=L6------------------Customer Domain-----------------------MEP=L6

Mohan, et. al.       Expires: September 2011               [Page 4]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

PE1 may detect a receive defect in local Ethernet AC via one of the
following mechanisms:
- An AIS alarm generated at an upstream node in the client domain
(CE1 in Figure 2) and received by a local MEP associated with the
local AC.
- Failure of the local link on which the AC is configured. Link
failure may be detected via physical failures (e.g., loss of signal
(LoS)), or via Ethernet Link OAM [802.3] critical link event
notifications generated at an upstream node CE1 with "Dying Gasp"
or "Critical Event" indication.
- Failure to receive CCMs on the AC if a local MEP is configured for
the AC.
- A CCM from CE1 with interface status TLV indicating interface down.
Other CCM interface status TLVs will not be used to indicate
failure or recovery from failure.

**Matthew> Given the above suggestion to show the possible MEGs on the
reference architecture, you should  rephrase these sections and following
 similar sections through out the draft. Also, you seem to be limiting
this to interface up/down events on the AC. I think you could also
account for any MAC status defect that affects the overall MAC defect
 state.

AC receive defect at PE1 impacts the ability of PE1 to receive user
traffic from the Client domain attached to PE1 via that AC.

Similarly, PE1 may detect a receive defect in the PW via one of the
following mechanisms:
- Forward Defect indication received from PE2. This defect
indication could point to problems associated with PE2's inability
to transmit traffic on the PW or PE2's inability to receive traffic
on its local AC.
- Unavailability of a PSN path in the PW domain to PE2.

PW forward defect indication received on PE1 impacts the ability of PE1
to receive traffic on the PW.

PE1 may be notified of an AC transmit defect via one of the following
mechanisms:
- CCMs with RDI (Remote Defect Indication) bit set.
- In case when the AC is associated with a physical port, failure of
the local link on which the AC is configured (e.g., LOS or via Ethernet
Link OAM [802.3] critical link event notifications generated at an
upstream node CE1 with "Link Fault" indication).

AC transmit defect impacts the ability of PE1 to send user traffic on
the local AC.

Similarly, PE1 may be notified of a PW transmit defect via Reverse
Defect indication from PE2, which could point to problems associated
with PE2's inability to receive traffic on the PW or PE2's inability
to transmit traffic on its local AC. PW transmit defect impacts PE1
ability to send user traffic toward CE2.

The procedures outlined in this document define the entry and exit
criteria for each of the four defect states with respect to Ethernet
ACs and corresponding PWs, and the consequent actions that PE1 must
support to properly interwork these defect states and corresponding
notification messages between the PW domain and the Native Service
(NS) domain. Receive Defect state should have precedence over
Transmit Defect state in terms of handling, when both transmit and

Mohan, et. al.       Expires: September 2011               [Page 5]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

receive defect states are identified simultaneously.

2. Terminology

This document uses the following terms:
AIS       Alarm Indication Signal
MD Level  Maintenance Domain (MD) Level which identifies a value
          in the range of 0-7 associated with Ethernet OAM frame.
          MD Level identifies the span of the Ethernet OAM frame.
MEP       Maintenance End Point is responsible for origination
          and termination of OAM frames for a given MEG
MIP       Maintenance Intermediate Point is located between peer
          MEPs and can process OAM frames but does not initiate
          or terminate them
RDI       Remote Defect Indication

Further, this document also uses the terminology and conventions
used in [PW-OAM-MSG-MAP].

3. PW Status and Defects

[PW-OAM-MSG-MAP] introduces a range of defects that impact PW
status. All these defect conditions are applicable for Ethernet PWs.

Similarly, there are different mechanisms described in [PW-OAM-MSG-
MAP] to detect PW defects, depending on the PSN type (e.g. MPLS PSN,
MPLS-IP PSN). Any of these mechanisms can be used when monitoring
the state of Ethernet PWs.  [PW-OAM-MSG-MAP] also discusses the
applicability of these failure detection mechanisms.

3.1 Use of Native Service (NS) notification

There is no NS fault notification capability currently specified for
Ethernet PWs. However, with the completion of Ethernet OAM work,
this capability should be added. This includes the ability to create
a MEP associated with the Ethernet PW on the PE. The native service
notification options include:

**Matthew> The above text seems out of date, since this draft addresses
many Ethernet fault notification mechanisms.

- AIS Frames sent by the local MEP to the MEP on the remote PE when
the MEP needs to convey PE receive defects, and when CCM
transmission is configured not to be turned ON.
- Suspension of CCM frames transmission from the MEP to the peer MEP
on the other PE to convey PE receive defects, when CCM
transmission is configured to be turned ON.
- RDI bit set in transmitted CCM frames, when loss of CCMs from the
peer MEP is detected or PE needs to convey PW reverse defects.

These NS OAM notifications are inserted into the corresponding PW.

Similarly, when the defect conditions are cleared, a PE can take one
of the following actions, depending on the mechanism that was used
for failure notification, to clear the defect sate on the peer PE:

Mohan, et. al.       Expires: September 2011               [Page 6]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

- Stop AIS Frame transmission from the local MEP to the MEP on the
remote PE to clear PW receive defects;
- Resuming CCM frames transmission from the MEP to the peer MEP to
clear PW forward defects notification, when CCM transmission is
configured to be turned ON.
- Clearing RDI indication in transmitted CCM frames, to clear PW
transmit defects notification.

**Matthew> Is there any impact of Y.1731 CSF? Is that in scope of this
draft or will it be addressed separately?

3.2 Use of PW Status notification for MPLS PSNs

When PWs are established using LDP, LDP status notification
signaling SHOULD be used as the default mechanism to signal AC and
PW status and defects [RFC4447]. For PWs established over an MPLS or
MPLS-IP PSN using other mechanisms (e.g. static configuration),
inband signaling using VCCV-BFD [RFC5885] SHOULD be used to convey AC
and PW status and defects.

**Matthew> The use of MUST and SHOULD above conflicts with the OAM message
 mapping draft. I suggest you align with that draft.

[PW-OAM-MSG-MAP] identifies the following PW defect status
codepoints:
- Forward defect: corresponds to a logical OR of local AC (ingress)
Receive fault, local PSN-facing PW (egress) transmit fault, and PW
not forwarding fault.
- Reverse defect: corresponds to a logical OR of local AC (egress)
transmit fault and local PW PSN-facing (ingress) receive fault.

There are also scenarios where a PE carries out PW label withdrawal
instead of PW status notification. These include administrative
disablement of the PW or loss of Target LDP session with the peer
PE.

3.3 Use of BFD Diagnostic Codes

When using VCCV, the control channel (CC) type and Connectivity
Verification (CV) Type are agreed on between the peer PEs using the
OAM capability sub-TLV signaled as part of the interface parameter
TLV when using FEC 129 and the interface parameter sub-TLV when
using FEC 128.

As defined in [PW-OAM-MSG-MAP], when CV type of 0x04 0r 0x1 is used
to indicate that BFD is used for PW fault detection only, PW defect
is detected via the BFD session while other defects, such as AC
detected or PE internal defects preventing it from forwarding traffic,
are communicated via LDP Status notification message in MPLS and
MPLS-IP PSN or other mechanisms in L2TP-IP PSN.

Similarly, when CV type of 0x08 or 0x20 is used to indicate that BFD
is used for both PW fault detection and AC/PW Fault Notification,
all defects are signaled via BFD.

Mohan, et. al.       Expires: September 2011               [Page 7]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

4. Ethernet AC Defect States Entry or Exit Criteria

4.1 AC Receive Defect State Entry or Exit

PE1 enters the AC Receive Defect state if any of the following
conditions are met:

- It detects or is notified of a physical layer fault on the
Ethernet interface. Ethernet link failure can be detected based on
loss of signal (LoS) or via Ethernet Link OAM [802.3] critical
link event notifications generated at an upstream node CE1 with
"Dying Gasp" or "Critical Event" indication.
- A MEP associated with the local AC receives an Ethernet AIS frame.
- A MEP associated with the local AC does not receive CCM frames
from the peer MEP in the client domain (e.g. CE1) within a
configurable interval equal to a multiple (e.g. 3.5) of the CCM
transmission period configured for the MEP. This is the case when
CCM transmission is configured to be turned ON.

**Matthew> I don;t think the interval is configurable, but the
transmission period is. So the text above should read: "A MEP
associated with the local AC does not receive CCM frames from the
peer MEP in the client domain (e.g. CE1) within an interval equal to a
multiple (e.g. 3.5) of the CCM transmission period configured for
the MEP."

- A CCM with interface status TLV indicating interface down. Other
CCM interface status TLVs will not be used to indicate
failure or recovery from failure.

PE1 exits the AC Receive Defect state if all of the conditions that
resulted in entering the defect state are cleared. This includes all
of the following conditions:

- Any physical layer fault on the Ethernet interface, if detected or
notified previously, iss removed (e.g. via loss of signal (LoS), or
Ethernet Link OAM [802.3] critical link event notifications with
"Dying Gasp" or "Critical Event" indication cleared at an upstream
node CE1).
- A MEP associated with the local AC does not receive any Ethernet
AIS frame within a period indicated by previously received AIS, if
AIS was resulted in entering the defect state.

- A MEP associated with the local AC and configured with CCM
transmission on receives a configured number (e.g. 3 or more) of
consecutive CCM frames from the peer MEP on CE1 within an interval
equal to a multiple (e.g. 3.5) of the CCM transmission period
configured for the MEP.

- CCM indicates interface status up.

4.2 AC Transmit Defect State Entry or Exit

PE1 enters the AC Transmit Defect state if any of the following
conditions is met:

- It detects or is notified of a physical layer fault on the
Ethernet interface (e.g. via loss of signal (LoS) or Ethernet Link
OAM [802.3] critical link event notifications generated at an
upstream node CE1 with "Link Fault" indication).
- A MEP configured with CCM transmission turned ON and associated
with the local AC receives a CCM frame, with its RDI bit set, from
peer MEP in the client domain (e.g. CE1).

Mohan, et. al.       Expires: September 2011               [Page 8]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

PE1 exits the AC Transmit Defect state if all of the conditions that
resulted in entering the defect state are cleared. This includes all
of the following conditions:

- Any physical layer fault on the Ethernet interface, if detected or
notified previously, is removed (e.g. via Ethernet Link OAM
[802.3] critical link event notifications with "Link Fault"
indication cleared at an upstream node CE1).
- A MEP configured with CCM transmission turned ON and associated
with the local AC does not receive a CCM frame with RDI bit set,
having received a previous CCM frame with RDI bit set from the
peer MEP in the client domain (e.g. CE1).

5. Ethernet AC and PW Defect States Interworking

5.1 PW Receive Defect Entry Procedures

When the PW status on PE1 transitions from working to PW Receive
Defect state, PE1's ability to receive user traffic from CE2 is
impacted. As a result, PE1 needs to notify CE1 about this problem.

Upon entry to the PW Receive Defect state, the following must be
done:

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is not configured to be turned ON, the MEP
associated with the AC must transmit AIS frames periodically to the
MEP in the client domain (e.g. on CE1) based on configured AIS
transmission period.

**Matthew> Is this an UP MEP pointing away from the AC into the PSN?
Please clarify.

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, and the MEP
associated with the AC is configured to support Interface Status TLV
in CCM messages, the MEP associated with the AC must transmit CCM
frames with Interface Status TLV as being down to the peer MEP in
the client domain (e.g. on CE1).

**Matthew> Please clarify if this is a DOWN MEP.

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, and the MEP
associated with the AC is configured to not support Interface Status
TLV in CCM messages, the MEP associated with the AC must stop
transmitting CCM frames to the peer MEP in the client domain (e.g.
on CE1).

**Matthew> Ditto

- If PE1 is configured to run E-LMI [MEF16] with CE1 and if E-LMI
is used for failure notification, PE1 must transmit E-LMI
asynchronous STATUS message with report type Single EVC Asynchronous
Status indicating that PW is Not Active.

Further, when PE1 enters the Receive Defect state, it must assume
that PE2 has no knowledge of the defect and must send reverse defect

Mohan, et. al.       Expires: September 2011               [Page 9]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

failure notification to PE2. For MPLS PSN or MPLS-IP PSN, this is
done via either a PW Status notification message indicating a
reverse defect; or via VCCV-BFD diagnostic code of reverse defect if
VCCV CV type of 0x08 had been negotiated. When Native Service OAM
mechanism is supported on PE, it can also use the NS OAM
notification as specified in Section 3.1.

If PW receive defect is entered as a result of a forward defect
notification from PE2 or via loss of control adjacency, no
additional action is needed since PE2 is expected to be aware of the
defect.

Note: The location of the MEP associated with the local AC within a
PE can be a down MEP on the port associated with the AC or an Up MEP
associated with an emulated LAN interface within the PE, as defined
in L2VPN framework for a VPLS PE. Though for the purposes of VPWS
service, VPLS PE architecture is not mandatory, the VPLS PE
architecture serves as a generic case where the PE can support both
VPWS and VPLS services.

**Matthew> I am not sure that fault propagation as described in this draft
is applicable to mp-mp services such as VPLS, since there is a
many-many relationship between PWs and ACs at a given PE.

5.2 PW Receive Defect Exit Procedures

When the PW status transitions from PW Receive Defect state to
working, PE1's ability to receive user traffic from CE2 is restored.
As a result, PE1 needs to cease defect notification to CE1 by
performing the following:

- If PE1 is configured with a a MEP associated with the local AC and
CCM transmission is not configured to be turned ON, the MEP
associated with the AC must stop transmitting AIS frames towards the
peer MEP in the client domain (e.g. on CE1).

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, and the MEP
associated with the AC is configured to support Interface Status TLV
in CCM messages, the MEP associated with the AC must transmit CCM
frames with Interface Status TLV as being Up to the peer MEP in the
client domain (e.g. on CE1).

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, and the MEP
associated with the AC is configured to not support Interface Status
TLV in CCM messages, the MEP associated with the AC must resume
transmitting CCM frames to the peer MEP in the client domain (e.g.
on CE1).

- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
used for fault notification, PE1 must transmit E-LMI asynchronous
STATUS message with report type Single EVC Asynchronous Status
indicating that PW is Active.

Mohan, et. al.       Expires: September 2011              [Page 10]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

Further, if the PW receive defect was explicitly detected by PE1, it
must now notify PE2 about clearing of Receive Defect state by
clearing reverse defect notification. For PWs over MPLS PSN or MPLS-
IP PSN, this is either done via PW Status message indicating
working; or via VCCV-BFD diagnostic code if VCCV CV type of 0x08/0x20
had been negotiated. When Native Service OAM mechanism is supported
on PE, it can also clear the NS OAM notification specified in Section
3.1.

If PW receive defect was established via notification from PE2 or
via loss of control adjacency, no additional action is needed, since
PE2 is expected to be aware of the defect clearing.

5.3 PW Transmit Defect Entry Procedures

When the PW status transitions from working to PW Transmit Defect
state, PE1's ability to transmit user traffic to CE2 is impacted. As
a result, PE1 needs to notify CE1 about this problem which has been
detected by PE1.

Upon entry to the PW Transmit Defect state, the following must be
done:

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, the MEP associated
with the AC must set the RDI bit in transmitted CCM frames sent to
the peer MEP in the client domain (e.g. on CE1).

**Matthew> Is it a MUST to set RDI? Or is it a MAY, since you may
also use the interface status TLV?

- If PE1 is configured to run E-LMI [MEF16] with CE1 and E-LMI is
used for fault notification, PE1 must transmit E-LMI asynchronous
STATUS message with report type Single EVC Asynchronous Status
indicating that PW is Not Active.

5.4 PW Transmit Defect Exit Procedures

When the PW status transitions from PW Transmit Defect state to
working, PE1's ability to transmit user traffic to CE2 is restored.
As a result, PE1 needs to cease defect notifications to CE1 and
perform the following

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, the MEP associated
with the AC must clear the RDI bit in the transmitted CCM frames to
the peer MEP (e.g. on CE1).

- If PE1 is configured to run E-LMI [MEF16] with CE1, PE1 must
transmit E-LMI asynchronous STATUS message with report type Single
EVC Asynchronous Status indicating that PW is Active.

Mohan, et. al.       Expires: September 2011              [Page 11]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

5.5 AC Receive Defect Entry Procedures

When AC status transitions from working to AC Receive Defect state,
PE1's ability to receive user traffic from CE1 is impacted. As a
result, PE1 needs to notify PE2 and CE1 about this problem.

If the AC receive defect is detected by PE1, it must notify PE2 in
the form of a forward defect notification.

When NS OAM is not supported on PE1, and for PW over MPLS PSN or
MPLS-IP PSN, forward defect notification is done via either PW
Status message indicating a forward defect or via VCCV-BFD
diagnostic code of forward defect if VCCV CV type of 0x08/0x20 had
been negotiated.

When Native Service OAM mechanism is supported on PE1, it can also
use the NS OAM notification as specified in Section 3.1.

In addition to above actions, PE1 must perform the following:

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, the MEP associated
with AC must set the RDI bit in transmitted CCM frames.

5.6 AC Receive Defect Exit Procedures

When AC status transitions from AC Receive Defect to working, PE1's
ability to receive user traffic from CE1 is restored. As a result,
PE1 needs to cease defect notifications to PE2 and CE1 and perform
the following:

- When NS OAM is not supported on PE1 and for PW over MPLS PSN or
MPLS-IP PSN, forward defect notification is cleared via PW Status
message indicating a working state; or via VCCV-BFD diagnostic code
if VCCV CV type of 0x08 or 0x20 had been negotiated.

- When Native Service OAM mechanism is supported on PE1, PE1 clears
the NS OAM notification as specified in Section 3.1.

- If PE1 is configured with a MEP associated with the local AC and
CCM transmission is configured to be turned ON, the MEP associated
with the AC must clear the RDI bit in transmitted CCM frames to the
peer MEP in the client domain (e.g. on CE1).

5.7 AC Transmit Defect Entry Procedures

When AC status transitions from working to AC Transmit Defect, PE1's
ability to transmit user traffic to CE1 is impacted. As a result,
PE1 needs to notify PE2 about this problem.

Mohan, et. al.       Expires: September 2011               [Page 12]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

If the AC transmit defect is detected by PE1, it must notify PE2 in
the form of a reverse defect notification.

When NS OAM is not supported on PE, in PW over MPLS PSN or MPLS-IP
PSN, reverse defect notification is either done via PW Status
message indicating a reverse defect; or via VCCV-BFD diagnostic code
of reverse defect if VCCV CV type of 0x08 or 0x20 had been negotiated.

When Native Service OAM mechanism is supported on PE, it can also
use the NS OAM notification as specified in Section 3.1.

5.8 AC Transmit Defect Exit Procedures

When AC status transitions from AC Transmit defect to working, PE1's
ability to transmit user traffic to CE1 is restored. As a result,
PE1 needs to clear notification to PE2.

If the AC Transmit defect is cleared, PE1 must clear reverse defect
notification to PE2.

When NS OAM is not supported on PE1 and for PW over MPLS PSN or
MPLS-IP PSN, reverse defect notification is cleared via either a PW
Status message indicating a working state or via VCCV-BFD diagnostic
code of if VCCV CV type of 0x08 had been negotiated.

When Native Service OAM mechanism is supported on PE1, PE1 can clear
NS OAM notification as specified in Section 3.1.

6. Acknowledgments

The authors are thankful to Samer Salam for his valuable
comments.

7. IANA Considerations

This document has no actions for IANA.

8. Security Considerations

This document does not impose any security concerns since it makes
use of existing OAM mechanisms and mapping of these messages does
not change inherent security features.

9. References

9.1 Normative References

Mohan, et. al.       Expires: September 2011              [Page 13]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

[Y.1731] "OAM Functions and mechanisms for Ethernet based networks",
ITU-T Y.1731, May 2006

[802.1ag] "Connectivity Fault Management", IEEE 802.1ag/D8.1, Jul
2007

[RFC4447] "Pseudowire Setup and Maintenance using LDP", RFC4447,
April 2006

[RFC5885] "Bidirectional Forwarding Detection (BFD) for the
Pseudowire Virtual Circuit Connectivity Verification (VCCV)",
RFC5885, June 2010

[802.3] "CDMA/CD access method and physical layer specifications",
Clause 57 for Operations, Administration and Maintenance, 2005

[MEF16] "Ethernet Local Management Interface", MEF16, January 2006

9.2 Informative References

[RFC3985] "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture",
RFC 3985, March 2005

[PW-OAM-MSG-MAP] "Pseudo Wire (PW) OAM Message Mapping", draft-ietf-
pwe3-oam-msg-map-14.txt, Work in progress, October 2010

[RFC5659] "An Architecture for Multi-Segment Pseudo Wire
Emulation Edge-to-Edge", RFC5659, October 2009

Appendix A: Ethernet Native Service Management

Ethernet OAM mechanisms are broadly classified into two categories:
Fault Management (FM) and Performance Monitoring (PM). ITU-T Y.1731
provides coverage for both FM and PM while IEEE 802.1ag provides
coverage for a sub-set of FM functions.

Ethernet OAM also introduces the concept of Maintenance Entity (ME)
which is used to identify the entity that needs to be managed. A ME
is inherently a point-to-point association. However, in case of a
multipoint association, Maintenance Entity Group (MEG) consisting of
different MEs is used. IEEE 802.1 uses the concept of Maintenance
Association (MA) which is used to identify both point-to-point and
multipoint associations. Each MA consists of Maintenance End Points
(MEPs) which are responsible for originating OAM frames. In between
the MEPs, there can also be Maintenance Intermediate Points (MIPs)
which do not originate OAM frames however do respond to OAM frames
from MEPs.

Mohan, et. al.       Expires: September 2011              [Page 14]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

Ethernet OAM allows for hierarchical maintenance entities to allow
for simultaneous end-to-end and segment monitoring. This is achieved
by having a provision of up to 8 Maintenance Domain Levels (MD
Levels) where each MEP or MIP is associated with a specific MD
Level.

It is important to note that the common set of FM mechanisms between
IEEE 802.1ag and ITU-T Y.1731 are completely compatible.

The common FM mechanisms include:

1) Continuity Check Messages (CCM)
2) Loopback Message (LBM) and Loopback Reply (LBR)
3) Linktrace Message (LTM) and Linktrace Reply (LTR)

CCM messages are used for fault detection including misconnections
and mis-configurations. Typically CCM messages are sent as multicast
frames or Unicast frames and also allow RDI notifications. LBM/LBR
are used to perform fault verification, while also allow for MTU
verification and CIR/EIR measurements. LTM/LTR can be used for
discovering the path traversed between a MEP and another target
MIP/MEP in the same MA. LTM/LTR also allow for fault localization.

In addition, ITU-T Y.1731 also specifies the following FM functions:

4) Alarm Indication Signal (AIS)

AIS allows for fault notification to downstream and upstream nodes.

Further, ITU-T Y.1731 also specifies the following PM functions:

5) Loss Measurement Message (LMM) and Reply (LMR)
6) Delay Measurement Message (DMR) and Reply (DMR)
7) 1-way Delay Message (1DM)

Mohan, et. al.       Expires: September 2011              [Page 15]
Internet-Draft    MPLS & Ethernet OAM Interworking         Mar 2011

While LMM/LMR is used to measure Frame Loss Ratio (FLR), DMM/DMR is
used to measure single-ended (aka two-way) Frame Delay (FD) and
Frame Delay Variation (FDV, also known as Jitter). 1DM can be used
for dual-ended (aka one-way) FD and FDV measurements.

Authors' Addresses

Dinesh Mohan
Nortel
3500 Carling Ave
Ottawa, ON K2H8E9
Email: [email-masked]

Nabil Bitar
Verizon Communications
117 West Street
Waltham, MA 02451
Email : [email-masked]

Simon Delord
Telstra
242 Exhibition St
Melbourne VIC 3000, Australia
E-mail: [email-masked]

Philippe Niger
France Telecom
2 av. Pierre Marzin
22300 LANNION, France
E-mail: [email-masked]

Ali Sajassi
Cisco
170 West Tasman Drive
San Jose, CA  95134, US
Email: [email-masked]

Ray Qiu
Email: [email-masked]

Mohan, et. al.       Expires: September 2011              [Page 16]