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

From: "O'Connor, Don" <[email-masked]>
Date: Wed, 12 Jul 2006 08:29:29 -0500

Tom

For L2 VPN Ethernet service what additional OAM capability does your OAM scenario below offer over one OAM flow with VCCV / Y.1731?

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Tuesday, July 11, 2006 6: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

> 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
>
>> -----Original Message-----
>> 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
>>
>>
>>
>> -----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.?
>>
>> 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
>>
>
>
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3

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

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

---

From: "O'Connor, Don" <[email-masked]>
Date: Wed, 12 Jul 2006 10:37:02 -0500

The proposal in the draft is equally applicable to a MPLS PSN. All that is requested is a codepoint for VCCV / Y.1731. This is within the charter.

Don

-----Original Message-----
From: Thomas D. Nadeau [mailto:[email-masked]]
Sent: Wednesday, July 12, 2006 9:57 AM
To: Yaakov Stein
Cc: pwe3
Subject: Re: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

	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

>> 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: <[email-masked]>
Date: Wed, 12 Jul 2006 19:20:59 +0100

Hi Yaakov...your stated OAM requirements are largely right but need some
slight corrections.....please see below (snipped)
> 
> [YJS] OK, I guess I agree that it might be even better to
> develop out own OAM. Leaving aside the resources and 
> expertise required for such a task, 
> I am quite sure that after a few years of work we would 
> recreate something essentially isomorphic to Y.1731. So all I 
> am proposing is to save a few years.
NH=> Y.1731 started out with good intentions, in fact it started out
largely from the requirement base that we set in Y.1710 for Y.1711
(though trying to apply co-ps OAM to a cl-ps mode network is not
actually that sensible, eg AIS is silly).....but it has also suffered
functionality creep, some of the stuff is not good IMO and we would want
it significantly profiled for sure for use in a co-ps mode (eg PBT)
layer network case.
> 
> Let's think about it. What do we need from an OAM protocol for PWs?
NH=> Let me re-phrase that to 'OAM for the co-ps mode'.

> 1) CC with several rates from hundreds per second to once
> every few minutes
NH=> This only works (and then has some very neat operational benefits)
if one has a fully labelled header in each traffic unit like we find in
PBT, ie SA and DA included in each/every traffic unit.  (The detailed
explantion of why this is comes from Shannon's work on Info Theory, and
how this relates to labelling information (i) at end points within a
single layer networks and (ii) in resource partitions on a client/server
basis per link connection). So if you DON'T have network significant
labels (ie one has label swapping on each link connection) then having
different CV rates is NOT a good idea, ie you can't define consistent
defect entry/exit criteria and defects will flap...and worse, with a
label-swapping paradigm you are strictly forced to run a CV flow on
every single connection whether it is important or not to be sure of
catching misbranching defects....and when you do (at the trail term
point) you have to squelch the whole traffic stream.  None of this
applies to PBT, indeed CV flows need only be run on important
connections as misconnectivity defects simply should not happen.

BTW...don't make the CV rate too small either as you will trigger
prot-sw on error events that would otherwise pass.....and trying to beat
the 50ms in SDH is generally just silly.

> 2) selective in-service and out-of-service loopbacks
> 3) trace
NH=> If one has a network significant SA+DA+VCID tuple in each/every
traffic unit that uniquely identifies the connection in the network, as
one has in PBT, then tracing can be done in smarter ways than OAM
message/response loopbacks.  Further, it would be very good practice to
routinely check that what the control or management plane thinks
fowarding tables should hold are actually what they do hold...again the
network unique SA+DA+VCID tuple makes this task far simpler.

> 4) optional AIS and perhaps RDI
NH=> AIS (or FDI) makes loads of sense in a co-cs mode layer network.
However, it makes no sense at all in a cl-ps mode layer network.  And it
is of arguable merit in a co-ps mode layer network.  CV are BDI are the
key always-on defect detection/handlinmg OAM tools in co mode layer
networks.  But 3 key points:
-	one MUST respect the nature of connections, ie p2p and p2mp only
-	OAM processing needs to be unidirectional....essential for p2mp
case
-	CV and BDI must not be coupled (as they are now in
Y.1731)...else we can't correctly deal with p2mp case.

> 5) delay, delay variations and perhaps throughput measurement
NH=> You are missing the loss measurement.  This also has the key point
of being able to tap-off an end-end PM flow at intermedaiute points to
do (should be rare) segment PM flow diagnostics.

> 6) definition of OAM endpoints and intermediate points
NH=> Some familiarity with G.805 func arch terms is useful here....the
key OAM flows need to be between trail termination points. 

> 7) hierarchy of OAM flows
NH=> I can see the superficial attraction in the TCM idea but I would
seriously advise folks against going there.

> 
> Sounds like Y.1731 to me.
NH=> Well, yes as a sensibly restricted profile of it and suitably
corrected where currently wrong/deficient.

regards, Neil

---

From: <[email-masked]>
Date: Wed, 12 Jul 2006 19:20:57 +0100

Vach,

> Yaakov,
> 
> ATM has a pretty full OAM set, most of which apparently has
> not been implemented and certainly not deployed, so having a 
> complete set isn't just an automatic winning combination.
NH=> This was my previous key point.....what might look like
comprenhensive OAM is not necessarily good OAM.  There are both
commercial and technical flaws with ATM.

The big commercial flaw was the original vision that a single co-ps mode
(in this case) layer network could do-it-all, ergo we got loads of
traffic/QoS classes and AALs which were never that successful....this
'one layer network can do-it-all with lots of QoS classes' mentality
just doesn't work.

Wrt technical OAM flaws there are lots (in I.610) but summarising a
couple of the major ones:
-	CC is useless as it does not contain a SA.....
-	...so to detect mismerge one must run a PM flow with a CC
flow.....still can't identify 'who' is the culprit and a very costly
processing solution (can't afford PM processing always on everywhere,
this needs to be an on-demand tool in general)
-	has limited form of nested TCM with 2 sub-layers...trail and
segment.  Segment OAM is not allowed out of segment, but under
misbranching traffic and OAM packets will leave the segment.....
-	.....so the loopback tool which is supposed to trace out the
misbranching route won't work....but its even worse as there has to be
an assumption that misconnectivity defects must be birectionally
symmetric.....but how do such defects know they have to be 'so
well-behaved'?  And when they are not there would be no return path even
if the loopback OAM could violate the segment OAM requirement.  Loopback
tools are only reliable under failure-free assumptions in co mode layer
networks.
  
> 
> I think the problem is that the OAM matches the PSN.  From 
> Dave's email, it sounds like it is an advantage to use this 
> OAM because the OAM matches the PSN.
NH=> The key point folks should try and grasp is that there is a
best-of-breed solution for OAM in each of the 3 network modes, ie cl-ps,
co-ps and co-cs....and they are subtly different.  Trying to force one
solution across all modes won't work....but this applies to all the
functional components, ie a single control-plane instance running IP to
Optics won't work either.

>  I think the first gate 
> is that the ethernet PSN is out of scope - we shouldn't be 
> making any assumptions about the PSN.  The second is that 
> there is no particular advantage to using an ethernet OAM on 
> a FR PW over an MPLS PSN using non-ethernet links.  This is 
> why I claim that PW is an abstraction, and despite Dave's 
> objections, I'd prefer to think of it as such.  Expecting a 
> uniform L2 in the PSN is a big assumption, particularly in 
> the context of multi-segment PWs, as Deborah pointed out.
NH=> The real problem here is that MPLS does NOT treat each of its
clients the same, ie IP => peer PDU or null encaps, MPLS => wrapper,
'Other' => PW encaps.  Not nice but arguably tolerable whilst PWs were
restricted to 1 hop.  Go >1 hop however and the originally restricted PW
adaptation function undergoes a major change of context as we now create
a new co-ps (PW) layer network above MPLS.  If you have this you need to
run OAM (and all the functional components) in it.  Just a fact.
> 
> That said, I'd much rather have a PW OAM that is independent 
> of any L2, and which we can tailor to the requirements of 
> PWE3 which is that that it cover all the emulated wires we 
> want to support (including, perhaps, MPLS and IP).
NH=> You have no choice IMO.....a PW co-ps layer network has been
created (which is a mistake, but it's too late now for MPLS) so it needs
its own OAM.

regards, Neil

>  I'd also 
> like for us (IETF) to be in control of this OAM since it 
> isn't clear that as we add PW types, that the OAM will nimbly 
> adapt, if owned by another SDO.
> 
> -Vach 
> 
> > From: Yaakov Stein [mailto:[email-masked]]
> > Sent: Wednesday, July 12, 2006 7:45 AM
> > To: Vach Kompella
> > > 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: "O'Connor, Don" <[email-masked]>
Date: Thu, 13 Jul 2006 09:34:12 -0500

It appears that there are OAM functionality tradeoffs between the many options embodied in the current version of VCCV - from least common denominator OAM to full function OAM. I would suggest that VCCV needs additional material to adequately define for VCCV channel type X and OAM protocol Y - what specific functions can be performed for what type of network configuration (single domain / multi-domain / MS-PW, etc). I would think that this is needed to provide service providers with adequate guidance on PW and end service (e.g. Ethernet) OAM capabilities, limitations, and tradeoffs
 
Don

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

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,
 
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.?

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: Yaakov Stein [ mailto:[email-masked]]
>Sent: Wednesday, July 12, 2006 7:52 PM
>To: Thomas D. Nadeau
>Cc: pwe3
>Subject: RE: [PWE3] Should we carry this principle over to ATM
>PWs, etc.?
>
>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
>
>