Subject: [PWE3] Should we carry this principle over to ATM PWs, etc.?

From: "Vach Kompella" <[email-masked]>
Date: Tue, 11 Jul 2006 15:12:58 -0700

Would we stop the VCCV work and put the L2 OAM flows of each PW type and
just stick a control word and label stack on them?  I'm sure we can find
ITU specs for each L2 we're trying to emulate.

-Vach

_______________________________________________
pwe3 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pwe3

---

From: "David Allan" <[email-masked]>
Date: Tue, 11 Jul 2006 18:33:21 -0400

Hi Vach

If PWs were carried by the L2 they were also emulating it may not be a
bad idea...gets you to the option of one system. Rather than simply
imposing a competely new system simply to instrument an adaptation
layer.

I think the essence of Dinesh's proposal is to converge on the high
runner, rather than mandating the imposition of a third system....

Works for me...
Dave

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 6:13 PM
To: 'pwe3'
Subject: [PWE3] Should we carry this principle over to ATM PWs, etc.?

-Vach

---

From: "Vach Kompella" <[email-masked]>
Date: Tue, 11 Jul 2006 15:41:39 -0700

Essentially, we develop layers of abstraction with PWE3oMPLS only to
resort to the underlying L2.  So what if the underlying L2 isn't
ethernet?  Do we use the fallback VCCV?  In other words, we have to
implement two OAMs for each L2?

-Vach 

> From: David Allan [mailto:[email-masked]] 
> Sent: Tuesday, July 11, 2006 3:33 PM
> To: Vach Kompella; pwe3
> Subject: RE: [PWE3] Should we carry this principle over to 
> ATM PWs, etc.?
> 
> 
> Hi Vach
> 
> If PWs were carried by the L2 they were also emulating it may 
> not be a bad idea...gets you to the option of one system. 
> Rather than simply imposing a competely new system simply to 
> instrument an adaptation layer.
> 
> I think the essence of Dinesh's proposal is to converge on 
> the high runner, rather than mandating the imposition of a 
> third system....
> 
> Works for me...
> Dave
> 
> 
> 
> Would we stop the VCCV work and put the L2 OAM flows of each 
> PW type and just stick a control word and label stack on 
> them?  I'm sure we can find ITU specs for each L2 we're 
> trying to emulate.
> 
> -Vach
> 
>

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Tue, 11 Jul 2006 17:55:46 -0500

For the proposal, were there any considerations if MS-PW (with possible
non-Ethernet domains)?
Deborah 

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 6:42 PM
To: 'David Allan'; 'pwe3'
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

-Vach

---

From: "Dinesh Mohan" <[email-masked]>
Date: Tue, 11 Jul 2006 19:40:06 -0400

Vach,

I am not sure from your response whether you view VCCV as LSP Ping, or
ICMP ping or BFD. Could you please clarify?

As it is, these are different OAM implementations.

If your response is that there is still one implementation based on the
PSN type, which allows to manage PSN and PWs using one OAM
implementation, you have just justified the use of Ethernet OAM payload
in VCCV across Ethernet PSN.

Regards,
Dinesh

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 6:42 PM
To: Allan, David (CAR:NS00); 'pwe3'
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

-Vach 

> bad idea...gets you to the option of one system.
> Would we stop the VCCV work and put the L2 OAM flows of each PW type 
> and just stick a control word and label stack on them?  I'm sure we 
> can find ITU specs for each L2 we're trying to emulate.
> 
> -Vach
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Tue, 11 Jul 2006 19:38:21 -0400

I think the answer is simple: use the
native OAM over the PW as if it were normal
data traffic, and use VCCV to diagnose/manage
the PW (whatever its type).  This is why I
don't see the draft in question as being
useful.

	--Tom

---

From: "David Allan" <[email-masked]>
Date: Tue, 11 Jul 2006 19:06:30 -0400

> Essentially, we develop layers of abstraction with PWE3oMPLS only to
resort to the 
> underlying L2.  So what if the underlying L2 isn't ethernet?  Do we
use the fallback 
> VCCV?  In other words, we have to implement two OAMs for each L2?

Do not really see PW OAM as an abstraction, it was simply resuse of MPLS
PSN OAM, witness the discussion today of IP headers on PW OAM flows.
Reality is none need it, the header was there for PHP, a purely PSN bit
of baggage....

Meanwhile, where the underlying network is homogenous, I'd like the
option of a common OAM system, and the underlying network is becoming
increasingly homogenous...so I believe that option has value....

I also like the relative completeness of CFM. VCCV (and in particular
BFD) was not really designed for multi-hop or mp2mp or has any sort of
PM capability. Therefore if I can negotiate support for the superior
system, I'll use it! And as the negotiated reply is increasingly likely
to be "sure", guess which system will be optimized...

Cheers
Dave

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 12 Jul 2006 16:38:04 +0200

> I think the answer is simple: use the native OAM over the PW as if it
were normal data traffic, 
> and use VCCV to diagnose/manage the PW (whatever its type).  
> This is why I don't see the draft in question as being useful.

Tom

I don't see your point.

No-one is saying that one shouldn't run the native OAM for the client.

The question is what OAM to run at the PW level.

VCCV provides a framework, but this framework has been filled to date
with LSP-ping and BFD. What is being proposed here is to augment VCCV
with a full-function OAM.

Consider the following scenario - an Ethernet service
starts out over an EFM PON, connects to a Metro,
from there over a MS-PW over MPLS, then to a Metro, 
and finally to the destination user.

      SRC - EFM - MEN - MPLS - MPLS- MEN - DST

The end-to-end OAM is based on Y.1731.
Over the various segments there are native server layer OAMs,
e.g. over the EFC segment we have EFM OAM, 
MEF specifies OAM for the MENs, 
and over each MPLS network we have some MPLS OAM.

We would like to have a PW-layer OAM run across the stitched PW.

BFD can not be used for this as in the present VCCV draft,
since BFD will span one segment of the MS-PW.

Rather than extending BFD/VCCV, we can use Y.1731 as the VCCV format.
We not only get a fuller set of OAM functions, 
we get the capability of up to 8 layer hierarchies.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 12 Jul 2006 16:46:48 +0200

> Would we stop the VCCV work and put the L2 OAM flows of each PW type
and just stick a control word and label stack on them?  
> I'm sure we can find ITU specs for each L2 we're trying to emulate.

Vach

I think the main idea was somewhat blurred here,
by Dinesh starting with statements about Ethernet PSNs.

The draft is suggesting the use of the Y.1731 formats
for ANY PW client over ANY PSN.

As long as we can find some form of Ethernet addresses at the endpoints
(and I am all for extending to alternative addressing if needed)
we can exploit the Y.1731 capabilties.

Y.1731 is the most comprehensive set of OAM functions
designed to date, with not only continuity check, 
but AIS, RDI, delay measurement, PDV measurement, 
throughput measurement, etc. etc.

Instead of using BFD as the VCCV format
(and I have not seen anyone complain that this is an "I OAM"
and thus restricted to IP PWs !)
why shouldn't we adopt the best OAM available?

Y(J)S

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 12 Jul 2006 10:07:36 -0400

> The question is what OAM to run at the PW level.

	I don't see why there is a question. There are
sufficient modes to run VCCV defined today.

> We would like to have a PW-layer OAM run across the stitched PW.

	And you can indeed do this. Look at the pw-switching
draft. We have started to explain how to carry MH-VCCV there.
I don't see issues with the CC/CV types that are currently defined.
Matthew/Mustapha's draft that was presented also includes many of
the other concepts that Luca and I were intending on adding to
the OAM section in the pw-switching draft. It will work fine for
single and multi-segment PWs.

	If you think there are, it would be nice to hear from
operators who are interested in providing these requirements.

> since BFD will span one segment of the MS-PW.

	Sure it can; take a look at pw-switching.

	--Tom

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 12 Jul 2006 17:47:15 +0200

Yaakov and all,
I think that the PWE3 has already defined addressing of the SS-PW endpoints in the form of FEC 128 and FEC 129.
This addressing extends to MS-PWs as well.
So any proposal to use an alternative addressing (be it Ethernet addresses or the Y.1731-style MEG ID/MEP ID addresses) raises, IMO, two questions:

1.	
	Which authority assigns the alternative addresses and how is their uniqueness guaranteed?
2.	
	How do you resolve one type of address to another?

IMHO the simplest way to answer (in a way) these questions would be to explicitly prohibit alternative addressing.  Another way would be to define a suitable "address resolution protocol". But simply ignoring these questions would not do. 

As for the full OAM capabilities provided by Y.1713 as opposed to capabilities provided by the existing PW techniques, I'd say that the short list of the missing functions includes:

1.	Measurement of the packet loss rate

	*	The Y.1731 approach to this measurement is essentially copied from the ATM specs and requires dedicated HW to insert counters of sent/received packets "on the fly" as well as relies heavily of lack of mis-ordering along the path. On the other hand, it claims to produce "absolutely accurate" results (again, under the assumption of no re-ordering)
	*	IETF has for quite some time pursued and codified an alternative approach (see RFC 2680 and RFC 3357) which, while only going for an approximate measurement, is, IMO, by the order of magnitude easier to implement on existing HW (since the measurements are performed across a sample dedicated flow rather than on the entrire traffic)
	*	Taking this into account I think that the IETF approach would be:

			*	Much simpler to implement with PWs
			*	Sufficiently accurate for most practical needs.

2.	Measurement of one-way/two-way packet delay/packet delay variation

	*	Y.1731 basic approach to these measurements basically does not differ much from the known IETF one and is quiet sound (it also uses a dedicated OAM flow (hence also producing the approximate, rather then absolutely accurate results)
	*	The drawback of the Y.1731 approach lies, IMHO, with its over-specialization of the OAM PDUs (e.g., you cannot measure both packet loss rate and packet delay variation using the same OAM PDU).  
	*	IMO piggy-backing all (or most) of the OAM data in the same OAM PDU (as discussed in your draft presented in Dallas) would be definitely an advantage.

3.	Some of the functionality intended by Y.1731 looks excessive to me in the PW context, e.g.ability to set the payload of some OAM PDUs to a PRBS:

	*	PW packets are normally FCS-protected on all the links, so bit errors on the link would result in loss of a packet (no need in PRBS to detect that)
	*	FCS retention could be used as an additional mechanism protecting against errors in the witching fabric of the routers.

Based on all that, I would suggest the following course of action:

1.	Identify "OAM gaps" with the existing PW OAM techniques
2.	Define solutions to cover these gaps that are:

	*	Backward-compatible with the existing techniques
	*	Backward-compatible with the existing PW implementations

Hopefully this clarifies my position in this discussion.

Regards,

                    Sasha

________________________________

From: Yaakov Stein [mailto:[email-masked]]
Sent: Wed 7/12/2006 5:46 PM
To: pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs, etc.?

Vach

Y(J)S

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 12 Jul 2006 10:57:06 -0400

The other problem with this draft is that
as I read the PWE3 charter, an ethernet PSN is not
a current work-item.

 From the PWE3 charter:

"Pseudowire Emulation Edge to Edge (PWE3) will specify the
encapsulation, transport, control, management, interworking and
security of services emulated over IETF specified PSNs."

	--Tom

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 12 Jul 2006 14:01:04 -0400

Deborah, 

Consideration has been given to MS-PW (with possible non-Ethernet
domains) though the initial thoughts are not captured in the current
draft and is expected to be developed as part of the on-going MS-PW
work.

I expect that these consideration would be no different than
considerations being given to existing payloads in MS-PW environments. I
have seen folks switch between LSP Ping and BFD functionalities when
making comparisons. I see these as being two different implementations
already. Further I would not expect LSP ping to be run across L2TP/IP
PSN. Therefore BFD would seem to be the choice among the current
payloads for MS-PW. But then, if I look at the functionality offered by
BFD, it still requires quite a bit of work, some areas have already been
identified and acknowledged.

Therefore, the question becomes, is it worthwhile augmenting a protocol
which wasn't necessarily designed to support some of these functions
initially or utilizing a protocol which has been extensively worked on
with support for functionality in ITU-T and IEEE already.

Regards,
Dinesh

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 6:56 PM
To: Vach Kompella; Allan, David (CAR:NS00); pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]]
Sent: Tuesday, July 11, 2006 6:42 PM
To: 'David Allan'; 'pwe3'
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

-Vach

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 12 Jul 2006 16:38:32 -0400

On Jul 12, 2006, at 2:01 PM, Dinesh Mohan wrote:

> PSN.

> Therefore BFD would seem to be the choice among the current
> payloads for MS-PW.

	This is not a good assumption. My initial implementations
will be using LSP Payload for MH VCCV, for example.

	--tom

> But then, if I look at the functionality offered by

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 13 Jul 2006 01:39:57 +0200

Tom, 

	The other problem with this draft is that as I read the PWE3
charter, an ethernet PSN is not a current work-item.

I have answered this several times.

Our suggestion does NOT require the use of Ethernet PSN,
and is equally applicable to MPLS or IP PSNs.

Y(J)S

---

From: "Brungard, Deborah A, ALABS" <[email-masked]>
Date: Wed, 12 Jul 2006 18:13:20 -0500

Dinesh,

>From your reply, is Ethernet OAM VCCV only intended for use with an
Ethernet PSN? Your latest revision (-01) seems to clarify as only for
PBT (-00 stated "especially when", -01 states "over PBT")? Can you
clarify as other replies on this thread propose this as an alternative
to VCCV/BFD (for use with a MPLS PSN).

Figure 2 shows 802.1/Y1731 used at the (Ethernet) PBT level. Is the
intention to use an e-2-e Y1731 OAM level at the PBT level plus VCCV
(Y1731) for the PW, or is the intention to only use VCCV (for both PW
and PBT OAM)? Can you clarify as you mentioned your proposal reduced the
number of OAM levels for Ethernet PBT, and version -01 describes the PBT
trunk is viewed as a single hop and the PW is directly bound with the
PBT trunk. Is this an alternative to using 802.1ag/Y1731 for PWoPBT
networks?

I agree with Neil, we should not over-simplify or over-complicate OAM.

Are there requirements for PBT OAM (or PWoPBT) functionality (IEEE/ITU)?

Deborah 

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 4:39 PM
To: Dinesh Mohan
Cc: Brungard, Deborah A, ALABS; Vach Kompella; David Allan; pwe3
Subject: Re: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

	--tom

---

From: "Yaakov Stein" <[email-masked]>
Date: Thu, 13 Jul 2006 01:51:51 +0200

Tom, 

Y(J)S

---

From: "Dinesh Mohan" <[email-masked]>
Date: Wed, 12 Jul 2006 21:31:38 -0400

Tom,

I keep hearing the same response over and over again. VCCV is positioned
as an OAM protocol whereas it is simply a means/channel to carry other
OAM protocols e.g. BFD, LSP Ping, ICMP ping. And BTW, why does VCCV need
different kinds of payloads? According to the statements I have seen
against the proposal, one protocol should have sufficed.

And needless to mention the plethora of options to indicate VCCV, i.e.
TTL option, CW option, Router Alert option, do not seem to make life any
simpler. Of course, then there is status signaling. And now the
extensions being proposed to accommodate MS-PW seem to rely upon
specific means to indicate VCCV.

The answer does not seem simple to me.

Regards,
Dinesh
-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 7:38 PM
To: Vach Kompella
Cc: 'pwe3'
Subject: Re: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

	I think the answer is simple: use the
native OAM over the PW as if it were normal data traffic, and use VCCV
to diagnose/manage the PW (whatever its type).  This is why I don't see
the draft in question as being useful.

	--Tom

>> If PWs were carried by the L2 they were also emulating it may not be 
>> a bad idea...gets you to the option of one system.

---

From: "David Allan" <[email-masked]>
Date: Wed, 12 Jul 2006 23:10:23 -0400

Deborah,

I think you're confusing a natural application of the proposal (latest
pw-o-pbt draft) with the proposal itself. 
As your questions apply to the application, I'll answer as author of the
draft in question...

Use of Y.1731 to instrument PBT is a distinct layer from the PW layer.
The PW and PBT not necessarily being fully congruent (e.g. MS-PWs, or
simply artifacts of implementation). The relatively high degree of
congruence (e.g. a PW segment by definition fate shares with a PBT
trunk) IMO significantly relaxes the requirements of the VCCV-ETHOAM
maintenance procedures.

No explicit requirements specific to PBT beyond Y.1730 that I am aware
of...

Rgds
Dave 

-----Original Message-----
From: Brungard, Deborah A, ALABS [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 7:13 PM
To: Thomas D. Nadeau; Mohan, Dinesh (CAR:1A14)
Cc: Vach Kompella; Allan, David (CAR:NS00); pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

Dinesh,

Deborah 

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, July 12, 2006 4:39 PM
To: Dinesh Mohan
Cc: Brungard, Deborah A, ALABS; Vach Kompella; David Allan; pwe3
Subject: Re: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

	--tom

---

From: "Florin Balus" <[email-masked]>
Date: Thu, 13 Jul 2006 01:28:34 -0400

At the end of the day it comes down to simplifying the life of the
operator focused on Ethernet based services - ELINE/Ethernet PWs and
ELAN/HVPLS. In this kind of networks, Ethernet Service OAM modules will
be predominant. 

I don't see why not allow the SPs THE OPTION to avoid different types of
Service OAM procedures and make use of additional features already
listed by Yaakov for what could be the predominant service... 

For all of this to work we need minimal standard (IANA) additions: i.e
new VCCV code points and a new Associated Chanel type. I don't really
see what is the big deal here?

And what is the difficulty implementation wise? As Don (O'Connor)
rightly noted during the PWE3 session, all Ethernet/HVPLS capable PEs
employ anyhow Ethernet OAM at service layer (and that should be, for
interoperability reasons, std based hence 802.1ag/Y.1731).

>Sent: Wednesday, July 12, 2006 7:52 PM
>To: Thomas D. Nadeau
>Cc: pwe3
>	The other problem with this draft is that as I read the 
>PWE3 charter, an ethernet PSN is not a current work-item.
>
>Our suggestion does NOT require the use of Ethernet PSN, and 
>is equally applicable to MPLS or IP PSNs.
>
>Y(J)S
>
>

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 13 Jul 2006 13:36:17 +0200

Florin and all,
 
Other issues notwithstanding, I think that the reference to HVPLS is not correct here, since HVPLS is different from MS-PW:

*	
	In the former, the PWs are terminated and switching is based on MAC addresses
*	
	In the latter, switching is based on PW labels.

In other words, if you would try to use this techique over an HVPLS, you would need an enhanced VSI with ability to extract EthOAM PDUs from the Associated Channel on top of its regular processing. IMHO it would be much easier to ran "native" EthOAM in such a case.

Regards,

                      Sasha

From: Florin Balus [mailto:[email-masked]]
Sent: Thu 7/13/2006 8:28 AM
To: Yaakov Stein; Thomas D. Nadeau
Cc: pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs, etc.?

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 13 Jul 2006 15:39:42 +0200

Florin, Yaakov and all,
Several people have notices that carryinh EthOAM PDUs in VCCV would be specially beneficial in the case of ETH PWs that provide E-Line or E-LAN services.
 
One point that went unnoticed is that RFC 4448 defines usage of CW for Ethernet PWs as OPTIONAL, the mandatory default encapsulation is without CW.
AFAIK, most (if not all) actually deployed Eth PWs follow this default encapsulation, i.e. no CW.
As a consequence, the only ways to indicate VCCV in these PW are:

*	
	By setting the TTL in he PW label to 1 (not applicable to MS-PWs)
*	
	By inserting a Router Alert label above the PW label (applicable to all cases).

The back side of using the Router Alert label is lack of the explicit ACh TYPE. This is not a serious issue with ICMP ping, LSP Ping and BFD in VCCV since all are carried in IP packets (and the last two - in UDP/IP packets using different UDP Destination ports).

Didi you consider using RFC 3378 (EtherIP) encapsulation for carrying Eth OAM PDUs in VCCV?

Regards,

                   Sasha

From: Sasha Vainshtein [mailto:[email-masked]]
Sent: Thu 7/13/2006 2:36 PM
To: Florin Balus; Yaakov Stein; Thomas D. Nadeau
Cc: pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs, etc.?

Florin and all,

*	

Regards,

                      Sasha

---

From: "Florin Balus" <[email-masked]>
Date: Thu, 13 Jul 2006 10:14:41 -0400

Sasha,
The idea of the HVPLS reference was to say Ethernet OAM modules are
already implemented and used anyhow in the Ethernet capable PEs for MAC
Layer OAM. If Ethernet is the predominant service and Ethernet OAM is
used to troubleshoot also customer access (or QinQ network for that
matter) why not use the same operational procedures across. 
See also in-line...

	From: Sasha Vainshtein [mailto:[email-masked]] 
	Sent: Thursday, July 13, 2006 7:36 AM
	To: Balus, Florin (CAR:6955); Yaakov Stein; Thomas D. Nadeau
	Cc: pwe3
	Subject: RE: [PWE3] Should we carry this principle over to ATM
PWs, etc.?

	Florin and all,
	 
	Other issues notwithstanding, I think that the reference to
HVPLS is not correct here, since HVPLS is different from MS-PW:
	[FB:] PWs are the building blocks for HVPLS, used to connect
VSIs. Depending on where those VSIs are located domain-wise and the CoI,
SS/MS-PWs may be used.

	*	
		In the former, the PWs are terminated and switching is
based on MAC addresses
	*	
		In the latter, switching is based on PW labels.

	In other words, if you would try to use this techique over an
HVPLS, you would need an enhanced VSI with ability to extract EthOAM
PDUs from the Associated Channel on top of its regular processing.
	[FB:] We just need the VSI to follow the same procedures used
currently for the supporting PWs: e.g. for the CW case check first 4
bits, if 0001 pass it to OAM; if associated chanel indicates Ethernet
OAM pass it to the right processing module (already there for MAC
OAM)...

	  IMHO it would be much easier to ran "native" EthOAM in such a
case.

	Regards,

	                      Sasha

	From: Florin Balus [mailto:[email-masked]]
	Sent: Thu 7/13/2006 8:28 AM
	To: Yaakov Stein; Thomas D. Nadeau
	Cc: pwe3
	Subject: RE: [PWE3] Should we carry this principle over to ATM
PWs, etc.?

	At the end of the day it comes down to simplifying the life of
the
	operator focused on Ethernet based services - ELINE/Ethernet PWs
and
	ELAN/HVPLS. In this kind of networks, Ethernet Service OAM
modules will
	be predominant.
	
	I don't see why not allow the SPs THE OPTION to avoid different
types of
	Service OAM procedures and make use of additional features
already
	listed by Yaakov for what could be the predominant service...
	
	For all of this to work we need minimal standard (IANA)
additions: i.e
	new VCCV code points and a new Associated Chanel type. I don't
really
	see what is the big deal here?
	
	And what is the difficulty implementation wise? As Don
(O'Connor)
	rightly noted during the PWE3 session, all Ethernet/HVPLS
capable PEs
	employ anyhow Ethernet OAM at service layer (and that should be,
for
	interoperability reasons, std based hence 802.1ag/Y.1731).

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 13 Jul 2006 17:30:42 +0200

Florin,
Thank you for a prompt response.
Please see inline below.
 
Regards,
                 Sasha

From: Florin Balus [mailto:[email-masked]]
Sent: Thu 7/13/2006 5:14 PM
To: Sasha Vainshtein; Yaakov Stein; Thomas D. Nadeau
Cc: pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs, etc.?

Sasha,
The idea of the HVPLS reference was to say Ethernet OAM modules are already implemented and used anyhow in the Ethernet capable PEs for MAC Layer OAM.
[Sasha] This is presumably correct (or incorrect) for all kinds of VPLS, hierarchical or not. I was surprised by your explicit reference to HVPLS.
If Ethernet is the predominant service and Ethernet OAM is used to troubleshoot also customer access 
[Sasha] This assumes that the customer access equipment supports Y.1731. I am not sure t what extend this is correct. You could probably count on the customer equipment supporting IEEE 802.3ah, but this is very different from Y.1731
(or QinQ network for that matter) why not use the same operational procedures across. 
See also in-line...

	Florin and all,
	 
	Other issues notwithstanding, I think that the reference to HVPLS is not correct here, since HVPLS is different from MS-PW:
	[FB:] PWs are the building blocks for HVPLS, used to connect VSIs. Depending on where those VSIs are located domain-wise and the CoI, SS/MS-PWs may be used.

	*	

	In other words, if you would try to use this techique over an HVPLS, you would need an enhanced VSI with ability to extract EthOAM PDUs from the Associated Channel on top of its regular processing.
	[FB:] We just need the VSI to follow the same procedures used currently for the supporting PWs: e.g. for the CW case check first 4 bits, if 0001 pass it to OAM; if associated chanel indicates Ethernet OAM pass it to the right processing module (already there for MAC OAM)...

	[Sasha] I do not see this as a viable approach: AFAIK, VSI usually receive Ethernet frames already de-capsulated from the PW (with an indication of the ingress interface being a PW for "split horizon", but no more than that).

	  IMHO it would be much easier to ran "native" EthOAM in such a case.

	Regards,

	                      Sasha