RE: Control protocol draft - section 5.3.1 change to PW st atus.

"Mustapha Aissaoui" <mustapha.aissaoui@alcatel.com> Fri, 18 February 2005 15:32 UTC

From: Mustapha Aissaoui <mustapha.aissaoui@alcatel.com>
Subject: RE: Control protocol draft - section 5.3.1 change to PW st atus.
Date: Fri, 18 Feb 2005 10:32:11 -0500
Lines: 150
References: <6733C768256DEC42A72BAFEFA9CF06D20B4918D7@ii0015exch002u.iprc.lucent.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-From: pwe3-bounces@ietf.org Fri Feb 18 17:47:19 2005
To: "'Kulkarni, Hrishikesh (Hrishikesh)'" <hkulkarni@lucent.com>, neil.2.harrison@bt.com, lmartini@cisco.com, pwe3@ietf.org
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
Thread-index: AcUVn8dxZ61aOqomShq0wMxezfAcywALc2Vg
In-reply-to: <6733C768256DEC42A72BAFEFA9CF06D20B4918D7@ii0015exch002u.iprc.lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Content-Transfer-Encoding: 7bit
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org
X-MailScanner-From: pwe3-bounces@ietf.org
X-MailScanner-To: ietf-pwe3@gmane.org
X-Message-ID:
Message-ID: <20140418091814.2560.62064.ARCHIVE@ietfa.amsl.com>

Rishi.
this is a hypothetical question. Although, the pwe3 ATM encap draft allows
for multiple VCs to be carried in a single PW, only a single VC is
prescribed. There are no procedures anywhere that describe the operation of
the dataplane, control plane, and OAM for this case.

Your question may be intended for the case of carrying a ATM virtual trunk
(VT) over MPLS. A virutal trunk is defined a range of VPIs on the same port.
This is being specified in the MFA. A special case of the VT is the PORT
mode, described in draft-ietf-pwe3-cell-transport-01.txt. However, in both
cases, the PE does not have context of the individual VCC and VPCs inside
the VT and therefore do not really qualify as N-to-1 connections to PW.

Mustapha. 

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of
Kulkarni, Hrishikesh (Hrishikesh)
Sent: Friday, February 18, 2005 4:37 AM
To: 'neil.2.harrison@bt.com'; lmartini@cisco.com; pwe3@ietf.org
Subject: RE: [PWE3] Control protocol draft - section 5.3.1 change to PW st
atus.

I agree with the workings/recommendations of OSI model and the server-client
architecture used in networks

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



> -----Original Message-----
> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org]On Behalf Of
> neil.2.harrison@bt.com
> Sent: Friday, February 18, 2005 1:48 PM
> To: lmartini@cisco.com; pwe3@ietf.org
> Subject: RE: [PWE3] Control protocol draft - section 5.3.1 
> change to PW
> status.
> 
> 
> 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: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] 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.
> > 
> > 
> > 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
> > 
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 

_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3