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

["Newton, Jonathan" <[e-mail]>]

Hi Neil,

A quick query on the subject of AIS:

I understand your summary of the background of AIS, but there is surely
still a requirement for a triggered forward error indication of some
form?  ATM defined AIS cells for this function, so there is already a
precedent for this function in a co-ps network.

The problem that I foresee is that, although ethernet is inherently
cl-ps, Ethernet will be extensively used in a p2p manner, especially
when ethernet is used as a tail circuit to an IP service.  In this case,
I think that an AIS function is valid.  If this is not available, would
we not need to have CCM enabled in all cases?

Maybe the problem stems from the fact that SPs are often trying to use
Ethernet, that is inherently connectionless, in a connection oriented
manner!

> Quite.....need to start getting these things right (here a 
> transparent client/server layer network relationship).
Yes, seems to be the root of a lot of issues we are running into! Is it
worth noting that Y.1731 seems to have defined a server layer:
"NOTE - A Server MEP needs to support ETH-AIS function, as described in
sub-clause 7.4, where the Server/ETH adaptation function is required to
issue frames with ETH-AIS information upon detection of defect at the
Server layer by the Server layer termination and/or adaptation
function."

Cheers,
~Jon.


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of [e-mail]
> Sent: 09 July 2008 20: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
> 

This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ 

The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies.
 
Cable and Wireless plc 
Registered in England and Wales.Company Number 238525 
Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3