From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Jim Harford <harford@milieunetworks.com>
Subject: ATM Forum liaison
Date: Sun, 04 Jan 2004 17:41:25 -0500
Lines: 63
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_289895687==_.ALT"
X-From: pwe3-admin@ietf.org Mon Jan 05 11:34:06 2004
Return-path: <pwe3-admin@ietf.org>
X-Sender: harford@milieunetworks.com/pop.bizmail.yahoo.com@localhost (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.0
To: pwe3@ietf.org
X-Virus-Scanned: by viruswatch at intrex.net
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

--=====================_289895687==_.ALT
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable


For your info, the following liaison is being sent from the ATM Forum to=20
the PWE3 group:

Gentlemen:
The ATM Forum met during the third week of October.  We are pleased to=20
announce that the following three documents have been approved:
    =B7    af-aic-0178.001 - version 2 of our ATM-MPLS Network Interworking=
=20
specification,
    =B7    af-aic-0196.000 - a new specification addressing N-to-one cell=20
mode, as defined in ITU-T Recommendation Y.1411, and
    =B7    af-cs-0197.000 - a new specification extending PNNI to establish=
=20
MPLS interworking labels.

Copies of these specifications are available at our web site,=
 www.atmforum.com.


Jim Harford

--=====================_289895687==_.ALT
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<br>
For your info, the following liaison is being sent from the ATM Forum to
the PWE3 group:<br>
<br>
Gentlemen:<br>
<font face=3D"Arial, Helvetica">The ATM Forum met during the third week of
October.&nbsp; We are pleased to announce that the following three
documents have been approved:<br>
</font><font face=3D"Symbol" size=3D4>&nbsp;&nbsp;
=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face=3D"Arial, Helvet=
ica"><b>af-aic-0178.001</b>
- version 2 of our ATM-MPLS Network Interworking specification,<br>
</font><font face=3D"Symbol" size=3D4>&nbsp;&nbsp;
=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face=3D"Arial, Helvet=
ica"><b>af-aic-0196.000</b>
- a new specification addressing N-to-one cell mode, as defined in ITU-T
Recommendation Y.1411, and<br>
</font><font face=3D"Symbol" size=3D4>&nbsp;&nbsp;
=B7<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;</x-tab></font><font face=3D"Arial, Helvet=
ica"><b>af-cs-0197.000</b>
- a new specification extending PNNI to establish MPLS interworking
labels.<br>
<br>
Copies of these specifications are available at our web site,
<a href=3D"http://www.atmforum.com/"=
 eudora=3D"autourl">www.atmforum.com</a>.<br>
<br>
<br>
Jim Harford<br>
</font></html>

--=====================_289895687==_.ALT--


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Mon, 5 Jan 2004 10:07:16 -0500
Lines: 40
Sender: pwe3-admin@ietf.org
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 05 16:18:06 2004
Return-path: <pwe3-admin@ietf.org>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'Peter Willis'" <pjw@ip-engineering.bt.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Hi Peter:

<snipped>
> Yes, I believe VCCV protects against swapped or mismerged 
> LSPs. There are two cases:
> 
> Wrong PW Label:
> When LSP Ping is used over the PW, the original PW-id FEC is 
> included in the message. The receiving PE will check whether 
> the FEC in the Ping message matches the original PW-id FEC. 
> It will reply accordingly. 

The caveat being that the ping implementation when transported by VCCV cares
about the incoming label (more akin to the TTL exhaust path through the
code) unlike PING implementation for LDP where simply being a viable egress
LSR for the FEC is sufficient (PHP case).
 
> Wrong PSN Label:
> To detect failures in the underlying transport LSPs, one 
> could run LSP Ping over the PSN LSPs. However, as far as the 
> PWs are concerned, VCCV would also protect against swapped or 
> mismerged PSN LSPs.  

It can detect them, but given the current state of technology, there is no
way to actually traceroute the path a PW will take over a PSN. Best you can
do now is when a PW fault is detected, traceroute all ECMP permutations in
the PSN and if a fault is found, assume they correspond (ECMP extensions to
LSP-Query were designed to close that gap a bit better...). If 'P' routers
recognized TTL exhaust of VCCV probes you could traceroute, but I don't
think you can depend on that.

If you are already doing PSN misbranching proactively via LSR self test or
FEC-CV, then presumably you have independently caught any PSN problems, and
the problem is unique to the PW layer or the PW-PSN binding (either way the
problem is local to the PE).

happy new year
Dave

<snipped to end>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: PWE3 @ 59th IETF - Seoul, Korea
Date: Mon, 05 Jan 2004 15:31:17 +0000
Organization: Cisco Systems, Inc.
Lines: 14
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Danny McPherson <danny@arbor.net>
X-From: pwe3-admin@ietf.org Mon Jan 05 16:36:06 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


I will be putting together the agenda for PWE3 @ 59th IETF
- Seoul, Korea.

Please send slot requests to me, together with a sentence
on what you will be presenting and the URL of the draft.

We (the chairs) need the slides by Wednesday 25th Feb so
that we can put them on the web site. We reserve the right
to a slot if the speaker fails to provide slides in advance.

Regards

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Mon, 5 Jan 2004 11:15:35 -0500
Lines: 77
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 05 17:28:07 2004
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "'Peter Willis'"
	 <pjw@ip-engineering.bt.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O



> -----Original Message-----
> From: David Allan [mailto:dallan@nortelnetworks.com]
> Sent: Monday, January 05, 2004 10:07 AM
> To: 'Busschbach, Peter B (Peter)'; 'Peter Willis'
> Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de;
> stbryant@cisco.com; pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention
> in PWE3] 
> 
> 
> Hi Peter:
> 
> <snipped>
> > Yes, I believe VCCV protects against swapped or mismerged 
> > LSPs. There are two cases:
> > 
> > Wrong PW Label:
> > When LSP Ping is used over the PW, the original PW-id FEC is 
> > included in the message. The receiving PE will check whether 
> > the FEC in the Ping message matches the original PW-id FEC. 
> > It will reply accordingly. 
> 
> The caveat being that the ping implementation when 
> transported by VCCV cares
> about the incoming label (more akin to the TTL exhaust path 
> through the
> code) unlike PING implementation for LDP where simply being a 
> viable egress
> LSR for the FEC is sufficient (PHP case).
>  
> > Wrong PSN Label:
> > To detect failures in the underlying transport LSPs, one 
> > could run LSP Ping over the PSN LSPs. However, as far as the 
> > PWs are concerned, VCCV would also protect against swapped or 
> > mismerged PSN LSPs.  
> 
> It can detect them, but given the current state of 
> technology, there is no
> way to actually traceroute the path a PW will take over a 
> PSN.

Hi Dave,

My point was that the tools specified in VCCV do enable detection of swapped or mismerged PSN LSPs. I agree that the tools do not enable the operator to locate the exact location of the failure. However, would that be different with Y.1711? It seems to me that any case of LSP swapping or mimerging requires network-wide fault coordination and possibly additional diagnostics to locate the failure.

Happy new year,

Peter


>Best you can
> do now is when a PW fault is detected, traceroute all ECMP 
> permutations in
> the PSN and if a fault is found, assume they correspond (ECMP 
> extensions to
> LSP-Query were designed to close that gap a bit better...). 
> If 'P' routers
> recognized TTL exhaust of VCCV probes you could traceroute, 
> but I don't
> think you can depend on that.
> 
> If you are already doing PSN misbranching proactively via LSR 
> self test or
> FEC-CV, then presumably you have independently caught any PSN 
> problems, and
> the problem is unique to the PW layer or the PW-PSN binding 
> (either way the
> problem is local to the PE).
> 
> happy new year
> Dave
> 
> <snipped to end>
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Mon, 5 Jan 2004 11:34:30 -0500
Lines: 105
Sender: pwe3-admin@ietf.org
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 05 17:38:05 2004
Return-path: <pwe3-admin@ietf.org>
To: "'Busschbach, Peter B (Peter)'" <busschbach@lucent.com>,
        "'Peter Willis'" <pjw@ip-engineering.bt.com>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

I didn't raise the point to be obnoxious, I raised it to identify IMO a gap
that exists in the current state of the art.

cheers
Dave

> -----Original Message-----
> From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com] 
> Sent: Monday, January 05, 2004 11:16 AM
> To: Allan, David [CAR:NS00:EXCH]; 'Peter Willis'
> Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; 
> stbryant@cisco.com; pwe3@ietf.org
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention in PWE3] 
> 
> 
> 
> 
> > -----Original Message-----
> > From: David Allan [mailto:dallan@nortelnetworks.com]
> > Sent: Monday, January 05, 2004 10:07 AM
> > To: 'Busschbach, Peter B (Peter)'; 'Peter Willis'
> > Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; 
> > stbryant@cisco.com; pwe3@ietf.org
> > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS
> > retention
> > in PWE3] 
> > 
> > 
> > Hi Peter:
> > 
> > <snipped>
> > > Yes, I believe VCCV protects against swapped or mismerged
> > > LSPs. There are two cases:
> > > 
> > > Wrong PW Label:
> > > When LSP Ping is used over the PW, the original PW-id FEC is
> > > included in the message. The receiving PE will check whether 
> > > the FEC in the Ping message matches the original PW-id FEC. 
> > > It will reply accordingly. 
> > 
> > The caveat being that the ping implementation when
> > transported by VCCV cares
> > about the incoming label (more akin to the TTL exhaust path 
> > through the
> > code) unlike PING implementation for LDP where simply being a 
> > viable egress
> > LSR for the FEC is sufficient (PHP case).
> >  
> > > Wrong PSN Label:
> > > To detect failures in the underlying transport LSPs, one
> > > could run LSP Ping over the PSN LSPs. However, as far as the 
> > > PWs are concerned, VCCV would also protect against swapped or 
> > > mismerged PSN LSPs.  
> > 
> > It can detect them, but given the current state of
> > technology, there is no
> > way to actually traceroute the path a PW will take over a 
> > PSN.
> 
> Hi Dave,
> 
> My point was that the tools specified in VCCV do enable 
> detection of swapped or mismerged PSN LSPs. I agree that the 
> tools do not enable the operator to locate the exact location 
> of the failure. However, would that be different with Y.1711? 
> It seems to me that any case of LSP swapping or mimerging 
> requires network-wide fault coordination and possibly 
> additional diagnostics to locate the failure.
> 
> Happy new year,
> 
> Peter
> 
> 
> >Best you can
> > do now is when a PW fault is detected, traceroute all ECMP
> > permutations in
> > the PSN and if a fault is found, assume they correspond (ECMP 
> > extensions to
> > LSP-Query were designed to close that gap a bit better...). 
> > If 'P' routers
> > recognized TTL exhaust of VCCV probes you could traceroute, 
> > but I don't
> > think you can depend on that.
> > 
> > If you are already doing PSN misbranching proactively via LSR
> > self test or
> > FEC-CV, then presumably you have independently caught any PSN 
> > problems, and
> > the problem is unique to the PW layer or the PW-PSN binding 
> > (either way the
> > problem is local to the PE).
> > 
> > happy new year
> > Dave
> > 
> > <snipped to end>
> > 
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: PW functional model and its OAM [was: FCS retention in
	 PWE3]
Date: Mon, 5 Jan 2004 12:32:48 -0500
Lines: 259
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D3B1.75251042"
Cc: "'neil.2.harrison@bt.com'" <neil.2.harrison@bt.com>,
        Maarten.Vissers@alcatel.de, stbryant@cisco.com, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 05 18:54:10 2004
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>,
        "Busschbach, Peter B (Peter)" <busschbach@lucent.com>,
        "'Peter Willis'"
	 <pjw@ip-engineering.bt.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3D3B1.75251042
Content-Type: text/plain;
	charset="ISO-8859-1"

Dave,
 
I am sorry if i sounded defensive. I didn't intend to be.
 
My question is: is there any OAM tool that automatically isolates the exact location where a switch overwrites label values incorrectly? I don't think Y.1711 does that and it is not obvious to me if it can be done with some light-weight OAM protocol at all.
 
Peter

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Monday, January 05, 2004 11:35 AM
To: 'Busschbach, Peter B (Peter)'; 'Peter Willis'
Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; stbryant@cisco.com; pwe3@ietf.org
Subject: RE: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3] 



I didn't raise the point to be obnoxious, I raised it to identify IMO a gap that exists in the current state of the art.

cheers 
Dave 

> -----Original Message----- 
> From: Busschbach, Peter B (Peter) [ mailto:busschbach@lucent.com <mailto:busschbach@lucent.com> ] 
> Sent: Monday, January 05, 2004 11:16 AM 
> To: Allan, David [CAR:NS00:EXCH]; 'Peter Willis' 
> Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; 
> stbryant@cisco.com; pwe3@ietf.org 
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> retention in PWE3] 
> 
> 
> 
> 
> > -----Original Message----- 
> > From: David Allan [ mailto:dallan@nortelnetworks.com <mailto:dallan@nortelnetworks.com> ] 
> > Sent: Monday, January 05, 2004 10:07 AM 
> > To: 'Busschbach, Peter B (Peter)'; 'Peter Willis' 
> > Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; 
> > stbryant@cisco.com; pwe3@ietf.org 
> > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS 
> > retention 
> > in PWE3] 
> > 
> > 
> > Hi Peter: 
> > 
> > <snipped> 
> > > Yes, I believe VCCV protects against swapped or mismerged 
> > > LSPs. There are two cases: 
> > > 
> > > Wrong PW Label: 
> > > When LSP Ping is used over the PW, the original PW-id FEC is 
> > > included in the message. The receiving PE will check whether 
> > > the FEC in the Ping message matches the original PW-id FEC. 
> > > It will reply accordingly. 
> > 
> > The caveat being that the ping implementation when 
> > transported by VCCV cares 
> > about the incoming label (more akin to the TTL exhaust path 
> > through the 
> > code) unlike PING implementation for LDP where simply being a 
> > viable egress 
> > LSR for the FEC is sufficient (PHP case). 
> >  
> > > Wrong PSN Label: 
> > > To detect failures in the underlying transport LSPs, one 
> > > could run LSP Ping over the PSN LSPs. However, as far as the 
> > > PWs are concerned, VCCV would also protect against swapped or 
> > > mismerged PSN LSPs.  
> > 
> > It can detect them, but given the current state of 
> > technology, there is no 
> > way to actually traceroute the path a PW will take over a 
> > PSN. 
> 
> Hi Dave, 
> 
> My point was that the tools specified in VCCV do enable 
> detection of swapped or mismerged PSN LSPs. I agree that the 
> tools do not enable the operator to locate the exact location 
> of the failure. However, would that be different with Y.1711? 
> It seems to me that any case of LSP swapping or mimerging 
> requires network-wide fault coordination and possibly 
> additional diagnostics to locate the failure. 
> 
> Happy new year, 
> 
> Peter 
> 
> 
> >Best you can 
> > do now is when a PW fault is detected, traceroute all ECMP 
> > permutations in 
> > the PSN and if a fault is found, assume they correspond (ECMP 
> > extensions to 
> > LSP-Query were designed to close that gap a bit better...). 
> > If 'P' routers 
> > recognized TTL exhaust of VCCV probes you could traceroute, 
> > but I don't 
> > think you can depend on that. 
> > 
> > If you are already doing PSN misbranching proactively via LSR 
> > self test or 
> > FEC-CV, then presumably you have independently caught any PSN 
> > problems, and 
> > the problem is unique to the PW layer or the PW-PSN binding 
> > (either way the 
> > problem is local to the PE). 
> > 
> > happy new year 
> > Dave 
> > 
> > <snipped to end> 
> > 
> 
> _______________________________________________ 
> pwe3 mailing list 
> pwe3@ietf.org 
> https://www1.ietf.org/mailman/listinfo/pwe3 <https://www1.ietf.org/mailman/listinfo/pwe3>  
> 


------_=_NextPart_001_01C3D3B1.75251042
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>RE: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3]</TITLE>

<META content="MSHTML 5.50.4933.1800" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=338222917-05012004><FONT face=Arial 
size=2>Dave,</FONT></SPAN></DIV>
<DIV><SPAN class=338222917-05012004><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=338222917-05012004><FONT face=Arial size=2>I am sorry if i 
sounded defensive. I didn't intend to be.</FONT></SPAN></DIV>
<DIV><SPAN class=338222917-05012004><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=338222917-05012004><FONT face=Arial size=2>My question is: is 
there any OAM tool that automatically isolates the exact location where a switch 
overwrites label values incorrectly? I don't think Y.1711 does that and it is 
not obvious to me if it can be done with some light-weight OAM protocol at 
all.</FONT></SPAN></DIV>
<DIV><SPAN class=338222917-05012004><FONT face=Arial 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=338222917-05012004><FONT face=Arial 
size=2>Peter</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> David Allan 
  [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Monday, January 05, 2004 
  11:35 AM<BR><B>To:</B> 'Busschbach, Peter B (Peter)'; 'Peter 
  Willis'<BR><B>Cc:</B> 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; 
  stbryant@cisco.com; pwe3@ietf.org<BR><B>Subject:</B> RE: [PWE3] PW functional 
  model and its OAM [was: FCS retention in PWE3] <BR><BR></FONT></DIV>
  <P><FONT size=2>I didn't raise the point to be obnoxious, I raised it to 
  identify IMO a gap that exists in the current state of the art.</FONT></P>
  <P><FONT size=2>cheers</FONT> <BR><FONT size=2>Dave</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Busschbach, Peter B (Peter) [<A 
  href="mailto:busschbach@lucent.com">mailto:busschbach@lucent.com</A>] 
  </FONT><BR><FONT size=2>&gt; Sent: Monday, January 05, 2004 11:16 AM</FONT> 
  <BR><FONT size=2>&gt; To: Allan, David [CAR:NS00:EXCH]; 'Peter Willis'</FONT> 
  <BR><FONT size=2>&gt; Cc: 'neil.2.harrison@bt.com'; 
  Maarten.Vissers@alcatel.de; </FONT><BR><FONT size=2>&gt; stbryant@cisco.com; 
  pwe3@ietf.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [PWE3] PW functional 
  model and its OAM [was: FCS </FONT><BR><FONT size=2>&gt; retention in PWE3] 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; 
  -----Original Message-----</FONT> <BR><FONT size=2>&gt; &gt; From: David Allan 
  [<A 
  href="mailto:dallan@nortelnetworks.com">mailto:dallan@nortelnetworks.com</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; Sent: Monday, January 05, 2004 10:07 AM</FONT> 
  <BR><FONT size=2>&gt; &gt; To: 'Busschbach, Peter B (Peter)'; 'Peter 
  Willis'</FONT> <BR><FONT size=2>&gt; &gt; Cc: 'neil.2.harrison@bt.com'; 
  Maarten.Vissers@alcatel.de; </FONT><BR><FONT size=2>&gt; &gt; 
  stbryant@cisco.com; pwe3@ietf.org</FONT> <BR><FONT size=2>&gt; &gt; Subject: 
  RE: [PWE3] PW functional model and its OAM [was: FCS</FONT> <BR><FONT 
  size=2>&gt; &gt; retention</FONT> <BR><FONT size=2>&gt; &gt; in PWE3] 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; Hi Peter:</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; &lt;snipped&gt;</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; Yes, I believe VCCV protects against swapped or mismerged</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; LSPs. There are two cases:</FONT> <BR><FONT 
  size=2>&gt; &gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; &gt; Wrong PW 
  Label:</FONT> <BR><FONT size=2>&gt; &gt; &gt; When LSP Ping is used over the 
  PW, the original PW-id FEC is</FONT> <BR><FONT size=2>&gt; &gt; &gt; included 
  in the message. The receiving PE will check whether </FONT><BR><FONT 
  size=2>&gt; &gt; &gt; the FEC in the Ping message matches the original PW-id 
  FEC. </FONT><BR><FONT size=2>&gt; &gt; &gt; It will reply accordingly. 
  </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; The caveat 
  being that the ping implementation when</FONT> <BR><FONT size=2>&gt; &gt; 
  transported by VCCV cares</FONT> <BR><FONT size=2>&gt; &gt; about the incoming 
  label (more akin to the TTL exhaust path </FONT><BR><FONT size=2>&gt; &gt; 
  through the</FONT> <BR><FONT size=2>&gt; &gt; code) unlike PING implementation 
  for LDP where simply being a </FONT><BR><FONT size=2>&gt; &gt; viable 
  egress</FONT> <BR><FONT size=2>&gt; &gt; LSR for the FEC is sufficient (PHP 
  case).</FONT> <BR><FONT size=2>&gt; &gt;&nbsp; </FONT><BR><FONT size=2>&gt; 
  &gt; &gt; Wrong PSN Label:</FONT> <BR><FONT size=2>&gt; &gt; &gt; To detect 
  failures in the underlying transport LSPs, one</FONT> <BR><FONT size=2>&gt; 
  &gt; &gt; could run LSP Ping over the PSN LSPs. However, as far as the 
  </FONT><BR><FONT size=2>&gt; &gt; &gt; PWs are concerned, VCCV would also 
  protect against swapped or </FONT><BR><FONT size=2>&gt; &gt; &gt; mismerged 
  PSN LSPs.&nbsp; </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
  &gt; It can detect them, but given the current state of</FONT> <BR><FONT 
  size=2>&gt; &gt; technology, there is no</FONT> <BR><FONT size=2>&gt; &gt; way 
  to actually traceroute the path a PW will take over a </FONT><BR><FONT 
  size=2>&gt; &gt; PSN.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Hi Dave,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  My point was that the tools specified in VCCV do enable </FONT><BR><FONT 
  size=2>&gt; detection of swapped or mismerged PSN LSPs. I agree that the 
  </FONT><BR><FONT size=2>&gt; tools do not enable the operator to locate the 
  exact location </FONT><BR><FONT size=2>&gt; of the failure. However, would 
  that be different with Y.1711? </FONT><BR><FONT size=2>&gt; It seems to me 
  that any case of LSP swapping or mimerging </FONT><BR><FONT size=2>&gt; 
  requires network-wide fault coordination and possibly </FONT><BR><FONT 
  size=2>&gt; additional diagnostics to locate the failure.</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Happy new year,</FONT> <BR><FONT 
  size=2>&gt; </FONT><BR><FONT size=2>&gt; Peter</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;Best you 
  can</FONT> <BR><FONT size=2>&gt; &gt; do now is when a PW fault is detected, 
  traceroute all ECMP</FONT> <BR><FONT size=2>&gt; &gt; permutations in</FONT> 
  <BR><FONT size=2>&gt; &gt; the PSN and if a fault is found, assume they 
  correspond (ECMP </FONT><BR><FONT size=2>&gt; &gt; extensions to</FONT> 
  <BR><FONT size=2>&gt; &gt; LSP-Query were designed to close that gap a bit 
  better...). </FONT><BR><FONT size=2>&gt; &gt; If 'P' routers</FONT> <BR><FONT 
  size=2>&gt; &gt; recognized TTL exhaust of VCCV probes you could traceroute, 
  </FONT><BR><FONT size=2>&gt; &gt; but I don't</FONT> <BR><FONT size=2>&gt; 
  &gt; think you can depend on that.</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; &gt; If you are already doing PSN misbranching 
  proactively via LSR</FONT> <BR><FONT size=2>&gt; &gt; self test or</FONT> 
  <BR><FONT size=2>&gt; &gt; FEC-CV, then presumably you have independently 
  caught any PSN </FONT><BR><FONT size=2>&gt; &gt; problems, and</FONT> 
  <BR><FONT size=2>&gt; &gt; the problem is unique to the PW layer or the PW-PSN 
  binding </FONT><BR><FONT size=2>&gt; &gt; (either way the</FONT> <BR><FONT 
  size=2>&gt; &gt; problem is local to the PE).</FONT> <BR><FONT size=2>&gt; 
  &gt; </FONT><BR><FONT size=2>&gt; &gt; happy new year</FONT> <BR><FONT 
  size=2>&gt; &gt; Dave</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
  size=2>&gt; &gt; &lt;snipped to end&gt;</FONT> <BR><FONT size=2>&gt; &gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  _______________________________________________</FONT> <BR><FONT size=2>&gt; 
  pwe3 mailing list</FONT> <BR><FONT size=2>&gt; pwe3@ietf.org</FONT> <BR><FONT 
  size=2>&gt; <A target=_blank 
  href="https://www1.ietf.org/mailman/listinfo/pwe3">https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3D3B1.75251042--


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: PW functional model and its OAM [was: FCS retention in PWE3]
Date: Tue, 6 Jan 2004 00:20:56 -0000
Lines: 442
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C3D3EA.F43A2828"
Cc: <Maarten.Vissers@alcatel.de>, <stbryant@cisco.com>, <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Tue Jan 06 01:31:13 2004
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
Content-Class: urn:content-classes:message
Thread-Topic: [PWE3] PW functional model and its OAM [was: FCS retention in PWE3] 
Thread-Index: AcPTtBYuNbIAiCLoSVmxMW7pMmcUwAAKf9eQ
To: <busschbach@lucent.com>, <dallan@nortelnetworks.com>,
        <pjw@ip-engineering.bt.com>
X-OriginalArrivalTime: 06 Jan 2004 00:20:57.0237 (UTC) FILETIME=[F461E450:01C3D3EA]
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3D3EA.F43A2828
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Peter,
=20
You are right it should not do this either.  We have to split the =
problem into 2 stages:  (i) automatic detection and handling (ii) =
on-demand diagnostics.  The former needs to be simple and 'always on', =
the latter can be more complex and is invoked to investigate 'why' the =
defect was detected in the 1st place. =20
=20
The automatic detection/handling function also needs to be generic (ie =
applies to all applications) and associated with the entity that is =
networked.....and that is the LSP, not the PW as that is a specific =
client->server adaptation function.  This should also be an obvious =
requirement if we consider multiple operator I/W cases where MPLS could =
be used, ie LSPs could apply at several levels (ie one LSP being a =
server layer to another LSP as a client layer) and belong to different =
administrations, so the OAM must be bound to the LSP....the PW =
adaptation function only applies between a specific pair of top-level =
points.
=20
regards, Neil

-----Original Message-----
From: Busschbach, Peter B (Peter) [mailto:busschbach@lucent.com]
Sent: 05 January 2004 17:33
To: 'David Allan'; Busschbach, Peter B (Peter); 'Peter Willis'
Cc: Harrison,N,Neil,IKR2 R; Maarten.Vissers@alcatel.de; =
stbryant@cisco.com; pwe3@ietf.org
Subject: RE: [PWE3] PW functional model and its OAM [was: FCS retention =
in PWE3]=20


Dave,
=20
I am sorry if i sounded defensive. I didn't intend to be.
=20
My question is: is there any OAM tool that automatically isolates the =
exact location where a switch overwrites label values incorrectly? I =
don't think Y.1711 does that and it is not obvious to me if it can be =
done with some light-weight OAM protocol at all.
=20
Peter

-----Original Message-----
From: David Allan [mailto:dallan@nortelnetworks.com]
Sent: Monday, January 05, 2004 11:35 AM
To: 'Busschbach, Peter B (Peter)'; 'Peter Willis'
Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de; =
stbryant@cisco.com; pwe3@ietf.org
Subject: RE: [PWE3] PW functional model and its OAM [was: FCS retention =
in PWE3]=20



I didn't raise the point to be obnoxious, I raised it to identify IMO a =
gap that exists in the current state of the art.

cheers=20
Dave=20

> -----Original Message-----=20
> From: Busschbach, Peter B (Peter) [ mailto:busschbach@lucent.com]=20
> Sent: Monday, January 05, 2004 11:16 AM=20
> To: Allan, David [CAR:NS00:EXCH]; 'Peter Willis'=20
> Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de;=20
> stbryant@cisco.com; pwe3@ietf.org=20
> Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> retention in PWE3]=20
>=20
>=20
>=20
>=20
> > -----Original Message-----=20
> > From: David Allan [ mailto:dallan@nortelnetworks.com]=20
> > Sent: Monday, January 05, 2004 10:07 AM=20
> > To: 'Busschbach, Peter B (Peter)'; 'Peter Willis'=20
> > Cc: 'neil.2.harrison@bt.com'; Maarten.Vissers@alcatel.de;=20
> > stbryant@cisco.com; pwe3@ietf.org=20
> > Subject: RE: [PWE3] PW functional model and its OAM [was: FCS=20
> > retention=20
> > in PWE3]=20
> >=20
> >=20
> > Hi Peter:=20
> >=20
> > <snipped>=20
> > > Yes, I believe VCCV protects against swapped or mismerged=20
> > > LSPs. There are two cases:=20
> > >=20
> > > Wrong PW Label:=20
> > > When LSP Ping is used over the PW, the original PW-id FEC is=20
> > > included in the message. The receiving PE will check whether=20
> > > the FEC in the Ping message matches the original PW-id FEC.=20
> > > It will reply accordingly.=20
> >=20
> > The caveat being that the ping implementation when=20
> > transported by VCCV cares=20
> > about the incoming label (more akin to the TTL exhaust path=20
> > through the=20
> > code) unlike PING implementation for LDP where simply being a=20
> > viable egress=20
> > LSR for the FEC is sufficient (PHP case).=20
> > =20
> > > Wrong PSN Label:=20
> > > To detect failures in the underlying transport LSPs, one=20
> > > could run LSP Ping over the PSN LSPs. However, as far as the=20
> > > PWs are concerned, VCCV would also protect against swapped or=20
> > > mismerged PSN LSPs. =20
> >=20
> > It can detect them, but given the current state of=20
> > technology, there is no=20
> > way to actually traceroute the path a PW will take over a=20
> > PSN.=20
>=20
> Hi Dave,=20
>=20
> My point was that the tools specified in VCCV do enable=20
> detection of swapped or mismerged PSN LSPs. I agree that the=20
> tools do not enable the operator to locate the exact location=20
> of the failure. However, would that be different with Y.1711?=20
> It seems to me that any case of LSP swapping or mimerging=20
> requires network-wide fault coordination and possibly=20
> additional diagnostics to locate the failure.=20
>=20
> Happy new year,=20
>=20
> Peter=20
>=20
>=20
> >Best you can=20
> > do now is when a PW fault is detected, traceroute all ECMP=20
> > permutations in=20
> > the PSN and if a fault is found, assume they correspond (ECMP=20
> > extensions to=20
> > LSP-Query were designed to close that gap a bit better...).=20
> > If 'P' routers=20
> > recognized TTL exhaust of VCCV probes you could traceroute,=20
> > but I don't=20
> > think you can depend on that.=20
> >=20
> > If you are already doing PSN misbranching proactively via LSR=20
> > self test or=20
> > FEC-CV, then presumably you have independently caught any PSN=20
> > problems, and=20
> > the problem is unique to the PW layer or the PW-PSN binding=20
> > (either way the=20
> > problem is local to the PE).=20
> >=20
> > happy new year=20
> > Dave=20
> >=20
> > <snipped to end>=20
> >=20
>=20
> _______________________________________________=20
> pwe3 mailing list=20
> pwe3@ietf.org=20
> https://www1.ietf.org/mailman/listinfo/pwe3=20
>=20


------_=_NextPart_001_01C3D3EA.F43A2828
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [PWE3] PW functional model and its OAM [was: FCS retention in =
PWE3]</TITLE>

<META content=3D"MSHTML 5.00.3013.2600" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004>Peter,</SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004>You are right it should not do this =
either.&nbsp; We=20
have to split the problem into 2 stages:&nbsp; (i) automatic detection =
and=20
handling (ii) on-demand diagnostics.&nbsp; The former needs to be simple =
and=20
'always on', the latter can be more complex and is invoked to =
investigate 'why'=20
the defect was detected in the 1st place.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004>The automatic detection/handling function =
also needs to=20
be generic (ie applies to all applications) and associated with the =
entity that=20
is networked.....and that is the LSP, not the PW as that is a specific=20
client-&gt;server adaptation function.&nbsp; This should also be an =
obvious=20
requirement if we consider multiple operator I/W cases where MPLS could =
be used,=20
ie LSPs could apply at several levels (ie one LSP being a server layer =
to=20
another LSP as a client layer) and belong to different administrations, =
so the=20
OAM must be bound to the LSP....the PW adaptation function only applies =
between=20
a specific pair of top-level points.</SPAN></FONT></DIV>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#800000 face=3D"Comic Sans MS" size=3D2><SPAN=20
class=3D480494822-05012004>regards, Neil</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"BORDER-LEFT: #800000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Busschbach, Peter =
B (Peter)=20
  [mailto:busschbach@lucent.com]<BR><B>Sent:</B> 05 January 2004=20
  17:33<BR><B>To:</B> 'David Allan'; Busschbach, Peter B (Peter); 'Peter =

  Willis'<BR><B>Cc:</B> Harrison,N,Neil,IKR2 R; =
Maarten.Vissers@alcatel.de;=20
  stbryant@cisco.com; pwe3@ietf.org<BR><B>Subject:</B> RE: [PWE3] PW =
functional=20
  model and its OAM [was: FCS retention in PWE3] <BR><BR></DIV></FONT>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial=20
  size=3D2>Dave,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial size=3D2>I am =
sorry if i=20
  sounded defensive. I didn't intend to be.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial size=3D2>My =
question is: is=20
  there any OAM tool that automatically isolates the exact location =
where a=20
  switch overwrites label values incorrectly? I don't think Y.1711 does =
that and=20
  it is not obvious to me if it can be done with some light-weight OAM =
protocol=20
  at all.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D338222917-05012004><FONT face=3DArial=20
  size=3D2>Peter</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> David Allan=20
    [mailto:dallan@nortelnetworks.com]<BR><B>Sent:</B> Monday, January =
05, 2004=20
    11:35 AM<BR><B>To:</B> 'Busschbach, Peter B (Peter)'; 'Peter=20
    Willis'<BR><B>Cc:</B> 'neil.2.harrison@bt.com'; =
Maarten.Vissers@alcatel.de;=20
    stbryant@cisco.com; pwe3@ietf.org<BR><B>Subject:</B> RE: [PWE3] PW=20
    functional model and its OAM [was: FCS retention in PWE3]=20
    <BR><BR></FONT></DIV>
    <P><FONT size=3D2>I didn't raise the point to be obnoxious, I raised =
it to=20
    identify IMO a gap that exists in the current state of the =
art.</FONT></P>
    <P><FONT size=3D2>cheers</FONT> <BR><FONT size=3D2>Dave</FONT> </P>
    <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
    From: Busschbach, Peter B (Peter) [<A=20
    =
href=3D"mailto:busschbach@lucent.com">mailto:busschbach@lucent.com</A>]=20
    </FONT><BR><FONT size=3D2>&gt; Sent: Monday, January 05, 2004 11:16 =
AM</FONT>=20
    <BR><FONT size=3D2>&gt; To: Allan, David [CAR:NS00:EXCH]; 'Peter=20
    Willis'</FONT> <BR><FONT size=3D2>&gt; Cc: 'neil.2.harrison@bt.com'; =

    Maarten.Vissers@alcatel.de; </FONT><BR><FONT size=3D2>&gt; =
stbryant@cisco.com;=20
    pwe3@ietf.org</FONT> <BR><FONT size=3D2>&gt; Subject: RE: [PWE3] PW =
functional=20
    model and its OAM [was: FCS </FONT><BR><FONT size=3D2>&gt; retention =
in PWE3]=20
    </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
    -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; &gt; From: =
David=20
    Allan [<A=20
    =
href=3D"mailto:dallan@nortelnetworks.com">mailto:dallan@nortelnetworks.co=
m</A>]</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; Sent: Monday, January 05, 2004 10:07 =
AM</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; To: 'Busschbach, Peter B (Peter)'; =
'Peter=20
    Willis'</FONT> <BR><FONT size=3D2>&gt; &gt; Cc: =
'neil.2.harrison@bt.com';=20
    Maarten.Vissers@alcatel.de; </FONT><BR><FONT size=3D2>&gt; &gt;=20
    stbryant@cisco.com; pwe3@ietf.org</FONT> <BR><FONT size=3D2>&gt; =
&gt; Subject:=20
    RE: [PWE3] PW functional model and its OAM [was: FCS</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; retention</FONT> <BR><FONT size=3D2>&gt; &gt; in =
PWE3]=20
    </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
&gt;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; Hi Peter:</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; </FONT><BR><FONT size=3D2>&gt; &gt; &lt;snipped&gt;</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; &gt; Yes, I believe VCCV protects against swapped =
or=20
    mismerged</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; LSPs. There are =
two=20
    cases:</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; </FONT><BR><FONT =
size=3D2>&gt;=20
    &gt; &gt; Wrong PW Label:</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; =
When LSP=20
    Ping is used over the PW, the original PW-id FEC is</FONT> <BR><FONT =

    size=3D2>&gt; &gt; &gt; included in the message. The receiving PE =
will check=20
    whether </FONT><BR><FONT size=3D2>&gt; &gt; &gt; the FEC in the Ping =
message=20
    matches the original PW-id FEC. </FONT><BR><FONT size=3D2>&gt; &gt; =
&gt; It=20
    will reply accordingly. </FONT><BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; &gt; The caveat being that the ping implementation =
when</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; transported by VCCV cares</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; about the incoming label (more akin to the TTL =
exhaust path=20
    </FONT><BR><FONT size=3D2>&gt; &gt; through the</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; code) unlike PING implementation for LDP where simply being a=20
    </FONT><BR><FONT size=3D2>&gt; &gt; viable egress</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; LSR for the FEC is sufficient (PHP case).</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;&nbsp; </FONT><BR><FONT size=3D2>&gt; &gt; &gt; Wrong PSN =
Label:</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; &gt; To detect failures in the =
underlying=20
    transport LSPs, one</FONT> <BR><FONT size=3D2>&gt; &gt; &gt; could =
run LSP=20
    Ping over the PSN LSPs. However, as far as the </FONT><BR><FONT =
size=3D2>&gt;=20
    &gt; &gt; PWs are concerned, VCCV would also protect against swapped =
or=20
    </FONT><BR><FONT size=3D2>&gt; &gt; &gt; mismerged PSN LSPs.&nbsp;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
&gt; It can=20
    detect them, but given the current state of</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; technology, there is no</FONT> <BR><FONT size=3D2>&gt; &gt; way =
to=20
    actually traceroute the path a PW will take over a </FONT><BR><FONT=20
    size=3D2>&gt; &gt; PSN.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; Hi Dave,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; My point was that the tools specified in VCCV do =
enable=20
    </FONT><BR><FONT size=3D2>&gt; detection of swapped or mismerged PSN =
LSPs. I=20
    agree that the </FONT><BR><FONT size=3D2>&gt; tools do not enable =
the operator=20
    to locate the exact location </FONT><BR><FONT size=3D2>&gt; of the =
failure.=20
    However, would that be different with Y.1711? </FONT><BR><FONT =
size=3D2>&gt;=20
    It seems to me that any case of LSP swapping or mimerging =
</FONT><BR><FONT=20
    size=3D2>&gt; requires network-wide fault coordination and possibly=20
    </FONT><BR><FONT size=3D2>&gt; additional diagnostics to locate the=20
    failure.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; Happy new=20
    year,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Peter</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; &gt;Best you can</FONT> <BR><FONT size=3D2>&gt; &gt; =
do now is=20
    when a PW fault is detected, traceroute all ECMP</FONT> <BR><FONT=20
    size=3D2>&gt; &gt; permutations in</FONT> <BR><FONT size=3D2>&gt; =
&gt; the PSN=20
    and if a fault is found, assume they correspond (ECMP =
</FONT><BR><FONT=20
    size=3D2>&gt; &gt; extensions to</FONT> <BR><FONT size=3D2>&gt; &gt; =
LSP-Query=20
    were designed to close that gap a bit better...). </FONT><BR><FONT=20
    size=3D2>&gt; &gt; If 'P' routers</FONT> <BR><FONT size=3D2>&gt; =
&gt; recognized=20
    TTL exhaust of VCCV probes you could traceroute, </FONT><BR><FONT=20
    size=3D2>&gt; &gt; but I don't</FONT> <BR><FONT size=3D2>&gt; &gt; =
think you can=20
    depend on that.</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =

    size=3D2>&gt; &gt; If you are already doing PSN misbranching =
proactively via=20
    LSR</FONT> <BR><FONT size=3D2>&gt; &gt; self test or</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; FEC-CV, then presumably you have independently =
caught any=20
    PSN </FONT><BR><FONT size=3D2>&gt; &gt; problems, and</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; the problem is unique to the PW layer or the =
PW-PSN binding=20
    </FONT><BR><FONT size=3D2>&gt; &gt; (either way the</FONT> <BR><FONT =

    size=3D2>&gt; &gt; problem is local to the PE).</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; </FONT><BR><FONT size=3D2>&gt; &gt; happy new year</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; Dave</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
    size=3D2>&gt; &gt; &lt;snipped to end&gt;</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
    _______________________________________________</FONT> <BR><FONT =
size=3D2>&gt;=20
    pwe3 mailing list</FONT> <BR><FONT size=3D2>&gt; =
pwe3@ietf.org</FONT>=20
    <BR><FONT size=3D2>&gt; <A =
href=3D"https://www1.ietf.org/mailman/listinfo/pwe3"=20
    =
target=3D_blank>https://www1.ietf.org/mailman/listinfo/pwe3</A></FONT>=20
    <BR><FONT size=3D2>&gt; =
</FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3D3EA.F43A2828--


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-satop-01.txt
Date: Wed, 07 Jan 2004 16:01:40 -0500
Lines: 81
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Jan 07 22:02:18 2004
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Structure-Agnostic TDM over Packet (SAToP)
	Author(s)	: S. Vainshtein, Y. Stein
	Filename	: draft-ietf-pwe3-satop-01.txt
	Pages		: 16
	Date		: 2004-1-7
	
This document describes a pseudowire encapsulation for TDM (T1, E1, T3,
E3) bit-streams that disregards any structure that may be imposed on 
these streams, in particular the structure imposed by the standard TDM 
framing [G.704].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-satop-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-satop-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Sasha Vainshtein <Sasha@AXERRA.com>
Subject: FW: I-D ACTION:draft-ietf-pwe3-satop-01.txt
Date: Thu, 8 Jan 2004 10:03:43 +0200
Lines: 131
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C3D5BD.EEE6E370"
Cc: "Yaakov Stein (E-mail)" <yaakov_s@rad.com>,
        "PWE3 WG (E-mail)"
	 <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Thu Jan 08 09:11:50 2004
Return-path: <pwe3-admin@ietf.org>
To: "Stewart Bryant (E-mail)" <stbryant@cisco.com>,
        "Danny McPherson (E-mail)" <danny@tcb.net>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C3D5BD.EEE6E370
Content-Type: text/plain;
	charset="windows-1255"

Stewart and Danny,
Yaakov and I feel that the draft is ready for the WG Last Call.

With best regards,
                                   Sasha Vainshtein
email:     sasha@axerra.com <mailto:sasha@axerra.com> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)
 


> -----Original Message-----
> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> Sent: Wednesday, January 07, 2004 11:02 PM
> Cc: pwe3@ietf.org
> Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-satop-01.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the Pseudo Wire Emulation Edge 
> to Edge Working Group of the IETF.
> 
> 	Title		: Structure-Agnostic TDM over Packet (SAToP)
> 	Author(s)	: S. Vainshtein, Y. Stein
> 	Filename	: draft-ietf-pwe3-satop-01.txt
> 	Pages		: 16
> 	Date		: 2004-1-7
> 	
> This document describes a pseudowire encapsulation for TDM 
> (T1, E1, T3,
> E3) bit-streams that disregards any structure that may be imposed on 
> these streams, in particular the structure imposed by the 
> standard TDM 
> framing [G.704].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-01.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body 
> of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pwe3-satop-01.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	mailserv@ietf.org.
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pwe3-satop-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 


------_=_NextPart_000_01C3D5BD.EEE6E370
Content-Type: message/rfc822

From foo@bar  Wed Dec 27 16:41:46 2006
To: 
Subject: 
Date: Thu, 8 Jan 2004 10:03:43 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C3D5BD.EEE6E370"
Status: O


------_=_NextPart_002_01C3D5BD.EEE6E370
Content-Type: text/plain



------_=_NextPart_002_01C3D5BD.EEE6E370
Content-Type: application/octet-stream;
	name="ATT42266.txt"
Content-Disposition: attachment;
	filename="ATT42266.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Eric Rosen <erosen@cisco.com>
Subject: Re: Re: PW Status negotiation procedure
Date: Thu, 08 Jan 2004 13:25:07 -0500
Lines: 16
Sender: pwe3-admin@ietf.org
References: <B99995113B318D44BBE87DC50092EDA90C0D5651@nj7460exch006u.ho.lucent.com>
Reply-To: erosen@cisco.com
Mime-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Cc: "'Luca Martini'" <lmartini@cisco.com>,
        "'Shah,
    Himanshu'" <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Jan 08 19:29:08 2004
Return-path: <pwe3-admin@ietf.org>
To: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
In-reply-to: Your message of Mon, 29 Dec 2003 12:03:08 -0500.
             <B99995113B318D44BBE87DC50092EDA90C0D5651@nj7460exch006u.ho.lucent.com> 
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3
 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3
 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


Peter> So the question  is: what good does  it do to inform PE2  that AC1 is
Peter> down, if PE2 is not able to propagate the failure indication over AC2
Peter> for lack of FDI?  

Imagine an ethernet AC  on PE1 which is connected via PW  to layer 3 routing
on PE2.  This could be useful in  order to allow PE2 to treat PE1's ethernet
AC as if it  were an ethernet directly on PE2.  Then  PE2 would need to know
if the  PE1's AC goes  down, but there  are no ethernet  failure indications
that can be relied upon. 

Peter> If PE1 detects that there is a failure, why can't it send an alarm to
Peter> the  SP's fault  management  system?  Are you  assuming  that the  SP
Peter> monitors PE2, but not PE1?  

This could well be the case; PE2 might belong to a different SP.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Busschbach, Peter B (Peter)" <busschbach@lucent.com>
Subject: RE: Re: PW Status negotiation procedure
Date: Thu, 8 Jan 2004 15:36:14 -0500
Lines: 46
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain
Cc: "'Luca Martini'" <lmartini@cisco.com>,
        "'Shah, Himanshu'"
	 <hshah@ciena.com>,
        "'Rex Emmanuel Fernando'" <rex@procket.com>, tob@laurelnetworks.com,
        Srihari Ramachandra Sangli <srihari@procket.com>,
        Renwei Li <renwei@procket.com>, Avneesh Sachdev <asachdev@procket.com>,
        Rajesh Parikh <rparikh@procket.com>, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Jan 08 22:03:11 2004
Return-path: <pwe3-admin@ietf.org>
To: "'erosen@cisco.com'" <erosen@cisco.com>
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

> From: Eric Rosen [mailto:erosen@cisco.com]
> Sent: Thursday, January 08, 2004 1:25 PM

> Peter> So the question  is: what good does  it do to inform 
> PE2  that AC1 is
> Peter> down, if PE2 is not able to propagate the failure 
> indication over AC2
> Peter> for lack of FDI?  
> 
> Imagine an ethernet AC  on PE1 which is connected via PW  to 
> layer 3 routing
> on PE2.  This could be useful in  order to allow PE2 to treat 
> PE1's ethernet
> AC as if it  were an ethernet directly on PE2.  Then  PE2 
> would need to know
> if the  PE1's AC goes  down, but there  are no ethernet  
> failure indications
> that can be relied upon. 

Good point

> 
> Peter> If PE1 detects that there is a failure, why can't it 
> send an alarm to
> Peter> the  SP's fault  management  system?  Are you  
> assuming  that the  SP
> Peter> monitors PE2, but not PE1?  
> 
> This could well be the case; PE2 might belong to a different SP.

Here is the problem I perceive:

According to Luca, PW Status messages have two goals:

a) for data plane fault management
b) for accounting purposes (i.e. SLA downtime measurements)

I understand the need for (a), but I think that (b) should be seen as a derivative of (a) and not as a goal in itself.

I think the need for PW Status for data plane fault management is clear. E.g. in the case of Frame Relay, there is a need for a mechanism to convey the fact that a Frame Relay PVC is inactive from the ingress PE to the egress PE. On the other hand, if ATM is emulated over PW, the situation is different. According to 5.2.3 of the ATM encapsulation draft, if the PW transports OAM cells transparently, the ingress PE should generate AIS cells if it detects a failure on an attachment circuit. Only if it doesn't support the generation of OAM cells is may use PW Status to inform the egress PE. Conclusion, the use of PW Status to convey Attachment Circuit Failures depends on the emulated protocol and the features of the Native Service Processing part of each PE.

Luca's suggestion that PW Status could also be used for SLA downtime measurements, is dangerous because it suggests that no matter what the emulated protocol is, a PE needs to send a PW Status message to its peer in case of an attachment failure. I think that is a misconception.

For SLA downtime measurements, the Service Provider (or multiple Service Providers in case a connection crosses SP boundaries) needs to know the status of the end-to-end connection. How this is done depends on the service. In case of SONET, SDH or ATM, it relies, among other things, on the detection of AIS and RDI signals at the far ends of the connection. In case of Frame Relay it relies on STATUS messages across NNIs and proprietary mechanisms within Frame Relay domains.

Therefore, the role of PW Status messages in the conveyance of Attachment Circuit Failures only serves to guarantee that end-to-end fault management works. The suggestion that the ingress PE needs to use PW Status messages to inform the egress PE of failures on attachment circuits so that a Service Provider can then poll PE2 takes too narrowly a view and is incorrect.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: draft-nadeau-pwe3-oam-msg-map-03.txt
Date: Fri, 09 Jan 2004 09:35:21 +0000
Organization: Cisco Systems, Inc.
Lines: 7
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Fri Jan 09 10:39:14 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Is there PWE3 WG consensus to make:

http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt

a WG draft?

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: Re: FW: I-D ACTION:draft-ietf-pwe3-satop-01.txt
Date: Fri, 09 Jan 2004 18:00:38 +0000
Organization: Cisco Systems, Inc.
Lines: 98
Sender: pwe3-admin@ietf.org
References: <AF5018AC03D1D411ABB70002A5091326D31A87@TLV1>
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Danny McPherson (E-mail)" <danny@tcb.net>,
        "Yaakov Stein (E-mail)" <yaakov_s@rad.com>,
        "PWE3 WG (E-mail)" <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Fri Jan 09 20:20:14 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Sasha Vainshtein <Sasha@AXERRA.com>
In-Reply-To: <AF5018AC03D1D411ABB70002A5091326D31A87@TLV1>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Sasha, Yaakov

Even though we do not anticipate any changes to SAToP, we
need to get tdm-requirements through last call first.

- Stewart


Sasha Vainshtein wrote:

> Stewart and Danny,
> Yaakov and I feel that the draft is ready for the WG Last Call.
> 
> With best regards,
>                                    Sasha Vainshtein
> email:     sasha@axerra.com <mailto:sasha@axerra.com> 
> tel:       +972-3-7659993 (office)
>            +972-8-9254948 (res.)
>            +972-58-674833 (cell.)
>  
> 
> 
> 
>>-----Original Message-----
>>From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
>>Sent: Wednesday, January 07, 2004 11:02 PM
>>Cc: pwe3@ietf.org
>>Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-satop-01.txt
>>
>>
>>A New Internet-Draft is available from the on-line 
>>Internet-Drafts directories.
>>This draft is a work item of the Pseudo Wire Emulation Edge 
>>to Edge Working Group of the IETF.
>>
>>	Title		: Structure-Agnostic TDM over Packet (SAToP)
>>	Author(s)	: S. Vainshtein, Y. Stein
>>	Filename	: draft-ietf-pwe3-satop-01.txt
>>	Pages		: 16
>>	Date		: 2004-1-7
>>	
>>This document describes a pseudowire encapsulation for TDM 
>>(T1, E1, T3,
>>E3) bit-streams that disregards any structure that may be imposed on 
>>these streams, in particular the structure imposed by the 
>>standard TDM 
>>framing [G.704].
>>
>>A URL for this Internet-Draft is:
>>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-satop-01.txt
>>
>>To remove yourself from the IETF Announcement list, send a message to 
>>ietf-announce-request with the word unsubscribe in the body 
>>of the message.
>>
>>Internet-Drafts are also available by anonymous FTP. Login 
>>with the username
>>"anonymous" and a password of your e-mail address. After logging in,
>>type "cd internet-drafts" and then
>>	"get draft-ietf-pwe3-satop-01.txt".
>>
>>A list of Internet-Drafts directories can be found in
>>http://www.ietf.org/shadow.html 
>>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>	mailserv@ietf.org.
>>In the body type:
>>	"FILE /internet-drafts/draft-ietf-pwe3-satop-01.txt".
>>	
>>NOTE:	The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant 
>>mail readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>		
>>		
>>Below is the data which will enable a MIME compliant mail reader
>>implementation to automatically retrieve the ASCII version of the
>>Internet-Draft.
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Date:
> Thu, 8 Jan 2004 10:03:43 +0200
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-pw-mib-03.txt
Date: Fri, 09 Jan 2004 16:28:01 -0500
Lines: 82
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Jan 09 22:29:25 2004
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Pseudo Wire (PW) Management Information Base
	Author(s)	: D. Zelig, T. Nadeau, D. Danenberg, S. Mantin
	Filename	: draft-ietf-pwe3-pw-mib-03.txt
	Pages		: 42
	Date		: 2004-1-9
	
This memo defines an experimental portion of the Management 
Information Base (MIB) for use with network management protocols in 
the Internet community.  In particular, it describes managed 
objects for modeling of Pseudo Wire (PW) services on a general 
Packet Switched Net (PSN).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-pw-mib-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-pw-mib-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: draft-nadeau-pwe3-oam-msg-map-03.txt
Date: Sun, 11 Jan 2004 09:13:00 +0200
Lines: 34
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-From: pwe3-admin@ietf.org Sun Jan 11 08:17:22 2004
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] draft-nadeau-pwe3-oam-msg-map-03.txt
Thread-Index: AcPWlIBm+be8kYUmQdaBheZZ46kmRABerY0Q
To: <stbryant@cisco.com>, <pwe3@ietf.org>
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Stewart,=20

> Is there PWE3 WG consensus to make:
>=20
> =
http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-map-03.txt
>=20
> a WG draft?

Regarding the "like to like" case, although I am certainly in favor
of rationalizing the OAM treatment for the different PW types,=20
I defer to the OAM experts regarding the details.

I do have serious problems with the "service interworking" cases
discussed in this draft.

First, I believe they are beyond the scope of our original charter
(at least as it presently stands).

Second, since we have never defined payload encapsulations=20
for the service interworking cases, I believe it is premature to
attempt to solve the OAM problems.

Finally, I find the discussion in the introduction to be quite =
confusing.
The user data for the ATM to FR over MPLS case is presented as either
being carried by ATM/FR or FR/ATM service interworking before the=20
MPLS edge, and then using an FR or ATM PW respectively.=20
Why then do we need figure 5?=20
If, from the point of view of the MPLS network,=20
we are simply carrying either an ATM or FR PW,=20
then the whole issue has been reduced to cases we know how to treat.

Y(J)S


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: draft-nadeau-pwe3-oam-msg-map-03.txt
Date: Mon, 12 Jan 2004 09:46:23 -0000
Lines: 76
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-From: pwe3-admin@ietf.org Mon Jan 12 10:56:17 2004
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] draft-nadeau-pwe3-oam-msg-map-03.txt
Thread-Index: AcPWlIBm+be8kYUmQdaBheZZ46kmRABerY0QADcrysA=
To: <yaakov_s@rad.com>, <stbryant@cisco.com>, <pwe3@ietf.org>
X-OriginalArrivalTime: 12 Jan 2004 09:46:23.0884 (UTC) FILETIME=[F0B7E4C0:01C3D8F0]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Stewart,

I very much agree with Yaakov on this. =20

I found the document quite confusing as it mixes up both client/server =
and peer network layer interworking relationships.......the treatment is =
for sure not the same in these cases.  Further, it is more than OAM that =
needs considering (even if one got the OAM parts right, which this =
document does not IMO), eg one also has to consider the impact:
-	on the higher level client entity that is common to each data-plane =
layer network partition;
-	to functions that may/may_not be present in each peer data-plane layer =
network protocol;
-	the control-plane relationships between the various data-plane layer =
networks.

If you are going to get this topic right (and its an area we, as an =
operator, are looking at right now internally from the perspective of =
network convergence) you have to be very clear about the layer =
relationships....so this means getting to grips with the G.805/809 =
functional architecture description about what is really going on first. =


I was also under the impression that peer layer network I/W topics (aka =
(badly IMO) 'service I/W') was outside the WG's charter?

regards, Neil

> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> Yaakov Stein
> Sent: 11 January 2004 07:13
> To: stbryant@cisco.com; pwe3@ietf.org
> Subject: RE: [PWE3] draft-nadeau-pwe3-oam-msg-map-03.txt
>=20
>=20
> Stewart,=20
>=20
> > Is there PWE3 WG consensus to make:
> >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-
map-03.txt
>=20
> a WG draft?

Regarding the "like to like" case, although I am certainly in favor
of rationalizing the OAM treatment for the different PW types,=20
I defer to the OAM experts regarding the details.

I do have serious problems with the "service interworking" cases
discussed in this draft.

First, I believe they are beyond the scope of our original charter
(at least as it presently stands).

Second, since we have never defined payload encapsulations=20
for the service interworking cases, I believe it is premature to
attempt to solve the OAM problems.

Finally, I find the discussion in the introduction to be quite =
confusing.
The user data for the ATM to FR over MPLS case is presented as either
being carried by ATM/FR or FR/ATM service interworking before the=20
MPLS edge, and then using an FR or ATM PW respectively.=20
Why then do we need figure 5?=20
If, from the point of view of the MPLS network,=20
we are simply carrying either an ATM or FR PW,=20
then the whole issue has been reduced to cases we know how to treat.

Y(J)S

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


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: draft-nadeau-pwe3-oam-msg-map-03.txt
Date: Mon, 12 Jan 2004 10:19:15 -0500
Organization: Cisco Systems, inc.
Lines: 50
Sender: pwe3-admin@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A5201701046@exrad2.ad.rad.co.il>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Jan 12 16:24:04 2004
Return-path: <pwe3-admin@ietf.org>
To: "'Yaakov Stein'" <yaakov_s@rad.com>, <stbryant@cisco.com>, <pwe3@ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A5201701046@exrad2.ad.rad.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


	Yakov,

> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On 
> Behalf Of Yaakov Stein
> Sent: Sunday, January 11, 2004 2:13 AM
> To: stbryant@cisco.com; pwe3@ietf.org
> Subject: RE: [PWE3] draft-nadeau-pwe3-oam-msg-map-03.txt
> 
> 
> Stewart, 
> 
> > Is there PWE3 WG consensus to make:
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-nadeau-pwe3-oam-msg-
map-03.txt
> 
> a WG draft?

> Regarding the "like to like" case, although I am certainly in favor
> of rationalizing the OAM treatment for the different PW types, 
> I defer to the OAM experts regarding the details.
> 
> I do have serious problems with the "service interworking" cases
> discussed in this draft.
> 
> First, I believe they are beyond the scope of our original charter
> (at least as it presently stands).

	Just to clarify, as I stated during the last PWE3 session
in Minneapolis, we shall remove the like-to-like case in the
next revision of the draft. As a matter of fact, we are working
on this as we speak, so this is not a problem.

> Finally, I find the discussion in the introduction to be quite
confusing.
> The user data for the ATM to FR over MPLS case is presented as either
> being carried by ATM/FR or FR/ATM service interworking before the 
> MPLS edge, and then using an FR or ATM PW respectively. 
> Why then do we need figure 5? 
> If, from the point of view of the MPLS network, 
> we are simply carrying either an ATM or FR PW, 
> then the whole issue has been reduced to cases we know how to treat.

	This can be clarified as part of the removal of the
like-to-like discussion in the draft.

	--Tom


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yaakov Stein" <yaakov_s@rad.com>
Subject: RE: draft-nadeau-pwe3-oam-msg-map-03.txt
Date: Mon, 12 Jan 2004 18:24:57 +0200
Lines: 33
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-From: pwe3-admin@ietf.org Mon Jan 12 17:30:13 2004
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
Thread-Topic: [PWE3] draft-nadeau-pwe3-oam-msg-map-03.txt
Thread-Index: AcPZH3v1X7wFhl3gScGBSSqLg6mj/gABTOGA
To: <tnadeau@cisco.com>, <stbryant@cisco.com>, <pwe3@ietf.org>
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

>=20
> 	Yakov,
<snip>
> 	Just to clarify, as I stated during the last PWE3 session
> in Minneapolis, we shall remove the like-to-like case in the
> next revision of the draft. As a matter of fact, we are working
> on this as we speak, so this is not a problem.

I recall your remarks at the meeting, but am not sure I understand=20
what will remain after the clean-up.

Since you are removing the "like-to-like" case, you are left
with the service interworking case, which is the one I was asking about.

In particular, are you limiting treatment to SI between ATM and FR
outside the MPLS network, and then using either an ATM or FR PW?

Are you providing a method of localizing the defect so that
in a scenario like   user1 ATM MPLS FR user2=20
we can differentiate between defects in the different networks
(in both directions)?

I didn't understand what types and positions of loopbacks are supported.

You seem to rely quite a lot on "BFD", which is only an informational =
draft
(and one whose status is unclear to me). Is this a limitation?=20

I am eagerly awaiting the new version, after which I will comment =
further.
(BTW, you have many outdated references that need fixing)

Y)J(S


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: draft-nadeau-pwe3-oam-msg-map-03.txt
Date: Mon, 12 Jan 2004 14:28:20 -0500
Organization: Cisco Systems, inc.
Lines: 66
Sender: pwe3-admin@ietf.org
References: <27A0F290348F8E45AEF79889DDE65A520170105D@exrad2.ad.rad.co.il>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Jan 12 20:33:05 2004
Return-path: <pwe3-admin@ietf.org>
To: "'Yaakov Stein'" <yaakov_s@rad.com>, <stbryant@cisco.com>, <pwe3@ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <27A0F290348F8E45AEF79889DDE65A520170105D@exrad2.ad.rad.co.il>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O



> -----Original Message-----
> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org] On 
> Behalf Of Yaakov Stein
> Sent: Monday, January 12, 2004 11:25 AM
> To: tnadeau@cisco.com; stbryant@cisco.com; pwe3@ietf.org
> Subject: RE: [PWE3] draft-nadeau-pwe3-oam-msg-map-03.txt
> 
> 
> > 
> > 	Yakov,
> <snip>
> > 	Just to clarify, as I stated during the last PWE3 session
> > in Minneapolis, we shall remove the like-to-like case in the
> > next revision of the draft. As a matter of fact, we are working
> > on this as we speak, so this is not a problem.
> 
> I recall your remarks at the meeting, but am not sure I understand 
> what will remain after the clean-up.

	You could wait and see, as we are planning on publishing
the update in the next few weeks. *)

> Since you are removing the "like-to-like" case, you are left
> with the service interworking case, which is the one I was 
> asking about.
> 
> In particular, are you limiting treatment to SI between ATM and FR
> outside the MPLS network, and then using either an ATM or FR PW?
> 
> Are you providing a method of localizing the defect so that
> in a scenario like user1 ATM MPLS FR user2 
> we can differentiate between defects in the different networks
> (in both directions)?

	If by "different networks" you mean the core and access 
networks, then yes. 
 
> I didn't understand what types and positions of loopbacks are 
> supported.
> 
> You seem to rely quite a lot on "BFD", which is only an 
> informational draft
> (and one whose status is unclear to me). Is this a limitation? 

	No. This draft was actually written before BFD, and
we only recently added it.

> I am eagerly awaiting the new version, after which I will 
> comment further.
> (BTW, you have many outdated references that need fixing)

	Thanks. Will fix.

	--tom


> 
> Y)J(S
> 
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www1.ietf.org/mailman/listinfo/pwe3
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-requirements-08.txt
Date: Mon, 12 Jan 2004 16:07:21 -0500
Lines: 86
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 12 22:08:11 2004
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
	Author(s)	: X. Xiao
	Filename	: draft-ietf-pwe3-requirements-08.txt
	Pages		: 20
	Date		: 2004-1-12
	
This document describes base requirements for the Pseudo-Wire
Emulation Edge to Edge Working Group (PWE3 WG). It provides
guidelines for other working group documents that will define
mechanisms for providing pseudo-wire emulation of Ethernet, ATM, and
Frame Relay. Requirements for pseudo-wire emulation of TDM (i.e.
'synchronous bit streams at rates defined by ITU G.702') are defined
in another document. It should be noted that the PWE3 WG standardizes
mechanisms that can be used to provide PWE3 services, but not the
services themselves.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-requirements-08.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-requirements-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-requirements-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Vach Kompella" <vkompella@timetra.com>
Subject: IANA values draft
Date: Mon, 12 Jan 2004 13:36:08 -0800
Organization: Alcatel USA
Lines: 47
Sender: pwe3-admin@ietf.org
Reply-To: <vach.kompella@alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Cc: <mark@townsley.net>, <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Mon Jan 12 22:39:02 2004
Return-path: <pwe3-admin@ietf.org>
To: "'Luca Martini'" <lmartini@cisco.com>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 12 Jan 2004 21:34:08.0332 (UTC) FILETIME=[CF8070C0:01C3D953]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Luca, Mark,

Under the interface parameters section, there is an inconsistency:

<draft-ietf-pwe3-iana-allocation-02.txt> says

The interface parameter ID is assigned as follows:
   Parameter   ID Length    Description

       0x01         4       Interface MTU in octets.
       0x02         4       Maximum Number of concatenated ATM cells.
       0x03   up to 82      Optional Interface Description string.
       0x04         4       CEP [8] Payload Bytes.
       0x05         2       CEP options.
       0x06         2       Requested VLAN ID
       0x07         4       CEP/TDM bit-rate
       0x08         2       Frame-Relay DLCI Length
       0x09         2       Fragmentation indicator

<draft-ietf-pwe3-control-protocol-05.txt> says

     - Interface MTU

       A 2 octet value indicating the MTU in octets. This is the Maximum
       Transmission Unit, excluding encapsulation overhead, of the ...

     - Requested VLAN ID.

       An Optional 16 bit value indicating the requested VLAN ID. This
       parameter MAY be used by an PE that is incapable of rewriting the
...

Note that both these fields are 16 bits, but the interface parameter
length as given by the IANA allocation draft is 4 and 2.  Does the IANA
specification for ID length include the parameter type and length?
Similar confusion for FR DLCI, max concat ATM cells, CEP payload bytes,
CEP options.

It might be better to set the interface parameter length field to
(option length + 2) to cover the type/length, unambiguously.  Make sure
to specify that in the description field, e.g., (desc str length + 2,
upto 82).

Vach Kompella
IP Division, Alcatel
vach.kompella@alcatel.com
+1 650 237-5152=20


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: Comments on VCCV-01
Date: Tue, 13 Jan 2004 14:18:43 -0500
Lines: 34
Sender: pwe3-admin@ietf.org
X-From: pwe3-admin@ietf.org Tue Jan 13 20:23:22 2004
Return-path: <pwe3-admin@ietf.org>
To: "'Thomas D. Nadeau'" <tnadeau@cisco.com>, pwe3@ietf.org
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Hi Tom:

A few comments in addition to those I've already posted on the list.

Section 3: Although the default behavior for LSP-PING is to sent the reply
over the return PW path, how to specifiy this is not explicitly mentioned.
The LSP-PING option "reply via application level control channel" looks to
be the closest but not quite. I'd suggest renaming the option "reply via
application specific channel" and mandating it's use in VCCV.

Section 3: VCCV as a means of negotiating OAM capabilities and hiding OAM
flows from ECMP seems to be getting blurred with the protocols in use. e.g.
that use of BFD is explicitly mentioned as "fault detection mode". I have
nothing against using BFD and LSP-PING, but describing protocol use as
"modes" seems to be an abuse of the english language. How about "The use of
BFD with VCCV provides a way to emulate..."

Section 6.1: Presume the OAM flag will be corrected to PW PID (actually has
ramifications throughout the document). I'd also like to see 1711 as an
option to the CV types field  (on the assumption the ITU will seek a PPP
DLL).

As a more general editorial comment, I am not entirely comfortable with the
language describing VCCV and what it does. It is continually described as a
"thing" when it simply uses the PW PID mechanism for multiplexing other
protocols over a PW and provides procedures for negotiating their use. So my
preference would be to see statements like "VCCV provides several means of
creating a control channel between PES that attaches the VC under test"
replaced with somthing I'd find more precise such as "VCCV uses LDP for MPLS
PWs to negotiate how OAM PDUs are multiplexed with the PW". If I am not
alone in this sentiment, I'll be glad to propose other text....

rgds
Dave


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Luca Martini <lmartini@cisco.com>
Subject: Re: IANA values draft
Date: Wed, 14 Jan 2004 13:21:43 -0700
Organization: Cisco Systems
Lines: 83
Sender: pwe3-admin@ietf.org
References: <010201c3d954$18c352c0$0101010a@eng.timetra.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: mark@townsley.net, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Jan 14 21:24:09 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.5) Gecko/20031020
X-Accept-Language: en-us, en
To: vach.kompella@alcatel.com
In-Reply-To: <010201c3d954$18c352c0$0101010a@eng.timetra.com>
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

yes I see the issue.
I'll fix it.

here is the fixed part:

Parameter  ID Length    Description

   0x01         4       Interface MTU in octets
   0x02         4       Maximum Number of concatenated ATM cells
   0x03   up to 82      Optional Interface Description string
   0x04         4       CEP [8] Payload Bytes
   0x05         4       CEP options
   0x06         4       Requested VLAN ID
   0x07         6       CEP/TDM bit-rate
   0x08         4       Frame-Relay DLCI Length
   0x09         4       Fragmentation indicator
   0x0A        4       FCS retension indicator

the text in the control document referring to this is :
"The Length field is defined as the length of the interface parameter
including the parameter id and length field itself. "

this seems clear to me .....


Thanks.
Luca



Vach Kompella wrote:

>Luca, Mark,
>
>Under the interface parameters section, there is an inconsistency:
>
><draft-ietf-pwe3-iana-allocation-02.txt> says
>
>The interface parameter ID is assigned as follows:
>   Parameter   ID Length    Description
>
>       0x01         4       Interface MTU in octets.
>       0x02         4       Maximum Number of concatenated ATM cells.
>       0x03   up to 82      Optional Interface Description string.
>       0x04         4       CEP [8] Payload Bytes.
>       0x05         2       CEP options.
>       0x06         2       Requested VLAN ID
>       0x07         4       CEP/TDM bit-rate
>       0x08         2       Frame-Relay DLCI Length
>       0x09         2       Fragmentation indicator
>
><draft-ietf-pwe3-control-protocol-05.txt> says
>
>     - Interface MTU
>
>       A 2 octet value indicating the MTU in octets. This is the Maximum
>       Transmission Unit, excluding encapsulation overhead, of the ...
>
>     - Requested VLAN ID.
>
>       An Optional 16 bit value indicating the requested VLAN ID. This
>       parameter MAY be used by an PE that is incapable of rewriting the
>...
>
>Note that both these fields are 16 bits, but the interface parameter
>length as given by the IANA allocation draft is 4 and 2.  Does the IANA
>specification for ID length include the parameter type and length?
>Similar confusion for FR DLCI, max concat ATM cells, CEP payload bytes,
>CEP options.
>
>It might be better to set the interface parameter length field to
>(option length + 2) to cover the type/length, unambiguously.  Make sure
>to specify that in the description field, e.g., (desc str length + 2,
>upto 82).
>
>Vach Kompella
>IP Division, Alcatel
>vach.kompella@alcatel.com
>+1 650 237-5152 
>
>
>  
>


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-pw-tc-mib-03.txt
Date: Wed, 14 Jan 2004 15:54:48 -0500
Lines: 82
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Wed Jan 14 21:55:09 2004
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Definitions for Textual Conventions and 
			  OBJECT-IDENTITIES for Pseudo-Wires Management
	Author(s)	: T. Nadeau, D. Danenberg, D. Zelig, A. Malis
	Filename	: draft-ietf-pwe3-pw-tc-mib-03.txt
	Pages		: 11
	Date		: 2004-1-14
	
This memo defines an experimental portion of the Management 
information Base (MIB) for use with network management protocols in 
the Internet community.  In particular, it describes the textual 
conventions to be used in the various Pseudo Wire (PW) MIB modules.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-pw-tc-mib-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-pw-tc-mib-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Andrew G. Malis" <andy.malis@tellabs.com>
Subject: Liaison from MPLS and Frame Relay Alliance to PWE3 WG
Date: Thu, 15 Jan 2004 07:45:15 -0500
Lines: 22
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: "Andrew G. Malis" <andy.malis@tellabs.com>, ietf-secretariat@ietf.org,
        mankin@psg.com, jon.peterson@neustar.biz, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Jan 15 13:56:08 2004
Return-path: <pwe3-admin@ietf.org>
X-Sender: vivacenet\amalis@po1.vivacenetworks.com (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.1.1
To: Stewart Bryant <stbryant@cisco.com>, Danny McPherson <danny@tcb.net>
X-OriginalArrivalTime: 15 Jan 2004 12:45:49.0588 (UTC) FILETIME=[80D13540:01C3DB65]
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Stewart and Danny,

In order to maintain the technical progress in the MPLS and FR Alliance, it 
would be greatly appreciated if the IETF could expedite the IANA 
assignments for FEC 128, FEC 129, and the PW Status TLV codepoints in 
draft-ietf-pwe3-control-protocol-05.txt and 
draft-ietf-pwe3-iana-allocation-02.txt.

The MPLS and FR Alliance is working with ITU-T Study Group 17 on 
Recommendation X.84 for FR over MPLS, which is aligned with 
draft-ietf-pwe3-frame-relay-01.txt. To complete the status signaling and 
approve the Recommendation, these codepoints require IANA assignment.

These codepoints are also required for the MPLS and FR Alliance to complete 
the FR over MPLS Interworking Implementation Agreement.

Please advise us at your earliest convenience on the status of these 
codepoint assignments.

Thanks,
Andy Malis
Chairman and President, MPLS & FR Alliance


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Moshe.Aharon@ecitele.com
Subject: l2vpn signaling (LDP/CR-LDP/RSVP-TE)
Date: Thu, 15 Jan 2004 16:28:12 +0200
Lines: 14
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: pwe3-admin@ietf.org Thu Jan 15 16:00:13 2004
Return-path: <pwe3-admin@ietf.org>
To: l2vpn@ietf.org, pwe3@ietf.org
X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999
X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.9a |January 7, 2002) at
 01/15/2004 04:58:12 PM
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Hello.

Since the decision (RFC3468) to not progress CR-LDP, it seems that in a
PWE3 ethernet VC, or any traffic-engineered l2vpn-ldp solution, A PE will
signal VC-LSPs using LDP on top of pre-signaled Tunnel-LSPs using RSVP-TE.
This forces any edge equipment to support both RSVP-TE and LDP.

Is this the right way to go (or am I missing something, and the above
observation is incorrect)?

Have the WGs considered a PWE3/VPLS signaling using RSVP?

Thanks!
/Moshe


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Kireeti Kompella <kireeti@juniper.net>
Subject: Re: l2vpn signaling (LDP/CR-LDP/RSVP-TE)
Date: Thu, 15 Jan 2004 10:35:34 -0800 (PST)
Lines: 19
Sender: pwe3-admin@ietf.org
References: <OF98A0A282.3A22E362-ONC2256E1C.004DE73C@ecitele.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: l2vpn@ietf.org, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Thu Jan 15 19:38:07 2004
Return-path: <pwe3-admin@ietf.org>
X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs
To: Moshe.Aharon@ecitele.com
In-Reply-To: <OF98A0A282.3A22E362-ONC2256E1C.004DE73C@ecitele.com>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

On Thu, 15 Jan 2004 Moshe.Aharon@ecitele.com wrote:

> This forces any edge equipment to support both RSVP-TE and LDP.

True, if the TE LSPs extend all the way to the PEs.  However, I'm not
aware of edge equipment that supports LDP but not RSVP-TE (or vice
versa).

> Have the WGs considered a PWE3/VPLS signaling using RSVP?

If you believe that PWE3 signaling should be point-to-point (and the
favorite example is carrying bandwidth/QoS information), yes, RSVP
would be a fine vehicle.  Note that the LSP hierarchy draft introduces
the notion of 'targeted RSVP sessions', if you squint just right.

The argument for doing VPLS with RSVP is weaker.

Kireeti.
-------


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Matthew.Bocci@alcatel.co.uk
Subject: Liaison from ATM Forum to PWE3 WG
Date: Thu, 15 Jan 2004 23:48:01 +0000
Lines: 20
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: ietf-secretariat@ietf.org, mankin@psg.com, jon.peterson@neustar.biz,
        pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Jan 16 01:01:40 2004
Return-path: <pwe3-admin@ietf.org>
To: Stewart Bryant <stbryant@cisco.com>, Danny McPherson <danny@tcb.net>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11  |July 24, 2002) at
 01/15/2004 23:54:07
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Stewart and Danny,

In order to maintain the technical progress in the ATM Forum, we would very
much appreciate if the IETF PWE3 WG could expedite the IANA code point
assignment for FEC 128 and FEC 129 code points and the PW status TLV code
points in draft-ietf-pwe3-control-protocol-05.txt and
draft-ietf-pwe3-iana-allocation-02.txt.

The ATM Forum is developing a specification that uses procedures contained
in these documents to establish ATM control channels in ATM-MPLS Network
Interworking. To complete the work and approve the specification, these
code points require IANA assignment.

Please advise us at your earliest convenience on the status of the code
point assignments.

Best regards,

Matthew Bocci
Chair, ATM Forum AIC Working Group


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Danny McPherson <danny@tcb.net>
Subject: Re: Liaison from ATM Forum to PWE3 WG
Date: Thu, 15 Jan 2004 17:00:25 -0700
Lines: 34
Sender: pwe3-admin@ietf.org
References: <OFF63D33DB.F38C4B2C-ON80256E1C.008249FA@netfr.alcatel.fr>
Mime-Version: 1.0 (Apple Message framework v609)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ietf-secretariat@ietf.org, pwe3@ietf.org,
        Stewart Bryant <stbryant@cisco.com>, jon.peterson@neustar.biz,
        mankin@psg.com
X-From: pwe3-admin@ietf.org Fri Jan 16 01:03:07 2004
Return-path: <pwe3-admin@ietf.org>
In-Reply-To: <OFF63D33DB.F38C4B2C-ON80256E1C.008249FA@netfr.alcatel.fr>
To: Matthew.Bocci@alcatel.co.uk
X-Mailer: Apple Mail (2.609)
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


Noted, as with Andy's.

If you'd like this to be recorded appropriately please send
it to statements@ietf.org.

-danny

On Jan 15, 2004, at 4:48 PM, Matthew.Bocci@alcatel.co.uk wrote:

> Stewart and Danny,
>
> In order to maintain the technical progress in the ATM Forum, we would 
> very
> much appreciate if the IETF PWE3 WG could expedite the IANA code point
> assignment for FEC 128 and FEC 129 code points and the PW status TLV 
> code
> points in draft-ietf-pwe3-control-protocol-05.txt and
> draft-ietf-pwe3-iana-allocation-02.txt.
>
> The ATM Forum is developing a specification that uses procedures 
> contained
> in these documents to establish ATM control channels in ATM-MPLS 
> Network
> Interworking. To complete the work and approve the specification, these
> code points require IANA assignment.
>
> Please advise us at your earliest convenience on the status of the code
> point assignments.
>
> Best regards,
>
> Matthew Bocci
> Chair, ATM Forum AIC Working Group


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Yongjun Im" <yjim@lge.com>
Subject: Re: l2vpn signaling (LDP/CR-LDP/RSVP-TE)
Date: Fri, 16 Jan 2004 16:04:31 +0900
Lines: 28
Sender: pwe3-admin@ietf.org
References: <OF98A0A282.3A22E362-ONC2256E1C.004DE73C@ecitele.com> <20040115103027.V31112@kummer.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: base64
Cc: <l2vpn@ietf.org>, <pwe3@ietf.org>
X-From: pwe3-admin@ietf.org Fri Jan 16 08:08:11 2004
Return-path: <pwe3-admin@ietf.org>
To: <Moshe.Aharon@ecitele.com>, <pwe3-admin@ietf.org>
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: base64
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

TDJWUE4gc2lnbmFsaW5nIGlzIGltcGxlbWVudGVkIHVzaW5nIHRhcmdldGVkIExEUCBzZXNzaW9u
LCB3aGljaCBpcw0KaW5kZXBlbmRlbnQgb2Ygb3JkaW5hcnkgTERQIHNlc3Npb24gdGhhdCBpcyB1
c2VkIGZvciBlc3RhYmxpc2hpbmcgaG9wLWJ5LWhvcA0KTFNQLiBJIGJlbGlldmUgdGhlIG1hcHBp
bmcgUFcgdG8gTFNQIHdoaWNoIExEUCwgQ1ItTFNQIG9yIFJTVlAtVEUNCm1pZ2h0IGhhdmUgZXN0
YWJsaXNoZWQgaXMgc3lzdGVtLWRlcGVuZGVudCBpc3N1ZS4gSW4gY2FzZSBvZiBFdGhlcm5ldCBv
dmVyIE1QTFMsDQpFdGhlcm5ldCBmcmFtZSBjb3VsZCBiZSB0cmFuc21pdHRlZCB0byBiZXN0LWVm
Zm9ydCBMU1AoYnkgTERQKSwgb3IgQ1ItTFNQIA0KKGJ5IENSLUxTUCBvciBSU1ZQLVRFKSwgZGVw
ZW5kaW5nIG9uIGN1c3RvbWVyJ3MgcmVxdWlyZW1lbnQoYmFuZHdpZHRoDQpndWFyYW50ZWUgZXRj
KSBhbmQgY29uZmlndXJhdGlvbi4NCg0KWW9uZ2p1bi4NCg0KDQotLS0tLSBPcmlnaW5hbCBNZXNz
YWdlIC0tLS0tIA0KRnJvbTogPHB3ZTMtYWRtaW5AaWV0Zi5vcmc+DQpUbzogPE1vc2hlLkFoYXJv
bkBlY2l0ZWxlLmNvbT4NCkNjOiA8bDJ2cG5AaWV0Zi5vcmc+OyA8cHdlM0BpZXRmLm9yZz4NClNl
bnQ6IEZyaWRheSwgSmFudWFyeSAxNiwgMjAwNCAzOjM1IEFNDQpTdWJqZWN0OiBSZTogW1BXRTNd
IGwydnBuIHNpZ25hbGluZyAoTERQL0NSLUxEUC9SU1ZQLVRFKQ0KDQoNCj4gT24gVGh1LCAxNSBK
YW4gMjAwNCBNb3NoZS5BaGFyb25AZWNpdGVsZS5jb20gd3JvdGU6DQo+IA0KPiA+IFRoaXMgZm9y
Y2VzIGFueSBlZGdlIGVxdWlwbWVudCB0byBzdXBwb3J0IGJvdGggUlNWUC1URSBhbmQgTERQLg0K
PiANCj4gVHJ1ZSwgaWYgdGhlIFRFIExTUHMgZXh0ZW5kIGFsbCB0aGUgd2F5IHRvIHRoZSBQRXMu
ICBIb3dldmVyLCBJJ20gbm90DQo+IGF3YXJlIG9mIGVkZ2UgZXF1aXBtZW50IHRoYXQgc3VwcG9y
dHMgTERQIGJ1dCBub3QgUlNWUC1URSAob3IgdmljZQ0KPiB2ZXJzYSkuDQo+IA0KPiA+IEhhdmUg
dGhlIFdHcyBjb25zaWRlcmVkIGEgUFdFMy9WUExTIHNpZ25hbGluZyB1c2luZyBSU1ZQPw0KPiAN
Cj4gSWYgeW91IGJlbGlldmUgdGhhdCBQV0UzIHNpZ25hbGluZyBzaG91bGQgYmUgcG9pbnQtdG8t
cG9pbnQgKGFuZCB0aGUNCj4gZmF2b3JpdGUgZXhhbXBsZSBpcyBjYXJyeWluZyBiYW5kd2lkdGgv
UW9TIGluZm9ybWF0aW9uKSwgeWVzLCBSU1ZQDQo+IHdvdWxkIGJlIGEgZmluZSB2ZWhpY2xlLiAg
Tm90ZSB0aGF0IHRoZSBMU1AgaGllcmFyY2h5IGRyYWZ0IGludHJvZHVjZXMNCj4gdGhlIG5vdGlv
biBvZiAndGFyZ2V0ZWQgUlNWUCBzZXNzaW9ucycsIGlmIHlvdSBzcXVpbnQganVzdCByaWdodC4N
Cj4gDQo+IFRoZSBhcmd1bWVudCBmb3IgZG9pbmcgVlBMUyB3aXRoIFJTVlAgaXMgd2Vha2VyLg0K
PiANCj4gS2lyZWV0aS4NCj4gLS0tLS0tLQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4gcHdlMyBtYWlsaW5nIGxpc3QNCj4gcHdlM0BpZXRm
Lm9yZw0KPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQo+IA==


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Loa Andersson <loa@pi.se>
Subject: Re: l2vpn signaling (LDP/CR-LDP/RSVP-TE)
Date: Thu, 15 Jan 2004 17:24:03 +0100
Lines: 38
Sender: pwe3-admin@ietf.org
References: <OF98A0A282.3A22E362-ONC2256E1C.004DE73C@ecitele.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: l2vpn@ietf.org, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Jan 16 11:59:04 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: Moshe.Aharon@ecitele.com
In-Reply-To: <OF98A0A282.3A22E362-ONC2256E1C.004DE73C@ecitele.com>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Moshe,

this is a horse and cart issue. Most commonly you'll have
an MPLS-enabled network using TE and L3vpn, you will do
TE by RSVP-TE. If you introduce l2vpn into that network
why would you want to add an extra protocol for that
specific TE?

/Loa

Moshe.Aharon@ecitele.com wrote:

>Hello.
>
>Since the decision (RFC3468) to not progress CR-LDP, it seems that in a
>PWE3 ethernet VC, or any traffic-engineered l2vpn-ldp solution, A PE will
>signal VC-LSPs using LDP on top of pre-signaled Tunnel-LSPs using RSVP-TE.
>This forces any edge equipment to support both RSVP-TE and LDP.
>
>Is this the right way to go (or am I missing something, and the above
>observation is incorrect)?
>
>Have the WGs considered a PWE3/VPLS signaling using RSVP?
>
>Thanks!
>/Moshe
>
>
>
>
>  
>

-- 

Loa Andersson

mobile +46 739 81 21 64


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: draft-ietf-pwe3-arch-06.txt comments and actions
Date: Mon, 19 Jan 2004 14:51:06 +0000
Organization: Cisco Systems, Inc.
Lines: 15
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Jan 19 15:54:44 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

We received a number of comments from the IESG review
of draft-ietf-pwe3-arch-06.txt. I will be sending out
a short series of mails each with a comment and the
proposed fix.

I will also post a draft with all the proposed fixes
on some convenient web server.

Having spoken to Danny I propose that we undertake a
two week review of just the amended text, and then
hand -07 of the draft back to Jon.

Regards

Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: [Fwd: Editorial comments on draft-ietf-pwe3-arch-06.txt Section 8
 (was: MIB Doctor (architectural) review needed)]
Date: Mon, 19 Jan 2004 15:09:18 +0000
Organization: Cisco Systems, Inc.
Lines: 352
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Jan 19 16:17:11 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

The following comments were received from the MIB review process.

Prayon, Tom Nadeau and I talked about this, and it was agreed that
they would re-write section 8 to make it more of an architectural
overview, removing specific PW type MIB references.

The proposed new section 8 is at the end of this mail.

-------- Original Message --------
Subject: Editorial comments on draft-ietf-pwe3-arch-06.txt Section 8 (was: MIB 
Doctor (architectural) review needed)
Date: Thu, 11 Dec 2003 08:58:10 -0800 (PST)
From: C. M. Heard <heard@pobox.com>
To: Mreview (E-mail) <mreview@ops.ietf.org>
CC: Stewart Bryant <stbryant@cisco.com>,        Prayson Pate 
<prayson.pate@overturenetworks.com>

On Thu, 4 Dec 2003, Wijnen, Bert (Bert) wrote:
> Document: draft-ietf-pwe3-arch-06.txt
> 
> Section 8 has a "architectural overview" of how PWE3 related
> MIBs fit in their architecture. We may want to check this out.
> 
> It is on IESG agenda today (Dec 4th)... so probably too late
> to feed any comments into the telechat today. I will take a defer
> so we as MIB doctors can do EARLY review instead of LATE review.

Sigh.  My general reaction to a first read of sections 8.1 and 8.2
was that the proposed MIB architecture seemed reasonable, but since
the devil is in often in the details, and I decided to look at the
reference documents to see how the proposed architecture is actually
realized in the draft PWE3 MIB modules, in particular in the ones
cited in the example shown in Figure 16: the PW-CEM-MIB, PW-TC-MIB,
PW-MIB, and PW-MPLS-MIB.  Alas, this exercise did not come off
entirely trouble-free:  the first problem that I ran into is that
the PW-TC-MIB and PW-MIB drafts have expired (which I got around
by retrieving old versions from the archive at
http://www.watersprings.org/pub/id/index-all.html);  the second
was that the PW-CEM-MIB no longer exists, it is now called the
PW-CEP-STD-MIB;  the third problem was that the reference
[PWMPLSMIB] points to the wrong document.

I'll have some substantive comments on the MIB architecture in
a subsequent message (mainly concerns that the relationship to
the IF-MIB is not discussed), but for now I'd like to get some
editorial comments on record.  Document authors have been cc:'d.

//cmh

Editorial comments on Section 8 of <draft-ietf-pwe3-arch-06.txt>:

Don't use of obsolete term "CEM" in Fig. 15 (Sec. 8.2.1, p.38):
---------------------------------------------------------------

OLD:

                   +-----------+ +-----------+     +-----------+
         Service   |    CEM    | | Ethernet  |     |    ATM    |
          Layer    |Service MIB| |Service MIB| ... |Service MIB|
                   +-----------+ +-----------+     +-----------+

NEW:
                   +-----------+ +-----------+     +-----------+
         Service   |   SONET   | | Ethernet  |     |    ATM    |
          Layer    |Service MIB| |Service MIB| ... |Service MIB|
                   +-----------+ +-----------+     +-----------+

Fix incorrect MIB module names in Fig. 16 (sec. 8.2.1, p.39):
-------------------------------------------------------------

OLD:
                      +-----------------+
                      |    SONET MIB    | RFC2558
                      +-----------------+
                               |
                      +-----------------+
            Service   |SONET Service MIB| pw-cem-mib
             Layer    +-----------------+
           - - - - - - - - - - | - - - - - - - - - - - - - - -
                      +-----------------+
           Generic PW | Generic PW MIBS | pw-tc-mib
             Layer    +-----------------+ pw-mib
           - - - - - - - - - - | - - - - - - - - - - - - - - -
                      +-----------------+
             PSN VC   |   MPLS VC MIBS  | pw-mpls-mib
             Layer    +-----------------+
           - - - - - - - - - - | - - - - - - - - - - - - - - -
                      +-----------------+
              PSN     |    MPLS MIBs    |   mpls-te-mib
             Layer    +-----------------+   mpls-lsr-mib

NEW:
                      +-----------------+
                      |    SONET MIB    | SONET-MIB
                      +-----------------+
                               |
                      +-----------------+
            Service   |SONET Service MIB| PW-CEP-STD-MIB
             Layer    +-----------------+
           - - - - - - - - - - | - - - - - - - - - - - - - - -
                      +-----------------+
           Generic PW | Generic PW MIBS | PW-TC-MIB
             Layer    +-----------------+ PW-MIB
           - - - - - - - - - - | - - - - - - - - - - - - - - -
                      +-----------------+
             PSN VC   |   MPLS VC MIBS  | PW-MPLS-MIB
             Layer    +-----------------+
           - - - - - - - - - - | - - - - - - - - - - - - - - -
                      +-----------------+
              PSN     |    MPLS MIBs    | MPLS-TE-STD-MIB
             Layer    +-----------------+ MPLS-LSR-STD-MIB

Fix incorrect citation/module name (sec. 8.2.2, p. 39)
------------------------------------------------------

OLD:
    adaptation MIB, in this case, it would produce the PW-CEM-MIB
______________________________________________________^^^^^^^^^^
    [PWMPLSMIB] that would be used to adapt SONET services to the
____^^^^^^^^^
    underlying PSN that carries the PWE3 service.

NEW:
    adaptation MIB, in this case, it would produce the PW-CEP-STD-MIB
    [PWCEPMIB] that would be used to adapt SONET services to the
    underlying PSN that carries the PWE3 service.

Eliminate incorrect citation (sec. 8.2.3, p. 40):
-------------------------------------------------

OLD:
    This MIB is used to interconnect the Service Layer MIBs to the PSN VC
    Layer MIBs. The latter will be described in the next section.  This
    layer also provides the PW-TC-MIB [PWTCMIB].  This MIB contains
    common SMI textual conventions [RFC1902] that MAY be used by any PW
___________________________________^^^^^^^
    MIB.

NEW:
    This MIB is used to interconnect the Service Layer MIBs to the PSN VC
    Layer MIBs. The latter will be described in the next section.  This
    layer also provides the PW-TC-MIB [PWTCMIB].  This MIB contains
    common SMI textual conventions that MAY be used by any PW MIB.

Fix incorrect references
------------------------

OLD:
    [PWMPLSMIB] Danenberg et al, "SONET/SDH Circuit Emulation Service
                Over MPLS (CEM) Management Information Base Using
                SMIv2", <draft-ietf-pwe3-cep-mib-01.txt>, work in
                progress, October 2002.

NEW:
    [PWMPLSMIB] Zelig et al, "Pseudo Wire (PW) over MPLS PSN
                Management Information Base",
                <draft-ietf-pwe3-pw-mpls-mib-03.txt>, work in
                progress, October 2003

    [PWCEPMIB]  Danenberg et al, "SONET/SDH Circuit Emulation Service
                Over Packet (CEP) Management Information Base Using
                SMIv2", <draft-ietf-pwe3-cep-mib-03.txt>, work in
                progress, October 2003.

Delete unneeded obsolete reference
----------------------------------

REMOVE:
    [RFC1902]   RFC-1902: Structure of Management Information for
                Version 2 of the Simple Network Management Protocol
                (SNMPv2), Case et al, January 1996.


==========================================================================
==========================================================================

Proposed new section 8:

8. Management and Monitoring

    This section describes the management and monitoring architecture for
    PWE3.

8.1  Status and Statistics

    The PE should report the status of the interface and tabulate
    statistics that help monitor the state of the network, and to help
    with measurement of service level agreements (SLAs). Typical counters
    include:

        o Counts of PW-PDUs sent and received, with and without errors.
        o Counts of sequenced PW-PDUs lost.
        o Counts of service PDUs sent and received over the PSN, with
          and without errors (non-TDM).
        o Service-specific interface counts.
        o One way delay and delay variation.

    These counters would be contained in a PW-specific MIB, and they
    should not replicate existing MIB counters.

8.2  PW SNMP MIB Architecture

    This section describes the general architecture for SNMP MIBs used to
    manage PW services and the underlying PSN.  The intent here is to
    provide a clear picture of how all of the pertinent MIBs fit together
    to form a cohesive management framework for deploying PWE3 services.
    Note that the names of MIB modules used below are suggestions, and do
    not necessarily require the actual modules used to realize the
    components in the architecture to be named exactly so.

8.2.1.  MIB Layering

    The SNMP MIBs created for PWE3 should fit the architecture shown in
    Figure 15.  The architecture provides a layered modular model into
    which any supported emulated service can be connected to any
    supported PSN type. This model fosters reuse of as much functionality
    as possible. For instance, the emulated service layer MIB modules do
    not redefine the existing emulated service MIB module; rather, they
    only associate it with the pseudowires used to carry the emulated
    service over the configured PSN. In this way, the PWE3 MIB
    architecture follows the overall PWE3 archiecture.

    The archtecture does allow for the joining of unsupported emulated
    service or PSN types by simply defining additional MIB modules to
    associate these new types with existing ones. These new modules can
    subsequently be standardized. Note that there is a separate MIB
    module for each emulated service as well as one for each underlying
    PSN.  These MIB modules may be used in various combinations as
    needed.

            Native
         Service MIBs    ...           ...               ...
                          |             |                 |
                    +-----------+ +-----------+     +-----------+
          Service   |    CEP    | | Ethernet  |     |    ATM    |
           Layer    |Service MIB| |Service MIB| ... |Service MIB|
                    +-----------+ +-----------+     +-----------+
                            \           |             /
                              \         |           /
        - - - - - - - - - - - - \ - - - | - - - - / - - - - - - -
                                  \     |       /
                    +-------------------------------------------+
         Generic PW |            Generic PW MIBs                |
           Layer    +-------------------------------------------+
                                 /             \
        - - - - - - - - - - - - / - - - - - - - - \ - - - - - - -
                              /                     \
                            /                         \
                    +--------------+             +----------------+
          PSN VC    |L2TP VC MIB(s)|             | MPLS VC MIB(s) |
           Layer    +--------------+             +----------------+
                           |                              |
          Native     +-----------+                  +-----------+
           PSN       |L2TP MIB(s)|                  |MPLS MIB(s)|
           MIBs      +-----------+                  +-----------+

                  Figure 15: MIB Module Layering Relationship


    Figure 16 shows an example for a SONET PW carried over MPLS Traffic
    Engineering Tunnel and an LDP-signaled LSP.

                             +-----------------+
                             |    SONET MIB    |  RFC2558
                             +-----------------+
                                      |
                        +------------------------------+
             Service    | Circuit Emulation Service MIB|
              Layer     +------------------------------+
            - - - - - - - - - - - - - | - - - - - - - - - - - - -
                             +-----------------+
            Generic PW       | Generic PW MIB  |
              Layer          +-----------------+
            - - - - - - - - - - - - - | - - - - - - - - - - - - -
                             +-----------------+
              PSN VC         |   MPLS VC MIBs  |
              Layer          +-----------------+
                                |           |
                   +-----------------+  +------------------+
                   | MPLS-TE-STD-MIB |  | MPLS-LSR-STD-MIB |
                   +-----------------+  +------------------+

        Figure 16: SONET PW over MPLS PSN Service-specific Example


8.2.2.  Service Layer MIB Modules

    This conceptual layer in the model contains MIB modules used to
    represent the relationship between emulated PWE3 services such as
    Ethernet, ATM, or Frame Relay and the pseudo-wire used to carry that
    service across the PSN. This layer contains those corresponding MIB
    modules used to mate or adapt those emulated services to the generic
    pseudo-wire representation, which are represented in the "Generic PW
    MIB" functional block in Figure 16 above.  This working group should
    not produce any MIB modules for managing the general service; rather,
    it should produce just those modules that are used to interface or
    adapt the emulated service onto the PWE3 management framework as
    shown above. For example, the standard SONET-MIB [RFC2558] is
    designed and maintained by another working group. The SONET-MIB is
    designed to manage the native service without PW emulation.  However,
    since the PWE3 working group is chartered to produce standards which
    show how to emulate existing technologies such as SONET/SDH over
    pseudo-wires rather than re-inventing those modules.

8.2.3.  Generic PW MIB Modules

    The middle layer in the architecture is referred to as the Generic PW
    Layer.  MIB in this layer are responsible for providing pseudo-wire
    specific counters and service models used for monitoring and
    configuration of PWE3 services over any supported PSN service. That
    is, this layer provides a general model of PWE3 abstraction for
    management purposes. This MIB is used to interconnect the MIB modules
    residing in the Service Layer to the PSN VC Layer MIBs (see section
    8.2.4).

8.2.4.  PSN VC Layer MIB Modules

    The third layer in the PWE3 management architecture is referred to as
    the PSN VC Layer. It is comprised of MIBs that are specifically
    designed to associate pseudo-wires onto those underlying PSN
    transport technologies that carry the pseudo-wire payloads across teh
    PSN.  In general this means that the MIB module provides a mapping
    between the emulated service that is mapped to the pseudo-wire via
    the Service Layer and Generic PW MIB Layer onto the native PSN
    service. For example, in the case of MPLS for example, it is required
    that the general VC service be mapped into MPLS LSPs via the MPLS-
    LSR-STD-MIB [LSRMIB] or Traffic Engineered (TE) Tunnels via the
    MPLS-TE-STD-MIB [TEMIB]. In addition, the MPLS-LDP-STD-MIB [LDPMIB]
    may be used to reveal the MPLS labels that are distributed over the
    MPLS PSN in order to maintain the PW service. As with the native
    service MIB modules described earlier, the MIB modules used to manage
    the native PSN services are produced by other working groups that
    design and specify the native PSN services. These MIBs should contain
    the appropriate mechanisms for monitoring and configuring the PSN
    service such that the emulated PWE3 service will function correctly.

8.3 Connection Verification and Traceroute

    A connection verification mechanism should be supported by PWs.
    Connection verification as well as other alarm mechanisms can alert
    the operator that a PW has lost its remote connection.  The opaque
    nature of a PW means that it is not possible to specify a generic
    connection verification or traceroute mechanism that passes this
    status to the CEs over the PW.  If connection verification status of
    the PW is needed by the CE, it MUST be mapped to the native
    connection status method.

    For troubleshooting purposes, it is sometimes desirable to know the
    exact functional path of a PW between PEs. This is provided by the
    traceroute service of the underlying PSN.  The opaque nature of the
    PW means that this traceroute information is only available within
    the provider network, e.g., at the PEs.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: draft-ietf-pwe3-arch-06.txt - 5.4.4 nit
Date: Mon, 19 Jan 2004 15:24:18 +0000
Organization: Cisco Systems, Inc.
Lines: 15
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Jan 19 16:34:08 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O



<Steve>

Nit: 5.4.4: bits 4-11 MUST be ignored by the receiver

=====================================================

Proposed change to rext in 5.4.4

<    Bits 4 to 11 inclusive are reserved for future use and must be zero.
---
 >    Bits 4 to 11 inclusive are reserved for future use, and MUST be
 >    ignored by the receiver.
---


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-pwe3-tdm-requirements-04.txt
Date: Mon, 19 Jan 2004 10:35:22 -0500
Lines: 85
Sender: pwe3-admin@ietf.org
Reply-To: Internet-Drafts@ietf.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 19 16:36:04 2004
Return-path: <pwe3-admin@ietf.org>
To: IETF-Announce: ;
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Pseudo Wire Emulation Edge to Edge Working Group of the IETF.

	Title		: Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN)
	Author(s)	: M. Riegel
	Filename	: draft-ietf-pwe3-tdm-requirements-04.txt
	Pages		: 26
	Date		: 2004-1-16
	
This document specifies the particular requirements for
edge-to-edge-emulation of circuits carrying time division multiplexed
digital signals of the PDH as well as the SONET/SDH hierarchy over
packet-switched networks. It is based on the common architecture for
Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH].
It makes references to requirements in [PWE3-REQ] where applicable
and complements [PWE3-REQ] by defining requirements originating from
specifics of TDM circuits.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pwe3-tdm-requirements-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-pwe3-tdm-requirements-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Stewart Bryant <stbryant@cisco.com>
Subject: draft-ietf-pwer-arch-06.txt security section comments 1/2
Date: Mon, 19 Jan 2004 15:29:47 +0000
Organization: Cisco Systems, Inc.
Lines: 49
Sender: pwe3-admin@ietf.org
Reply-To: stbryant@cisco.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-From: pwe3-admin@ietf.org Mon Jan 19 16:40:29 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
To: "pwe3@ietf.org" <pwe3@ietf.org>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

<Russ>

    Section 10, 4th paragraph says:

       IPSec MAY provide authentication, integrity, non-repudiation, and
       confidentiality of data transferred between two PEs. It cannot
       provide the equivalent services to the native service.

    IPsec does not, and cannot, provide non-repudiation.  IPsec can be used
    to provide integrity, authentication, confidentiality, and access
    control.

    Once this correction is made, I am concerned that the IPsec-related
    access controls will be confused with the access controls being
    discussed in the last paragraph of section 10.  I belive some
    clarifying language is needed.

<Steve>

10: IPsec does not provide non-repudiation.

=======================================================================

I propose that we make the following changes to section 9 (security section)


=============
<    IPSec MAY provide authentication, integrity, non-repudiation, and
<    confidentiality of data transferred between two PEs. It cannot
<    provide the equivalent services to the native service.
---
 >    IPSec MAY provide authentication, integrity, and confidentiality of
 >    data transferred between two PEs. It cannot provide the equivalent
 >

=============


<    the data path. The access controls that are in place in the PE to
<    protect and validate its configuration will be sufficient to ensure
<    that the NSP performs as expected.
---
 >    the data path. A PE designed and managed to best current practise
 >    will have controls in place that protect and validate its
 >    configuration and these will be sufficient to ensure that the NSP
 >    behaves as expected.


- Stewart


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Max Riegel <maximilian.riegel@siemens.com>
Subject: Re: I-D ACTION:draft-ietf-pwe3-tdm-requirements-04.txt
Date: Mon, 19 Jan 2004 18:34:24 +0100
Lines: 34
Sender: pwe3-admin@ietf.org
References: <200401191535.KAA21625@ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: pwe3@ietf.org
X-From: pwe3-admin@ietf.org Mon Jan 19 18:43:06 2004
Return-path: <pwe3-admin@ietf.org>
X-Sender: dems1cg2@139.21.212.200
X-Mailer: QUALCOMM Windows Eudora Version 5.1.1
To: stbryant@cisco.com, danny@arbor.net
In-Reply-To: <200401191535.KAA21625@ietf.org>
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Stewart, Danny,

after careful review and cleaning up quite a number of editorial issues in 
the document I believe the TDM requirements I-D is now ready for working 
group last call.
What is your opinion?

Bye
Max

At 2004-01-19 10:35 -0500, Internet-Drafts@ietf.org wrote:
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Pseudo Wire Emulation Edge to Edge 
>Working Group of the IETF.
>
>         Title           : Requirements for Edge-to-Edge Emulation of TDM 
> Circuits over Packet Switching Networks (PSN)
>         Author(s)       : M. Riegel
>         Filename        : draft-ietf-pwe3-tdm-requirements-04.txt
>         Pages           : 26
>         Date            : 2004-1-16
>
>This document specifies the particular requirements for
>edge-to-edge-emulation of circuits carrying time division multiplexed
>digital signals of the PDH as well as the SONET/SDH hierarchy over
>packet-switched networks. It is based on the common architecture for
>Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [PWE3-ARCH].
>It makes references to requirements in [PWE3-REQ] where applicable
>and complements [PWE3-REQ] by defining requirements originating from
>specifics of TDM circuits.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-requirements-04.txt


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Thomas Narten <narten@us.ibm.com>
Subject: Re: Liaison from ATM Forum to PWE3 WG
Date: Mon, 19 Jan 2004 21:38:02 -0500
Lines: 30
Sender: pwe3-admin@ietf.org
References: <OFF63D33DB.F38C4B2C-ON80256E1C.008249FA@netfr.alcatel.fr>
Cc: Stewart Bryant <stbryant@cisco.com>, Danny McPherson <danny@tcb.net>,
        mankin@psg.com, jon.peterson@neustar.biz, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Tue Jan 20 03:50:06 2004
Return-path: <pwe3-admin@ietf.org>
To: Matthew.Bocci@alcatel.co.uk
In-Reply-To: Message from Matthew.Bocci@alcatel.co.uk
   of "Thu, 15 Jan 2004 23:48:01 GMT." <OFF63D33DB.F38C4B2C-ON80256E1C.008249FA@netfr.alcatel.fr> 
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Some clarifying questions.

Matthew.Bocci@alcatel.co.uk writes:

> Stewart and Danny,

> In order to maintain the technical progress in the ATM Forum, we would very
> much appreciate if the IETF PWE3 WG could expedite the IANA code point
> assignment for FEC 128 and FEC 129 code points and the PW status TLV code
> points in draft-ietf-pwe3-control-protocol-05.txt and
> draft-ietf-pwe3-iana-allocation-02.txt.

> The ATM Forum is developing a specification that uses procedures contained
> in these documents to establish ATM control channels in ATM-MPLS Network
> Interworking. To complete the work and approve the specification, these
> code points require IANA assignment.

Do you need the code points, or do you actually need both the code
points and completion of the relevant drafts? I.e., do you not need to
also reference the two above named drafts in a normative fashion as
well, in which case, having them be Internet-Drafts is presumably a
problem?

Also, when you say "expedite", is there a specific deadline you are
trying to meet, where not having the IANA code points is a show
stopper of some kind (and the last remaining issue blocking completion
of something, e.g., publication of a standard?) If so, it would be
helpful to know the deadline and understand the nature of it.

Thomas


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Matthew.Bocci@alcatel.co.uk
Subject: Re: Liaison from ATM Forum to PWE3 WG
Date: Tue, 20 Jan 2004 18:24:47 +0000
Lines: 81
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Danny McPherson <danny@tcb.net>, jon.peterson@neustar.biz, mankin@psg.com,
        pwe3@ietf.org, pwe3-admin@ietf.org,
        Stewart Bryant <stbryant@cisco.com>
X-From: pwe3-admin@ietf.org Tue Jan 20 19:37:14 2004
Return-path: <pwe3-admin@ietf.org>
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11  |July 24, 2002) at
 01/20/2004 18:31:28
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


Thomas,

Thank you for your response. Please see below for some comments.

Matthew



|---------+--------------------------->
|         |           Thomas Narten   |
|         |           <narten@us.ibm.c|
|         |           om>             |
|         |           Sent by:        |
|         |           pwe3-admin@ietf.|
|         |           org             |
|         |                           |
|         |                           |
|         |           20/01/2004 02:38|
|         |                           |
|---------+--------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |        To:      Matthew BOCCI/GB/ALCATEL@ALCATEL                                                                              |
  |        cc:      Stewart Bryant <stbryant@cisco.com>, Danny McPherson <danny@tcb.net>, mankin@psg.com,                         |
  |        jon.peterson@neustar.biz, pwe3@ietf.org                                                                                |
  |        Subject: Re: [PWE3] Liaison from ATM Forum to PWE3 WG                                                                  |
  >-------------------------------------------------------------------------------------------------------------------------------|




Some clarifying questions.

Matthew.Bocci@alcatel.co.uk writes:

> Stewart and Danny,

> In order to maintain the technical progress in the ATM Forum, we would
very
> much appreciate if the IETF PWE3 WG could expedite the IANA code point
> assignment for FEC 128 and FEC 129 code points and the PW status TLV code
> points in draft-ietf-pwe3-control-protocol-05.txt and
> draft-ietf-pwe3-iana-allocation-02.txt.

> The ATM Forum is developing a specification that uses procedures
contained
> in these documents to establish ATM control channels in ATM-MPLS Network
> Interworking. To complete the work and approve the specification, these
> code points require IANA assignment.

Do you need the code points, or do you actually need both the code
points and completion of the relevant drafts? I.e., do you not need to
also reference the two above named drafts in a normative fashion as
well, in which case, having them be Internet-Drafts is presumably a
problem?

MB> Yes, in practice we would need to reference both the code points, and
the drafts themselves in a normative way.

Also, when you say "expedite", is there a specific deadline you are
trying to meet, where not having the IANA code points is a show
stopper of some kind (and the last remaining issue blocking completion
of something, e.g., publication of a standard?) If so, it would be
helpful to know the deadline and understand the nature of it.

MB> The ATM Forum specification depends on the procedures contained in the
above mentioned drafts and cannot be approved and published until the IANA
code points are allocated, and we have an RFC number for the PWE3 control
draft. The earliest that we could start the approvals process is at the
next ATMF meeting at the end of April 2004. Meetings run on a 3 month
cycle, so if the IANA code points are not allocated until after April, we
would have to wait until the following meeting (3 months later), and so on.


Thomas

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


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Thomas Narten <narten@us.ibm.com>
Subject: Re: Liaison from ATM Forum to PWE3 WG
Date: Tue, 20 Jan 2004 18:21:15 -0500
Lines: 32
Sender: pwe3-admin@ietf.org
References: <OF46CED7FA.4D3717CD-ON80256E21.00639A5F@netfr.alcatel.fr>
Cc: Danny McPherson <danny@tcb.net>, jon.peterson@neustar.biz, mankin@psg.com,
        pwe3@ietf.org, pwe3-admin@ietf.org,
        Stewart Bryant <stbryant@cisco.com>
X-From: pwe3-admin@ietf.org Wed Jan 21 00:26:05 2004
Return-path: <pwe3-admin@ietf.org>
To: Matthew.Bocci@alcatel.co.uk
In-Reply-To: Message from Matthew.Bocci@alcatel.co.uk
   of "Tue, 20 Jan 2004 18:24:47 GMT." <OF46CED7FA.4D3717CD-ON80256E21.00639A5F@netfr.alcatel.fr> 
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Matthew.Bocci@alcatel.co.uk writes:
> Do you need the code points, or do you actually need both the code
> points and completion of the relevant drafts? I.e., do you not need to
> also reference the two above named drafts in a normative fashion as
> well, in which case, having them be Internet-Drafts is presumably a
> problem?

> MB> Yes, in practice we would need to reference both the code points, and
> the drafts themselves in a normative way.

What this suggests to me is that expediting the IANA assignments
doesn't really help you a whole lot. What you really want is the
document to be approved for publicatoin as an RFC (together with the
IANA assignments). (Note: normally, at RFC publication time, IANA
would assign the code points.)

Is this a correct interpretation?

> MB> The ATM Forum specification depends on the procedures contained in the
> above mentioned drafts and cannot be approved and published until the IANA
> code points are allocated, and we have an RFC number for the PWE3 control
> draft. The earliest that we could start the approvals process is at the
> next ATMF meeting at the end of April 2004. Meetings run on a 3 month
> cycle, so if the IANA code points are not allocated until after April, we
> would have to wait until the following meeting (3 months later), and so on.

This is good information to know, as it suggests good milestones for
the WG to try and achieve. I'll have to defer to the chairs and WG for
comments on how close the documents are for forwarding to the IESG and
what obstacles remain.

Thomas


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Matthew.Bocci@alcatel.co.uk
Subject: Re: Liaison from ATM Forum to PWE3 WG
Date: Thu, 22 Jan 2004 17:39:23 +0000
Lines: 74
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Danny McPherson <danny@tcb.net>, jon.peterson@neustar.biz, mankin@psg.com,
        pwe3@ietf.org, pwe3-admin@ietf.org,
        Stewart Bryant <stbryant@cisco.com>
X-From: pwe3-admin@ietf.org Thu Jan 22 18:48:09 2004
Return-path: <pwe3-admin@ietf.org>
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Lotus Notes Release 5.0.8  June 18, 2001
X-MIMETrack: Serialize by Router on GBMAIL02/GB/ALCATEL(Release 5.0.11  |July 24, 2002) at
 01/22/2004 17:39:18
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


Thomas,

Your interpretation is correct.

Best regards,

Matthew



|---------+--------------------------->
|         |           Thomas Narten   |
|         |           <narten@us.ibm.c|
|         |           om>             |
|         |           Sent by:        |
|         |           pwe3-admin@ietf.|
|         |           org             |
|         |                           |
|         |                           |
|         |           20/01/2004 23:21|
|         |                           |
|---------+--------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |        To:      Matthew BOCCI/GB/ALCATEL@ALCATEL                                                                              |
  |        cc:      Danny McPherson <danny@tcb.net>, jon.peterson@neustar.biz, mankin@psg.com, pwe3@ietf.org, pwe3-admin@ietf.org,|
  |        Stewart Bryant <stbryant@cisco.com>                                                                                    |
  |        Subject: Re: [PWE3] Liaison from ATM Forum to PWE3 WG                                                                  |
  >-------------------------------------------------------------------------------------------------------------------------------|




Matthew.Bocci@alcatel.co.uk writes:
> Do you need the code points, or do you actually need both the code
> points and completion of the relevant drafts? I.e., do you not need to
> also reference the two above named drafts in a normative fashion as
> well, in which case, having them be Internet-Drafts is presumably a
> problem?

> MB> Yes, in practice we would need to reference both the code points, and
> the drafts themselves in a normative way.

What this suggests to me is that expediting the IANA assignments
doesn't really help you a whole lot. What you really want is the
document to be approved for publicatoin as an RFC (together with the
IANA assignments). (Note: normally, at RFC publication time, IANA
would assign the code points.)

Is this a correct interpretation?

> MB> The ATM Forum specification depends on the procedures contained in
the
> above mentioned drafts and cannot be approved and published until the
IANA
> code points are allocated, and we have an RFC number for the PWE3 control
> draft. The earliest that we could start the approvals process is at the
> next ATMF meeting at the end of April 2004. Meetings run on a 3 month
> cycle, so if the IANA code points are not allocated until after April, we
> would have to wait until the following meeting (3 months later), and so
on.

This is good information to know, as it suggests good milestones for
the WG to try and achieve. I'll have to defer to the chairs and WG for
comments on how close the documents are for forwarding to the IESG and
what obstacles remain.

Thomas

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


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "Thomas D. Nadeau" <tnadeau@cisco.com>
Subject: RE: Comments on VCCV-01
Date: Mon, 26 Jan 2004 09:00:37 -0500
Organization: Cisco Systems, inc.
Lines: 82
Sender: pwe3-admin@ietf.org
References: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09CE4@zcard031.ca.nortel.com>
Reply-To: <tnadeau@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: "'Rahul Aggarwal'" <rahul@juniper.net>,
        "'Monique Morrow \(mmorrow\)'" <mmorrow@cisco.com>,
        "'George Swallow \(swallow\)'" <swallow@cisco.com>
X-From: pwe3-admin@ietf.org Tue Jan 27 02:03:48 2004
Return-path: <pwe3-admin@ietf.org>
To: "'David Allan'" <dallan@nortelnetworks.com>, <pwe3@ietf.org>
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
Importance: Normal
In-Reply-To: <FFFC48AEAA5F7447929F4F0D93FCC12D05D09CE4@zcard031.ca.nortel.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O


	Sorry it took so long to reply, but I have
been working on 100 other things. :P

> Hi Tom:
> 
> A few comments in addition to those I've already posted on the list.
> 
> Section 3: Although the default behavior for LSP-PING is to 
> sent the reply
> over the return PW path, how to specifiy this is not 
> explicitly mentioned.
> The LSP-PING option "reply via application level control 
> channel" looks to
> be the closest but not quite. I'd suggest renaming the option 
> "reply via
> application specific channel" and mandating it's use in VCCV.

	I am not quite sure what you are getting at. I have
modified the text a bit clearer. Please take a look at it
when it is out in the next day or so.

> Section 3: VCCV as a means of negotiating OAM capabilities 
> and hiding OAM
> flows from ECMP seems to be getting blurred with the 
> protocols in use. e.g.
> that use of BFD is explicitly mentioned as "fault detection 
> mode". I have
> nothing against using BFD and LSP-PING, but describing protocol use as
> "modes" seems to be an abuse of the english language. How 
> about "The use of BFD with VCCV provides a way to emulate..."

	I don't understand why you want to make the distinction
betweeen emulation of a detection mechanism or an actual detection
mechanism.

> Section 6.1: Presume the OAM flag will be corrected to PW PID 
> (actually has ramifications throughout the document). 

	Done.

> I'd also like to see 
> 1711 as an option to the CV types field  (on the assumption the 
> ITU will seek a PPP DLL).

	If the working group desires such a mode to be
added, then we can, but lets hear from the WG before we
do this. 

> As a more general editorial comment, I am not entirely 
> comfortable with the
> language describing VCCV and what it does. It is continually 
> described as a
> "thing" when it simply uses the PW PID mechanism for 
> multiplexing other
> protocols over a PW and provides procedures for negotiating 
> their use. So my
> preference would be to see statements like "VCCV provides 
> several means of
> creating a control channel between PES that attaches the VC 
> under test"
> replaced with somthing I'd find more precise such as "VCCV 
> uses LDP for MPLS
> PWs to negotiate how OAM PDUs are multiplexed with the PW". 
> If I am not alone in this sentiment, I'll be glad to propose other
text....

	I am not sure what you are getting at. Perhaps
if you could give some specific examples it might be
clearer.

	--Tom

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


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: "David Allan" <dallan@nortelnetworks.com>
Subject: RE: Comments on VCCV-01
Date: Mon, 26 Jan 2004 10:00:44 -0500
Lines: 109
Sender: pwe3-admin@ietf.org
Cc: "'Rahul Aggarwal'" <rahul@juniper.net>,
        "'Monique Morrow (mmorrow)'"
	 <mmorrow@cisco.com>,
        "'George Swallow (swallow)'" <swallow@cisco.com>
X-From: pwe3-admin@ietf.org Wed Jan 28 00:58:23 2004
Return-path: <pwe3-admin@ietf.org>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>, pwe3@ietf.org
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

Hi: 
> 	Sorry it took so long to reply, but I have
> been working on 100 other things. :P
> 
> > Hi Tom:
> > 
> > A few comments in addition to those I've already posted on the list.
> > 
> > Section 3: Although the default behavior for LSP-PING is to
> > sent the reply
> > over the return PW path, how to specifiy this is not 
> > explicitly mentioned.
> > The LSP-PING option "reply via application level control 
> > channel" looks to
> > be the closest but not quite. I'd suggest renaming the option 
> > "reply via
> > application specific channel" and mandating it's use in VCCV.
> 
> 	I am not quite sure what you are getting at. I have
> modified the text a bit clearer. Please take a look at it
> when it is out in the next day or so.

OK

 
> > Section 3: VCCV as a means of negotiating OAM capabilities
> > and hiding OAM
> > flows from ECMP seems to be getting blurred with the 
> > protocols in use. e.g.
> > that use of BFD is explicitly mentioned as "fault detection 
> > mode". I have
> > nothing against using BFD and LSP-PING, but describing 
> protocol use as
> > "modes" seems to be an abuse of the english language. How 
> > about "The use of BFD with VCCV provides a way to emulate..."
> 
> 	I don't understand why you want to make the distinction 
> betweeen emulation of a detection mechanism or an actual 
> detection mechanism.

I'm more concerned with what VCCV actually is. IMHO it is a means of muxing
protocols with a PW in such a way that it is not considered by deployed ECMP
and some control plane extensions to negotiate what protocols are supported.
It is a minor nit, but I find the description rather grandiose vs. actual
reality.


> 
> > Section 6.1: Presume the OAM flag will be corrected to PW PID
> > (actually has ramifications throughout the document). 
> 
> 	Done.

Great.

> 
> > I'd also like to see
> > 1711 as an option to the CV types field  (on the assumption the 
> > ITU will seek a PPP DLL).
> 
> 	If the working group desires such a mode to be
> added, then we can, but lets hear from the WG before we
> do this. 

OK, Danny, Stuart.... (?) (!)

> 
> > As a more general editorial comment, I am not entirely
> > comfortable with the
> > language describing VCCV and what it does. It is continually 
> > described as a
> > "thing" when it simply uses the PW PID mechanism for 
> > multiplexing other
> > protocols over a PW and provides procedures for negotiating 
> > their use. So my
> > preference would be to see statements like "VCCV provides 
> > several means of
> > creating a control channel between PES that attaches the VC 
> > under test"
> > replaced with somthing I'd find more precise such as "VCCV 
> > uses LDP for MPLS
> > PWs to negotiate how OAM PDUs are multiplexed with the PW". 
> > If I am not alone in this sentiment, I'll be glad to propose other
> text....
> 
> 	I am not sure what you are getting at. Perhaps
> if you could give some specific examples it might be
> clearer.

Again refers to how the text seems to inflate having a PW code point into a
"mode"...

Dave

> 
> 	--Tom
> 
> > 
> > rgds
> > Dave
> > 
> > _______________________________________________
> > pwe3 mailing list
> > pwe3@ietf.org
> > https://www1.ietf.org/mailman/listinfo/pwe3
> > 
> 
> 
> 


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Shahram Davari <Shahram_Davari@pmc-sierra.com>
Subject: RE: Comments on VCCV-01
Date: Thu, 29 Jan 2004 07:12:39 -0800
Lines: 11
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain
Cc: "'Rahul Aggarwal'" <rahul@juniper.net>,
        "'Monique Morrow (mmorrow)'"
	 <mmorrow@cisco.com>,
        "'George Swallow (swallow)'" <swallow@cisco.com>
X-From: pwe3-admin@ietf.org Thu Jan 29 16:16:09 2004
Return-path: <pwe3-admin@ietf.org>
To: "'tnadeau@cisco.com'" <tnadeau@cisco.com>,
        "'David Allan'"
	 <dallan@nortelnetworks.com>, pwe3@ietf.org
X-Mailer: Internet Mail Service (5.5.2656.59)
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

>> I'd also like to see 
>> 1711 as an option to the CV types field  (on the assumption the 
>> ITU will seek a PPP DLL).
>
>	If the working group desires such a mode to be
>added, then we can, but lets hear from the WG before we
>do this. 
>
 I am in favor of adding 1711 mode.

-Shahram


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: neil.2.harrison@bt.com
Subject: RE: Comments on VCCV-01
Date: Thu, 29 Jan 2004 16:39:04 -0000
Lines: 26
Sender: pwe3-admin@ietf.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-From: pwe3-admin@ietf.org Thu Jan 29 18:24:35 2004
Return-path: <pwe3-admin@ietf.org>
X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1
content-class: urn:content-classes:message
Thread-Topic: [PWE3] Comments on VCCV-01
Thread-Index: AcPme7wJPEOocwtBQySn2RWbleHE9QAChX2Q
To: <pwe3@ietf.org>
X-OriginalArrivalTime: 29 Jan 2004 16:39:04.0981 (UTC) FILETIME=[68813450:01C3E686]
Content-Transfer-Encoding: quoted-printable
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

> From: pwe3-admin@ietf.org [mailto:pwe3-admin@ietf.org]On Behalf Of
> Shahram Davari
> Sent: 29 January 2004 15:13
> To: 'tnadeau@cisco.com'; 'David Allan'; pwe3@ietf.org
> Cc: 'Rahul Aggarwal'; 'Monique Morrow (mmorrow)'; 'George Swallow
> (swallow)'
> Subject: RE: [PWE3] Comments on VCCV-01
>=20
>=20
> >> I'd also like to see=20
> >> 1711 as an option to the CV types field  (on the assumption the=20
> >> ITU will seek a PPP DLL).
> >
> >	If the working group desires such a mode to be
> >added, then we can, but lets hear from the WG before we
> >do this.=20
> >
>  I am in favor of adding 1711 mode.
>=20
> -Shahram

NH=3D> I guess folks would not be surprised to hear we would like this =
too.

regards, Neil
BT/GS CTO


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Peter Willis <pjw@ip-engineering.bt.com>
Subject: Re: Comments on VCCV-01
Date: Fri, 30 Jan 2004 16:30:23 +0000
Lines: 13
Sender: pwe3-admin@ietf.org
References: <4B6D09F3B826D411A67300D0B706EFDE0115CDA5@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-From: pwe3-admin@ietf.org Fri Jan 30 17:34:03 2004
Return-path: <pwe3-admin@ietf.org>
X-Mailer: exmh version 2.5 07/13/2001 with version: MH 6.8.3 #11[UCI]
To: pwe3@ietf.org
In-reply-to: Your message of "Thu, 29 Jan 2004 07:12:39 PST."
             <4B6D09F3B826D411A67300D0B706EFDE0115CDA5@nt-exch-yow.pmc_nt.nt.pmc-sierra.bc.ca> 
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

> >> I'd also like to see 
> >> 1711 as an option to the CV types field  (on the assumption the 
> >> ITU will seek a PPP DLL).
> >
> >	If the working group desires such a mode to be
> >added, then we can, but lets hear from the WG before we
> >do this. 
> >

I too would like to see a 1711 mode added to the CV types field.

Peter Willis
Office of BT Group CTO.


From pwe3-admin@ietf.org  Wed Dec 27 16:41:46 2006
From: Chris Chase <chase@att.com>
Subject: Re: l2vpn signaling (LDP/CR-LDP/RSVP-TE)
Date: Fri, 30 Jan 2004 11:56:26 -0500
Lines: 50
Sender: pwe3-admin@ietf.org
References: <OF98A0A282.3A22E362-ONC2256E1C.004DE73C@ecitele.com> <20040115103027.V31112@kummer.juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Moshe.Aharon@ecitele.com, l2vpn@ietf.org, pwe3@ietf.org
X-From: pwe3-admin@ietf.org Fri Jan 30 17:59:05 2004
Return-path: <pwe3-admin@ietf.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
To: Kireeti Kompella <kireeti@juniper.net>
In-Reply-To: <20040115103027.V31112@kummer.juniper.net>
Content-Transfer-Encoding: 7bit
Errors-To: pwe3-admin@ietf.org
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>,
	<mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
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>
Status: O

How well are edge nodes going to scale for a full mesh of targeted LDP 
sessions?  I keep hearing from vendors about connection limits on their 
TCP stacks.  Whether it is BGP for CE-PE connections in 2547 services or 
targeted LDP for PWE, it seems there are constant pressures on the 
number of connections vendors can support.

With RSVP for the vc label signaling I don't see the connection 
constrains from a full mesh.  A couple years ago Andy Malis told me that 
not looking at RSVP was simply because implementations were already 
starting down the LDP road.

Chris Chase


On 1/15/2004 1:35 PM, Kireeti Kompella wrote:

>On Thu, 15 Jan 2004 Moshe.Aharon@ecitele.com wrote:
>
>  
>
>>This forces any edge equipment to support both RSVP-TE and LDP.
>>    
>>
>
>True, if the TE LSPs extend all the way to the PEs.  However, I'm not
>aware of edge equipment that supports LDP but not RSVP-TE (or vice
>versa).
>
>  
>
>>Have the WGs considered a PWE3/VPLS signaling using RSVP?
>>    
>>
>
>If you believe that PWE3 signaling should be point-to-point (and the
>favorite example is carrying bandwidth/QoS information), yes, RSVP
>would be a fine vehicle.  Note that the LSP hierarchy draft introduces
>the notion of 'targeted RSVP sessions', if you squint just right.
>
>The argument for doing VPLS with RSVP is weaker.
>
>Kireeti.
>-------
>
>_______________________________________________
>pwe3 mailing list
>pwe3@ietf.org
>https://www1.ietf.org/mailman/listinfo/pwe3
>  
>