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

[<[e-mail]>]

Thanks Maarten,

I don't have time right now to engage you in a detailed discussion of
all these points...many of which relate to the same issues you have with
my colleague Andy Reid etc in the SG15 unified modelling work, ie what
is a connection, etc.  However, I fully stand by what I said earlier wrt
key principles here....and to quickly summarise:
-	if a technology is so bad it must have complex OAM and be
monitored to death the problem lies with the technology/network design,
eg the FUD over the alarm storm issue to justify AIS where it is simply
not required nor used today, eg IP networks;
-	OAM must be as a simple and sparse of function as
possible...largely because it must be super reliable but also because it
has an opex cost to configure/run/process;
-	in all nested TCM proposals over the last 10+ years I have seen
no solution for their automatic configuration and accurate processing
handling across failures/restorations....if this stuff was so vital
we've have done loads of it by now...but for some reason we haven't.

Regards, Neil

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]] 
> Sent: 14 July 2008 09:14
> To: Harrison,N,Neil,CXM R
> Cc: [e-mail]
> Subject: RE: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt 
> as WG draft
> 
> Neil,
> 
> AIS/FDI OAM for all technologies is associated with 
> configured point-to-point, point-to-multipoint, 
> rooted-multipoint and multipoint-to-multipoint 'transport 
> entities' (i.e.
> PDH/SDH/OTN/ATM/MPLS(-TP)connections, Ethernet VLANs 
> (inlcuding a standalone 802.1D network)). AIS will also be 
> associated with the point-to-point and point-to-multipoint 
> PBB-TE connections.
> 
> COCS, COPS and CLPS are three types of forwarding mode within 
> 'transport entities'. 'Transport entities' itself 
> **connection-oriented**, connection admission controlled and 
> traffic engineered; they are set up under management plane 
> control, with or without the help of a control plane.
> 
> - COCS is a forwarding mode in a 'transport entity' in which 
> every traffic unit is treated identically from a forwarding 
> perspective in the switch functions and link ingress points.
> - COPS is a forwarding mode in a 'transport entity'in which 
> every traffic unit is treated identically from a forwarding 
> perspective in the switch functions (same as COCS case), but 
> may be treated differently in link ingress points. In link 
> ingress points the CoS and Discard Eligibility of the traffic 
> unit determine the forwarding.
> - CLPS is a forwarding mode in a 'transport entity' in which 
> traffic units may be treated differently from a forwarding 
> perspective in switch functions and link ingress points. In 
> the link ingress points the CoS and Discard Eligibility of 
> the traffic unit determine its forwarding (same as in COPS 
> case). In the switch fucntions the value of a label within 
> the traffic unit (e.g. address label or demultiplexer label) 
> determines the forwarding of a traffic unit within the 
> 'transport entity'.
> 
> CLPS forwarding behaviour within 'transport entities' is 
> specified today for Ethernet VLANs and IP VPNs. 
> The label in the traffic unit that is used to determine which 
> output port or output ports of the VLAN/VPN 'transport 
> entity' should receive this traffic unit is the destination 
> address label.
> 
> 	Note that an 802.1D network is an Ethernet network with 
> a single VLAN (single 'transport entity'). 
> 	The 'internet' is an IP network with a single (public) 'IP VPN'
> (signle 'transport entity').
> 
> In **theory** it is possible to specify CLPS forwarding also in e.g.
> point-to-multipoint MPLS tunnels when those tunnels carry 
> point-to-multipoint MPLS PWs (with each PW carrying e.g. a TV 
> channel).
> Forwarding of a traffic unit within a MPLS tunnel connection 
> in a MPLS tunnel switch will - in a CLPS mode - depend on the 
> value of the PW label inside the traffic unit. For this 
> purpose PW labels will be registered per MPLS tunnel output 
> port, and if a PW label value X is not assocaited with a 
> tunnel output port Y, then the MPLS tunnel traffic unit will 
> not be forwarded via this output port Y.
> 
> OAM mechanisms are specified to monitor these 
> **connection-oriented** 'transport entities'. 
> OAM mechanisms are not specified to monitor the individual 
> traffic units or streams of traffic units that are 
> transported between ports of 'transport entities'.
> 
> AIS/FDI, LCK, OCI/UNEQ are OAM maintenance signals that are 
> generated within the scope of the **connection-oriented** 
> 'transport entity', including the Ethernet VLAN 'transport 
> entity'. That is why Ethernet AIS is specified in Y.1731, 
> G.8021 and G.8051. Without this Ethernet AIS OAM you will get 
> alarm storms in Ethernet VLAN and VPLS transport networks.
> 
> You need the AIS/FDI based alarm suppression mechanism as 
> soon as you deploy a 'transport entity' continuity check 
> mechanism and you can not guarantee that a broken 'transport 
> entity' has its connectivity restored within 2 seconds. As 
> PBB-TE tunnel connections are set up under management 
> control, PBB-TE AIS will be necessary to prevent PBB-TE 
> tunnel Loss of Continuity alarm storms after a cable with 96 
> fibers, each carrying e.g. 80 40G wavelengths is broken.
> 
> Note that a Server MEP has nothing to do with TCM. A Server 
> MEP is a MEP in the server layer. Example of ETH Server MEP 
> function: SDH VC-n termination plus Sn/ETH adaptation function.
> 
> ---
> 
> Every layer has three types of Maintenance Entity Groups 
> (MEG) within a 'transport entity':
> 1) Network Connection (NC) MEG level
> 2) Tandem Connection (TC) MEG level
> 3) Link Connection (LC) MEG level.
> 
> The NC-MEG level is always present in a layer network 
> supporting OAM. It is however an operator's choice to deploy 
> the available OAM at this NC-MEG level.
> 
> TC-MEG and LC-MEG level presence depend of the layer 
> network's role (transport service layer, transport tunnel 
> layer, transport link layer), single/multi-owner status of 
> the 'transport entity' and survivability
> (protection) requirements.
> 
> 
> A) Transport Link (or Section) layer requires typically 
> support of the NC-MEG level only; i.e. case of I-NNI and E-NNI. 
> Only when this link/section layer signal is treated as a 
> port-based service TC-/LC-MEG levels will become important; 
> i.e. case of UNI.
> 
> B) Transport Tunnel (or Path) layer requires typically 
> support of the NC-MEG level only; i.e. case of I-NNI and E-NNI.
> When this tunnel/path layer signal is treated as an 
> individual or bundled service entity, then TC-/LC-MEG levels 
> will become important; i.e. case of UNI and carrier-carrier.
> Tunnel protection switching is assumed to be performed 
> between PE nodes using the NC-MEG level MEP functions to 
> monitor for SF/SD status.
> 
> C) Transport service (or Channel) layer requires support for 
> the NC-MEG level and possibly for TC-MEG and LC-MEG levels as well.
> When the service/channel layer 'transport entity' starts/ends 
> inside the transport network (at UNI-N ports) of a single 
> network operator and if such 'transport entity' is not 
> protected, then the NC-MEG will be the only active MEG level. 
> When protection of a 'transport entity' segment is required, 
> a TC-MEG level is necessary to monitor the segment.
> When two or more network operators provide the 'transport 
> entity', each operator want to be able to monitor the 
> status/performance of the 'transport entity' segment in its 
> network; this requires the presence of a TC-MEG level.
> When the 'transport entity' starts/ends in the customer 
> domain, the NC-MEG level is owned by the customer and the 
> transport network must deploy a TC-MEG level to monitor the 
> status/performance provided by the transport network between 
> the UNI-N ports. For this case, the LC-MEG level may be used 
> to monitor the status/performance of the 'transport entity' 
> segment on each UNI (CE to T-PE) and E-NNI.
> 
> When the PBB-TE tunnel layer is a tunnel/path layer operated 
> within the administrative domain of a single network operator 
> you will need only the NC-MEG level. 
> As soon as PBB-TE tunnel connections may start/end in the 
> customer domains or in two network operator domains, PBB-TE 
> tunnel layer will need TC-MEG and LC-MEG levels.
> 
> Regards,
> Maarten
> 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of [e-mail]
> Sent: 12 July 2008 10:16
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [PWE3] draft-mohan-pwe3-mpls-eth-oam-iwk-00.txt 
> as WG draft
> 
> 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
> 
> 
> 
_______________________________________________
pwe3 mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/pwe3