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

From: "Vach Kompella" <[email-masked]>
Date: Wed, 12 Jul 2006 07:11:19 -0700

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.

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

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).  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 

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 7:45 AM
> To: Vach Kompella
> Subject: RE: [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
> 
> 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
> 

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

---

From: "Yaakov Stein" <[email-masked]>
Date: Wed, 12 Jul 2006 17:35:18 +0200

Yaakov,

[YJS] I would argue that most of the OAM features have been implemented,
but not all in any particular scenario.
That is why Y.1731 was built in modular fashion.

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.  I think the first gate is that the ethernet PSN is out
of scope - we shouldn't be making any assumptions about the PSN.  

[YJS] which is precisely why I am saying that we are NOT assuming an
Ethernet PSN.
Yes, it is "cheaper" to implement if the vendor already has Y.1731
implemented in his box
for the PSN. I believe this is precisely why BFD got put into VCCV -
vendors already had it running.
So according to my reasoning we should pick a STATE-OF-THE-ART OAM,
and not be restricted by what is easier for vendors (vendor hat off).

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.

[YJS] As you know I had a specialized OAM running for TDMoIP PWs. 
I am now giving this up and adopting Y.1731, which certainly was not
designed for TDM ! 
However, it has all the functionality I need.

[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.

Let's think about it. What do we need from an OAM protocol for PWs?
1) CC with several rates from hundreds per second to once every few
minutes
2) selective in-service and out-of-service loopbacks
3) trace
4) optional AIS and perhaps RDI
5) delay, delay variations and perhaps throughput measurement
6) definition of OAM endpoints and intermediate points 
7) hierarchy of OAM flows

Sounds like Y.1731 to me.

Y(J)S

---

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

Vach, Yaakov and all,
Please see a brief comment inline below.
 
Regards,
                 Sasha

________________________________

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

Yaakov,

[Sasha] At least SOME of the ATM OAM functionality has been implemented and, in some cases, even deployed (e.g., the connectivity check).  How much of the Y.1731 OAM has been implemented and deployed? 

 --- snipped ...

---

From: "Sasha Vainshtein" <[email-masked]>
Date: Wed, 12 Jul 2006 18:02:38 +0200

Yaakov and all,
Please see inline below an analysis of the OAM requirements vs. existing techniques.
The rest of the text is snipped for clarity

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

... snipped ...

[Sasha] BFD allows you this functionality with the added ability to negotiate the CC rate s and dead intervals with resolution of micrfoseconds (instead of having a fixed non-extendable set of rates as per Y.1711)

[Sasha] LSP-Ping in ping mode provides you with that

3) trace

[Sasha] LSP-Ping in traceroute  mode provides you with that.

[Sasha] Status TLV and/or Status indications in the |BFD provide that

[Sasha] This is a gap in the existinhg OAM mechanism. Let's address this specific problem

[Sasha] IMO this introduces a problem instead of solving it (as explained in my previous email)

7) hierarchy of OAM flows
[Sasha] We have at least two approaches for MS-PW OAM that use existing capabilities.

[Sasha] With 5 of 7 items adequately covered and one being rather a nuisance than an advantage, would you really go for a completely new approach?

Y(J)S

---

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

Vach,

I think you missed some of my points....

1) You think of it as an abstraction, IMO PWs simply adopted MPLS PSN
tools, including things not required such as IP headers, FEC stack etc.
It is simply a common denominator in one scenario, and if I assume
MPLSoIP and MPLSoGRE and MPLSoL2TPv3 really means PWoIP, PWoGRE and
PWoL2TPv3 it is no longer common.

2) IMO one issue is the number of OAM systems you intend to deploy. The
option to minimize the overall set is a useful one. This is an
operational issue not an implementation issue. 

3) As myself, Yaakov and others have noted, Y.1731 has additional useful
functionalites not available with the current PW suite. Particularly
true in the case of L2VPN clients.

Cheers
Dave

-----Original Message-----
From: Vach Kompella [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 10:11 AM
To: 'Yaakov Stein'; 'pwe3'
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

Yaakov,

-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.
> 
> 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: "Yaakov Stein" <[email-masked]>
Date: Thu, 13 Jul 2006 01:51:58 +0200

Sasha
 
What you are saying is that we can do some
of the functionality by using a large medley of protocols,
many of which may not be un use
and some may be mutually contradictory if used in the ways you propose.
 
Without going into your proposals one by one,
my macro point of view is that I need to thank you 
for providing the best proof of the relative simplicity of our proposal.
 
BTW, we are proposing 1731 and NOT 1711 (was that a Freudian slip?).
 
Y(J)S

From: Sasha Vainshtein [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 18:03
To: Yaakov Stein; Vach Kompella; pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

Yaakov and all,
Please see inline below an analysis of the OAM requirements vs. existing
techniques.
The rest of the text is snipped for clarity

... snipped ...

[Sasha] BFD allows you this functionality with the added ability to
negotiate the CC rate s and dead intervals with resolution of
micrfoseconds (instead of having a fixed non-extendable set of rates as
per Y.1711)

3) trace

[Sasha] This is a gap in the existinhg OAM mechanism. Let's address this
specific problem

[Sasha] IMO this introduces a problem instead of solving it (as
explained in my previous email)

7) hierarchy of OAM flows
[Sasha] We have at least two approaches for MS-PW OAM that use existing
capabilities.

[Sasha] With 5 of 7 items adequately covered and one being rather a
nuisance than an advantage, would you really go for a completely new
approach?

Y(J)S

---

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

Sasha

 
 
Y(J)S

Yaakov and all,

... snipped ...

3) trace

Y(J)S

---

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

Yaakov,
Thank you for a prompt response and a typo catched (of course I meant Y.1731).
Wrt to your substantial objections, it looks if they are based on the assumptions that Y.1731:

1.	
	Is the "best OAM there is" (I am quoting one of your emails) 
2.	
	Already has multiple interoperable implementations 
3.	
	Is already widely deployed (so that the operators and vendors have real-life experience with it).

I think (and I can be wrong, of course) that these assumptions are questionable.
 
The "large medley of protocols" you refer to is, IMO, not much different from Y.1731 which uses a separate set of PDUs for almost every of its multiple functions. But the design of these protocols has been aligned with the existing PW equipment architecture while Y.1731 relies, in certain cases, on yet non-existing HW capabilities. So I very much doubt if it is really as simple as you try to present it.
 
Regards,
                         Sasha

From: Yaakov Stein [mailto:[email-masked]]
Sent: Thu 7/13/2006 2:51 AM
To: Sasha Vainshtein; Vach Kompella; pwe3
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs, etc.?

Sasha

 
 
Y(J)S

Yaakov and all,

... snipped ...

3) trace

Y(J)S