Subject: RE: Proposal to Progress draft-nadeau-pwe3-oam-msg-map-04.txt as a PWE3 WG Item

From: [email-masked]
Date: Mon, 1 Mar 2004 14:45:07 -0000

> I have not seen your contribution/draft proposal in the IETF yet
> (hopefully this is forthcoming).

Please can you explain why you see the need for a contribution/draft to be submitted to the IETF? Y.1711 has been clearly defined and standardised by the ITU. If you are asserting that standards are only valid if they have been submitted to the IETF, are you also expecting contributions/drafts to be submitted to the IETF explaining how ATM, FR, TDM, etc. work?
 
Regards,
Richard

---

From: Kenji Kumaki <[email-masked]>
Date: Tue, 02 Mar 2004 00:13:38 +0900

Hi all,

This draft is useful OAM from the point of SP's view.
I would like to support this one as a WG doc.

Regards,
Kenji

On Mon, 1 Mar 2004 04:59:53 +0100
"Monique Morrow (mmorrow)" <[email-masked]> wrote:

> Folks,
>  
> I presented OAM Msg Mapping status today in Seoul,
> http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-04.txt
> with a proposal to progress the draft as a Working Group item  
>  
> Whilst we had no opposition the room, I would like to ensure that there
> is consensus on the list to progress the draft as a WG item.
>  
> Essentially, the draft has been revised to reflect like-to-like
> constructs as per the scope of PWE3 and, covers fault detection and
> alarm message mapping as two separate elements.
>  
> /Monique
>  
>  

-- 
Kenji Kumaki <[email-masked]>

---

From: [email-masked]
Date: Mon, 1 Mar 2004 20:56:34 -0000

Many thanks Peter for providing a useful and reasoned response here......please see below.  regards, Neil

Busschbach, Peter B (Peter) wrote 01 March 2004 16:18:

> > 1	No defects are defined anywhere (not just in here but 
> > in any other IETF draft/rfc) in terms of clear entry/exit 
> > criteria and consequent actions.  Note that the defects in 
> > MPLS are different to the defects in IP.....which should not 
> > be surprising as their modes are different, and even this 
> > draft recognises that fact (also see 4).  CF Y.1711 where 
> > these are specified.
> > 
> 
> The draft identifies several tools for fault detection. IMO, 
> the documents that describe these tools should define entry 
> and exit criteria. The BFD draft already does that. To the 
> extent that the OAM Message Mapping draft should add clarity 
> on entry and exit criteria, we could add that to subsequent drafts.
NH=> Thanks.  But please remember that the defects that are relevant to a co-ps mode are different to those in a cl-ps mode (and both are different to a co-cs mode).  And a co-ps mode which does things like mp2p, PHP and ECMP if different yet again (here I would advise just using ad hoc diagnostics and running automatic defect detection/handling on the higher p2p LSPs where one can).  Y.1711 gives the sort of specification we would be expecting to see.
> 
> > 
> > 2	There is no demarcation between the available state and 
> > unavailable state for network trail entities.  This means 
> > there is no temporal basis for the specification of an 
> > availability SLA or a network performance SLA, noting that 
> > the latter is only relevant to the available state.  These 
> > impact network element specifications and thus have 
> > consequential impact on NMS/OSS.  NE and NMS/OSS 
> > considerations are important for an operator to see correctly 
> > executed.  CF Y.1711 where the unavailable state is specified 
> > (as a consequential persistence of defects).
> > 
> 
> Adding a definition of availabillity would be pretty easy to 
> specify and implement. I would like to understand better, 
> though, how this would be used in practice. It seems to me 
> that SLAs apply to the services carried over PWs, not to the 
> PWs themselves.
NH=> Several points here.

First, there is a difference between QoS and Network Performance (NP) metrics/objectives.  The former are what a specific application percieves, whereas the latter are application invariant (ie for a given level of NP impairment different applications can have quite a different perspective on QoS).  NP metrics are really what the network elements should capture and SLAs specify.

Second, the control of availability and NP are complementary performance requirements.  If one does not have an agreed datum at which NP metrics should no longer be counted then one can easily distort the NP SLA.  There is also the requirement to measure the same 'apples and apples' here in different networks/equipment.....and this also applies *across* nested layer networks (the commonly agreed integration period for assessing availability is based on 10s of outage). Further, a service which has a 99% unavailability can still have perfect NP......this is why these metrics are complimentary.  See section 7 of Y.1711 for more info.

Third, there is a key ordering behaviour here:
=> ensure the right net arch for mode considered 1st
=> this allows the relevant defects to be identified
=> this allows appropriate OAM to be specified (and from this defect entry/exit criteria and consequent actions)
=> this allows unavalability entry/exit criteria to be specified based on defect persistence
=> this allows the up-time to be specified over which NP is relevent
You can very easily make life more complex than it need be by not following this ordering.  Further, and for complexity reasons, I would also not advise using NP metrics within the availability entry/exit criteria.....just use defect persistency.  Much careful thought went into Y.1711 on these, and several other, matters that may not be readily apparent to someone on a cursory reading.
> 
> > 
> > 3	Seq Nos cannot be left 'open-ended' wrt aberration 
> > handling.  At some degree of persistent corruption a defect 
> > state must be declared.  This therefore requires entry/exit 
> > criteria and consequent actions specifying.  We note this is 
> > at least recognised as an open issue in section 4.1.1.
> > 
> 
> agreed
NH=> Thanks Peter, I do know that you also recognise this point.
> 
> > 
> > 4	A PW is *not* a networked entity....it is just an 
> > adaptation function (now whether it is a good adaptation 
> > function for the server layer considered is a different 
> > consideration).  An LSP however is a networked path entity in 
> > the case of using MPLS (co-ps mode).  Similarly, an IP pkt is 
> > also a networked entity (in the case of an IP cl-ps mode 
> > server layer).  XoverMPLS is therefore not the same as 
> > XoverIP....I am perplexed as to why this fact so hard for 
> > some folks to grok/accept.  Is it to make the work palatable 
> > to IETF folks?  But who is kidding who here?  Whilst this 
> > stance might be necessary to 'sell' this stuff in IETF, 
> > speaking as an operator we can't afford to base future 
> > network investments on such misplaced ideologies....we need 
> > this stuff properly architecting else it will impact our 
> > costs (both capex and opex) and the efficacy of the services 
> > we can offer.  
> > 
> > This distinction between MPLS and IP is even recognised in 
> > the draft.....for example, in section 4.1 it says:
> > 
> > "In case of MPLS there are additional failures (see also [ITU-T 
> >    Y.1710]). E.g. 
> >     
> >    . PW mislabeling, which could be due to a failure on the 
> > ingress PE 
> >      or due to an over-writing of the PW label value 
> somewhere along 
> >      the way 
> >     
> >    . Label swapping or LSP mismerge in the PSN network, which could 
> >      result in the termination of a PW at the wrong egress PE. 
> > 
> >    . Unintended self-replication (e.g. due to loops or denial-of-
> >      Service attacks) "
> > 
> > This is of course correct. Note that these defects *cannot* 
> > occur in a cl-ps server layer like IP, which is precisely 
> > what the above text implies, because a cl-ps server layer 
> > must always have a network significant DA/SA pair in each 
> > packet.  However, when using a co-ps forwarding mode like 
> > MPLS this is not the case.  Here we have a trail entity (ie 
> > an LSP) that is constructed between addressable (ie network 
> > significant) access points by the concatenation of a sequence 
> > of single link-connection (downstream only) significant identifiers.
> > 
> > So given this is even recognised in the draft now (and as one 
> > reads through the draft it becomes increasingly clear that 
> > the MPLS server layer case is being treated quite differently 
> > to the IP server layer case), then why not go the extra step 
> > and come clean by accepting that we don't have to force 
> > XoverMPLS to be the same as XoverIP?  We could have a 
> > nice/simple adaptation for carrying clients over arch 
> > compliant MPLS now and really start to leverage the latent 
> > potential of MPLS.
> > 
> > Can someone please explain to us why this can't this be done 
> > (and please don't use mp2p and PHP as excuses....we know 
> > these are broken arch flavours of MPLS, we just have to live 
> > with these and move on....we should not keep making further 
> > mistakes on the back of past mistakes)?
> > 
> 
> Many of the procedures described in the document apply to 
> both X-over-MPLS and X-over-IP. Some procedures depend on the 
> specific type of PSN and are identified as such. 
> 
> I don't understand why it is so hard to grok that there is an 
> advantage in trying to achieve as much commonality as 
> possible between both modes, given that many network elements 
> support both MPLS and IP.
NH=> Oh I do understand why some might hold this view.  However, it is a fact that a co-cs mode is different to a co-ps mode is different to a cl-ps mode.  One can get far more benefits IMO by using these differences wisely rather than not.  We have further stuff we are pursuing where using the modes in a complimentary manner can lead in our view to a better alternate network services vision.....however, this is outside the scope of this thread.
> 
> 
> > 
> > 5	Can someone please explain to us why Y.1710 (which is 
> > largely about principles/requirements) is at long last 
> > recognised in this draft but Y.1711 is not recognised as a 
> > valid OAM solution for MPLS?  This is especially puzzling for 
> > us as Y.1711 is simple and complete (wrt defect and 
> > availability specifications) and was written by an 
> > operator.....so one might get the hint here that it was 
> > something that we 'required' ;-)  It seems quite bizarre that 
> > this is not included (even for completeness of reference), 
> > especially noting this remark at the end of section 4.2.2:
> > 
> > "Based on these observations, it is clear that a Service 
> > Provider has the disposal of a variety of tools. There are 
> > many factors that influence which combination of tools best 
> > meets its needs." 
> > 
> > Is there some specific technical (or other) reason why Y.1711 
> > cannot be referenced?
> > 
> 
> No technical reason. Since Y.1711 is controversial within the 
> IETF, it was decided to leave it out of the current draft and 
> ask  the mailing list for their opinion about the inclusion 
> of Y.1711. That request went out a while ago and several 
> people responded. I assume it is up to the WG Chairs to make 
> the final decision.
NH=> What am I supposed to say to this?  Seems a very strange situation where some folks can work on a control-plane for SDH and yet ignore a simple/complete MPLS OAM solution like Y.1711.  It should at least be referenced even if folks then choose to ignore it for their own reasons.
> 
> > 
> > 6	In section 4.4 it says:
> > 
> > "Besides reporting PW failures, PW status is used to 
> > propagate AC failures. When and how to use those messages is 
> > dependent on the emulated protocol and will be explained in 
> > the subsequent paragraphs 5.3 and 6.3)."
> > 
> > This is generally incorrect.  If one respects the 
> > client/server architectural requirements (in particular 
> > client and server layer independence, and client layer 
> > transparency) then a failure of a client layer network should 
> > have no consequential impact on any server layer.  The above 
> > statement is violating layer independence and it is therefore 
> > not a good idea.  It's the same as asking a SDH network to 
> > carry an ATM client (or any other client) layer's failure 
> indications.
> > 
> > And what happens if the client and server layers are own by 
> > different operating parties?  This is obviously a wrong 
> > behaviour here.
> > 
> > Each layer network must be self-contained and in a 
> > client/server relationship they must be independent.
> > 
> 
> I agree. As you can verify, the behavior specified for PWE of 
> ATM, SONET (CES)and TDM (SATOP) meets your requirements. 
> However, what to do in case of Frame Relay? Frame Relay 
> doesn't have a standard in-band way of conveying state 
> information  from one NNI to another. In case a PW is used to 
> connect two FR NNIs, it was decided to use the PW Status 
> message to carry AC state information.
> 
> What do you propose? Should we eradicate Frame Relay from 
> this world because it doesn't meet your client/server principles? :-)
NH=> No of course not....but vendors specified FR not operators.  There is a lesson there ;-)
> 
> 
> >  
> > 7	In section 4.7 it says:
> > 
> > "PWs can fail in a single direction or in both directions. 
> > PEs SHOULD keep track of the status of each individual 
> > direction. In other words, a PE SHOULD be able to distinguish 
> > between the following states: "PW UP", "PW Transmit Direction 
> > Down", "PW Receive Direction Down", "PW Receive and Transmit Down". 
> >    
> > The next two sections discuss under which conditions a PE 
> > enters and exits these states. To avoid an unnecessarily 
> > complicated description, only the states "PW UP" and "PW 
> > DOWN" are discussed without further analysis whether it 
> > applies to one or two directions of the PW."
> > 
> > Be careful here.  Performance metrics apply unidirectionally 
> > and only to the available state.  However, for many 
> > applications the failure of one direction effectively means 
> > *both* directions must be considered as failed.  Thus even if 
> > only a single direction fails (though to be accurate, this 
> > actually means if one direction enters the unavailable state) 
> > then the collection of performance metrics of *both* 
> > directions should be suspended....at least wrt to their 
> > meaning against any performance SLAs that are being measured. 
> >  Have a read of Y.1711, as this explains what is required here.
> > 
> > 
> 
> Good point. The PW Status error codes distinguish between the 
> PW being down in one direction and it being down in both 
> directions. Therefore, the PEs need to maintain the states 
> identified in the document. However, as far as availability  
> from an operator perspective is concerned, the PW should be 
> considered down even if only one direciton is down. We can 
> clarify that in the next draft.
NH=> Thanks....but note my earlier comments on availability vs NP objectives.  Its so easy to make life very hard for yourself.  These aspectes were considered in Y.1711 in an attempt to make this stuff simple.
> 
> 
> > 8	In section 4.7.1 it says:
> > 
> > "Note that if the control session between the PEs fails, the 
> > PW is torn down and needs to be re-established. As a 
> > consequence, control session failure leads to disappearance 
> > of the PW, not to a PW Down state." 
> > 
> > This should not be taken as a general requirement.  Failures 
> > of control-plane components should not necessarily remove 
> > data-plane trails that have been set-up.  This is 
> > particularly true in the case of S-PVC-like constructs.
> > 
> 
> I agree, but IMO this should be resolved in the Control 
> Draft.
NH=> I agree.  But maybe the requirement should at least be noted.

> The current version of the control draft refers to  
> RFC 3036 for the use of LDP to set up PWs. In my 
> interpretation that means that a PW must be torn down if the 
> LDP session fails. Graceful Restart for PWs could be added 
> but would require specific text to that effect. Once it is in 
> the Control Draft, we could update the OAM Message Mapping 
> draft accordingly.
> 
> 
> > 
> > 9	Towards the end of section 5.2 FR 'port-mode' is 
> > mentioned.  Similarly in section 6.2 wrt ATM 'transparent 
> > mapping' it says:
> > 
> > "In case of transparent mapping, where the PE does not keep 
> > track of the status of individual ATM VPCs or VCCs, it is 
> > possible that a PE does not know which VPCs and/or VCCs are 
> > active. In such a case there is a need for another fault 
> > indication mechanism on the AC. This is beyond the scope of 
> > this document."
> > 
> > 'Port-mode' has no meaning in functional architecture 
> > terms.....and for a good reason as the extract above 
> > demonstrates....and really ought not to be used for any client case.
> 
> I think there are situations in which the port mode makes 
> sense and where proper behavior can be specified. It is, 
> however, our of scope and I don't think we should use 
> bandwidth on the mailing list to discuss that.
NH=> OK, but the cases where this can be resolved are not clear to me however.

---

From: [email-masked]
Date: Tue, 2 Mar 2004 09:09:32 -0000

> Neil,
> 
> Without re-quoting the email exchange (to save us all some BW 
> and disk 
> space), it's clear that you have some technical problems with 
> this draft. 
> :-)  However, are you opposed to this becoming a working 
> group draft solely 
> on the technical grounds, or because you also feel that it's 
> not a valid WG 
> work item because it doesn't fit within the charter and/or 
> because you feel 
> that it's not a useful work item?  If your objection is 
> solely technical, 
> then it can still become a WG draft, and we can all work 
> towards correcting 
> the details.  Personally, I think this fits within the WG charter 
> (especially now since the interworking aspects have been removed) and 
> provides not just useful, but required, functionality.
> 
> Cheers,
> Andy

Hi Andy,

Our concerns are not whether: (i) this work in/out charter?, and/or (ii) this draft is technically correct?, and/or(iii) this is useful work anyway?  We have a more fundamental issue regarding the efficacy of the architecture and the functional components of the underpinning technologies concerned.

Let me try and explain this.  I work closely with some of the guys who did a lot of the G.805/809 functional architecture stuff.  We have a deep passion about getting the net arch right. Why?  Well, bitter experience has taught us that bad net arch will hurt downstream in many ways.....esp when its consequences play right through to NMS/OSS.  We have been here far too many times in the past.  So any technology that (i) breaks the arch rules of the network mode considered and/or (ii) has significant functional deficiences is going to start ringing alarms bells for us.

Now folks here would not get too upset if this stuff stayed niche, but when things like MPLS start to get discussed as a key core convergence technology then we are going to take a far stronger interest in it.

(To save your hard disc) I won't repeat the arguments about what is wrong with MPLS as-is, PWs not being a proper layer network, etc.  We are sure of our ground here, but we also know there is no point arguing with folks you don't understand the func arch language (or perhaps have other reasons for not wanting to accept our arguments). 

Currently we regard MPLS as not fit-for-purpose as a key convergence technology.....and from discusssions we have had with engineers in several other operators it seems we are not alone in this view (though very few operators are active in standards these days, and even fewer are prepared to say anything in public for various reasons).

You have heard me say in the past that we need all 3 networking modes, and that the key challenge we have is working out how to make them work together most optimally to deliver a full range of network services that are fairly-priced, meaningful and secure in a future-proofed architecture at min capex/opex.....and we have some ideas on how to do this.  To us this starts with a good appreciation and respect of G.805/809 principles (though its more than that).  We need some technology to assume the co-ps role in this architecture, and in fact this does not have to be MPLS.  But if MPLS can assume this role then great.  But to do so the broken stuff needs to be deprecated over the long-term and the missing stuff added (eg the need an OOB control/management-plane that you/I briefly discussed a while ago when you came to see us).  We would also like to see a simpler adaptation for carrying clients over LSPs.  Put simply, we'd like to be able to do far more with MPLS and *not* PWs.

Now let's get back to this draft.  Its not that long ago we tried to get folks in IETF interested in adding an OAM functional component to MPLS.  Initially this idea was ridiculed......'go buy from a decent vendor and don't fix bugs with more SW' was the gist of the initial rebuff. We then tried running a BOF...little joy even then.  However, when deployed stuff started breaking then suddenly MPLS OAM is back on the agenda.  And not only that, I am seeing stuff that looks like my own words being played back now, eg don't use the control-plane to proxy for missing data-plane OAM, mis-branch/merge defects need factoring-in (because its a co-ps mode), etc.  Even Y.1710 requirements/principles is now getting quoted.

So, in summary:
-	whether this draft is in/out of charter is irrelevant in our view
-	the only thing that matters to us is whether MPLS is architecturally fit-for-purpose or not as a key core convergence technology, and this cannot be solved by any amount of tinkering with this draft
-	I do have some technical concerns with the draft (and I have already given some that Peter B has kindly responded to)......but fixing these will still not address our deeper arch concerns over MPLS
-	we are pleased to see service i/w removed at least.....though service i/w with PWs has no arch meaning IMO.

regards, Neil