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

From: <[email-masked]>
Date: Wed, 12 Jul 2006 16:02:27 +0100

Yaakov/folks....

> -----Original Message-----
> From: Yaakov Stein [mailto:[email-masked]] 
> Sent: 12 July 2006 15:47
> To: pwe3
> 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.
NH=> People should not confuse 'a bloated OAM specification' with 'a
good OAM specification'.  Over-done OAM is almost as bad as none.   

We would want a significantly reduced profile of Y.1731 for a co-ps mode
layer network based on the ethernet traffic unit (eg PBT) and here is
why......folks keep asking for operator input so here I'm trying to
provide some:

-	The reason we have OAM largely turned-off in our well-engineered
networks today is that we can't afford to collect/process it...it is not
adding any value.  Conversely, if we have a need for running lots of
monitoring (ie because the performance is so poor/uncertain that it
demands it) then we are already dead as an operator.  So either way,
bloated OAM is NOT required.

-	the always-on defect detection/handling OAM needs to be sparse,
HW friendly and simple because it MUST be super reliable.  The more
functionality that is added the less reliable the OAM becomes.  I
shudder to think of what could go wrong with misconfigured or faulty
nested TCM levels.

-	Lots of QoS classes requires lots of PM OAM.  If one understands
how real-world networks must be designed and operated over a planning
cycle, then having lots of QoS classes is a total waste of time.....and
as already noted we can't afford to run lots of continuous OAM anyway.

-	Y.1731 shows different operating parties running different
nested TCM segments.  Bad idea.  Why?  Because all these nested TCM
segments all reside in the SAME layer network and one should not be
partitioning a single layer network between different operating parties
like this UNLESS it is supporting a specific and well-defined PUBLIC
service....and in which case these interfaces would be E-NNIs.  I do not
believe we have any well-defined public services for what is suggested
in Y.1731.  When one operating party wishes to convey its layer network
(any mode, all 3 planes) over the transport network of some other
operating party the correct relationship is a client/server one, ie full
functional decoupling....so nested TCM does NOT apply here, as one
should be running OAM in the client and server layer networks quite
independently of each other.  BTW:  MACinMAC is true client/server, so
is IPinIP.  Nested LSPs in MPLS is NOT true client/server and neither is
QinQ in ethernet.

-	Having the right type/level of OAM present from the word go
helps vendors iron-out bugs before large scale deployment.

-	The OAM required for each of the 3 network modes is subtly
different because the network modes are different.  Y.1731 is supposed
to be designed for the cl-ps ethernet mode.  Well OK, but:
	 (i) I question the wisdom of the amount of OAM here per
se.....esp noting that nested TCM in a cl-ps mode network makes even
less sense to me than having TCM in a co network (and we would not even
do that) as this does at least have a stable long-holding connections
that do NOT move if the routing/STP changes....which is not necessarily
due to failures but could arise from adding a new node or link!
	(ii) I question the wisdom of assuming native cl-ps ethernet is
what one would use in the WAN anyway...we really need a good co-ps mode
solution to augment our cl-ps IP networks and our co-cs OTN/SDH
networks. From our work on unified modelling we know PBT has near-ideal
co-ps mode labelling and this has several spin-off OAM benefits (can
list if needed).

-	 In co mode networks the first thing we need to be clear on and
get right is the nature of a connection.....which, from information
theoretic considerations, MUST respect the following requirements
(breaks these rules and the construct won't be sensibly
manageable....this is more than just OAM):
	o	single source
	o	connectivity=1
	o	no routing choice within the connection.
So p2p and p2mp construct are connections, mp2p and mp2mp constructs are
NOT connections.

-	In a co mode network the fault and performance management MUST
be unidirectional and the CV flow MUST be decoupled from the BDI flow
and not piggybacked as indicated in Y.1731.  Why?  Well, although
piggybacking works fine for the p2p bi-directionally symmetric case it
does not work fine for p2mp case because we do not have symmetric
connections.  That is, if a defect affects a p2p leaf->root connection
we should NOT be sending a BDI in the return p2mp root->leaves
connection as it will get sent, incorrectly, to all leaves.

regards, Neil
> 
> 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
> 

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

---

From: "Dinesh Mohan" <[email-masked]>
Date: Thu, 13 Jul 2006 12:44:38 -0400

Neil,

I agree with your statement that for a co-ps mode, Y.1731 can be
profiled. So depending on the applications, Y.1731 profiles can be
applied. 

Even though the discussion thread digressed into bunch of different
directions, which happens quite often, the main point of the
contribution has been to support Ethernet OAM payload within VCCV. As
has been pointed out by different folks on the mailing list, Ethernet
OAM (as defined in Y.1731 and its profiles e.g. CFM being defined in
802.1ag or another profile for PBT) can be used to manage PWs in both
PSN dependent or PSN agnostic scenarios. It is more functional that
current BFD, LSP Ping, ICMP Ping protocols with the possibility to use
specific profiles.

Regards,
Dinesh
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, July 12, 2006 11:02 AM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

Yaakov/folks....

> Subject: RE: [PWE3] Should we carry this principle over to ATM PWs, 
> etc.?
> 
> 
> 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.

regards, Neil
> 
> 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: "Craig White" <[email-masked]>
Date: Fri, 14 Jul 2006 09:54:49 -0400

Hi!

*snip*

> current BFD, LSP Ping, ICMP Ping protocols with the possibility to use

But BFD, LSP Ping, ICMP Ping are protocols developed by the IETF, i.e., we
can make changes to these protocols if/when needed.

-craig

---

From: "Dinesh Mohan" <[email-masked]>
Date: Sun, 16 Jul 2006 17:26:44 -0400

Craig,
 
I understand the sentiment expressed here. But, it is also important to
note that during the development of this work, there had been a lot of
collaboration between IEEE 802.1 and ITU-T SG13/15. We should resist
ourselves from reinventing the wheel. If the functionality is already
available and requires enhancements, collaboration is desirable than a
"designed here" label.
 
I see no reason to discount collaboration at this stage since most of
the applicable functionality is already offered by Ethernet OAM.
 
Regards,
Dinesh

________________________________

From: Craig White [mailto:[email-masked]] 
Sent: Friday, July 14, 2006 9:55 AM
To: [email-masked]
Subject: Re: [PWE3] Should we carry this principle over to ATM PWs,
etc.?

Hi!

*snip*

	PSN dependent or PSN agnostic scenarios. It is more functional
that 
	current BFD, LSP Ping, ICMP Ping protocols with the possibility
to use
	specific profiles.

But BFD, LSP Ping, ICMP Ping are protocols developed by the IETF, i.e.,
we can make changes to these protocols if/when needed. 

-craig