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

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

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

---

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

Neil,

I would like to suggest that we focus on addressing the technical
concerns you may have for the draft itself - this seems most expedient
for all and defer the architecture discussion to the MPLS WG for
example. It may be that you might consider a draft pointing out what you
consider as architectural flaws with a technical proposal to address
these flaws. 

As for this particular draft, we would like to work with you to resolve
some of the specific technical issues.

Regards,

Monique

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 02 March 2004 10:10
To: [email-masked]
Cc: [email-masked]; Monique Morrow (mmorrow); [email-masked];
[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

> 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

---

From: Philip Yim <[email-masked]>
Date: Tue, 2 Mar 2004 10:01:17 -0800

All, BT is a "proven network operator" and Neil et al raises 
some serious points that need to be addressed. In what forum 
I know not but to be sure MPLS will not become a core 
convergence technology unless it "correctly" deals with 
experienced operator views. 

Best

Philip

---- Original message ----
>Date: Tue, 2 Mar 2004 09:09:32 -0000
>From: [email-masked]  
>Subject: RE: [PWE3] Proposal to Progress  draft-nadeau-pwe3-
oam-msg-map-04.txt as a PWE3 WG Item  
>To: <[email-masked]>
>Cc: <[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>, <[email-masked]>, 
<[email-masked]>
>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
> 
>
>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3
Philip Yim

Bodega Networks, Inc.
Bus: 707-479-7640
Fax: 775-890-8293

www.bodeganetworks.com

This electronic message contains information from Bodega Networks, Inc. which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure,copying, distribution or use of the contents of this information is prohibited.

If you have received this electronic message in error, please notify us by telephone or email(to the numbers or address above) immediately.

---

From: [email-masked]
Date: Tue, 2 Mar 2004 20:04:50 -0000

Monique....We have been discussing how to respond to you wrt this mail and your last mail; where you invited us to submit a draft with our proposals in it.....so sorry for the small delay in responding.

I am happy to work on the technical detail of this draft (in fact I have already submitted some comments that Peter B kindly responded to).  However, this assumes this draft is based on the right solution already.....and that is probably not the case.  In fact, the draft already shows that our main concern is true (ie that an adaptation of X to MPLS requires a different treatment to an adaptation of X to IP) by the various areas in the draft where different behaviours are noted both for the different defect types that can occur (ie MPLS server case different to IP server case) and how these may impact the different signalling cases.

Once we have concluded our internal discussions we will try and post something with our ideas in it....some will relate to MPLS per se and some will relate to the adaptation of clients into MPLS, so I am not sure where this best fits.  We'll think on it.

regards, Neil

> From: Monique Morrow (mmorrow) [mailto:[email-masked]]
> Sent: 02 March 2004 14:43
> To: Harrison,N,Neil,IKR2 R
> Cc: [email-masked]; [email-masked]; Reid,ABD,Andy,NUJ91 R;
> Mcguire,A,Alan,XGH6 MCGUIRA R; Willis,PJ,Peter,CD WILLISPJ R;
> Spencer,R,Richard,XGH5 R; Niven-Jenkins,B,Ben,XGH5 R;
> Milham,DJ,Dave,XGJ1 MILHAMDJ R; [email-masked]
> and/or (ii)
> tried to get

---

From: [email-masked]
Date: Mon, 1 Mar 2004 12:54:42 -0000

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

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

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.

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

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?

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.

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.

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.

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.

.....so far.....regards, Neil

---

From: "Monique Morrow (mmorrow)" <[email-masked]>
Date: Mon, 1 Mar 2004 15:10:12 +0100

Neil,

Note the authors of the document are large and part carriers who have
contributed to it --

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

I would also like to note for the record, that this draft had been
proposed as WG item post IETF 58.

We have aligned the document as per the current scope of PWE3.

Regards,

/Monique
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 01 March 2004 13:55
To: Monique Morrow (mmorrow); [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];

 

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.

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

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.

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:

    

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

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?

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

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

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

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.