[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] On
> Behalf Of Dinesh Mohan
> Sent: 08 July 2008 16:08
> To: stbryant at cisco.com; 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: pwe3-bounces at ietf.org [mailto:pwe3-bounces at ietf.org] 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
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
> _______________________________________________
> pwe3 mailing list
> pwe3 at ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
>
_______________________________________________
pwe3 mailing list
pwe3 at ietf.org
https://www.ietf.org/mailman/listinfo/pwe3