Subject: [PWE3] Remote Loopback Control

From: Ron Cohen <[email-masked]>
Date: Tue, 27 Apr 2010 12:50:54 +0300

Hi pwe3ers,

Assume the following setup:

DS1---CES-A---SATOP-PW---CES-B---DS1

A DS1 SATOP pseudo-wire is setup up between two network elements CES A and B.

There is a need, coming from the field, to set (and release) the
remote side of the pseudo-wire to loopback state. That is, to be able
to ask CES-A for remote loopback on CES-B, i.e. being able to test
from CES-A the correct operation of the SATOP-PW.

I discussed this issue with Sasha, to check whether he is also
familiar with the request to support this feature and to consult how
to best use or extend the pw protocol suite for this purpose.

I guess the first question to the group is whether others have also
seen the need for remote loopback control (for SATOP and other pw-s).

Best,
Ron

---

From: Osnat Shasha <[email-masked]>
Date: Tue, 27 Apr 2010 13:29:19 +0300

Hi Ron,

Yes - there is.

Osnat Shasha
Axerra Networks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Cohen
Sent: Tuesday, April 27, 2010 12:51 PM
To: PWE3 (IETF)
Subject: [PWE3] Remote Loopback Control

Hi pwe3ers,

Best,
Ron
_______________________________________________
pwe3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pwe3

---

From: Phil Bedard <[email-masked]>
Date: Tue, 27 Apr 2010 11:02:26 -0400

I have definitely seen a need for this.  We see the most demand for carriers wanting the ability to send in-band facility loop codes to loop CES B from their own test equipment connected to CES A.  Today it requires we put a smartjack on the end of the CES circuit which is sub-optimal.  The interpretation of the loop codes is probably outside the scope of PWE3, but the messaging to initiate and teardown the loop is definitely something we'd like to see defined.  

We've actually seen more call for PW loopbacks on ethernet circuits since it can be used as a mechanism to perform per-service loopbacks. 

Phil

---

From: Osnat Shasha <[email-masked]>
Date: Wed, 28 Apr 2010 15:54:18 +0300

Yes - What you are describing is T1 in-band far-end loopback activation which is one type of activating far-end loopback on Ethernet circuit.
And yes, according to Ron's mail, the patterns to initiate and to release this far-end loopback needed to be expressed in the pw protocol (I assume that for this type of loopback you may use other patterns...)

We should also cover the E1 far-end loopback on Ethernet circuit as well (activation of that may be implementation depended). 

- Osnat.

-----Original Message-----
From: Phil Bedard [mailto:[email-masked]] 
Sent: Tuesday, April 27, 2010 6:02 PM
To: Osnat Shasha
Cc: Ron Cohen; PWE3 (IETF)
Subject: Re: [PWE3] Remote Loopback Control

Phil

---

From: Ron Cohen <[email-masked]>
Date: Thu, 29 Apr 2010 10:53:16 +0300

Hi

In summary, there is a need for this function for DS1 SATOP pws, and
support for E1 SATOP pws is also desired.

I think that this functionality is useful for all pw types whenever a
pw is setup between two administrative domains. For example, assume
CES-A is a customer-premise-equipment (like my DSL router at home)
which is not managed by the provider, and CES-B is a provider's box.
In these scenarios it is useful to signal loopback request across the
pw to debug connectivity. It is not clear to me whether this is real
enough scenario so unless others also think this functionality is
useful in general I believe support for remote loopback signaling for
all pw types is only a 'nice to have' requirement.

Other requirements for such solution is simplicity, backward
compatibility and support for both dynamically and statically-set pws.

How do we signal remote loopback? With Sasha's help the following
three options (or some combinations thereof) were identified:

1. Use a combination of M-bits in PWE3 SATOP header for signaling
loopack activation de-activation

2. Use VCCV. Allocate new associated channel type for carrying remote
loopback control.

3. Add status bit(s) and use PW status messages for signaling. For
static pws use the method defined in 'Pseudowire Status for Static
Pseudowires' draft.

The first solution limits applicability of the solution to SATOP pws
only (M-bits are not used for SATOP pws). The first solution requires
more work to address backward compatibility with existing
implementations. I feel a bit uncomfortable using the third solution
(pw status) as loopback commands are not strictly status - they are
control commands. My preference is the second option (vccv) for
carrying loopback commands. Optionally I do think we need to extend
also the pw status message by adding a 'in-loopback' status bit which
is set (and reset) through the vccv control channel.

Feedback appreciated:

- More feedback on the need for a standard solution for remote
loopback in SATOP and other PWs
- Feedback on additional requirements
- Feedback on either of the 3 solutions (or any others we missed)
- Feedback on the preferred solution (vccv for control, status for
in-loopback status).

Best,
Ron

---

From: [email-masked]
Date: Thu, 29 Apr 2010 17:02:31 +0800

hi
I think this Loopback is client service layer function. I don't know what 
relation with PW layer？
this OAM function in client service layer is independent of pw layer OAM 
function.
maybe i can't understand what you say.

best regards
liu

Ron Cohen <[email-masked]> 
发件人:  [email-masked]
2010-04-29 15:53

收件人
"PWE3 (IETF)" <[email-masked]>
抄送

主题
Re: [PWE3] Remote Loopback Control

Hi

Feedback appreciated:

Best,
Ron

On Wed, Apr 28, 2010 at 3:54 PM, Osnat Shasha <[email-masked]> wrote:
> Yes - What you are describing is T1 in-band far-end loopback activation 
which is one type of activating far-end loopback on Ethernet circuit.
> And yes, according to Ron's mail, the patterns to initiate and to 
release this far-end loopback needed to be expressed in the pw protocol (I 
assume that for this type of loopback you may use other patterns...)
>
> We should also cover the E1 far-end loopback on Ethernet circuit as well 
(activation of that may be implementation depended).
> I have definitely seen a need for this.  We see the most demand for 
carriers wanting the ability to send in-band facility loop codes to loop 
CES B from their own test equipment connected to CES A.  Today it requires 
we put a smartjack on the end of the CES circuit which is sub-optimal. 
 The interpretation of the loop codes is probably outside the scope of 
PWE3, but the messaging to initiate and teardown the loop is definitely 
something we'd like to see defined.
>
> We've actually seen more call for PW loopbacks on ethernet circuits 
since it can be used as a mechanism to perform per-service loopbacks.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Yaakov Stein <[email-masked]>
Date: Thu, 29 Apr 2010 13:01:52 +0300

Ron

I think I am missing something.

If you have a SAToP PW, it carries all the "special" bits,
including those that trigger a remote TDM device to go into loopback.

So what else do you need ?

When using structure-aware methods, you can also transport the overhead bits
even if you overwrite the FAS.

If you want the remote PE to perform the loopback,
then you are not testing the entire end-to-end TDM service.
You can always check the PW integrity with VCCV echoes.

I think it is a bad idea to make a PW-specific pseudoTDM-loopback mechanism.
If you want to test the PW, you can. 
If you want to test the end-to-end TDM, you can.

I saw a comment that you might be able to save monetary outlay
on smartjack or similar TDM loopback equipment. Yes, this is true.
However, TDM PWs are here to emulate as best they can the TDM service,
not to add features to it (even if they may save some OPEX).
If there is a desire to save OPEX in end-to-end TDM circuit,
then please take this need to the ITU.

Y(J)S

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ron Cohen
Sent: Tuesday, April 27, 2010 12:51
To: PWE3 (IETF)
Subject: [PWE3] Remote Loopback Control

Hi pwe3ers,

Best,
Ron

---

From: Carlos Pignataro <[email-masked]>
Date: Thu, 29 Apr 2010 09:07:11 -0400

Group,

Would <http://tools.ietf.org/html/draft-boutros-mpls-tp-loopback-03>,
"Operating MPLS Transport Profile LSP in Loopback Mode", be relevant to
this discussion?

--->8---
1. Introduction
...
   The mechanisms in this document apply to asso-
   ciated bidirectional paths as defined in [7], which include MPLS-TP
   LSPs, bi-directional RSVP-TE tunnels, pseudowires (PW), and Multi-
   segment PWs.
--->8---

Thanks,

-- Carlos.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 29 Apr 2010 09:20:10 -0400

This draft does indeed seem like a reasonable place to start from.

    --Tom

---

From: Ron Cohen <[email-masked]>
Date: Thu, 29 Apr 2010 18:54:26 +0300

Hi Carlos, all,

Thanks for the reference. Indeed the problem I described is covered in
the much larger scope of loopback control addressed in this draft.

The concerns I have after a quick read are:

- The scope being tied with MPLS TP. I want to make sure that the
solution is valid regardless of transport (IP, MPLS, etc).

- Simplicity: The loopback control mechanisms defined in this draft do
not seem to be overly complex, as a small subset of the described
protocols can be used for the specific SATOP loopback problem.
However, it is not clear to me from the draft which subset is going to
be mandated for minimal implementation, which hopefully should not be
too far from the subset required for the SATOP problem.

Can you elaborate more on the status of the draft ?

Can you address my concerns? Any other relevant concerns?

What are the best next steps?

Best,
Ron

---

From: Ron Cohen <[email-masked]>
Date: Thu, 29 Apr 2010 19:40:20 +0300

Hi Yaakov,

Please see below

> So what else do you need ?

I don't have access to these bits in SATOP. The IWF is indifferent.
The NSP (e.g. liu/framer) can usually monitor these special bits if
received from the DS1 line (at CES-A) at the entry to the pw, but not
if these bits are sent at the end of the pw to the DS1 line (at
CES-B).

> You can always check the PW integrity with VCCV echoes.

Good point. I agree. But it doesn't address the smartjack scenario.

> then please take this need to the ITU.

I don't necessarily share you view point on IETF vs. ITU roles. I
agree that the WG does not need to address all problems and all
scenarios. This is part of the discussion; the WG needs to decide if
this problem should be addressed or not.

Best,
Ron

---

From: Sami Boutros <[email-masked]>
Date: Thu, 29 Apr 2010 10:46:45 -0700

Hi Ron,

>solution is valid regardless of transport (IP, MPLS, etc).

The mechanisms in the draft apply MPLS-TP LSPs, bi-directional
RSVP-TE tunnels, pseudowires (PW), and Multi-segment PWs.

>too far from the subset required for the SATOP problem.

The draft defines 2 functions which are loopback and Lock, Lock to take
the LSP/PW out of service, then perform the loopback function.

We originally had an OAM loopback defined but we are taking this out of
the draft, and the draft will only cover DataPacket loopback.

>Can you elaborate more on the status of the draft ?

We re-published the draft last March.

Thanks,

Sami

---

From: Phil Bedard <[email-masked]>
Date: Thu, 29 Apr 2010 17:12:53 -0400

> then please take this need to the ITU.

I made the comment and I also said I don't think interpreting the actual inband codes is an IETF/PWE3 function.  That is something which the vendors need to implement as features on their equipment.   The part in scope for PWE3 is if a vendor does implement a feature to sniff the wire for certain bits, provide the signaling constructs to loopback the pseudowire on the far end.   This doesn't exactly emulate a smartjack since you are looping the PWE3 service and not the framer on the far end but it's close enough for most customers.  There are vendors who do this today through proprietary OAM signaling to the far-end.

On the Ethernet side, we would like to see PW level loopback for throughput testing to eliminate NIDs which act as Ethernet smartjacks.   We are seeing support by some vendors for sending/receiving Y.1731 LB messages at line rate which can be used for throughput testing, probably a better long-term solution, but PWE3 has better support than Y.1731.  

Phil

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 30 Apr 2010 16:55:35 +0300

Ron

Let's try to clarify precisely what you want to do.

Who is initiating the loopback request, and who should be looping back?

The TDM endpoint can request the loopback in the usual way,
and MUST NOT be aware that the TDM is going part of the way over
a PW, except for the differences between a true TDM service and an emulated one
detailed in the applicability statements (e.g., timing, ...)

If I understand you now, you want to request from the PE,
since otherwise why do you care if it is SAToP or not ?

If the loopback is to be performed at the remote PE,
then that functionality is already present.

If the loopback is to be performed at the remote TDM device,
then, once again, this must be requested by its peer.
Doing otherwise would be a serious layer violation.

I am not raising a political matter of ITU vs IETF,
I am asking whether you are asking for TDM functionality or PWE functionality.
If you are asking for some layer violating mixture then this should be avoided
at all costs (yes, including costs of implementing the standard TDM loopback)

Y(J)S 

-----Original Message-----
From: Ron Cohen [mailto:[email-masked]] 
Sent: Thursday, April 29, 2010 19:40
To: Yaakov Stein
Cc: PWE3 (IETF)
Subject: Re: [PWE3] Remote Loopback Control

Hi Yaakov,

Please see below

Best,
Ron

---

From: Yaakov Stein <[email-masked]>
Date: Fri, 30 Apr 2010 17:26:48 +0300

Phil, 

> I made the comment and I also said I don't think interpreting the actual inband codes is an IETF/PWE3 function.  
So far I completely agree.

> That is something which the vendors need to implement as features on their equipment.   
Assuming you mean TDM vendors and not PWE vendors I agree.

> The part in scope for PWE3 is if a vendor does implement a feature to sniff the wire for certain bits, 
> provide the signaling constructs to loopback the pseudowire on the far end.   
So what you want is a function that "emulates" a remote loopback, but not at the remote TDM end equipment.
Now, assume that the PW is a small part of the overall TDM path, and that there is an additional 100 km
of TDM line and several pieces of native TDM equipment between the remote PE and the final TDM equipment
that you want to loopback. You are suggesting that we fake the loopback at the remote PE,
and leave the operator thinking that he received an OK on his end-to-end service,
when no such test was carried out. 

Following this logic, why don't we monitor for TDM loopback requests at the local PE ?
This would save PSN bandwidth and would not be significantly less reliable than looping back
at the remote PE (since we can check the PW integrity using VCCV).

> This doesn't exactly emulate a smartjack since you are looping the PWE3 service and not the framer on the far end 
> but it's close enough for most customers.  
PERHAPS for the very very special case of a standalone PWE IWF co-located with the TDM end equipment
with a visible single link connecting the two that is totally owned by the operator interested
in the test, and that can be tested by some other means.
In no other case would this be acceptable.

> There are vendors who do this today through proprietary OAM signaling to the far-end.
I am not sure what this means.

> On the Ethernet side, we would like to see PW level loopback for throughput testing to eliminate NIDs 
> which act as Ethernet smartjacks.   
We already have PW layer loopback as part of the PE that already exists.
Just ask your PWE vendor how to activate the VCCV channel functionality.

You do not need an Ethernet NID - indeed and Ethernet NID tests something else entirely.
It tests Ethernet continuity and connectivity, where the Ethernet is the server layer over which
either all or part of the PWE layer is traveling (and, of course, there may be intervening layers).

So if you have an Ethernet service giving you access to an MPLS network, 
the Ethernet OAM only check that access.

> We are seeing support by some vendors for sending/receiving Y.1731 LB messages at line rate which can be used 
> for throughput testing, probably a better long-term solution, but PWE3 has better support than Y.1731.  
I am not sure how to compare Y.1731 (or EFM-OAM for that matter) with VCCV, 
but some Ethernet OAM functionality is universal for any Ethernet sold as a service.

However, this is not the point. OAM functionality monitors service characteristics for its own layer,
and should never be used to monitor a server or client layer.
Of course, it is proper to use such OAM as a trigger or a debugging tool for other layers.
For example, if your end-to-end TDM loopback fails, you would first check the remote TDM network/equipment
using TDM diagnostics tools. For example, if you have a service provider that takes your TDM
and puts it onto SDH or PWE or whatever, you should be able to test the connectivity up to the
local IWF. This would be considered an NSP function if it is a PWE IWF, and should be supported,
although its functionality is outside the scope of PWE3. 
If that is not the problem, the PWE provider will test his PW continuity, and the remote TDM network
should be tested. If you have a collocated PWE IWF and have an Ethernet service carrying it to
somewhere, then definitely check the Ethernet server layer for lack of continuity or connectivity problems.

However, please do not ask the PWE IWF to pretend to be some TDM equipment
located somewhere else. 

Y(J)S

---

From: Phil Bedard <[email-masked]>
Date: Fri, 30 Apr 2010 11:48:32 -0400

> Assuming you mean TDM vendors and not PWE vendors I agree.

Is there a difference?  I would consider a device which transport TDM as a PW to be both...   

> when no such test was carried out.
  
That's rarely our use case, or else we wouldn't want the functionality.  Our general use case is for cell backhaul where we are colocated in the same cabinet as the customer end TDM equipment.   Their final end equipment doesn't always support loopbacks, that's why they want us to provide equipment which does.   We'd rather just pass the bits through and let them loop their own equipment and run tests, but in some cases they want to test the service to our demarc before they plug their equipment in and sometimes they can't loop their equipment because it doesn't support it.  We can do network loopbacks on the far end framer, but it's a manual process.  Like I said, today we end up putting smartjacks on the end of the circuit to accomplish the same functionality.  
> at the remote PE (since we can check the PW integrity using VCCV).

We can do this today.  Most vendors support the proper loopback codes to loop the client-side framer back towards the customer's equipment.  Unfortunately they want to loop the far end through our network.   

> In no other case would this be acceptable.

We have upwards of a thousand PWE connections which are exactly that, only the client operator wants to do the testing. 

> I am not sure what this means.

Sorry this wasn't clear and has nothing to do with PWE.  There are vendors who will capture an incoming facility loopback, and through some proprietary messaging tell the remote end to loop its framer back towards the network.  I think RAD is one of those vendors... 

> either all or part of the PWE layer is traveling (and, of course, there may be intervening layers).

We need a mechanism to loopback service frames, not respond to VCCV LBMs, unless I'm misinterpreting the capabilities of VCCV.  The NID is connected to the AC portion of the PW, the PW isn't going over the NID.   The NID sits between our PE and the customer Ethernet equipment, much like a smartjack does in a T1 circuit.  The NIDs we use today support service level loopbacks at the Ethernet layer so we can run RFC2889/RFC2544 tests across the service, but it's an external device we have to buy which we'd rather not.   Most PE vendors support Y.1731 now which gives us the CC/CV ability the NID does, but we are lacking the ability to do throughput testing.   Throughput testing is one of the testing types in Y.1731 via the ETH-TEST signal, so we are hoping vendors will adopt that, but in the absence of using it a PWE service level frame loopback would work.