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

[<[e-mail]>]

Thank you Jon....some attempted answers in-line: 
[e-mail] wrote 11 July 2008 18:22

> 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.
NH=> Yes, that is true.  However, it's not as obvious a requirement as
you might think.  FDI requires a persistent binding of a client and
server layer network, ie the sever, on failure, needs to be sure who its
clients are in order to inject FDI into them....it's not much good if
those clients change.  This long-lasting client/server permanence has
been a traditional truth in nested PDH/SDH co-cs mode transport layer
networks...which is of course where the notion of AIS comes from as I
explained.  But what if the clients can change more dynamically?  Start
by envisioning co-cs or co-ps mode SVC clients (eg co-cs PSTN) which
have shrinking holding times......in the limit this become a single
message of a cl-ps mode client layer network.  So if we imagine a link
connection in such a client layer network (ie a single hop between 2
adjacent client layer nodes which is provided by a network connection in
some lower layer server network) it becomes quite clear that we cannot
assign any permanence between a specific client communications instance
and their use (or not) of that link (=server network connection).
Hopefully you can see that.  And this is why it makes no sense
whatsoever to carry over the idea of AIS/FDI into cl-ps mode layer
networks and explains why IEEE had the good sense to take AIS out of
802.1ag.

We discussed the issue of FDI within BT when considering the OAM we
would want for PBB-TE (co-ps mode based on using the original cl-ps
Ethernet traffic unit), and on balance we considered it was not a good
idea.  However, the CV and BDI OAM functions are essential....but they
should NOT be piggybacked in order that we can properly address the p2mp
connection case.

But as I also noted in my mail, a key requirement on OAM (at least that
used for defect detection) is that it is super reliable, and that tends
to mean as sparse as possible of function with minimal configuration.
Anything that requires lots of config (and the TCM stuff factors heavily
here - see later comment) is really not a requirement.
> 
> 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?
NH=> Please remember that CV and FDI are very different.  CV checks THIS
layer network, FDI is an indication of failure (possibly from a CV flow
detected defect) in a LOWER layer network.  I've seen folks try and 'do
away' with CV and just use FDI...it's a mistake.....as to get FDI SOME
layer network has to be able to detect it's failures, and it won't
always be the section layer, ie very bottom of stack, that can do this.
No CV means you are blind to defects in your layer network, you only see
server layer defects IFF they generate a FDI into your layer network
across the adaptation function...and as explained above, FDI/AIS is not
such a great idea as folks might think.
> 
> Maybe the problem stems from the fact that SPs are often 
> trying to use Ethernet, that is inherently connectionless, in 
> a connection oriented manner!
NH=> Well yes....but the mere fact that special topology consideration
exists (ie the p2p degenerate network case you mentioned above) is not
the general network case.  
> 
> > 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!
NH=> It is rather important/fundamental....but it is violated all over
the place.  I'll say no more on the matter here.

> 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."
NH=> This is all about TCM.  One might like to observe that in any
general layer network only the access points are fixed....intermediate
points can change, and indeed MUST change if we want to have resiliency.
(You may be struck here by the similarities to the point I made earlier
regarding FDI and how one can't assume a permanence between a client
communications instance and the links (=server layer connections) it is
using at any epoch).  Now try and get your head around how you would
manage the config of such (moveable) intermediate points, especially if
you were trying to get accurate perf mon (PM) data across failures and
restorations.  TCM sounds good on paper, but show me the management
solutions for PM across dynamic changes of routing.  Hint=> I've looked
quite closely at doing this at end points that are time invariant/fixed
in the past and this is not a simple problem even here (eg pkts
in-flight, clock differences) now extrapolate that problem to a raft of
nested TCM levels that are not invariant/fixed....let me know when you
have an answer for PM in TCM across failures/restorations ;-)

Regards, Neil


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