From pwe3-bounces@ietf.org Fri Nov 02 12:31:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InzO1-0003LI-R6; Fri, 02 Nov 2007 12:28:45 -0400 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1InzO0-0003LA-DI for pwe3-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 12:28:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InzO0-0003L1-39; Fri, 02 Nov 2007 12:28:44 -0400 Received: from smail5.alcatel.fr ([62.23.212.27]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InzNz-0004S0-JW; Fri, 02 Nov 2007 12:28:44 -0400 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lA2GRUV1022672; Fri, 2 Nov 2007 17:27:30 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Fri, 2 Nov 2007 17:28:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 2 Nov 2007 17:28:40 +0100 Message-ID: <2E17595838F96949AB1F0FD9A8EC5ED00B99BF@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Vancouver meeting slots Thread-Index: AcgdbU9+2ZQLFrNRQ4+uTcDBgey5cQAABIAw From: "BOCCI Matthew" To: X-OriginalArrivalTime: 02 Nov 2007 16:28:42.0007 (UTC) FILETIME=[6E59AA70:01C81D6D] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: pwe3-chairs@ietf.org Subject: [PWE3] FW: Vancouver meeting slots X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0498786825==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0498786825== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C81D6D.6E3E90F8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C81D6D.6E3E90F8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > All, >=20 > Please can you send requests for a slot at the next PWE3 meeting to me > by Monday 19th November. >=20 > Please also include a summary of what you want to talk about, and a > pointer to the draft, if any. >=20 > Best regards, >=20 > Matthew ------_=_NextPart_001_01C81D6D.6E3E90F8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FW: Vancouver meeting slots

All,

Please can you send requests for a slot = at the next PWE3 meeting to me by Monday 19th November.

Please also include a summary of what = you want to talk about, and a pointer to the draft, if any.

Best regards,

Matthew

------_=_NextPart_001_01C81D6D.6E3E90F8-- --===============0498786825== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0498786825==-- From pwe3-bounces@ietf.org Sun Nov 04 15:09:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IolmB-0001iH-F3; Sun, 04 Nov 2007 15:08:55 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IolmA-0001f1-HK for pwe3-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 15:08:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IolmA-0001ej-7U for pwe3@ietf.org; Sun, 04 Nov 2007 15:08:54 -0500 Received: from smtp.testbed.se ([80.86.78.228] helo=fw.testbed.se) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iolm8-0001Xj-VX for pwe3@ietf.org; Sun, 04 Nov 2007 15:08:54 -0500 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1Iolm8-0002Ca-4p for pwe3@ietf.org; Sun, 04 Nov 2007 21:08:52 +0100 Received: from h241n2fls33o874.telia.com ([213.66.47.241]:61441 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1Iolm5-0002CJ-LL; Sun, 04 Nov 2007 21:08:49 +0100 Message-ID: <472E26BC.40207@pi.se> Date: Sun, 04 Nov 2007 21:08:28 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Iesg (E-mail)" , mpls@ietf.org, pwe3 , ccamp X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A0B0204.472E25C4.01C2,ss=1,fgs=0 X-cff-SpamScore: 0(/) X-cff-SpamReport: ----- ----- Message is unknown to the spam scanner. X-cff-LastScanner: footer X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: IAB , Thomas Walsh , Dinesh Mohan , "Matthew Bocci \(IETF\)" , Deborah Brungard , Stewart Bryant Subject: [PWE3] The IETF t-mpls design team X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The IAB has decided to appoint the following design team: - Loa Andersson - Matthew Bocci - Deborah Brungard - Stewart Bryant - Ross Callon - Dinesh Mohan - Tom Nadeau - Tom Walsh to address issues in preparation of the potential cooperation between IETF and ITU-T on protocols for t-mpls. The design team will further discuss its charter and coordinate it with IAB as necessary; a tentative design team is: o Identifying an action list for the IETF o Identifying incompatibles and inconsistencies between IETF and ITU-T documents o IETF decisions to be revisited o organization to take care of ITU-T mpls/pwe3 requirements On behalf of the IAB /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 07 00:48:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipdm5-0002aQ-Kb; Wed, 07 Nov 2007 00:48:25 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Ipdm4-0002a3-Iq for pwe3-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 00:48:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipdm4-0002Zn-8A for pwe3@ietf.org; Wed, 07 Nov 2007 00:48:24 -0500 Received: from mxa6.qos.net.il ([80.74.96.6] helo=mx5a1.qos.net.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipdlv-0001cB-Q5 for pwe3@ietf.org; Wed, 07 Nov 2007 00:48:23 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx5a1.qos.net.il (Postfix) with ESMTP id 3870C34EC4D for ; Wed, 7 Nov 2007 07:45:18 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 7 Nov 2007 07:47:14 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-pwe3-tdm-control-protocol-extensi-04: Summary issues raised during the WG LC Thread-Index: AcghAaXEBYKcyhgrSui90ja8BHmWAg== From: "Sasha Vainshtein" To: "pwe3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 419681661a5a61835a9a79996a04e3e9 Cc: Danny McPherson , Carlos Pignataro , Yaakov Stein , stbryant@cisco.com Subject: [PWE3] draft-ietf-pwe3-tdm-control-protocol-extensi-04: Summary issues raised during the WG LC X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1198106138==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1198106138== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82101.CF29EF58" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82101.CF29EF58 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, In the wake of the WG LC, Stewart and Carlos have sent their comments on the -04 version of the draft in question to the list.=20 No other comments have been received. =20 We've hold an off-the-list discussion of the issues raised that has helped to clarify the issues and agree on their resolution in the -05 version of the draft. A (rather long) summary of this discussion can be found below. ________________________________ ISSUE:=20 Mention MPLS in the title and abstract to match exclusion of L2TPv3. PROPOSED RESOLUTION: Accepted. New title:=20 Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks New abstract:=20 This document defines extension to the PWE3 control protocol [RFC4447]=20 and PWE3 IANA allocations [RFC4446] required for setup of =20 TDM pseudo wires in MPLS networks. =09 ________________________________ ISSUE: Usage of the PW Status messages for carrying the status of Attachment Circuits of TDM PWs is NOT RECOMMENDED. This may end in conflict with known proposals to use these messages for PW protection. PROPOSED RESOLUTION: Leave the text "as is". AUTHORS' REASONING: The status of the ACs is adequately carried across the PSN by the flags in the TDM PW Control Word. Having two different mechanisms to carry this across can only result in racing.=20 At the same time, the PW protection mechanisms proposed in draft-muley-dutta-pwe3-redundancy-bit-01.txt and/ or draft-muley-pwe3-redundancy-01.txt require some dual-homing protocol on Attachment Circuits. There is no such protocol for TDM ACs. ________________________________ ISSUE: TDM PW type values are explicitly listed in the text in spite of being already listed in the appropriate IANA registry. Looks like an opportunity for errors. PROPOSED RESOLUTION: Leave the text "as is". AUTHORS' REASONING: Simplifies reading of the document by the implementers. And the check vs. the registry must be only done once. ________________________________ ISSUE: CEP/TDM Payload Bytes parameter is described as being used with all SAToP and CESoPSN PWs. Suggestion to say "for all except TDMoIP". =20 PROPOSED RESOLUTION: =09 Leave the text "as is". AUTHORS' REASONING: =09 There are two different TDMoIP PW types; and positive thinking looks preferable to the authors. ________________________________ ISSUE: Presence of some interface parameters is defined as OPTIONAL, and default values of these parameters (as defined in the appropriate encapsulation documents) must be assumed if they are omitted. While this definitely would work, it looks like more complicated code vs. less bytes sent during setup... PROPOSED RESOLUTION: Leave the text "as is". AUTHORS' REASONING: 1.=09 This is compatible with the existing implementations and with the approved MFA 8.0.0 IA. 2.=09 The PE that sends the PW label mapping message is not prevented from including all the interface parameters, so there is no additional complexity here. The PE that receives this message can initialize all the interface parameters to defaults and then update them from the actual values found in the received message (that you do not find there, you do not update). This looks as a healthy approach in any case and at least as simple as checking for presence of all the parameters.=20 ________________________________ ISSUE: A clearer way to say that "a TDM PW encapsulation MUST either use or not use RTP in both directions" is required. PROPOSED RESOLUTION: Accepted. =20 Alternative text: Use or non-use of RTP MUST match in the two directions.=20 ________________________________ ISSUE: =09 Add a reference to RFC 4446 in the Security Considerations section to say that it is the same =20 PROPOSED RESOLUTION: =09 Accepted. But it probably should 4447. Modified text: =09 This draft does not have any additional impact on security of PWs above=20 that of basic LDP setup of PWs as defined in [RFC4447]. ________________________________ ISSUE:=20 =09 Add (and use) an Informative Reference to draft-ietf-l2tpext-tdm-xx PROPOSED RESOLUTION: =09 Leave the references "as is" in this draft, but include a reference to this draft in draft-ietf-l2tpext-tdm-xx ________________________________ ISSUE: =09 If possible, explain the reasons for skipping some values in the enumerations for such parameters as TDMoIP AAL1 mode and TDMoIP AAL2 Option. =20 PROPOSED RESOLUTION: Leave "as is" (no special reasons, this is how it has been implemented).=20 ________________________________ ISSUE: Is it the need to specify AAL2 encoding types and, in the case of G.711 encoding, A-law or mu-law? PROPOSED RESOLUTION: No need to specify A-law or mu-law, and specific encoding are out of scope; the two sides MUST agree on them.=20 Modified text: Encoding specifies native signal processing performed on the payload. When no native signal processing is performed (i.e. G.711 encoding) this field MUST be zero. Other specific values that can be used in this field are beyond the scope of this specification, but the two directions MUST match for the PW setup to succeed. ________________________________ ISSUE: Different names for different unused/reserved bit fields in the TDM Options structure (F and X). One name would suffice. PROPOSED RESOLUTION: Leave the text "as is". It is convenient for some implementations to treat these fields differently. ________________________________ ISSUE: The suggested Interface Parameter ID value for AAL1 options overlaps with a value already assigned in the IANA registry. PROPOSED RESOLUTION: Shift the suggested Interface Parameter ID values for AAL1 and AAL2 options to avoid the overlap. ________________________________ ISSUE: Length of some of the new Interface Parameters has not been defined. PROPOSED RESOLUTION: Add a new sub-section at the beginning of Section 3 listing all the relevant Interface Parameters with their IDs (assigned or suggested) and length. Remove the IDs from the sections describing the syntax and semantics of these parameters. ________________________________ =20 The -05 version of the draft that resolves all these issues and fixes a couple of typos will be submitted to the IETF later today. Meanwhile it can be found at: ftp://ftp.axerra.com/sasha/draft-ietf-pwe3-tdm-control-protocol-extensi- 05.txt =20 =20 Regards, Yaakov and Sasha ------_=_NextPart_001_01C82101.CF29EF58 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
In the = wake of the=20 WG LC, Stewart and Carlos have sent their comments on the -04 version of = the=20 draft in question to the list.
No = other comments=20 have been received.
 
We've = hold an=20 off-the-list discussion of the issues raised that has helped to clarify = the=20 issues and  agree on their resolution
in the = -05 version=20 of the draft. A (rather long) summary of this discussion = can be found=20 below.
ISSUE: 
Mention MPLS in=20 the title and abstract to match exclusion of=20 L2TPv3.
PROPOSED=20 RESOLUTION:
Accepted.
New=20 title:
Control Protocol=20 Extensions for Setup of TDM Pseudowires in = MPLS=20 Networks
New abstract: =
This = document=20 defines extension to the PWE3 control protocol [RFC4447]
 and = PWE3=20 IANA allocations [RFC4446] required for setup of 
 TDM = pseudo=20 wires in MPLS=20 networks.
ISSUE:
Usage of the PW=20 Status messages for carrying the status of Attachment Circuits of = TDM PWs=20 is NOT RECOMMENDED. This may end in conflict with known proposals = to=20 use these messages for PW = protection.
PROPOSED=20 RESOLUTION:
Leave the text "as=20 is".
AUTHORS'=20 REASONING:
The status of the ACs is adequately carried = across=20 the PSN by the flags in the TDM PW Control Word. Having two different=20 mechanisms to carry this across can only result in racing.=20
At the same time, the PW protection = mechanisms=20 proposed in draft-muley-dutta-pwe3-redundancy-bit-01.txt and/ or=20 draft-muley-pwe3-redundancy-01.txt require some dual-homing protocol = on=20 Attachment Circuits. There is no such protocol for TDM=20 ACs.
ISSUE:
TDM = PW type values=20 are explicitly listed in the text in spite of being already listed in = the=20 appropriate IANA registry. Looks like an opportunity for=20 errors.
PROPOSED=20 RESOLUTION:
Leave the text "as=20 is".
AUTHORS'=20 REASONING:
Simplifies reading of the document by the=20 implementers. And the check vs. the registry must be only done=20 once.
ISSUE:
CEP/TDM=20 Payload Bytes parameter is described as being used with all SAToP and = CESoPSN=20 PWs. Suggestion to say "for all except = TDMoIP".
 
PROPOSED=20 RESOLUTION:
Leave the text "as=20 is".
AUTHORS'=20 REASONING:
There are two different = TDMoIP PW types;=20 and positive thinking looks preferable to the=20 = authors.
ISSUE:
Presence of some interface parameters is defined = as=20 OPTIONAL, and default values of these parameters (as defined in the=20 appropriate encapsulation documents) must be assumed if they are = omitted.=20 While this definitely would work, it looks like more complicated code = vs. less=20 bytes sent during setup...
PROPOSED = RESOLUTION:
Leave the text "as=20 is".
AUTHORS' REASONING:
  1. This is=20 compatible with the existing implementations and with the approved = MFA 8.0.0=20 IA.
  2. The PE that sends the PW = label=20 mapping message is not prevented from including all the = interface=20 parameters, so there is no additional complexity here. The PE that=20 receives this message can initialize all the = interface=20 parameters to defaults and then update them from the actual values = found in=20 the received message (that you do not find there, you do not = update). This=20 looks as a healthy approach in any case and at least as simple as = checking=20 for presence of all the=20 parameters. 
ISSUE:
A clearer way to = say that=20 "a TDM PW encapsulation MUST either use or = not use=20 RTP in both directions" is=20 required.
PROPOSED = RESOLUTION:
Accepted.
 
=
Alternative = text:

Use or non-use of RTP MUST = match in=20 the two directions.=20

ISSUE:
Add a reference = to RFC 4446=20 in the Security Considerations section to say that it is the=20 same
 
PROPOSED=20 RESOLUTION:
Accepted. But it probably = should=20 4447.
Modified=20 text:
This draft does not have any = additional=20 impact on security of PWs above
 that of basic LDP setup of = PWs=20 as defined in=20 = [RFC4447].
ISSUE:
Add = (and use) an=20 Informative Reference to=20 draft-ietf-l2tpext-tdm-xx
PROPOSED=20 RESOLUTION:
Leave the = references "as is" in=20 this draft, but include a reference to this draft in=20 = draft-ietf-l2tpext-tdm-xx
<= SPAN=20 class=3D046170111-30102007>
ISSUE:
If = possible, explain=20 the reasons for skipping some values in the enumerations for such = parameters=20 as  TDMoIP AAL1 mode and TDMoIP AAL2 = Option.=20 =  
PROPOSED = RESOLUTION:
Leave "as is" (no special = reasons, this=20 is how it has been implemented).=20 =
ISSUE:
Is it = the need to=20 specify AAL2 encoding = types and, in=20 the case of G.711 encoding, A-law or=20 mu-law?
PROPOSED=20 RESOLUTION:
No need to specify A-law or mu-law, and specific encoding are = out of=20 scope; the two = sides MUST  agree on them.
Modified=20 text:
Encoding = specifies native=20 signal processing performed on the payload. When no native signal = processing=20 is performed (i.e. G.711 encoding) this field MUST be zero. Other specific values that can be used in this = field are=20 beyond the scope of this specification, but the two directions MUST = match for=20 the PW setup to=20 = succeed.
ISSUE:
Different names for different unused/reserved bit fields in = the TDM=20 Options structure (F and X). One name would=20 suffice.
PROPOSED=20 RESOLUTION:
Leave the=20 text "as is".  It is convenient for some implementations to treat = these=20 fields=20 differently.
=
ISSUE:
The suggested Interface Parameter ID value for AAL1 options = overlaps=20 with a value already assigned in the IANA=20 registry.
PROPOSED=20 RESOLUTION:
Shift = the suggested=20 Interface Parameter ID values for AAL1 and AAL2 options to avoid the=20 overlap.
ISSUE:
Length = of some of the=20 new Interface Parameters has not been=20 defined.
PROPOSED=20 RESOLUTION:
Add a new = sub-section at the=20 beginning of Section 3 listing all the relevant Interface = Parameters with=20 their IDs (assigned or suggested) and length. Remove the IDs from = the=20 sections describing the syntax and semantics of these=20 parameters.
 
The = -05 version of=20 the draft that resolves all these issues and fixes a couple of typos = will be=20 submitted to the IETF later today.
Meanwhile it can be=20 found at:
ftp://ftp.axerra.com/sasha/draft-ietf-pwe3-tdm-control-pro= tocol-extensi-05.txt
 
 
Regards,
       &nbs= p;     =20 Yaakov and Sasha
------_=_NextPart_001_01C82101.CF29EF58-- --===============1198106138== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1198106138==-- From pwe3-bounces@ietf.org Wed Nov 07 05:56:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpiaK-0006di-7p; Wed, 07 Nov 2007 05:56:36 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IpiaJ-0006dc-41 for pwe3-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 05:56:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpiaI-0006dQ-ND for pwe3@ietf.org; Wed, 07 Nov 2007 05:56:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpiaF-0002i1-Bg for pwe3@ietf.org; Wed, 07 Nov 2007 05:56:34 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 41AEB32899; Wed, 7 Nov 2007 10:56:01 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IpiZl-0004gw-5u; Wed, 07 Nov 2007 05:56:01 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: sasha@axerra.com From: IETF I-D Submission Tool Message-Id: Date: Wed, 07 Nov 2007 05:56:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yaakov_s@rad.com, pwe3@ietf.org Subject: [PWE3] New Version Notification for draft-ietf-pwe3-tdm-control-protocol-extensi-05 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org A new version of I-D, draft-ietf-pwe3-tdm-control-protocol-extensi-05.txt has been successfuly submitted by Sasha Vainshtein and posted to the IETF repository. Filename: draft-ietf-pwe3-tdm-control-protocol-extensi Revision: 05 Title: Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks Creation_date: 2007-11-07 WG ID: pwe3 Number_of_pages: 13 Abstract: This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. Vainshtein and Stein Standards Track [page 1] Control Protocol Extensions for TDM Pseudo wires November 2007 The IETF Secretariat. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 07 06:00:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpieC-0001Ny-Mr; Wed, 07 Nov 2007 06:00:36 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IpieB-0001Mp-EA for pwe3-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 06:00:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpieB-0001MG-3L; Wed, 07 Nov 2007 06:00:35 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipie7-0002rW-Rn; Wed, 07 Nov 2007 06:00:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id CD90332899; Wed, 7 Nov 2007 11:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ipidd-0001cN-Mi; Wed, 07 Nov 2007 06:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 07 Nov 2007 06:00:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-tdm-control-protocol-extensi-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks Author(s) : S. Vainshtein, Y. Stein Filename : draft-ietf-pwe3-tdm-control-protocol-extensi-05.txt Pages : 13 Date : 2007-11-07 This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. Vainshtein and Stein Standards Track [page 1] Control Protocol Extensions for TDM Pseudo wires November 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-control-protocol-extensi-05.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-control-protocol-extensi-05.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-control-protocol-extensi-05.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" Content-Type: text/plain Content-ID: <2007-11-07055559.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-tdm-control-protocol-extensi-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-tdm-control-protocol-extensi-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-07055559.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Fri Nov 09 04:02:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPlG-00053Z-Qe; Fri, 09 Nov 2007 04:02:46 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IqPlE-0004yK-Gq for pwe3-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 04:02:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqPlE-0004y2-5H for pwe3@ietf.org; Fri, 09 Nov 2007 04:02:44 -0500 Received: from smtp.testbed.se ([80.86.78.228] helo=fw.testbed.se) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqPlD-0002eK-Nl for pwe3@ietf.org; Fri, 09 Nov 2007 04:02:44 -0500 Received: from MailerDaemon by fw.testbed.se with local-bsmtp (Exim 4.63) (envelope-from ) id 1IqPlB-0004ys-OO for pwe3@ietf.org; Fri, 09 Nov 2007 10:02:41 +0100 Received: from h241n2fls33o874.telia.com ([213.66.47.241]:62135 helo=[192.168.0.100]) by fw.testbed.se with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1IqPl5-0004xy-N4; Fri, 09 Nov 2007 10:02:35 +0100 Message-ID: <47342221.4070201@pi.se> Date: Fri, 09 Nov 2007 10:02:25 +0100 From: Loa Andersson Organization: Acreo AB User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Iesg (E-mail)" , mpls@ietf.org, pwe3 , ccamp References: <472E26BC.40207@pi.se> In-Reply-To: <472E26BC.40207@pi.se> X-Enigmail-Version: 0.95.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A0B0204.473420E6.004A,ss=1,fgs=0 X-cff-SpamScore: 0(/) X-cff-SpamReport: ----- ----- Message is unknown to the spam scanner. X-cff-LastScanner: footer X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: t-mpls-dt@testbed.se, IAB Subject: [PWE3] Re: The IETF t-mpls design team X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org All, I made one mistake in listing the dt-members, - Mark Townsley is also on the team. Apologies for this. /Loa Loa Andersson wrote: > The IAB has decided to appoint the following design team: > > - Loa Andersson > - Matthew Bocci > - Deborah Brungard > - Stewart Bryant > - Ross Callon > - Dinesh Mohan > - Tom Nadeau > - Tom Walsh > > to address issues in preparation of the potential cooperation > between IETF and ITU-T on protocols for t-mpls. > > The design team will further discuss its charter and coordinate > it with IAB as necessary; a tentative design team is: > > o Identifying an action list for the IETF > o Identifying incompatibles and inconsistencies between IETF > and ITU-T documents > o IETF decisions to be revisited > o organization to take care of ITU-T mpls/pwe3 requirements > > > On behalf of the IAB > > /Loa > > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se This email was Anti Virus checked by Astaro Security Gateway. http://www.astaro.com _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Nov 09 14:26:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZV4-0000YN-SU; Fri, 09 Nov 2007 14:26:42 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IqZV4-0000Tr-7u for pwe3-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:26:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZV2-0000R9-MF for pwe3@ietf.org; Fri, 09 Nov 2007 14:26:41 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqZV2-0000NF-EV for pwe3@ietf.org; Fri, 09 Nov 2007 14:26:40 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns3.neustar.com (Postfix) with ESMTP id 1299E175AD; Fri, 9 Nov 2007 19:26:10 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IqZUX-0008PF-Ja; Fri, 09 Nov 2007 14:26:09 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: cpignata@cisco.com From: IETF I-D Submission Tool Message-Id: Date: Fri, 09 Nov 2007 14:26:09 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: pwe3@ietf.org, thomas.nadeau@bt.com Subject: [PWE3] New Version Notification for draft-ietf-pwe3-vccv-bfd-00 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org A new version of I-D, draft-ietf-pwe3-vccv-bfd-00.txt has been successfuly submitted by Carlos Pignataro and posted to the IETF repository. Filename: draft-ietf-pwe3-vccv-bfd Revision: 00 Title: Bi-directional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) Creation_date: 2007-11-09 WG ID: pwe3 Number_of_pages: 12 Abstract: This document describes new Connectivity Verification (CV) types for using Bi-directional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. The IETF Secretariat. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Nov 09 14:30:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZYN-0005t6-QU; Fri, 09 Nov 2007 14:30:07 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IqZYM-0005rA-9y for pwe3-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:30:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZYL-0005mW-PV; Fri, 09 Nov 2007 14:30:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZYI-0003Xm-6f; Fri, 09 Nov 2007 14:30:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 2B1D532899; Fri, 9 Nov 2007 19:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqZYI-0006Gn-2j; Fri, 09 Nov 2007 14:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 09 Nov 2007 14:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-vccv-bfd-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Bi-directional Forwarding Detection (BFD) for the Pseudowire Virtual Circuit Connectivity Verification (VCCV) Author(s) : T. Nadeau, C. Pignataro Filename : draft-ietf-pwe3-vccv-bfd-00.txt Pages : 12 Date : 2007-11-09 This document describes new Connectivity Verification (CV) types for using Bi-directional Forwarding Detection (BFD) with Virtual Circuit Connectivity Verification (VCCV). VCCV provides a control channel that is associated with a Pseudowire (PW), as well as the corresponding operations and management functions such as connectivity verification to be used over that control channel. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-vccv-bfd-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-vccv-bfd-00.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-vccv-bfd-00.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" Content-Type: text/plain Content-ID: <2007-11-09142607.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-vccv-bfd-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-vccv-bfd-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-09142607.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Nov 14 00:16:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAbj-0007lU-9U; Wed, 14 Nov 2007 00:16:11 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsAbh-0007gx-B5 for pwe3-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 00:16:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAbf-0007fZ-Uy for pwe3@ietf.org; Wed, 14 Nov 2007 00:16:08 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsAbf-0005I3-PE for pwe3@ietf.org; Wed, 14 Nov 2007 00:16:07 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 9BA9B26E85; Wed, 14 Nov 2007 05:16:07 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IsAbf-0000Zl-HZ; Wed, 14 Nov 2007 00:16:07 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: sasha@axerra.com From: IETF I-D Submission Tool Message-Id: Date: Wed, 14 Nov 2007 00:16:07 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: yaakov_s@rad.com, pwe3@ietf.org Subject: [PWE3] New Version Notification for draft-ietf-pwe3-tdm-control-protocol-extensi-06 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org A new version of I-D, draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt has been successfuly submitted by Sasha Vainshtein and posted to the IETF repository. Filename: draft-ietf-pwe3-tdm-control-protocol-extensi Revision: 06 Title: Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks Creation_date: 2007-11-13 WG ID: pwe3 Number_of_pages: 13 Abstract: This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. Vainshtein and Stein Standards Track [page 1] Control Protocol Extensions for TDM Pseudo wires November 2007 The IETF Secretariat. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 14 00:20:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAfV-0004S3-Lo; Wed, 14 Nov 2007 00:20:05 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsAfU-0004Ov-3J for pwe3-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 00:20:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAfT-0004Om-IN; Wed, 14 Nov 2007 00:20:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsAfT-0002vY-6k; Wed, 14 Nov 2007 00:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id C6CA0175DF; Wed, 14 Nov 2007 05:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsAfS-0004At-9I; Wed, 14 Nov 2007 00:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Nov 2007 00:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks Author(s) : S. Vainshtein, Y. Stein Filename : draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt Pages : 13 Date : 2007-11-14 This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks. Vainshtein and Stein Standards Track [page 1] Control Protocol Extensions for TDM Pseudo wires November 2007 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-control-protocol-extensi-06.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-control-protocol-extensi-06.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" Content-Type: text/plain Content-ID: <2007-11-14001605.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-14001605.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Nov 14 00:21:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAgZ-0005rU-5f; Wed, 14 Nov 2007 00:21:11 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsAgY-0005rP-IW for pwe3-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 00:21:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsAgY-0005rH-7t for pwe3@ietf.org; Wed, 14 Nov 2007 00:21:10 -0500 Received: from mxa6.qos.net.il ([80.74.96.6] helo=mx5a1.qos.net.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsAgX-0002yn-PR for pwe3@ietf.org; Wed, 14 Nov 2007 00:21:10 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx5a1.qos.net.il (Postfix) with ESMTP id 8AD6C8A207 for ; Wed, 14 Nov 2007 07:18:17 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 14 Nov 2007 07:20:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-pwe3-tdm-control-protocol-extensi-06 Thread-Index: AcgmfYzcUWf4+JPMS3Wn0v9EMKgfAwAABcMQ From: "Sasha Vainshtein" To: "pwe3" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Carlos Pignataro , Yaakov Stein , stbryant@cisco.com Subject: [PWE3] FW: New Version Notification for draft-ietf-pwe3-tdm-control-protocol-extensi-06 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi all, This posting fixes a typo that has been only noticed=20 after the -05 version has been posted regarding values of the Payload Bytes attribute: -05 version: The specified value P MUST be an integer factor of N,=20 -06 version: The specified value P MUST be an integer multiple of N,=20 Apologies and best regards, Sasha -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Wednesday, November 14, 2007 7:16 AM To: Sasha Vainshtein Cc: pwe3@ietf.org; yaakov_s@rad.com Subject: New Version Notification for draft-ietf-pwe3-tdm-control-protocol-extensi-06=20 A new version of I-D, draft-ietf-pwe3-tdm-control-protocol-extensi-06.txt has been successfuly submitted by Sasha Vainshtein and posted to the IETF repository. Filename: draft-ietf-pwe3-tdm-control-protocol-extensi Revision: 06 Title: Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks Creation_date: 2007-11-13 WG ID: pwe3 Number_of_pages: 13 Abstract: This document defines extension to the PWE3 control protocol [RFC4447] and PWE3 IANA allocations [RFC4446] required for setup of TDM pseudowires in MPLS networks.=20 =20 Vainshtein and Stein Standards Track [page 1] =20 Control Protocol Extensions for TDM Pseudo wires November 2007 =20 The IETF Secretariat. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Thu Nov 15 04:02:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsacP-0001ht-Pn; Thu, 15 Nov 2007 04:02:37 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsacO-0001g2-EW for pwe3-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 04:02:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsacO-0001fr-0n for pwe3@ietf.org; Thu, 15 Nov 2007 04:02:36 -0500 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsacK-0002t5-W6 for pwe3@ietf.org; Thu, 15 Nov 2007 04:02:35 -0500 Received: from E03MVB2-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 09:02:31 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Nov 2007 09:02:26 -0000 Message-ID: <2ECAA42C79676B42AEBAC11229CA7D0C0167F79B@E03MVB2-UKBR.domain1.systemhost.net> In-Reply-To: <353299.8317.qm@web50005.mail.re2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: E1 Framing question Thread-Index: AcgnU8YOOXTS3EqMRxaT7BiL176aGgAEdDUA From: To: , , X-OriginalArrivalTime: 15 Nov 2007 09:02:31.0340 (UTC) FILETIME=[4128CEC0:01C82766] X-Spam-Score: -1.0 (-) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: Subject: [PWE3] RE: E1 Framing question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1745046963==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1745046963== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82766.40A2212A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82766.40A2212A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, =20 I'd need more information on this to try and answer properly. The key issue is what does the intervening equipment allow to pass transparently? If you want to pursue further I suggest we take this off-line wrt PWE3. =20 regards, Neil -----Original Message----- From: JimRoberts [mailto:jr@askonce.net]=20 Sent: 15 November 2007 06:50 To: pwe3@ietf.org; akiva@AXERRA.com; Harrison,N,Neil,DMN R Subject: E1 Framing question Gentlemen =20 >From this URL http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html =20 I was researching E1 Framing on a Sprint International Private Line going from Portland Oregon to Costa Rica and the effect of taking the framed circuit and passing it through the DACS equipment of the local LEC in Costa Rica which does not support framing and I came across a correspondence you were involved in several years ago. =20 I would very much value your opinion on whether this is a possiblity, ie can framing bits pass through to a CPE device when the local LEC in Costa Rica does not frame the incoming framed E1 from Sprint when they send it out towards the customer equipment. =20 Your input would be very much appreciated. =20 Jim Roberts - President Ask Once Communications Inc. 3402 NE 98th Ave. Building # 2=20 Vancouver, WA 98662=20 360-883-1800 voice=20 360-883-1888 fax 360-921-8383 Mobile=20 jr@askonce.net www.askonce.net =20 All correspondence contained in this e-mail is considered confidential. If you have received this e-mail in error please delete it immediately. Thank you. ------_=_NextPart_001_01C82766.40A2212A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Jim,
 
I'd need more information on this to try and answer = properly.  The=20 key issue is what does the intervening equipment allow to pass=20 transparently?  If you want to pursue further I suggest we take = this=20 off-line wrt PWE3.
 
regards, Neil
-----Original Message-----
From: = JimRoberts=20 [mailto:jr@askonce.net]
Sent: 15 November 2007 = 06:50
To:=20 pwe3@ietf.org; akiva@AXERRA.com; Harrison,N,Neil,DMN = R
Subject: E1=20 Framing question

Gentlemen
 
From this URL  http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html
 
I was researching E1 Framing on a Sprint International Private = Line going=20 from Portland Oregon to Costa Rica and the effect of taking the framed = circuit=20 and passing it through the DACS equipment of the local LEC in Costa = Rica which=20 does not support framing and I came across a correspondence you were = involved=20 in several years ago.
 
I would very much value your opinion on whether this is a = possiblity, ie=20 can framing bits pass through to a CPE device when the local LEC in = Costa Rica=20 does not frame the incoming framed E1 from Sprint when they send it = out=20 towards the customer equipment.
 
Your input would be very much appreciated.
 


Jim Roberts - President
Ask Once Communications=20 Inc.
3402 NE 98th Ave.  Building # 2
Vancouver, WA 98662=20
360-883-1800 voice
360-883-1888 fax
360-921-8383 Mobile 
jr@askonce.net
www.askonce.net
 
All correspondence contained in this = e-mail is=20 considered
confidential.  If you have = received this=20 e-mail in error
please delete it immediately.  = Thank=20 = you.
= ------_=_NextPart_001_01C82766.40A2212A-- --===============1745046963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1745046963==-- From pwe3-bounces@ietf.org Thu Nov 15 04:32:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isb5V-0000G6-Ug; Thu, 15 Nov 2007 04:32:41 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsYpK-00047X-8E for pwe3-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 02:07:50 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsYpJ-00045c-TL for pwe3@ietf.org; Thu, 15 Nov 2007 02:07:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsYYH-0002VG-Cw for pwe3@ietf.org; Thu, 15 Nov 2007 01:50:13 -0500 Received: from web50005.mail.re2.yahoo.com ([206.190.38.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IsYYG-0004ab-UD for pwe3@ietf.org; Thu, 15 Nov 2007 01:50:13 -0500 Received: (qmail 10782 invoked by uid 60001); 15 Nov 2007 06:50:12 -0000 X-YMail-OSG: MYbGUWUVM1m3JhSpnt.XJACA_LpauUUqhgu6snD7JMyF7I8dWs3k5AZIWzZwC8L7eTtNDgsuaXqjhfU4uIbF3P1OORZ31tyyx8krDEONsnKGk8plvlR.I3DVcxZuwHslThN_DR0XgZ1VNRQ- Received: from [67.160.142.250] by web50005.mail.re2.yahoo.com via HTTP; Wed, 14 Nov 2007 22:50:12 PST X-RocketYMMF: askonce1 Date: Wed, 14 Nov 2007 22:50:12 -0800 (PST) From: JimRoberts To: pwe3@ietf.org, akiva@AXERRA.com, neil.2.harrison@bt.com MIME-Version: 1.0 Message-ID: <353299.8317.qm@web50005.mail.re2.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-TMDA-Confirmed: Thu, 15 Nov 2007 02:07:49 -0500 X-Mailman-Approved-At: Thu, 15 Nov 2007 04:32:40 -0500 Cc: Subject: [PWE3] E1 Framing question X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jr@askonce.net List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1249191302==" Errors-To: pwe3-bounces@ietf.org --===============1249191302== Content-Type: multipart/alternative; boundary="0-1967478731-1195109412=:8317" Content-Transfer-Encoding: 8bit --0-1967478731-1195109412=:8317 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Gentlemen From this URL http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html I was researching E1 Framing on a Sprint International Private Line going from Portland Oregon to Costa Rica and the effect of taking the framed circuit and passing it through the DACS equipment of the local LEC in Costa Rica which does not support framing and I came across a correspondence you were involved in several years ago. I would very much value your opinion on whether this is a possiblity, ie can framing bits pass through to a CPE device when the local LEC in Costa Rica does not frame the incoming framed E1 from Sprint when they send it out towards the customer equipment. Your input would be very much appreciated. Jim Roberts - President Ask Once Communications Inc. 3402 NE 98th Ave. Building # 2 Vancouver, WA 98662 360-883-1800 voice 360-883-1888 fax 360-921-8383 Mobile jr@askonce.net www.askonce.net All correspondence contained in this e-mail is considered confidential. If you have received this e-mail in error please delete it immediately. Thank you. --0-1967478731-1195109412=:8317 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Gentlemen
 
 
I was researching E1 Framing on a Sprint International Private Line going from Portland Oregon to Costa Rica and the effect of taking the framed circuit and passing it through the DACS equipment of the local LEC in Costa Rica which does not support framing and I came across a correspondence you were involved in several years ago.
 
I would very much value your opinion on whether this is a possiblity, ie can framing bits pass through to a CPE device when the local LEC in Costa Rica does not frame the incoming framed E1 from Sprint when they send it out towards the customer equipment.
 
Your input would be very much appreciated.
 


Jim Roberts - President
Ask Once Communications Inc.
3402 NE 98th Ave.  Building # 2
Vancouver, WA 98662
360-883-1800 voice
360-883-1888 fax
360-921-8383 Mobile 
www.askonce.net
 
All correspondence contained in this e-mail is considered
confidential.  If you have received this e-mail in error
please delete it immediately.  Thank you.
--0-1967478731-1195109412=:8317-- --===============1249191302== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1249191302==-- From pwe3-bounces@ietf.org Thu Nov 15 04:40:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsbCq-0005vt-3n; Thu, 15 Nov 2007 04:40:16 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsbCo-0005uB-Vs for pwe3-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 04:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsbCo-0005ts-KY for pwe3@ietf.org; Thu, 15 Nov 2007 04:40:14 -0500 Received: from [212.199.240.16] (helo=antivir2.rad.co.il) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsbCj-0004DO-Tl for pwe3@ietf.org; Thu, 15 Nov 2007 04:40:14 -0500 Received: from exrad3.ad.rad.co.il ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 15 Nov 2007 11:40:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] E1 Framing question Date: Thu, 15 Nov 2007 11:40:05 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D05933CDF@exrad3.ad.rad.co.il> In-Reply-To: <353299.8317.qm@web50005.mail.re2.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] E1 Framing question Thread-Index: AcgnaoYf0+es2vPIRXil8NVSE0CWUgAALwIQ From: "Yaakov Stein" To: , , , X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2127206035==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============2127206035== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8276B.80818B5A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8276B.80818B5A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim =20 If your link is structure agnostic (as you imply by saying that you have an unframed interface and a private line) then all bits will pass through unchanged. =20 Y(J)S ________________________________ From: JimRoberts [mailto:jr@askonce.net]=20 Sent: Thursday, November 15, 2007 8:50 AM To: pwe3@ietf.org; akiva@AXERRA.com; neil.2.harrison@bt.com Subject: [PWE3] E1 Framing question Gentlemen =20 >From this URL http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html =20 I was researching E1 Framing on a Sprint International Private Line going from Portland Oregon to Costa Rica and the effect of taking the framed circuit and passing it through the DACS equipment of the local LEC in Costa Rica which does not support framing and I came across a correspondence you were involved in several years ago. =20 I would very much value your opinion on whether this is a possiblity, ie can framing bits pass through to a CPE device when the local LEC in Costa Rica does not frame the incoming framed E1 from Sprint when they send it out towards the customer equipment. =20 Your input would be very much appreciated. =20 Jim Roberts - President Ask Once Communications Inc. 3402 NE 98th Ave. Building # 2=20 Vancouver, WA 98662=20 360-883-1800 voice=20 360-883-1888 fax 360-921-8383 Mobile=20 jr@askonce.net www.askonce.net =20 All correspondence contained in this e-mail is considered confidential. If you have received this e-mail in error please delete it immediately. Thank you. ------_=_NextPart_001_01C8276B.80818B5A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jim
 
If=20 your link is structure agnostic (as you imply by saying that you have an = unframed interface
and a=20 private line) then all bits will pass through = unchanged.
 
Y(J)S

From: JimRoberts = [mailto:jr@askonce.net]=20
Sent: Thursday, November 15, 2007 8:50 AM
To:=20 pwe3@ietf.org; akiva@AXERRA.com; = neil.2.harrison@bt.com
Subject:=20 [PWE3] E1 Framing question

Gentlemen
 
From this URL  http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html
 
I was researching E1 Framing on a Sprint International Private Line = going=20 from Portland Oregon to Costa Rica and the effect of taking the framed = circuit=20 and passing it through the DACS equipment of the local LEC in Costa Rica = which=20 does not support framing and I came across a correspondence you were = involved in=20 several years ago.
 
I would very much value your opinion on whether this is a = possiblity, ie=20 can framing bits pass through to a CPE device when the local LEC in = Costa Rica=20 does not frame the incoming framed E1 from Sprint when they send it out = towards=20 the customer equipment.
 
Your input would be very much appreciated.
 


Jim Roberts - President
Ask Once Communications=20 Inc.
3402 NE 98th Ave.  Building # 2
Vancouver, WA 98662=20
360-883-1800 voice
360-883-1888 fax
360-921-8383 Mobile 
jr@askonce.net
www.askonce.net
 
All correspondence contained in this = e-mail is=20 considered
confidential.  If you have = received this=20 e-mail in error
please delete it immediately.  = Thank=20 you.
------_=_NextPart_001_01C8276B.80818B5A-- --===============2127206035== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============2127206035==-- From pwe3-bounces@ietf.org Thu Nov 15 04:52:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsbOx-0005jx-BT; Thu, 15 Nov 2007 04:52:47 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IsbOv-0005fk-CR for pwe3-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 04:52:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsbOv-0005fc-0l for pwe3@ietf.org; Thu, 15 Nov 2007 04:52:45 -0500 Received: from mxa5.qos.net.il ([80.74.96.15] helo=mxa6.qos.net.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsbOt-0003Rn-U0 for pwe3@ietf.org; Thu, 15 Nov 2007 04:52:44 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mxa6.qos.net.il (Postfix) with ESMTP id 9FBC16E008D for ; Thu, 15 Nov 2007 11:00:47 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] RE: E1 Framing question Date: Thu, 15 Nov 2007 11:51:04 +0200 Message-ID: In-Reply-To: <2ECAA42C79676B42AEBAC11229CA7D0C0167F79B@E03MVB2-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] RE: E1 Framing question Thread-Index: AcgnU8YOOXTS3EqMRxaT7BiL176aGgAEdDUAAAHRGoA= From: "Sasha Vainshtein" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: akivas@scopus.net X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1198375818==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1198375818== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8276D.2DF18782" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8276D.2DF18782 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Neil, Jim and all, Akiva Sadovsky can be reached atakivas@scopus.net =20 Regards, Sasha ________________________________ From: neil.2.harrison@bt.com [mailto:neil.2.harrison@bt.com]=20 Sent: Thursday, November 15, 2007 11:02 AM To: jr@askonce.net; pwe3@ietf.org; akiva@AXERRA.com Subject: [PWE3] RE: E1 Framing question Jim, =20 I'd need more information on this to try and answer properly. The key issue is what does the intervening equipment allow to pass transparently? If you want to pursue further I suggest we take this off-line wrt PWE3. =20 regards, Neil -----Original Message----- From: JimRoberts [mailto:jr@askonce.net]=20 Sent: 15 November 2007 06:50 To: pwe3@ietf.org; akiva@AXERRA.com; Harrison,N,Neil,DMN R Subject: E1 Framing question =09 =09 Gentlemen =20 From this URL http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html =20 I was researching E1 Framing on a Sprint International Private Line going from Portland Oregon to Costa Rica and the effect of taking the framed circuit and passing it through the DACS equipment of the local LEC in Costa Rica which does not support framing and I came across a correspondence you were involved in several years ago. =20 I would very much value your opinion on whether this is a possiblity, ie can framing bits pass through to a CPE device when the local LEC in Costa Rica does not frame the incoming framed E1 from Sprint when they send it out towards the customer equipment. =20 Your input would be very much appreciated. =20 Jim Roberts - President Ask Once Communications Inc. 3402 NE 98th Ave. Building # 2=20 Vancouver, WA 98662=20 360-883-1800 voice=20 360-883-1888 fax 360-921-8383 Mobile=20 =09 jr@askonce.net www.askonce.net =20 All correspondence contained in this e-mail is considered confidential. If you have received this e-mail in error please delete it immediately. Thank you. ------_=_NextPart_001_01C8276D.2DF18782 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
Neil, Jim and all,
Akiva Sadovsky can be reached = atakivas@scopus.net=
 
Regards,
       &nbs= p;            = ; =20 Sasha

From: neil.2.harrison@bt.com=20 [mailto:neil.2.harrison@bt.com]
Sent: Thursday, November 15, = 2007=20 11:02 AM
To: jr@askonce.net; pwe3@ietf.org;=20 akiva@AXERRA.com
Subject: [PWE3] RE: E1 Framing=20 question

Jim,
 
I'd need more information on this to try and answer = properly.  The=20 key issue is what does the intervening equipment allow to pass=20 transparently?  If you want to pursue further I suggest we take = this=20 off-line wrt PWE3.
 
regards, Neil
-----Original Message-----
From: = JimRoberts=20 [mailto:jr@askonce.net]
Sent: 15 November 2007 = 06:50
To:=20 pwe3@ietf.org; akiva@AXERRA.com; Harrison,N,Neil,DMN = R
Subject: E1=20 Framing question

Gentlemen
 
From this URL  http://www1.ietf.org/mail-archive/web/pwe3/current/msg02884.html
 
I was researching E1 Framing on a Sprint International Private = Line going=20 from Portland Oregon to Costa Rica and the effect of taking the framed = circuit=20 and passing it through the DACS equipment of the local LEC in Costa = Rica which=20 does not support framing and I came across a correspondence you were = involved=20 in several years ago.
 
I would very much value your opinion on whether this is a = possiblity, ie=20 can framing bits pass through to a CPE device when the local LEC in = Costa Rica=20 does not frame the incoming framed E1 from Sprint when they send it = out=20 towards the customer equipment.
 
Your input would be very much appreciated.
 


Jim Roberts - President
Ask Once Communications=20 Inc.
3402 NE 98th Ave.  Building # 2
Vancouver, WA 98662=20
360-883-1800 voice
360-883-1888 fax
360-921-8383 Mobile 
jr@askonce.net
www.askonce.net
 
All correspondence contained in this = e-mail is=20 considered
confidential.  If you have = received this=20 e-mail in error
please delete it immediately.  = Thank=20 = you.
= ------_=_NextPart_001_01C8276D.2DF18782-- --===============1198375818== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1198375818==-- From pwe3-bounces@ietf.org Fri Nov 16 00:16:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IstZ1-0004Xc-UP; Fri, 16 Nov 2007 00:16:23 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IstZ0-0004Tb-5J for pwe3-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 00:16:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IstYz-0004TR-QG for pwe3@ietf.org; Fri, 16 Nov 2007 00:16:21 -0500 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IstYz-0004CP-BU for pwe3@ietf.org; Fri, 16 Nov 2007 00:16:21 -0500 Received: by dog.tcb.net (Postfix, from userid 0) id 950092680BA; Thu, 15 Nov 2007 22:16:20 -0700 (MST) Received: from [172.20.2.234] (12.35.162.130 [12.35.162.130]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for pwe3@ietf.org; Thu, 15 Nov 2007 22:16:20 -0700 (MST) (envelope-from danny@tcb.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=12.35.162.130; client-port=56549; syn-fingerprint=65535:55:1:64:M1460,N,W0,N,N,T,S MacOS 10.4.8; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v752.3) References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2CEB7FBC-F088-4939-86FE-618E1E85E21E@tcb.net> Content-Transfer-Encoding: 7bit From: Danny McPherson Date: Thu, 15 Nov 2007 22:16:07 -0700 To: pwe3 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [PWE3] Fwd: Revised Internet-Drafts Submission Cutoff Dates for the 70th IETF Meeting in Vancouver, BC, Canada X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Begin forwarded message: > From: ietf-secretariat@ietf.org > Date: November 15, 2007 10:00:02 PM MST > To: ietf-announce@ietf.org > Cc: wgchairs@ietf.org > Subject: Revised Internet-Drafts Submission Cutoff Dates for the > 70th IETF Meeting in Vancouver, BC, Canada > > All revised Internet-Drafts (version -01 and higher) must be submitted > by Monday, November 19th at 9:00 AM ET (14:00 UTC/GMT). > > Revised Internet-Drafts received after the cutoff date will not be > made > available in the Internet-Drafts directory or announced until on or > after Monday, December 3rd at 9:00 AM ET (14:00 UTC/GMT), when > Internet-Draft posting > resumes. Please do not wait until the last minute to submit. > > The Secretariat encourages you to submit your Internet-Drafts via > the Internet-Draft > Submission Tool (IDST) https://datatracker.ietf.org/idst/upload.cgi. > If you are unable to do so, then you may still submit your Internet- > Drafts manually by > sending them to internet-drafts@ietf.org. If you are submitting a > version -00 WG draft that > replaces non-WG draft, then you must submit it manually as the > current IDST cannot handle > replacements. Please be sure to state that one draft replaces > another in the cover note that > accompanies your submission. Also, please note that the IDST will > not accept drafts > submitted after their respective cutoff dates. > > Thank you for your understanding and cooperation. If you have any > questions or concerns, then please send a message to > internet-drafts@ietf.org. > > The IETF Secretariat > > FYI: The Internet-Draft cutoff dates as well as other significant > dates > for the 70th IETF Meeting can be found at http://www.ietf.org/ > meetings/cutoff_dates_70.html. > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Sun Nov 18 09:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itkqc-0004cn-HP; Sun, 18 Nov 2007 09:10:06 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1ItkqZ-0004Z3-6h for pwe3-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 09:10:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItkqY-0004Yv-Q9; Sun, 18 Nov 2007 09:10:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItkqY-00009h-En; Sun, 18 Nov 2007 09:10:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 5FBD22AC75; Sun, 18 Nov 2007 14:10:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItkqY-0002g9-2n; Sun, 18 Nov 2007 09:10:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 09:10:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-pw-mib-13.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire (PW) Management Information Base (MIB) Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-pw-mib-13.txt Pages : 67 Date : 2007-11-18 This memo defines an experimental portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of Pseudowire Edge-to-Edge services carried over a general Packet Switched Network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-13.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-13.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" Content-Type: text/plain Content-ID: <2007-11-18090818.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18090818.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Sun Nov 18 09:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl0I-0003D1-Bi; Sun, 18 Nov 2007 09:20:06 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Itl0F-0003Cg-RV for pwe3-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 09:20:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl0F-0003CY-FE; Sun, 18 Nov 2007 09:20:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itl0F-0000Rz-3o; Sun, 18 Nov 2007 09:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id B2383175AB; Sun, 18 Nov 2007 14:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itl0E-0002pI-6y; Sun, 18 Nov 2007 09:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 09:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-pw-mpls-mib-13.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Pseudowire (PW) over MPLS PSN Management Information Base (MIB) Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-pw-mpls-mib-13.txt Pages : 32 Date : 2007-11-18 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes a MIB module for PW operation over Multi- Protocol Label Switching (MPLS) Label Switch Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-mpls-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-mpls-mib-13.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-mpls-mib-13.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" Content-Type: text/plain Content-ID: <2007-11-18091529.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-mpls-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-mpls-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18091529.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Sun Nov 18 09:20:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl0k-0003QQ-AH; Sun, 18 Nov 2007 09:20:34 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Itl0j-0003QH-8e for pwe3-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 09:20:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl0i-0003Q4-TC; Sun, 18 Nov 2007 09:20:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itl0i-0000T5-I1; Sun, 18 Nov 2007 09:20:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7600E2AC65; Sun, 18 Nov 2007 14:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itl0E-0002pL-7i; Sun, 18 Nov 2007 09:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 09:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-enet-mib-12.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Ethernet Pseudowire (PW) Management Information Base (MIB) Author(s) : D. Zelig, T. Nadeau Filename : draft-ietf-pwe3-enet-mib-12.txt Pages : 24 Date : 2007-11-18 This memo defines a 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 Ethernet Pseudowire (PW) services. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-enet-mib-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-enet-mib-12.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-enet-mib-12.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" Content-Type: text/plain Content-ID: <2007-11-18091929.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-enet-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-enet-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18091929.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Sun Nov 18 09:20:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl0r-0003d3-Kj; Sun, 18 Nov 2007 09:20:41 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Itl0l-0003Re-7b for pwe3-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 09:20:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itl0k-0003RL-Kw; Sun, 18 Nov 2007 09:20:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itl0i-0004kO-9M; Sun, 18 Nov 2007 09:20:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 4248A328E7; Sun, 18 Nov 2007 14:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itl0E-0002pD-5a; Sun, 18 Nov 2007 09:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 09:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-pw-tc-mib-13.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Definitions for Textual Conventions and for Managing Pseudowires over PSN Author(s) : T. Nadeau, et al. Filename : draft-ietf-pwe3-pw-tc-mib-13.txt Pages : 12 Date : 2007-11-18 This memo defines a Management Information Base (MIB) module which contains Textual Conventions (TCs) to represent commonly-used Pseudowire (PW) management information. The intent is that these TCs will be imported and used in PW-related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-pw-tc-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-13.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-13.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" Content-Type: text/plain Content-ID: <2007-11-18091209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-pw-tc-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-pw-tc-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18091209.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Sun Nov 18 12:30:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItnyH-0007QF-Kt; Sun, 18 Nov 2007 12:30:13 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Itny8-0007HX-V8 for pwe3-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 12:30:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itny8-0007HN-Ik; Sun, 18 Nov 2007 12:30:04 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itny6-0001UJ-7E; Sun, 18 Nov 2007 12:30:04 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 20D70328E7; Sun, 18 Nov 2007 17:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itny6-0003r2-04; Sun, 18 Nov 2007 12:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 12:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: pwe3@ietf.org Subject: [PWE3] I-D Action:draft-ietf-pwe3-cep-mib-11.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : SONET/SDH Circuit Emulation Service Over Packet (CEP) Management Information Base (MIB) Using SMIv2 Author(s) : D. Zelig, et al. Filename : draft-ietf-pwe3-cep-mib-11.txt Pages : 71 Date : 2007-11-18 This memo defines a 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 SONET/SDH circuits over a Packet Switch Network (PSN). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cep-mib-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-cep-mib-11.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-cep-mib-11.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" Content-Type: text/plain Content-ID: <2007-11-18122158.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-cep-mib-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-cep-mib-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18122158.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Mon Nov 19 15:15:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD20-0002vD-Hj; Mon, 19 Nov 2007 15:15:44 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IuD1p-0002hu-Qp for pwe3-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:15:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD1o-0002g6-JZ; Mon, 19 Nov 2007 15:15:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuD1o-0008Pn-6J; Mon, 19 Nov 2007 15:15:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 1BE012AC4F; Mon, 19 Nov 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuD1J-0003gd-SM; Mon, 19 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-segmented-pw-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Segmented Pseudo Wire Author(s) : L. Martini, et al. Filename : draft-ietf-pwe3-segmented-pw-06.txt Pages : 38 Date : 2007-11-19 This document describes how to connect pseudo wires (PW) between two distinct PW control planes or PSN domains. The PW control planes may belong to independent autonomous systems, or the PSN technology is heterogeneous, or a PW might need to be aggregated at a specific PSN point. The PW packet data units are simply switched from one PW to another without changing the PW payload. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-segmented-pw-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-segmented-pw-06.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-segmented-pw-06.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" Content-Type: text/plain Content-ID: <2007-11-19144737.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-segmented-pw-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-segmented-pw-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19144737.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Mon Nov 19 15:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD2J-0003pF-ST; Mon, 19 Nov 2007 15:16:03 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IuD1u-0002oU-2R for pwe3-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 15:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD1r-0002kE-Gb; Mon, 19 Nov 2007 15:15:35 -0500 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuD1o-00018t-IY; Mon, 19 Nov 2007 15:15:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 24FF1327C1; Mon, 19 Nov 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuD1J-0003ga-RX; Mon, 19 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-dynamic-ms-pw-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Dynamic Placement of Multi Segment Pseudo Wires Author(s) : F. Balus, et al. Filename : draft-ietf-pwe3-dynamic-ms-pw-06.txt Pages : 21 Date : 2007-11-19 There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-dynamic-ms-pw-06.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-dynamic-ms-pw-06.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" Content-Type: text/plain Content-ID: <2007-11-19143804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-dynamic-ms-pw-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19143804.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Wed Nov 21 04:11:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulcF-0001zV-Fd; Wed, 21 Nov 2007 04:11:27 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IulcD-0001hc-8t for pwe3-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:11:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulcC-0001ao-Im for pwe3@ietf.org; Wed, 21 Nov 2007 04:11:24 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IulcB-0000qe-Tw for pwe3@ietf.org; Wed, 21 Nov 2007 04:11:24 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:11:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 21 Nov 2007 10:11:20 +0100 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0FB3D6BF@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification for draft-jounay-pwe3-dynamic-pw-update-00.txt Thread-Index: AcgsHns8wPF5mgpZT4ee/x/49YP0tw== From: "JOUNAY Frederic RD-RESA-LAN" To: X-OriginalArrivalTime: 21 Nov 2007 09:11:21.0870 (UTC) FILETIME=[7BDBC2E0:01C82C1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Subject: [PWE3] Notification for draft-jounay-pwe3-dynamic-pw-update-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0655477406==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0655477406== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82C1E.7BBAFFA3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82C1E.7BBAFFA3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The subject draft is available from the on-line Internet-Drafts directories. It has been submitted to the PWE3 Working Group. Title : Dynamic Update of PW Parameters=20 Author(s) : F.Jounay, et al. Filename : draft-jounay-pwe3-dynamic-pw-update-00.txt Pages : 15 Date : 2007-11-12 =20 Abstract =20 This draft aims at providing a generic solution for updating PW=20 characteristics (interface parameters, label) on-the-fly without=20 service interruption. The document specifies a new generic PWE=20 control protocol mechanism called the PW Update. A PW Update LDP=20 sub-TLV is defined for that purpose. It defines the signaling=20 extension and describes the procedures to dynamically update the PW=20 parameters. A use case is provided for CESoPSN PWs. =20 A URL for this Internet-Draft is: http://tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw-update-00.txt Comments and discussions are requested on the mailing list. A presentation is planned at the Vancouver IETF. Best regards, Frederic ------_=_NextPart_001_01C82C1E.7BBAFFA3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Notification for = draft-jounay-pwe3-dynamic-pw-update-00.txt

The subject draft is available = from the on-line Internet-Drafts
directories. It has been = submitted to the PWE3 Working Group.



      = Title       : Dynamic Update of PW = Parameters
      = Author(s)   : F.Jounay, et al.
      = Filename    : = draft-jounay-pwe3-dynamic-pw-update-00.txt
      = Pages       : 15
      = Date        : 2007-11-12

 
Abstract
  
   This draft aims at = providing a generic solution for updating PW
   characteristics = (interface parameters, label) on-the-fly without
   service = interruption. The document specifies a new generic PWE
   control protocol = mechanism called the PW Update. A PW Update LDP
   sub-TLV is defined = for that purpose. It defines the signaling
   extension and = describes the procedures to dynamically update the PW
   parameters. A use = case is provided for CESoPSN PWs.
  
A URL for this Internet-Draft = is:

http://tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw-update-00= .txt

Comments and discussions are = requested on the mailing list. A presentation is planned at the = Vancouver IETF.

Best regards,

Frederic


------_=_NextPart_001_01C82C1E.7BBAFFA3-- --===============0655477406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0655477406==-- From pwe3-bounces@ietf.org Wed Nov 21 04:11:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iulcb-0003C5-1l; Wed, 21 Nov 2007 04:11:49 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Iulca-000356-88 for pwe3-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 04:11:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IulcZ-00031l-RF for pwe3@ietf.org; Wed, 21 Nov 2007 04:11:47 -0500 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IulcW-0005k6-5D for pwe3@ietf.org; Wed, 21 Nov 2007 04:11:47 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:11:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Nov 2007 10:11:41 +0100 Message-ID: <8AA97249241F7148BE6D3D8B93D83F5A0FB3D6C1@ftrdmel2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Notification for draft-jounay-pwe3-p2mp-pw-requirements-01.txt Thread-Index: AcgrnU4N4+TL7Hy1RcmuhXWYxJBBBAAf7C3Q From: "JOUNAY Frederic RD-RESA-LAN" To: X-OriginalArrivalTime: 21 Nov 2007 09:11:41.0901 (UTC) FILETIME=[87CC3FD0:01C82C1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [PWE3] Notification for draft-jounay-pwe3-p2mp-pw-requirements-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org The subject draft is available from the on-line Internet-Drafts directories. It has been submitted to the PWE3 Working Group. Title : Use Cases and signaling requirements for Point-to-Multipoint PW=20 Author(s) : F.Jounay, et al. Filename : draft-jounay-pwe3-p2mp-pw-requirements-01.txt Pages : 18 Date : 2007-11-20 =20 Abstract =20 This document provides some use cases advocating for the definition=20 of a unidirectional Point-to-Multipoint Pseudowire (P2MP PW) and its=20 relevant Virtual Private P2MP Multicast Service (VPMS). Based on these use=20 cases it also presents a set of requirements for the set up and=20 maintenance of P2MP PW, proposed as guidelines for possible solutions. =20 =20 A URL for this Internet-Draft is: http://tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-pw-requirements-01. txt Comments and discussions are requested on the mailing list. A presentation is planned at the Vancouver IETF. Best regards, Frederic _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 21 09:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqbY-0002iL-LF; Wed, 21 Nov 2007 09:31:04 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IuqbX-0002hL-2C for pwe3-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 09:31:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuqbW-0002gF-HK for pwe3@ietf.org; Wed, 21 Nov 2007 09:31:02 -0500 Received: from smail5.alcatel.fr ([64.208.49.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuqbQ-0006jn-LB for pwe3@ietf.org; Wed, 21 Nov 2007 09:31:02 -0500 Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail5.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lALETU9e025937 for ; Wed, 21 Nov 2007 15:29:30 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Nov 2007 15:30:55 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 21 Nov 2007 15:30:54 +0100 Message-ID: <2E17595838F96949AB1F0FD9A8EC5ED017A3A7@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF70 PWE3 Agenda Thread-Index: AcgsSx90jyVj50uLSTic1xmbSDxwAg== From: "BOCCI Matthew" To: X-OriginalArrivalTime: 21 Nov 2007 14:30:55.0425 (UTC) FILETIME=[20301310:01C82C4B] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.13 X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Subject: [PWE3] IETF70 PWE3 Agenda X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1820177139==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1820177139== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82C4B.20058D43" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82C4B.20058D43 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All, Here is the draft agenda for the PWE3 meeting in Vancouver. I have also uploaded this to the IETF meeting materials page. Please can presenters send me their slides by noon GMT on Friday 31st November. Please let me know if you have any comments/corrections/additions. Best regards, Matthew MONDAY, December 3rd, 2007 - 15:20 - 17:20 ----------------------------------- CHAIRS: Danny McPherson & Stewart Bryant 15 mins WG Status and Update - Chairs 15 mins - PW Redundancy - Marc Lasserre (marc.lasserre@alcatel-lucent.com) http://tools.ietf.org/wg/pwe3/draft-muley-dutta-pwe3-redundancy-bit-02.t xt http://tools.ietf.org/wg/pwe3/draft-muley-pwe3-pw-redundancy-02.txt 10 mins - VCCV-BFD - Tom Nadeau (Thomas.nadeau@bt.com) http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00 10 mins - Pseudowire Emulation MPLS PSN Congestion Status Bit - Matthew Bocci (matthew.bocci@alcatel.lucent.co.uk) http://tools.ietf.org/wg/pwe3/draft-bocci-martini-pwe3-psn-congestion-bi t-00.txt 10 mins - Load Balancing Fat MPLS Pseudowires - Joerg Kuechemann (Joerg.Kuechemann@telekom.de) http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00 10 Mins - Dynamic Update of PW parameters (v00) - Frederic Jounay (frederic.jounay@orange-ftgroup.com) - http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw-update-00 .txt=20 10 mins - P2MP PW Requirements v01 - Frederic Jounay (frederic.jounay@orange-ftgroup.com) http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-pw-requirements -01=20 Since the draft introduce a new service terminology, I'm probably going to ask a time slot also in L2VPN) 10 mins - PMP PW Signaling and Auto-Discovery in L2VPNs - Rahul Aggarwal(rahul@juniper.net) http://tools.ietf.org/wg/l2vpn/draft-raggarwa-l2vpn-p2mp-pw-00.txt 10 mins - T-MPLS Update - Stewart bryant (stbryant@cisco.com) ------_=_NextPart_001_01C82C4B.20058D43 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable IETF70 PWE3 Agenda

All,

Here is the draft agenda for the PWE3 = meeting in Vancouver. I have also uploaded this to the IETF meeting = materials page.

Please can presenters send me their = slides by noon GMT on Friday 31st November.

Please let me know if you have any = comments/corrections/additions.

Best regards,

Matthew


MONDAY, December 3rd, 2007 – = 15:20 - 17:20
-----------------------------------
CHAIRS: Danny McPherson & Stewart = Bryant

15 mins WG Status and Update - = Chairs


15 mins - PW Redundancy – = Marc Lasserre (marc.lasserre@alcatel-lucent.com)
http://tools.ietf.org/wg/pwe3/draft-muley-dutta-pwe3-redun= dancy-bit-02.txt
http://tools.ietf.org/wg/pwe3/draft-muley-pwe3-pw-redundan= cy-02.txt


10 mins – = VCCV-BFD – Tom Nadeau (Thomas.nadeau@bt.com)
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00

10 mins – Pseudowire = Emulation MPLS PSN Congestion Status Bit – Matthew = Bocci (matthew.bocci@alcatel.lucent.co.uk)
http://tools.ietf.org/wg/pwe3/draft-bocci-martini-pwe3-psn= -congestion-bit-00.txt

10 mins - Load Balancing Fat MPLS = Pseudowires - Joerg Kuechemann (Joerg.Kuechemann@telekom.de)
http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00=

10 Mins - Dynamic Update of PW = parameters (v00) – Frederic = Jounay (frederic.jounay@orange-ftgroup.com) -
http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynami= c-pw-update-00.txt

10 mins - P2MP PW Requirements v01 - = Frederic Jounay (frederic.jounay@orange-ftgroup.com)
http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-p= w-requirements-01
Since the draft introduce a new = service terminology, I'm probably going to ask a time slot also in = L2VPN)

10 mins - PMP PW Signaling and = Auto-Discovery in L2VPNs - Rahul Aggarwal(rahul@juniper.net)
http://tools.ietf.org/wg/l2vpn/draft-raggarwa-l2vpn-p2mp-p= w-00.txt


10 mins – T-MPLS = Update – Stewart bryant (stbryant@cisco.com)

------_=_NextPart_001_01C82C4B.20058D43-- --===============1820177139== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1820177139==-- From pwe3-bounces@ietf.org Wed Nov 21 10:11:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurEc-0006Bt-UX; Wed, 21 Nov 2007 10:11:26 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IurEa-0006Bf-Rf for pwe3-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 10:11:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IurEa-0006BW-Er for pwe3@ietf.org; Wed, 21 Nov 2007 10:11:24 -0500 Received: from colt-na7.alcatel.fr ([62.23.212.7] helo=smail6.alcatel.fr) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IurEZ-00044f-Q6 for pwe3@ietf.org; Wed, 21 Nov 2007 10:11:24 -0500 Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail6.alcatel.fr (8.13.4/8.13.4/ICT) with ESMTP id lALF9xMO009622 for ; Wed, 21 Nov 2007 16:09:59 +0100 Received: from FRVELSMBS14.ad2.ad.alcatel.com ([155.132.6.34]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 21 Nov 2007 16:11:22 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] IETF70 PWE3 Agenda X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 21 Nov 2007 16:11:21 +0100 Message-ID: <2E17595838F96949AB1F0FD9A8EC5ED017A3D3@FRVELSMBS14.ad2.ad.alcatel.com> In-Reply-To: <2E17595838F96949AB1F0FD9A8EC5ED017A3A7@FRVELSMBS14.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] IETF70 PWE3 Agenda Thread-Index: AcgsSx90jyVj50uLSTic1xmbSDxwAgABY4uA References: <2E17595838F96949AB1F0FD9A8EC5ED017A3A7@FRVELSMBS14.ad2.ad.alcatel.com> From: "BOCCI Matthew" To: X-OriginalArrivalTime: 21 Nov 2007 15:11:22.0329 (UTC) FILETIME=[C6BC3C90:01C82C50] X-Scanned-By: MIMEDefang 2.51 on 155.132.188.84 X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1774268162==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1774268162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82C50.C6957BF5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82C50.C6957BF5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable That should read Friday 30th November ! =20 Matthew ________________________________ From: BOCCI Matthew=20 Sent: 21 November 2007 14:31 To: pwe3@ietf.org Subject: [PWE3] IETF70 PWE3 Agenda =09 =09 All,=20 Here is the draft agenda for the PWE3 meeting in Vancouver. I have also uploaded this to the IETF meeting materials page. Please can presenters send me their slides by noon GMT on Friday 31st November.=20 Please let me know if you have any comments/corrections/additions.=20 Best regards,=20 Matthew=20 MONDAY, December 3rd, 2007 - 15:20 - 17:20=20 -----------------------------------=20 CHAIRS: Danny McPherson & Stewart Bryant=20 15 mins WG Status and Update - Chairs=20 15 mins - PW Redundancy - Marc Lasserre (marc.lasserre@alcatel-lucent.com)=20 =09 http://tools.ietf.org/wg/pwe3/draft-muley-dutta-pwe3-redundancy-bit-02.t xt =20 =09 http://tools.ietf.org/wg/pwe3/draft-muley-pwe3-pw-redundancy-02.txt =20 10 mins - VCCV-BFD - Tom Nadeau (Thomas.nadeau@bt.com)=20 http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00 =20 10 mins - Pseudowire Emulation MPLS PSN Congestion Status Bit - Matthew Bocci (matthew.bocci@alcatel.lucent.co.uk)=20 =09 http://tools.ietf.org/wg/pwe3/draft-bocci-martini-pwe3-psn-congestion-bi t-00.txt =20 10 mins - Load Balancing Fat MPLS Pseudowires - Joerg Kuechemann (Joerg.Kuechemann@telekom.de)=20 http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00 =20 10 Mins - Dynamic Update of PW parameters (v00) - Frederic Jounay (frederic.jounay@orange-ftgroup.com) -=20 =09 http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw-update-00 .txt =20 10 mins - P2MP PW Requirements v01 - Frederic Jounay (frederic.jounay@orange-ftgroup.com)=20 =09 http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-pw-requirements -01 =20 Since the draft introduce a new service terminology, I'm probably going to ask a time slot also in L2VPN)=20 10 mins - PMP PW Signaling and Auto-Discovery in L2VPNs - Rahul Aggarwal(rahul@juniper.net)=20 =09 http://tools.ietf.org/wg/l2vpn/draft-raggarwa-l2vpn-p2mp-pw-00.txt =20 10 mins - T-MPLS Update - Stewart bryant (stbryant@cisco.com)=20 ------_=_NextPart_001_01C82C50.C6957BF5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable IETF70 PWE3 Agenda
That should read Friday 30th November = !
 
Matthew

From: BOCCI Matthew =
Sent: 21=20 November 2007 14:31
To: pwe3@ietf.org
Subject: = [PWE3]=20 IETF70 PWE3 Agenda

All,

Here is the draft agenda for the PWE3 = meeting in=20 Vancouver. I have also uploaded this to the IETF meeting materials=20 page.

Please can presenters send me their = slides by noon=20 GMT on Friday 31st November.

Please let me know if you have any=20 comments/corrections/additions.

Best regards,

Matthew


MONDAY, December 3rd, 2007 – 15:20 - = 17:20
----------------------------------- =
CHAIRS: Danny McPherson & Stewart = Bryant

15 mins WG Status and Update - = Chairs=20


15 mins - PW Redundancy – Marc Lasserre=20 (marc.lasserre@alcatel-lucent.com)
http://tools.ietf.org/wg/pwe3/draft-muley-dutta-pwe3-redundancy-= bit-02.txt=20
http://tools.ietf.org/wg/pwe3/draft-muley-pwe3-pw-redundancy-02.= txt=20


10 mins – VCCV-BFD = – Tom Nadeau=20 (Thomas.nadeau@bt.com)
http://tools.ietf.org/html/draft-ietf-pwe3-vccv-bfd-00=20

10 mins – Pseudowire = Emulation MPLS PSN=20 Congestion Status Bit – Matthew Bocci (matthew.bocci@alcatel.lucent.co.uk) =
http://tools.ietf.org/wg/pwe3/draft-bocci-martini-pwe3-psn-conge= stion-bit-00.txt=20

10 mins - Load Balancing Fat MPLS = Pseudowires -=20 Joerg Kuechemann (Joerg.Kuechemann@telekom.de)
http://tools.ietf.org/html/draft-bryant-filsfils-fat-pw-00=20

10 Mins - Dynamic Update of PW = parameters=20 (v00) –=20 Frederic Jounay (frederic.jounay@orange-ftgroup.com) -
http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-dynamic-pw-u= pdate-00.txt

10 mins - P2MP PW Requirements v01 - = Frederic=20 Jounay (frederic.jounay@orange-ftgroup.com)
http://www.tools.ietf.org/wg/pwe3/draft-jounay-pwe3-p2mp-pw-requ= irements-01
Since = the draft=20 introduce a new service terminology, I'm probably going to ask a time = slot=20 also in L2VPN)

10 mins - PMP PW Signaling and = Auto-Discovery in=20 L2VPNs - Rahul Aggarwal(rahul@juniper.net)
http://tools.ietf.org/wg/l2vpn/draft-raggarwa-l2vpn-p2mp-pw-00.t= xt=20


10 mins – T-MPLS = Update – Stewart bryant=20 (stbryant@cisco.com)

------_=_NextPart_001_01C82C50.C6957BF5-- --===============1774268162== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1774268162==-- From pwe3-bounces@ietf.org Thu Nov 22 13:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGd5-0006R6-DM; Thu, 22 Nov 2007 13:18:23 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IvGd4-0006Ic-5N for pwe3-confirm+ok@megatron.ietf.org; Thu, 22 Nov 2007 13:18:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvGd3-0006G7-Pz for pwe3@ietf.org; Thu, 22 Nov 2007 13:18:21 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IvGd3-0008Ie-CK for pwe3@ietf.org; Thu, 22 Nov 2007 13:18:21 -0500 X-IronPort-AV: E=Sophos;i="4.21,452,1188770400"; d="scan'208";a="158555020" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 22 Nov 2007 19:18:21 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAMIIKgY030804; Thu, 22 Nov 2007 19:18:20 +0100 Received: from dhcp-gpk02-vlan300-64-103-65-14.cisco.com (dhcp-gpk02-vlan300-64-103-65-14.cisco.com [64.103.65.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAMII2ZZ012040; Thu, 22 Nov 2007 18:18:14 GMT Message-ID: <4745C7DB.7030701@cisco.com> Date: Thu, 22 Nov 2007 18:18:03 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pwe3 , t-mpls-dt@testbed.se Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1752; t=1195755500; x=1196619500; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20SG15Q12=20liaison=20on=20MS-PW=20requirements |Sender:=20; bh=Wro6+NP43X/SoiJM9p25ozWtgPncSvE4EyzOr0X2IQA=; b=YlZTnCakvg3iJs8k9iHwJC0LqtVTbcbZDddB5ylt5086wuTaYGiw/ELQGm4Xhz3xzGdjvrVg ZpAcc56Vbx/Yel7zy6xc8si6T1bqoQ1D5d0Q3YG0aM/c2byB98pEZANo; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [PWE3] SG15Q12 liaison on MS-PW requirements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org I have been taking a look at the following liaison statement https://datatracker.ietf.org/liaison/372/ I replying I think that we have to strongly express our willingness to work together and to request requirements. Given that we have all but completed draft-ietf-pwe3-ms-pw-requirements-05.txt I think that we would have to take the requirements as as supplementary to the existing requirements. Now I have a few concerns that we need to look at in the document: "Inside the T-MPLS network there is a 1:1 relationship between the MPLS MS-PW and the T-MPLS Channel trail; therefore the TMC/PW_A function is not required to insert a PW label. The reason is that the functionality of multiplexing (for vertical scalability reasons) multiple pseudo-wires over a single trunk is performed at the TMP level (by multiplexing multiple TMCs over a TMP)." This is saying (and I think that this is a problem that applies to TMPLS in general that we have not picked up on) that there is only ONE label in the packet that does double duty between PW label AND as MPLS label - perhaps Itallo can confirm). This breaks the PWE3/MPLS architecture. The only way that I can see it fitting is if we allow PHP of the PW lable IFF there is only one PW, which seems something of an irony! "Given the fact that T-MPLS has the same QoS architecture as IP/MPLS networks, the mapping of the QoS at the client MPLS PW layer and the QoS at the server T-MPLS channel layer is straightforward." That is true for data traffic, BUT with the re-use of the exp bits in the OAM I am not sure that it holds across the whole design. Please could others read the liaison and comment on the correct response. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Fri Nov 23 11:46:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivbfs-0002lx-9w; Fri, 23 Nov 2007 11:46:40 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Ivbfr-0002ls-6v for pwe3-confirm+ok@megatron.ietf.org; Fri, 23 Nov 2007 11:46:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ivbfq-0002lk-Rq for pwe3@ietf.org; Fri, 23 Nov 2007 11:46:38 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ivbfq-0006sd-4n for pwe3@ietf.org; Fri, 23 Nov 2007 11:46:38 -0500 X-IronPort-AV: E=Sophos;i="4.21,458,1188770400"; d="eml'208?scan'208,208,217";a="158645019" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Nov 2007 17:46:37 +0100 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lANGkbpg021579; Fri, 23 Nov 2007 17:46:37 +0100 Received: from dhcp-gpk02-vlan300-64-103-65-14.cisco.com (dhcp-gpk02-vlan300-64-103-65-14.cisco.com [64.103.65.14]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lANGkbZZ027501; Fri, 23 Nov 2007 16:46:37 GMT Message-ID: <474703ED.1080106@cisco.com> Date: Fri, 23 Nov 2007 16:46:37 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: pwe3 Content-Type: multipart/mixed; boundary="------------050302090500060707030504" DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6246; t=1195836397; x=1196700397; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20[Fwd=3A=20[TICTOC]=20updated=20charter=20page=20and=20agenda= 20submitted] |Sender:=20; bh=9ogxK+nxZ7Do0qIFtbcZVrLqPja1E07j0WBurNeAe2g=; b=qa0EPoy1H2A8waWWOwAmBHFqhFCQRbyzunyeq+Demlv46zXffgIl6z8/+p9Xq9RDF8vm+Ezd zhdmLydcVV2fByn0RlWnXIEDqIvU/u163ElovxhS7twfIN2UMmxN/3ZV; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Subject: [PWE3] [Fwd: [TICTOC] updated charter page and agenda submitted] X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --------------050302090500060707030504 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This will be of interest to some members of the PWE3 list Stewart --------------050302090500060707030504 Content-Type: message/rfc822; name="[TICTOC] updated charter page and agenda submitted.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[TICTOC] updated charter page and agenda submitted.eml" X-Account-Key: account3 X-Mozilla-Keys: Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id SAA10103 for ; Thu, 15 Nov 2007 18:07:29 GMT Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2007 10:07:29 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lAFI7T5t004322; Thu, 15 Nov 2007 10:07:29 -0800 Received: from sj-inbound-a.cisco.com (sj-inbound-a.cisco.com [128.107.234.204]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lAFI7S87017679; Thu, 15 Nov 2007 18:07:29 GMT X-from-outside-Cisco: 156.154.16.145 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAAABcaPEecmhCRnmdsb2JhbACCdIwMAQEBAQcEBhEY X-IronPort-AV: E=Sophos;i="4.21,421,1188802800"; d="scan'208,217";a="74854334" Received: from optimus.ietf.org (HELO megatron.ietf.org) ([156.154.16.145]) by sj-inbound-a.cisco.com with ESMTP; 15 Nov 2007 10:07:28 -0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isj7d-0007XW-Jt; Thu, 15 Nov 2007 13:07:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isj7c-0007XJ-JR for tictoc@ietf.org; Thu, 15 Nov 2007 13:07:24 -0500 Received: from antivir2.rad.co.il ([62.0.23.221]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isj7a-0001SL-60 for tictoc@ietf.org; Thu, 15 Nov 2007 13:07:22 -0500 Received: from exrad3.ad.rad.co.il ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 15 Nov 2007 20:07:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 15 Nov 2007 20:07:18 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D05933FA2@exrad3.ad.rad.co.il> Thread-Topic: updated charter page and agenda submitted Thread-Index: AcgnslwmRLzMwKWHTWmOsS5WDQV2cA== From: "Yaakov Stein" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [TICTOC] updated charter page and agenda submitted X-BeenThere: tictoc@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Timing over IP Connection and Transfer of Clock BOF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0189951405==" Errors-To: tictoc-bounces@ietf.org Authentication-Results: sj-dkim-4; header.From=yaakov_s@rad.com; dkim=neutral This is a multi-part message in MIME format. --===============0189951405== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C827B2.5C41EECA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C827B2.5C41EECA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all,=20 =20 We have (once again) updated the charter page www.dspcsp.com/tictoc. =20 An agenda has been submitted (you can see it at http://www3.ietf.org/proceedings/07dec/agenda/tictoc.txt). =20 Comments are welcome. =20 Y(J)S ------_=_NextPart_001_01C827B2.5C41EECA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi = all,=20
 
We = have (once again)=20 updated the charter page www.dspcsp.com/tictoc.
 
An = agenda has been=20 submitted (you can see it at http://= www3.ietf.org/proceedings/07dec/agenda/tictoc.txt).
 
Comments are=20 welcome.
 
Y(J)S
------_=_NextPart_001_01C827B2.5C41EECA-- --===============0189951405== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www1.ietf.org/mailman/listinfo/tictoc --===============0189951405==-- --------------050302090500060707030504 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --------------050302090500060707030504-- From pwe3-bounces@ietf.org Sat Nov 24 06:51:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtXm-0001W8-2F; Sat, 24 Nov 2007 06:51:30 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IvtXl-0001W0-78 for pwe3-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:51:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtXk-0001Vs-Tj; Sat, 24 Nov 2007 06:51:28 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtXg-0007TY-Q2; Sat, 24 Nov 2007 06:51:28 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm10b47481bcf; Sat, 24 Nov 2007 20:04:21 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm7e47421614; Tue, 20 Nov 2007 04:32:22 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Tue, 20 Nov 2007 04:32:22 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD2I-0003IL-DV; Mon, 19 Nov 2007 15:16:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD1r-0002kE-Gb; Mon, 19 Nov 2007 15:15:35 -0500 Received: from ns1.neustar.com ([156.154.16.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuD1o-00018t-IY; Mon, 19 Nov 2007 15:15:35 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 24FF1327C1; Mon, 19 Nov 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuD1J-0003ga-RX; Mon, 19 Nov 2007 15:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 15:15:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-dynamic-ms-pw-06.txt X-BeenThere: pwe3@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire Emulation Edge to Edge Working Group of the IETF. Title : Dynamic Placement of Multi Segment Pseudo Wires Author(s) : F. Balus, et al. Filename : draft-ietf-pwe3-dynamic-ms-pw-06.txt Pages : 21 Date : 2007-11-19 There is a requirement for service providers to be able to extend the reach of pseudo wires (PW) across multiple Packet Switched Network domains. A Multi-Segment PW is defined as a set of two or more contiguous PW segments that behave and function as a single point- to-point PW. This document describes extensions to the PW control protocol to dynamically place the segments of the multi segment pseudo wire among a set of Provider Edge (PE) routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-dynamic-ms-pw-06.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-dynamic-ms-pw-06.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" Content-Type: text/plain Content-ID: <2007-11-19143804.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pwe3-dynamic-ms-pw-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pwe3-dynamic-ms-pw-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19143804.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --NextPart-- From pwe3-bounces@ietf.org Mon Nov 26 05:15:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwazh-0002ln-4u; Mon, 26 Nov 2007 05:15:13 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Iwazf-0002fn-Ji for pwe3-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 05:15:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwazf-0002dD-8F for pwe3@ietf.org; Mon, 26 Nov 2007 05:15:11 -0500 Received: from david.sha.siemens.com.cn ([194.138.203.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwazS-0001LK-Kr for pwe3@ietf.org; Mon, 26 Nov 2007 05:15:11 -0500 Received: from mail.sha.siemens.com.cn (mail.sha.siemens.com.cn [194.138.237.116]) by david.sha.siemens.com.cn (8.11.7/8.11.7) with ESMTP id lAQAEkQ14134; Mon, 26 Nov 2007 18:14:46 +0800 (CST) Received: from ssmcmail07.cn001.siemens.net ([140.231.196.47]) by mail.sha.siemens.com.cn (8.11.7/8.11.7) with ESMTP id lAQAEkh00065; Mon, 26 Nov 2007 18:14:46 +0800 (CST) Received: by ssmcmail07.cn001.siemens.net with Internet Mail Service (5.5.2657.72) id ; Mon, 26 Nov 2007 18:14:46 +0800 Message-ID: <83678987E699AF4F88FE1DA70BA9359F07B23E7C@ssmcmail05.cn001.siemens.net> From: "Jin Li Zhong, PB SHA" To: pwe3@ietf.org, stbryant@cisco.com Date: Mon, 26 Nov 2007 18:14:45 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.7 (++) X-Scan-Signature: a630332fa112280ecc4c4186b5c9ea83 Cc: Subject: [PWE3] RE: SG15Q12 liaison on MS-PW requirements (Stewart Bryant) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0503076481==" Errors-To: pwe3-bounces@ietf.org 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. --===============0503076481== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83015.2B1678E3" 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_01C83015.2B1678E3 Content-Type: text/plain Hi all In my personal opinion, the most disadvantage of the solution described in liaison statement is: the MS-PW is only doing the mapping to TMC, and PW is somelike meaningless. This will change the role of PW, and in fact, the client layer netwrok and the server layer t-mpls transport network are mixed together in the data plane. In my opinion, using TMP/TMC to multiplex MS-PW is a better solution. We can keep the independence of PW setting up and forwarding, and this solution is much more conform with draft-ietf-pwe3-ms-pw-requirements-05. TMP multiplexing solution is recommended. Best Regards Lizhong JIN Nokia Siemens Networks Systems Engineering NGM Building 89, 1122 North QinZhou Road, Shanghai, 200211, P.R.China e-mail: lizhong.jin@siemens.com -----Original Message--------------------------------------------------------------------- ------ Message: 1 Date: Thu, 22 Nov 2007 18:18:03 +0000 From: Stewart Bryant Subject: [PWE3] SG15Q12 liaison on MS-PW requirements To: pwe3 , t-mpls-dt@testbed.se Message-ID: <4745C7DB.7030701@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed I have been taking a look at the following liaison statement https://datatracker.ietf.org/liaison/372/ I replying I think that we have to strongly express our willingness to work together and to request requirements. Given that we have all but completed draft-ietf-pwe3-ms-pw-requirements-05.txt I think that we would have to take the requirements as as supplementary to the existing requirements. Now I have a few concerns that we need to look at in the document: "Inside the T-MPLS network there is a 1:1 relationship between the MPLS MS-PW and the T-MPLS Channel trail; therefore the TMC/PW_A function is not required to insert a PW label. The reason is that the functionality of multiplexing (for vertical scalability reasons) multiple pseudo-wires over a single trunk is performed at the TMP level (by multiplexing multiple TMCs over a TMP)." This is saying (and I think that this is a problem that applies to TMPLS in general that we have not picked up on) that there is only ONE label in the packet that does double duty between PW label AND as MPLS label - perhaps Itallo can confirm). This breaks the PWE3/MPLS architecture. The only way that I can see it fitting is if we allow PHP of the PW lable IFF there is only one PW, which seems something of an irony! "Given the fact that T-MPLS has the same QoS architecture as IP/MPLS networks, the mapping of the QoS at the client MPLS PW layer and the QoS at the server T-MPLS channel layer is straightforward." That is true for data traffic, BUT with the re-use of the exp bits in the OAM I am not sure that it holds across the whole design. Please could others read the liaison and comment on the correct response. - Stewart ------------------------------ Message: 2 Date: Fri, 23 Nov 2007 16:46:37 +0000 From: Stewart Bryant Subject: [PWE3] [Fwd: [TICTOC] updated charter page and agenda submitted] To: pwe3 Message-ID: <474703ED.1080106@cisco.com> Content-Type: text/plain; charset="iso-8859-1" This will be of interest to some members of the PWE3 list Stewart -------------- next part -------------- An embedded message was scrubbed... From: "Yaakov Stein" Subject: [TICTOC] updated charter page and agenda submitted Date: Thu, 15 Nov 2007 20:07:18 +0200 Size: 5536 Url: http://www1.ietf.org/pipermail/pwe3/attachments/20071123/7ba83084/TICTOCupda tedcharterpageandagendasubmitted.eml ------------------------------ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 End of pwe3 Digest, Vol 43, Issue 14 ************************************ ------_=_NextPart_001_01C83015.2B1678E3 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: SG15Q12 liaison on MS-PW requirements (Stewart = Bryant)

 Hi all
In my personal opinion, the most disadvantage of the = solution described in liaison statement is: the MS-PW is only doing the = mapping to TMC, and PW is somelike meaningless. This will change the = role of PW, and  in fact, the client layer netwrok and the server = layer t-mpls transport network are mixed together in the data = plane.

In my opinion, using TMP/TMC to multiplex MS-PW is a = better solution. We can keep the independence of PW setting up and = forwarding, and this solution is much more conform with = draft-ietf-pwe3-ms-pw-requirements-05. TMP multiplexing solution is = recommended.



Best Regards
Lizhong JIN

Nokia Siemens Networks
Systems Engineering NGM
Building 89, 1122 North QinZhou Road,
Shanghai, 200211, P.R.China
e-mail: lizhong.jin@siemens.com

-----Original = Message-----------------------------------------------------------------= ----------

Message: 1
Date: Thu, 22 Nov 2007 18:18:03 +0000
From: Stewart Bryant = <stbryant@cisco.com>
Subject: [PWE3] SG15Q12 liaison on MS-PW = requirements
To: pwe3 <pwe3@ietf.org>, = t-mpls-dt@testbed.se
Message-ID: = <4745C7DB.7030701@cisco.com>
Content-Type: text/plain; charset=3DISO-8859-1; = format=3Dflowed

I have been taking a look at the following liaison = statement

https://datatracker.ietf.org/liaison/372/

I replying I think that we have to strongly = express
our willingness to work together and to = request
requirements.  Given that we have all but = completed

draft-ietf-pwe3-ms-pw-requirements-05.txt

I think that we would have to take the requirements = as
as supplementary to the existing = requirements.

Now I have a few concerns that we need to look at = in
the document:

"Inside the T-MPLS network there is a 1:1 = relationship
between the MPLS MS-PW and the T-MPLS Channel trail; =
therefore the TMC/PW_A function is not required to =
insert a PW label. The reason is that the = functionality
of multiplexing (for vertical scalability reasons) =
multiple pseudo-wires over a single trunk is = performed
at the TMP level (by multiplexing multiple TMCs over = a TMP)."

This is saying (and I think that this is a problem =
that applies to TMPLS in general that we have = not
picked up on) that there is only ONE label
in the packet that does double duty between PW = label
AND as MPLS label - perhaps Itallo can confirm). = This
breaks the PWE3/MPLS architecture. The only way that = I can
see it fitting is if we allow PHP of the PW = lable
IFF there is only one PW, which seems something = of
an irony!

"Given the fact that T-MPLS has the same QoS = architecture
as IP/MPLS networks, the mapping of the QoS at the = client
MPLS PW layer and the QoS at the server T-MPLS = channel
layer is straightforward."

That is true for data traffic, BUT with the re-use =
of the exp bits in the OAM I am not sure that = it
holds across the whole design.

Please could others read the liaison and comment = on
the correct response.

- Stewart








------------------------------

Message: 2
Date: Fri, 23 Nov 2007 16:46:37 +0000
From: Stewart Bryant = <stbryant@cisco.com>
Subject: [PWE3] [Fwd: [TICTOC] updated charter page = and agenda
        submitted]
To: pwe3 <pwe3@ietf.org>
Message-ID: = <474703ED.1080106@cisco.com>
Content-Type: text/plain; = charset=3D"iso-8859-1"

This will be of interest to some members of the PWE3 = list


Stewart


-------------- next part --------------
An embedded message was scrubbed...
From: "Yaakov Stein" = <yaakov_s@rad.com>
Subject: [TICTOC] updated charter page and agenda = submitted
Date: Thu, 15 Nov 2007 20:07:18 +0200
Size: 5536
Url: http://www1.ietf.org/pipermail/pwe3/attachments/200711= 23/7ba83084/TICTOCupdatedcharterpageandagendasubmitted.eml

------------------------------

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


End of pwe3 Digest, Vol 43, Issue 14
************************************

------_=_NextPart_001_01C83015.2B1678E3-- --===============0503076481== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0503076481==-- From pwe3-bounces@ietf.org Mon Nov 26 09:38:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwf62-0005Ob-96; Mon, 26 Nov 2007 09:38:02 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Iwf60-0005OW-OM for pwe3-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 09:38:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwf60-0005OO-Em for pwe3@ietf.org; Mon, 26 Nov 2007 09:38:00 -0500 Received: from rv-out-0910.google.com ([209.85.198.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwf5s-0007Sg-JS for pwe3@ietf.org; Mon, 26 Nov 2007 09:38:00 -0500 Received: by rv-out-0910.google.com with SMTP id l15so524282rvb for ; Mon, 26 Nov 2007 06:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=AMyMF923vL/pmf+XwQGeu6rQR4ApS4rPLUtzl21R6Fk=; b=RndF306Muq99DzWemvtRNZYSFxO0IFRYMvtD6hyD7tbODxUlNBtOD4zAzcYQG7b0PbMvvShEZyzqFoFXLwOGLNQNBvYdXpmz2BQoE06sVCD5o8CF+efIh/m8s6UlFzr6I3PGR3G2nBM9eLom8uRlPsNhNbGv5HGE1JAIPfNW1Mo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f0rvut04t4JaKKw2XZ7OgOr4LuCVu6QWyvlqtnmuXQL/wr7770k4xIJB0LD+mVsyxinkEeolpVyTp30XaoWCaNJVKz1F374iOZGYWW5TJ2HYmgZWang4vL5kzdHmrWbz0TsDKyIgLnicBlKPBl2tAjy0DuA/faFvDtOKcu/GDqk= Received: by 10.114.192.1 with SMTP id p1mr545646waf.1196087871628; Mon, 26 Nov 2007 06:37:51 -0800 (PST) Received: by 10.114.174.3 with HTTP; Mon, 26 Nov 2007 06:37:51 -0800 (PST) Message-ID: <7c923b5e0711260637t1b8b0345kba379571ddac8b29@mail.gmail.com> Date: Mon, 26 Nov 2007 15:37:51 +0100 From: "Francesco Fondelli" To: stbryant@cisco.com Subject: Re: [PWE3] SG15Q12 liaison on MS-PW requirements In-Reply-To: <4745C7DB.7030701@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4745C7DB.7030701@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: t-mpls-dt@testbed.se, pwe3 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org On Nov 22, 2007 7:18 PM, Stewart Bryant wrote: [cut] > picked up on) that there is only ONE label > in the packet that does double duty between PW label [cut] No, IMHO that statement says something different. G.805 terminology/methodology is the whole point here. Even if I am far to fully understand G.805 functional architecture I try to explain what the liaison says (at least my interpretation). We have to agree on few points before any dissertation: 1) In figure 1 (liaison 2007-09-20) "T-MPLS path" *functionally matches* a plain LSP. This entity is just *described*, from a functional view point, in G.8110.1 (using G.805 terminology/methodology). Please note that the entire "T-MPLS thing" can be defined as -- a *description* of MPLS from a different view point + some additional constraints (no PHP, only connection-oriented, etc) + a specific OAM mechanism --. I understand this might sound strange. 2) In figure 1 (liaison 2007-09-20) "T-MPLS channel" *functionally matches* a plain PW. It is so close to a PW that I call it "PW" :-) 3) In G.805 formalism a triangle is a "trail termination" and a trapezium is an "adaptation", again we are talking about *functional blocks*. If you want to describe a network architecture in G.805 terms you begin describing each single network element functional block: you'll describe what goes in ("input signal"), what comes out ("output signal") and what a single bloody block in the middle should do ("functional block"). ITU-T people claim they can describe everything using this paradigm (SDH, MPLS, even IP or PBB or whatever). 4) Figure I.3 of G.8110.1 illustrates how the PWE3 concept fits within the T-MPLS layer network model (again this is a *description*) and Figure I.4 (same rec, G.8110.1) illustrates how a MS-PW can be *described* using the same framework. Please note that ITU-T people say that an Appendix is just informative... ... hemmm actually is the only part of a ITU-T recommendation that I vaguely understand. 5) A G.805 trapezium functional block usually performs mux/demux operations. This is graphically represented drawing more then one incoming line (5.3.3.1.1, G.805). However the TMC/PW trapezium (liaison fig 2) has *only one* ingress line (in G.805 terms I guess we can say that it accepts only one client signal). ---------- Ok. If someone doesn't agree with me about above statements please *stop reading* and try to provide alternative interpretations. The liaison, in my opinion, says: "We (T-MPLS guys) already have a functionally equivalent PW in our model (i.e. T-MPLS channel trail). If we attach this *thing* to a PW segment we obtain a MS-PW. Do you mind if we do something like that?". > there is only ONE label in the packet there are TWO labels in that packet, because the TMC/PW trapezium usually pushes one specified new label onto the label stack (somewhere in G.8110.1 or G.8110). I beg the "T-MPLS design team" to produce an informational I-D to address these terminology issues (something like rfc 4397 for GMPLS-ASON) otherwise this mess will never stop. Moreover I suggest that people understanding G.805 functional architecture stand up and correct me about what I have just said. I really need someone telling me whether I'm right or not! > > - Stewart Ciao, my 2 cents FF ps in its infinite wisdom ITU-T has made free/available all recommendations referenced in this email (http://www.itu.int/rec/T-REC/e), I have no access to new unpublished amendments. _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Tue Nov 27 09:10:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix18e-0006VL-7e; Tue, 27 Nov 2007 09:10:12 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Iwgui-0005of-5c for pwe3-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 11:34:28 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Iwguh-0005oX-Sb for pwe3@ietf.org; Mon, 26 Nov 2007 11:34:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwgr0-0004fS-Ft for pwe3@ietf.org; Mon, 26 Nov 2007 11:30:38 -0500 Received: from chn-hclin-gws01.hcl.in ([203.105.186.19] helo=gws03.hcl.in) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwgqu-0002WS-0R for pwe3@ietf.org; Mon, 26 Nov 2007 11:30:38 -0500 Received: from gws03.hcl.in (gws03 [10.249.64.134]) by localhost.hcl.in (Postfix) with ESMTP id D0D8037C0DE for ; Mon, 26 Nov 2007 22:00:27 +0530 (IST) Received: from chn-egw02-out.corp.hcl.in (unknown [10.249.64.38])by gws03.hcl.in (Postfix) with ESMTP id AA9C437C097for ; Mon, 26 Nov 2007 22:00:27 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw02-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 22:00:27 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 26 Nov 2007 22:00:22 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Thread-Index: AcgwSaRC257SZ7ZDT/G6RClSdX8YkQ== From: "Raman Rangaswamy" To: X-OriginalArrivalTime: 26 Nov 2007 16:30:27.0573 (UTC) FILETIME=[A72FC250:01C83049] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-9.5871 TC:1F TRN:58 TV:5.0.1023(15570.000) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 X-TMDA-Confirmed: Mon, 26 Nov 2007 11:34:27 -0500 X-Mailman-Approved-At: Tue, 27 Nov 2007 09:10:10 -0500 Cc: Raman Rangaswamy , "Vijayanand C - TLS, Chennai." Subject: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000993452==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0000993452== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83049.A71EE28E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83049.A71EE28E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi , =20 Can I conclude from the below draft sections that "LSP Ping should be used to test MPLS PWs over MPLS PSN and=20 it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel)=2E" =20 Draft: draft-ietf-pwe3-vccv-15 Section 3 : The CV types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs=2E=20 =20 Section 4: The various VCCV CV types supported are used only when they apply to the context of the PW demultiplexer in use=2E For example, LSP Ping type should only be used=20 when MPLS is utilized as the PSN=2E =20 Thanks, Raman R DISCLAIMER: ---------------------------------------------------------------------------= -------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and=20 attachments please check them for viruses and defect=2E ---------------------------------------------------------------------------= -------------------------------------------- ------_=_NextPart_001_01C83049.A71EE28E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi ,

 

Can I conclude from the below draft sections= that

“LSP Ping should be used to test MPLS PWs over MPLS PSN and=

it does not applicable to test MPLS PWs over IP PSN(Say GRE= tunnel)=2E”

 

Draft:= draft-ietf-pwe3-vccv-15

Section 3 :=
 The CV types include LSP Ping=
 [RFC4379] for MPLS
PWs, and ICMP Ping [RFC0792]=
 [RFC4443] for both MPLS and L2TPv3 PWs=2E=
 
 
Section 4: The various VCCV CV types supported=
 are used only when they apply to=
 the
context of the PW demultiplexer in=
 use=2E  For example, LSP Ping type should only be used=
 
when MPLS is utilized as the PSN=
=2E
=

Thanks,

Raman R

DISCLAIMER:
---------------------------------------------------------------------------= --------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and= intended for the named recipient(s) only=2E
It shall not attach any liability on the originator or HCL or its= affiliates=2E Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect= the opinions of HCL or its affiliates=2E
Any form of reproduction, dissemination, copying, disclosure, modification,= distribution and / or publication of
this message without the prior written consent of the author of this e-mail= is strictly prohibited=2E If you have
received this email in error please delete it and notify the sender= immediately=2E Before opening any mail and
attachments please check them for viruses and defect=2E

---------------------------------------------------------------------------= --------------------------------------------
------_=_NextPart_001_01C83049.A71EE28E-- --===============0000993452== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0000993452==-- From pwe3-bounces@ietf.org Tue Nov 27 09:25:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1NX-0006Dx-Rm; Tue, 27 Nov 2007 09:25:35 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1Ix1NX-0006Dh-4e for pwe3-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 09:25:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ix1NW-0006DX-Ov for pwe3@ietf.org; Tue, 27 Nov 2007 09:25:34 -0500 Received: from static-72-71-250-34.cncdnh.fios.verizon.net ([72.71.250.34] helo=lucidvision.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ix1NV-0005GV-UY for pwe3@ietf.org; Tue, 27 Nov 2007 09:25:34 -0500 Received: from [192.168.1.120] (static-72-71-250-36.cncdnh.fios.verizon.net [72.71.250.36]) by lucidvision.com (Postfix) with ESMTP id 668E2238629; Tue, 27 Nov 2007 09:26:14 -0500 (EST) Message-Id: From: Thomas Nadeau To: "Raman Rangaswamy" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Date: Tue, 27 Nov 2007 09:25:33 -0500 References: X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.1 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Cc: pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1857085603==" Errors-To: pwe3-bounces@ietf.org --===============1857085603== Content-Type: multipart/alternative; boundary=Apple-Mail-6-970484755 --Apple-Mail-6-970484755 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable =09 > Hi , > > Can I conclude from the below draft sections that > =93LSP Ping should be used to test MPLS PWs over MPLS PSN and > it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).=94 VCCV should always be used to test the PW layer regardless of = the PW type or encapsulation, and the appropriate tools for the lower layer =20 to test those. So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp tunnels/paths. --Tom > > Draft: draft-ietf-pwe3-vccv-15 > Section 3 : The CV types include LSP Ping [RFC4379] for MPLS > PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. > > Section 4: The various VCCV CV types supported are used only when =20 > they apply to the > context of the PW demultiplexer in use. For example, LSP Ping type =20= > should only be used > when MPLS is utilized as the PSN. > > Thanks, > Raman R > DISCLAIMER: > = --------------------------------------------------------------------------= --------------------------------------------- > > The contents of this e-mail and any attachment(s) are confidential =20 > and intended for the named recipient(s) only. > It shall not attach any liability on the originator or HCL or its =20 > affiliates. Any views or opinions presented in > this email are solely those of the author and may not necessarily =20 > reflect the opinions of HCL or its affiliates. > Any form of reproduction, dissemination, copying, disclosure, =20 > modification, distribution and / or publication of > this message without the prior written consent of the author of this =20= > e-mail is strictly prohibited. If you have > received this email in error please delete it and notify the sender =20= > immediately. Before opening any mail and > attachments please check them for viruses and defect. > > = --------------------------------------------------------------------------= --------------------------------------------- > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --Apple-Mail-6-970484755 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
=
Hi = ,
Can I conclude from the = below draft sections that
=93LSP Ping should be used to test MPLS PWs = over MPLS PSN and
it does not = applicable to test MPLS PWs over IP PSN(Say GRE = tunnel).=94

VCCV = should always be used to test the PW layer regardless of the = PW 
type or encapsulation, and the appropriate tools for = the lower layer to test those. 
So use LSP ping/trace for = MPLS LSPs, and ICMP echo for = IP/l2tp 
tunnels/paths.


--Tom


Draft: = draft-ietf-pwe3-vccv-15
Section 3 : =
The CV types =
include LSP Ping [RFC4379] for MPLS
PWs, and ICMP Ping [RFC0792] =
[RFC4443] for both MPLS and L2TPv3 PWs. =

Section 4: The various VCCV CV types supported are used only =
when they apply to the
context of the PW demultiplexer =
in use.  For example, LSP Ping type should only be used =
Thanks,
Raman = R
DISCLAIMER:
-----------------------------------------= --------------------------------------------------------------------------= ----

The contents of this e-mail and any attachment(s) are = confidential and intended for the named recipient(s) only.
It shall = not attach any liability on the originator or HCL or its affiliates. Any = views or opinions presented in 
this email are solely = those of the author and may not necessarily reflect the opinions of HCL = or its affiliates.
Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication of 
this message without = the prior written consent of the author of this e-mail is strictly = prohibited. If you have
received this email in error please delete it = and notify the sender immediately. Before opening any mail and 
attachments please = check them for viruses and = defect.

-----------------------------------------------------------= ------------------------------------------------------------
_______________________________________________
= pwe3 mailing list
pwe3@ietf.org
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHrl-0002eD-Cn; Wed, 28 Nov 2007 03:01:53 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxHrj-0002dn-CI for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 03:01:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxHrd-0002aY-Li for pwe3@ietf.org; Wed, 28 Nov 2007 03:01:45 -0500 Received: from [212.199.240.16] (helo=antivir2.rad.co.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxHrW-0000GB-DP for pwe3@ietf.org; Wed, 28 Nov 2007 03:01:39 -0500 Received: from exrad3.ad.rad.co.il ([192.114.24.112]) by antivir2.rad.co.il with ESMTP; 28 Nov 2007 10:01:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 28 Nov 2007 10:00:09 +0200 Message-ID: <457D36D9D89B5B47BC06DA869B1C815D05B14176@exrad3.ad.rad.co.il> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-bryant-filsfils-fat-pw Thread-Index: AcgxlLInEhbuMPd3SXWKOZSM/7qXBQ== From: "Yaakov Stein" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 73f7847c44628482de9d5f1018acf469 Subject: [PWE3] draft-bryant-filsfils-fat-pw X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0847226407==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0847226407== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83194.E4C59DD2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83194.E4C59DD2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stewart and other authors =20 I just finished reading the FAT-PW draft, and have a few comments/questions. =20 1. The draft says "Operators have requested the ability..." Since I have never heard this request from any of the operators with which we work, can this be changed to "Some operators have requested ..." ? Since there is one operator on the author list, I guess we can guess which operator has requested this feature ! =20 2. The example given is for Ethernet PWs. Is this draft limited to this case? There is discussion of whether it is limited to IP over Ethernet,=20 but this more basic question is not addressed. For example, could this load balancing to be performed for ATM PWs=20 based on the AAL5 flows? =20 3. PWs are an emulation of the native service. Why is this emulation being called upon to deliver a feature NOT present in the native service ? Doesn't this break the model a bit? =20 4. A native service processing function is required for differentiating between different flows at ingress. If this draft is indeed limited to Ethernet PWs, such a processing function already exists in the native service. 802.3 clause 43 (LAG) defines conversations for exactly this purpose (commonly implemented by hashing IP addresses and port numbers), and even mentions the use of load balancing in the distribution of conversations over links. I think this function should be at least referenced. =20 5. My greatest problem is with the prefered mode of section 1.1,=20 which builds a PW label stack under the MPLS label stack. The proposal is for 2 PW labels (once again, somewhat breaking RFC3985). Figure 2 is not completely clear about the label structure. There are two possibilities: 1) both load balancing label and PW label have stack bit set. (I hope not !) 2) the load balancing label has S=3D1, and the PW label has S=3D0. So formally, the PW label seems to be an MPLS label. Both possibilities break the standard model. =20 I would certainly like to see more justification of the problem before breaking the model in this way.=20 Perhaps a short requirements document is in order? =20 6. The draft recommends generating a load balancing label in such fashion that the entropy is high. This assumes that the precise form of the label is used to determine the load balancing path (possibly a hash of some sort). Could this mechanism, even if beyond the scope of the document, be explained a bit more ? =20 7. With the optional mode of section 1.2 several PW labels are mapped to a single AC. I have no problem with this approach. In fact, I feel that it is somewhat similar to the solutions being proposed for PW protection. For PW protection two labels mapped to the AC or end-user application,=20 where one label belongs to the active PW, and the other to the backup PW (not being used). For load balancing two or more PWs, all in active state, are mapped to the same AC. Would it be possible to integrate the two features into one mechanism for mapping multiple PW labels in either active or backup state to one AC or end-user identifier? =20 8. The term VC as opposed to PW is used in various places in the document. I am not sure what is meant here. Is the intent that a "VC" is one of the paths of the=20 load-balanced "PW" ? =20 The first paragraph of section 4 seems to imply that the authors are willing to settle=20 on either of the modes rather than both. I would support the PW label mode. If some entropy-rich information needs to be placed in the packet, perhaps the flags in the CW could be used (if 16 paths is sufficient). =20 Y(J)S =20 ------_=_NextPart_001_01C83194.E4C59DD2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Stewart and other=20 authors
 
I just = finished=20 reading the FAT-PW draft, and have a few = comments/questions.
 
1. The = draft says=20 "Operators have requested the ability..."
   =20 Since I have never heard this request from any of the operators with = which we=20 work,
   =20 can this be changed to "Some operators have requested ..." = ?
   =20 Since there is one operator on the author list, I guess we can guess=20 which operator has requested
   =20 this feature !
 
2. The = example given=20 is for Ethernet PWs. Is this draft limited to this = case?
   =20 There is discussion of whether it is limited to IP over Ethernet,=20
   =20 but this more basic question is not addressed.
   =20 For example, could this load balancing to be performed for ATM = PWs=20
   =20 based on the AAL5 flows?
 
3. PWs = are an=20 emulation of the native service.
   Why is=20 this emulation being called upon to deliver a feature NOT present in the = native=20 service ?
   Doesn't=20 this break the model a bit?
 
4. A = native service=20 processing function is required for differentiating between different=20 flows
   at=20 ingress. If this draft is indeed limited to Ethernet PWs, such a = processing=20 function
   already=20 exists in the native service. 802.3 clause 43 (LAG) defines=20 conversations
   for=20 exactly this purpose (commonly implemented by hashing IP addresses and = port=20 numbers),
   and=20 even mentions the use of load balancing in the distribution of = conversations=20 over links.
   I think=20 this function should be at least referenced.
 
5. My = greatest=20 problem is with the prefered mode of section 1.1,
   =20 which builds a PW label stack under the MPLS label = stack.
   =20 The proposal is for 2 PW labels (once again, somewhat breaking=20 RFC3985).
   =20 Figure 2 is not completely clear about the label=20 structure.
   =20 There are two possibilities:
     1) both load = balancing label=20 and PW label have stack bit set. (I hope not !)
     2) the load = balancing label=20 has S=3D1, and the PW label has S=3D0.
       &nbs= p; So=20 formally, the PW label seems to be an MPLS label.
   =20 Both possibilities break the standard model.
 
   I would=20 certainly like to see more justification of the = problem
   before=20 breaking the model in this way.
   Perhaps=20 a short requirements document is in order?
 
6. The = draft=20 recommends generating a load balancing label in such = fashion
   =20 that the entropy is high. This assumes that the precise form of the=20 label
   =20 is used to determine the load balancing path (possibly a hash of some=20 sort).
   =20 Could this mechanism, even if beyond the scope of the document, be = explained a=20 bit more ?
 
7. = With the optional=20 mode of section 1.2 several PW labels are mapped to a single=20 AC.
    I=20 have no problem with this approach. In fact, I feel that it=20 is
    somewhat similar to = the=20 solutions being proposed for PW protection.
    For PW protection two labels = mapped to the=20 AC or end-user application,
   =20 where one label belongs to the active PW, and the other to the = backup PW=20 (not being used).
   =20 For load balancing two or more PWs, all in active state, are mapped = to the=20 same AC.
   =20 Would it be possible to integrate the two features into one=20 mechanism
   =20 for mapping multiple PW labels in either active or backup state to one = AC or=20 end-user identifier?
 
8. The = term VC as=20 opposed to PW is used in various places in the = document.
    I=20 am not sure what is meant here. Is the intent that a "VC" is one of the = paths of=20 the
   =20 load-balanced "PW" ?
 
The = first paragraph=20 of section 4 seems to imply that the authors are willing to settle=20
on = either of the=20 modes rather than both. I would support the PW = label=20 mode.
If=20 some entropy-rich information needs to be placed in the=20 packet,
perhaps the flags in=20 the CW could be used (if 16 paths is sufficient).
 
Y(J)S
 
------_=_NextPart_001_01C83194.E4C59DD2-- --===============0847226407== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0847226407==-- From pwe3-bounces@ietf.org Wed Nov 28 04:24:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJ8w-0007x0-Ug; Wed, 28 Nov 2007 04:23:42 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxJ8u-0007uA-S9 for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 04:23:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxJ8u-0007kT-CX for pwe3@ietf.org; Wed, 28 Nov 2007 04:23:40 -0500 Received: from mxa6.qos.net.il ([80.74.96.6] helo=mx05.qos.net.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxJ8t-0005K1-0c for pwe3@ietf.org; Wed, 28 Nov 2007 04:23:39 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mx05.qos.net.il (Postfix) with ESMTP id 3AC8637345F for ; Wed, 28 Nov 2007 11:23:35 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Date: Wed, 28 Nov 2007 11:23:18 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Thread-Index: AcgxAXrMTcugO4dnRhK3jnZou7f5VQAndFOA From: "Sasha Vainshtein" To: "Thomas Nadeau" , "Raman Rangaswamy" X-Spam-Score: 0.0 (/) X-Scan-Signature: 07e9b4af03a165a413ec6e4d37ae537b Cc: pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1643743608==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1643743608== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C831A0.6D5A403E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C831A0.6D5A403E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tom, Raman and all, My understanding of the original question was (please correct me if I got something wrong): Can LSP ping in VCCV be used to verify the PW connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW label (bound to the appropriate PW Id or Generalized PW Id FEC) for PW demultiplexing? And is such a verification required if the IP connectivity to the remote device is OK? IMHO the answer is: *=09 Such a verification makes sense (the PW demuxing in the remote box can go wrong even if the IP transport brings the PW packets to the correct remote box) *=09 LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way to perform it. Did I miss something? =20 Regards, Sasha ________________________________ From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Tuesday, November 27, 2007 4:26 PM To: Raman Rangaswamy Cc: pwe3@ietf.org; Vijayanand C - TLS, Chennai. Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? =09 Hi , =09 Can I conclude from the below draft sections that "LSP Ping should be used to test MPLS PWs over MPLS PSN and it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel)." VCCV should always be used to test the PW layer regardless of the PW=20 type or encapsulation, and the appropriate tools for the lower layer to test those.=20 So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=20 tunnels/paths. --Tom =09 =09 =09 Draft: draft-ietf-pwe3-vccv-15 Section 3 : The CV types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs.=20 =20 Section 4: The various VCCV CV types supported are used only when they apply to the context of the PW demultiplexer in use. For example, LSP Ping type should only be used=20 when MPLS is utilized as the PSN. =20 Thanks, Raman R DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 =09 ------_=_NextPart_001_01C831A0.6D5A403E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Tom,=20 Raman and all,
My=20 understanding of the original question was (please correct me if I got = something=20 wrong):
Can LSP ping in VCCV be used to verify = the PW=20 connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for transport = and the=20 PW label (bound to the appropriate PW Id or Generalized PW Id FEC) for = PW=20 demultiplexing? And is such a verification required if the IP = connectivity to=20 the remote device is OK?
IMHO the answer is:
  • Such=20 a verification makes sense (the PW = demuxing=20 in the remote box can go wrong even if the IP transport brings the PW = packets=20 to the correct remote box)
  • LSP=20 Ping in VCCV is the appropriate (and, AFAIK, the only) way to perform=20 it.
Did I miss something?
 
Regards,
       &nbs= p;          =20 Sasha

From: Thomas Nadeau=20 [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, November 27, = 2007=20 4:26 PM
To: Raman Rangaswamy
Cc: pwe3@ietf.org; = Vijayanand C=20 - TLS, Chennai.
Subject: Re: [PWE3] Is VCCV LSP Ping to test = only MPLS=20 PWs over MPLS PSN ?


Hi=20 ,
Can = I conclude=20 from the below draft sections that
“LSP Ping should=20 be used to test MPLS PWs over MPLS PSN = and
it = does not=20 applicable to test MPLS PWs over IP PSN(Say GRE=20 tunnel).”

VCCV = should=20 always be used to test the PW layer regardless of the PW 
type or encapsulation, and the appropriate tools for the lower = layer to=20 test those. 
So use LSP ping/trace for MPLS LSPs, and ICMP echo for = IP/l2tp 
tunnels/paths.


--Tom


Draft:=20 draft-ietf-pwe3-vccv-15
Section 3 : The CV types include LSP Ping [RFC4379] for =
MPLS
PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 =
PWs. 
 
Section =
4: The various =
VCCV CV types supported are used only when they apply to =
the
context of the PW demultiplexer in use.  For example, LSP =
Ping type should only be used 
when MPLS is utilized as the =
PSN.
 =
Thanks, Raman=20 R
DISCLAIMER:
------------------------------------------= -------------------------------------------------------------------------= ----

The=20 contents of this e-mail and any attachment(s) are confidential = and=20 intended for the named recipient(s) only.
It shall not attach = any=20 liability on the originator or HCL or its affiliates. Any views = or=20 opinions presented in 
this email are = solely those=20 of the author and may not necessarily reflect the opinions of = HCL or its=20 affiliates.
Any form of reproduction, dissemination, copying, = disclosure, modification, distribution and / or publication = of 
this message = without the=20 prior written consent of the author of this e-mail is strictly=20 prohibited. If you have
received this email in error please = delete it=20 and notify the sender immediately. Before opening any mail = and 
attachments = please check=20 them for viruses and=20 = defect.

----------------------------------------------------------= -------------------------------------------------------------
<= /TD>
_______________________________________________<= BR>pwe3=20 mailing list
pwe3@ietf.org
https://www1.ietf.or= g/mailman/listinfo/pwe3

------_=_NextPart_001_01C831A0.6D5A403E-- --===============1643743608== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1643743608==-- From pwe3-bounces@ietf.org Wed Nov 28 05:52:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKWu-0004pd-4V; Wed, 28 Nov 2007 05:52:32 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxKWt-0004pV-3s for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:52:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKWs-0004pK-Ne for pwe3@ietf.org; Wed, 28 Nov 2007 05:52:30 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxKWr-0002LY-SG for pwe3@ietf.org; Wed, 28 Nov 2007 05:52:30 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 28 Nov 2007 05:52:29 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lASAqTfD003409; Wed, 28 Nov 2007 05:52:29 -0500 Received: from 53.245.168.192.in-addr.arpa (rtp-vpn2-20.cisco.com [10.82.240.20]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lASAqR0i001567; Wed, 28 Nov 2007 10:52:28 GMT Message-ID: <474D486C.9090108@cisco.com> Date: Wed, 28 Nov 2007 10:52:28 +0000 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Yaakov Stein Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw References: <457D36D9D89B5B47BC06DA869B1C815D05B14176@exrad3.ad.rad.co.il> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D05B14176@exrad3.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7004; t=1196247149; x=1197111149; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[PWE3]=20draft-bryant-filsfils-fat-pw |Sender:=20 |To:=20Yaakov=20Stein=20; bh=Dtfm7IOkNia6HGY57zqwD3DmvrPluqPeExXKQxDbhAs=; b=zxY8qsHxlBrmD9IHGA+3p+AWUZ2LidZOt+qX+xLeofernZ9DTwddODsmxMjeu4zy7uSDBEaQ LL4CBNG+B3cdUXhvz0xHNk/y06kxBQA/4B6hfJdR861IfeLe9k9lcYIC; Authentication-Results: rtp-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 2.6 (++) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yaakov Stein wrote: > Stewart and other authors > > I just finished reading the FAT-PW draft, and have a few > comments/questions. > > 1. The draft says "Operators have requested the ability..." > Since I have never heard this request from any of the operators > with which we work, > can this be changed to "Some operators have requested ..." ? > Since there is one operator on the author list, I guess we can > guess which operator has requested > this feature ! OK. > > 2. The example given is for Ethernet PWs. Is this draft limited to > this case? > There is discussion of whether it is limited to IP over Ethernet, > but this more basic question is not addressed. > For example, could this load balancing to be performed for ATM PWs > based on the AAL5 flows? The most pressing demand is Ethernet, since Ethernet has a higher potential access b/w to core b/w ratio than any of the other PWs we have designed. However whilst I see less need to deploy the technology with other PW types, I see no reason to limit the draft to Ethernet. For example, I suppose we might need to use this for some data center connectivity such as Fibre Channel. > > 3. PWs are an emulation of the native service. > Why is this emulation being called upon to deliver a feature NOT > present in the native service ? > Doesn't this break the model a bit? The issue is to try to increase the effective core to edge bandwidth ratio. In architecture terms you could consider that the NSP broke the native service into a number of flow groups and then multiplexed flows onto a number of parallel PWs. The issue is then whether we then map these flow groups onto a number of pseudowires (multi PW label approach) or a single PW with some form of multiplexing indicator. So I think that the multiple PW label approach is entirely consistent with RFC3985. However I think that the load balance label approach results in better load balancing, and uses fewer MPLS FIB entries. > > 4. A native service processing function is required for > differentiating between different flows > at ingress. If this draft is indeed limited to Ethernet PWs, such a > processing function > already exists in the native service. 802.3 clause 43 (LAG) defines > conversations > for exactly this purpose (commonly implemented by hashing IP > addresses and port numbers), > and even mentions the use of load balancing in the distribution of > conversations over links. > I think this function should be at least referenced. We were not aware of that. Please can you provide us with a reference and we will take a look at it (and of course add it to the draft). > > 5. My greatest problem is with the prefered mode of section 1.1, > which builds a PW label stack under the MPLS label stack. > The proposal is for 2 PW labels (once again, somewhat breaking > RFC3985). > Figure 2 is not completely clear about the label structure. > There are two possibilities: > 1) both load balancing label and PW label have stack bit set. (I > hope not !) No - this would defeat the load balancers! > 2) the load balancing label has S=1, and the PW label has S=0. > So formally, the PW label seems to be an MPLS label. > Both possibilities break the standard model. This is the case we propose, and I agree that it is not covered by RFC3985 and that an extension is needed. However the PW label (outer label) still is the one that the egress PE processes just as it does today and it is this label that provides the context. However the operation identified by the context needs to be changed from strip PW label and CW and sent to interface X (maybe with some VLAN operation), to strip (PW label and LB label (without looking at it) ) and continue as before. > > I would certainly like to see more justification of the problem > before breaking the model in this way. > Perhaps a short requirements document is in order? > OK we will provide some more context in the draft. There is more context in the slide deck that will be presented. > 6. The draft recommends generating a load balancing label in such fashion > that the entropy is high. This assumes that the precise form of > the label > is used to determine the load balancing path (possibly a hash of > some sort). > Could this mechanism, even if beyond the scope of the document, be > explained a bit more ? Discussion of the MPLS label stack hash mechanism has always been a sensitive subject in the IETF. Clearly our assumption is that the label with the S-bit = 1 is a component of the hash for non-IP packets, and I think this is common across the P router vendors. Certainly of all the labels in the stack, the one with the S bit =1 is the only one that a PW is able to influence. However the draft does need some more text on this subject and this can be added. > > 7. With the optional mode of section 1.2 several PW labels are mapped > to a single AC. > I have no problem with this approach. In fact, I feel that it is > somewhat similar to the solutions being proposed for PW protection. > For PW protection two labels mapped to the AC or end-user > application, > where one label belongs to the active PW, and the other to the > backup PW (not being used). > For load balancing two or more PWs, all in active state, are > mapped to the same AC. With hindsight I think that we need to make this the default mechanism, (for backward compatibility reasons) although I am concerned that it will not work as well as mechanism described in section 1.1 which has much better statistical properties. > Would it be possible to integrate the two features into one mechanism > for mapping multiple PW labels in either active or backup state to > one AC or end-user identifier? I need to think about this. > > 8. The term VC as opposed to PW is used in various places in the document. > I am not sure what is meant here. Is the intent that a "VC" is one > of the paths of the > load-balanced "PW" ? It is the term used in RFC4447. We well take a look at where we used it and add some clarification. > > The first paragraph of section 4 seems to imply that the authors are > willing to settle > on either of the modes rather than both. I would support the PW label > mode. It's difficult. One mode is MUCH better than two, but the mode that is more powerful needs an extension to RFC3985 and requires a change to the PE design. PWE3 WG needs to discuss the issues and form a conclusion. Lets digest the issue and form considered opinion on the best way to go forward. > If some entropy-rich information needs to be placed in the packet, > perhaps the flags in the CW could be used (if 16 paths is sufficient). That does not work - please see RFC4928. - Stewart _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 28 08:47:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNFj-0005zj-D6; Wed, 28 Nov 2007 08:46:59 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxNFh-0005nc-Kw for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:46:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNFh-0005mc-AI for pwe3@ietf.org; Wed, 28 Nov 2007 08:46:57 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNFg-0002DG-4z for pwe3@ietf.org; Wed, 28 Nov 2007 08:46:57 -0500 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lASDknf16422; Wed, 28 Nov 2007 08:46:49 -0500 (EST) Received: from [10.83.216.148] (rtp-cpignata-vpn3.cisco.com [10.83.216.148]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with SMTP id lASDl2u20027; Wed, 28 Nov 2007 08:47:02 -0500 (EST) Message-ID: <474D713F.7090104@cisco.com> Date: Wed, 28 Nov 2007 08:46:39 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Sasha Vainshtein Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? References: In-Reply-To: X-Enigmail-Version: 0.95.5 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ X-Spam-Score: -4.0 (----) X-Scan-Signature: 876202f9cbc0933cffbc58102e40f8f2 Cc: Raman Rangaswamy , pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1426265085==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1426265085== Content-Type: multipart/alternative; boundary="------------050202010404080009070308" This is a multi-part message in MIME format. --------------050202010404080009070308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id lASDknf16422 Hi, On 11/28/2007 4:23 AM, Sasha Vainshtein said the following: > Tom, Raman and all, > My understanding of the original question was (please correct me if I > got something wrong): > > /Can LSP ping in VCCV be used to verify the PW connectivity if it > uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW > label (bound to the appropriate PW Id or Generalized PW Id FEC) > for PW demultiplexing? And is such a verification required if the > IP connectivity to the remote device is OK?/ > > IMHO the answer is: > > * > Such a verification *makes* *sense* (the PW demuxing in the > remote box can go wrong even if the IP transport brings the PW > packets to the correct remote box) > * > LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way > to perform it. > > Did I miss something? I don't think you missed anything. I understood the question (and answer) the same way. The relevant text is the one that Raman originally quoted, i.e.: The various VCCV CV Types supported are used only when they apply to the context of the PW demultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS is utilized as the PSN. However, it is unfortunate that the example (intended to clarify) might be source of confusion. The key is "/only when they apply to the context of the PW demultiplexer in use/", so LSP Ping applies when using MPLS Labels as PW Demultiplexer. The wording chosen in the second sentence (the example) might not be the best to convey the intended meaning. Would it help if the second sentence was reworded from: For example, the LSP Ping CV Type should only be used when MPLS is utilized as the PSN. to: For example, the LSP Ping CV Type should only be used when MPLS Labels are utilized as PW Demultiplexer. I think that this does not change the intended meaning, but instead it narrows and clarifies the wording of the example, and there's still time for such wording change. Thanks, --Carlos. > =20 > Regards, > Sasha > > -----------------------------------------------------------------------= - > *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] > *Sent:* Tuesday, November 27, 2007 4:26 PM > *To:* Raman Rangaswamy > *Cc:* pwe3@ietf.org; Vijayanand C - TLS, Chennai. > *Subject:* Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS > PSN ? > > >> Hi , >> Can I conclude from the below draft sections that >> =E2=80=9CLSP Ping should be used to test MPLS PWs over MPLS PSN and >> it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).=E2= =80=9D > > VCCV should always be used to test the PW layer regardless of the PW=20 > type or encapsulation, and the appropriate tools for the lower layer > to test those.=20 > So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=20 > tunnels/paths. > > > --Tom > > >> *Draft: draft-ietf-pwe3-vccv-15* >> *Section 3 : *The CV types include LSP Ping [RFC4379] for MPLS >> PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs.=20 >> =20 >> *Section 4:* The various VCCV CV types supported are used only when th= ey apply to the >> context of the PW demultiplexer in use. For example, LSP Ping type sh= ould only be used=20 >> when MPLS is utilized as the PSN. >> =20 >> Thanks, >> *Raman R* >> DISCLAIMER: >> ----------------------------------------------------------------------= ------------------------------------------------- >> >> The contents of this e-mail and any attachment(s) are confidential >> and intended for the named recipient(s) only. >> It shall not attach any liability on the originator or HCL or its >> affiliates. Any views or opinions presented in=20 >> this email are solely those of the author and may not necessarily >> reflect the opinions of HCL or its affiliates. >> Any form of reproduction, dissemination, copying, disclosure, >> modification, distribution and / or publication of=20 >> this message without the prior written consent of the author of this >> e-mail is strictly prohibited. If you have >> received this email in error please delete it and notify the sender >> immediately. Before opening any mail and=20 >> attachments please check them for viruses and defect. >> >> ----------------------------------------------------------------------= ------------------------------------------------- >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 > > -----------------------------------------------------------------------= - > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > =20 --=20 --Carlos Pignataro. Escalation RTP - cisco Systems --------------050202010404080009070308 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id lASDknf16422 Hi,

On 11/28/2007 4:23 AM, Sasha Vainshtein said the following:
Tom, Raman and all,
My understanding of the original question was (please correct me if I got something wrong):
Can LSP ping in VCCV be used to verify the PW connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW label (bound to the appropriate PW Id or Generalized PW Id FEC) for PW demultiplexing? And is such a verification required if the IP connectivity to the remote device is OK?<= /em>
IMHO the answer is:
  • Such a verification makes sense (the PW demuxing in the remote box can go wrong even if the IP transport brings the PW packets to the correct remote box)
  • LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way to perform it.
Did=C2=A0I=C2=A0miss=C2=A0something?<= /font>
I don't think you missed anything. I understood the question (and answer) the same way.
The relevant text is the one that Raman originally quoted, i.e.:
   The various VCCV CV Types
   supported are used only when they apply to the context of the PW
   demultiplexer in use.  For example, the LSP Ping CV Type should only
   be used when MPLS is utilized as the PSN.
However, it is unfortunate that the example (intended to clarify) might be source of confusion. The key is "only when they apply to the context of the PW demultiplexer in use", so LSP Ping applies when using MPLS Labels as PW Demultiplexer. The wording chosen in the second sentence (the example) might not be the best to convey the intended meaning. Would it help if the second sentence was reworded from:
   For example, the LSP Ping CV Type should only
   be used when MPLS is utilized as the PSN.
to:
   For example, the LSP Ping CV Type should only
   be used when MPLS Labels are utilized as PW Demultiplexer.
I think that this does not change the intended meaning, but instead it narrows and clarifies the wording of the example, and there's still time for such wording change.

Thanks,

--Carlos.

=C2=A0
Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Sasha

From: Thoma= s Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, November 27, 2007 4:26 PM
To: Raman Rangaswamy
Cc: pwe3@ietf.org; Vijayanand C - TLS, Chennai.
Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ?


=
Hi ,
Can= I conclude from the below draft sections that
=E2= =80=9CLSP Ping should be used to test MPLS PWs over MPLS PSN and<= /font>
it = does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).=E2=80=9D

= VCCV should always be used to test the PW layer regardless of the PW=C2=A0
type or encapsulation, and the appropriate tools for the lower layer to test those.=C2=A0
So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=C2=A0=
tunnels/paths.


= --Tom


Draft: draft-ietf-pwe3-vccv-15
Section 3 : The CV types =
include LSP Ping [RFC4379] for MPLS
PWs, and ICMP=
 Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. 
=C2=A0
Section 4: The various =
VCCV CV types supported are used only when they apply to the
context of th=
e PW demultiplexer in use.=C2=A0 For example, LSP Ping type should only b=
e used 
when MPLS is =
utilized as the PSN.
Thanks,=
Raman R
DISCLAIMER:
-------------------------------------------------------------------------= ----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=C2=A0
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=C2=A0
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and=C2=A0
attachments please check them for viruses and defect.

-------------------------------------------------------------------------= ----------------------------------------------
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/pwe3


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

--=20
--Carlos Pignataro.
Escalation RTP - cisco Systems
--------------050202010404080009070308-- --===============1426265085== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1426265085==-- From pwe3-bounces@ietf.org Wed Nov 28 08:55:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNO8-000785-SN; Wed, 28 Nov 2007 08:55:40 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxNO7-00077r-FY for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:55:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNO7-00077e-5S for pwe3@ietf.org; Wed, 28 Nov 2007 08:55:39 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNO5-0003Dn-R4 for pwe3@ietf.org; Wed, 28 Nov 2007 08:55:39 -0500 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lASDtW317263; Wed, 28 Nov 2007 08:55:32 -0500 (EST) Received: from [10.83.216.148] (rtp-cpignata-vpn3.cisco.com [10.83.216.148]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with SMTP id lASDtou02609; Wed, 28 Nov 2007 08:55:51 -0500 (EST) Message-ID: <474D7350.1020708@cisco.com> Date: Wed, 28 Nov 2007 08:55:28 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Sasha Vainshtein Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? References: <474D713F.7090104@cisco.com> In-Reply-To: <474D713F.7090104@cisco.com> X-Enigmail-Version: 0.95.5 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bd14a31ed5bce9138736cf0e98bb014 Cc: Raman Rangaswamy , pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1499301227==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1499301227== Content-Type: multipart/alternative; boundary="------------020501050303090708030405" This is a multi-part message in MIME format. --------------020501050303090708030405 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id lASDtW317263 On 11/28/2007 8:46 AM, Carlos Pignataro said the following: > Hi, > > On 11/28/2007 4:23 AM, Sasha Vainshtein said the following: >> Tom, Raman and all, >> My understanding of the original question was (please correct me if I >> got something wrong): >> >> /Can LSP ping in VCCV be used to verify the PW connectivity if it >> uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW >> label (bound to the appropriate PW Id or Generalized PW Id FEC) >> for PW demultiplexing? And is such a verification required if the >> IP connectivity to the remote device is OK?/ >> >> IMHO the answer is: >> >> * >> Such a verification *makes* *sense* (the PW demuxing in the >> remote box can go wrong even if the IP transport brings the PW >> packets to the correct remote box) >> * >> LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way >> to perform it. >> >> Did I miss something? > I don't think you missed anything. I understood the question (and > answer) the same way. > The relevant text is the one that Raman originally quoted, i.e.: > The various VCCV CV Types > supported are used only when they apply to the context of the PW > demultiplexer in use. For example, the LSP Ping CV Type should only > be used when MPLS is utilized as the PSN. > However, it is unfortunate that the example (intended to clarify) > might be source of confusion. The key is "/only when they apply to the > context of the PW demultiplexer in use/", so LSP Ping applies when > using MPLS Labels as PW Demultiplexer. To add to this, the same can be inferred from Figures 1 and 2 (relevant snips below), the reference model and protocol stack, although it might help reword the example; | |<---------- VCCV ---------->| | | |<------- Pseudowire ------->| | | | | | | | |<-- PSN Tunnel -->| | | ... +-------------+ +-------------+ | | VCCV/PW | | |Demultiplexer| < Control Channel > |Demultiplexer| +-------------+ +-------------+ | PSN | < PSN Tunnel > | PSN | +-------------+ +-------------+ Thanks, --Carlos. > The wording chosen in the second sentence (the example) might not be > the best to convey the intended meaning. Would it help if the second > sentence was reworded from: > For example, the LSP Ping CV Type should only > be used when MPLS is utilized as the PSN. > to: > For example, the LSP Ping CV Type should only > be used when MPLS Labels are utilized as PW Demultiplexer. > I think that this does not change the intended meaning, but instead it > narrows and clarifies the wording of the example, and there's still > time for such wording change. > > Thanks, > > --Carlos. > >> =20 >> Regards, >> Sasha >> >> ----------------------------------------------------------------------= -- >> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> *Sent:* Tuesday, November 27, 2007 4:26 PM >> *To:* Raman Rangaswamy >> *Cc:* pwe3@ietf.org; Vijayanand C - TLS, Chennai. >> *Subject:* Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over >> MPLS PSN ? >> >> >>> Hi , >>> Can I conclude from the below draft sections that >>> =E2=80=9CLSP Ping should be used to test MPLS PWs over MPLS PSN and >>> it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).=E2= =80=9D >> >> VCCV should always be used to test the PW layer regardless of the PW=20 >> type or encapsulation, and the appropriate tools for the lower layer >> to test those.=20 >> So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=20 >> tunnels/paths. >> >> >> >> --Tom >> >> >>> *Draft: draft-ietf-pwe3-vccv-15* >>> *Section 3 : *The CV types include LSP Ping [RFC4379] for MPLS >>> PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs.=20 >>> =20 >>> *Section 4:* The various VCCV CV types supported are used only when t= hey apply to the >>> context of the PW demultiplexer in use. For example, LSP Ping type s= hould only be used=20 >>> when MPLS is utilized as the PSN. >>> =20 >>> Thanks, >>> *Raman R* >>> DISCLAIMER: >>> ---------------------------------------------------------------------= -------------------------------------------------- >>> >>> The contents of this e-mail and any attachment(s) are confidential >>> and intended for the named recipient(s) only. >>> It shall not attach any liability on the originator or HCL or its >>> affiliates. Any views or opinions presented in=20 >>> this email are solely those of the author and may not necessarily >>> reflect the opinions of HCL or its affiliates. >>> Any form of reproduction, dissemination, copying, disclosure, >>> modification, distribution and / or publication of=20 >>> this message without the prior written consent of the author of this >>> e-mail is strictly prohibited. If you have >>> received this email in error please delete it and notify the sender >>> immediately. Before opening any mail and=20 >>> attachments please check them for viruses and defect. >>> >>> ---------------------------------------------------------------------= -------------------------------------------------- >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> =20 > > --=20 > --Carlos Pignataro. > Escalation RTP - cisco Systems > -----------------------------------------------------------------------= - > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 > =20 --=20 --Carlos Pignataro. Escalation RTP - cisco Systems --------------020501050303090708030405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id lASDtW317263

On 11/28/2007 8:46 AM, Carlos Pignataro said the following:
Hi,

On 11/28/2007 4:23 AM, Sasha Vainshtein said the following:
Tom, Raman and all,
My understanding of the original question was (please correct me if I got something wrong):
Can LSP ping in VCCV be used to verify the PW connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW label (bound to the appropriate PW Id or Generalized PW Id FEC) for PW demultiplexing? And is such a verification required if the IP connectivity to the remote device is OK?<= /em>
IMHO the answer is:
  • Such a verification makes sense (the PW demuxing in the remote box can go wrong even if the IP transport brings the PW packets to the correct remote box)
  • LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way to perform it.
<= font color=3D"#0000ff">Did=C2=A0I=C2=A0miss=C2=A0something?<= /font>
I don't think you missed anything. I understood the question (and answer) the same way.
The relevant text is the one that Raman originally quoted, i.e.:
   The various VCCV CV Types
   supported are used only when they apply to the context of the PW
   demultiplexer in use.  For example, the LSP Ping CV Type should only
   be used when MPLS is utilized as the PSN.
However, it is unfortunate that the example (intended to clarify) might be source of confusion. The key is "only when they apply to the context of the PW demultiplexer in use", so LSP Ping applies when using MPLS Labels as PW Demultiplexer.
To add to this, the same can be inferred from Figures 1 and 2 (relevant snips below), the reference model and protocol stack, although it might help reword the example;
            |          |<---------- VCCV ---------->|         =
 |
            |          |<------- Pseudowire ------->|          |
            |          |                            |          |
            |          |    |<-- PSN Tunnel -->|    |          |
...
       +-------------+                                +-------------=
+
       |             |            VCCV/PW             |             |
       |Demultiplexer|       < Control Channel >      |Demultiplexe=
r|
       +-------------+                                +-------------+
       |    PSN      |          < PSN Tunnel >        |    PSN     =
 |
       +-------------+                                +-------------+
Thanks,

--Carlos.
The wording chosen in the second sentence (the example) might not be the best to convey the intended meaning. Would it help if the second sentence was reworded from:
   For example, the LSP Ping CV Type should only
   be used when MPLS is utilized as the PSN.
to:
   For example, the LSP Ping CV Type should only
   be used when MPLS Labels are utilized as PW Demultiplexer.
I think that this does not change the intended meaning, but instead it narrows and clarifies the wording of the example, and there's still time for such wording change.

Thanks,

--Carlos.

=C2=A0
Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Sasha

From: Tho= mas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, November 27, 2007 4:26 PM
To: Raman Rangaswamy
Cc: pwe3@ie= tf.org; Vijayanand C - TLS, Chennai.
Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ?


Hi ,
Can= I conclude from the below draft sections that
=E2= =80=9CLSP Ping should be used to test MPLS PWs over MPLS PSN and<= /font>
it = does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).=E2=80=9D

VCCV should always be used to test the PW layer regardless of the PW=C2=A0
type or encapsulation, and the appropriate tools for the lower layer to test those.=C2=A0
So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=C2= =A0
tunnels/paths.


--Tom


Draft: draft-ietf-pwe3-vccv-15
Section 3 : The CV types =
include LSP Ping [RFC4379] for MPLS
PWs, and ICMP=
 Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. 
=C2=A0
Section 4: The various =
VCCV CV types supported are used only when they apply to the
context of th=
e PW demultiplexer in use.=C2=A0 For example, LSP Ping type should only b=
e used 
when MPLS is =
utilized as the PSN.
Thanks,=
Raman R
DISCLAIMER: -------------------------------------------------------------------------= ----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=C2=A0
this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=C2=A0
this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and=C2=A0
attachments please check them for viruses and defect.

-------------------------------------------------------------------------= ----------------------------------------------
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/pwe3


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

--=20
--Carlos Pignataro.
Escalation RTP - cisco Systems

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

--=20
--Carlos Pignataro.
Escalation RTP - cisco Systems
--------------020501050303090708030405-- --===============1499301227== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1499301227==-- From pwe3-bounces@ietf.org Wed Nov 28 08:56:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNPM-0007rp-3H; Wed, 28 Nov 2007 08:56:56 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxNPJ-0007qW-QD for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 08:56:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNPJ-0007qH-Cf for pwe3@ietf.org; Wed, 28 Nov 2007 08:56:53 -0500 Received: from mxa5.qos.net.il ([80.74.96.15] helo=mxa6.qos.net.il) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxNPI-000835-A2 for pwe3@ietf.org; Wed, 28 Nov 2007 08:56:53 -0500 Received: from mail.axerra.com (webmail.axerra.com [80.74.100.75]) by mxa6.qos.net.il (Postfix) with ESMTP id 4A32B5FEC49 for ; Wed, 28 Nov 2007 15:02:25 +0200 (IST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Date: Wed, 28 Nov 2007 15:56:21 +0200 Message-ID: In-Reply-To: <474D713F.7090104@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Thread-Index: AcgxxUXQ3vziqio7T1WQgYWii9ITXAAAK6hQ From: "Sasha Vainshtein" To: "Carlos Pignataro" , "Thomas Nadeau" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b Cc: Mark Townsley , Raman Rangaswamy , pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0444981577==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0444981577== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C831C6.9293BB20" This is a multi-part message in MIME format. ------_=_NextPart_001_01C831C6.9293BB20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Carlos and all, Adding Mark (as the shepherding AD) to the CC list. =20 I think that the wording you've proposed would substantially improve the readability of the document. =20 Tom, Could you possibly re-phrase as per Carlos suggestion during the AUTH48 phase? =20 Regards, Sasha =20 ________________________________ From: Carlos Pignataro [mailto:cpignata@cisco.com]=20 Sent: Wednesday, November 28, 2007 3:47 PM To: Sasha Vainshtein Cc: Thomas Nadeau; Raman Rangaswamy; pwe3@ietf.org; Vijayanand C - TLS, Chennai. Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Hi, On 11/28/2007 4:23 AM, Sasha Vainshtein said the following:=20 Tom, Raman and all, My understanding of the original question was (please correct me if I got something wrong): Can LSP ping in VCCV be used to verify the PW connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW label (bound to the appropriate PW Id or Generalized PW Id FEC) for PW demultiplexing? And is such a verification required if the IP connectivity to the remote device is OK? IMHO the answer is: *=09 Such a verification makes sense (the PW demuxing in the remote box can go wrong even if the IP transport brings the PW packets to the correct remote box) *=09 LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way to perform it. Did I miss something? I don't think you missed anything. I understood the question (and answer) the same way. The relevant text is the one that Raman originally quoted, i.e.: The various VCCV CV Types supported are used only when they apply to the context of the PW demultiplexer in use. For example, the LSP Ping CV Type should only be used when MPLS is utilized as the PSN. However, it is unfortunate that the example (intended to clarify) might be source of confusion. The key is "only when they apply to the context of the PW demultiplexer in use", so LSP Ping applies when using MPLS Labels as PW Demultiplexer. The wording chosen in the second sentence (the example) might not be the best to convey the intended meaning. Would it help if the second sentence was reworded from: For example, the LSP Ping CV Type should only be used when MPLS is utilized as the PSN. to: For example, the LSP Ping CV Type should only be used when MPLS Labels are utilized as PW Demultiplexer. I think that this does not change the intended meaning, but instead it narrows and clarifies the wording of the example, and there's still time for such wording change. Thanks, --Carlos. =20 Regards, Sasha ________________________________ From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Tuesday, November 27, 2007 4:26 PM To: Raman Rangaswamy Cc: pwe3@ietf.org; Vijayanand C - TLS, Chennai. Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? =09 =09 =09 =09 Hi , =09 Can I conclude from the below draft sections that "LSP Ping should be used to test MPLS PWs over MPLS PSN and it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel)." VCCV should always be used to test the PW layer regardless of the PW=20 type or encapsulation, and the appropriate tools for the lower layer to test those.=20 So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=20 tunnels/paths. =09 =09 =09 --Tom =09 =09 =09 =09 Draft: draft-ietf-pwe3-vccv-15 Section 3 : The CV types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs.=20 =20 Section 4: The various VCCV CV types supported are used only when they apply to the context of the PW demultiplexer in use. For example, LSP Ping type should only be used=20 when MPLS is utilized as the PSN. =20 Thanks, Raman R DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- =09 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 =09 =09 ________________________________ _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 =20 --=20 --Carlos Pignataro. Escalation RTP - cisco Systems ------_=_NextPart_001_01C831C6.9293BB20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Carlos=20 and all,
Adding=20 Mark (as the shepherding AD) to the CC list.
 
I=20 think that the wording you've proposed would substantially improve the=20 readability of the document.
 
Tom,
Could=20 you possibly re-phrase as per Carlos suggestion during the AUTH48=20 phase?
 
Regards,
          &nbs= p;            = ;    =20 Sasha
 

From: Carlos Pignataro=20 [mailto:cpignata@cisco.com]
Sent: Wednesday, November 28, = 2007 3:47=20 PM
To: Sasha Vainshtein
Cc: Thomas Nadeau; Raman = Rangaswamy;=20 pwe3@ietf.org; Vijayanand C - TLS, Chennai.
Subject: Re: = [PWE3] Is=20 VCCV LSP Ping to test only MPLS PWs over MPLS PSN ?

Hi,

On 11/28/2007 4:23 AM, Sasha Vainshtein said the=20 following:=20
Tom,=20 Raman and all,
My=20 understanding of the original question was (please correct me if I got = something wrong):
Can LSP ping in VCCV be used to = verify the PW=20 connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for = transport and=20 the PW label (bound to the appropriate PW Id or Generalized PW Id = FEC) for=20 PW demultiplexing? And is such a verification required if the IP=20 connectivity to the remote device is = OK?
IMHO the answer is:
  • Such a verification = makes=20 sense (the PW demuxing in the remote box can go = wrong even=20 if the IP transport brings the PW packets to the correct remote=20 box)
  • LSP Ping in VCCV is the appropriate (and, = AFAIK,=20 the only) way to perform it.
Did I miss something?
<= /BLOCKQUOTE>I=20 don't think you missed anything. I understood the question (and answer) = the same=20 way.
The relevant text is the one that Raman originally quoted, = i.e.:
   The various VCCV CV Types
   supported are used only when they apply to the context of the PW
   demultiplexer in use.  For example, the LSP Ping CV Type should only
   be used when MPLS is utilized as the PSN.
However, it is = unfortunate=20 that the example (intended to clarify) might be source of confusion. The = key is=20 "only when they apply to the context of the PW demultiplexer in = use", so=20 LSP Ping applies when using MPLS Labels as PW Demultiplexer. The wording = chosen=20 in the second sentence (the example) might not be the best to convey the = intended meaning. Would it help if the second sentence was reworded = from:
   For example, the LSP Ping CV Type should only
   be used when MPLS is utilized as the PSN.
to:
   For =
example, the LSP Ping CV Type should only
   be used when MPLS Labels are utilized as PW Demultiplexer.
I = think that=20 this does not change the intended meaning, but instead it narrows and = clarifies=20 the wording of the example, and there's still time for such wording=20 change.

Thanks,

--Carlos.

 
Regards,
       &nbs= p;          =20 Sasha

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20
Sent: Tuesday, November 27, 2007 4:26 PM
To: = Raman=20 Rangaswamy
Cc: pwe3@ietf.org; Vijayanand C - TLS,=20 Chennai.
Subject: Re: [PWE3] Is VCCV LSP Ping to test only = MPLS PWs=20 over MPLS PSN ?


Hi=20 ,
Can I conclude=20 from the below draft sections that
“LSP Ping should=20 be used to test MPLS PWs over MPLS PSN = and it = does not=20 applicable to test MPLS PWs over IP PSN(Say GRE=20 tunnel).”

VCCV should=20 always be used to test the PW layer regardless of the PW 
type or encapsulation, and the appropriate tools for the lower = layer to=20 test those. 
So use LSP ping/trace for MPLS LSPs, and ICMP echo for=20 IP/l2tp 
tunnels/paths.


--Tom


Draft:=20 draft-ietf-pwe3-vccv-15
Section 3 : The CV types include LSP Ping [RFC4379] for =
MPLS
PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 =
PWs. 
 
Section =
4: The various =
VCCV CV types supported are used only when they apply to =
the
context of the PW demultiplexer in use.  For example, LSP =
Ping type should only be used 
when MPLS is utilized as the =
PSN.
 =
Thanks, Raman=20 R
DISCLAIMER:
------------------------------------------= -------------------------------------------------------------------------= ----

The=20 contents of this e-mail and any attachment(s) are confidential = and=20 intended for the named recipient(s) only.
It shall not = attach any=20 liability on the originator or HCL or its affiliates. Any = views or=20 opinions presented in 
this email are = solely=20 those of the author and may not necessarily reflect the = opinions of=20 HCL or its affiliates.
Any form of reproduction, = dissemination,=20 copying, disclosure, modification, distribution and / or = publication=20 of 
this = message=20 without the prior written consent of the author of this e-mail = is=20 strictly prohibited. If you have
received this email in = error=20 please delete it and notify the sender immediately. Before = opening any=20 mail and 
attachments=20 please check them for viruses and=20 = defect.

----------------------------------------------------------= -------------------------------------------------------------
<= /TD>
_______________________________________________<= BR>pwe3=20 mailing list
pwe3@ietf.org
https://www1.ietf.org/mailman/listinfo/pwe3<= BR>


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

--=20
--Carlos Pignataro.
Escalation RTP - cisco Systems
------_=_NextPart_001_01C831C6.9293BB20-- --===============0444981577== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0444981577==-- From pwe3-bounces@ietf.org Wed Nov 28 09:13:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNf0-0008Et-On; Wed, 28 Nov 2007 09:13:06 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxNey-0008E3-Fl for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:13:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxNey-0008Dq-5z for pwe3@ietf.org; Wed, 28 Nov 2007 09:13:04 -0500 Received: from hen.cisco.com ([64.102.19.198] helo=av-tac-rtp.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxNex-000521-G5 for pwe3@ietf.org; Wed, 28 Nov 2007 09:13:04 -0500 X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost [127.0.0.1]) by av-tac-rtp.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id lASECv118990; Wed, 28 Nov 2007 09:12:57 -0500 (EST) Received: from [10.83.216.148] (rtp-cpignata-vpn3.cisco.com [10.83.216.148]) by rooster.cisco.com (8.11.7p3+Sun/8.11.7) with SMTP id lASEDJu05384; Wed, 28 Nov 2007 09:13:19 -0500 (EST) Message-ID: <474D7768.9080408@cisco.com> Date: Wed, 28 Nov 2007 09:12:56 -0500 From: Carlos Pignataro Organization: cisco Systems, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Sasha Vainshtein Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? References: In-Reply-To: X-Enigmail-Version: 0.95.5 X-Face: *3w8NvnQ|kS~V{&{U}$?G9U9EJQ8p9)O[1[1F'1i>XIc$5FR!hdAIf5}'Xu-3`^Z']h0J* ccB'fl/XJYR[+,Z+jj`4%06nd'y9[ln&ScJT5S+O18e^ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by av-tac-rtp.cisco.com id lASECv118990 X-Spam-Score: -4.0 (----) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Raman Rangaswamy , pwe3@ietf.org, "Vijayanand C - TLS, Chennai." , Mark Townsley X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Sasha, VCCV is now in AUTH48, so timing couldn't be better :) I'll send in this change to the RFC Editor (I believe it's an editorial, to clarify/narrow the example's wording), but I'll wait a bit in case there's other comment= s. Thank you, and thanks Raman for finding this room for improvement :) --Carlos. On 11/28/2007 8:56 AM, Sasha Vainshtein said the following: > Carlos and all, > Adding Mark (as the shepherding AD) to the CC list. > =20 > I think that the wording you've proposed would substantially improve th= e > readability of the document. > =20 > Tom, > Could you possibly re-phrase as per Carlos suggestion during the AUTH48 > phase? > =20 > Regards, > Sasha > =20 >=20 > -----------------------------------------------------------------------= - > *From:* Carlos Pignataro [mailto:cpignata@cisco.com] > *Sent:* Wednesday, November 28, 2007 3:47 PM > *To:* Sasha Vainshtein > *Cc:* Thomas Nadeau; Raman Rangaswamy; pwe3@ietf.org; Vijayanand C - > TLS, Chennai. > *Subject:* Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS = PSN ? >=20 > Hi, >=20 > On 11/28/2007 4:23 AM, Sasha Vainshtein said the following: >> Tom, Raman and all, >> My understanding of the original question was (please correct me if I >> got something wrong): >> >> /Can LSP ping in VCCV be used to verify the PW connectivity if it >> uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW >> label (bound to the appropriate PW Id or Generalized PW Id FEC) >> for PW demultiplexing? And is such a verification required if the >> IP connectivity to the remote device is OK?/ >> >> IMHO the answer is: >> >> * >> Such a verification *makes* *sense* (the PW demuxing in the >> remote box can go wrong even if the IP transport brings the PW >> packets to the correct remote box) >> * >> LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way >> to perform it. >> >> Did I miss something? > I don't think you missed anything. I understood the question (and > answer) the same way. > The relevant text is the one that Raman originally quoted, i.e.: >=20 > The various VCCV CV Types > supported are used only when they apply to the context of the PW > demultiplexer in use. For example, the LSP Ping CV Type should only > be used when MPLS is utilized as the PSN. >=20 > However, it is unfortunate that the example (intended to clarify) might > be source of confusion. The key is "/only when they apply to the contex= t > of the PW demultiplexer in use/", so LSP Ping applies when using MPLS > Labels as PW Demultiplexer. The wording chosen in the second sentence > (the example) might not be the best to convey the intended meaning. > Would it help if the second sentence was reworded from: >=20 > For example, the LSP Ping CV Type should only > be used when MPLS is utilized as the PSN. >=20 > to: >=20 > For example, the LSP Ping CV Type should only > be used when MPLS Labels are utilized as PW Demultiplexer. >=20 > I think that this does not change the intended meaning, but instead it > narrows and clarifies the wording of the example, and there's still tim= e > for such wording change. >=20 > Thanks, >=20 > --Carlos. >=20 >> =20 >> Regards, >> Sasha >> >> ----------------------------------------------------------------------= -- >> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> *Sent:* Tuesday, November 27, 2007 4:26 PM >> *To:* Raman Rangaswamy >> *Cc:* pwe3@ietf.org; Vijayanand C - TLS, Chennai. >> *Subject:* Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS >> PSN ? >> >> >>> Hi , >>> Can I conclude from the below draft sections that >>> =E2=80=9CLSP Ping should be used to test MPLS PWs over MPLS PSN and >>> it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).=E2= =80=9D >> >> VCCV should always be used to test the PW layer regardless of the PW=20 >> type or encapsulation, and the appropriate tools for the lower layer >> to test those.=20 >> So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=20 >> tunnels/paths. >> >> >> --Tom >> >> >>> *Draft: draft-ietf-pwe3-vccv-15* >>> *Section 3 : *The CV types include LSP Ping [RFC4379] for MPLS >>> PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs.=20 >>> =20 >>> *Section 4:* The various VCCV CV types supported are used only when t= hey apply to the >>> context of the PW demultiplexer in use. For example, LSP Ping type s= hould only be used=20 >>> when MPLS is utilized as the PSN. >>> =20 >>> Thanks, >>> *Raman R* >>> DISCLAIMER: >>> ---------------------------------------------------------------------= -------------------------------------------------- >>> >>> The contents of this e-mail and any attachment(s) are confidential >>> and intended for the named recipient(s) only. >>> It shall not attach any liability on the originator or HCL or its >>> affiliates. Any views or opinions presented in=20 >>> this email are solely those of the author and may not necessarily >>> reflect the opinions of HCL or its affiliates. >>> Any form of reproduction, dissemination, copying, disclosure, >>> modification, distribution and / or publication of=20 >>> this message without the prior written consent of the author of this >>> e-mail is strictly prohibited. If you have >>> received this email in error please delete it and notify the sender >>> immediately. Before opening any mail and=20 >>> attachments please check them for viruses and defect. >>> >>> ---------------------------------------------------------------------= -------------------------------------------------- >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> ----------------------------------------------------------------------= -- >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> =20 >=20 > --=20 > --Carlos Pignataro. > Escalation RTP - cisco Systems >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 --=20 --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 28 09:47:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOCN-000524-SR; Wed, 28 Nov 2007 09:47:35 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxOCM-00051f-8g for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 09:47:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOCL-00051K-Tu for pwe3@ietf.org; Wed, 28 Nov 2007 09:47:33 -0500 Received: from dog.tcb.net ([64.78.150.133]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxOCK-0006oE-Tr for pwe3@ietf.org; Wed, 28 Nov 2007 09:47:33 -0500 Received: by dog.tcb.net (Postfix, from userid 0) id 75579268081; Wed, 28 Nov 2007 07:47:32 -0700 (MST) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Wed, 28 Nov 2007 07:47:32 -0700 (MST) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=60427; data-bytes=0 Message-ID: <474D7F83.3040101@castlepoint.net> Date: Wed, 28 Nov 2007 07:47:31 -0700 From: Shane Amante User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Yaakov Stein Subject: Re: [PWE3] draft-bryant-filsfils-fat-pw References: <457D36D9D89B5B47BC06DA869B1C815D05B14176@exrad3.ad.rad.co.il> In-Reply-To: <457D36D9D89B5B47BC06DA869B1C815D05B14176@exrad3.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: pwe3@ietf.org X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Hi Yaakov, Yaakov Stein wrote: > Stewart and other authors > > I just finished reading the FAT-PW draft, and have a few comments/questions. > > 1. The draft says "Operators have requested the ability..." > Since I have never heard this request from any of the operators with > which we work, > can this be changed to "Some operators have requested ..." ? > Since there is one operator on the author list, I guess we can guess > which operator has requested > this feature ! Speaking as /another/ operator, I can say there is an absolutely strong need to solve this problem, (and, has been for quite a long time, actually). Consider the fact that 10 GbE has become (is becoming?) a pretty common access circuit to Backbones and that within most SP networks the dominant Backbone link size are 10G. As you're likely well aware, the IEEE HSSG is working on both 40 GbE and 100 GbE. Once 40 GbE is available, (and assuming its used for WAN connectivity, perhaps similar to 10 GbE LAN PHY), then OC-768c Backbone links will suffer the same problem. 100 GbE will, eventually, be used as both core and access links. In short, this problem is not going away. We need to solve it. > 2. The example given is for Ethernet PWs. Is this draft limited to this > case? > There is discussion of whether it is limited to IP over Ethernet, > but this more basic question is not addressed. > For example, could this load balancing to be performed for ATM PWs > based on the AAL5 flows? From my perspective, Ethernet is far and away the biggest "problem child" out there today, due to the size of access to Backbone links, (see above). While it may be admirable to look at making this draft "generic" for a variety of PW types, I wouldn't lose any sleep if this draft remained focused on just Ethernet. > 3. PWs are an emulation of the native service. > Why is this emulation being called upon to deliver a feature NOT > present in the native service ? > Doesn't this break the model a bit? > > 4. A native service processing function is required for differentiating > between different flows > at ingress. If this draft is indeed limited to Ethernet PWs, such a > processing function > already exists in the native service. 802.3 clause 43 (LAG) defines > conversations > for exactly this purpose (commonly implemented by hashing IP > addresses and port numbers), > and even mentions the use of load balancing in the distribution of > conversations over links. > I think this function should be at least referenced. > > 5. My greatest problem is with the prefered mode of section 1.1, > which builds a PW label stack under the MPLS label stack. > The proposal is for 2 PW labels (once again, somewhat breaking RFC3985). > Figure 2 is not completely clear about the label structure. > There are two possibilities: > 1) both load balancing label and PW label have stack bit set. (I > hope not !) > 2) the load balancing label has S=1, and the PW label has S=0. > So formally, the PW label seems to be an MPLS label. > Both possibilities break the standard model. > > I would certainly like to see more justification of the problem > before breaking the model in this way. > Perhaps a short requirements document is in order? When I read the draft, this is the part I also had the most concern with. In particular, I like the "simplicity" of the LB Label approach (i.e.: savings on FIB space, no need to signal first and last labels for each PW, etc.); however, I am concerned about the implications of, or potential need to, define a 'generic' MPLS PW label. My primary concern is future extensibility. Specifically, in case there are /other/ applications, which may or may not have been brought to the surface, yet, that may have similar needs/desire for a 2nd PW label. If that ultimately means we gain consensus to amend the PWE3 Architecture, I'm OK with that, but certainly we would need to have more discussion to see whether or not it is a good approach and, more importantly, what are the other implications that go along with it? > 6. The draft recommends generating a load balancing label in such fashion > that the entropy is high. This assumes that the precise form of the > label > is used to determine the load balancing path (possibly a hash of > some sort). > Could this mechanism, even if beyond the scope of the document, be > explained a bit more ? Load-balancing over LAG and ECMP paths, using some number of MPLS labels as input to a load-balancing hash algorithm, is common across all vendors. However, such algorithms are 'proprietary' to each vendor. I'm not sure how much more can be said other than the fact that, one would strongly prefer that the output of a LAG or ECMP hashing algorithm is spread out among the largest number of hash buckets, (as is practical), to get the most even distribution of flows across a set of N links in a LAG or ECMP path. And, I think the draft already makes this point, in Section 3: ---snip--- It is recommended that the method chosen to generate the load balancing labels introduces a high degree of entropy in their values, to maximise the entropy presented to the ECMP path selection mechanism in the LSRs in the PSN, and hence distribute the flows as evenly as possible over the available PSN ECMP paths. ---snip--- Is there something else you had in mind? -shane > 7. With the optional mode of section 1.2 several PW labels are mapped to > a single AC. > I have no problem with this approach. In fact, I feel that it is > somewhat similar to the solutions being proposed for PW protection. > For PW protection two labels mapped to the AC or end-user application, > where one label belongs to the active PW, and the other to the > backup PW (not being used). > For load balancing two or more PWs, all in active state, are mapped > to the same AC. > Would it be possible to integrate the two features into one mechanism > for mapping multiple PW labels in either active or backup state to > one AC or end-user identifier? > > 8. The term VC as opposed to PW is used in various places in the document. > I am not sure what is meant here. Is the intent that a "VC" is one > of the paths of the > load-balanced "PW" ? > > The first paragraph of section 4 seems to imply that the authors are > willing to settle > on either of the modes rather than both. I would support the PW label mode. > If some entropy-rich information needs to be placed in the packet, > perhaps the flags in the CW could be used (if 16 paths is sufficient). > > Y(J)S > > > > ------------------------------------------------------------------------ > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www1.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 28 10:07:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOVw-0000Gj-4H; Wed, 28 Nov 2007 10:07:48 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxKW0-0004f6-FA for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 05:51:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxKVz-0004bU-Aj for pwe3@ietf.org; Wed, 28 Nov 2007 05:51:35 -0500 Received: from gws04.hcl.in ([203.105.186.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxKVx-0002HU-HI for pwe3@ietf.org; Wed, 28 Nov 2007 05:51:35 -0500 Received: from gws04.hcl.in (gws04 [10.249.64.135]) by localhost.hcl.in (Postfix) with ESMTP id 61B993670E5; Wed, 28 Nov 2007 16:21:30 +0530 (IST) Received: from chn-egw01-out.corp.hcl.in (unknown [10.249.64.37])by gws04.hcl.in (Postfix) with ESMTPid 24F943670C1; Wed, 28 Nov 2007 16:21:30 +0530 (IST) Received: from CHN-HCLT-EVS02.HCLT.CORP.HCL.IN ([10.101.26.16]) by chn-egw01-out.corp.hcl.in with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 16:21:29 +0530 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Date: Wed, 28 Nov 2007 16:21:24 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Thread-Index: AcgxAXrMTcugO4dnRhK3jnZou7f5VQAndFOAAAJRCrA= References: From: "Raman Rangaswamy" To: "Sasha Vainshtein" , "Thomas Nadeau" X-OriginalArrivalTime: 28 Nov 2007 10:51:29.0261 (UTC) FILETIME=[A16F21D0:01C831AC] X-imss-version: 2.049 X-imss-result: Passed X-imss-scanInfo: M:T L:E SM:1 X-imss-tmaseResult: TT:1 TS:-22.0158 TC:1F TRN:95 TV:5.0.1023(15572.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: d7967c711acf4eec6f9b62d49dcc5a34 X-Mailman-Approved-At: Wed, 28 Nov 2007 10:07:47 -0500 Cc: pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1815632176==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============1815632176== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C831AC.A1488AE0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C831AC.A1488AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha & Tom, =20 Thanks for your input.=20 =20 Sasha, your understanding of the question is correct.. =20 Regds, Raman ________________________________ From: Sasha Vainshtein [mailto:Sasha@AXERRA.com]=20 Sent: Wednesday, November 28, 2007 2:53 PM To: Thomas Nadeau; Raman Rangaswamy Cc: pwe3@ietf.org; Vijayanand C - TLS, Chennai. Subject: RE: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? =20 Tom, Raman and all, My understanding of the original question was (please correct me if I got something wrong): Can LSP ping in VCCV be used to verify the PW connectivity if it uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW label (bound to the appropriate PW Id or Generalized PW Id FEC) for PW demultiplexing? And is such a verification required if the IP connectivity to the remote device is OK? IMHO the answer is: * Such a verification makes sense (the PW demuxing in the remote box can go wrong even if the IP transport brings the PW packets to the correct remote box) * LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way to perform it. Did I miss something? =20 Regards, Sasha =20 ________________________________ From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]=20 Sent: Tuesday, November 27, 2007 4:26 PM To: Raman Rangaswamy Cc: pwe3@ietf.org; Vijayanand C - TLS, Chennai. Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? =20 =09 Hi , Can I conclude from the below draft sections that "LSP Ping should be used to test MPLS PWs over MPLS PSN and it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel)." =20 VCCV should always be used to test the PW layer regardless of the PW=20 type or encapsulation, and the appropriate tools for the lower layer to test those.=20 So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp=20 tunnels/paths. =20 =20 --Tom =20 Draft: draft-ietf-pwe3-vccv-15 Section 3 : The CV types include LSP Ping [RFC4379] for MPLS PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs.=20 =20 Section 4: The various VCCV CV types supported are used only when they apply to the context of the PW demultiplexer in use. For example, LSP Ping type should only be used=20 when MPLS is utilized as the PSN. =20 Thanks, Raman R DISCLAIMER: ------------------------------------------------------------------------ ----------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in=20 this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of=20 this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and=20 attachments please check them for viruses and defect. ------------------------------------------------------------------------ ----------------------------------------------- _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 =20 ------_=_NextPart_001_01C831AC.A1488AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha & = Tom,

 

Thanks for your input. =

 

Sasha, your understanding of the = question is correct..

 

=

Regds,

=

Raman

From: Sasha = Vainshtein [mailto:Sasha@AXERRA.com]
Sent: Wednesday, November = 28, 2007 2:53 PM
To: Thomas Nadeau; = Raman Rangaswamy
Cc: pwe3@ietf.org; = Vijayanand C - TLS, Chennai.
Subject: RE: [PWE3] Is = VCCV LSP Ping to test only MPLS PWs over MPLS PSN = ?

 

Tom, Raman and = all,

My understanding of the original = question was (please correct me if I got something = wrong):

Can LSP ping in = VCCV be used to verify the PW connectivity if it uses, say, MPLS-in-IP or = MPLS-in-GRE for transport and the PW label (bound to the appropriate PW Id or = Generalized PW Id FEC) for PW demultiplexing? And is such a verification required if = the IP connectivity to the remote device is = OK?

IMHO the answer = is:

  • Such a = verification makes sense (the PW demuxing in the remote box can go wrong even if the IP = transport brings the PW packets to the correct remote = box)
  • LSP Ping in = VCCV is the appropriate (and, AFAIK, the only) way to perform = it.

Did I miss something?=

 

Regards,

      =              Sasha

 

From: Thomas Nadeau [mailto:tnadeau@lucidvision.com]
Sent: Tuesday, November = 27, 2007 4:26 PM
To: Raman Rangaswamy
Cc: pwe3@ietf.org; = Vijayanand C - TLS, Chennai.
Subject: Re: [PWE3] Is = VCCV LSP Ping to test only MPLS PWs over MPLS PSN = ?

 

Hi ,

Can I conclude from = the below draft sections that

“LSP Ping should be used to = test MPLS PWs over MPLS PSN and

it does not applicable to test = MPLS PWs over IP PSN(Say GRE tunnel).”

 

VCCV should always be used to test the PW layer regardless of = the PW 

type or encapsulation, and the appropriate tools for the lower = layer to test those. 

So use LSP ping/trace for MPLS LSPs, and ICMP echo for = IP/l2tp 

tunnels/paths.

 

 

--Tom

 



Draft: draft-ietf-pwe3-vccv-15

Section 3 : The CV types include LSP Ping =
[RFC4379] for MPLS
PWs, and ICMP Ping [RFC0792] =
[RFC4443] for both MPLS and L2TPv3 PWs. 
 
Section =
4: The various VCCV CV types =
supported are used only when they apply to =
the
context of the PW =
demultiplexer in use.  For example, LSP Ping type should only be =
used 
when MPLS is utilized as the =
PSN.

Thanks,

Raman R

DISCLAIMER:
= -------------------------------------------------------------------------= ----------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its = affiliates. Any views or opinions presented in 
this email are solely those of the author and may not necessarily = reflect the opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, = modification, distribution and / or publication of 
this message without the prior written consent of the author of this = e-mail is strictly prohibited. If you have
received this email in error please delete it and notify the sender immediately. Before opening any mail and 
attachments please check them for viruses and defect.

= -------------------------------------------------------------------------= ----------------------------------------------

____________= ___________________________________
pwe3 mailing list
pwe3@ietf.org
https://www1.ietf.or= g/mailman/listinfo/pwe3

 

------_=_NextPart_001_01C831AC.A1488AE0-- --===============1815632176== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============1815632176==-- From pwe3-bounces@ietf.org Wed Nov 28 10:17:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOfG-0003zX-E9; Wed, 28 Nov 2007 10:17:26 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxOfF-0003zB-GK for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 10:17:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOfF-0003yz-6Z for pwe3@ietf.org; Wed, 28 Nov 2007 10:17:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOfE-0003a6-1E for pwe3@ietf.org; Wed, 28 Nov 2007 10:17:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Nov 2007 07:17:23 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lASFHN5w024783; Wed, 28 Nov 2007 07:17:23 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lASFGdgq005313; Wed, 28 Nov 2007 15:17:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 10:17:06 -0500 Received: from rtp-townsley-vpn1.cisco.com ([10.83.1.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 10:17:05 -0500 Message-ID: <474D867C.2060306@cisco.com> Date: Wed, 28 Nov 2007 16:17:16 +0100 From: Mark Townsley User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Sasha Vainshtein Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 28 Nov 2007 15:17:05.0807 (UTC) FILETIME=[BC5B11F0:01C831D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5817; t=1196263043; x=1197127043; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[PWE3]=20Is=20VCCV=20LSP=20Ping=20to=20test=20only=20 MPLS=20PWs=20over=20MPLS=20PSN=20? |Sender:=20; bh=AfN2Cv2oAWn+5j8kjHngNaHWuHY7205FapVw3XWkeuw=; b=QWxqSOfnt8eN15hbxbWUA6AHPSeQzcTMWMCAI/CMLUhwrUHez0VcjRxwy4NNY79oA10YnFSJ 0FjuYly1uZzaSEz1WN+Y9B6wcYhCC8driUOSFbLpIt1GW9rRcwysx/6+; Authentication-Results: sj-dkim-4; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Carlos Pignataro , Raman Rangaswamy , pwe3@ietf.org, "Vijayanand C - TLS, Chennai." X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: pwe3-bounces@ietf.org Yes Carlos, I think your wording is more accurate. Thanks. - Mark Sasha Vainshtein wrote: > Carlos and all, > Adding Mark (as the shepherding AD) to the CC list. > I think that the wording you've proposed would substantially improve > the readability of the document. > Tom, > Could you possibly re-phrase as per Carlos suggestion during the > AUTH48 phase? > Regards, > Sasha > > ------------------------------------------------------------------------ > *From:* Carlos Pignataro [mailto:cpignata@cisco.com] > *Sent:* Wednesday, November 28, 2007 3:47 PM > *To:* Sasha Vainshtein > *Cc:* Thomas Nadeau; Raman Rangaswamy; pwe3@ietf.org; Vijayanand C - > TLS, Chennai. > *Subject:* Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS > PSN ? > > Hi, > > On 11/28/2007 4:23 AM, Sasha Vainshtein said the following: >> Tom, Raman and all, >> My understanding of the original question was (please correct me if I >> got something wrong): >> >> /Can LSP ping in VCCV be used to verify the PW connectivity if it >> uses, say, MPLS-in-IP or MPLS-in-GRE for transport and the PW >> label (bound to the appropriate PW Id or Generalized PW Id FEC) >> for PW demultiplexing? And is such a verification required if the >> IP connectivity to the remote device is OK?/ >> >> IMHO the answer is: >> >> * >> Such a verification *makes* *sense* (the PW demuxing in the >> remote box can go wrong even if the IP transport brings the PW >> packets to the correct remote box) >> * >> LSP Ping in VCCV is the appropriate (and, AFAIK, the only) way >> to perform it. >> >> Did I miss something? > I don't think you missed anything. I understood the question (and > answer) the same way. > The relevant text is the one that Raman originally quoted, i.e.: > The various VCCV CV Types > supported are used only when they apply to the context of the PW > demultiplexer in use. For example, the LSP Ping CV Type should only > be used when MPLS is utilized as the PSN. > However, it is unfortunate that the example (intended to clarify) > might be source of confusion. The key is "/only when they apply to the > context of the PW demultiplexer in use/", so LSP Ping applies when > using MPLS Labels as PW Demultiplexer. The wording chosen in the > second sentence (the example) might not be the best to convey the > intended meaning. Would it help if the second sentence was reworded from: > For example, the LSP Ping CV Type should only > be used when MPLS is utilized as the PSN. > to: > For example, the LSP Ping CV Type should only > be used when MPLS Labels are utilized as PW Demultiplexer. > I think that this does not change the intended meaning, but instead it > narrows and clarifies the wording of the example, and there's still > time for such wording change. > > Thanks, > > --Carlos. > >> Regards, >> Sasha >> >> ------------------------------------------------------------------------ >> *From:* Thomas Nadeau [mailto:tnadeau@lucidvision.com] >> *Sent:* Tuesday, November 27, 2007 4:26 PM >> *To:* Raman Rangaswamy >> *Cc:* pwe3@ietf.org; Vijayanand C - TLS, Chennai. >> *Subject:* Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over >> MPLS PSN ? >> >> >>> Hi , >>> Can I conclude from the below draft sections that >>> “LSP Ping should be used to test MPLS PWs over MPLS PSN and >>> it does not applicable to test MPLS PWs over IP PSN(Say GRE tunnel).” >> >> VCCV should always be used to test the PW layer regardless of the PW >> type or encapsulation, and the appropriate tools for the lower layer >> to test those. >> So use LSP ping/trace for MPLS LSPs, and ICMP echo for IP/l2tp >> tunnels/paths. >> >> >> --Tom >> >> >>> *Draft: draft-ietf-pwe3-vccv-15* >>> *Section 3 : *The CV types include LSP Ping [RFC4379] for MPLS >>> PWs, and ICMP Ping [RFC0792] [RFC4443] for both MPLS and L2TPv3 PWs. >>> >>> *Section 4:* The various VCCV CV types supported are used only when they apply to the >>> context of the PW demultiplexer in use. For example, LSP Ping type should only be used >>> when MPLS is utilized as the PSN. >>> >>> Thanks, >>> *Raman R* >>> DISCLAIMER: >>> ----------------------------------------------------------------------------------------------------------------------- >>> >>> The contents of this e-mail and any attachment(s) are confidential >>> and intended for the named recipient(s) only. >>> It shall not attach any liability on the originator or HCL or its >>> affiliates. Any views or opinions presented in >>> this email are solely those of the author and may not necessarily >>> reflect the opinions of HCL or its affiliates. >>> Any form of reproduction, dissemination, copying, disclosure, >>> modification, distribution and / or publication of >>> this message without the prior written consent of the author of this >>> e-mail is strictly prohibited. If you have >>> received this email in error please delete it and notify the sender >>> immediately. Before opening any mail and >>> attachments please check them for viruses and defect. >>> >>> ----------------------------------------------------------------------------------------------------------------------- >>> >>> _______________________________________________ >>> pwe3 mailing list >>> pwe3@ietf.org >>> https://www1.ietf.org/mailman/listinfo/pwe3 >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www1.ietf.org/mailman/listinfo/pwe3 >> > > -- > --Carlos Pignataro. > Escalation RTP - cisco Systems _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 From pwe3-bounces@ietf.org Wed Nov 28 16:10:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUB7-0002xz-8L; Wed, 28 Nov 2007 16:10:41 -0500 Received: from pwe3 by megatron.ietf.org with local (Exim 4.43) id 1IxUB5-0002vL-I2 for pwe3-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 16:10:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUB4-0002sH-Gh for pwe3@ietf.org; Wed, 28 Nov 2007 16:10:38 -0500 Received: from audl751.usa.alcatel.com ([143.209.238.164]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxU9u-0001Py-J8 for pwe3@ietf.org; Wed, 28 Nov 2007 16:09:28 -0500 Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id lASL99Cp022751; Wed, 28 Nov 2007 15:09:10 -0600 Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.7]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 28 Nov 2007 15:09:09 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Date: Wed, 28 Nov 2007 15:09:09 -0600 Message-ID: <4A5028372622294A99B8FFF6BD06EB7B039104BB@USDALSMBS03.ad3.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PWE3] Is VCCV LSP Ping to test only MPLS PWs over MPLS PSN ? Thread-Index: AcgxyNbFVPFh5ouPQ9GAx0RCLeS9JAAOhPwg From: "AISSAOUI Mustapha" To: , X-OriginalArrivalTime: 28 Nov 2007 21:09:09.0651 (UTC) FILETIME=[EB25DE30:01C83202] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 Cc: townsley@cisco.com, ramanrs@hcl.in, pwe3@ietf.org, vijayc@hcl.in X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0279691623==" Errors-To: pwe3-bounces@ietf.org This is a multi-part message in MIME format. --===============0279691623== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C83202.EAD3467D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C83202.EAD3467D Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Q2FybG9zIGFuZCBhbGwsDQpJIGFncmVlIHRoaXMgY2xhcmlmaWNhdGlvbiBpcyBuZWNlc3Nhcnku IFdlIGFscmVhZHkgaGF2ZSBkZXBsb3llZCBpbXBsZW1lbnRhdGlvbiB1c2luZyBMU1AgUGluZyBD ViB0eXBlIGZvciBQVyBvdmVyIEdSRSB0dW5uZWxzLg0KDQpNdXN0YXBoYS4NClNlbnQgZnJvbSBt eSBCbGFja2JlcnJ5IQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBDYXJs b3MgUGlnbmF0YXJvIDxjcGlnbmF0YUBjaXNjby5jb20+DQpUbzogU2FzaGEgVmFpbnNodGVpbiA8 U2FzaGFAQVhFUlJBLmNvbT4NCkNjOiBSYW1hbiBSYW5nYXN3YW15IDxyYW1hbnJzQGhjbC5pbj47 IHB3ZTNAaWV0Zi5vcmcgPHB3ZTNAaWV0Zi5vcmc+OyBWaWpheWFuYW5kIEMgLSBUTFMsQ2hlbm5h aS4gPHZpamF5Y0BoY2wuaW4+OyBNYXJrIFRvd25zbGV5IDx0b3duc2xleUBjaXNjby5jb20+DQpT ZW50OiBXZWQgTm92IDI4IDA4OjEyOjU2IDIwMDcNClN1YmplY3Q6IFJlOiBbUFdFM10gSXMgVkND ViBMU1AgUGluZyB0byB0ZXN0IG9ubHkgTVBMUyBQV3Mgb3ZlciBNUExTIFBTTiA/DQoNCkhpIFNh c2hhLA0KDQpWQ0NWIGlzIG5vdyBpbiBBVVRINDgsIHNvIHRpbWluZyBjb3VsZG4ndCBiZSBiZXR0 ZXIgOikgSSdsbCBzZW5kIGluIHRoaXMNCmNoYW5nZSB0byB0aGUgUkZDIEVkaXRvciAoSSBiZWxp ZXZlIGl0J3MgYW4gZWRpdG9yaWFsLCB0byBjbGFyaWZ5L25hcnJvdw0KdGhlIGV4YW1wbGUncyB3 b3JkaW5nKSwgYnV0IEknbGwgd2FpdCBhIGJpdCBpbiBjYXNlIHRoZXJlJ3Mgb3RoZXIgY29tbWVu dHMuDQpUaGFuayB5b3UsIGFuZCB0aGFua3MgUmFtYW4gZm9yIGZpbmRpbmcgdGhpcyByb29tIGZv ciBpbXByb3ZlbWVudCA6KQ0KDQotLUNhcmxvcy4NCg0KT24gMTEvMjgvMjAwNyA4OjU2IEFNLCBT YXNoYSBWYWluc2h0ZWluIHNhaWQgdGhlIGZvbGxvd2luZzoNCj4gQ2FybG9zIGFuZCBhbGwsDQo+ IEFkZGluZyBNYXJrIChhcyB0aGUgc2hlcGhlcmRpbmcgQUQpIHRvIHRoZSBDQyBsaXN0Lg0KPiAg DQo+IEkgdGhpbmsgdGhhdCB0aGUgd29yZGluZyB5b3UndmUgcHJvcG9zZWQgd291bGQgc3Vic3Rh bnRpYWxseSBpbXByb3ZlIHRoZQ0KPiByZWFkYWJpbGl0eSBvZiB0aGUgZG9jdW1lbnQuDQo+ICAN Cj4gVG9tLA0KPiBDb3VsZCB5b3UgcG9zc2libHkgcmUtcGhyYXNlIGFzIHBlciBDYXJsb3Mgc3Vn Z2VzdGlvbiBkdXJpbmcgdGhlIEFVVEg0OA0KPiBwaGFzZT8NCj4gIA0KPiBSZWdhcmRzLA0KPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU2FzaGENCj4gIA0KPiANCj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ICpGcm9tOiogQ2FybG9zIFBpZ25hdGFybyBbbWFpbHRvOmNwaWduYXRhQGNpc2NvLmNv bV0NCj4gKlNlbnQ6KiBXZWRuZXNkYXksIE5vdmVtYmVyIDI4LCAyMDA3IDM6NDcgUE0NCj4gKlRv OiogU2FzaGEgVmFpbnNodGVpbg0KPiAqQ2M6KiBUaG9tYXMgTmFkZWF1OyBSYW1hbiBSYW5nYXN3 YW15OyBwd2UzQGlldGYub3JnOyBWaWpheWFuYW5kIEMgLQ0KPiBUTFMsIENoZW5uYWkuDQo+ICpT dWJqZWN0OiogUmU6IFtQV0UzXSBJcyBWQ0NWIExTUCBQaW5nIHRvIHRlc3Qgb25seSBNUExTIFBX cyBvdmVyIE1QTFMgUFNOID8NCj4gDQo+IEhpLA0KPiANCj4gT24gMTEvMjgvMjAwNyA0OjIzIEFN LCBTYXNoYSBWYWluc2h0ZWluIHNhaWQgdGhlIGZvbGxvd2luZzoNCj4+IFRvbSwgUmFtYW4gYW5k IGFsbCwNCj4+IE15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIG9yaWdpbmFsIHF1ZXN0aW9uIHdhcyAo cGxlYXNlIGNvcnJlY3QgbWUgaWYgSQ0KPj4gZ290IHNvbWV0aGluZyB3cm9uZyk6DQo+Pg0KPj4g ICAgIC9DYW4gTFNQIHBpbmcgaW4gVkNDViBiZSB1c2VkIHRvIHZlcmlmeSB0aGUgUFcgY29ubmVj dGl2aXR5IGlmIGl0DQo+PiAgICAgdXNlcywgc2F5LCBNUExTLWluLUlQIG9yIE1QTFMtaW4tR1JF IGZvciB0cmFuc3BvcnQgYW5kIHRoZSBQVw0KPj4gICAgIGxhYmVsIChib3VuZCB0byB0aGUgYXBw cm9wcmlhdGUgUFcgSWQgb3IgR2VuZXJhbGl6ZWQgUFcgSWQgRkVDKQ0KPj4gICAgIGZvciBQVyBk ZW11bHRpcGxleGluZz8gQW5kIGlzIHN1Y2ggYSB2ZXJpZmljYXRpb24gcmVxdWlyZWQgaWYgdGhl DQo+PiAgICAgSVAgY29ubmVjdGl2aXR5IHRvIHRoZSByZW1vdGUgZGV2aWNlIGlzIE9LPy8NCj4+ DQo+PiBJTUhPIHRoZSBhbnN3ZXIgaXM6DQo+Pg0KPj4gICAgKg0KPj4gICAgICAgU3VjaCBhIHZl cmlmaWNhdGlvbiAqbWFrZXMqICpzZW5zZSogKHRoZSBQVyBkZW11eGluZyBpbiB0aGUNCj4+ICAg ICAgIHJlbW90ZSBib3ggY2FuIGdvIHdyb25nIGV2ZW4gaWYgdGhlIElQIHRyYW5zcG9ydCBicmlu Z3MgdGhlIFBXDQo+PiAgICAgICBwYWNrZXRzIHRvIHRoZSBjb3JyZWN0IHJlbW90ZSBib3gpDQo+ PiAgICAqDQo+PiAgICAgICBMU1AgUGluZyBpbiBWQ0NWIGlzIHRoZSBhcHByb3ByaWF0ZSAoYW5k LCBBRkFJSywgdGhlIG9ubHkpIHdheQ0KPj4gICAgICAgdG8gcGVyZm9ybSBpdC4NCj4+DQo+PiBE aWQgSSBtaXNzIHNvbWV0aGluZz8NCj4gSSBkb24ndCB0aGluayB5b3UgbWlzc2VkIGFueXRoaW5n LiBJIHVuZGVyc3Rvb2QgdGhlIHF1ZXN0aW9uIChhbmQNCj4gYW5zd2VyKSB0aGUgc2FtZSB3YXku DQo+IFRoZSByZWxldmFudCB0ZXh0IGlzIHRoZSBvbmUgdGhhdCBSYW1hbiBvcmlnaW5hbGx5IHF1 b3RlZCwgaS5lLjoNCj4gDQo+ICAgIFRoZSB2YXJpb3VzIFZDQ1YgQ1YgVHlwZXMNCj4gICAgc3Vw cG9ydGVkIGFyZSB1c2VkIG9ubHkgd2hlbiB0aGV5IGFwcGx5IHRvIHRoZSBjb250ZXh0IG9mIHRo ZSBQVw0KPiAgICBkZW11bHRpcGxleGVyIGluIHVzZS4gIEZvciBleGFtcGxlLCB0aGUgTFNQIFBp bmcgQ1YgVHlwZSBzaG91bGQgb25seQ0KPiAgICBiZSB1c2VkIHdoZW4gTVBMUyBpcyB1dGlsaXpl ZCBhcyB0aGUgUFNOLg0KPiANCj4gSG93ZXZlciwgaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCB0aGUg ZXhhbXBsZSAoaW50ZW5kZWQgdG8gY2xhcmlmeSkgbWlnaHQNCj4gYmUgc291cmNlIG9mIGNvbmZ1 c2lvbi4gVGhlIGtleSBpcyAiL29ubHkgd2hlbiB0aGV5IGFwcGx5IHRvIHRoZSBjb250ZXh0DQo+ IG9mIHRoZSBQVyBkZW11bHRpcGxleGVyIGluIHVzZS8iLCBzbyBMU1AgUGluZyBhcHBsaWVzIHdo ZW4gdXNpbmcgTVBMUw0KPiBMYWJlbHMgYXMgUFcgRGVtdWx0aXBsZXhlci4gVGhlIHdvcmRpbmcg Y2hvc2VuIGluIHRoZSBzZWNvbmQgc2VudGVuY2UNCj4gKHRoZSBleGFtcGxlKSBtaWdodCBub3Qg YmUgdGhlIGJlc3QgdG8gY29udmV5IHRoZSBpbnRlbmRlZCBtZWFuaW5nLg0KPiBXb3VsZCBpdCBo ZWxwIGlmIHRoZSBzZWNvbmQgc2VudGVuY2Ugd2FzIHJld29yZGVkIGZyb206DQo+IA0KPiAgICBG b3IgZXhhbXBsZSwgdGhlIExTUCBQaW5nIENWIFR5cGUgc2hvdWxkIG9ubHkNCj4gICAgYmUgdXNl ZCB3aGVuIE1QTFMgaXMgdXRpbGl6ZWQgYXMgdGhlIFBTTi4NCj4gDQo+IHRvOg0KPiANCj4gICAg Rm9yIGV4YW1wbGUsIHRoZSBMU1AgUGluZyBDViBUeXBlIHNob3VsZCBvbmx5DQo+ICAgIGJlIHVz ZWQgd2hlbiBNUExTIExhYmVscyBhcmUgdXRpbGl6ZWQgYXMgUFcgRGVtdWx0aXBsZXhlci4NCj4g DQo+IEkgdGhpbmsgdGhhdCB0aGlzIGRvZXMgbm90IGNoYW5nZSB0aGUgaW50ZW5kZWQgbWVhbmlu ZywgYnV0IGluc3RlYWQgaXQNCj4gbmFycm93cyBhbmQgY2xhcmlmaWVzIHRoZSB3b3JkaW5nIG9m IHRoZSBleGFtcGxlLCBhbmQgdGhlcmUncyBzdGlsbCB0aW1lDQo+IGZvciBzdWNoIHdvcmRpbmcg Y2hhbmdlLg0KPiANCj4gVGhhbmtzLA0KPiANCj4gLS1DYXJsb3MuDQo+IA0KPj4gIA0KPj4gUmVn YXJkcywNCj4+ICAgICAgICAgICAgICAgICAgICBTYXNoYQ0KPj4NCj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4gKkZyb206KiBUaG9tYXMgTmFkZWF1IFttYWlsdG86dG5hZGVhdUBsdWNpZHZpc2lvbi5j b21dDQo+PiAqU2VudDoqIFR1ZXNkYXksIE5vdmVtYmVyIDI3LCAyMDA3IDQ6MjYgUE0NCj4+ICpU bzoqIFJhbWFuIFJhbmdhc3dhbXkNCj4+ICpDYzoqIHB3ZTNAaWV0Zi5vcmc7IFZpamF5YW5hbmQg QyAtIFRMUywgQ2hlbm5haS4NCj4+ICpTdWJqZWN0OiogUmU6IFtQV0UzXSBJcyBWQ0NWIExTUCBQ aW5nIHRvIHRlc3Qgb25seSBNUExTIFBXcyBvdmVyIE1QTFMNCj4+IFBTTiA/DQo+Pg0KPj4NCj4+ PiBIaSAsDQo+Pj4gQ2FuIEkgY29uY2x1ZGUgZnJvbSB0aGUgYmVsb3cgZHJhZnQgc2VjdGlvbnMg dGhhdA0KPj4+IOKAnExTUCBQaW5nIHNob3VsZCBiZSB1c2VkIHRvIHRlc3QgTVBMUyBQV3Mgb3Zl ciBNUExTIFBTTiBhbmQNCj4+PiBpdCBkb2VzIG5vdCBhcHBsaWNhYmxlIHRvIHRlc3QgTVBMUyBQ V3Mgb3ZlciBJUCBQU04oU2F5IEdSRSB0dW5uZWwpLuKAnQ0KPj4NCj4+IFZDQ1Ygc2hvdWxkIGFs d2F5cyBiZSB1c2VkIHRvIHRlc3QgdGhlIFBXIGxheWVyIHJlZ2FyZGxlc3Mgb2YgdGhlIFBXIA0K Pj4gdHlwZSBvciBlbmNhcHN1bGF0aW9uLCBhbmQgdGhlIGFwcHJvcHJpYXRlIHRvb2xzIGZvciB0 aGUgbG93ZXIgbGF5ZXINCj4+IHRvIHRlc3QgdGhvc2UuIA0KPj4gU28gdXNlIExTUCBwaW5nL3Ry YWNlIGZvciBNUExTIExTUHMsIGFuZCBJQ01QIGVjaG8gZm9yIElQL2wydHAgDQo+PiB0dW5uZWxz L3BhdGhzLg0KPj4NCj4+DQo+PiAtLVRvbQ0KPj4NCj4+DQo+Pj4gKkRyYWZ0OiBkcmFmdC1pZXRm LXB3ZTMtdmNjdi0xNSoNCj4+PiAqU2VjdGlvbiAzIDogKlRoZSBDViB0eXBlcyBpbmNsdWRlIExT UCBQaW5nIFtSRkM0Mzc5XSBmb3IgTVBMUw0KPj4+IFBXcywgYW5kIElDTVAgUGluZyBbUkZDMDc5 Ml0gW1JGQzQ0NDNdIGZvciBib3RoIE1QTFMgYW5kIEwyVFB2MyBQV3MuIA0KPj4+ICANCj4+PiAq U2VjdGlvbiA0OiogVGhlIHZhcmlvdXMgVkNDViBDViB0eXBlcyBzdXBwb3J0ZWQgYXJlIHVzZWQg b25seSB3aGVuIHRoZXkgYXBwbHkgdG8gdGhlDQo+Pj4gY29udGV4dCBvZiB0aGUgUFcgZGVtdWx0 aXBsZXhlciBpbiB1c2UuICBGb3IgZXhhbXBsZSwgTFNQIFBpbmcgdHlwZSBzaG91bGQgb25seSBi ZSB1c2VkIA0KPj4+IHdoZW4gTVBMUyBpcyB1dGlsaXplZCBhcyB0aGUgUFNOLg0KPj4+ICANCj4+ PiBUaGFua3MsDQo+Pj4gKlJhbWFuIFIqDQo+Pj4gRElTQ0xBSU1FUjoNCj4+PiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+ DQo+Pj4gVGhlIGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudChzKSBh cmUgY29uZmlkZW50aWFsDQo+Pj4gYW5kIGludGVuZGVkIGZvciB0aGUgbmFtZWQgcmVjaXBpZW50 KHMpIG9ubHkuDQo+Pj4gSXQgc2hhbGwgbm90IGF0dGFjaCBhbnkgbGlhYmlsaXR5IG9uIHRoZSBv cmlnaW5hdG9yIG9yIEhDTCBvciBpdHMNCj4+PiBhZmZpbGlhdGVzLiBBbnkgdmlld3Mgb3Igb3Bp bmlvbnMgcHJlc2VudGVkIGluIA0KPj4+IHRoaXMgZW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0 aGUgYXV0aG9yIGFuZCBtYXkgbm90IG5lY2Vzc2FyaWx5DQo+Pj4gcmVmbGVjdCB0aGUgb3Bpbmlv bnMgb2YgSENMIG9yIGl0cyBhZmZpbGlhdGVzLg0KPj4+IEFueSBmb3JtIG9mIHJlcHJvZHVjdGlv biwgZGlzc2VtaW5hdGlvbiwgY29weWluZywgZGlzY2xvc3VyZSwNCj4+PiBtb2RpZmljYXRpb24s IGRpc3RyaWJ1dGlvbiBhbmQgLyBvciBwdWJsaWNhdGlvbiBvZiANCj4+PiB0aGlzIG1lc3NhZ2Ug d2l0aG91dCB0aGUgcHJpb3Igd3JpdHRlbiBjb25zZW50IG9mIHRoZSBhdXRob3Igb2YgdGhpcw0K Pj4+IGUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZQ0KPj4+IHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHRoZSBz ZW5kZXINCj4+PiBpbW1lZGlhdGVseS4gQmVmb3JlIG9wZW5pbmcgYW55IG1haWwgYW5kIA0KPj4+ IGF0dGFjaG1lbnRzIHBsZWFzZSBjaGVjayB0aGVtIGZvciB2aXJ1c2VzIGFuZCBkZWZlY3QuDQo+ Pj4NCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+PiBwd2UzIG1haWxpbmcgbGlzdA0KPj4+IHB3ZTNAaWV0Zi5vcmcg PG1haWx0bzpwd2UzQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3B3ZTMNCj4+DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gcHdlMyBtYWlsaW5nIGxp c3QNCj4+IHB3ZTNAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3B3ZTMNCj4+ICAgDQo+IA0KPiAtLSANCj4gLS1DYXJsb3MgUGlnbmF0YXJvLg0KPiBF c2NhbGF0aW9uIFJUUCAtIGNpc2NvIFN5c3RlbXMNCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ IHB3ZTMgbWFpbGluZyBsaXN0DQo+IHB3ZTNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0KDQotLSANCi0tQ2FybG9zIFBpZ25hdGFyby4NCkVz Y2FsYXRpb24gUlRQIC0gY2lzY28gU3lzdGVtcw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0KcHdlM0BpZXRmLm9y Zw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMw0K ------_=_NextPart_001_01C83202.EAD3467D Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTEuNTkiPg0KPFRJVExFPlJlOiBbUFdFM10g SXMgVkNDViBMU1AgUGluZyB0byB0ZXN0IG9ubHkgTVBMUyBQV3Mgb3ZlciBNUExTIFBTTiA/PC9U SVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KPCEtLSBDb252ZXJ0ZWQgZnJvbSB0ZXh0L3BsYWluIGZv cm1hdCAtLT4NCg0KPFA+PEZPTlQgU0laRT0yPkNhcmxvcyBhbmQgYWxsLDxCUj4NCkkgYWdyZWUg dGhpcyBjbGFyaWZpY2F0aW9uIGlzIG5lY2Vzc2FyeS4gV2UgYWxyZWFkeSBoYXZlIGRlcGxveWVk IGltcGxlbWVudGF0aW9uIHVzaW5nIExTUCBQaW5nIENWIHR5cGUgZm9yIFBXIG92ZXIgR1JFIHR1 bm5lbHMuPEJSPg0KPEJSPg0KTXVzdGFwaGEuPEJSPg0KU2VudCBmcm9tIG15IEJsYWNrYmVycnkh PEJSPg0KPEJSPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj4NCkZyb206IENhcmxv cyBQaWduYXRhcm8gJmx0O2NwaWduYXRhQGNpc2NvLmNvbSZndDs8QlI+DQpUbzogU2FzaGEgVmFp bnNodGVpbiAmbHQ7U2FzaGFAQVhFUlJBLmNvbSZndDs8QlI+DQpDYzogUmFtYW4gUmFuZ2Fzd2Ft eSAmbHQ7cmFtYW5yc0BoY2wuaW4mZ3Q7OyBwd2UzQGlldGYub3JnICZsdDtwd2UzQGlldGYub3Jn Jmd0OzsgVmlqYXlhbmFuZCBDIC0gVExTLENoZW5uYWkuICZsdDt2aWpheWNAaGNsLmluJmd0Ozsg TWFyayBUb3duc2xleSAmbHQ7dG93bnNsZXlAY2lzY28uY29tJmd0OzxCUj4NClNlbnQ6IFdlZCBO b3YgMjggMDg6MTI6NTYgMjAwNzxCUj4NClN1YmplY3Q6IFJlOiBbUFdFM10gSXMgVkNDViBMU1Ag UGluZyB0byB0ZXN0IG9ubHkgTVBMUyBQV3Mgb3ZlciBNUExTIFBTTiA/PEJSPg0KPEJSPg0KSGkg U2FzaGEsPEJSPg0KPEJSPg0KVkNDViBpcyBub3cgaW4gQVVUSDQ4LCBzbyB0aW1pbmcgY291bGRu J3QgYmUgYmV0dGVyIDopIEknbGwgc2VuZCBpbiB0aGlzPEJSPg0KY2hhbmdlIHRvIHRoZSBSRkMg RWRpdG9yIChJIGJlbGlldmUgaXQncyBhbiBlZGl0b3JpYWwsIHRvIGNsYXJpZnkvbmFycm93PEJS Pg0KdGhlIGV4YW1wbGUncyB3b3JkaW5nKSwgYnV0IEknbGwgd2FpdCBhIGJpdCBpbiBjYXNlIHRo ZXJlJ3Mgb3RoZXIgY29tbWVudHMuPEJSPg0KVGhhbmsgeW91LCBhbmQgdGhhbmtzIFJhbWFuIGZv ciBmaW5kaW5nIHRoaXMgcm9vbSBmb3IgaW1wcm92ZW1lbnQgOik8QlI+DQo8QlI+DQotLUNhcmxv cy48QlI+DQo8QlI+DQpPbiAxMS8yOC8yMDA3IDg6NTYgQU0sIFNhc2hhIFZhaW5zaHRlaW4gc2Fp ZCB0aGUgZm9sbG93aW5nOjxCUj4NCiZndDsgQ2FybG9zIGFuZCBhbGwsPEJSPg0KJmd0OyBBZGRp bmcgTWFyayAoYXMgdGhlIHNoZXBoZXJkaW5nIEFEKSB0byB0aGUgQ0MgbGlzdC48QlI+DQomZ3Q7 Jm5ic3A7PEJSPg0KJmd0OyBJIHRoaW5rIHRoYXQgdGhlIHdvcmRpbmcgeW91J3ZlIHByb3Bvc2Vk IHdvdWxkIHN1YnN0YW50aWFsbHkgaW1wcm92ZSB0aGU8QlI+DQomZ3Q7IHJlYWRhYmlsaXR5IG9m IHRoZSBkb2N1bWVudC48QlI+DQomZ3Q7Jm5ic3A7PEJSPg0KJmd0OyBUb20sPEJSPg0KJmd0OyBD b3VsZCB5b3UgcG9zc2libHkgcmUtcGhyYXNlIGFzIHBlciBDYXJsb3Mgc3VnZ2VzdGlvbiBkdXJp bmcgdGhlIEFVVEg0ODxCUj4NCiZndDsgcGhhc2U/PEJSPg0KJmd0OyZuYnNwOzxCUj4NCiZndDsg UmVnYXJkcyw8QlI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFNhc2hhPEJSPg0KJmd0OyZuYnNwOzxCUj4NCiZndDs8QlI+DQomZ3Q7 IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLTxCUj4NCiZndDsgKkZyb206KiBDYXJsb3MgUGlnbmF0YXJvIFs8QSBI UkVGPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIj5tYWlsdG86Y3BpZ25hdGFAY2lzY28uY29t PC9BPl08QlI+DQomZ3Q7ICpTZW50OiogV2VkbmVzZGF5LCBOb3ZlbWJlciAyOCwgMjAwNyAzOjQ3 IFBNPEJSPg0KJmd0OyAqVG86KiBTYXNoYSBWYWluc2h0ZWluPEJSPg0KJmd0OyAqQ2M6KiBUaG9t YXMgTmFkZWF1OyBSYW1hbiBSYW5nYXN3YW15OyBwd2UzQGlldGYub3JnOyBWaWpheWFuYW5kIEMg LTxCUj4NCiZndDsgVExTLCBDaGVubmFpLjxCUj4NCiZndDsgKlN1YmplY3Q6KiBSZTogW1BXRTNd IElzIFZDQ1YgTFNQIFBpbmcgdG8gdGVzdCBvbmx5IE1QTFMgUFdzIG92ZXIgTVBMUyBQU04gPzxC Uj4NCiZndDs8QlI+DQomZ3Q7IEhpLDxCUj4NCiZndDs8QlI+DQomZ3Q7IE9uIDExLzI4LzIwMDcg NDoyMyBBTSwgU2FzaGEgVmFpbnNodGVpbiBzYWlkIHRoZSBmb2xsb3dpbmc6PEJSPg0KJmd0OyZn dDsgVG9tLCBSYW1hbiBhbmQgYWxsLDxCUj4NCiZndDsmZ3Q7IE15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIG9yaWdpbmFsIHF1ZXN0aW9uIHdhcyAocGxlYXNlIGNvcnJlY3QgbWUgaWYgSTxCUj4NCiZn dDsmZ3Q7IGdvdCBzb21ldGhpbmcgd3JvbmcpOjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgL0NhbiBMU1AgcGluZyBpbiBWQ0NWIGJlIHVzZWQgdG8g dmVyaWZ5IHRoZSBQVyBjb25uZWN0aXZpdHkgaWYgaXQ8QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB1c2VzLCBzYXksIE1QTFMtaW4tSVAgb3IgTVBMUy1pbi1HUkUgZm9yIHRy YW5zcG9ydCBhbmQgdGhlIFBXPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bGFiZWwgKGJvdW5kIHRvIHRoZSBhcHByb3ByaWF0ZSBQVyBJZCBvciBHZW5lcmFsaXplZCBQVyBJ ZCBGRUMpPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIFBXIGRlbXVs dGlwbGV4aW5nPyBBbmQgaXMgc3VjaCBhIHZlcmlmaWNhdGlvbiByZXF1aXJlZCBpZiB0aGU8QlI+ DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJUCBjb25uZWN0aXZpdHkgdG8gdGhl IHJlbW90ZSBkZXZpY2UgaXMgT0s/LzxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgSU1ITyB0 aGUgYW5zd2VyIGlzOjxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgKjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1 Y2ggYSB2ZXJpZmljYXRpb24gKm1ha2VzKiAqc2Vuc2UqICh0aGUgUFcgZGVtdXhpbmcgaW4gdGhl PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmVtb3Rl IGJveCBjYW4gZ28gd3JvbmcgZXZlbiBpZiB0aGUgSVAgdHJhbnNwb3J0IGJyaW5ncyB0aGUgUFc8 QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwYWNrZXRz IHRvIHRoZSBjb3JyZWN0IHJlbW90ZSBib3gpPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsgKjxCUj4NCiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExT UCBQaW5nIGluIFZDQ1YgaXMgdGhlIGFwcHJvcHJpYXRlIChhbmQsIEFGQUlLLCB0aGUgb25seSkg d2F5PEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8g cGVyZm9ybSBpdC48QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IERpZCBJIG1pc3Mgc29tZXRo aW5nPzxCUj4NCiZndDsgSSBkb24ndCB0aGluayB5b3UgbWlzc2VkIGFueXRoaW5nLiBJIHVuZGVy c3Rvb2QgdGhlIHF1ZXN0aW9uIChhbmQ8QlI+DQomZ3Q7IGFuc3dlcikgdGhlIHNhbWUgd2F5LjxC Uj4NCiZndDsgVGhlIHJlbGV2YW50IHRleHQgaXMgdGhlIG9uZSB0aGF0IFJhbWFuIG9yaWdpbmFs bHkgcXVvdGVkLCBpLmUuOjxCUj4NCiZndDs8QlI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRo ZSB2YXJpb3VzIFZDQ1YgQ1YgVHlwZXM8QlI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cHBv cnRlZCBhcmUgdXNlZCBvbmx5IHdoZW4gdGhleSBhcHBseSB0byB0aGUgY29udGV4dCBvZiB0aGUg UFc8QlI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRlbXVsdGlwbGV4ZXIgaW4gdXNlLiZuYnNw OyBGb3IgZXhhbXBsZSwgdGhlIExTUCBQaW5nIENWIFR5cGUgc2hvdWxkIG9ubHk8QlI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlIHVzZWQgd2hlbiBNUExTIGlzIHV0aWxpemVkIGFzIHRoZSBQ U04uPEJSPg0KJmd0OzxCUj4NCiZndDsgSG93ZXZlciwgaXQgaXMgdW5mb3J0dW5hdGUgdGhhdCB0 aGUgZXhhbXBsZSAoaW50ZW5kZWQgdG8gY2xhcmlmeSkgbWlnaHQ8QlI+DQomZ3Q7IGJlIHNvdXJj ZSBvZiBjb25mdXNpb24uIFRoZSBrZXkgaXMgJnF1b3Q7L29ubHkgd2hlbiB0aGV5IGFwcGx5IHRv IHRoZSBjb250ZXh0PEJSPg0KJmd0OyBvZiB0aGUgUFcgZGVtdWx0aXBsZXhlciBpbiB1c2UvJnF1 b3Q7LCBzbyBMU1AgUGluZyBhcHBsaWVzIHdoZW4gdXNpbmcgTVBMUzxCUj4NCiZndDsgTGFiZWxz IGFzIFBXIERlbXVsdGlwbGV4ZXIuIFRoZSB3b3JkaW5nIGNob3NlbiBpbiB0aGUgc2Vjb25kIHNl bnRlbmNlPEJSPg0KJmd0OyAodGhlIGV4YW1wbGUpIG1pZ2h0IG5vdCBiZSB0aGUgYmVzdCB0byBj b252ZXkgdGhlIGludGVuZGVkIG1lYW5pbmcuPEJSPg0KJmd0OyBXb3VsZCBpdCBoZWxwIGlmIHRo ZSBzZWNvbmQgc2VudGVuY2Ugd2FzIHJld29yZGVkIGZyb206PEJSPg0KJmd0OzxCUj4NCiZndDsm bmJzcDsmbmJzcDsmbmJzcDsgRm9yIGV4YW1wbGUsIHRoZSBMU1AgUGluZyBDViBUeXBlIHNob3Vs ZCBvbmx5PEJSPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBiZSB1c2VkIHdoZW4gTVBMUyBpcyB1 dGlsaXplZCBhcyB0aGUgUFNOLjxCUj4NCiZndDs8QlI+DQomZ3Q7IHRvOjxCUj4NCiZndDs8QlI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZvciBleGFtcGxlLCB0aGUgTFNQIFBpbmcgQ1YgVHlw ZSBzaG91bGQgb25seTxCUj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYmUgdXNlZCB3aGVuIE1Q TFMgTGFiZWxzIGFyZSB1dGlsaXplZCBhcyBQVyBEZW11bHRpcGxleGVyLjxCUj4NCiZndDs8QlI+ DQomZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIGRvZXMgbm90IGNoYW5nZSB0aGUgaW50ZW5kZWQgbWVh bmluZywgYnV0IGluc3RlYWQgaXQ8QlI+DQomZ3Q7IG5hcnJvd3MgYW5kIGNsYXJpZmllcyB0aGUg d29yZGluZyBvZiB0aGUgZXhhbXBsZSwgYW5kIHRoZXJlJ3Mgc3RpbGwgdGltZTxCUj4NCiZndDsg Zm9yIHN1Y2ggd29yZGluZyBjaGFuZ2UuPEJSPg0KJmd0OzxCUj4NCiZndDsgVGhhbmtzLDxCUj4N CiZndDs8QlI+DQomZ3Q7IC0tQ2FybG9zLjxCUj4NCiZndDs8QlI+DQomZ3Q7Jmd0OyZuYnNwOzxC Uj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPEJSPg0KJmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU2FzaGE8QlI+DQomZ3Q7Jmd0OzxC Uj4NCiZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxCUj4NCiZndDsmZ3Q7ICpGcm9tOiogVGhvbWFz IE5hZGVhdSBbPEEgSFJFRj0ibWFpbHRvOnRuYWRlYXVAbHVjaWR2aXNpb24uY29tIj5tYWlsdG86 dG5hZGVhdUBsdWNpZHZpc2lvbi5jb208L0E+XTxCUj4NCiZndDsmZ3Q7ICpTZW50OiogVHVlc2Rh eSwgTm92ZW1iZXIgMjcsIDIwMDcgNDoyNiBQTTxCUj4NCiZndDsmZ3Q7ICpUbzoqIFJhbWFuIFJh bmdhc3dhbXk8QlI+DQomZ3Q7Jmd0OyAqQ2M6KiBwd2UzQGlldGYub3JnOyBWaWpheWFuYW5kIEMg LSBUTFMsIENoZW5uYWkuPEJSPg0KJmd0OyZndDsgKlN1YmplY3Q6KiBSZTogW1BXRTNdIElzIFZD Q1YgTFNQIFBpbmcgdG8gdGVzdCBvbmx5IE1QTFMgUFdzIG92ZXIgTVBMUzxCUj4NCiZndDsmZ3Q7 IFBTTiA/PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7Jmd0OyBIaSAs PEJSPg0KJmd0OyZndDsmZ3Q7IENhbiBJIGNvbmNsdWRlIGZyb20gdGhlIGJlbG93IGRyYWZ0IHNl Y3Rpb25zIHRoYXQ8QlI+DQomZ3Q7Jmd0OyZndDsg4oCcTFNQIFBpbmcgc2hvdWxkIGJlIHVzZWQg dG8gdGVzdCBNUExTIFBXcyBvdmVyIE1QTFMgUFNOIGFuZDxCUj4NCiZndDsmZ3Q7Jmd0OyBpdCBk b2VzIG5vdCBhcHBsaWNhYmxlIHRvIHRlc3QgTVBMUyBQV3Mgb3ZlciBJUCBQU04oU2F5IEdSRSB0 dW5uZWwpLuKAnTxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZndDsgVkNDViBzaG91bGQgYWx3YXlz IGJlIHVzZWQgdG8gdGVzdCB0aGUgUFcgbGF5ZXIgcmVnYXJkbGVzcyBvZiB0aGUgUFc8QlI+DQom Z3Q7Jmd0OyB0eXBlIG9yIGVuY2Fwc3VsYXRpb24sIGFuZCB0aGUgYXBwcm9wcmlhdGUgdG9vbHMg Zm9yIHRoZSBsb3dlciBsYXllcjxCUj4NCiZndDsmZ3Q7IHRvIHRlc3QgdGhvc2UuPEJSPg0KJmd0 OyZndDsgU28gdXNlIExTUCBwaW5nL3RyYWNlIGZvciBNUExTIExTUHMsIGFuZCBJQ01QIGVjaG8g Zm9yIElQL2wydHA8QlI+DQomZ3Q7Jmd0OyB0dW5uZWxzL3BhdGhzLjxCUj4NCiZndDsmZ3Q7PEJS Pg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyAtLVRvbTxCUj4NCiZndDsmZ3Q7PEJSPg0KJmd0OyZn dDs8QlI+DQomZ3Q7Jmd0OyZndDsgKkRyYWZ0OiBkcmFmdC1pZXRmLXB3ZTMtdmNjdi0xNSo8QlI+ DQomZ3Q7Jmd0OyZndDsgKlNlY3Rpb24gMyA6ICpUaGUgQ1YgdHlwZXMgaW5jbHVkZSBMU1AgUGlu ZyBbUkZDNDM3OV0gZm9yIE1QTFM8QlI+DQomZ3Q7Jmd0OyZndDsgUFdzLCBhbmQgSUNNUCBQaW5n IFtSRkMwNzkyXSBbUkZDNDQ0M10gZm9yIGJvdGggTVBMUyBhbmQgTDJUUHYzIFBXcy48QlI+DQom Z3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7Jmd0OyZndDsgKlNlY3Rpb24gNDoqIFRoZSB2YXJp b3VzIFZDQ1YgQ1YgdHlwZXMgc3VwcG9ydGVkIGFyZSB1c2VkIG9ubHkgd2hlbiB0aGV5IGFwcGx5 IHRvIHRoZTxCUj4NCiZndDsmZ3Q7Jmd0OyBjb250ZXh0IG9mIHRoZSBQVyBkZW11bHRpcGxleGVy IGluIHVzZS4mbmJzcDsgRm9yIGV4YW1wbGUsIExTUCBQaW5nIHR5cGUgc2hvdWxkIG9ubHkgYmUg dXNlZDxCUj4NCiZndDsmZ3Q7Jmd0OyB3aGVuIE1QTFMgaXMgdXRpbGl6ZWQgYXMgdGhlIFBTTi48 QlI+DQomZ3Q7Jmd0OyZndDsmbmJzcDs8QlI+DQomZ3Q7Jmd0OyZndDsgVGhhbmtzLDxCUj4NCiZn dDsmZ3Q7Jmd0OyAqUmFtYW4gUio8QlI+DQomZ3Q7Jmd0OyZndDsgRElTQ0xBSU1FUjo8QlI+DQom Z3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08QlI+DQomZ3Q7Jmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyZndDsgVGhl IGNvbnRlbnRzIG9mIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudChzKSBhcmUgY29uZmlk ZW50aWFsPEJSPg0KJmd0OyZndDsmZ3Q7IGFuZCBpbnRlbmRlZCBmb3IgdGhlIG5hbWVkIHJlY2lw aWVudChzKSBvbmx5LjxCUj4NCiZndDsmZ3Q7Jmd0OyBJdCBzaGFsbCBub3QgYXR0YWNoIGFueSBs aWFiaWxpdHkgb24gdGhlIG9yaWdpbmF0b3Igb3IgSENMIG9yIGl0czxCUj4NCiZndDsmZ3Q7Jmd0 OyBhZmZpbGlhdGVzLiBBbnkgdmlld3Mgb3Igb3BpbmlvbnMgcHJlc2VudGVkIGluPEJSPg0KJmd0 OyZndDsmZ3Q7IHRoaXMgZW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0aGUgYXV0aG9yIGFuZCBt YXkgbm90IG5lY2Vzc2FyaWx5PEJSPg0KJmd0OyZndDsmZ3Q7IHJlZmxlY3QgdGhlIG9waW5pb25z IG9mIEhDTCBvciBpdHMgYWZmaWxpYXRlcy48QlI+DQomZ3Q7Jmd0OyZndDsgQW55IGZvcm0gb2Yg cmVwcm9kdWN0aW9uLCBkaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBkaXNjbG9zdXJlLDxCUj4NCiZn dDsmZ3Q7Jmd0OyBtb2RpZmljYXRpb24sIGRpc3RyaWJ1dGlvbiBhbmQgLyBvciBwdWJsaWNhdGlv biBvZjxCUj4NCiZndDsmZ3Q7Jmd0OyB0aGlzIG1lc3NhZ2Ugd2l0aG91dCB0aGUgcHJpb3Igd3Jp dHRlbiBjb25zZW50IG9mIHRoZSBhdXRob3Igb2YgdGhpczxCUj4NCiZndDsmZ3Q7Jmd0OyBlLW1h aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmU8QlI+DQomZ3Q7Jmd0OyZndDsg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkg dGhlIHNlbmRlcjxCUj4NCiZndDsmZ3Q7Jmd0OyBpbW1lZGlhdGVseS4gQmVmb3JlIG9wZW5pbmcg YW55IG1haWwgYW5kPEJSPg0KJmd0OyZndDsmZ3Q7IGF0dGFjaG1lbnRzIHBsZWFzZSBjaGVjayB0 aGVtIGZvciB2aXJ1c2VzIGFuZCBkZWZlY3QuPEJSPg0KJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZn dDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPEJSPg0KJmd0OyZndDsmZ3Q7PEJSPg0KJmd0OyZndDsmZ3Q7IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KJmd0OyZndDsmZ3Q7 IHB3ZTMgbWFpbGluZyBsaXN0PEJSPg0KJmd0OyZndDsmZ3Q7IHB3ZTNAaWV0Zi5vcmcgJmx0OzxB IEhSRUY9Im1haWx0bzpwd2UzQGlldGYub3JnIj5tYWlsdG86cHdlM0BpZXRmLm9yZzwvQT4mZ3Q7 PEJSPg0KJmd0OyZndDsmZ3Q7IDxBIEhSRUY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3B3ZTMiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3B3 ZTM8L0E+PEJSPg0KJmd0OyZndDs8QlI+DQomZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08QlI+DQom Z3Q7Jmd0OzxCUj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPEJSPg0KJmd0OyZndDsgcHdlMyBtYWlsaW5nIGxpc3Q8QlI+DQomZ3Q7Jmd0 OyBwd2UzQGlldGYub3JnPEJSPg0KJmd0OyZndDsgPEEgSFJFRj0iaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcHdlMyI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcHdlMzwvQT48QlI+DQomZ3Q7Jmd0OyZuYnNwOyZuYnNwOzxCUj4NCiZndDs8QlI+ DQomZ3Q7IC0tPEJSPg0KJmd0OyAtLUNhcmxvcyBQaWduYXRhcm8uPEJSPg0KJmd0OyBFc2NhbGF0 aW9uIFJUUCAtIGNpc2NvIFN5c3RlbXM8QlI+DQomZ3Q7PEJSPg0KJmd0OzxCUj4NCiZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPEJSPg0KJmd0OzxCUj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188QlI+DQomZ3Q7IHB3ZTMgbWFpbGluZyBsaXN0PEJSPg0K Jmd0OyBwd2UzQGlldGYub3JnPEJSPg0KJmd0OyA8QSBIUkVGPSJodHRwczovL3d3dzEuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9wd2UzIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9wd2UzPC9BPjxCUj4NCjxCUj4NCi0tPEJSPg0KLS1DYXJsb3MgUGlnbmF0YXJvLjxC Uj4NCkVzY2FsYXRpb24gUlRQIC0gY2lzY28gU3lzdGVtczxCUj4NCjxCUj4NCjxCUj4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPg0KcHdlMyBtYWls aW5nIGxpc3Q8QlI+DQpwd2UzQGlldGYub3JnPEJSPg0KPEEgSFJFRj0iaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMyI+aHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcHdlMzwvQT48QlI+DQo8L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRN TD4= ------_=_NextPart_001_01C83202.EAD3467D-- --===============0279691623== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www1.ietf.org/mailman/listinfo/pwe3 --===============0279691623==--