Subject: RE: Control protocol draft - section 5.3.1 change to PWst atus.

From: [email-masked]
Date: Thu, 24 Feb 2005 08:42:35 -0000

Mutatapha...It is not correct or acceptable to simply focus on one facet
here (ie OAM) of a client/server layer network relationship. The clear
requirement is simply this:

	A client layer network (all planes) should be transported
tranparently over any server layer network.

I do not think is useful to simply home-in on the OAM aspects
only....and even then just the 'always-on' defect detection/handling
OAM, as there is also 'on-demand' OAM, eg PM probes, diagnostics.

Note - One has to accept that in the past not all layer networks have
been functionally well-specified.  However, this is no reason or excuse
to continue this problem into next generation networks.  Sadly I think
we are some way of achieving this (and in fact some things are getting
worse not better IMO), and speaking as an operator I am not happy this
is the case....esp when its rather obvious IMO what is required to do
things correctly, based on knowldege gained over many years and by using
formal network modelling techniques like functional architecture.

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mustapha Aissaoui
> Sent: 23 February 2005 15:09
> To: 'Shahram Davari'; 'Luca Martini'
> Cc: Harrison,N,Neil,IKM1 R; [email-masked]
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 
> change to PWst atus.
> 
> 
> Shahram,
> This is why I asked that we should only withdraw the label 
> when the AC is administrativley DOWN when the label withdraw 
> method is used. Operational status should be updated by 
> AIS/RDI which gets passed transparently if the label is not 
> whithdrawn.
> 
> Mustapha.
> 
> -----Original Message-----
> From: Shahram Davari [mailto:[email-masked]]
> Sent: Wednesday, February 23, 2005 9:45 AM
> To: 'Luca Martini'; Mustapha Aissaoui
> Cc: [email-masked]; [email-masked]
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 
> change to PW st atus.
> 
> Luca,
> 
> > >Luca,
> > >However, it all appears that if the label withdraw PW status
> > method is used,
> > >then a label is withdrawn if say a AIS cell is received from
> > the local ATM
> > >network or LMI indicated a fault. Am I wrong?
> > >
> > >
> > >
> > yes. This is correct, then the remote end would re-generate the AIS 
> > alarm.
> >
> 
> How does the other end know whether this is an administrative 
> withdrwal for removing the service (in which case it should 
> not generate AIS) or it is a withdrawal caused by a fault (in 
> which case it should generate AIS)?
> 
> -Shahram
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Thu, 24 Feb 2005 09:55:26 -0500

Neil,
it is understood that other ATM OAM capabilities are carried transparently
over the server layer. This is clearly described in
draft-ietf-pwe3-oam-msg-map-02.txt.

However, I do not think that such a general requirement can easily be met
with all client layer technologies. For example, FR OAM (FRF.19) has been
specified late in the game anf there has not been much deployment out there.
Therefore, in the above draft, we allow the translation of FR PVC status
into either PW status signaling or into BFD status. This is just a pragmatic
approach to deal with some of the realities of the existing link layer
techonologies.

Regards,
Mustapha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 24, 2005 3:43 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PWst
atus.

I do not think is useful to simply home-in on the OAM aspects only....and
even then just the 'always-on' defect detection/handling OAM, as there is
also 'on-demand' OAM, eg PM probes, diagnostics.

Note - One has to accept that in the past not all layer networks have been
functionally well-specified.  However, this is no reason or excuse to
continue this problem into next generation networks.  Sadly I think we are
some way of achieving this (and in fact some things are getting worse not
better IMO), and speaking as an operator I am not happy this is the
case....esp when its rather obvious IMO what is required to do things
correctly, based on knowldege gained over many years and by using formal
network modelling techniques like functional architecture.

regards, Neil

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mustapha Aissaoui
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to
> PWst atus.
>
>
> Shahram,
> This is why I asked that we should only withdraw the label when the AC
> is administrativley DOWN when the label withdraw method is used.
> Operational status should be updated by AIS/RDI which gets passed
> transparently if the label is not whithdrawn.
>
> Mustapha.
>
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to
> PW st atus.
>
> Luca,
>
> > >Luca,
> withdrwal for removing the service (in which case it should not
> generate AIS) or it is a withdrawal caused by a fault (in which case
> it should generate AIS)?
>
> -Shahram
>
>
>

---

From: [email-masked]
Date: Thu, 24 Feb 2005 15:48:20 -0000

Mutahpha...please see below.

> From: Mustapha Aissaoui [mailto:[email-masked]] 
> Sent: 24 February 2005 14:55
> To: Harrison,N,Neil,IKM1 R
> Cc: [email-masked]; [email-masked]; [email-masked]
> it is understood that other ATM OAM capabilities are carried 
> transparently over the server layer. This is clearly 
> described in draft-ietf-pwe3-oam-msg-map-02.txt.
NH=> Transparency is a general requirement of any XoverY.  This ought to
be a non-issue.  Why on earth folks decided to start compressing clients
(and in so many ways in some cases) is quite beyond me.  Have you ever
looked at the load points at which real networks run, and understood why
this is so?  BW squeezing is not a key requirement....avoiding
complexity and layer violations is however. 
> 
> However, I do not think that such a general requirement can 
> easily be met with all client layer technologies.
NH=> This was precisely my point below.  BUT, we should not use this as
an excuse to continue to get it wrong.

> For 
> example, FR OAM (FRF.19) has been specified late in the game 
NH=> And largely by the vendor community....sound familiar?

> and there has not been much deployment out there.
NH=> Don't you think MPLS was also rather 'late in the game' at doing
anything about OAM?..despite multiple efforts by BT to get folks looking
at this stuff several years ago.  And I'd still like to know where all
the defect cases are specified in terms of entry/exit criteria and
consequent actions....inc stuff like the still open issue on persistent
Seq No abberation.  Can you tell me when this is going to be addressed
please? 

> Therefore, 
> in the above draft, we allow the translation of FR PVC status 
> into either PW status signaling or into BFD status.
> This is just a pragmatic approach to deal with some of the realities 
> of the existing link layer techonologies.
NH=> They are NOT link layer technologies.....these are proper layer
networks (despite how poorly specified some are).  If you want to talk
about section layer technologies that is different, ie stuff that is not
networked and sits right at the bottom of the stack, eg optical,
electrical line codes on Tx media.

regards, Neil  
> To: [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Mutatapha...It is not correct or acceptable to simply focus 
> on one facet here (ie OAM) of a client/server layer network 
> relationship. The clear requirement is simply this:
> 
> 	A client layer network (all planes) should be 
> transported tranparently over any server layer network.
> 
> only....and even then just the 'always-on' defect 
> detection/handling OAM, as there is also 'on-demand' OAM, eg 
> PM probes, diagnostics.
> 
> Note - One has to accept that in the past not all layer 
> networks have been functionally well-specified.  However, 
> this is no reason or excuse to continue this problem into 
> next generation networks.  Sadly I think we are some way of 
> achieving this (and in fact some things are getting worse not 
> better IMO), and speaking as an operator I am not happy this 
> is the case....esp when its rather obvious IMO what is 
> required to do things correctly, based on knowldege gained 
> over many years and by using formal network modelling 
> techniques like functional architecture.
> 
> regards, Neil
> 
> change to 
> when the AC 
> change to