Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

[Maarten Vissers <[e-mail]>]

retry..

-----Original Message-----
From: Maarten Vissers [mailto:[e-mail]]
Sent: 14 July 2008 11:02
To: '[e-mail]'; '[e-mail]'; '[e-mail]'
Cc: '[e-mail]'; '[e-mail]'
Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Neil,

> 2	I note that the BDI (or RDI) function has been piggy-backed in CC
messages in both Y.1731 and 802.1ag.
> In the case of co-cs or co-ps mode layer networks this only works for 
> symmetrical bidirectional connections, ie p2p constructs only.  It 
> does not work for p2mp connection constructs (as these cannot be
bidirectionally symmetric) and so a CC message and a BDI message need to be
distinct/independent OAM messages here.

You make a mistake here. First you have to specify what a bidirectional p2mp
connection looks like and how the traffic flows, then you can address the CC
and RDI/BDI OAM mechanism.

1) A n-port bidirectional p2mp connection consists of either
  - one unidirectional p2mp connection from A to Z1..Zn-1 and
  - n-1 unidirectional p2p connections from Zi to A (i=1, .., n-1), or
  - one unidirectional p2mp connection from A to Z1..Zn-1 and
  - one unidirectional mp2p connection from Z1..Zn-1 to A.

Traffic flows from A to Zi.
OAM flows from A to Zi and from Zi to A.

Question: is there also traffic from Zi to A? 

The second case (p2mp + mp2p) connection can be supported in a transport
tunnel layer. This p2mp/mp2p connection carries transport service layer
unidirectional and bidirectional p2p connections and/or unidirectional p2mp
connections, which have unique label values within the p2mp/mp2p tunnel
connection. Example: MPLS p2mp/mp2p tunnel with bidir p2p PWs and unidir
p2mp PWs, Ethernet asymmetric VLAN without MAC learning.

The first case can be supported in a transport service layer and transport
tunnel layer. 

2) For the first case when there is no traffic from Zi to A, the CC function
checks the A to Zi (i=1, .., n-1) maintenance entities and the signal fail
status at the Zi ends is reported via RDI/BDI function from Zi to A. The CC
fucntion between Zi and A checks if the Zi to A connection is operational
and thus able to carry RDI/BDI from Zi.
There is as such no problem to combine CC and RDI/BDI OAM in a single OAM
message.

For the second case (p2mp/mp2p tunnel connection) CC function checks the A
to Zi Maintenance Entities and the signal fail status at the Zi ends is
reported via RDI/BDI function from Zi to A. The CC fucntion between Zi and A
checks if the Zi to A maintenance entity is operational and carries the
RDI/BDI from Zi. At A, the status of the mp2p unidir 'transport entity' is
computed from the status of the individual p2p maintenance entities; the
result is reported from A to Zi via the RDI/BDI inside the CC from A to Zi.
There is as such no problem to combine CC and RDI/BDI OAM in a single OAM
message.

Regards,
Maarten

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: 09 July 2008 21:18
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft

Hi Dinesh and Ali,

A few observations on the draft and the subject of OAM in general that you
might like to take into account:

1	Despite what some folks having been trying to do in ITU the OAM
required for each of the 3 network modes (cl-ps, co-ps and co-cs) is not the
same.  For example, AIS is mentioned in the draft.  AIS has its roots in
co-cs mode PDH/TDM networks.  AIS is about alarm suppression (in co mode
clients *above* a server failure) not generating alarms.  It was a direct
consequence of old TTL logic when, on failure, the logic 'floated' to +5V
(ie binary 1).....so a binary all 1s signal was the natural indication of
failure here.  Note in particular it is a passive signal....in the sense
that we don't have to actively create special traffic units to mimic it as
we would in any packet network.  Further, since the co-cs mode is
characterised by a constant bit rate signal AIS is naturally a constant
stream of binary all 1s (when replacing the traffic signal).

AIS is however not a natural signal in packet networks.  And whilst it is
understandable to want to have an AIS/FDI OAM function in co-ps mode layer
networks (on the assumption they have proper single source connections, ie
p2p or p2mp constructs only) it has no meaning in cl-ps mode networks, eg
IP, Ethernet.  And this, of course, is why IEEE saw fit to deprecate AIS in
802.1ag for Ethernet OAM.

My view is that IETF should align its position with that of the IEEE
standards when dealing with Ethernet OAM.



2	I note that the BDI (or RDI) function has been piggy-backed in
CC messages in both Y.1731 and 802.1ag.  In the case of co-cs or co-ps mode
layer networks this only works for symmetrical bidirectional connections, ie
p2p constructs only.  It does not work for p2mp connection constructs (as
these cannot be bidirectionally symmetric) and so a CC message and a BDI
message need to be distinct/independent OAM messages here.  This is
something to bear in mind for GMPLS (controlled co-cs mode layer network
connections), MPLS and PWs (assuming the case of both these supporting
proper single source co-ps connections).

Now of course Ethernet is a cl-ps mode technology so we don't have
connections. However, if we make the OAM CC message a broadcast function
between MEPs then we force a condition of symmetry here and so one can, in
principle, piggyback BDI in CC messages.....the traffic of course can be,
and usually is, unicast (once SA MAC learning has taken place).  So the
first observation here is that the OAM is not exercising exactly the same
processing path as the traffic.  Further, the indiscriminate broadcasting of
BDI to N far-ends wrt to an unknown number of incoming failures is hardly
good practice (see section 7.5 in Y.1731).

However, the key point I am making here is the former one, ie when we are
dealing with proper co-cs or co-ps mode p2mp connections we cannot piggyback
BDI in CC messages.


3	It is a very, very bad idea to have client layer defects
reflected in a server layer network (be this DP/CP/MP).  I just noted Yaakov
also allude to this point in his mail 09 July 2008 17:31, viz:

"However, I would like to reiterate what I said in Philadelphia.
I am not a great fan of OAM mapping at all, and wouldn't care if the present
oam-msg-map draft died a natural death.
Ethernet to Ethernet PW OAM interworking is an evil, but frequently a
necessary one.
Work on it needs to be expedited."

Quite.....need to start getting these things right (here a transparent
client/server layer network relationship).


4	Final, and far more general, point....OAM needs to be uber
reliable...far more so than the intrinsic failure rate of the network it
resides in.  So defect detection/handling OAM needs to be as simple/sparse
as possible.  Collecting OAM (esp Perf Mon OAM) information also has a real
opex cost.  Ops folks will turn-off as much OAM as they can...esp
bloated/bad OAM (Y.1731 is bloated IMO).  I've just noticed TCM (Tandem
Connection Monitoring) has been added to the
PWE3 charter.  I would strongly advise IETF *not* to go here just because
others have included this in their standards.  This idea has been around for
many years in ITU and there are very good reasons why very little of it is
used in practice (I can spell this out if not obvious).

Regards, Neil



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Dinesh Mohan
> Sent: 08 July 2008 16:08
> To: [e-mail]; pwe3
> Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> as WG draft
> 
> Stewart, of course as an author I support this as a WG draft :-)
> 
> FYI...an updated version of the document is also available based on 
> feedback during the meeting and some further offline
> discussions:
> http://www.ietf.org/internet-drafts/draft-mohan-pwe3-mpls-eth-
> oam-iwk-01
> .txt
> 
> If we agree, this could be the version that can be accepted for 
> working group draft.
> 
> ---
> Dinesh
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf 
> Of Stewart Bryant
> Sent: Tuesday, July 08, 2008 7:35 AM
> To: pwe3
> Subject: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt as WG draft
> 
> We have a request to accept MPLS and Ethernet OAM Interworking
> 
> http://tools.ietf.org/id/draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt
> 
> as a working group draft.
> 
> The authors thought that PWE3 had already agreed to this, but the 
> minutes of the last meeting do not say that, and in any case we did 
> not do a list poll.
> 
> Please can we have views on whether to accept as WG draft by COB 15th 
> July.
> 
> Thanks
> 
> Stewart/Danny
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pwe3
> 
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3


_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3