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

From: "Busschbach, Peter B (Peter)" <[email-masked]>
Date: Mon, 1 Mar 2004 11:18:28 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, March 01, 2004 7:55 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: [PWE3] Proposal to Progress
> draft-nadeau-pwe3-oam-msg-map-04.txt as a PWE3 WG Item
> 
> 
> <converted to plain text from original HTML format>
> 
> Monique Morrow wrote 01 March 2004 04:00
> 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.
> ====
> 
> We (ie BT) cannot support this document as it stands for 
> several reasons....for example:
> 
> 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.

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

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

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

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

> 
> 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? :-)

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

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

> 
> 
> .....so far.....regards, Neil
> 
> 
> 
>  
>  
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "David Allan" <[email-masked]>
Date: Tue, 2 Mar 2004 03:42:27 -0500

I'd like to suggest a more specific title,

"Interworking of fault notifications for PWs", OAM is a BIG subject....

Neil does provide an important list of items to be addressed. I'd
specifically amplify that directional of notifications (AIS vs RDI) needs to
be preserved, a simple down indication is the degenerate case.

I've also suggested that Y.1712 should be in the document....

cheers
Dave

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Tue, 2 Mar 2004 15:30:04 +0100

Dave,
 
Certainly up for discussion -- would like to collaborate further.
 
Thanks !
 
/m

	-----Original Message-----
	From: David Allan [mailto:[email-masked]] 
	Sent: 02 March 2004 09:42
	To: 'Busschbach, Peter B (Peter)'; [email-masked]';
Monique Morrow (mmorrow); [email-masked]
	Cc: Shahram Davari
	Subject: RE: [PWE3] Proposal to Progress
draft-nadeau-pwe3-oam-msg-map-04. txt as a PWE3 WG Item

	"Interworking of fault notifications for PWs", OAM is a BIG
subject.... 

	Neil does provide an important list of items to be addressed.
I'd specifically amplify that directional of notifications (AIS vs RDI)
needs to be preserved, a simple down indication is the degenerate case.

	cheers 
	Dave