Subject: Control protocol draft - section 5.3.1 change to PW status.

From: Luca Martini <[email-masked]>
Date: Thu, 17 Feb 2005 16:34:35 -0700

In this section , we were asked to make the implementation of the PW 
status messages/TLV mandatory.
Also all "CE-facing port" terminology will be changed to "attachment 
circuit".

5.3.1. Use of Label Mappings.

   The PEs MUST send PW label mapping messages to their peers as soon as
   the PW is configured and administratively enabled, regardless of the
   CE-facing interface state. The PW label should not be withdrawn
   unless the user administratively configures the CE-facing interface
   down (or the PW configuration is deleted entirely). Using the
   procedures outlined in this section a simple label withdraw method
   MAY also be supported as a primitive means of signaling PW status. It
   is strongly RECOMMENDED that the PW status signaling procedures below
   be fully implemented. In any case if the Label mapping is not
   available the PW MUST be considered in the down state.

will change to:

5.3.1. Use of Label Mappings.
The PEs MUST send PW label mapping messages to their peers as soon as the PW
is configured and administratively enabled, regardless of the attachment
circuit state. The PW label should not be withdrawn unless the user
administratively configures the CE-facing interface down (or the PW
configuration is deleted entirely). Using the procedures outlined in this
section a simple label withdraw method MUST also be supported as a primitive
means of signaling PW status. In any case if the Label mapping is not
available the PW MUST be considered in the down state.

Once, the PW status negotiation procedures are completed and if they result
in the use of the label withdraw method for PW status communication, the
label withdraw PW status method MUST be used. This will result in the PW
label mapping message being advertised only if the attachment circuit
becomes active. The PW status signaling procedures described in this section
MUST be fully implemented.

Please let me know if you have any comments about this text.
Luca

---

From: [email-masked]
Date: Fri, 18 Feb 2005 08:18:03 -0000

Luca asked:  Please let me know if you have any comments about this
text.

Question:  Is there is any inference in this text (or other text in this
draft, or in any other draft for that matter) that a PW must be taken
down in response to a failure on an AC?  If there is then its wrong.
One should NEVER take down a server layer trail in response to a defect
in some client layer link connection.  Just think if we did this for all
nested layer networks right down to optics!

regards, Neil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Luca Martini
> Sent: 17 February 2005 23:35
> To: PWE3 WG (E-mail)
> Subject: [PWE3] Control protocol draft - section 5.3.1 change 
> to PW status.
> 
> 
> The PEs MUST send PW label mapping messages to their peers as 
> soon as the PW is configured and administratively enabled, 
> regardless of the attachment circuit state. The PW label 
> should not be withdrawn unless the user administratively 
> configures the CE-facing interface down (or the PW 
> configuration is deleted entirely). Using the procedures 
> outlined in this section a simple label withdraw method MUST 
> also be supported as a primitive means of signaling PW 
> status. In any case if the Label mapping is not available the 
> PW MUST be considered in the down state.
> 
> Once, the PW status negotiation procedures are completed and 
> if they result in the use of the label withdraw method for PW 
> status communication, the label withdraw PW status method 
> MUST be used. This will result in the PW label mapping 
> message being advertised only if the attachment circuit 
> becomes active. The PW status signaling procedures described 
> in this section MUST be fully implemented.
> 
> 
> Please let me know if you have any comments about this text. Luca
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: [email-masked]
Date: Fri, 18 Feb 2005 10:01:55 -0000

Rishi,

> From: Kulkarni, Hrishikesh (Hrishikesh) [mailto:[email-masked]] 
> Sent: 18 February 2005 09:37
> To: Harrison,N,Neil,IKM1 R; [email-masked]; [email-masked]
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 
> change to PW status.
> 
> 
> I agree with the workings/recommendations of OSI model and 
> the server-client architecture 
> used in networks
NH=> Please do NOT confuse OSI and func arch.  The OSI model is
seriously flawed as it assumes there is only *one* layer network
(L3).....this is patently wrong and has confused many folks.  There are
3 network modes, cl-ps, co-ps and co-cs.  These are all 'L3' in some
arbitrary OSI sense.  One mode is not 'better than another'.  All
technologies map to one of these modes and all 3 are required (by a full
service operator like BT at least).  The 'goodness' of some technology
is solely determined by the completeness and correctness of its
functional component specifications (these are not identical over all
modes but there is significant potential for re-use and there are common
themes).  

Func Arch is about describing networks (all modes) in a rigorous
manner....so its not some sort of 'opinon', its simply a statement of
fact.  It capures all the topological building blocks of networks (and
it especially explains partitioning and layering).  It is (or should be)
a precursor activity to defining NE specifications and management
information models.  However, if the base network arch is not right then
no amount of effort later can recover this (esp at the NMS/OSS and
service-management level....garbage in, garbage out).

regards, Neil
> 
> so let me rephrase the question:
> In case of N:1 ATM pwe3, Multiple CE-side facing interfaces 
> could communicate over a single pwe3. So do you recommend 
> sending label withdraw if one 
> of the ce-side facing interface is administered down?
> 
> also,
> "
> This will result in the PW label mapping message being 
> advertised only 
> if the attachment circuit becomes active. The PW status 
> signaling procedures described in this section MUST be fully 
> implemented. "
> 
> looks like this text is saying, bring up the "server" layer 
> when "client" layer is active.
> 
> I am really interested in knowing, the PW status management 
> in case of N:1 
> and 1:1 PWE3. Please help clarify.
> 
> 
> Rishi
> 
> 
> 
> > From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of 
> > [email-masked]
> > Sent: Friday, February 18, 2005 1:48 PM
> > To: [email-masked]; [email-masked]
> > Subject: RE: [PWE3] Control protocol draft - section 5.3.1
> > change to PW
> > status.
> > 
> >

---

From: [email-masked]
Date: Sat, 19 Feb 2005 12:40:54 -0000

Luca...

> Sent: 19 February 2005 03:20
> To: Shahram Davari
> Cc: PWE3 WG (E-mail)
> Subject: Re: [PWE3] Control protocol draft - section 5.3.1 
> change to PW status.
> 
> 
> Shahram Davari wrote:
> 
> >Luca,
> >
> >Why is there any difference in treating the AC down and 
> receiving say 
> >ATM OAM?
> >
> >  
> >
> I'm not sure I understand what you mean by "treating" ...
> the AC will have a rx fault if it receives an ATM AIS alarm 
> on it.
NH=>The whole point of AIS/FDI is to SUPPRESS alarms not create them! So
if you see an incoming FDI/AIS then the problem is NOT in the layer
network where you see the FDI/AIS....so no alarms should be raised here.

> This 
> will result in a PW status message sent along the PW.
NH=> This is strictly wrong.  You are creating a coupling between the
client and the server layer here.  The client layer FDI should be
transparent to the server.  If we had done what you are suggesting we
would have all layers down to optics somehow signalling higher layer
faults....clearly this is rather silly.

> The AC can be down , and no ATM AIS alarm present.
NH=> Please stop making the association AIS=alarm.

regards, Neil
 
> Maybe 
> there are too 
> many errored cell s on it ....
> Luca
> 
> >-Shahram
> >
> >  
> >
> >>Luca Martini
> >>Sent: Friday, February 18, 2005 10:41 AM
> >>To: Kulkarni, Hrishikesh (Hrishikesh)
> >>Cc: PWE3 WG (E-mail)
> >>Subject: Re: [PWE3] Control protocol draft - section 5.3.1
> >>change to PW
> >>st atus.
> >>
> >>
> >>Rishi,
> >>
> >>I just spotted another problem, the text "CE- facing
> >>interface down" is incorrect.I had already replaced it with 
> >>"attachment circuit". This should resolve your concern.
> >>Also note that the specific status definition for ATM is 
> >>specified in the ATM draft.
> >>
> >>Current text is :
> >>
> >>soon as the PW
> >>administratively configures the attachment circuit down (or the PW
> >>outlined in this
> >>if they result
> >>Kulkarni, Hrishikesh (Hrishikesh) wrote:
> >>
> >>    
> >>
> >>>See comments inline.
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>Luca Martini
> >>>>Sent: Friday, February 18, 2005 5:05 AM
> >>>>To: PWE3 WG (E-mail)
> >>>>Subject: [PWE3] Control protocol draft - section 5.3.1 
> change to PW 
> >>>>status.
> >>>>
> >>>>
> >>>>In this section , we were asked to make the implementation
> >>>>        
> >>>>
> >>of the PW
> >>    
> >>
> >>>>Also all "CE-facing port" terminology will be changed to
> >>>>        
> >>>>
> >>"attachment
> >>    
> >>
> >>>>circuit".
> >>>>
> >>>>  unless the user administratively configures the 
> >>>>        
> >>>>
> >>CE-facing interface
> >>    
> >>
> >>>> procedures outlined in this section a simple label
> >>>>        
> >>>>
> >>withdraw method
> >>    
> >>
> >>>>soon as the PW
> >>>>outlined in this
> >>>>means of signaling PW status. In any case if the Label 
> >>>>        
> >>>>
> >>mapping is not
> >>    
> >>
> >>>The label withdrawal should not be dependent on the state of
> >>>      
> >>>
> >>the CE-facing
> >>    
> >>
> >>>interface.
> >>>take for example N:1 ATM pwe3. Ckts from various CE-facing
> >>>      
> >>>
> >>interface can
> >>    
> >>
> >>>come
> >>>into a single N:1 ATM pwe3.
> >>>
> >>> 
> >>>
> >>>      
> >>>
> >>>>if they result
> >>>>label mapping message being advertised only if the 
> >>>>        
> >>>>
> >>attachment circuit
> >>    
> >>
> >>>Again, in case of N:1 ATM pwe3, one ckt going active or inactive
> >>>should not trigger label advertise or label withdrawals, 
> since there 
> >>>are many other ckts going over the pwe3. 
> >>>
> >>>My request is to spell the above procedures separately for 1:1
> >>>and N:1 pwe3.
> >>>
> >>>rishi
> >>>
> >>>
> >>> 
> >>>
> >>>      
> >>>

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 22 Feb 2005 10:04:33 -0500

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?

Also, how should we interpret the new text? Initially, you advertize the
label regardless of the state of AC. Then, if the PW status negotiation
results in the use of the label withdraw PW status method, would you
immediately withdraw the label because the AC is not active? 

I would like to see a simplification to the procedures. The reason why label
withdrawal is to be avoided as much as possible is because it confuses a
fault condition with an adiministrative operation. We do not want to have
the network react to some unstable CPE or L2 network condition.

I suggest that regardless of the PW status method used, a label is
withdrawan only if the user configures the AC administrative state to DOWN.
Any other fault condition should raise an alarm to the management system but
should not cause a label withdrawal.

Mustapha.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Luca
Martini
Sent: Friday, February 18, 2005 10:45 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [PWE3] Control protocol draft - section 5.3.1 change to PW
status.

[email-masked] wrote:

>Question:  Is there is any inference in this text (or other text in 
>this draft, or in any other draft for that matter) that a PW must be 
>taken down in response to a failure on an AC?  If there is then its wrong.
>  
>
In the new PW status design, described here , the  PW is not "taken down ",
but instead attachment circuit status is communicated to the remote end of
the PW.
So the answer is no. Example ATM AIS alarm. The AIS OAM cells will be passed
along the PW , additionally a PW status TLV "interface Receive Fault" will
also be transmitted in the control protocol.

Luca

>in some client layer link connection.  Just think if we did this for 
>all nested layer networks right down to optics!
>
>regards, Neil
>
>  
>
>>From: [email-masked] [mailto:[email-masked]] On Behalf 
>>Of Luca Martini
>>Subject: [PWE3] Control protocol draft - section 5.3.1 change to PW 
>>status.
>>
>>
>>attachment circuit state. The PW label should not be withdrawn unless 
>>the user administratively configures the CE-facing interface down (or 
>>the PW configuration is deleted entirely). Using the procedures 
>>outlined in this section a simple label withdraw method MUST also be 
>>supported as a primitive means of signaling PW status. In any case if 
>>the Label mapping is not available the PW MUST be considered in the 
>>down state.
>>
>>Once, the PW status negotiation procedures are completed and if they 
>>result in the use of the label withdraw method for PW status 
>>communication, the label withdraw PW status method MUST be used. This 
>>will result in the PW label mapping message being advertised only if 
>>the attachment circuit becomes active. The PW status signaling 
>>procedures described in this section MUST be fully implemented.
>>
>>

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Tue, 22 Feb 2005 10:11:49 -0500

The last parapgraph in my email should read:
"I suggest that regardless of the PW status method used, a label is
withdrawan only if the user configures the AC administrative state to DOWN.
Any other fault condition should raise an alarm to the management system in
the case of the label withdrawal PW status method and additionally the
generation of a PW status TLV message in the case of the PW status signaling
method."

Mustapha. 

-----Original Message-----
From: Mustapha Aissaoui [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2005 10:05 AM
To: 'Luca Martini'; [email-masked]'
Cc: [email-masked]'
Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW
status.

Luca,

Mustapha.  

-----Original Message-----

Luca

---

From: Luca Martini <[email-masked]>
Date: Tue, 22 Feb 2005 09:16:03 -0700

>network or LMI indicated a fault. Am I wrong?
yes. This is correct, then the remote end would re-generate the AIS alarm.

>immediately withdraw the label because the AC is not active? 
That would be my understanding. Some state needs to be kept for this PW, 
for the life of the LDP session, to indicate that the PW uses label 
withdraw method.

>the network react to some unstable CPE or L2 network condition.
For this reason we have PW status TLV infrastructure. Remember that this 
is a MUST implement, therefore this is what is going to be used by ALL 
PWE3 implementations.

>should not cause a label withdrawal.
This would break any status notification.
The intent is not to break current deployments. After all they must be 
working fine with just the label withdraw method.
Whether this text is there or not , the implementations will implement 
label withdraw anyway. We all agree that if there is no label 
advertisement the PW is down.
That is the main point.
Why are you so keen in disabling the backward compatibility ?
I would like this standard to be implemented, not the old draft-martini.

Luca

---

From: [email-masked]
Date: Tue, 22 Feb 2005 16:38:39 -0000

Mustapha, 

This is precisely why I raised this point.....but please do not overlook
the more fundamantal point that 'defect events' in any client layer
should never result in 'events' in any server layer.  One should not
violate principles like these just because its expedient.  If everyone
had taken this attitude we could, in theory, cause 'events' at the
optics layer (maybe in someone else's network even) for 'defect events'
in some client perhaps several layers removed (upwards).  Clearly this
is a nonsense.

regards, Neil

> Sent: 22 February 2005 15:05
> To: 'Luca Martini'; Harrison,N,Neil,IKM1 R
> Cc: [email-masked]
> 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?
> 
> Also, how should we interpret the new text? Initially, you 
> advertize the label regardless of the state of AC. Then, if 
> the PW status negotiation results in the use of the label 
> withdraw PW status method, would you immediately withdraw the 
> label because the AC is not active? 
> 
> I would like to see a simplification to the procedures. The 
> reason why label withdrawal is to be avoided as much as 
> possible is because it confuses a fault condition with an 
> adiministrative operation. We do not want to have the network 
> react to some unstable CPE or L2 network condition.
> 
> I suggest that regardless of the PW status method used, a 
> label is withdrawan only if the user configures the AC 
> administrative state to DOWN. Any other fault condition 
> should raise an alarm to the management system but should not 
> cause a label withdrawal.
> 
> Mustapha.  
> 
> In the new PW status design, described here , the  PW is not 
> "taken down ", but instead attachment circuit status is 
> communicated to the remote end of the PW. So the answer is 
> no. Example ATM AIS alarm. The AIS OAM cells will be passed 
> along the PW , additionally a PW status TLV "interface 
> Receive Fault" will also be transmitted in the control protocol.
> 
> Luca
> 
> >>   The PEs MUST send PW label mapping messages to their 
> peers as soon
> >>as
> >>   MAY also be supported as a primitive means of signaling 
> PW status. 
> >>It

---

From: [email-masked]
Date: Tue, 22 Feb 2005 16:51:56 -0000

Luca wrote 22 February 2005 16:16
> 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,
NH=> The strict interpretation of your response is that Mustapha's
observation is *wrong*.....but I do not believe you meant that, just the
opposite in fact.  The required behaviour is quite simple: Defects in a
client layer network should never cause consequent actions in a server
layer network.

> then the remote end would re-generate 
> the AIS alarm.
NH=> As I have previously pointed out, there is no such animal as an
'AIS alarm'.  The purpose of AIS is to stop alarms, not generate them.
Note - It was because of confusion like this that I changed the name of
this function to FDI (ie Forward Defect Indication).

regards, Neil
> 
> >Also, how should we interpret the new text? Initially, you advertize 
> >the label regardless of the state of AC. Then, if the PW status 
> >negotiation results in the use of the label withdraw PW 
> status method, 
> >would you immediately withdraw the label because the AC is 
> not active?
> >
> >  
> >
> reason why 
> >label withdrawal is to be avoided as much as possible is because it 
> >confuses a fault condition with an adiministrative 
> operation. We do not 
> >want to have the network react to some unstable CPE or L2 network 
> >condition.
> >
> >  
> >
> >withdrawan only if the user configures the AC administrative 
> state to 
> >DOWN. Any other fault condition should raise an alarm to the 
> management 
> >system but should not cause a label withdrawal.
> >
> >  
> >
> >From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of 
> >Luca Martini
> >In the new PW status design, described here , the  PW is not "taken 
> >down ", but instead attachment circuit status is communicated to the 
> >remote end of the PW. So the answer is no. Example ATM AIS 
> alarm. The 
> >AIS OAM cells will be passed along the PW , additionally a PW status 
> >TLV "interface Receive Fault" will also be transmitted in 
> the control 
> >protocol.
> >
> >Luca
> >
> >  
> >

---

From: Luca Martini <[email-masked]>
Date: Tue, 22 Feb 2005 12:35:00 -0700

>in some client perhaps several layers removed (upwards).  Clearly this
Neil, I agree, however the PW is not a client of the PW control 
protocol. I see the PW an adaptation of the atm/frame/ethernet etc. to MPLS.
So we are not causing an alarm in the RSVP LSP , or in the IGP protocol.....

Luca

>>>taken down in response to a failure on an AC?  If there is 
>>>      
>>>
>>then its wrong.
>>    
>>
>>> 
>>>
>>>      
>>>
>>>One should NEVER take down a server layer trail in response 
>>>      
>>>
>>to a defect
>>    
>>
>>>>The PEs MUST send PW label mapping messages to their peers 
>>>>        
>>>>
>>as soon as
>>    
>>
>>>>the PW is configured and administratively enabled, 
>>>>        
>>>>
>>regardless of the 
>>    
>>
>>>>attachment circuit state. The PW label should not be 
>>>>        
>>>>
>>withdrawn unless 
>>    
>>
>>>>the user administratively configures the CE-facing 
>>>>        
>>>>
>>interface down (or 
>>    
>>
>>>>outlined in this section a simple label withdraw method 
>>>>        
>>>>
>>MUST also be 
>>    
>>
>>>>supported as a primitive means of signaling PW status. In 
>>>>        
>>>>
>>any case if 
>>    
>>
>>>>communication, the label withdraw PW status method MUST be 
>>>>        
>>>>
>>used. This 
>>    
>>
>>>>will result in the PW label mapping message being 
>>>>        
>>>>
>>advertised only if 
>>    
>>

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Wed, 23 Feb 2005 10:04:06 -0500

Luca,
See below.

Mustapha.

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Tuesday, February 22, 2005 11:16 AM
To: Mustapha Aissaoui
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Control protocol draft - section 5.3.1 change to PW
status.

>>Any other fault condition should raise an alarm to the management
>>ystem but should not cause a label withdrawal.

>The intent is not to break current deployments. After all they must be
working fine with >just the label withdraw method.
>Whether this text is there or not , the implementations will implement
label withdraw > anyway. We all agree that if there is no label
advertisement the PW is down.

>Luca

I corrected my sentence above in a follow-up email. This should read as
follows:

If we stick to the above in the case of the label withdraw method, then a PE
will be able to forward a received or locally generated AIS/RDI to the
remote AC. This is the desired behaviour. Obviously, FR PWs will not have a
mean to notify the remote AC of a fault indicated by LMI except through the
management system. But this is OK since the label withdraw method was meant
to be a basic method.

---

From: Benny Ammitzbøll <[email-masked]>
Date: Wed, 23 Feb 2005 10:29:04 +0100

Sorry if I jump in in the middle of this, but I believe that Neils point is
that the PW is the server and what the PW carries inside is the client. This
also IMO means that the AC is client and the state of the AC should not
affect the server layer, i.e. the PW.

I think it would help to stress more clearly in section 5.3.1 that the
coupling between AC state and PW state is NOT the desired behaviour, but it
is only there because of backwards compatability with non-standard
equipment.

My proposal for a new text:

   The PEs MUST send PW label mapping messages to their peers as soon as
   the PW is configured and administratively enabled, regardless of the
   attachment circuit state. The PW label should not be withdrawn unless
   the user administratively configures the PW down (or the PW configuration
   is deleted entirely). If the Label mapping is not available the PW MUST
   be considered in the down state.

   For backwards compatability a simple label withdraw method MUST also be
   supported as a legacy means of signaling PW status. When the PW status
   negotiation procedures are completed and if they result in not using the
   PW Status TVL, the label withdraw PW status method MUST be used. This
   will result in the PW label mapping message being advertised only if
   the attachment circuit becomes active. The PW status signaling
   procedures described in this section MUST be fully implemented.

/Benny

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Luca Martini
Sent: 22. februar 2005 20:35
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [PWE3] Control protocol draft - section 5.3.1 change to PW
status.

Luca

---

From: [email-masked]
Date: Wed, 23 Feb 2005 11:45:56 -0000

Luca/Mustapha,

Luca wrote 22 February 2005 19:35
> >This is precisely why I raised this point.....but please do not 
> >overlook the more fundamantal point that 'defect events' in
> any client
> >layer should never result in 'events' in any server layer.
> One should
> >not violate principles like these just because its expedient.  If 
> >everyone had taken this attitude we could, in theory, cause
> 'events' at
> >the optics layer (maybe in someone else's network even) for 'defect 
> >events' in some client perhaps several layers removed (upwards). 
> >Clearly this is a nonsense.
> >
> >regards, Neil
> >
> >  
> >
NH=> I also agree with this observation.....if only from the rather
obvious observation that the setting up of a *traffic* data-plane MPLS
co-ps trail can be via NMS or signalling protocol X, Y or Z.....or that
an IP cl-ps flow can be set-up via L2TPv3.  But there are different
issues here however Luca.  Let's decouple the traffic data-plane traffic
from its control-plane facets for the moment (I'll ignore here whether
these should be OOB wrt each other).

Data-plane:  If I have XoverMPLS say, then X is a layer network
(technology X) and MPLS is (or should be) a layer network....and these
should be functionally decoupled.  There are similar (albeit different)
considerations for XoverIP...just as indeed there are for XoverSDH_VC4
say.

The 'thing' that maps a *link-connection* in (the client) layer network
X to a *trail* in the (server) layer network of MPLS (or IP or SDH_VC4,
etc) is the adaptation function.  PWs are, or at least 'were' when only
SH, an adaptation function.  I pass no value judgement on how good the
adaptation function is, I simply note here that that is what a SH-PW is.
However, this is no longer the case with MH-PWs.  So not only are X and
MPLS layer networks in their own right, but now PWs are becoming a layer
network in their own right too.....with the nasty corollary of MPLS (eg
LDP or RSVP-TE) and IP (ie L2TPv3) peer-partition control-plane
interworking looming.  Note also that the PW layer is ill-defined IMO.

So how do we get out of this mess?  Well, we could start with the
observation that XoverMPLS != XoverIP.....this is simply a fact.  *IF*
one could do this then there is no reason why *any* MPLS LSP is not an
'XoverMPLS' LSP, ie an LSP becomes truly multi-protocol in what it
supports.....so why should an LSP supporting ethernet say be treated any
differently to an LSP supporting IP as a client?

Until/unless folks are prepared to accept this then IMO we are stuck in
the never ending wrongness of 'XoverPSN'.  PWs are an artificial
construction that are hiding the truth as to what is going on here in
terms of the real layer network relationships involved.

> I see the PW an adaptation of the
> atm/frame/ethernet etc. to MPLS.
NH=> Yes....and therein lies one of the problems, ie why is IP treated
differently when it is a client of an MPLS LSP?  If you ponder over
GMPLS and the co-cs mode (as a server layer, and any co-cs mode
technology) for a moment you will observe that this distinction is a
FORCED requirement, ie one cannot have a SDH_VC4 (say) traffic stream
co-existing with an IP traffic stream in the same data-plane.  MPLS is
not like this however.  So the problems here are actually rather
fundamental....and I'm not sure we can do much about this now.

> So we are not causing an
> alarm in the RSVP LSP , or in the IGP protocol.....
NH=> Nor should they be.  We are talking traffic data-planes here (or at
least I am). In any case you should *never* be raising 'alarms' in the
control-plane (be this signalling, eg RSVP-TE or LDP or whatever....or
the routing protocol) for traffic data-plane defects....at least for the
co-ps and co-cs modes.  But then are you able to see this if it is not
already clear to you that the cl-ps mode is not the same as the co-ps or
co-cs modes?  Trying to treat these 3 modes identically is where things
went awry in the 1st place.

I am not sure we can fix these things any more....its all too far gone
IMO.  The fundamantal problem is that IP and MPLS were *assumed* to be
largely one and the same thing at t=0....and this can be made to work in
a limited scope scenario.  With GMPLS however, this coupling can't be
done....the co-cs mode forbids it.  However, once you get into the
full-service needs of a large operator (and let's not kid ourselves any
of this stuff is appropriate for the Internet) you need to be a lot more
precise with how layer networks are specified/used IMO.

regards, Neil
> [mailto:[email-masked]] On Behalf 
> >>>>Of Luca Martini
> >>>>status messages/TLV mandatory. Also all "CE-facing port" 
> terminology 
> >>>>will be changed to
> >>>>        
> >>>>
> >>"attachment
> >>    
> >>
> >>>>circuit".
> >>>>

---

From: [email-masked]
Date: Thu, 24 Feb 2005 16:05:14 -0000

Mustapha,

Mustapha Aissaoui wrote 24 February 2005 15:01
> 
> Rishi,
> I am not sure you have read my response to your message last 
> week. I was telling you the case of N:1 VC-to-PW is 
> hypthetical. The current ATM draft only deals with a single 
> VC per PW when using the N:1 cell mode encapsulation 
> encapsulation. In other words, the ATM VC and the ATM PW are 
> peers.
NH=> This is incorrect.  There are 2 MPLS LSPs.  The top level LSP is
not there for any primary considerations of 'hierarchy' it is a FORCED
p2p construct to make sure there is demerging from any lower mp2p
constructs.  Note also that in a proper client/server case there is only
a requirement for a single server layer construct, no matter how many
clients are muxed into it, eg 63 VC_12 clients into a single server VC_4
in SDH say.

However, it is still a server layer construct wrt to the (in this case)
ATM client.  There are NOT in any way peers.
Note - if they were to be considered as peers, you would also have to
have (for example) signaling protocol conversion between the partitions.
In general however, peer-partition i/w is not a good idea...one has some
chance for technologies belonging to the same network mode, but almost
no chance for technologies belonging to differenmt modes (because of the
function/feature mismatch).

> The server layer is the PSN tunnel.
NH=> Not strictly correct.  The 'PSN tunnel' is a server construct to
the higher LSP entity.  However, the 2 LSPs are NOT seperate layer
networks.....not sure if you get this, ring me if not clear....though
you could check out MPLS func arch in G.8110.

Final point.  A SH-PW was not a layer network.  It was an adaptation
function between X and MPLS (or IP).  MH-PWs are now changing this, ie a
new layer network is now being created in all but name.

regards, Neil
> 
> Now, if one wants to implement a true N:1 VC-to-PW, then the 
> PW becomes a server layer to the ATM VCs. The PW is 
> pre-established and is used as a tunnel. In that case, you 
> will not withdraw the PW label in response to administrative 
> or operational state of the individual ATM VCs.
> 
> Mustapha.
> 
> Sent: Thursday, February 24, 2005 4:04 AM
> To: 'Mustapha Aissaoui'; 'Shahram Davari'; 'Luca Martini'
> The problem of when multiple AC are going through a singe N:1 
> PWE3 remains unsolved. if we withdraw the label when one AC 
> is admin down, what about other AC.
> 
> Rishi
> 
> 
> > Mustapha Aissaoui
> > Sent: Wednesday, February 23, 2005 8:39 PM
> > To: 'Shahram Davari'; 'Luca Martini'
> change to 
> > PW st 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.
> >
> > From: Shahram Davari [mailto:[email-masked]]
> > Sent: Wednesday, February 23, 2005 9:45 AM
> > To: 'Luca Martini'; Mustapha Aissaoui
> change to 
> > PW st atus.
> > > method is used,
> > > 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
> >
> >
> >

---

From: "Mustapha Aissaoui" <[email-masked]>
Date: Thu, 24 Feb 2005 12:42:11 -0500

Neil,
I agree that the SH-PW has been designed as an adaptation function into a
PSN. However, in theory this does not mean it cannot be considered a layer
of its own. In ATM, AAL is both an adaptation function and a layer of its
own. Though there was a lot of resistance to making it a full blown layer
entity with OAM, etc., because it is redundant.

Coming back to the issue in this email, if one uses N:1 cell mode
encapsulation with a single ATM connection per PW, yes the ATM PW is
strictly speaking not a peer to the ATM VC/VP. I was explaining that in that
case, one may release the label if the AC administrative status changed to
DOWN because of the 1-to-1 relationship. If one carries multiple VCs in a
PW, then changing the Admin status of a single VC, or even all configured
VCs, should not automatically cause a label withdrawal. This is because, the
PW is still able to carry a newly configured VC.

Mustapha.
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, February 24, 2005 11:05 AM
To: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW
status.

Mustapha,

>
> Rishi,
> I am not sure you have read my response to your message last week. I
> was telling you the case of N:1 VC-to-PW is hypthetical. The current
> ATM draft only deals with a single VC per PW when using the N:1 cell
> mode encapsulation encapsulation. In other words, the ATM VC and the
> ATM PW are peers.
NH=> This is incorrect.  There are 2 MPLS LSPs.  The top level LSP is not
there for any primary considerations of 'hierarchy' it is a FORCED p2p
construct to make sure there is demerging from any lower mp2p constructs.
Note also that in a proper client/server case there is only a requirement
for a single server layer construct, no matter how many clients are muxed
into it, eg 63 VC_12 clients into a single server VC_4 in SDH say.

However, it is still a server layer construct wrt to the (in this case) ATM
client.  There are NOT in any way peers.
Note - if they were to be considered as peers, you would also have to have
(for example) signaling protocol conversion between the partitions.
In general however, peer-partition i/w is not a good idea...one has some
chance for technologies belonging to the same network mode, but almost no
chance for technologies belonging to differenmt modes (because of the
function/feature mismatch).

> The server layer is the PSN tunnel.
NH=> Not strictly correct.  The 'PSN tunnel' is a server construct to the
higher LSP entity.  However, the 2 LSPs are NOT seperate layer
networks.....not sure if you get this, ring me if not clear....though you
could check out MPLS func arch in G.8110.

Final point.  A SH-PW was not a layer network.  It was an adaptation
function between X and MPLS (or IP).  MH-PWs are now changing this, ie a new
layer network is now being created in all but name.

regards, Neil
>
> Now, if one wants to implement a true N:1 VC-to-PW, then the PW
> becomes a server layer to the ATM VCs. The PW is pre-established and
> is used as a tunnel. In that case, you will not withdraw the PW label
> in response to administrative or operational state of the individual
> ATM VCs.
>
> Mustapha.
>
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to
> PW status.
>
> Mustapha,
>
> PWE3 remains unsolved. if we withdraw the label when one AC is admin
> down, what about other AC.
>
> Rishi
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 25 Feb 2005 07:58:21 -0500

OK, I give in to Benny and Dave.  Let's incorporate Benny's clarification 
and make the "SHOULD" a "MAY".

Thanks,
Andy

-----------

At 2/25/2005 07:24 AM -0500, David Allan wrote:

> > I think we have to spell out very clearly that the label
> > withdraw is not the way to signal AC state to the remote PE.
> > For this reason I also think the SHOULD should just be a MAY.
>
>I agree with this. There are clearly consequences to a label withdraw that
>must be supported, but it should not be used to communicate AC state (and
>IMO administative state).
>
>Dave

---

From: Luca Martini <[email-masked]>
Date: Fri, 25 Feb 2005 14:04:34 -0700

Benny Ammitzbøll wrote:

>The sentence "The PW label should not be withdrawn unless the user
>administratively configures the attachment circuit down" stands on its own
>early on. It is confusing me - am I right in assuming that a PE that
>supports the Status message (and has negotiated to use the Status message)
>should *only* send a label withdraw if the PW itself is deleted or set to
>admin down? This sentence makes it sound like it is ok to send a label
>withdraw when the user sets the AC admin state down - even if the Status
>message is in use!
>  
>
yes I agree , I 'll change the text to be more clear.

Luca

>I think we have to spell out very clearly that the label withdraw is not the
>way to signal AC state to the remote PE. For this reason I also think the
>SHOULD should just be a MAY.
>
>/Benny
>
>Sent: 25. februar 2005 03:10
>To: Busschbach, Peter B (Peter)
>Cc: Thomas D. Nadeau; Shahram Davari; [email-masked]; 'Benny Ammitzboll';
>[email-masked]; [email-masked]
>Ok,
>here is the section in question :
>---------------------------------------------
>.Pc "Use of Label Mappings."
>section a simple label withdraw method SHOULD also be supported as a legacy
>in the use of the label withdraw method for PW status communication, and
>this method is not supported by the PE, then the PW MUST be disabled and a
>label release message MUST be sent to he remote PE with the following error:
>
>"Label Withdraw PW Status Method Not Supported"
>
>If the label withdraw method for PW status communication is selected for the
>PW, it  will result in the PW label mapping message being advertised only if
>the attachment circuit becomes active.
>The PW status signaling procedures described in this section MUST be fully
>implemented.
>----------------------------------------------------------
>
>Is this ok ?
>
>I am in favor of the SHOULD myself , but it might not make the AD/IESG
>review. They will probably ask in what situation is this part not going
>to be implemented ?
>
>Luca
>
>
>
>Busschbach, Peter B (Peter) wrote:
>
>  
>
>>I agree with Andy's proposal.
>>
>>Peter
>>
>>
>>
>>    
>>
>>>From: Andrew G. Malis [mailto:[email-masked]]
>>>Sent: Thursday, February 24, 2005 3:50 PM
>>>To: Thomas D. Nadeau
>>>Cc: Luca Martini; Shahram Davari; [email-masked]; 'Benny Ammitzboll';
>>>Busschbach, Peter B (Peter); [email-masked];
>>>[email-masked]
>>>The SHOULD in Tom's text below needs to be a MUST, since if
>>>the negotiation
>>>results in using the Withdraw method, then you MUST follow
>>>Tom's algorithm.
>>>
>>>I would also prefer that implementations SHOULD implement
>>>Withdraw for
>>>backwards compatibility, rather than MAY, to encourage backwards
>>>compatibility without actually requiring it.  When the
>>>Proposed Standard
>>>goes for Draft Standard, we can think about lessening the
>>>SHOULD to a MAY
>>>(or even removing it), since hopefully at that point the
>>>installed base
>>>would have migrated to the RFC.
>>>
>>>Cheers,
>>>Andy
>>>
>>>------------
>>>
>>>At 2/24/2005 02:51 PM -0500, Thomas D. Nadeau wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>       Cool with me.  So I think it should be worded
>>>>like:
>>>>
>>>>If the PW status negotiation results in Label Withdraw method then
>>>>you SHOULD use either 1) label withdraw method, or 2) if
>>>>label withdraw is not implemented, we disable the PW with a label
>>>>release error message.
>>>>
>>>>       --tom
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>>>Excellent , it sound like we are converging.
>>>>>However we need to agree on the logic of this PW status procedure.
>>>>>If the PW status negotiation results in Label Withdraw method then :
>>>>>
>>>>>1) we use label withdraw method ( MAY option )
>>>>>2) if label withdraw is not implemented , we disable the PW
>>>>>
>>>>>
>>>>>          
>>>>>
>>>with a label
>>>
>>>
>>>      
>>>
>>>>>release error message.
>>>>>3) we do nothing. however in this case PW messaging would be broken.
>>>>>
>>>>>I think that we need #1 and #2 in the text with the
>>>>>
>>>>>
>>>>>          
>>>>>
>>>corresponding error
>>>
>>>
>>>      
>>>
>>>>>for #2
>>>>>
>>>>>Do you agree ?
>>>>>
>>>>>Luca
>>>>>
>>>>>
>>>>>          
>>>>>