From internet-drafts@ietf.org Mon Jul 2 20:11:45 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF27621F8596; Mon, 2 Jul 2012 20:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRWLEJVGYuAr; Mon, 2 Jul 2012 20:11:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B4121F8543; Mon, 2 Jul 2012 20:11:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120703031143.23885.94321.idtracker@ietfa.amsl.com> Date: Mon, 02 Jul 2012 20:11:43 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-cbit-negotiation-05.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 03:11:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : Pseudowire Control Word Negotiation Mechanism Update Author(s) : Lizhong Jin Raymond Key Simon Delord Thomas Nadeau Sami Boutros Filename : draft-ietf-pwe3-cbit-negotiation-05.txt Pages : 10 Date : 2012-07-02 Abstract: The control word negotiation mechanism specified in RFC4447 has a problem when a PE changes the preference for the use of the control word from NOT PREFERRED to PREFERRED. This document updates RFC4447 and RFC6073 by adding the Label Request message to resolve this control word negotiation issue for single-segment and multi-segment pseudowires. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-cbit-negotiation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-cbit-negotiation-05 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-cbit-negotiation-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From dmm@1-4-5.net Tue Jul 3 10:11:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C1711E8196 for ; Tue, 3 Jul 2012 10:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQPB76NB9Pxv for ; Tue, 3 Jul 2012 10:11:06 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D24C11E818B for ; Tue, 3 Jul 2012 10:11:06 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6107363ggn.31 for ; Tue, 03 Jul 2012 10:11:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=eQbzR3doNbE0xrcI2Zaoly+uYjFTfYy48T1zh404FAU=; b=INAyfDSMDa9RXTSsGdVRexx/e419roKhplGu2lTwEjTm7uiMZ8J9o75kmxkNaanBmM L/JOfwInP5Qm5Ny/mGlkbcqjqgQnkGPFqfoitl0cm574mKS/jEWZXAVgQtQc++y4MO1g WY43/fhgQIrZNtyh3H6M+iGZDwwGcSM1Za5OQPQKNKavtPbo97I+VaIXligMi6DtFCor akb5YRkkBbmjT+IJiF+FQbgg9k0SZbphSAGf6cleEUwuljkOBicKEV8X4RhqijwvN5Oj amfpNRtpU+fgseKYf2sH9rjZL49wGPDmLFt9S8R6SHWV5Six1czEZH8/C5BTTlKo9rdr xyZA== MIME-Version: 1.0 Received: by 10.60.25.38 with SMTP id z6mr19328422oef.15.1341335474673; Tue, 03 Jul 2012 10:11:14 -0700 (PDT) Received: by 10.76.19.16 with HTTP; Tue, 3 Jul 2012 10:11:14 -0700 (PDT) X-Originating-IP: [24.21.216.213] Date: Tue, 3 Jul 2012 10:11:14 -0700 Message-ID: From: David Meyer To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl4wQ3kqS9UCRbgxSWVW49EKGcVvSz4uchWFGvQAfiyYVrpVOc1XUOI/N7C3a+wBJQ9H/u+ Subject: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 17:11:07 -0000 Folks, "MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been posted. Looking forward to your review. --dmm (for Jan, dward, and Andrew) From amalis@gmail.com Tue Jul 3 11:14:31 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C9A911E80FD for ; Tue, 3 Jul 2012 11:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcqoeri-pHqS for ; Tue, 3 Jul 2012 11:14:30 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92D5811E808C for ; Tue, 3 Jul 2012 11:14:30 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6186697ggn.31 for ; Tue, 03 Jul 2012 11:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fqObITtzIy7+cD84ijbAj+LIYzn0Q39iEZxxbILnAc0=; b=fp6jw6kGfNxIPSoHP7B+LZLo8by9OqoE68D1AnaXgPD9j8DcjcnM/VQv4SzWkI2SB0 Jqh8oDGjbJzOr1I+bxLD3pgEu0cj+3E3kBCDahRQo96xAsxMaZwsD1y5jyn77+cdRImQ WLuW6ysXnnELtqda8wYih0+SAv02hjDE7wPoNTZnIlMPEMEhxjrdvJTINQHu1njtjmZu O3An7C7s7QryDsL1BOTYwpzvFWS0wsPORIfibfQzOgyM+yE0JgkRhw8ZqJD4sNkk/Iuu HJNRY1DUGSM8SZ5047aBYyC5sWjkN2CzQKZw0QKM8k26NqDD92IYava8MrO7wFZlKzja Kjxg== Received: by 10.68.132.166 with SMTP id ov6mr9542869pbb.24.1341339278362; Tue, 03 Jul 2012 11:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.45.9 with HTTP; Tue, 3 Jul 2012 11:14:18 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Tue, 3 Jul 2012 14:14:18 -0400 Message-ID: To: David Meyer , Jan Medved , Andrew McLachlan Content-Type: text/plain; charset=ISO-8859-1 Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2012 18:14:31 -0000 Dave, Jan, Andrew, An interesting draft. I have a few comments, with my WG chair hat off: 1. An editorial comment, there's no "-" or internal uppercase "W" in "Pseudowire", which is the proper spelling (I saw at least three different spellings in the draft). 2. Section 1.3 states: "PWs are configured as bi-directional paths over the MPLS-TP network, usually by an external management platform. At present no open standards exist to provision these PWs, and therefore there is a reliance on vendor specific provisioning platforms." Certainly, there's nothing that prevents the use of T-LDP for PW use in MPLS-TP networks, this is already documented in section 5.2 of RFC 6373. Speaking of which, you should also have a table in your draft similar to the table in section 5.2 that shows how your draft meets the MPLS-TP control plane requirements listed in section 2 of RFC 6373. You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp, which specifies useful functionality in this area. In any case, you should be clear that this is an alternative control plane to T-LDP. 3. Section 4: In addition to RFC 6423, you may wish to include a reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode for use with MPLS-TP. You may also wish to reference RFC 5860. Cheers, Andy On Tue, Jul 3, 2012 at 1:11 PM, David Meyer wrote: > Folks, > > "MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been > posted. Looking forward to your review. > > --dmm (for Jan, dward, and Andrew) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From Alexander.Vainshtein@ecitele.com Tue Jul 3 22:05:21 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C57B11E80F0 for ; Tue, 3 Jul 2012 22:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNZFuHxTv7BK for ; Tue, 3 Jul 2012 22:05:19 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 10E3521F8702 for ; Tue, 3 Jul 2012 22:05:18 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-15.tower-27.messagelabs.com!1341378325!3092994!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 31285 invoked from network); 4 Jul 2012 05:05:25 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-15.tower-27.messagelabs.com with SMTP; 4 Jul 2012 05:05:25 -0000 X-AuditID: a8571401-b7ff06d000000c6d-e5-4ff3d046ce90 Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 1F.A1.03181.640D3FF4; Wed, 4 Jul 2012 07:10:31 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 4 Jul 2012 07:05:25 +0200 From: Alexander Vainshtein To: "Andrew G. Malis" , David Meyer , Jan Medved , Andrew McLachlan Thread-Topic: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Thread-Index: AQHNWT7xvqwGUdtG106/a2x3EHFnsJcXu00AgADPmMw= Date: Wed, 4 Jul 2012 05:05:24 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02097A99FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTfWwLYRzHPXfX9jo7udXos0Zojki8dNogqZcOyUSFKUYIEk7v0V60d02v 2MTLiH8sw4ZhE0oss2yzZSxCNkS9jEpmGIpUvEaGyLJlEcR4zjFLxP31ud/3+3t5nvsdTZpK DRZalCIoLPEBTp9CpYABFtuctm6PfUcp5Xz+sNLgfF32QO+MFTYYnEXf2knn3q5GaqbOXXvp JuU++K1B575YnjS4W+NL3RUVX4iFuhUFYDovSXKEjyCrgBSvi1sYFjfy3nzOKgouzsFZQwHe i4JIirg4PhRCksBlpVj/eaZjmyhZkeSVBVHyubi5uR6b0zl5is3BZS3xi4oV2YK8GLAGkaLw PmTFEfUokrCmjvRfv9pFhFpy8qp2FRkKQNnMQmCkITsJtj4+Rmg8FLY9r9cXghTaxMYBvPUg oVMFE3sKwKPxGSrrWRc8W5P8ZUpn9wFYeS5JqgLJniFgfcdmlQez8+Hpd3f1KqezOXDXkRbM NOapsKBslRqm2FGwu/q7QWUGW5qPRSmtcSmAP5LRXxMZ2UWwruQFUBng6T7Hawmtlxk+fRP9 PTULK5rvkhoPgR2ve3Uaj4D3Ol/89svw9qEbhNYsDd4ue0Npngx4tSpBFYOh5f3KlvdLKe+X osUzYaL0oF7jcbDy5AdSYxs80huj+sdPAEM1MK8Li0IopKy12x2ZyCtGUABleuXgWYB3q2pZ OrgAXu3JjAGWBlwqYxze7THp+I1KfjAGMmiCG8Jsu4NDg9bKQr6fV/yrwxsCSIkBSJNcOvOk CWuMwOdvRmH5jzQbX24JaRnoldVPH1k90W7//wtnZuoXZ3lMrA8v53qEQij8p84wmuYgs6AV t0gLIx/KWycGIn9lgjaqY6TiMWTVwyghPqiIPk2PgwyLmfGrAqsK/g1SX+57YMaHHcxsVdVU vKB9We9xQQIXlE51qQXxD9MnWQrADHLZszaj623zbqbi6802eVtiZEvSaDk/1pPVtD37sL17 y8kJ87Kb6Y+dxXNdPY6mkppXP7pyLIW11Wkrl0cPOXfWvmy49jRXuGfbNLX4fie9/0p7CZz1 aQzM7uh55O81PUwbPfvotbzE+P1T2qO6RlhHX248Pu2AbqCFRz23jhdxlOLnHWPJsML/BPXb D5soBAAA Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 05:05:21 -0000 --_000_F9336571731ADE42A5397FC831CEAA02097A99FRIDWPPMB001ecite_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Andy and all, I've looked up the draft in question, and I have some comments/questions in= addition to Andy's: 1. The PWE3 WG has defined multiple MIBs that can be used for PW setup an= d teardown by a management application (MPLS-TP or not). IMO the draft= should indicate that the method proposed there is an alternative not just t= o PW signaling via T-LDP (as Andy has said) but also to static PW setup usin= g these MIBs. 2. The wording of the draft seems to suggest a difference between the hea= d-end PE and the tail-end one, e.g., as in he following fragment: "Although= the Virtual OF switch is the same a both the head-end and tail-end nodes, t= he group table is only used at the head-end node, where a Fast Failover grou= p is set up for each pair of ports that correspond to the primary-backup Tra= nsport LSP pair. At the tail-end node, only flows are set up." I do not und= erstand how does this (and similar) fragments deal with the fact of PWs bein= g inherently bidirectional. 3. The PWs run in MPLS (or MPLS-TP) tunnels in order to improve scalabili= ty of P routers, because the same tunnel between a given pair of PEs can be= shared by multiple PW instances. It is not clear from the text how such sha= ring can be accommodated in the proposed OF switch model. 4. Reference to RFC 6423 suggests that OAM discussion in the draft is PW= OAM and OAM for Tunnel LSPs. Does this imply that the protection actions ar= e triggered by the PW-level OAM, and, what is supposed to happen if a pair o= f T-LSPs is shared by multiple PW instances? 5. The text defining the OF switch and its matching rules is not clear. I= n particular, it seems to imply that PW labels are checked from being receiv= ed from a specific T-LSP (as a port of the OF switch). IMHO this a clear con= tradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031, and= to the fact that PW labels are allocated from the per-platform label space= (as per RFC 4447). My 2c, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Andrew G. M= alis [amalis@gmail.com] Sent: Tuesday, July 03, 2012 8:14 PM To: David Meyer; Jan Medved; Andrew McLachlan Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Dave, Jan, Andrew, An interesting draft. I have a few comments, with my WG chair hat off: 1. An editorial comment, there's no "-" or internal uppercase "W" in "Pseudowire", which is the proper spelling (I saw at least three different spellings in the draft). 2. Section 1.3 states: "PWs are configured as bi-directional paths over the MPLS-TP network, usually by an external management platform. At present no open standards exist to provision these PWs, and therefore there is a reliance on vendor specific provisioning platforms." Certainly, there's nothing that prevents the use of T-LDP for PW use in MPLS-TP networks, this is already documented in section 5.2 of RFC 6373. Speaking of which, you should also have a table in your draft similar to the table in section 5.2 that shows how your draft meets the MPLS-TP control plane requirements listed in section 2 of RFC 6373. You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp, which specifies useful functionality in this area. In any case, you should be clear that this is an alternative control plane to T-LDP. 3. Section 4: In addition to RFC 6423, you may wish to include a reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode for use with MPLS-TP. You may also wish to reference RFC 5860. Cheers, Andy On Tue, Jul 3, 2012 at 1:11 PM, David Meyer wrote: > Folks, > > "MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been > posted. Looking forward to your review. > > --dmm (for Jan, dward, and Andrew) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02097A99FRIDWPPMB001ecite_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Andy and all,

I've looked up the draft in question, and I have some comments/quest= ions in addition to Andy's:

  1. The PWE3 WG has defined multiple MIBs that can be used for PW setup and= teardown by a      management application (MPLS-TP= or not). IMO the draft should indicate that the method proposed there= is an alternative not just to PW signaling via T-LDP (as Andy has said) but also to static PW setup using these MIBs.
  2. The wordin= g of the draft seems to suggest a difference between the head-end PE and the= tail-end one, e.g., as in he following fragment: "Although the Vir= tual OF switch is the same a both the head-end and tail-end nodes, the= group table is only used at the head-end node, where a Fast Failover group is set up for each p= air of ports that correspond to the primary-backup Transport LSP pair.&= nbsp; At the tail-end node, only flows are set up." I do= not understand how does this (and similar) fragments deal with the fact of PWs being inherently bidirectional.
  3. The PWs= run in MPLS (or MPLS-TP) tunnels in order to improve scalabilit= y of P routers, because the same tunnel between a given pair of PEs can be s= hared by multiple PW instances. It is not clear from the text how such= sharing can be accommodated in the proposed OF switch model.
  4.  Reference to RFC 6423 sugge= sts that OAM discussion in the draft is PW OAM and OAM for Tunnel LSPs. Does= this imply that the protection actions are triggered by the PW-level OAM, a= nd, what is supposed to happen if a pair of T-LSPs is shared by multiple PW instances?
  5. The text defining the OF switch and its matching rul= es is not clear. In particular, it seems to imply that PW labels are checked= from being received from a specific T-LSP (as a port of the OF switch). IMH= O this a clear contradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031, and to the fact that PW labels are = allocated from the per-platform label space (as per RFC 4447).

    6. My 2c,

         Sasha

    ________________________________________
    From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Andrew G.&n= bsp;Malis [amalis@gmail.com]
    Sent: Tuesday, July 03, 2012 8:14 PM
    To: David Meyer; Jan Medved; Andrew McLachlan
    Cc: pwe3@ietf.org
    Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please=

    Dave, Jan, Andrew,

    An interesting draft. I have a few comments, with my WG chair hat off:

    1. An editorial comment, there's no "-" or internal uppercase &quo= t;W" in
    "Pseudowire", which is the proper spelling (I saw at= least three
    different spellings in the draft).

    2. Section 1.3 states: "PWs are
       configured as bi-directional paths over the MPLS-TP network, us= ually
       by an external management platform.  At present no open st= andards
       exist to provision these PWs, and therefore there is a reliance= on
       vendor specific provisioning platforms."

    Certainly, there's nothing that prevents the use of T-LDP for PW use
    in MPLS-TP networks, this is already documented in section 5.2 of RFC
    6373.

    Speaking of which, you should also have a table in your draft similar
    to the table in section 5.2 that shows how your draft meets the
    MPLS-TP control plane requirements listed in section 2 of RFC 6373.

    You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp,
    which specifies useful functionality in this area.

    In any case, you should be clear that this is an alternative control
    plane to T-LDP.

    3. Section 4: In addition to RFC 6423, you may wish to include a
    reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode
    for use with MPLS-TP. You may also wish to reference RFC 5860.

    Cheers,
    Andy

    On Tue, Jul 3, 2012 at 1:11 PM, David Meyer <dmm@1-4-5.net> wrote:
    > Folks,
    >
    > "MPLS-TP PseudoWire Configuration using Op= enFlow 1.3" has just been
    > posted. Looking forward to your review.
    >
    > --dmm (for Jan, dward, and Andrew)
    > _______________________________________________
    > pwe3 mailing list
    > pwe3@ietf.org
    > https://www.ietf.org/mailman/listinfo/pwe3
    _______________________________________________
    pwe3 mailing list
    pwe3@ietf.org
    https://www.ietf.org/mailman/listinfo/pwe3

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02097A99FRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Tue Jul 3 22:16:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BD721F876D for ; Tue, 3 Jul 2012 22:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4rqTi9bWI5B for ; Tue, 3 Jul 2012 22:16:10 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id C200521F876F for ; Tue, 3 Jul 2012 22:16:09 -0700 (PDT) Received: from [85.158.139.83:13507] by server-1.bemta-5.messagelabs.com id 6A/FE-19721-2A1D3FF4; Wed, 04 Jul 2012 05:16:18 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-182.messagelabs.com!1341378977!30839133!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.5.10; banners=-,-,- Received: (qmail 26292 invoked from network); 4 Jul 2012 05:16:18 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-2.tower-182.messagelabs.com with SMTP; 4 Jul 2012 05:16:18 -0000 X-AuditID: a8571401-b7ff06d000000c6d-b2-4ff3d2d2b68f Received: from FRGRWPVCH001.ecitele.com (Unknown_Domain [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id ED.C1.03181.2D2D3FF4; Wed, 4 Jul 2012 07:21:23 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Wed, 4 Jul 2012 07:16:17 +0200 From: Alexander Vainshtein To: "Andrew G. Malis" , David Meyer , Jan Medved , Andrew McLachlan Thread-Topic: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Thread-Index: AQHNWT7xvqwGUdtG106/a2x3EHFnsJcXu00AgADPmMyAAAlAFQ== Date: Wed, 4 Jul 2012 05:16:16 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA02097AACFRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLsWRmVeSWpSXmKPExsXCxcggpXv50md/gyNLOCzuXV3GbvF45mU2 i0NdG9kten5fYbbo+7SFxYHVY83eYyweU35vZPXYOesuu8e5U6EeS5b8ZApgjWpgtEnMy8sv SSxJVUhJLU62VQooyixLTK5UUshMsVUyVFIoyElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5 Cql5yfkpmXnptkqewf66FhamlrqGSnYhGZnFCqm6uYmZOQq5qcXFiempCkARkFfyUhLWMWec XzeXqWBKXMWKHrMGxv++XYycHBICJhKnT85jgrDFJC7cW8/WxcjFISRwilFic/sSJghnMaPE 6Ud9bCBVbAK2EptW3wWrEhHoZ5RYtvkuM0iCWWAtk8T6l1UgtrCAj8Ty5+fBGkQEfCVaZhwH sjmAbCeJLbdLQMIsAioSd+edBmvlBSo5+OkM1ObrjBJ7DjxlB0lwCvhJ3Dh+khHEZgQ67/up NUwQu8Qlbj2ZD3W2gMSSPeeZIWxRiZeP/7FC2PISFz88gKrPl3h5+BTUMkGJkzOfsEDUSEoc XHGDZQKj2CwkY2chaZmFpAUiridxY+oUNghbW2LZwtfMELauxIx/h1iQxRcwsq9iFE8rykwp KChOMjAw1EtNzixJzUnVS87P3cQITFsrwkUYdzA+6tU7xCjAwajEw8sp99lfiDWxrLgy9xCj JAeTkiiv7gWgEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHem7uBcrwpiZVVqUX5MClXYOBOZJbi Ts4HRX1JvLGBAW6Okjjv+iA7fyGBdGDizE5NLUgtgpkjw8GhJMG7HGS9YFFqempFWmZOCUKa iYMT5AweoDOCQGp4iwsSc4sz0yHypxglpcR5T4IkBEASGaV5cL2vGMWBnhXmvQaS5QEmULiu V0ADmYAG5i3+BDIQmGHgUlINjGGl01oU1TTtf97jN7VelrjVwklCvq1qdl6Q6uJGhQcc2trz dy3oebtKVWJpXXTLrAO1fDZ9n+9o6qrtYvnwnjVnX2PCzuwtQnaWmrE/w87msHg9W7ZvzoR1 ZZ+FknatDbugs/CrRN+aq6+YHkvd+jWpQ0O5Z0HqebddhqtmbOM9nx/9T0rIS4mlOCPRUIu5 qDgRAMniZqooBAAA Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , "pwe3@ietf.org" , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jul 2012 05:16:11 -0000 --_000_F9336571731ADE42A5397FC831CEAA02097AACFRIDWPPMB001ecite_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all again, One more comment (forgot to include it in the original email) added at the e= nd of the list in blue. Regards, Sasha ________________________________ From: Alexander Vainshtein Sent: Wednesday, July 04, 2012 7:05 AM To: Andrew G. Malis; David Meyer; Jan Medved; Andrew McLachlan Cc: pwe3@ietf.org; Mishael Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev= ; Idan Kaspit; Vladimir Kleiner Subject: RE: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Andy and all, I've looked up the draft in question, and I have some comments/questions in= addition to Andy's: 1. The PWE3 WG has defined multiple MIBs that can be used for PW setup an= d teardown by a management application (MPLS-TP or not). IMO the draft= should indicate that the method proposed there is an alternative not just t= o PW signaling via T-LDP (as Andy has said) but also to static PW setup usin= g these MIBs. 2. The wording of the draft seems to suggest a difference between the hea= d-end PE and the tail-end one, e.g., as in he following fragment: "Although= the Virtual OF switch is the same a both the head-end and tail-end nodes, t= he group table is only used at the head-end node, where a Fast Failover grou= p is set up for each pair of ports that correspond to the primary-backup Tra= nsport LSP pair. At the tail-end node, only flows are set up." I do not und= erstand how does this (and similar) fragments deal with the fact of PWs bein= g inherently bidirectional. 3. The PWs run in MPLS (or MPLS-TP) tunnels in order to improve scalabili= ty of P routers, because the same tunnel between a given pair of PEs can be= shared by multiple PW instances. It is not clear from the text how such sha= ring can be accommodated in the proposed OF switch model. 4. Reference to RFC 6423 suggests that OAM discussion in the draft is PW= OAM and OAM for Tunnel LSPs. Does this imply that the protection actions ar= e triggered by the PW-level OAM, and, what is supposed to happen if a pair o= f T-LSPs is shared by multiple PW instances? 5. The text defining the OF switch and its matching rules is not clear. I= n particular, it seems to imply that PW labels are checked from being receiv= ed from a specific T-LSP (as a port of the OF switch). IMHO this a clear con= tradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031, and= to the fact that PW labels are allocated from the per-platform label space= (as per RFC 4447). 6. In order to assign PW labels, the management application needs the inf= ormation about the pool of unused MPLS labels on each of the PE devices. The= methods for obtaining such information using the OpenFlow tehnique are not= mentioned in the draft. My 2c, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Andrew G. M= alis [amalis@gmail.com] Sent: Tuesday, July 03, 2012 8:14 PM To: David Meyer; Jan Medved; Andrew McLachlan Cc: pwe3@ietf.org Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Dave, Jan, Andrew, An interesting draft. I have a few comments, with my WG chair hat off: 1. An editorial comment, there's no "-" or internal uppercase "W" in "Pseudowire", which is the proper spelling (I saw at least three different spellings in the draft). 2. Section 1.3 states: "PWs are configured as bi-directional paths over the MPLS-TP network, usually by an external management platform. At present no open standards exist to provision these PWs, and therefore there is a reliance on vendor specific provisioning platforms." Certainly, there's nothing that prevents the use of T-LDP for PW use in MPLS-TP networks, this is already documented in section 5.2 of RFC 6373. Speaking of which, you should also have a table in your draft similar to the table in section 5.2 that shows how your draft meets the MPLS-TP control plane requirements listed in section 2 of RFC 6373. You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp, which specifies useful functionality in this area. In any case, you should be clear that this is an alternative control plane to T-LDP. 3. Section 4: In addition to RFC 6423, you may wish to include a reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode for use with MPLS-TP. You may also wish to reference RFC 5860. Cheers, Andy On Tue, Jul 3, 2012 at 1:11 PM, David Meyer wrote: > Folks, > > "MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been > posted. Looking forward to your review. > > --dmm (for Jan, dward, and Andrew) > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA02097AACFRIDWPPMB001ecite_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Hi all again,

One more comment (forgot to include it in the original email) added at th= e end of the list in blue.

 

Regards,

     Sasha

 

From: Alexander Vainshtein
Sent: Wednesday, July 04, 2012 7:05 AM
To: Andrew G. Malis; David Meyer; Jan Medved; Andrew McLachlan
Cc: pwe3@ietf.org; Mishael Wexler; Rotem Cohen; Gideon Agmon; Andrew= Sergeev; Idan Kaspit; Vladimir Kleiner
Subject: RE: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review= please

Andy and all,

I've looked up the draft in question, and I have some comments/quest= ions in addition to Andy's:

  1. The PWE3 WG has defined multiple MIBs that can be used for PW setup and= teardown by a      management application (MPLS-TP= or not). IMO the draft should indicate that the method proposed there= is an alternative not just to PW signaling via T-LDP (as Andy has said) but also to static PW setup using these MIBs.
  2. The wordin= g of the draft seems to suggest a difference between the head-end PE and the= tail-end one, e.g., as in he following fragment: "Although the Vir= tual OF switch is the same a both the head-end and tail-end nodes, the= group table is only used at the head-end node, where a Fast Failover group is set up for each p= air of ports that correspond to the primary-backup Transport LSP pair.&= nbsp; At the tail-end node, only flows are set up." I do= not understand how does this (and similar) fragments deal with the fact of PWs being inherently bidirectional.
  3. The PWs= run in MPLS (or MPLS-TP) tunnels in order to improve scalabilit= y of P routers, because the same tunnel between a given pair of PEs can be s= hared by multiple PW instances. It is not clear from the text how such= sharing can be accommodated in the proposed OF switch model.
  4.  Reference to RFC 6423 sugge= sts that OAM discussion in the draft is PW OAM and OAM for Tunnel LSPs. Does= this imply that the protection actions are triggered by the PW-level OAM, a= nd, what is supposed to happen if a pair of T-LSPs is shared by multiple PW instances?
  5. The text defining the OF switch and its matching rul= es is not clear. In particular, it seems to imply that PW labels are checked= from being received from a specific T-LSP (as a port of the OF switch). IMH= O this a clear contradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031, and to the fact that PW labels are = allocated from the per-platform label space (as per RFC 4447).
  6. In order to assign PW labels, the managemen= t application needs the information about the pool of unused MPLS labels on= each of the PE devices. The methods for obtaining such information using th= e OpenFlow tehnique are not mentioned in the draft.

My 2c,

     Sasha

________________________________________
From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Andrew G.&n= bsp;Malis [amalis@gmail.com]
Sent: Tuesday, July 03, 2012 8:14 PM
To: David Meyer; Jan Medved; Andrew McLachlan
Cc: pwe3@ietf.org
Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please=

Dave, Jan, Andrew,

An interesting draft. I have a few comments, with my WG chair hat off:

1. An editorial comment, there's no "-" or internal uppercase &quo= t;W" in
"Pseudowire", which is the proper spelling (I saw at= least three
different spellings in the draft).

2. Section 1.3 states: "PWs are
   configured as bi-directional paths over the MPLS-TP network, us= ually
   by an external management platform.  At present no open st= andards
   exist to provision these PWs, and therefore there is a reliance= on
   vendor specific provisioning platforms."

Certainly, there's nothing that prevents the use of T-LDP for PW use
in MPLS-TP networks, this is already documented in section 5.2 of RFC
6373.

Speaking of which, you should also have a table in your draft similar
to the table in section 5.2 that shows how your draft meets the
MPLS-TP control plane requirements listed in section 2 of RFC 6373.

You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp,
which specifies useful functionality in this area.

In any case, you should be clear that this is an alternative control
plane to T-LDP.

3. Section 4: In addition to RFC 6423, you may wish to include a
reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode
for use with MPLS-TP. You may also wish to reference RFC 5860.

Cheers,
Andy

On Tue, Jul 3, 2012 at 1:11 PM, David Meyer <dmm@1-4-5.net> wrote:
> Folks,
>
> "MPLS-TP PseudoWire Configuration using Op= enFlow 1.3" has just been
> posted. Looking forward to your review.
>
> --dmm (for Jan, dward, and Andrew)
> _______________________________________________
> pwe3 mailing list
> pwe3@ietf.org
> https://www.ietf.org/mailman/listinfo/pwe3
_______________________________________________
pwe3 mailing list
pwe3@ietf.org
https://www.ietf.org/mailman/listinfo/pwe3

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA02097AACFRIDWPPMB001ecite_-- From yaakov_s@rad.com Wed Jul 4 22:39:43 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B1D21F8595 for ; Wed, 4 Jul 2012 22:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.164 X-Spam-Level: X-Spam-Status: No, score=-102.164 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-eFOE6KjNOU for ; Wed, 4 Jul 2012 22:39:42 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id F257921F8587 for ; Wed, 4 Jul 2012 22:39:38 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 5 Jul 2012 08:06:47 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Thu, 5 Jul 2012 08:39:43 +0300 From: Yaakov Stein To: David Meyer , "pwe3@ietf.org" Thread-Topic: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Thread-Index: AQHNWT7sHhzvkIa10UyP+fXzI0vYRZcaKIiw Date: Thu, 5 Jul 2012 05:39:43 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044DED8C@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.141.36] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9044DED8CEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090205.4FF528A1.000E,ss=1,fgs=0 Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 05:39:43 -0000 --_000_07F7D7DED63154409F13298786A2ADC9044DED8CEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In addition to Andy's remark on "pseudowire" G.ach and G-ach should be GACH or G-ACh. To answer one of Sasha's questions, the terms head-end and tail-end refer to the protection switching, which is not limited to bidirectional switching. I don't understand why this use case is the first one being addressed. Static configuration of LSPs can obviously be done using OpenFlow, and perhaps a document explaining this would be useful (if perhaps somewhat= trivial). I think that the case for using OpenFlow (instead of T-LDP) for PWs is not = as clear. PW setup as a host of interface parameters that need to be specified, that OpenFlow would be hard-pressed to address. The particular uses being described here seem to be an academic exercise to show that OpenFlow can (barely) accomplish some very specific tasks. Finally, I wholeheartedly agree with Sasha's added remark that this solution would seem to be limited to OpenFlow-only solutions and not to hybrid ones, because of a fundamental clash between the the on-switch label generator and controller label binding. Y(J)S -----Original Message----- From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Meyer Sent: Tuesday, July 03, 2012 20:11 To: pwe3@ietf.org Subject: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Folks, "MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been posted. Looking forward to your review. --dmm (for Jan, dward, and Andrew) _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 --_000_07F7D7DED63154409F13298786A2ADC9044DED8CEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In addition to Andy's remark on &quo= t;pseudowire"

G.ach and G-ach should be GACH or G-= ACh.

 

To answer one of Sasha's questions,<= o:p>

the terms head-end and tail-end refe= r to the protection switching,

which is not limited to bidirectiona= l switching.

 

I don't understand why this use case= is the first one being addressed.

Static configuration of LSPs can obv= iously be done using OpenFlow,

and perhaps a document explaining th= is would be useful (if perhaps somewhat trivial).

 

I think that the case for using Open= Flow (instead of T-LDP) for PWs is not as clear.

PW setup as a host of interface para= meters that need to be specified,

that OpenFlow would be hard-pressed = to address.

 

The particular uses being described = here seem to be an academic exercise

to show that OpenFlow can (barely) a= ccomplish some very specific tasks.

 

Finally, I wholeheartedly agree with= Sasha's added remark

that this solution would seem to be = limited to OpenFlow-only solutions

and not to hybrid ones, because of a= fundamental clash between the

the on-switch label generator and co= ntroller label binding.

 

Y(J)S

 

 

-----Original Message-----
From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf Of Dav= id Meyer
Sent: Tuesday, July 03, 2012 20:11
To: pwe3@ietf.org
Subject: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please

 

Folks,

 

"MPLS-TP PseudoWire Configuration using Open= Flow 1.3" has just been

posted. Looking forward to your review.

 

--dmm (for Jan, dward, and Andrew)

_______________________________________________

pwe3 mailing list

pwe3@ietf.org

https://www.ietf.org/mailman/listinfo/pwe3

--_000_07F7D7DED63154409F13298786A2ADC9044DED8CEXRAD5adradcoil_-- From dmm@1-4-5.net Thu Jul 5 06:37:38 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B821521F8566 for ; Thu, 5 Jul 2012 06:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gElJQUmtPOIk for ; Thu, 5 Jul 2012 06:37:33 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBD3D21F853F for ; Thu, 5 Jul 2012 06:37:30 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so15103126obb.31 for ; Thu, 05 Jul 2012 06:37:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iAbRYBQ6gWN/sSmpuyXNJO4R+gGJK6CVvT/tXmJJm/I=; b=EmHY2JB45eioyiqcS3NLoErKdys4e6xM7a+/872fHQTQrmDwwcxoCnvEp5YXDdjEcs zRbUeiTB9jIwB5IAWr0Aqmu6YVJwUMdhS6l72Cj+9hYmeowA5QXnNgilBF/Wa8VJxRjJ WUXMP15JPOZOwhHeNAYzaUMSMy47UR046Zlx/Zee/iOtbl2FNkZq+g//eUhp4SodZwY1 jLtvmXY2Va6vKhJxXkoX5m06CO+ksg+fFyN78wFSrLCuYDW8klgel/Bk9JErcCKKFHlS tRZNuuXGLCztiJQTD23UMuCddP+yT33Cd5kK6P+uDcWs+PNlRJCTZXD/Y09F9fyPxvCa TkHA== MIME-Version: 1.0 Received: by 10.182.136.71 with SMTP id py7mr21517124obb.45.1341495464264; Thu, 05 Jul 2012 06:37:44 -0700 (PDT) Received: by 10.76.19.16 with HTTP; Thu, 5 Jul 2012 06:37:44 -0700 (PDT) X-Originating-IP: [24.21.216.213] In-Reply-To: References: Date: Thu, 5 Jul 2012 06:37:44 -0700 Message-ID: From: David Meyer To: "Andrew G. Malis" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQl4BELDcA9YJSiT4OUWfJgEjyhfhjByjY8q0ZgfQobbMVRAJ72Zwe3q6mxJ8KzhbTemUyYC Cc: pwe3@ietf.org, Andrew McLachlan , Jan Medved Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 13:37:39 -0000 Thanks Andrew. Working on the next rev and will incorporate your suggestions/comments. ---dmm On Tue, Jul 3, 2012 at 11:14 AM, Andrew G. Malis wrote: > Dave, Jan, Andrew, > > An interesting draft. I have a few comments, with my WG chair hat off: > > 1. An editorial comment, there's no "-" or internal uppercase "W" in > "Pseudowire", which is the proper spelling (I saw at least three > different spellings in the draft). > > 2. Section 1.3 states: "PWs are > configured as bi-directional paths over the MPLS-TP network, usually > by an external management platform. At present no open standards > exist to provision these PWs, and therefore there is a reliance on > vendor specific provisioning platforms." > > Certainly, there's nothing that prevents the use of T-LDP for PW use > in MPLS-TP networks, this is already documented in section 5.2 of RFC > 6373. > > Speaking of which, you should also have a table in your draft similar > to the table in section 5.2 that shows how your draft meets the > MPLS-TP control plane requirements listed in section 2 of RFC 6373. > > You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp, > which specifies useful functionality in this area. > > In any case, you should be clear that this is an alternative control > plane to T-LDP. > > 3. Section 4: In addition to RFC 6423, you may wish to include a > reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode > for use with MPLS-TP. You may also wish to reference RFC 5860. > > Cheers, > Andy > > On Tue, Jul 3, 2012 at 1:11 PM, David Meyer wrote: >> Folks, >> >> "MPLS-TP PseudoWire Configuration using OpenFlow 1.3" has just been >> posted. Looking forward to your review. >> >> --dmm (for Jan, dward, and Andrew) >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 From wwwrun@rfc-editor.org Thu Jul 5 12:19:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEFB21F8653 for ; Thu, 5 Jul 2012 12:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.184 X-Spam-Level: X-Spam-Status: No, score=-102.184 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqQx9HtD+AeU for ; Thu, 5 Jul 2012 12:19:21 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7509E21F85B6 for ; Thu, 5 Jul 2012 12:19:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id DDEC0B1E002; Thu, 5 Jul 2012 12:18:04 -0700 (PDT) To: mustapha.aissaoui@alcatel-lucent.com, busschbach@alcatel-lucent.com, lmartini@cisco.com, mmorrow@cisco.com, Thomas.Nadeau@ca.com, yaakov_s@rad.com, stbryant@cisco.com, adrian@olddog.co.uk, matthew.bocci@alcatel-lucent.com, andrew.g.malis@verizon.com From: RFC Errata System Message-Id: <20120705191804.DDEC0B1E002@rfc-editor.org> Date: Thu, 5 Jul 2012 12:18:04 -0700 (PDT) Cc: pwe3@ietf.org, muly_i@rad.com, rfc-editor@rfc-editor.org Subject: [PWE3] [Editorial Errata Reported] RFC6310 (3281) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 19:19:22 -0000 The following errata report has been submitted for RFC6310, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6310&eid=3281 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: 6.1.3 Original Text ------------- This is achieved by including a capability TLV in the PW Forward Error Correction (FEC) interface parameters TLV. Corrected Text -------------- This is achieved by including a capability TLV in the PW Forwarding Equivalence Class (FEC) interface parameters TLV. Notes ----- "FEC" should also be added to the list of abbreviations in section 2.1. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6310 (draft-ietf-pwe3-oam-msg-map-16) -------------------------------------- Title : Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping Publication Date : July 2011 Author(s) : M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein Category : PROPOSED STANDARD Source : Pseudowire Emulation Edge to Edge Area : Routing Stream : IETF Verifying Party : IESG From dmm@1-4-5.net Thu Jul 5 12:22:06 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24B611E80D1 for ; Thu, 5 Jul 2012 12:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48z2rGoy87jO for ; Thu, 5 Jul 2012 12:22:05 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6F11E80CE for ; Thu, 5 Jul 2012 12:22:04 -0700 (PDT) Received: by yenq13 with SMTP id q13so8621519yen.31 for ; Thu, 05 Jul 2012 12:22:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=sR1reFGqpIJ43dLAoK6fFiiVh+KB4HquqG1DYv8Vg0A=; b=nRWjsOqEWy0ngsbO5jZRARyhdHG5u+IQ5teu/nqnEP2yfaBRNP3EL6Nrssv0xWcMsh x2ozutFwBuTeTc7oc41J/Xmjt3dNFd+zBDyUXxP/p1Oarrk+WDYbb1vGsn+KBALSzP2J JCTMjxi0jcuS2kczcVcibv47IEQwgBKT9btp/rIpDW3RfaCveTx0COEmUWjgkvuQANCs /JfP8y8YPN/L3Td7BhynlYzawT8v8rd3A6IvdytZGrByG+qw7z2TC2ergTCdmQz6LLyU v/0EOqcHnF8gfzbstYZmYEc+4e7680uW9SQ6S5z7U/Khyj8nRRxpX2NQBoxCN55nm4F9 n85A== MIME-Version: 1.0 Received: by 10.60.29.72 with SMTP id i8mr27951516oeh.26.1341516138960; Thu, 05 Jul 2012 12:22:18 -0700 (PDT) Received: by 10.76.19.16 with HTTP; Thu, 5 Jul 2012 12:22:18 -0700 (PDT) X-Originating-IP: [171.68.46.188] Date: Thu, 5 Jul 2012 12:22:18 -0700 Message-ID: From: David Meyer To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlM+lnHunIDthIp2yd3q0ssLOVYaCzecPklwr9OIW/ZpMkuOtdgZmDJrhTRGjk/fsZ4aOfk Cc: Jan Medved Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 19:22:06 -0000 Dave, We'd like to get a slot for Topic: draft-medved-pwe3-of-config Draft Name: draft-medved-pwe3-of-config Requested Duration: 20 minutes Speaker Name: TBD (Jan, dmm, or Andrew) Thnx, --dmm From Alexander.Vainshtein@ecitele.com Thu Jul 5 12:39:00 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B054021F8624 for ; Thu, 5 Jul 2012 12:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOxt4imzG4AW for ; Thu, 5 Jul 2012 12:38:59 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5833421F8616 for ; Thu, 5 Jul 2012 12:38:59 -0700 (PDT) Received: from [85.158.143.35:13266] by server-2.bemta-4.messagelabs.com id B0/F1-17938-06DE5FF4; Thu, 05 Jul 2012 19:39:12 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-21.messagelabs.com!1341517151!12597385!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 1537 invoked from network); 5 Jul 2012 19:39:11 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-3.tower-21.messagelabs.com with SMTP; 5 Jul 2012 19:39:11 -0000 X-AuditID: a8571402-b7f116d0000051b6-8b-4ff5e9296b11 Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 29.94.20918.A29E5FF4; Thu, 5 Jul 2012 21:21:14 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 5 Jul 2012 21:39:09 +0200 From: Alexander Vainshtein To: RFC Errata System , "mustapha.aissaoui@alcatel-lucent.com" , "busschbach@alcatel-lucent.com" , "lmartini@cisco.com" , "mmorrow@cisco.com" , "Thomas.Nadeau@ca.com" , "yaakov_s@rad.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "matthew.bocci@alcatel-lucent.com" , "andrew.g.malis@verizon.com" , "muly_i@rad.com" Thread-Topic: [PWE3] [Editorial Errata Reported] RFC6310 (3281) Thread-Index: AQHNWuMh1LctqcPNfEmRYG1F0rHQMJcbE6Rb Date: Thu, 5 Jul 2012 19:39:09 +0000 Message-ID: References: <20120705191804.DDEC0B1E002@rfc-editor.org> In-Reply-To: <20120705191804.DDEC0B1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLsWRmVeSWpSXmKPExsXCxcggpav18qu/weSJChY/em4wW7Rv38Vo 8fLRbyaL53f+slsc7rrLaNF1eD27xeKvu9ktWuatY7Lo+7SFxaJp/1c2i3NP5zBanG98zGLx oesHqwOvR+uzvawenQuEPab83sjqsWTJTyaPFZtXMnpMWpvm0dB2jNWj9btoAEdUA6NNYl5e fkliSapCSmpxsq1SQFFmWWJypZJCZoqtkqGSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrL zFNIzUvOT8nMS7dV8gz217WwMLXUNVSyC8nILFZI1c1NzMxRyE0tLk5MT1UAioD8n5eSsI45 49HT90wFW8UqDj3Na2DcJtTFyMkhIWAisaL9MhOELSZx4d56ti5GLg4hgVOMEkv7m1khnMWM EndnbWQEqWITsJXYtPouG4gtIvCLRaK/txTEZhZwkzh19hRYXFjATmLfjTusEDX2EmcnzQeK cwDZRhKdvSYgYRYBFYmJE96DlfAK+Eqs+72DBcQWEjCX2D7nEDOIzSlgIbHmxA2wOCPQcd9P rWGCWCUucevJfKijBSSW7DnPDGGLSrx8/I8VwpaXuPjhAVS9jsSC3Z/YIGxtiWULXzND7BWU ODnzCQtEvaTEwRU3WCYwis9CsmIWkvZZSNpnIWlfwMiyilHCLcjTxScgINjJwMBIz9XZM8TV x1XP2d93EyMw3a0IF2Hawdh80/AQowAHoxIP742sL/5CrIllxZW5hxglOZiURHl3vPjqL8SX lJ9SmZFYnBFfVJqTWnyIUYKDWUmEtzcDKMebklhZlVqUD5OyAAbiRGYp7uR8UAyXxBsbGKBw lMR544Ls/IUE0oHJLjs1tSC1CKZVhoNDSYK3/Q3QVMGi1PTUirTMnBKENBMHJ8hmHqDNnSA1 vMUFibnFmekQ+VOMklLivCUgCQGQREZpHlzvK0ZxoP+EeSNAsjzApAfX9QpoIBPQwLzFn0AG ArMCXEqqgVH1UjGTrSlH4pxpeslr1/wuOaxv65F+9s3mpNTz/yUmfpz5wb9LaEKsd8Wnd7IN 8t912llDRNOven473n6ySuTwgTn/buRP/JGy9unk2dmreBTSNBRvL1txvjhonfQu2bO/Oexa 1r8567uwUjH/xxtD+wTuP0l/s3r1L93eJ3b8ouaVsN9baycqsRRnJBpqMRcVJwIAgXqYSTcE AAA= Cc: "pwe3@ietf.org" , "muly_i@rad.com" Subject: Re: [PWE3] [Editorial Errata Reported] RFC6310 (3281) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 19:39:00 -0000 Hi all, Muly, a good catch! Of course this Erratum should be verified. To the best of my recollection Yaakov and I have encountered a similar inapp= ropriate expansion (FEC --> Forward Error Correction instead of FEC --> Forw= ard Equivalent Class) by the RFC Editor while working on RFC 5287, but have= been lucky enough to catch it before publication. So it looks like a recurr= ent error (without a forward correction mechanism:-) in the RFC Editor proce= ss. My 2c, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of RFC Errata= System [rfc-editor@rfc-editor.org] Sent: Thursday, July 05, 2012 9:18 PM To: mustapha.aissaoui@alcatel-lucent.com; busschbach@alcatel-lucent.com; lma= rtini@cisco.com; mmorrow@cisco.com; Thomas.Nadeau@ca.com; yaakov_s@rad.com;= stbryant@cisco.com; adrian@olddog.co.uk; matthew.bocci@alcatel-lucent.com;= andrew.g.malis@verizon.com Cc: pwe3@ietf.org; muly_i@rad.com; rfc-editor@rfc-editor.org Subject: [PWE3] [Editorial Errata Reported] RFC6310 (3281) The following errata report has been submitted for RFC6310, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message M= apping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6310&eid=3D3281 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: 6.1.3 Original Text ------------- This is achieved by including a capability TLV in the PW Forward Error Corre= ction (FEC) interface parameters TLV. Corrected Text -------------- This is achieved by including a capability TLV in the PW Forwarding Equivale= nce Class (FEC) interface parameters TLV. Notes ----- "FEC" should also be added to the list of abbreviations in section 2.1. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6310 (draft-ietf-pwe3-oam-msg-map-16) -------------------------------------- Title : Pseudowire (PW) Operations, Administration, and Mainte= nance (OAM) Message Mapping Publication Date : July 2011 Author(s) : M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.= Nadeau, Y(J). Stein Category : PROPOSED STANDARD Source : Pseudowire Emulation Edge to Edge Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From stbryant@cisco.com Thu Jul 5 12:50:15 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F8221F84D5 for ; Thu, 5 Jul 2012 12:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.563 X-Spam-Level: X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJrKLx2a-vgG for ; Thu, 5 Jul 2012 12:50:14 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 25D0521F84C2 for ; Thu, 5 Jul 2012 12:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=3642; q=dns/txt; s=iport; t=1341517828; x=1342727428; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=k7AjE+dk9uVw4Kjhtq24jmdqKrYAvo588BlpQ/2JwEk=; b=LTjQ5Z9ZYYYa0h2jp2WhXx0K1uFsvf6k8dZG1jYcqcyx9vNwMCTbzfBA maGxycwM/WxOEMjdQTWFxVM3j4OGuJB+8wqeg2R7FIN9w0JvPzyHCO/7P Q6zb5751yGmBiy7CImFUdoH9DFV8WhhnS4NIVw5oQn3GrZao7jRsR76nO 4=; X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="51047579" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 05 Jul 2012 19:50:28 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q65JoQJC006590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Jul 2012 19:50:28 GMT Received: from stbryant-mac2.lan (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q65JoNoe019375; Thu, 5 Jul 2012 20:50:23 +0100 (BST) Message-ID: <4FF5EFFF.3010608@cisco.com> Date: Thu, 05 Jul 2012 20:50:23 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Vainshtein References: <20120705191804.DDEC0B1E002@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "yaakov_s@rad.com" , "Thomas.Nadeau@ca.com" , "lmartini@cisco.com" , "muly_i@rad.com" , "busschbach@alcatel-lucent.com" , "pwe3@ietf.org" , "mustapha.aissaoui@alcatel-lucent.com" , "andrew.g.malis@verizon.com" Subject: Re: [PWE3] [Editorial Errata Reported] RFC6310 (3281) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2012 19:50:16 -0000 Sasha Whilst it is an error, I am not convinced that anyone would incorrectly implement the protocol as a result of this error, and thus it seems to me that it should be deferred to the next revision of RFC6310. - Stewart On 05/07/2012 20:39, Alexander Vainshtein wrote: > Hi all, > > Muly, a good catch! Of course this Erratum should be verified. > > To the best of my recollection Yaakov and I have encountered a similar inappropriate expansion (FEC --> Forward Error Correction instead of FEC --> Forward Equivalent Class) by the RFC Editor while working on RFC 5287, but have been lucky enough to catch it before publication. So it looks like a recurrent error (without a forward correction mechanism:-) in the RFC Editor process. > > My 2c, > Sasha > ________________________________________ > From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of RFC Errata System [rfc-editor@rfc-editor.org] > Sent: Thursday, July 05, 2012 9:18 PM > To: mustapha.aissaoui@alcatel-lucent.com; busschbach@alcatel-lucent.com; lmartini@cisco.com; mmorrow@cisco.com; Thomas.Nadeau@ca.com; yaakov_s@rad.com; stbryant@cisco.com; adrian@olddog.co.uk; matthew.bocci@alcatel-lucent.com; andrew.g.malis@verizon.com > Cc: pwe3@ietf.org; muly_i@rad.com; rfc-editor@rfc-editor.org > Subject: [PWE3] [Editorial Errata Reported] RFC6310 (3281) > > The following errata report has been submitted for RFC6310, > "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6310&eid=3281 > > -------------------------------------- > Type: Editorial > Reported by: Muly Ilan > > Section: 6.1.3 > > Original Text > ------------- > This is achieved by including a capability TLV in the PW Forward Error Correction (FEC) interface parameters TLV. > > Corrected Text > -------------- > This is achieved by including a capability TLV in the PW Forwarding Equivalence Class (FEC) interface parameters TLV. > > Notes > ----- > "FEC" should also be added to the list of abbreviations in section 2.1. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6310 (draft-ietf-pwe3-oam-msg-map-16) > -------------------------------------- > Title : Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping > Publication Date : July 2011 > Author(s) : M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein > Category : PROPOSED STANDARD > Source : Pseudowire Emulation Edge to Edge > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 > This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof. > > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From yaakov_s@rad.com Fri Jul 6 04:55:58 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD4421F879E for ; Fri, 6 Jul 2012 04:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBaLDirIQYQi for ; Fri, 6 Jul 2012 04:55:57 -0700 (PDT) Received: from rad.co.il (mailrelay01-q.rad.co.il [80.74.100.150]) by ietfa.amsl.com (Postfix) with ESMTP id 35A7421F879C for ; Fri, 6 Jul 2012 04:55:54 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 6 Jul 2012 14:36:07 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Fri, 6 Jul 2012 14:56:04 +0300 From: Yaakov Stein To: RFC Errata System , "mustapha.aissaoui@alcatel-lucent.com" , "busschbach@alcatel-lucent.com" , "lmartini@cisco.com" , "mmorrow@cisco.com" , "Thomas.Nadeau@ca.com" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "matthew.bocci@alcatel-lucent.com" , "andrew.g.malis@verizon.com" Thread-Topic: [Editorial Errata Reported] RFC6310 (3281) Thread-Index: AQHNWuMhpo7MUQ6s/UC0kk9XKZYUA5ccJk4w Date: Fri, 6 Jul 2012 11:56:03 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044DFA2B@EXRAD5.ad.rad.co.il> References: <20120705191804.DDEC0B1E002@rfc-editor.org> In-Reply-To: <20120705191804.DDEC0B1E002@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [207.232.33.112] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A020208.4FF6D256.0044,ss=1,fgs=0 Cc: "pwe3@ietf.org" , Muly Ilan Subject: Re: [PWE3] [Editorial Errata Reported] RFC6310 (3281) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 11:55:58 -0000 Indeed, this erratum should be approved. The erratum submitter told me about this nit, and I encouraged him to submi= t it as an erratum. Y(J)S -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Thursday, July 05, 2012 22:18 To: mustapha.aissaoui@alcatel-lucent.com; busschbach@alcatel-lucent.com; lm= artini@cisco.com; mmorrow@cisco.com; Thomas.Nadeau@ca.com; Yaakov Stein; st= bryant@cisco.com; adrian@olddog.co.uk; matthew.bocci@alcatel-lucent.com; an= drew.g.malis@verizon.com Cc: Muly Ilan; pwe3@ietf.org; rfc-editor@rfc-editor.org Subject: [Editorial Errata Reported] RFC6310 (3281) The following errata report has been submitted for RFC6310, "Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message = Mapping". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6310&eid=3D3281 -------------------------------------- Type: Editorial Reported by: Muly Ilan Section: 6.1.3 Original Text ------------- This is achieved by including a capability TLV in the PW Forward Error Corr= ection (FEC) interface parameters TLV. Corrected Text -------------- This is achieved by including a capability TLV in the PW Forwarding Equival= ence Class (FEC) interface parameters TLV. Notes ----- "FEC" should also be added to the list of abbreviations in section 2.1. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC6310 (draft-ietf-pwe3-oam-msg-map-16) -------------------------------------- Title : Pseudowire (PW) Operations, Administration, and Maint= enance (OAM) Message Mapping Publication Date : July 2011 Author(s) : M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T.= Nadeau, Y(J). Stein Category : PROPOSED STANDARD Source : Pseudowire Emulation Edge to Edge Area : Routing Stream : IETF Verifying Party : IESG From dmm@1-4-5.net Fri Jul 6 07:42:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D05921F8597 for ; Fri, 6 Jul 2012 07:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9ngMt62BJqo for ; Fri, 6 Jul 2012 07:42:49 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4721F858A for ; Fri, 6 Jul 2012 07:42:49 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6742303vcq.31 for ; Fri, 06 Jul 2012 07:43:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UeuUmeIGChhRFPekMuaFyc7Ul7kSdsSsAGk4zqQknw0=; b=WwV1phYUWAK1l+W6LIqI2QZmlcgRelPn1EnrnaUtpNNeLvXStRiMw9Gr4X1hUkixvL 0gY/MRJH/S4IeyRBSVVOSj7dkNaWMIArEvVlA+KGIKS5bD11C55zcLhfoi8BP2U7JWgU Wp4soyToy0D8DMh8nsI0gQ8P2GTNGqCH+pWVsW0ai1Rj0I+nPQA/niaScnlXE5pOLG/L K86GVE594E8N5p/V1MHc3CBuNN2ae/RqCmnzBrIlQJHDjbVtCO6ceU917s9xnjrFgjvq ZSkHQhkXCEJuJY6PlHzs6M/cbci9BTX9qtPP3pALOhlaWilMfbjaoLQI6NdUJpyoGNek 1q5A== MIME-Version: 1.0 Received: by 10.52.92.129 with SMTP id cm1mr12087391vdb.126.1341585785722; Fri, 06 Jul 2012 07:43:05 -0700 (PDT) Received: by 10.52.115.167 with HTTP; Fri, 6 Jul 2012 07:43:05 -0700 (PDT) X-Originating-IP: [2001:468:d01:9c:d027:bf4e:284e:8b07] In-Reply-To: References: Date: Fri, 6 Jul 2012 07:43:05 -0700 Message-ID: From: David Meyer To: "Andrew G. Malis" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnqB9R489ufcHwZQUNhxoYD5slBsgO+hthoXmp5pgAuAbW+U+uHoEPZwxbmv/1+oRt5Eeqd Cc: pwe3@ietf.org, Andrew McLachlan , Jan Medved Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:42:50 -0000 Hey Andy, On Tue, Jul 3, 2012 at 11:14 AM, Andrew G. Malis wrote: > Dave, Jan, Andrew, > > An interesting draft. I have a few comments, with my WG chair hat off: > > 1. An editorial comment, there's no "-" or internal uppercase "W" in > "Pseudowire", which is the proper spelling (I saw at least three > different spellings in the draft). Fixed, thanks. > > 2. Section 1.3 states: "PWs are > configured as bi-directional paths over the MPLS-TP network, usually > by an external management platform. At present no open standards > exist to provision these PWs, and therefore there is a reliance on > vendor specific provisioning platforms." > > Certainly, there's nothing that prevents the use of T-LDP for PW use > in MPLS-TP networks, this is already documented in section 5.2 of RFC > 6373. > > Speaking of which, you should also have a table in your draft similar > to the table in section 5.2 that shows how your draft meets the > MPLS-TP control plane requirements listed in section 2 of RFC 6373. This is part of what wasn't well stated in the draft. We're not proposing a new TP control plane, rather just a way of provisioning PWs over existing MPLS-TP control planes. > > You may also wish to read draft-cao-pwe3-mpls-tp-pw-over-bidir-lsp, > which specifies useful functionality in this area. > > In any case, you should be clear that this is an alternative control > plane to T-LDP. As mentioned above, its not an alternate control plane. > > 3. Section 4: In addition to RFC 6423, you may wish to include a > reference to draft-ietf-pwe3-vccv-for-gal, which defines the VCCV mode > for use with MPLS-TP. You may also wish to reference RFC 5860. Still thinking about this one. Thanks for the comments. New (clearer) revision should be out by Monday. --dmm From dmm@1-4-5.net Fri Jul 6 07:59:31 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE96A21F86B6 for ; Fri, 6 Jul 2012 07:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6E4yFcHXVNLh for ; Fri, 6 Jul 2012 07:59:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C736121F85A1 for ; Fri, 6 Jul 2012 07:59:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6764016vbb.31 for ; Fri, 06 Jul 2012 07:59:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Mq7Z/lRqMRYnOp2ddWi5gDvsrKHYk1ThnY6ikZhPT0U=; b=MO4ZNKtpBY1wxN5bTMNxcVJaVME6bvYDgVFqeP9V/LWebnIT5ch1SwQ6K0qMZMYYio JSgSUcGbg73to+FNitN+r+pc7CsFFpfl1v3fxPkkXDQmNoaaZwNecS3KRcT6kZG8iCIK sXQca6Gw+YfWN3z2ZdnuVcA6b5ltumLXjd+ijEECTFYDcrqnpwfrV7vJxd615ASGPsj4 Y1B8ho0wZlm7Gc1gHwxo4ynOAKhhRaAt8loyd24UtQ4LB9scMQ8WX8NOTqvIgeBUNcZH c9+nIcWae0jejuveg+LgJAB5be1qGpKFOnc/xETKKuzaeCVatVabtiiIW4cqt1V7UzJo dDhQ== MIME-Version: 1.0 Received: by 10.220.247.139 with SMTP id mc11mr14608719vcb.52.1341586786090; Fri, 06 Jul 2012 07:59:46 -0700 (PDT) Received: by 10.52.115.167 with HTTP; Fri, 6 Jul 2012 07:59:46 -0700 (PDT) X-Originating-IP: [2001:468:d01:9c:d027:bf4e:284e:8b07] In-Reply-To: References: Date: Fri, 6 Jul 2012 07:59:46 -0700 Message-ID: From: David Meyer To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQm6bFoNB9/5CeCtsZj8jf6NX5kGPhsSY5OJ+pKr2FDv9U25053LML1XieneHV7SangwRTBY Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Jan Medved , "pwe3@ietf.org" , Andrew McLachlan , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 14:59:31 -0000 Alexander, On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein wrote: > Andy and all, > > I've looked up the draft in question, and I have some comments/questions in > addition to Andy's: > > The PWE3 WG has defined multiple MIBs that can be used for PW setup and > teardown by a management application (MPLS-TP or not). IMO the draft > should indicate that the method proposed there is an alternative not just to > PW signaling via T-LDP (as Andy has said) but also to static PW setup using > these MIBs. As I mentioned, the draft did not intended to provide an alternate control plane; hopefully that will be clear in the next rev. I'll add some text around the point you make WRT MIBs above. > The wording of the draft seems to suggest a difference between the head-end > PE and the tail-end one, e.g., as in he following fragment: "Although the > Virtual OF switch is the same a both the head-end and tail-end nodes, the > group table is only used at the head-end node, where a Fast Failover group > is set up for each pair of ports that correspond to the primary-backup > Transport LSP pair. At the tail-end node, only flows are set up." I do not > understand how does this (and similar) fragments deal with the fact of PWs > being inherently bidirectional. I've cleaned this up. The distinction was in the description, not the functionality. Thanks for point this out. > The PWs run in MPLS (or MPLS-TP) tunnels in order to improve scalability of > P routers, because the same tunnel between a given pair of PEs can be shared > by multiple PW instances. It is not clear from the text how such sharing can > be accommodated in the proposed OF switch model. Humm, here is nothing that stops the "transport virtual port" from sharing transport labels if that is appropriate. Perhaps I'm not understanding your point? > Reference to RFC 6423 suggests that OAM discussion in the draft is PW OAM > and OAM for Tunnel LSPs. Does this imply that the protection actions are > triggered by the PW-level OAM, and, what is supposed to happen if a pair of > T-LSPs is shared by multiple PW instances? That wasn't the intention; will clean up the text. > The text defining the OF switch and its matching rules is not clear. In > particular, it seems to imply that PW labels are checked from being received > from a specific T-LSP (as a port of the OF switch). IMHO this a clear > contradiction to the MPLS (and MPLS-TP) data plane as defined in RFC 3031, > and to the fact that PW labels are allocated from the per-platform label > space (as per RFC 4447). Again, this wasn't the intention. I'll have a look at how we might clean this up. Thanks for the comments. --dmm From ietf-ipr@ietf.org Fri Jul 6 10:09:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9920121F876E; Fri, 6 Jul 2012 10:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6Ygvzjj02wm; Fri, 6 Jul 2012 10:09:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A1721F869E; Fri, 6 Jul 2012 10:09:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: lmartini@cisco.com, matthew.bocci@alcatel-lucent.co.uk, florin.balus@alcatel-lucent.com X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706170910.29277.8856.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 10:09:10 -0700 Cc: pwe3@ietf.org, andrew.g.malis@verizon.com, ipr-announce@ietf.org, stbryant@cisco.com Subject: [PWE3] IPR Disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-pwe3-dynamic-ms-pw-15 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 17:09:11 -0000 Dear Luca Martini, Matthew Bocci, Florin Balus: An IPR disclosure that pertains to your Internet-Draft entitled "Dynamic Placement of Multi Segment Pseudowires" (draft-ietf-pwe3-dynamic-ms-pw) was submitted to the IETF Secretariat on 2012-07-05 and has been posted on the = "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1810/). The title of the IPR disclosure is "Alcatel-Lucent's Statement about IPR related to draft-ietf-pwe3-dynamic-ms- pw-15.""); The IETF Secretariat From Alexander.Vainshtein@ecitele.com Fri Jul 6 11:29:25 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9203311E809F for ; Fri, 6 Jul 2012 11:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNz6si+-lQdx for ; Fri, 6 Jul 2012 11:29:24 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 1213A11E8079 for ; Fri, 6 Jul 2012 11:29:23 -0700 (PDT) Received: from [85.158.143.99:30797] by server-2.bemta-4.messagelabs.com id E6/36-17938-39E27FF4; Fri, 06 Jul 2012 18:29:39 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-216.messagelabs.com!1341599379!24211813!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 23294 invoked from network); 6 Jul 2012 18:29:39 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-7.tower-216.messagelabs.com with SMTP; 6 Jul 2012 18:29:39 -0000 X-AuditID: a8571402-b7f116d0000051b6-f3-4ff72a5712d4 Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 12.B4.20918.75A27FF4; Fri, 6 Jul 2012 20:11:35 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Fri, 6 Jul 2012 20:29:38 +0200 From: Alexander Vainshtein To: David Meyer Thread-Topic: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Thread-Index: AQHNWT7xvqwGUdtG106/a2x3EHFnsJcXu00AgADPmMyAA7EMAIAAV6uu Date: Fri, 6 Jul 2012 18:29:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTaUwTQRh1drftUlmzFLBDverGH14lrWiyGooHYkqEFFFDQuKxtmO72m6b blHKLxI1JqiIiRdVIygiwROVBKOYUI0ENFqjJoqCRkg88CBeKKhxt4uIcX69mffevPlmviFx 3Se1geSFIAoInIdRawktGGUwFUzvt5tvRCDb9bBWw3ZX3lezkbIGDbtz8AHOln+8RCxQ2U43 3yRsewcbVLbL4U6N7U77SltNzXcsT1VYCtI5QfAFuSAyOpHosDJ5AX4T5wgxRt5pZSyM0e/h HMiLhKCV4fx+JDiZDK3xv5EuyXjBiASHz8kLLiuTvdxuYtk5c00WJmOFmxeNyOTleI/Ri0SR cyGjtCKXIjjXnsXd798N4P5rsHjHnWZVKWhNLANxJKRnw67ackLBY2G065y6DGhJHd0OYO9A HVAmxwF80rFLI6vUtBVeONWplnESPQm2RI9hsginj+DwW+PhGJFI58CTL+8OiXLh1oOtQ3gJ jDZvi2GCngKrm75gMqYkTbTyokZJq8Lg9YHqmCiOXga/bO+JJQPpfP3tp2MGnNbDjp6jmHJu GtZcvYsrOBm+7v6lUvAkeK/v+ZB+Jqy68lGt4BmwtroXV4ITYFtlz1D9KbCl7hFRAfThERHh EfbwCHt4hL0KEPUALsnPXpyTl7d8kdk8KzUrM3tFVk5WaqY99wKQ2qiuIAlrAlseWyKAJgET T4FDX+06FbdJDHkjIIXEmGSqzdRv141Z53OG3JzoXhMo8iAxAiCJM0nU9j5JTjm5UAkK+P5Q rHSLe3DDaIdPfuXgmjSz+Z8Jo6dW52fYdbRLar2NCPlR4I91PEkykLotJyYEkAsVr+c9wb80 RsbJyfFScoesoUQ/5xV5l8K3gxSDXjHTMuEuEoa9b4Beqi+R6pTZeKn9hl1vpA0xacP1B+VS ROk7DFOGUlBYH6qwtlgsFL0/mWnprSj++fLHgqkHNo+aOaHt8yqi9UNCAbv2xrxo37TznXvT yl+lbXjqTdcubExpyCrMrRzMOGHyNX0PZRZdL1k6/23mupVUSdfu4kU5jZMHPA3uM0UJ2x7e /zy2fu7EW7kvuiPPjhYCQyQ/9dShcc59r/d8AuQyhhDdnGU6HhC538jo5KoGBAAA Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Jan Medved , "pwe3@ietf.org" , Andrew McLachlan , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:29:25 -0000 David, Please see a couple of comments inline below. Hopefully they clarify my posi= tion. I have snipped some fragments of your response to make the remaining text mo= re readable. Regards, Sasha ________________________________________ From: David Meyer [dmm@1-4-5.net] Sent: Friday, July 06, 2012 4:59 PM To: Alexander Vainshtein Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; pwe3@ietf.org; Mishael We= xler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir Klein= er Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please Alexander, On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein wrote: > Andy and all, > > I've looked up the draft in question, and I have some comments/questions i= n > addition to Andy's: > > The PWE3 WG has defined multiple MIBs that can be used for PW setup and > teardown by a management application (MPLS-TP or not). IMO the draft > should indicate that the method proposed there is an alternative not just= to > PW signaling via T-LDP (as Andy has said) but also to static PW setup usin= g > these MIBs. As I mentioned, the draft did not intended to provide an alternate control plane; hopefully that will be clear in the next rev. I'll add some text around the point you make WRT MIBs above. [[Sasha]] Well, MIBs are not part of control plane (at least, for me), but o= f the Management Plane - and, to the best of my understanding, so is OpenFlo= w. But putting terminology aside, the PWE3 MIBs provide a certain abstract m= odel of the PW endpoints that is integrated with the existing model for MPLS= etc. Your draft seems to offer an alternative abstract model that seems to mix PW= and MPLS functionality. --- snipped -- > The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalabilit= y of > P routers, because the same tunnel between a given pair of PEs can be shar= ed > by multiple PW instances. It is not clear from the text how such sharing c= an > be accommodated in the proposed OF switch model. Humm, here is nothing that stops the "transport virtual port" from sharing transport labels if that is appropriate. Perhaps I'm not understanding your point? [[Sasha]] What is important is that multiple PWs sharing a common MPLS tunne= l LSP are fate-sharing in the PSN core, and the model should IMHO reflect th= is fact explicitly. E.g., the protection switch is applied to tunnel LSPs, n= ot to individual PWs. This affects both the management aspects (e.g., failur= es of individual PWs sharing a tunnel LSP should be suppressed when the tune= el LSP fails) and the data plane (e.g., the time it takes to complete a prot= ection switch triggered by the tunnel LSP failure should not depend upon the= number of PWs using this tunnel LSP). IMHO and FWIW the model where each PW= uses its individual "transport virtual ports" does not make this easy (if a= t all possible) even if you allow sharing of labels between thee ports. Or d= o I miss something? --- snipped to the end --- This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From dmm@1-4-5.net Fri Jul 6 11:35:43 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9300F21F864E for ; Fri, 6 Jul 2012 11:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mh8noEAm3mo for ; Fri, 6 Jul 2012 11:35:42 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE8FB21F864D for ; Fri, 6 Jul 2012 11:35:42 -0700 (PDT) Received: by vcqp1 with SMTP id p1so6888220vcq.31 for ; Fri, 06 Jul 2012 11:35:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=01XdbwACYu1Xdk4OrD/j+pjXBd31OE8HaC0/W97FZFo=; b=nczZWeVdl3d52630vEv57RvoL5A6zq21P8yfDmce8JTDtL+1miLhc2Ue/0GvXDOku7 8ZUrx9KubIGY8IOGRgNA2tmQbxP0q2po8RkyaBpoEBzcJC/XeHgrDaWz0gOcLgNSTqi7 CaYdZv2rHAo9duaurHvQfWmJuW4+I5u5D4xx/bBRBFUjUlxBkf9z/pmxvIeTne/n3z0X DFxo7D6SlaNmxmml6vRLJ7qCUIS9OHX2CY2YbzBtoOXhJuvyTRqPG7OkIxEyoGQ9MUDu nsAUPAUli852RUpoB7ezsC2rVJhV0bNzNEtjzlHHsXs1L0ubLxkZ+DWJ/do0N227Y0Ly lm2Q== MIME-Version: 1.0 Received: by 10.52.95.171 with SMTP id dl11mr12368340vdb.120.1341599759034; Fri, 06 Jul 2012 11:35:59 -0700 (PDT) Received: by 10.52.115.167 with HTTP; Fri, 6 Jul 2012 11:35:58 -0700 (PDT) X-Originating-IP: [24.21.216.213] In-Reply-To: References: Date: Fri, 6 Jul 2012 11:35:58 -0700 Message-ID: From: David Meyer To: Alexander Vainshtein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkfenuwPYliE8eEavgTRgAOLN7tfgrdMMJIiADHBOvvYtibM8FpvfykHvh158VNzvbQpKfp Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Jan Medved , "pwe3@ietf.org" , Andrew McLachlan , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:35:43 -0000 Excellent comments/clarifications Sasha. Thanks, really appreciate it and I'll work this into the next rev (working on that now). --dmm On Fri, Jul 6, 2012 at 11:29 AM, Alexander Vainshtein wrote: > David, > Please see a couple of comments inline below. Hopefully they clarify my p= osition. > > I have snipped some fragments of your response to make the remaining text= more readable. > > Regards, > Sasha > > ________________________________________ > From: David Meyer [dmm@1-4-5.net] > Sent: Friday, July 06, 2012 4:59 PM > To: Alexander Vainshtein > Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; pwe3@ietf.org; Mishael= Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir K= leiner > Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review ple= ase > > Alexander, > > > On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein > wrote: >> Andy and all, >> >> I've looked up the draft in question, and I have some comments/questions= in >> addition to Andy's: >> >> The PWE3 WG has defined multiple MIBs that can be used for PW setup and >> teardown by a management application (MPLS-TP or not). IMO the draf= t >> should indicate that the method proposed there is an alternative not jus= t to >> PW signaling via T-LDP (as Andy has said) but also to static PW setup us= ing >> these MIBs. > > As I mentioned, the draft did not intended to provide an alternate > control plane; hopefully that will be clear in the next rev. I'll add > some text around the point you make WRT MIBs above. > > [[Sasha]] Well, MIBs are not part of control plane (at least, for me), bu= t of the Management Plane - and, to the best of my understanding, so is Ope= nFlow. But putting terminology aside, the PWE3 MIBs provide a certain abstr= act model of the PW endpoints that is integrated with the existing model fo= r MPLS etc. > Your draft seems to offer an alternative abstract model that seems to mix= PW and MPLS functionality. > > --- snipped -- > >> The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalabil= ity of >> P routers, because the same tunnel between a given pair of PEs can be sh= ared >> by multiple PW instances. It is not clear from the text how such sharing= can >> be accommodated in the proposed OF switch model. > > Humm, here is nothing that stops the "transport virtual port" from > sharing transport labels if that is appropriate. Perhaps I'm not > understanding your point? > > [[Sasha]] What is important is that multiple PWs sharing a common MPLS tu= nnel LSP are fate-sharing in the PSN core, and the model should IMHO reflec= t this fact explicitly. E.g., the protection switch is applied to tunnel LS= Ps, not to individual PWs. This affects both the management aspects (e.g., = failures of individual PWs sharing a tunnel LSP should be suppressed when t= he tuneel LSP fails) and the data plane (e.g., the time it takes to complet= e a protection switch triggered by the tunnel LSP failure should not depend= upon the number of PWs using this tunnel LSP). IMHO and FWIW the model whe= re each PW uses its individual "transport virtual ports" does not make this= easy (if at all possible) even if you allow sharing of labels between thee= ports. Or do I miss something? > > --- snipped to the end --- > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > From amalis@gmail.com Fri Jul 6 11:48:03 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D822721F84DF for ; Fri, 6 Jul 2012 11:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHOHD5ZOxzXC for ; Fri, 6 Jul 2012 11:48:03 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E169A21F84D9 for ; Fri, 6 Jul 2012 11:48:02 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9801544ggn.31 for ; Fri, 06 Jul 2012 11:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=xAq/GyvXnpeDDArMYMe/r4RX1z+UeqUYYGXAii4O8pM=; b=p5OovlOONIdmMYDiZFwUBTZComaSDGHzQFYIbQG5cOjAG4LweRv3o69ZXWDflQombI QHzJbF7JmFK84saWzCUEvLTSNvGemOkXWQ80PJlN8hc9bpkcygvp1F9muKsi5CvlqYjC WHNA7ecbNlQ6W/lwioQlxJf7yEQl+xdjXkiCezJYuqiKFV0E3G9Byh1b1dSilgUphxqc c0yqptanZIiFelP+XIVplzURkKGq+2zMIxIDRiSYxqnTLWqe268bs15XK9dILRSyWXN2 bv9MCATzYmkWLCn0OYM4orYm8xX9gXUDW426I09T1dRJrw7ilJreO+KesmBajmNT4sOm znzA== Received: by 10.66.88.68 with SMTP id be4mr47285852pab.23.1341600498982; Fri, 06 Jul 2012 11:48:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.45.9 with HTTP; Fri, 6 Jul 2012 11:47:58 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 6 Jul 2012 14:47:58 -0400 Message-ID: To: David Meyer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Jan Medved , "pwe3@ietf.org" , Andrew McLachlan , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 18:48:04 -0000 Dave, One other comment that just occurred to me as you're working on your update - the current revision of the draft obviously only works with single-segment PWs, but that's not explicitly stated anywhere, other than being alluded to in the title of figure 1. You may wish to make that restriction explicit, unless you do intend to include MS-PWs in a future revision, in which case that should be made clear as well. Cheers, Andy On Fri, Jul 6, 2012 at 2:35 PM, David Meyer wrote: > Excellent comments/clarifications Sasha. Thanks, really appreciate it > and I'll work this into the next rev (working on that now). > > --dmm > > > On Fri, Jul 6, 2012 at 11:29 AM, Alexander Vainshtein > wrote: >> David, >> Please see a couple of comments inline below. Hopefully they clarify my = position. >> >> I have snipped some fragments of your response to make the remaining tex= t more readable. >> >> Regards, >> Sasha >> >> ________________________________________ >> From: David Meyer [dmm@1-4-5.net] >> Sent: Friday, July 06, 2012 4:59 PM >> To: Alexander Vainshtein >> Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; pwe3@ietf.org; Mishae= l Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir = Kleiner >> Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review pl= ease >> >> Alexander, >> >> >> On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein >> wrote: >>> Andy and all, >>> >>> I've looked up the draft in question, and I have some comments/question= s in >>> addition to Andy's: >>> >>> The PWE3 WG has defined multiple MIBs that can be used for PW setup and >>> teardown by a management application (MPLS-TP or not). IMO the dra= ft >>> should indicate that the method proposed there is an alternative not ju= st to >>> PW signaling via T-LDP (as Andy has said) but also to static PW setup u= sing >>> these MIBs. >> >> As I mentioned, the draft did not intended to provide an alternate >> control plane; hopefully that will be clear in the next rev. I'll add >> some text around the point you make WRT MIBs above. >> >> [[Sasha]] Well, MIBs are not part of control plane (at least, for me), b= ut of the Management Plane - and, to the best of my understanding, so is Op= enFlow. But putting terminology aside, the PWE3 MIBs provide a certain abst= ract model of the PW endpoints that is integrated with the existing model f= or MPLS etc. >> Your draft seems to offer an alternative abstract model that seems to mi= x PW and MPLS functionality. >> >> --- snipped -- >> >>> The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalabi= lity of >>> P routers, because the same tunnel between a given pair of PEs can be s= hared >>> by multiple PW instances. It is not clear from the text how such sharin= g can >>> be accommodated in the proposed OF switch model. >> >> Humm, here is nothing that stops the "transport virtual port" from >> sharing transport labels if that is appropriate. Perhaps I'm not >> understanding your point? >> >> [[Sasha]] What is important is that multiple PWs sharing a common MPLS t= unnel LSP are fate-sharing in the PSN core, and the model should IMHO refle= ct this fact explicitly. E.g., the protection switch is applied to tunnel L= SPs, not to individual PWs. This affects both the management aspects (e.g.,= failures of individual PWs sharing a tunnel LSP should be suppressed when = the tuneel LSP fails) and the data plane (e.g., the time it takes to comple= te a protection switch triggered by the tunnel LSP failure should not depen= d upon the number of PWs using this tunnel LSP). IMHO and FWIW the model wh= ere each PW uses its individual "transport virtual ports" does not make thi= s easy (if at all possible) even if you allow sharing of labels between the= e ports. Or do I miss something? >> >> --- snipped to the end --- >> This e-mail message is intended for the recipient only and contains info= rmation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. = If you have received this transmission in error, please inform us by e-mail= , phone or fax, and then delete the original and all copies thereof. >> From dmm@1-4-5.net Fri Jul 6 12:17:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A029521F85D6 for ; Fri, 6 Jul 2012 12:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTLWLAOv-hGs for ; Fri, 6 Jul 2012 12:17:47 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB34721F85D5 for ; Fri, 6 Jul 2012 12:17:47 -0700 (PDT) Received: by ggnc4 with SMTP id c4so9830486ggn.31 for ; Fri, 06 Jul 2012 12:18:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=fZ4BJxKwd5SGHPrD/TZmpo3z1M/TtWYVUSy3S/5d07A=; b=SX2U5HeTGT7xHTdczErYCAG8x4NQR204Cx0z261AvUpcm4Ga73AxgOJbybUQ7VBeSR j9WU+8b2k9/7iy1VrdSF4wF5SpwozPsTbEKQNCU2Ufvl8MmQfmCUTwD4cHcfJLGuqHcM VIUP5Lv+2vSgNcYUs9KZR08dRuWyOjiuDJGMXVud/d0xmiKQQ+Wnek14W6Hey+rQ5XpL aCByl4x80MBRMwVXUq1Zfpyq0bmUvPAojislJ1+chFwmEN/w7eraiUsCIs/Rk6SppBVW jtk6vrLzlIBLJdZpz9/yNJE5kKkiCse4WNgG5MMtB/4yfsJZ3aMWIINNZkOKtJXZ5gEk oU9w== MIME-Version: 1.0 Received: by 10.60.12.37 with SMTP id v5mr305657oeb.25.1341602284364; Fri, 06 Jul 2012 12:18:04 -0700 (PDT) Received: by 10.76.19.16 with HTTP; Fri, 6 Jul 2012 12:18:03 -0700 (PDT) X-Originating-IP: [24.21.216.213] In-Reply-To: References: Date: Fri, 6 Jul 2012 12:18:03 -0700 Message-ID: From: David Meyer To: "Andrew G. Malis" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQldaf6O9R+uWiDvsOnHUoR+C0pyM6K5GVUVbh3z9GXJVd1koIo4GXZfz9+P2IAnZAnT+DcR Cc: Vladimir Kleiner , Andrew Sergeev , Idan Kaspit , Mishael Wexler , Jan Medved , "pwe3@ietf.org" , Andrew McLachlan , Rotem Cohen Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review please X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 19:17:48 -0000 Thanks Andy, will definitely do that. --dmm On Fri, Jul 6, 2012 at 11:47 AM, Andrew G. Malis wrote: > Dave, > > One other comment that just occurred to me as you're working on your > update - the current revision of the draft obviously only works with > single-segment PWs, but that's not explicitly stated anywhere, other > than being alluded to in the title of figure 1. You may wish to make > that restriction explicit, unless you do intend to include MS-PWs in a > future revision, in which case that should be made clear as well. > > Cheers, > Andy > > On Fri, Jul 6, 2012 at 2:35 PM, David Meyer wrote: >> Excellent comments/clarifications Sasha. Thanks, really appreciate it >> and I'll work this into the next rev (working on that now). >> >> --dmm >> >> >> On Fri, Jul 6, 2012 at 11:29 AM, Alexander Vainshtein >> wrote: >>> David, >>> Please see a couple of comments inline below. Hopefully they clarify my= position. >>> >>> I have snipped some fragments of your response to make the remaining te= xt more readable. >>> >>> Regards, >>> Sasha >>> >>> ________________________________________ >>> From: David Meyer [dmm@1-4-5.net] >>> Sent: Friday, July 06, 2012 4:59 PM >>> To: Alexander Vainshtein >>> Cc: Andrew G. Malis; Jan Medved; Andrew McLachlan; pwe3@ietf.org; Misha= el Wexler; Rotem Cohen; Gideon Agmon; Andrew Sergeev; Idan Kaspit; Vladimir= Kleiner >>> Subject: Re: [PWE3] draft-medved-pwe3-of-config-00.txt posted, review p= lease >>> >>> Alexander, >>> >>> >>> On Tue, Jul 3, 2012 at 10:05 PM, Alexander Vainshtein >>> wrote: >>>> Andy and all, >>>> >>>> I've looked up the draft in question, and I have some comments/questio= ns in >>>> addition to Andy's: >>>> >>>> The PWE3 WG has defined multiple MIBs that can be used for PW setup an= d >>>> teardown by a management application (MPLS-TP or not). IMO the dr= aft >>>> should indicate that the method proposed there is an alternative not j= ust to >>>> PW signaling via T-LDP (as Andy has said) but also to static PW setup = using >>>> these MIBs. >>> >>> As I mentioned, the draft did not intended to provide an alternate >>> control plane; hopefully that will be clear in the next rev. I'll add >>> some text around the point you make WRT MIBs above. >>> >>> [[Sasha]] Well, MIBs are not part of control plane (at least, for me), = but of the Management Plane - and, to the best of my understanding, so is O= penFlow. But putting terminology aside, the PWE3 MIBs provide a certain abs= tract model of the PW endpoints that is integrated with the existing model = for MPLS etc. >>> Your draft seems to offer an alternative abstract model that seems to m= ix PW and MPLS functionality. >>> >>> --- snipped -- >>> >>>> The PWs run in in MPLS (or MPLS-TP) tunnels in order to improve scalab= ility of >>>> P routers, because the same tunnel between a given pair of PEs can be = shared >>>> by multiple PW instances. It is not clear from the text how such shari= ng can >>>> be accommodated in the proposed OF switch model. >>> >>> Humm, here is nothing that stops the "transport virtual port" from >>> sharing transport labels if that is appropriate. Perhaps I'm not >>> understanding your point? >>> >>> [[Sasha]] What is important is that multiple PWs sharing a common MPLS = tunnel LSP are fate-sharing in the PSN core, and the model should IMHO refl= ect this fact explicitly. E.g., the protection switch is applied to tunnel = LSPs, not to individual PWs. This affects both the management aspects (e.g.= , failures of individual PWs sharing a tunnel LSP should be suppressed when= the tuneel LSP fails) and the data plane (e.g., the time it takes to compl= ete a protection switch triggered by the tunnel LSP failure should not depe= nd upon the number of PWs using this tunnel LSP). IMHO and FWIW the model w= here each PW uses its individual "transport virtual ports" does not make th= is easy (if at all possible) even if you allow sharing of labels between th= ee ports. Or do I miss something? >>> >>> --- snipped to the end --- >>> This e-mail message is intended for the recipient only and contains inf= ormation which is CONFIDENTIAL and which may be proprietary to ECI Telecom.= If you have received this transmission in error, please inform us by e-mai= l, phone or fax, and then delete the original and all copies thereof. >>> From stbryant@cisco.com Tue Jul 10 00:56:37 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369B021F85CE for ; Tue, 10 Jul 2012 00:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.564 X-Spam-Level: X-Spam-Status: No, score=-110.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxPgPAD+Y5eh for ; Tue, 10 Jul 2012 00:56:36 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id AF51821F85C9 for ; Tue, 10 Jul 2012 00:56:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=183; q=dns/txt; s=iport; t=1341907024; x=1343116624; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=H01XbppiiyqRtEr4nipOAUXaNWu5iA68kaT181OWh5k=; b=GtGNwX6A0zjeQKDxqB5upHF2+mySv/bnIFogxLmz1S4b82TOcQJFZh6O FlxhayIY6Fyv2lg9J7eVaVGbTW9ZuYEE6tcu/IqtIlvCB6jixwW2hvedc PXWo+fmKpgfliDrqUuCqaQsGKDdIcpmVhALXEegHdF6kFvqbVTpiMjlmU o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroOAD3f+0+rRDoG/2dsb2JhbABFjVGofAQDgSiBB4IhAQEEEgECI0ARLBYPCQMCAQIBRQYNCAEBHodqAZw0g0gQnG2RYgOVNo4fgQRigmA X-IronPort-AV: E=Sophos;i="4.77,558,1336348800"; d="scan'208";a="51520556" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 10 Jul 2012 07:57:03 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6A7v1dw005224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2012 07:57:02 GMT Received: from dhcp-10-61-110-150.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q6A7uwra001314; Tue, 10 Jul 2012 08:56:59 +0100 (BST) Message-ID: <4FFBE04A.5010203@cisco.com> Date: Tue, 10 Jul 2012 08:56:58 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: pwe3 References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> In-Reply-To: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 07:56:37 -0000 Do the authors think that running transparent SONET emulation over IP is likely in practice, or is this included because SAToP included it? Stewart (Speaking as an individual) From Alexander.Vainshtein@ecitele.com Tue Jul 10 02:01:04 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D8E11E80A0 for ; Tue, 10 Jul 2012 02:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.301 X-Spam-Level: X-Spam-Status: No, score=-5.301 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmukuQtxVOuf for ; Tue, 10 Jul 2012 02:01:03 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id C438D11E808E for ; Tue, 10 Jul 2012 02:01:02 -0700 (PDT) Received: from [85.158.143.35:50951] by server-1.bemta-4.messagelabs.com id 0E/30-24392-86FEBFF4; Tue, 10 Jul 2012 09:01:28 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-7.tower-21.messagelabs.com!1341910883!12403022!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 31210 invoked from network); 10 Jul 2012 09:01:23 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-7.tower-21.messagelabs.com with SMTP; 10 Jul 2012 09:01:23 -0000 X-AuditID: a8571406-b7f546d000002eb1-f1-4ffbef638a60 Received: from FRGRWPVCH001.ecitele.com (Unknown_Domain [10.1.18.35]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id F7.28.11953.36FEBFF4; Tue, 10 Jul 2012 11:01:23 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Tue, 10 Jul 2012 11:01:22 +0200 From: Alexander Vainshtein To: "gmanhoudt@aimvalley.nl" , "stephan.roullot@alcatel-lucent.com" , "peter.roberts@alcatel-lucent.com" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGcQcIs6TA3k0aw083lr8KXcpciKb2Q Date: Tue, 10 Jul 2012 09:01:22 +0000 Message-ID: References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> In-Reply-To: <4FFBE04A.5010203@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupll+LIzCtJLcpLzFFi42LhYmSQ0k1+/9vfoOGYpMWTlc/ZLW5vespq 0fdpC4vFvketjBbnns5htNgy/R+LxYeuH6wO7B7b709j9Wh9tpfVY8rvjaweO2fdZfdYsuQn k8ektWkBbFENjDaJeXn5JYklqQopqcXJtkoBRZllicmVSgqZKbZKhkoKBTmJyam5qXkltkqJ BQWpeSlKdlwKGMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMkuJCOzWCFVNzcxM0chN7W4 ODE9VQEoAvJZXkrCOuaMtd1djAXdMhWHThxgamB8JNbFyMkhIWAisXHrQiYIW0ziwr31bF2M XBxCAqcYJa582cYM4SxhlNi/dg47SBWbgK3EptV3wapEBE4zSnS/XssC4jALzGeUuL58FQtI lbCAlcT9N8vBOkQErCWWd6xghLCNJOatgZjEIqAqMan5HpjNK+Ar8fzOZqA7OIDWJUjMWO4O EuYU0JRo7z/CCmIzAp33/dQasFOZBcQlbj2ZD3W2gMSSPeeZIWxRiZeP/7FC2HISTSuvsEPU 60gs2P2JDcLWlli28DUzxFpBiZMzn7BA1EtKHFxxg2UCo/gsJCtmIWmfhaR9FpL2BYwsqxgl 0ooyU3IKyoqTDAxM9VKTM0tSc1L1kvNzNzECE9WKcBG2HYwNE/QOMQpwMCrx8G5g+e0vxJpY VlyZe4hRkoNJSZTX4QVQiC8pP6UyI7E4I76oNCe1+BCjBAezkgivzgmgHG9KYmVValE+TMoC GIYTmaW4k/NBkVwSb2xggMJREuddH2TnLySQDkx52ampBalFMK0yHBxKEryL3wFNFSxKTU+t SMvMKUFIM3FwgmzmAdq8GaSGt7ggMbc4Mx0if4pRlWNZ29EbjEIsefl5qVLivCtBigRAijJK 8+DmvGIUB/pVmHcjSJYHmBLhJrwCGs4ENLy95xfIcGDOgEtJNTDWipdsLPURMWBknuSxsFVk RsSE9wuS3SXqm9dLzI3uWH46LF9YZe22CbNL3/AVVL35ncXOyZX8dQ5H/Q8p7560wPVzXYSP Ckfw9YYIsh/acMrGckPfxSn1jeIVs3bvcE385rHLQel9TRnr6kPhW1jEzqeVT+4X1tA6KXTs 7c7APSZ9IWlOR5VYijMSDbWYi4oTAc4NySIgBAAA Cc: "Yaakov Stein \(yaakov_s@rad.com\)" , pwe3 , "stbryant@cisco.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 09:01:04 -0000 Hi all, Several comments on the draft in question: 1. The draft seems to follow closely RFC 4553, including support of IPv4/IPv= 6 as the PSN, congestion handling etc. I echo Stewart's question regarding u= sage of IPv4/IPv6 PSN (with limited TE capabilities) for carrying such high-= rate CBR flows as STM-1/OC-3 and higher. 2. The draft correctly mentions RFC 4842 as an alternative (and approved by= the IETF) method for emulating SONET/SDH over PSN. However, it is worth not= ing that one of the reasons this method has been preferred to transparent pa= ssing of the entire SONET/SDDH bit stream (e.g., as proposed in one of the e= arly precursors of RFC 4553 - see http://www.watersprings.org/pub/id/draft-= vainshtein-cesopsn-01.txt, Annex B) to was elimination of the need to manipu= late the S1 byte in the SONET/SDH overhead. The lower nibble of this byte co= ntains encoded quality of the system clock of the SONET/SDH mux that has bee= n used to drive the outgoing SONET/SDH bit stream. Simply passing tits value= transparently thru the PSN does not make any sense (and, indeed, potentiall= y violates integrity of clock distribution). The IWF proposed in the draft c= annot access this byte because it is unaware of the SONET/SDH boundaries, an= d neither can this be done by the OSn_TT_So & OSn/RSn_A_So/ OSn_TT_Sk & OS= n/RSn_A_Sk functional blocks to which the IWF is connected. IMHO the draft= should explain in some detail how this issue is resolved. Alternatively, it= should state that the SONET/SDH bit stream that has passed thru the TSoP PW= MUST NOT be used as the clock source by the CE device. 3. The draft defines only LOS as the mandatory SONET/SDH AC fault to affect= setting of the L bit in the PW control word. However, if Loss of Frame defe= ct is encountered (dLOF), de-scrambling of the incoming SONET/SDH stream ca= nnot be completed, and the payload of the TSoP would become junk; hence IMO= LOF must be added as a mandatory trigger for asserting the SF condition in= Section 3.1. (And, while the reference to the ITU-T G.783 functional block= s implies that, it would be nice to explain that the incoming SONET/SDH bit= stream is segmented and encapsulated after de-scrambling - for the sake of= the readers that do not parse the ITU-T-ish easily:-) 4. The draft seems to imply that TSoP requires, as a pre-requisite, availabi= lity of common high-quality clock for the pair of PEs terminating a TSoP PW= by both mandating the use of the minimal RTP header in the encapsulation an= d not recommending usage of adaptive clock recovery for these PWs. However,= this important restriction is not reflected in the Applicability Statement= section of the draft. 5. The draft mentions the need not to exceed the path MTU between the pair o= f PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS PSN (wher= e it obviously applies). Hopefully these notes will be useful. Regards, Sasha > -----Original Message----- > From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf > Of Stewart Bryant > Sent: Tuesday, July 10, 2012 10:57 AM > To: pwe3 > Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP > > Do the authors think that running transparent > SONET emulation over IP is likely in practice, or is > this included because SAToP included it? > > Stewart > (Speaking as an individual) > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From lmartini@cisco.com Tue Jul 10 11:35:19 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFD621F8738 for ; Tue, 10 Jul 2012 11:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RYNzKl1yGVM for ; Tue, 10 Jul 2012 11:35:19 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) by ietfa.amsl.com (Postfix) with ESMTP id EEBD521F8767 for ; Tue, 10 Jul 2012 11:35:18 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id q6AHbKuc024515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 10 Jul 2012 11:37:20 -0600 (MDT) Message-ID: <4FFC75D9.5080604@cisco.com> Date: Tue, 10 Jul 2012 12:35:05 -0600 From: Luca Martini User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: pwe3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 18:35:19 -0000 WG, At the request of the chairs, I have posted the initial version of an update to rfc4447. This is the next step in the process defined by rfc6410 to progress this document to "Internet Standard". Quoting rfc6410: " A specification may be, and indeed, is likely to be, revised as it advances from Proposed Standard to Internet Standard. When a revised specification is proposed for advancement to Internet Standard, the IESG shall determine the scope and significance of the changes to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at Proposed Standard before progressing." According to the above guidelines, I have revised the rfc4447 document to incorporate all erratas , and a WG discussions about the PW encapsulation being symmetric in both direction of traffic. I also added a clarification about the LDP mode bit as per MPLS WG discussion. Let me know what else I might have missed. Here is a list of changes from my log: -------------------------------------------------------------------------------------------------------------------------------- - Updated all references - published v00 of bis rfc draft - Added clarification about PW always being symmetrical in both direction of traffic. - Changed Generalized ID FEC element, and Generalized PWid FEC element to >> Generalized PWid FEC element to be consistent with IANA allocation and within the document ( this was noted in errata, but IMHO incorrectly rejected ) - Errata ID: 1530 - accepted - Errata ID: 3112 - accepted - Errata ID: 3114 - accepted - Errata ID: 3115 - removed table - Errata ID: 86 - accepted - Errata ID: 938 - accepted - Added text to specify that downstream unsolicited bit does not apply to pw application according to draft-raza-mpls-ldp-applicability-label-adv-02.txt (WG document of MPLS WG) - made source identical , to rfc -------------------------------------------------------------------------------------------------------------------------------- Thanks. Luca From Internet-Drafts@ietf.org Tue Jul 10 16:13:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC14F11E815B; Tue, 10 Jul 2012 16:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.219 X-Spam-Level: X-Spam-Status: No, score=-102.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPiJgL0K4bu9; Tue, 10 Jul 2012 16:13:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55E7311E812B; Tue, 10 Jul 2012 16:13:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120710231350.3128.32535.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2012 16:13:50 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-rfc4447bis-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 23:13:51 -0000 --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 Setup and Maintenance using the Label Distribution Protocol Author(s) : L. Martini, et al Filename : draft-ietf-pwe3-rfc4447bis Pages : 33 Date : July 10, 2012 Layer 2 services (such as Frame Relay, Asynchronus Transfer Mode, and Ethernet) can be "emulated" over an MPLS backbone by encapsulating the Layer 2 Packet Data Units (PDU) and then transmitting them over "pseudowires". It is also possible to use pseudowires to provide low-rate Time Dividion Multiplexed and Synchronous Optical NETworking circuit emulation over a MPLS-enabled network. This document specifies a protocol for establishing and maintaining the pseudowires, using extensions to the Label Distribution Protocol (LDP). Procedures for encapsulating Layer 2 PDUs are specified in a set of companion documents. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-rfc4447bis-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pwe3-rfc4447bis"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-07-10161350.I-D@ietf.org> --NextPart-- From Alexander.Vainshtein@ecitele.com Tue Jul 10 22:21:28 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FAA221F85FD; Tue, 10 Jul 2012 22:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM5zHyaC-owI; Tue, 10 Jul 2012 22:21:26 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 17CF321F85FC; Tue, 10 Jul 2012 22:21:25 -0700 (PDT) Received: from [85.158.143.99:4792] by server-2.bemta-4.messagelabs.com id CA/E0-17938-27D0DFF4; Wed, 11 Jul 2012 05:21:54 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-216.messagelabs.com!1341984114!21146875!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 22558 invoked from network); 11 Jul 2012 05:21:54 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-6.tower-216.messagelabs.com with SMTP; 11 Jul 2012 05:21:54 -0000 X-AuditID: a8571401-b7ff06d000000c6d-2f-4ffd0eb8b8ea Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 98.D1.03181.8BE0DFF4; Wed, 11 Jul 2012 07:27:21 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 07:21:53 +0200 From: Alexander Vainshtein To: Luca Martini Thread-Topic: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes Thread-Index: AQHNXsrYgfdlUXxfr0mSCyPb8SZy+Zcjf45X Date: Wed, 11 Jul 2012 05:21:52 +0000 Message-ID: References: <4FFC75D9.5080604@cisco.com> In-Reply-To: <4FFC75D9.5080604@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTfUgTYRzu3d3mbe3kXNpeRx/jMLCPydSiRZv1R39kEOtLKqHs3L1tR9vt 3E1rgWFWREIfUoFZpoJmpmj5gYlSuYLI6AsKM0siDfugL0kqddJdV2Z0fz3v+zzP7/n97n5H YIYejYng+CAK8IyX1uhwHZhmsrRHR5zWukrcNvQ8EmV7Vl2rth0bbsFXYqtPjV1Rr66q+qFa p8osAHaG5/1BJojMLBJdDnpdgMtjXCHazLEOOpk2C17GhXyIDzpoRhAQz9JpOvN/j12ScbwZ 8S4/y/FuB52+0Wmx2ZYssyTTaZs8nGhGFh/Dec0+JIqMG5mlG7llnt3RgHkaC7s0QnnCno79 n/ECcHZ2EdASkFoMDx4fUSt4JnzY36gpAjrCQHUD2HJkNEo5VAHYdXp/lKzSUA7YVPdCI+NY ah5suDkGZIxRy+CN24W4jGdQy+HXM0UqRWOHvYfHf+MUOHq4WEojCFzyFkQS5WuSWgvvdtT/ shqoRPix/xAmYy01H94ouferPJCa+9Zdr1KijPDZYLlKaZqCVZ0PMAXHwbcDE7+HmQubWwfU in4RrOgY1ih4IbxQ+R5TcmPgnTODuKKPh10Xn+IngLF0SkTpFHvpFHvpFHsFwC8B484AxwqC mG21JichFxdEXpTk8vuagLQqFzfHgqvg1dGkMKAIQOvJley406Bm8sSQLwziCRUdR87RRZyG 6Gw/G/IwoicrkOtFYhhAAqNjSe05SU6yTGgvCvj/UDbpFRZjpukuv/yFg1mpVus/B9pINm5I cxoot7R2uxASUOCPdRZB0JBs1UuJMQHkRnt2ct7gX1pFaOVkvZRcJ2tIUWB8IudW+G4QbzKS 9TJByYQnl5/0vgNGab4Z5HWZ1UurN+l6JxVUSQUrquVRROlXmKRMBQDuyJhIHXGXhad1D/Ut ar/a/DrWviRHk3EytOXJWy6x8HwOGM38Ekdvtc99E0l0b0pNX3BkTWVCcXZNee+2Dy/7Fvb1 isPHtJb8+z3nch5frilryQtXX8NvrSrRLf2U8r1NvyJ9e+HHfCFlvKfz6PqUg7tH21aEOvcR JbXMowNPMsdoXPQwyQuwgMj8BGtH4OXqAwAA Cc: "mpls@ietf.org" , pwe3 Subject: Re: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 05:21:28 -0000 Luca (and all), I fully support the idea of progressing RFC 4447 to Internet Standard. Looking up the draft, I have found the following difference with the current= text: RFC 4447, Section 3: LDP MUST be used in its "downstream unsolicited" mode. which is quite unambiguous. draft-ietf-pwe3-rfc4447bis-00, Section 3, changes this to: LDP MUST exchange PW FEC label bindings in downstream unsolicited man= ner, independent of the negotiated label advertisement mode of the LDP session. I assume that this is the change you've had in mind when you said: ""Added text to specify that downstream unsolicited bit does not apply to PW= application..." even if the actual text states that it does apply. But, what is more serious, this seems to contradict the following statement= in RFC 5036, Section 2.6: However, for any given LDP session, each LSR must be aware of the labe= l distribution method used by its peer in order to avoid situations where one peer using Downstream Unsolici= ted label distribution assumes its peer is also. and further in Section 2.6.3: Each interface on an LSR is configured to operate in either Downstream Unsolicited or Downstream on Demand advertisement mode. LSRs exchange advertisement modes during initialization. I am not sure that the proposed change in 4447 complies with the quoted stat= ements in 5036. A reference (in the notes only, not in the draft) to draft-raza (which has n= ot yet been posted as a WG document) does not justify such a deviation IMHO.= It could also put 4447bis on hold if an explicit dependency is created. At= the very least we should hear what the MPLS WG has to say on that. And, speaking about references, I see that RFC 4448 is marked as "Work in Pr= ogress" in the draft. Is it just a typo, or do you imply that it is going to undergo a revision so= on? Hopefully these notes will be useful. Regards, Sasha ________________________________________ From: pwe3-bounces@ietf.org [pwe3-bounces@ietf.org] on behalf of Luca Martin= i [lmartini@cisco.com] Sent: Tuesday, July 10, 2012 8:35 PM To: pwe3 Subject: [PWE3] draft-ietf-pwe3-rfc4447bis-00.txt Notes WG, At the request of the chairs, I have posted the initial version of an update to rfc4447. This is the next step in the process defined by rfc6410 to progress this document to "Internet Standard". Quoting rfc6410: " A specification may be, and indeed, is likely to be, revised as it advances from Proposed Standard to Internet Standard. When a revised specification is proposed for advancement to Internet Standard, the IESG shall determine the scope and significance of the changes to the specification, and, if necessary and appropriate, modify the recommended action. Minor revisions and the removal of unused features are expected, but a significant revision may require that the specification accumulate more experience at Proposed Standard before progressing." According to the above guidelines, I have revised the rfc4447 document to incorporate all erratas , and a WG discussions about the PW encapsulation being symmetric in both direction of traffic. I also added a clarification about the LDP mode bit as per MPLS WG discussion. Let me know what else I might have missed. Here is a list of changes from my log: ----------------------------------------------------------------------------= ---------------------------------------------------- - Updated all references - published v00 of bis rfc draft - Added clarification about PW always being symmetrical in both direction of traffic. - Changed Generalized ID FEC element, and Generalized PWid FEC element to >> Generalized PWid FEC element to be consistent with IANA allocation and within the document ( this was noted in errata, but IMHO incorrectly rejected ) - Errata ID: 1530 - accepted - Errata ID: 3112 - accepted - Errata ID: 3114 - accepted - Errata ID: 3115 - removed table - Errata ID: 86 - accepted - Errata ID: 938 - accepted - Added text to specify that downstream unsolicited bit does not apply to pw application according to draft-raza-mpls-ldp-applicability-label-adv-02.txt (WG document of MPLS WG) - made source identical , to rfc ----------------------------------------------------------------------------= ---------------------------------------------------- Thanks. Luca _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From Alexander.Vainshtein@ecitele.com Wed Jul 11 03:51:15 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCAD21F8656; Wed, 11 Jul 2012 03:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.288 X-Spam-Level: X-Spam-Status: No, score=-5.288 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8CpJCTufP4B; Wed, 11 Jul 2012 03:51:13 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.130]) by ietfa.amsl.com (Postfix) with ESMTP id 803B821F8643; Wed, 11 Jul 2012 03:51:10 -0700 (PDT) Received: from [85.158.139.83:58404] by server-2.bemta-5.messagelabs.com id F7/68-04598-ABA5DFF4; Wed, 11 Jul 2012 10:51:38 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-16.tower-182.messagelabs.com!1342003881!20050821!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 26065 invoked from network); 11 Jul 2012 10:51:21 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-16.tower-182.messagelabs.com with SMTP; 11 Jul 2012 10:51:21 -0000 X-AuditID: a8571402-b7f116d0000051b6-e1-4ffd564bda7e Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 37.75.20918.B465DFF4; Wed, 11 Jul 2012 12:32:43 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 12:51:20 +0200 From: Alexander Vainshtein To: "david.i.allan@ericsson.com" , "swallow@cisco.com" , "jdrake@juniper.net" Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7Wg== Date: Wed, 11 Jul 2012 10:51:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A20BFRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALsWRmVeSWpSXmKPExsXCxcggpesd9tff4GanrMWndztYLB6e385s Meeus8WtpStZLfo+bWGxuD2lidFiw5pHjA7sHlN+b2T1+PX1KpvHkiU/mTyuN11lD2CJamC0 SczLyy9JLElVSEktTrZVCijKLEtMrlRSyEyxVTJUUijISUxOzU3NK7FVSiwoSM1LUbLjUsAA NkBlmXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZKdiEZmcUKqbq5iZk5CrmpxcWJ6akKQBGQf/JS EtYxZ5xuuMlacNagYumJ5AbG5VpdjJwcEgImEhu/H2WHsMUkLtxbz9bFyMUhJHCKUWLSmU5G CGcJo8TuyQ8ZQarYBGwlNq2+C1YlIjCVUWLTma/sIA6zwBomiaObrrKCVAkLmEnsfvwRzBYR sJZY9PUjM4StJ7FzQjfYJBYBVYkJb5+wgdi8Ar4Svx99ALuDEeiO76fWMIHYzALiEreezGeC uE9AYsme88wQtqjEy8f/WCFsOYmmlVfYIerzJV7d62OGmCkocXLmExaIGkmJgytusExgFJmF ZOwsJC2zkLRAxHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYwSbkGeLj4BAcFOBgZGeq7O niGuPq56zv6+mxiBSWlFuAjTDsbmm4aHGAU4GJV4eCfE//EXYk0sK67MPcQoycGkJMo72/+v vxBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3hofoBxvSmJlVWpRPkzKFRiIE5mluJPzQZFcEm9s YICboyTOGxdk5y8kkA5MhtmpqQWpRTBzZDg4lCR490cCrRAsSk1PrUjLzClBSDNxcIKcwQN0 xluQGt7igsTc4sx0iPwpRlWOCx+P3GAUYsnLz0uVEud9DlIkAFKUUZoHN+cVozjQ48K870Cy PMBkCTfhFdBwJqDhC5b+ARkOzCZwKakGxvojpRf6EnsWVhgIdNd1XNrXuNKK7WUQv+DWOVMC 2nP9uk8GPhFg5tCVqxBrlfHfXNrFamYbu69nAttHpikZhTFFbk3hQREK75Y67z6iJlQx61NL c9mySqNNzv7PwqbEFVnubmVQsOL232x8moO9Yd7hn4ZfpW6c4/3cbnbORNKn7/SMDhUlluKM REMt5qLiRADEbMp4IwQAAA== Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , "tnadeau@juniper.net" , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 10:51:15 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A20BFRIDWPPMB001ecite_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized "may" and not one of the IETF reserved requirement lev= el words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A20BFRIDWPPMB001ecite_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized “may” and not one of the IETF reserved requirement= level words.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A20BFRIDWPPMB001ecite_-- From agmalis@gmail.com Wed Jul 11 05:02:50 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17F3521F865A for ; Wed, 11 Jul 2012 05:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KuNawYe+1-A for ; Wed, 11 Jul 2012 05:02:49 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5200D21F8646 for ; Wed, 11 Jul 2012 05:02:49 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1176424ggn.31 for ; Wed, 11 Jul 2012 05:03:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=1Copx8UabdD3lcCHuNeVyHrbkFH7rWs0lXbAXmWB/k4=; b=UPtq3X39SYgOdHoJGuyl4plmnl5pAp/1sMJapur7I/dDYu87yGAK5PcMDFv4gNcCK7 bIoS9TrRujIkxssogOBwGhQLeUvFgNTERl/nFJUJXqBJA5dKbpCKcaV6J26Ol42taa04 blCS7wXkYL3iLOeR7rFm9vLN13KB5eBNNJ7y1FsF/50eN+Lgf5SUEeHIR7jXTYML4kQd M/GpC0qSu2ZeYOdccZkpkq7IJddICw+kr+v5V9qtVZhijG7CmHo1x3zNygQZb20zvl4I hdb4nbOTZ1NDrS7Jr9abX/DmbzlEffhhYQbhwsf3JRSOb+Pjtp/JXBx3CKN2UZA37/7I dhFA== Received: by 10.50.89.169 with SMTP id bp9mr14287785igb.59.1342008198963; Wed, 11 Jul 2012 05:03:18 -0700 (PDT) MIME-Version: 1.0 Sender: agmalis@gmail.com Received: by 10.64.77.78 with HTTP; Wed, 11 Jul 2012 05:02:58 -0700 (PDT) In-Reply-To: <4FFC2297.90108@pi.nu> References: <01da01cd5e96$70cab2d0$52601870$@olddog.co.uk> <4FFC2297.90108@pi.nu> From: "Andrew G. Malis" Date: Wed, 11 Jul 2012 08:02:58 -0400 X-Google-Sender-Auth: EvIFw-aCZNmx10rVcy9Wr7YSIBM Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PWE3] Fwd: [mpls] Feedback request: draft on IP/MPLS transmission interruption X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:02:50 -0000 pwe3 WG, This is a draft that is of interest to the pwe3 WG in addition to the mpls WG. On a first reading, the draft doesn't seem to be taking the requirements of PW applications into account. As Loa and Adrian say below, comments should be on the opsarea list. Cheers, Andy ---------- Forwarded message ---------- From: Loa Andersson Date: Tue, Jul 10, 2012 at 8:39 AM Subject: Re: [mpls] Feedback request: draft on IP/MPLS transmission interruption To: adrian@olddog.co.uk Cc: ietf@cdl.asgaard.org, mpls@ietf.org, lilianyuan@chinamobile.com, Fan Peng Working Group, Adrian was quicker than I was on this, just want echo his sentiment. I think that by default the comments should go to the opsawg mailing list - but if you for some reason is not subscribed to that list, send them to the mpls wg list or directly to me and I will forward. /Loa On 2012-07-10 14:20, Adrian Farrel wrote: > > I think the MPLS WG should look at this I-D as well. > > Feedback to the authors or on the OPSAWG list, please. > > Adrian > > *From:*opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] *On > Behalf Of *Fan Peng > *Sent:* 10 July 2012 05:52 > *To:* opsawg@ietf.org > *Cc:* ietf@cdl.asgaard.org; lilianyuan@chinamobile.com > *Subject:* [OPSAWG] Feedback request: draft on IP/MPLS transmission > > interruption > > Dear all, > > We have just updated the draft on IP/MPLS transmission interruption to > 01 version, and we would like to hear comments from you. > > http://tools.ietf.org/html/draft-fan-opsawg-transmission-interruption-01 > > We presented the last version in Paris hoping the industry could discuss > the problem of whether the sub-50ms outage time requirement is suitable > for IP/MPLS. We proposed at the meeting two principles for network and > service design, configuration and operation: the IP/MPLS bearer should > satisfy quality requirements of upper level services and applications, > while services and applications should also take into account the > intrinsic IP capabilities. We did analysis on softswitch and reached the > IP interruption requirement of 3 sec. > > In this 01 version we added case of parameter configuration in SS7 > network to illustrate principle 2 (adaptation to IP). We gave examples > on SCTP and M2PA and delivered the concept that upper levels should be > more tolerable to IP best effort to avoid frequent disconnection. > Parameter configuration needs to consider both requirement of > application and nature of IP. Influence on service like SMS is also > involved. > > Any feedback would be highly appreciated. > > Thanks and regards, > > Fan, Peng > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Wed Jul 11 05:09:17 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F039D21F85D2 for ; Wed, 11 Jul 2012 05:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_00=-2.599, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq3nJpEZZJR1 for ; Wed, 11 Jul 2012 05:09:16 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED7F21F856C for ; Wed, 11 Jul 2012 05:09:12 -0700 (PDT) Received: by yhfs35 with SMTP id s35so1659361yhf.27 for ; Wed, 11 Jul 2012 05:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=tw/xiqd76MCGtT1QnePXhKDGERVy0/+aI4a+l5hq7Qw=; b=qMuIdakABF9PzTmzORdHos75V2ZzBvyhmeNGSW2kPpjpvDAE28Ej0lJu3AJGTRQl8V bR1GfxaM04P1axpNWfnw2R17oXw5Au+R0A3Lm85FvYv2TO4XTFnjpzT52LlrLA4Q8epj bvCygtxXcQBoT65YVfOavNuzItFIIaRAMm0Qj25lIhAXHeN03MO8ceL1kKTn9K98jC2e B77zOACLkRZopaPbxOIEgc7AUZgG8jIZBy9qXmihfxX35dLUW0byumvktkKU84f0bIbk 2kJ//xok6CQVmU2KnBDs4a1aMHZH6L6hPngU8ewPqy8VYizh3SbBo3sSR6VZl3uI6Qy+ DXqw== Received: by 10.50.187.233 with SMTP id fv9mr14306838igc.59.1342008582212; Wed, 11 Jul 2012 05:09:42 -0700 (PDT) MIME-Version: 1.0 Sender: agmalis@gmail.com Received: by 10.64.77.78 with HTTP; Wed, 11 Jul 2012 05:09:22 -0700 (PDT) In-Reply-To: References: <01da01cd5e96$70cab2d0$52601870$@olddog.co.uk> <4FFC2297.90108@pi.nu> From: "Andrew G. Malis" Date: Wed, 11 Jul 2012 08:09:22 -0400 X-Google-Sender-Auth: m-ohuI60rbUjql4XtYKHycL31P4 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [PWE3] [mpls] Feedback request: draft on IP/MPLS transmission interruption X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 12:09:17 -0000 Correction: discussion should be on the OPSAWG list. Thanks, Andy On Wed, Jul 11, 2012 at 8:02 AM, Andrew G. Malis wrote: > pwe3 WG, > > This is a draft that is of interest to the pwe3 WG in addition to the > mpls WG. On a first reading, the draft doesn't seem to be taking the > requirements of PW applications into account. As Loa and Adrian say > below, comments should be on the opsarea list. > > Cheers, > Andy > > ---------- Forwarded message ---------- > From: Loa Andersson > Date: Tue, Jul 10, 2012 at 8:39 AM > Subject: Re: [mpls] Feedback request: draft on IP/MPLS transmission interruption > To: adrian@olddog.co.uk > Cc: ietf@cdl.asgaard.org, mpls@ietf.org, lilianyuan@chinamobile.com, > Fan Peng > > > Working Group, > > Adrian was quicker than I was on this, just want echo his sentiment. > I think that by default the comments should go to the opsawg mailing > list - but if you for some reason is not subscribed to that list, send > them to the mpls wg list or directly to me and I will forward. > > /Loa > > > On 2012-07-10 14:20, Adrian Farrel wrote: >> >> I think the MPLS WG should look at this I-D as well. >> >> Feedback to the authors or on the OPSAWG list, please. >> >> Adrian >> >> *From:*opsawg-bounces@ietf.org [mailto:opsawg-bounces@ietf.org] *On >> Behalf Of *Fan Peng >> *Sent:* 10 July 2012 05:52 >> *To:* opsawg@ietf.org >> *Cc:* ietf@cdl.asgaard.org; lilianyuan@chinamobile.com >> *Subject:* [OPSAWG] Feedback request: draft on IP/MPLS transmission >> >> interruption >> >> Dear all, >> >> We have just updated the draft on IP/MPLS transmission interruption to >> 01 version, and we would like to hear comments from you. >> >> http://tools.ietf.org/html/draft-fan-opsawg-transmission-interruption-01 >> >> We presented the last version in Paris hoping the industry could discuss >> the problem of whether the sub-50ms outage time requirement is suitable >> for IP/MPLS. We proposed at the meeting two principles for network and >> service design, configuration and operation: the IP/MPLS bearer should >> satisfy quality requirements of upper level services and applications, >> while services and applications should also take into account the >> intrinsic IP capabilities. We did analysis on softswitch and reached the >> IP interruption requirement of 3 sec. >> >> In this 01 version we added case of parameter configuration in SS7 >> network to illustrate principle 2 (adaptation to IP). We gave examples >> on SCTP and M2PA and delivered the concept that upper levels should be >> more tolerable to IP best effort to avoid frequent disconnection. >> Parameter configuration needs to consider both requirement of >> application and nature of IP. Influence on service like SMS is also >> involved. >> >> Any feedback would be highly appreciated. >> >> Thanks and regards, >> >> Fan, Peng >> >> >> >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> > > -- > > > Loa Andersson email: loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92 13 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From yshen@juniper.net Wed Jul 11 08:11:16 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874B921F8738 for ; Wed, 11 Jul 2012 08:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egEvAyeun8Yl for ; Wed, 11 Jul 2012 08:11:16 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 91C4621F8734 for ; Wed, 11 Jul 2012 08:11:15 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKT/2XsLGQuVS0GqRh/qfKtt6Cwt6vRSVx@postini.com; Wed, 11 Jul 2012 08:11:46 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jul 2012 08:11:12 -0700 Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 11 Jul 2012 08:11:12 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 11 Jul 2012 11:11:11 -0400 From: Yimin Shen To: "pwe3@ietf.org" Date: Wed, 11 Jul 2012 11:11:11 -0400 Thread-Topic: New revision of "PW Endpoint Fast Failure Protection" draft Thread-Index: Ac1fd2e7galKRt5VTbSzlJcRpLqj/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] New revision of "PW Endpoint Fast Failure Protection" draft X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:11:16 -0000 Hi, We have recently updated the "PW Endpoint Fast Failure Protection" draft be= low based on the comments that we received during IETF 83 in Paris. Once ag= ain, thanks for all those constructive comments. =20 http://tools.ietf.org/html/draft-shen-pwe3-endpoint-fast-protection-02 The major changes in this revision include: [1] Assumption of generic PSN transport layer. This makes the mechanism app= licable to PWs that are transported by RSVP-TE tunnels, LDP tunnels, or IP-= based tunnels.=20 [2] Clarification of the relationship between local repair (proposed by the= draft), global repair, and control protocol convergence. While emphasizing= the advantage of local repair from the perspective of traffic restoration = time, the draft also describes the importance of working in conjunction wit= h global repair and control protocol convergence after a failure, to move t= raffic permanently to a fully functional PW. [3] The description of "context identifier" has been re-written for an easi= er understanding of how it facilitates primary/bypass tunnel establishment = and context-specific label switching. Therefore, we'd like to hear your further comments and suggestions on this = draft. Regards, -Yimin Shen Juniper Networks From gregory.mirsky@ericsson.com Wed Jul 11 08:36:54 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D98021F86B3; Wed, 11 Jul 2012 08:36:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIkfgqvAEv61; Wed, 11 Jul 2012 08:36:53 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id CD8F421F86A1; Wed, 11 Jul 2012 08:36:52 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6BFb6Z7019664 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jul 2012 10:37:20 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 11 Jul 2012 11:37:07 -0400 From: Gregory Mirsky To: Alexander Vainshtein , David Allan I , "swallow@cisco.com" , "jdrake@juniper.net" Date: Wed, 11 Jul 2012 11:37:05 -0400 Thread-Topic: [mpls] Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAJsURg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D71927CCEUSAACMS0715e_" MIME-Version: 1.0 Cc: Mishael Wexler , "mpls@ietf.org" , Rotem Cohen , "pwe3 \(pwe3@ietf.org\)" , "tnadeau@juniper.net" Subject: Re: [PWE3] [mpls] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 15:36:54 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D71927CCEUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sasha, et al., I think that one of differences between CC defined in RFC 5885 and RFC 6428= in introduction of independent mode to monitor associated bi-directional p= 2p connections. Then there's FSMs fo coordinated and independent modes, Fig= .7 and Fig.8 in RFC 6428, that are different from FSM of RFC 5880. Then, IM= HO, using G-ACh from RFC 6428 indicates possible use of RFC 6428-based CV w= hile there's no CV for neither Control Channel 0x07. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org= ); Rotem Cohen Subject: [mpls] Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_FE60A4E52763E84B935532D7D9294FF137D71927CCEUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Dear Sasha, et al.,
= I think that one of differences b= etween CC=20 defined in RFC 5885 and RFC 6428 in introduction of independent mode to mon= itor=20 associated bi-directional p2p connections. Then there's FSMs fo coordinated= and=20 independent modes, Fig.7 and Fig.8 in RFC 6428, that are different from FSM= of=20 RFC 5880. Then, IMHO, using G-ACh from RFC 6428 indicates possible use of R= FC=20 6428-based CV while there's no CV for neither Control Channel=20 0x07.
 
   =20 Regards,
       =20 Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: D= avid=20 Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org;= =20 Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org); Rotem=20 Cohen
Subject: [mpls] Doubts in allocation of a new G-ACH type=20 for

Hi all,

I have doubts regarding allocation of the G-ACH type f= or the=20 MPLS-TP CC message in RFC=20 6428.

 

Looking at both this RFC and RFC 5885, it seems that the= format=20 of the MPLS-TP CC packet and the format of the raw BFD packet in VCCV is ex= actly=20 the same. However, two different G-ACH types have been allocated by IANA fo= r=20 these two cases.

 

IMHO and FWIW such duplication can only create=20 interoperability problems, especially with progress of the new VCCV Type (u= sing=20 GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capab= ility=20 to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the=20 confusion IMO, since it uses un-capitalized “may” and not one o= f the IETF=20 reserved requirement level words.

 

Clarification of intentions by the editors of RFC 6428= =20 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_FE60A4E52763E84B935532D7D9294FF137D71927CCEUSAACMS0715e_-- From david.i.allan@ericsson.com Wed Jul 11 09:07:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7B611E8114; Wed, 11 Jul 2012 09:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeKIq5bJ8lY7; Wed, 11 Jul 2012 09:07:05 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7577211E8085; Wed, 11 Jul 2012 09:07:05 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6BG7V9H016944; Wed, 11 Jul 2012 11:07:34 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.11]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 11 Jul 2012 12:07:27 -0400 From: David Allan I To: Alexander Vainshtein , "swallow@cisco.com" , "jdrake@juniper.net" Date: Wed, 11 Jul 2012 12:07:26 -0400 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAK655Q Message-ID: <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_" MIME-Version: 1.0 Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , "tnadeau@juniper.net" , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:07:07 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha: The reason for this is the overall system behavior implied. A 5885 code poi= nt is purely CC operation. A 6428 code point indicates that CV will be inte= rleaved with the stream. We wanted to explicitly disambiguate this. It further permits misbranching of a 5885 stream into a 6428 path to be det= ected so the overall network is more robust. If the CC messages in both 588= 5 and 6428 had a common code point, this would not be possible, and CV oper= ation would not be authoritative. I hope this helps Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sasha:
 
The=20 reason for this is the overall system behavior implied. A 5885 code point i= s=20 purely CC operation. A 6428 code point indicates that CV will be interleave= d=20 with the stream. We wanted to explicitly disambiguate=20 this.
 
It=20 further permits misbranching of a 5885 stream into a 6428 path to be detect= ed so=20 the overall network is more robust. If the CC messages in both 5885 and 642= 8 had=20 a common code point, this would not be possible, and CV operation would not= be=20 authoritative.
 
I hope=20 this helps
Dave

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July = 11,=20 2012 3:51 AM
To: David Allan I; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: Doubts in allocation of a new G-ACH type for=20

Hi all,

I have doubts regarding allocation of the G-ACH type f= or the=20 MPLS-TP CC message in RFC=20 6428.

 

Looking at both this RFC and RFC 5885, it seems that the= format=20 of the MPLS-TP CC packet and the format of the raw BFD packet in VCCV is ex= actly=20 the same. However, two different G-ACH types have been allocated by IANA fo= r=20 these two cases.

 

IMHO and FWIW such duplication can only create=20 interoperability problems, especially with progress of the new VCCV Type (u= sing=20 GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capab= ility=20 to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the=20 confusion IMO, since it uses un-capitalized “may” and not one o= f the IETF=20 reserved requirement level words.

 

Clarification of intentions by the editors of RFC 6428= =20 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_60C093A41B5E45409A19D42CF7786DFD53BC0658B4EUSAACMS0703e_-- From jdrake@juniper.net Wed Jul 11 09:24:28 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FED811E80CF; Wed, 11 Jul 2012 09:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.704, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AN+6yEGGqXG; Wed, 11 Jul 2012 09:24:26 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id CE94E11E8088; Wed, 11 Jul 2012 09:24:22 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT/2ozLNprYLieEJCY9aLiq3v78vpS5I7@postini.com; Wed, 11 Jul 2012 09:24:54 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Wed, 11 Jul 2012 09:24:03 -0700 From: John E Drake To: Alexander Vainshtein , "david.i.allan@ericsson.com" , "swallow@cisco.com" Date: Wed, 11 Jul 2012 09:24:01 -0700 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgALh55Q Message-ID: <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A5A82A4B7AEMBX01HQjnprn_" MIME-Version: 1.0 Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , Thomas Nadeau , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:24:28 -0000 --_000_5E893DB832F57341992548CDBB333163A5A82A4B7AEMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, The BFD packet format is the same for both CC and CV. The reason for havi= ng two code points is to indicate to the receiver whether there is a traili= ng source ID TLV, in which case the packet is to be used for CV rather than= CC. Thanks, John Sent from my iPhone From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: david.i.allan@ericsson.com; swallow@cisco.com; John E Drake Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf.org);= Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_5E893DB832F57341992548CDBB333163A5A82A4B7AEMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha,

 

The BFD packet format is the same for both CC and CV= .  The  reason for having two code points is to indicate to the r= eceiver whether there is a trailing source ID TLV, in which case the packet= is to be used for CV rather than CC.

 

Thanks,

 

John

<= p class=3DMsoNormal> <= /p>

Sent from my iPh= one

 

Fro= m: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 3:51 AM
To: david.i.allan@eri= csson.com; swallow@cisco.com; John E Drake
Cc: cpignata@cisco.com= ; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew S= ergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-A= CH type for

&nb= sp;

Hi all,

I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC m= essage in RFC 6428.=

 

Lo= oking at both this RFC and R= FC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two differen= t G-ACH types have been allocated by IANA for these two cases.

 

IMHO and F= WIW such duplication can only create interoperability problems, especially = with progress of the new VCCV Type (using GAL) for PWs. The text in Section= 3.1 of 6428 that refers to existing capability to run BFD over LSP with th= e G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses = un-capitalized “may” and not one of the IETF reserved requireme= nt level words.

 

Clarification of intentions by the editors of RFC 6428 (a= nd/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the r= ecipient only and contains information which is CONFIDENTIAL and which may = be proprietary to ECI Telecom. If you have received this transmission in er= ror, please inform us by e-mail, phone or fax, and then delete the original= and all copies thereof.

= --_000_5E893DB832F57341992548CDBB333163A5A82A4B7AEMBX01HQjnprn_-- From yaakov_s@rad.com Wed Jul 11 09:55:23 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C73411E810C for ; Wed, 11 Jul 2012 09:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHSP7GxfxBLw for ; Wed, 11 Jul 2012 09:55:18 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8D85911E8106 for ; Wed, 11 Jul 2012 09:55:15 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 11 Jul 2012 19:21:09 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 19:55:42 +0300 From: Yaakov Stein To: Alexander Vainshtein , "gmanhoudt@aimvalley.nl" , "stephan.roullot@alcatel-lucent.com" , "peter.roberts@alcatel-lucent.com" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGiS690goHnm0iu3kV86wpwkZciBfkAgAI6eNA= Date: Wed, 11 Jul 2012 16:55:42 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044E3B7C@EXRAD5.ad.rad.co.il> References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.141.36] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9044E3B7CEXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090204.4FFDB00F.0076,ss=1,fgs=0 Cc: pwe3 , "stbryant@cisco.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 16:55:23 -0000 --_000_07F7D7DED63154409F13298786A2ADC9044E3B7CEXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors of draft-manhoudt-pwe3-tsop and the rest of PWE3, This approach was considered a long time ago, but was not accepted due to a major architectural flaws. First, as Sasha said, it does not find the S1 byte and thus lies about the SSM message. This is not acceptable behavior. In terms that non-TDM people would understand, this would be similar to discovering an incorrect header checksum. but then recalculating it to cover up the loss. Second, this function is at least a section (in SDH terminology a regenerat= or section) termination (since it does not divide up STM-Ns, it is not a line termination). Section terminations MUST terminate and regenerate the section overhead (A1, A2, J0, B1, etc.) and optionally SHOULD enable insertion and dropping = of E1, F1, and D1/2/3 Data Communcations Channels. Once again, by transparently passing these bytes rather than regenerating t= hem, the emulation "lies" about their values. Finally, as Sasha already stated, the scrambling mechanism recovery after a single packet loss is problematic. This in itself pretty much kills the service usefulness if there is any pac= ket loss. In addition the clocking is not sufficiently described. I understand that RTP usage is mandated, and for some reason that 25 MHz is the nominal frequency. However, it is not clear what that 25 MHz is locked to. Is this always "common clock" (differential mode) ? Also, why is G.709 AIS generated instead of SDH MS-AIS or MSF-AIS ? I have a funny feeling that someone is trying to trick the SDH end devices NOT to recognize the fault condition. G.826 specifies that detecting AIS causes the declaration of a severely err= ored second (SES) and that there can be no more than 1/5 of a percent of SESes, i.e., about 1 AIS event in 500 seconds. At the default payload size of 810 Bytes, a single STM-1 takes 3 packets, so that there are 24,000 packets per second, so we are talking about an packet loss ratio of 1 in 500*24,000 =3D 12 mill= ion, i.e., about 8E-8. Nits: As with all PWs, TSoP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. well, it will require extensions to 4447. The key difference between the CEP approach and the TSoP approach is that within CEP an incoming STM-N is terminated and demultiplexed to its constituent VCs (Virtual Containers). I don't agree. While transport of VTs/VCs is allowed, an STM-1 can be transported directly using CEP without demuxing. However, the framing is discovered and the CW structure pointer points to t= he beginning of the SPE. This is the correct behavior for a regenerator. Why is G.709 an informative reference, if one needs to generate its AIS pat= tern ? Y(J)S --_000_07F7D7DED63154409F13298786A2ADC9044E3B7CEXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors of draft-manhoudt-pwe3-tsop and the rest of PWE3,

 

This approach was considered a long time ago,

but was not accepted due to a major architectural flaws.

 

First, as Sasha said, it does not find the S1 byte

and thus lies about the SSM message.

This is not acceptable behavior.

In terms that non-TDM people would understand,

this would be similar to discovering an incorrect header che= cksum.

but then recalculating it to cover up the loss.

 

Second, this function is at least a section (in SDH terminol= ogy a regenerator section) termination

(since it does not divide up STM-Ns, it is not a line termin= ation).

Section terminations MUST terminate and regenerate the secti= on overhead

(A1, A2, J0, B1, etc.) and optionally SHOULD enable insertio= n and dropping of

E1, F1, and D1/2/3 Data Communcations Channels.

Once again, by transparently passing these bytes rather than= regenerating them,

the emulation "lies" about their values.

 

Finally, as Sasha already stated, the scrambling mechanism

recovery after a single packet loss is problematic.

This in itself pretty much kills the service usefulness if t= here is any packet loss.

 

In addition the clocking is not sufficiently described.=

I understand that RTP usage is mandated,

and for some reason that 25 MHz is the nominal frequency.

However, it is not clear what that 25 MHz is locked to.=

Is this always "common clock" (differential mode) = ?

 

Also, why is G.709 AIS generated instead of SDH MS-AIS or MS= F-AIS ?

I have a funny feeling that someone is trying to trick the S= DH end devices

NOT to recognize the fault condition.

G.826 specifies that detecting AIS causes the declaration of= a severely errored second (SES)

and that there can be no more than 1/5 of a percent of SESes= ,

i.e., about 1 AIS event in 500 seconds.

At the default payload size of 810 Bytes, a single STM-1 tak= es 3 packets,

so that there are 24,000 packets per second,

so we are talking about an packet loss ratio of 1 in 500*24,= 000 =3D 12 million,

i.e., about 8E-8.

 

Nits:  

   As with all PWs, TSoP PWs may be manually configured =
or set up using
   the PWE3 control protocol [RFC4447].

well, it will require extensions to 4447.<= /p>

 

   The key difference between the CEP approach and the T=
SoP
   approach is that within CEP an incoming STM-N is term=
inated and
   demultiplexed to its constituent VCs (Virtual Contain=
ers).

I don't agree. While transport of VTs/VCs is allowed,

an STM-1 can be transported directly using CEP without demux= ing.

However, the framing is discovered and the CW structure poin= ter points to the beginning of the SPE.

This is the correct behavior for a regenerator.

 

Why is G.709 an informative reference, if one needs to gener= ate its AIS pattern ?

 

Y(J)S

 

 

--_000_07F7D7DED63154409F13298786A2ADC9044E3B7CEXRAD5adradcoil_-- From Alexander.Vainshtein@ecitele.com Wed Jul 11 10:12:33 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5F711E8101; Wed, 11 Jul 2012 10:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKPuY2ZvtNtI; Wed, 11 Jul 2012 10:12:32 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 80BAE11E80EF; Wed, 11 Jul 2012 10:12:28 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-13.tower-27.messagelabs.com!1342026774!8703161!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 22010 invoked from network); 11 Jul 2012 17:12:55 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-13.tower-27.messagelabs.com with SMTP; 11 Jul 2012 17:12:55 -0000 X-AuditID: a8571406-b7f546d000002eb1-d6-4ffdb416c99f Received: from FRGRWPVCH001.ecitele.com (Unknown_Domain [10.1.18.35]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 10.C8.11953.614BDFF4; Wed, 11 Jul 2012 19:12:54 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 19:12:54 +0200 From: Alexander Vainshtein To: John E Drake , "david.i.allan@ericsson.com" , "swallow@cisco.com" Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgALh55QAAEniWc= Date: Wed, 11 Jul 2012 17:12:53 +0000 Message-ID: References: , <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A37AFRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0wTWRT2dqbt0O3oWIFeG6PNGHGzpmxRSWbREo2P4Kqp8bnZxODQXttZ 22nTKSiamFo0xgemxlckG6umEFSkIirEVxTNgihCguyyGo1a3ERECcRHVkW901EkMc6PyXfO 953znblzLkUYarUmShCDKCDyHlajI3VgmMmSfmbAbo2VTOX6X9ST3KPWOoL78/4s7m75MTW3 q/8Myd3bGwbcqarHYIY2b++7GnXe21cdmrxY7H9V3j/hDu0i8vcQmM6Loi/IB5HZiSSHjV0U EIp4RzFrFpw2Nos1+z28A3mRGLSxvN+PRCebqzN/80zHMkE0I9Hhcwqiy8bOW2K3cFz2L5Ys NnepW5DMyOLlBY/ZiySJdyEzzsjfIzpXVRPu2nip2n9pwbr927aqQqB9xnaQQkFmKnxd1apS cDpsexDXbAc6ysA0A/h+cy+hBDEAy6/9TcoqDWODp0/cT6pSmR0AVjTc0soBwcRUsHRTv0ZW jWJy4IEtz5M4lZkGj77qIxScAxPxzqQfyUyAHYcak5hmFsKe6DmtjA1MKYAX/8uQcQqzAFae eAtkDPB8b5qrknqCMcK7XdHPczMwdrGVUHAafJr4oFbwOFh7NoExhfU+GG78TbEaCW8c7CIV yWh4tbKTjID0siFdy75WlA2pUCRW2Hs7Sih4Eqw48uwz/hnWvGwBQ/OHgfY4gKsDgtPjL5IK rNbsTOQQgsiDMh0+72mAN6xyRaqmHoQimQ2AoQCrp+urB+wGNV8kFXsbwGhKxabRe2pwaniB z1ns5iV3fqDQg6QGACmCTaXXRjBHO/ni9Sjg+0LNwUe7mzD94PDJ/z6YP8Vq/X7AGun44ly7 gXHh7VyDkB8FvvQZQ1EspOtqscXIAHKhdasFT/ArraJS5DH0eIx9soaW/LxXElwK3wyyqOqe 652AauuT3+frmjqBgRR9IjIZ6VVyASMXuAvFwZ7dwIgPYRRdJrN6vLmD3bqxkQobHS5/Lxvh mzRImUKg5Ed6AtV2u/fco/JLx/grD8PxC2crCojsmQM7C99UtOsmjRifEQ4Z/1rW/fHms8j8 EbMycsbGo+0f9U2vVZPTnvdtmP3H/l7J/3SiNh94u540Vt2MW4eVZs9NJG7wJ7esvNP460n9 leVey5Pqygst0+z5/8aaWqKRjZd3m+6d2ljS84IlJTef9RMRkPhPSU+WkUYEAAA= Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , Thomas Nadeau , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:12:34 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A37AFRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable John, Lots of thanks for a prompt response. Unfortunately it does not address my question which referred to CC operation= only. It does not involve CV operation which indeed requires its own dedica= ted G-ACh type. But CC (and RDI) operation seems to be exactly the same in RFC 6428 and RFC= 5885. Or do I miss something? Regards, Sasha ________________________________ From: John E Drake [jdrake@juniper.net] Sent: Wednesday, July 11, 2012 6:24 PM To: Alexander Vainshtein; david.i.allan@ericsson.com; swallow@cisco.com Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf.org);= Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Sasha, The BFD packet format is the same for both CC and CV. The reason for havin= g two code points is to indicate to the receiver whether there is a trailing= source ID TLV, in which case the packet is to be used for CV rather than CC= . Thanks, John Sent from my iPhone From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: david.i.allan@ericsson.com; swallow@cisco.com; John E Drake Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf.org);= Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized =93may=94 and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A37AFRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

John,

Lots of thanks for a prompt response.

 

Unfortunately it does not address my question which referred to CC operat= ion only. It does not involve CV operation which indeed requires its own ded= icated G-ACh type.

 

But CC (and RDI) operation seems to be exactly the same in RFC 6428= and RFC 5885.

 

Or do I miss something?

 

Regards,

     Sasha 

From: John E Drake [jdrake@juniper.net]
Sent: Wednesday, July 11, 2012 6:24 PM
To: Alexander Vainshtein; david.i.allan@ericsson.com; swallow@cisco.c= om
Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

Sasha,

 

The BFD packet format= is the same for both CC and CV.  The  reason for having two code= points is to indicate to the receiver whether there is a trailing source ID= TLV, in which case the packet is to be used for CV rather than CC.

 

Thanks,

 

John

 

Sent from my iPhone

 

From: Alexander Vainshtein [mailto:Alexander.Vainshtein= @ecitele.com]
Sent: Wednesday, July 11, 2012 3:51 AM
To: david.i.allan@ericsson.com; swallow@cisco.com; John E Drake
Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

 

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized =93may=94 and not one of the IETF reserved requirement level wo= rds.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A37AFRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Wed Jul 11 10:17:04 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D27811E8101; Wed, 11 Jul 2012 10:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJGbq4OEUlP4; Wed, 11 Jul 2012 10:17:03 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 8B95011E8088; Wed, 11 Jul 2012 10:17:02 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-27.messagelabs.com!1342027052!1927820!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 28397 invoked from network); 11 Jul 2012 17:17:32 -0000 Received: from unknown (HELO fridlpvsb005.ecitele.com) (168.87.1.157) by server-11.tower-27.messagelabs.com with SMTP; 11 Jul 2012 17:17:32 -0000 X-AuditID: a8571406-b7f546d000002eb1-d7-4ffdb52cb528 Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by fridlpvsb005.ecitele.com (Symantec Messaging Gateway) with SMTP id 11.C8.11953.C25BDFF4; Wed, 11 Jul 2012 19:17:32 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 19:17:32 +0200 From: Alexander Vainshtein To: David Allan I , "swallow@cisco.com" , "jdrake@juniper.net" Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAK655QAAJsTPw= Date: Wed, 11 Jul 2012 17:17:31 +0000 Message-ID: References: , <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A391FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3WTf0gTYRjHe+9u22leXNP0bUXNi4gy16yEq5wE/UCJUioooqhze92Ottva TXNmYFFRQWVllBpoNcNKLH9baZJo2EKbhTWMgtLIjH4YSfTD6s4rE6L76/M83+/7PM979xyJ ays0OpIXPMgtcHZGHUqEgnG62Lm1wynGc00x7Md3DQT7/H49zp59uoztKb2kYo9+rCHYJ/l7 AXut/AVYqknK/1apSvo61K1O8vm+YEmP93ZrUolNuSCBEwSnh/MgvQWJZhOT6uYzObOX0fMW ExPH6F12zowcSPCYGM7lQoKFSQzV//MkSDZe0CPB7LTwgtXEJK9LiWXZ+EWxcUziehsv6lGs g+PtegcSRc6K9FJGvo9g2VaB2748r9a47qVmvboVnQtqlx8GISSkF8JgX59a4UgYeHZV4lBS S/sBbAgc/h34AKz80YHLLjVtglVXno4IEfQ+AB+0DmFygNPlGGyr6lbJrnB6MTy9/+1I3Qh6 CTw/NIgrvBh2tBeM5Al6JnzR1onJTNGr4Zmu/YTMWroAwP5HRplD6I2w5YMPyAyk+T77y0f8 OB0Fe/qKMWVuGvoa7+MKT4Kve3+oFJ4Oq2t7VYrfCeuGr6uUXhPh3YI+QvFMhrfLgkQeiCwc U7ZwzJHCMUeUvBG+7yzGFY6BF8+9+c3zYOWnDjA2XwI0lwFMd/MWuytTTDMa4w3IzHuQHRnM TkcVkFasbEOEugHk5hlaAE0CJoxqqBhO0aq4TNHraAGTSYyZRJ2slFIT0pwWr40TbVvdGXYk tgBI4kwEtTNP0igL581GbucfaYX0co/juvFmp/zxPVsXGI3/D5go6uraxBQtbZXWcztCLuT+ U2cqSTKQmlcjtZjoRlaUlc7bPX9ljAyRxwiTxlgpeyjRxTlE3qrofhBDBgZbg4C8Ud8eBFpC cApIF0VpZSstW20Zwmi1ARAlXT+cSpbVMGlpR+sMSC0wqUVJ6Xe5hfQTjUq6XLAmkJ/d0z3r McoZ1xlnKsqZ3xVIMw3ZVu6oIBJOtL0032kMps3w4d6D47fUHlt31990xHFqSuTPA9PyuPBd y6rUzY35OwxnPs8/1uzYsMe3u7drrX8WttnQX3jTeIRdNXit9FD199kn0g9lRedUZ1tBzUH7 tLqi5N5nkQ/VRRfuXS9jCNHGxc3B3SL3C68YzglBBAAA Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , "tnadeau@juniper.net" , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:17:04 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A391FRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dave, Lots of thanks for a prompt response. Unfortunately I have to say that it is confusing: interleave of CC and CV pa= ckets on the same stream is achieved by using a different G-ACh type for CV= messages. This type discriminates between CC and CV messages equally well f= or any of the two G-ACh types that potentially could be used for carrying CC= messages. Do I miss something fundamental? Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, July 11, 2012 6:07 PM To: Alexander Vainshtein; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf.= org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Hi Sasha: The reason for this is the overall system behavior implied. A 5885 code poin= t is purely CC operation. A 6428 code point indicates that CV will be interl= eaved with the stream. We wanted to explicitly disambiguate this. It further permits misbranching of a 5885 stream into a 6428 path to be dete= cted so the overall network is more robust. If the CC messages in both 5885= and 6428 had a common code point, this would not be possible, and CV operat= ion would not be authoritative. I hope this helps Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf.= org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized =93may=94 and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A391FRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Dave,

Lots of thanks for a prompt response.

 

Unfortunately I have to say that it is confusing: interleave of CC and CV= packets on the same stream is achieved by using a different G-ACh= type for CV messages. This type discriminates between CC and CV message= s equally well for any of the two G-ACh types that potentially could be used fo= r carrying CC messages.

 

Do I miss something fundamental?

 

Regards,

     Sasha 

From: David Allan I [david.i.allan@ericsson.= com]
Sent: Wednesday, July 11, 2012 6:07 PM
To: Alexander Vainshtein; swallow@cisco.com; jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe= 3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

Hi Sasha:
 
The reason for this is the overall system behavior implied. A= 5885 code point is purely CC operation. A 6428 code point indicates that CV= will be interleaved with the stream. We wanted to explicitly disambiguate this.
 
It further permits misbranching of a 5885 stream into a 6428 p= ath to be detected so the overall network is more robust. If the CC messages= in both 5885 and 6428 had a common code point, this would not be possible, and CV operation would not be authoritat= ive.
 
I hope this helps
Dave

From: Alexander Vainshtein [mailto:A= lexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe= 3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized =93may=94 and not one of the IETF reserved requirement level wo= rds.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A391FRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Wed Jul 11 10:20:29 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297A711E8110 for ; Wed, 11 Jul 2012 10:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXR3jHQWdjgT for ; Wed, 11 Jul 2012 10:20:28 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 6AD0C11E8101 for ; Wed, 11 Jul 2012 10:20:27 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1342027256!3078341!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 6101 invoked from network); 11 Jul 2012 17:20:57 -0000 Received: from unknown (HELO fridlppsb001.ecitele.com) (168.87.1.157) by server-6.tower-27.messagelabs.com with SMTP; 11 Jul 2012 17:20:57 -0000 X-AuditID: a8571401-b7ff06d000000c6d-17-4ffdb7409bab Received: from FRGRWPVCH001.ecitele.com (Unknown_Domain [10.1.18.35]) by fridlppsb001.ecitele.com (Symantec Messaging Gateway) with SMTP id 42.22.03181.047BDFF4; Wed, 11 Jul 2012 19:26:24 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRGRWPVCH001.ecitele.com ([10.1.18.35]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 19:20:55 +0200 From: Alexander Vainshtein To: Yaakov Stein , "gmanhoudt@aimvalley.nl" , "stephan.roullot@alcatel-lucent.com" , "peter.roberts@alcatel-lucent.com" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGcQcIs6TA3k0aw083lr8KXcpciKb2QgAID2wCAAChiag== Date: Wed, 11 Jul 2012 17:20:55 +0000 Message-ID: References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> , <07F7D7DED63154409F13298786A2ADC9044E3B7C@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9044E3B7C@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A3B3FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTfWgTZxzem7tLrl1PzjSaN6Fjx8uEMUlIWQtnZzrZKGZzI7oNhP2jZ/Im OUwux13UtpujBMJcmbOzOjUoKkZbbbVrjbQVKxq/MKDzA7VurV9tKuuc+2BQdRp219OuMHZ/ Pe/veX7P73nvfkcT1u8tTlqUEliRhCgyl5Kl4CWna0HvM7/nclsVP7r/voX/qadA8d/8mSX5 4/dSgL9Y2A747JYiyf/e/IhaYPH13v6O8qXGBijfpr+7KV9/etjiy2Qem3wbD4YWmz9tAvMF SYonhATmglgNeNFiRVwtBBoQJwa9qBJxclQI4BiWEl4kyDKWgqi2lPvPM1+TiRKHpUA8KEph L3rvY7+L56vnuSpR7ScRUeWwKyaIUS6GVVUIY06r6DeTgssPEZH+HZ/L65tAfTb9B9UEuqRm UEJDtgrmjh43G3g2vHSrS8OltJXNA3jl2v3nhwyAvWMFUleZWS/s6RieJGzsQwBvbthANQOa JtgwfNK9RNeUszXw9oM2i45t7FuwbV07MPA7cE/rgEnHJDsHnp3om/Rk2A/hwXWp58NGANx6 Z5zQPUvYRfBWHuoaoKWbyHdO9hKsHf44utNkpGZh5tgPhIFnwZ9HipSBX4WHj4xQhj4OW3a2 m41ZM+H5baOkoXHAk+2DZAuYnZ5mm57Wkp7WYtTdcHDzJrOB58J9u38hDOyCW4s5cnp9F7Ac APaQIgZlWV3h8VS6cUBM4Ch2B+KxHqCtWvtSG+gD99a7c4ClASpj2O5nfislrFYbYjngoE1o FtOql2asiAcbIoIaWaasimI1ByBNIBuzpkXjmKDQ0IiV+AuqTnu33xLOlwNx/dMnlr3p8fz/ AdmZro9q/VY2rC3nSoxlrLzwqaBpBJmxrDZipoLDuD4kRhP/0ia6RI9RpsXgj+gxVFmIqWLY 4PNgDn3owelBYCWluISddmZCN2J1UWSVNOUzDuzaxcuZos6Wacs65TCumZs08117n+rm2s8z RTmbwOavzeGL2aWx+i35D3a/5n9YkirYvrw54/q5tY3JE2fKFybIuo53lUwmWX3plWjq9YU1 23q5iup9hdor7w/J23Ot3CLH6c5Tv/Yn6d++GL7ceC7UecKG/np69byZ7rjh6Ltbk7zg6K6q 2NE65H7y9uHP1g7t3fNVqG7ANc+OXHeKyY2IVCNC5RuEogr/AJ28VK5DBAAA Cc: pwe3 , "stbryant@cisco.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:20:29 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A3B3FRIDWPPMB001ecite_ Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Hi all, I concur with Yaakov's points. Regards, Sasha ________________________________ From: Yaakov Stein [yaakov_s@rad.com] Sent: Wednesday, July 11, 2012 6:55 PM To: Alexander Vainshtein; gmanhoudt@aimvalley.nl; stephan.roullot@alcatel-lu= cent.com; peter.roberts@alcatel-lucent.com Cc: stbryant@cisco.com; pwe3; Ron Cohen Subject: RE: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Authors of draft-manhoudt-pwe3-tsop and the rest of PWE3, This approach was considered a long time ago, but was not accepted due to a major architectural flaws. First, as Sasha said, it does not find the S1 byte and thus lies about the SSM message. This is not acceptable behavior. In terms that non-TDM people would understand, this would be similar to discovering an incorrect header checksum. but then recalculating it to cover up the loss. Second, this function is at least a section (in SDH terminology a regenerato= r section) termination (since it does not divide up STM-Ns, it is not a line termination). Section terminations MUST terminate and regenerate the section overhead (A1, A2, J0, B1, etc.) and optionally SHOULD enable insertion and dropping o= f E1, F1, and D1/2/3 Data Communcations Channels. Once again, by transparently passing these bytes rather than regenerating th= em, the emulation "lies" about their values. Finally, as Sasha already stated, the scrambling mechanism recovery after a single packet loss is problematic. This in itself pretty much kills the service usefulness if there is any pack= et loss. In addition the clocking is not sufficiently described. I understand that RTP usage is mandated, and for some reason that 25 MHz is the nominal frequency. However, it is not clear what that 25 MHz is locked to. Is this always "common clock" (differential mode) ? Also, why is G.709 AIS generated instead of SDH MS-AIS or MSF-AIS ? I have a funny feeling that someone is trying to trick the SDH end devices NOT to recognize the fault condition. G.826 specifies that detecting AIS causes the declaration of a severely erro= red second (SES) and that there can be no more than 1/5 of a percent of SESes, i.e., about 1 AIS event in 500 seconds. At the default payload size of 810 Bytes, a single STM-1 takes 3 packets, so that there are 24,000 packets per second, so we are talking about an packet loss ratio of 1 in 500*24,000 =3D 12 milli= on, i.e., about 8E-8. Nits: As with all PWs, TSoP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. well, it will require extensions to 4447. The key difference between the CEP approach and the TSoP approach is that within CEP an incoming STM-N is terminated and demultiplexed to its constituent VCs (Virtual Containers). I don't agree. While transport of VTs/VCs is allowed, an STM-1 can be transported directly using CEP without demuxing. However, the framing is discovered and the CW structure pointer points to th= e beginning of the SPE. This is the correct behavior for a regenerator. Why is G.709 an informative reference, if one needs to generate its AIS patt= ern ? Y(J)S This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A3B3FRIDWPPMB001ecite_ Content-Type: text/html; charset="iso-8859-1" content-transfer-encoding: quoted-printable

Hi all,

I concur with Yaakov's points.

 

Regards,

     Sasha

From: Yaakov Stein [yaakov_s@rad.com]
Sent: Wednesday, July 11, 2012 6:55 PM
To: Alexander Vainshtein; gmanhoudt@aimvalley.nl; stephan.roullot@alc= atel-lucent.com; peter.roberts@alcatel-lucent.com
Cc: stbryant@cisco.com; pwe3; Ron Cohen
Subject: RE: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP

Authors of draft-manhoudt-pwe3-tsop and th= e rest of PWE3,

 

This approach was considered a long time a= go,

but was not accepted due to a major archit= ectural flaws.

 

First, as Sasha said, it does not find the= S1 byte

and thus lies about the SSM message.

This is not acceptable behavior.

In terms that non-TDM people would underst= and,

this would be similar to discovering an in= correct header checksum.

but then recalculating it to cover up the= loss.

 

Second, this function is at least a sectio= n (in SDH terminology a regenerator section) termination

(since it does not divide up STM-Ns, it is= not a line termination).

Section terminations MUST terminate and re= generate the section overhead

(A1, A2, J0, B1, etc.) and optionally SHOU= LD enable insertion and dropping of

E1, F1, and D1/2/3 Data Communcations Chan= nels.

Once again, by transparently passing these= bytes rather than regenerating them,

the emulation "lies" about their= values.

 

Finally, as Sasha already stated, the scra= mbling mechanism

recovery after a single packet loss is pro= blematic.

This in itself pretty much kills the servi= ce usefulness if there is any packet loss.

 

In addition the clocking is not sufficient= ly described.

I understand that RTP usage is mandated,

and for some reason that 25 MHz is the nom= inal frequency.

However, it is not clear what that 25 MHz= is locked to.

Is this always "common clock" (d= ifferential mode) ?

 

Also, why is G.709 AIS generated instead o= f SDH MS-AIS or MSF-AIS ?

I have a funny feeling that someone is try= ing to trick the SDH end devices

NOT to recognize the fault condition.

G.826 specifies that detecting AIS causes= the declaration of a severely errored second (SES)

and that there can be no more than 1/5 of= a percent of SESes,

i.e., about 1 AIS event in 500 seconds.

At the default payload size of 810 Bytes,= a single STM-1 takes 3 packets,

so that there are 24,000 packets per secon= d,

so we are talking about an packet loss rat= io of 1 in 500*24,000 =3D 12 million,

i.e., about 8E-8.

 

Nits:  

   As with all PWs, TSoP PWs may be manually configured or=
 set up using
   the PWE3 control protocol [RFC4447].

well, it will require extensio= ns to 4447.

 

   The key difference between the CEP approach and the T=
SoP
   approach is that within CEP an incoming STM-N is term=
inated and
   demultiplexed to its constituent VCs (Virtual Contain=
ers).

I don't agree. While transport= of VTs/VCs is allowed,

an STM-1 can be transported di= rectly using CEP without demuxing.

However, the framing is discov= ered and the CW structure pointer points to the beginning of the SPE.=

This is the correct behavior f= or a regenerator.

 

Why is G.709 an informative re= ference, if one needs to generate its AIS pattern ?

 

Y(J)S

 

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A3B3FRIDWPPMB001ecite_-- From david.i.allan@ericsson.com Wed Jul 11 10:20:49 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4719311E8120; Wed, 11 Jul 2012 10:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKBwsnwKmh1s; Wed, 11 Jul 2012 10:20:46 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 5203011E811D; Wed, 11 Jul 2012 10:20:46 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6BHKwCe003426; Wed, 11 Jul 2012 12:21:14 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.11]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 11 Jul 2012 13:21:10 -0400 From: David Allan I To: Alexander Vainshtein Date: Wed, 11 Jul 2012 13:21:09 -0400 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAK655QAAJsTPwAADHVYA== Message-ID: <60C093A41B5E45409A19D42CF7786DFD53BC065985@EUSAACMS0703.eamcs.ericsson.se> References: , <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD53BC065985EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:20:49 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD53BC065985EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha: cc list trimmed.... I'm sorry, I'm not quite grasping your point. We need to know when CC will not have CV interleaved. We need to know when CC will have CV interleaved. We need to know when a CV TLV will be present. Ergo 3 code points. Could you clarify your concern? Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:18 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Dave, Lots of thanks for a prompt response. Unfortunately I have to say that it is confusing: interleave of CC and CV p= ackets on the same stream is achieved by using a different G-ACh type for C= V messages. This type discriminates between CC and CV messages equally well= for any of the two G-ACh types that potentially could be used for carrying= CC messages. Do I miss something fundamental? Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, July 11, 2012 6:07 PM To: Alexander Vainshtein; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Hi Sasha: The reason for this is the overall system behavior implied. A 5885 code poi= nt is purely CC operation. A 6428 code point indicates that CV will be inte= rleaved with the stream. We wanted to explicitly disambiguate this. It further permits misbranching of a 5885 stream into a 6428 path to be det= ected so the overall network is more robust. If the CC messages in both 588= 5 and 6428 had a common code point, this would not be possible, and CV oper= ation would not be authoritative. I hope this helps Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_60C093A41B5E45409A19D42CF7786DFD53BC065985EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Sasha:
 
cc=20 list trimmed....
 
I'm=20 sorry, I'm not quite grasping your point.
 
We=20 need to know when CC will not have CV interleaved.
We=20 need to know when CC will have CV interleaved.
We=20 need to know when a CV TLV will be present.
 
Ergo 3=20 code points. Could you clarify your concern?
Dave

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July = 11,=20 2012 10:18 AM
To: David Allan I; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for= =20

Dave,

Lots of thanks for a prompt response.

 

Unfortunately I have to say that it is confusing: interleave of CC and C= V=20 packets on the same stream is achieved by using a different G-ACh= =20 type for CV messages. This type discriminates between CC and CV messages eq= ually=20 well for any of the two G-ACh types that potentia= lly=20 could be used for carrying CC messages.

 

Do I miss something fundamental?

 

Regards,

     Sasha 

From: David Allan I=20 [david.i.allan@ericsson.com]
Sent: Wednesday, July 11, 2012 6:07= =20 PM
To: Alexander Vainshtein; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for= =20

Hi=20 Sasha:
 
The=20 reason for this is the overall system behavior implied. A 5885 code point i= s=20 purely CC operation. A 6428 code point indicates that CV will be interleave= d=20 with the stream. We wanted to explicitly disambiguate=20 this.
 
It=20 further permits misbranching of a 5885 stream into a 6428 path to be detect= ed so=20 the overall network is more robust. If the CC messages in both 5885 and 642= 8 had=20 a common code point, this would not be possible, and CV operation would not= be=20 authoritative.
 
I hope=20 this helps
Dave

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July = 11,=20 2012 3:51 AM
To: David Allan I; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: Doubts in allocation of a new G-ACH type for=20

Hi all,

I have doubts regarding allocation of the G-ACH type f= or the=20 MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, i= t seems=20 that the format of the MPLS-TP CC packet and the format of the raw BFD pack= et in=20 VCCV is exactly the same. However, two different G-ACH types have been allo= cated=20 by IANA for these two cases.

 

IMHO and FWIW such duplication can only create=20 interoperability problems, especially with progress of the new VCCV Type (u= sing=20 GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capab= ility=20 to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the=20 confusion IMO, since it uses un-capitalized “may” and not one o= f the IETF=20 reserved requirement level words.

 

Clarification of intentions by the editors of RFC 6428= =20 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_60C093A41B5E45409A19D42CF7786DFD53BC065985EUSAACMS0703e_-- From Alexander.Vainshtein@ecitele.com Wed Jul 11 10:29:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94511E80CD; Wed, 11 Jul 2012 10:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xf-hAuA1ynYk; Wed, 11 Jul 2012 10:29:23 -0700 (PDT) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.34]) by ietfa.amsl.com (Postfix) with ESMTP id 427F021F8594; Wed, 11 Jul 2012 10:29:22 -0700 (PDT) Received: from [85.158.138.51:24841] by server-1.bemta-3.messagelabs.com id A8/D5-14648-018BDFF4; Wed, 11 Jul 2012 17:29:52 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-10.tower-174.messagelabs.com!1342027791!24374599!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 27581 invoked from network); 11 Jul 2012 17:29:52 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-10.tower-174.messagelabs.com with SMTP; 11 Jul 2012 17:29:52 -0000 X-AuditID: a8571403-b7eff6d000003899-10-4ffdb801bff1 Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 62.68.14489.108BDFF4; Wed, 11 Jul 2012 19:29:37 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 11 Jul 2012 19:29:51 +0200 From: Alexander Vainshtein To: Gregory Mirsky , David Allan I , "swallow@cisco.com" , "jdrake@juniper.net" Thread-Topic: [mpls] Doubts in allocation of a new G-ACH type for Thread-Index: AQHNX3sSiCn3X34i4EqIXHysnGrWUpckVUkB Date: Wed, 11 Jul 2012 17:29:50 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A3C7FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa0zTUBj1rt1WkGoZUy6L0dnExIibw0eojyFqNBijQ+Yr/tG6XrbGrV3W iU7/wKI/JPFNfBCnaOYDBRFEIYiigC8ShZioxLdCNCLRaFCCCtpSRRJjf537nfOd8932K4EZ yvQmgheCKCCwXloXi8eCISYLqO512PIaIfOquQpj3rbnA+bws3nM4xPFWmbn50qceVIQBsz5 ktcgXZ9R8L1cm/HtywNdRjTao8l4FH6gz8RX54JZrCCIQTaIzBySXHY6M8DnsK4QbeY5O51C m/1e1oV8SAjaadbvRwJHp8Wa/3lmyTJeMCPBJXK84LbTC50OC8NMm25JodOWeXjJjCw+lvea fUiSWDcyyxXlPgK39hzm2R/t1fu3Ozd1XT2lyQWlC/JBDAGpqTDvUVin4pGw5XlZPzZQTQBe ylubD2JlHAWwIVKHKYSOssOKs890CmGkKgE80NGGKweMagHw84sKraJKoNJh/Y5IPzZSc2DB 9U5cxZPh/Z8f+51wahw8+P2NRsEktRi+qD2Oq3GHAIy83K9XiBhqFdz28CdQMJDn624q6W/A qET4uP2oRp2bgtHaZkzFI+C7tj6tisfACxfbtKpehKUfmn+HxcM7h9pxVZMEr59uxXeDkYWD bAsHtRQOalHrNvjx3lFMxcnw5LH3v/EkWN51FwyuFwH9GQCzAzzn9edI62y2KVbk4oPIi6wu 0VcB5B07vdKIVYOuXdZ6QBGAjiOrz/U6DFo2Rwr56kESoaFHkPvK5dKwdSIX8rCSZ01ggxdJ 9QASGG0kN+6WOZJjQ5tRQPxDzZff7h7MNNQlKl8/uGaKzfb/A51IlmWlOQyUW97P9Qj5UeCP zyiCoCE5o0qOiA8gN9qUzXuDf2kNEaOMESeP4VQ0pORnfRLvVvkmkEy0fGpsBURN1e1WYMAF UUCmRHK5IqUUqWeDMODWARLl6yeQqxU2Tt7aAZ8OOUIjRxSd+KFEyH/RAGXKBWj8sZs1p264 e5YaGw53L33NEyv6dD1XZjuHW/KMIX+lcVUJNXpIeDR3uSahuC+LLr71tftCY/KXLVsj2dcW 8a8ml0a604N7XdCqS10yUyi9UcedvWdPzSrZe2BuZ5E96emciVItc2Re6lixU49lxjsXaL7O CN9usR5xELtS6xpoXPKwKROwgMT+AgpIObpCBAAA Cc: Mishael Wexler , "mpls@ietf.org" , Rotem Cohen , "pwe3 \(pwe3@ietf.org\)" , "tnadeau@juniper.net" Subject: Re: [PWE3] [mpls] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 17:29:24 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A3C7FRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Greg, Lots of thanks for a prompt response. Regarding your first point - ability to maintain independent BFD sessions fo= r associated unidirectional LSPs: Do you imply that, as far as co-routed bid= irectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-ACh Type =3D= 22? As for ability to deduce from receiving something with G-ACh Type =3D 22 tha= t you should be also reqdy to receive something with G-ACh Type =3D 23 (CV),= I do not think that this is explicitly specified anywhere. From my point of= view, ability to support CV MUST be explicitly synchronized between the LSP= endpoints (by configuration or signaling). My 2c, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Wednesday, July 11, 2012 5:37 PM To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@juniper.n= et Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Dear Sasha, et al., I think that one of differences between CC defined in RFC 5885 and RFC 6428= in introduction of independent mode to monitor associated bi-directional p2= p connections. Then there's FSMs fo coordinated and independent modes, Fig.7= and Fig.8 in RFC 6428, that are different from FSM of RFC 5880. Then, IMHO,= using G-ACh from RFC 6428 indicates possible use of RFC 6428-based CV while= there's no CV for neither Control Channel 0x07. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: [mpls] Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized =93may=94 and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A3C7FRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Greg,

Lots of thanks for a prompt response.

 

Regarding your first point - ability to maintain independent BFD sessions= for associated unidirectional LSPs: Do you imply that, as far as co-routed= bidirectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-A= Ch Type =3D 22?

 

As for ability to deduce from receiving something with G-ACh Type= =3D 22 that you should be also reqdy to receive something with= G-ACh Type =3D 23 (CV), I do not think that this is explicitly speci= fied anywhere. From my point of view, ability to support CV MUST be explicitly synchronized between the LSP endpoints (by= configuration or signaling).

 

My 2c,

     Sasha

From: Gregory Mirsky [gregory.mirsky@ericsso= n.com]
Sent: Wednesday, July 11, 2012 5:37 PM
To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@ju= niper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

 
Dear Sasha, et al.,
I think that one of differences between CC defined in RFC 5885 and RFC 6428 in introduct= ion of independent mode to monitor associated bi-directional p2p connections= . Then there's FSMs fo coordinated and independent modes, Fig.7 and Fig.8 in= RFC 6428, that are different from FSM of RFC 5880. Then, IMHO, using G-ACh from RFC 6428 indicates possi= ble use of RFC 6428-based CV while there's no CV for neither Control Channel= 0x07.
 
    Regards,
        Greg

From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: [mpls] Doubts in allocation of a new G-ACH type for

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized =93may=94 and not one of the IETF reserved requirement level wo= rds.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A3C7FRIDWPPMB001ecite_-- From jdrake@juniper.net Wed Jul 11 11:32:42 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E46111E80EF; Wed, 11 Jul 2012 11:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.936 X-Spam-Level: X-Spam-Status: No, score=-5.936 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoVzgA+4+0ZY; Wed, 11 Jul 2012 11:32:40 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 20F1F11E80DB; Wed, 11 Jul 2012 11:32:39 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT/3G4UKLChPQnWZ0d3ipHRzpNLe+dmEZ@postini.com; Wed, 11 Jul 2012 11:33:11 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 11 Jul 2012 11:30:27 -0700 From: John E Drake To: Alexander Vainshtein , "david.i.allan@ericsson.com" , "swallow@cisco.com" Date: Wed, 11 Jul 2012 11:30:27 -0700 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgALh55QAAEniWcAAx45gA== Message-ID: <5E893DB832F57341992548CDBB333163A5A82A4D88@EMBX01-HQ.jnpr.net> References: , <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_" MIME-Version: 1.0 Cc: "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , Thomas Nadeau , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:32:42 -0000 --_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sasha, Oopsie. Doesn't RFC 5885 describe the use of BFD for pseudowire VCCV? Other than= the independent mode that Greg mentioned, RFC 6428 is just standard BFD b= ut it is for an LSP rather than a pseudowire. Or did I miss something 8->? Thanks, John Sent from my iPhone From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:13 AM To: John E Drake; david.i.allan@ericsson.com; swallow@cisco.com Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf.org);= Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for John, Lots of thanks for a prompt response. Unfortunately it does not address my question which referred to CC operatio= n only. It does not involve CV operation which indeed requires its own dedi= cated G-ACh type. But CC (and RDI) operation seems to be exactly the same in RFC 6428 and RFC= 5885. Or do I miss something? Regards, Sasha ________________________________ From: John E Drake [jdrake@juniper.net] Sent: Wednesday, July 11, 2012 6:24 PM To: Alexander Vainshtein; david.i.allan@ericsson.com; swallow@cisco.com Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf= .org; pwe3 (pwe3@ietf.org); Rot= em Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Sasha, The BFD packet format is the same for both CC and CV. The reason for havi= ng two code points is to indicate to the receiver whether there is a traili= ng source ID TLV, in which case the packet is to be used for CV rather than= CC. Thanks, John Sent from my iPhone From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: david.i.allan@ericsson.com; swallow@= cisco.com; John E Drake Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf= .org; pwe3 (pwe3@ietf.org); Rot= em Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sasha,

 

Oopsie.

 

Doesn’t RFC 5885  describe the u= se of BFD for pseudowire VCCV?   Other than the independent mode = that Greg mentioned,  RFC 6428 is just standard BFD but it is for an L= SP rather than a pseudowire.  Or did I miss something 8->?

 =

Thanks,=

 

John

 

Sent from my iPhone

 

From: Alexander Vainshtein [mailto:Alexander.= Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 10:13 AM<= br>To: John E Drake; david.i.allan@ericsson.com; swallow@cisco.comCc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@i= etf.org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE= : Doubts in allocation of a new G-ACH type for

=

 

John,

Lots of = thanks for a prompt response.

 

Unfortuna= tely it does not address my question which referred to CC operation only. I= t does not involve CV operation which indeed requires its own dedicated G-A= Ch type.

 

But CC (and RDI) operation see= ms to be exactly the same in RFC 6428 and RFC 5885.<= /p>

 

Or do I miss something?

 

Regards,

  = ;   Sasha 

From: John E Drake [j= drake@juniper.net]
Sent: Wednesday, July 11, 2012 6:24 PM
T= o: Alexander Vainshtein; = david.i.allan@ericsson.com; swallo= w@cisco.com
Cc: cpignat= a@cisco.com; Thomas Nadeau; mpls@ietf.= org; pwe3 (pwe3@ietf.org); Rotem C= ohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in alloc= ation of a new G-ACH type for

Sasha,

 

The BFD packet format is the same for both CC and = CV.  The  reason for having two code points is to indicate to the= receiver whether there is a trailing source ID TLV, in which case the pack= et is to be used for CV rather than CC.<= o:p>

 = ;

T= hanks,

 

John

 

Sent from my iPhone

 <= o:p>

From:= Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 3:51 AM
To: david.i.allan@ericsson.com; swallow@cisco.com; John E Drake
Cc: cpignata@cisco.com; Thomas Nadeau; mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael WexlerSubject: Doubts in allocation of a new G-ACH type for

 

Hi all,

I have doubts regarding allocation of th= e G-ACH type for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885= , it seems that the format of the MPLS-TP CC packet and the format of the r= aw BFD packet in VCCV is exactly the same. However, two different G-ACH typ= es have been allocated by IANA for these two cases.

 

=

IMHO and FWIW such duplica= tion can only create interoperability problems, especially with progress of= the new VCCV Type (using GAL) for PWs. The text in Section 3.1 of 6428 tha= t refers to existing capability to run BFD over LSP with the G-ACh using Ch= annel Type 7 only adds to the confusion IMO, since it uses un-capitalized &= #8220;may” and not one of the IETF reserved requirement level words.<= o:p>

 = ;

Cla= rification of intentions by the editors of RFC 6428 (and/or of RFC 5885) wo= uld be highly appreciated.

 

Regards,

=      Sasha

 

This e-mail message is intended for t= he recipient only and contains information which is CONFIDENTIAL and which = may be proprietary to ECI Telecom. If you have received this transmission i= n error, please inform us by e-mail, phone or fax, and then delete the orig= inal and all copies thereof.

=

This e-mail message is intended for the recipient only and contain= s information which is CONFIDENTIAL and which may be proprietary to ECI Tel= ecom. If you have received this transmission in error, please inform us by = e-mail, phone or fax, and then delete the original and all copies thereof. =

= --_000_5E893DB832F57341992548CDBB333163A5A82A4D88EMBX01HQjnprn_-- From gregory.mirsky@ericsson.com Wed Jul 11 17:04:05 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DF811E8115; Wed, 11 Jul 2012 17:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHwUkUG+PgFq; Wed, 11 Jul 2012 17:04:02 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 952C311E80C9; Wed, 11 Jul 2012 17:04:01 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6C04PCr012622; Wed, 11 Jul 2012 19:04:27 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 11 Jul 2012 20:04:19 -0400 From: Gregory Mirsky To: Alexander Vainshtein Date: Wed, 11 Jul 2012 20:04:17 -0400 Thread-Topic: [mpls] Doubts in allocation of a new G-ACH type for Thread-Index: AQHNX3sSiCn3X34i4EqIXHysnGrWUpckVUkBgABrAmA= Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF137D7192B15EUSAACMS0715e_" MIME-Version: 1.0 Cc: Mishael Wexler , "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] [mpls] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 00:04:05 -0000 --_000_FE60A4E52763E84B935532D7D9294FF137D7192B15EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sasha, if one is interested only in CC monitoring on bi-directional p2p LSP in coo= rdinated mode, then, IMHO, use PW-ACH ecapsulation is as good as MPLS-TP CC= code point. In Section 3.3 of RFC 6428 I read (apologies for a lengthy quote): "CC and CV operations are simultaneously employed on a maintenance entity (ME) within a single BFD session. The expected usage is that normal operation is to send CC BFD protocol data units (PDUs) interleaved with a CV BFD PDU (augmented with a Source MEP-ID and identified as requiring additional processing by the different ACh channel types)." Yes, though there is no MUST or even CAN but I'd interpret it as SHOULD. At= the same time MPLS-TP CC ACh MAY be used, by mutual agreement between the = end points, as CC only, without expectation of CV messages. AFAIK, http://t= ools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08 supports exp= licit CC and CC/CV configuration. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:30 AM To: Gregory Mirsky; David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org= ); Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Greg, Lots of thanks for a prompt response. Regarding your first point - ability to maintain independent BFD sessions f= or associated unidirectional LSPs: Do you imply that, as far as co-routed b= idirectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-ACh Type = =3D 22? As for ability to deduce from receiving something with G-ACh Type =3D 22 th= at you should be also reqdy to receive something with G-ACh Type =3D 23 (CV= ), I do not think that this is explicitly specified anywhere. From my point= of view, ability to support CV MUST be explicitly synchronized between the= LSP endpoints (by configuration or signaling). My 2c, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Wednesday, July 11, 2012 5:37 PM To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@juniper.= net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org= ); Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Dear Sasha, et al., I think that one of differences between CC defined in RFC 5885 and RFC 6428= in introduction of independent mode to monitor associated bi-directional p= 2p connections. Then there's FSMs fo coordinated and independent modes, Fig= .7 and Fig.8 in RFC 6428, that are different from FSM of RFC 5880. Then, IM= HO, using G-ACh from RFC 6428 indicates possible use of RFC 6428-based CV w= hile there's no CV for neither Control Channel 0x07. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org= ); Rotem Cohen Subject: [mpls] Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_FE60A4E52763E84B935532D7D9294FF137D7192B15EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Sasha,
if one is interested only in CC monitoring on=20 bi-directional p2p LSP in coordinated mode, then, IMHO, use PW-ACH ecapsula= tion=20 is as good as MPLS-TP CC code point.
In Section 3.3 of RFC 6428 I read (apologies for a= lengthy=20 quote):
  "CC and CV operations are simultaneously em= ployed on=20 a maintenance
   entity (ME) within a single BFD session. = ; The=20 expected usage is that
   normal operation is to send CC BFD=20 protocol data units (PDUs)
   interleaved with a CV BFD PDU=20 (augmented with a Source MEP-ID and
   identified as requiring= =20 additional processing by the different ACh
   channel types)."= =20
Yes, though there is no MUST or even CAN but I'd i= nterpret=20 it as SHOULD. At the same time MPLS-TP CC ACh MAY be used, by mutual agreem= ent=20 between the end points, as CC only, without expectation of CV messages. AFA= IK,=20 http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08=  supports=20 explicit CC and CC/CV configuration.
 
  &n= bsp; Regards,
        Greg
 
From: Alexa= nder=20 Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wedne= sday,=20 July 11, 2012 10:30 AM
To: Gregory Mirsky; David Allan I;=20 swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org; Mishael= =20 Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org); Rotem=20 Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH typ= e=20 for

Greg,

Lots of thanks for a prompt response.

 

Regarding your first point - ability to maintain independent BFD session= s for=20 associated unidirectional LSPs: Do you imply that, as far as co-routed=20 bidirectional LSPs are concerned, G-ACh Type =3D 7 is as good as=20 G-ACh Type =3D 22?

 

As for ability to deduce from receiving something with G-ACh Type= =3D 22=20 that you should be also reqdy to receive something with G-ACh=20 Type =3D 23 (CV), I do not think that this is explicitly specified anywhere= . From=20 my point of view, ability to support CV MUST be explicitly synchronized bet= ween=20 the LSP endpoints (by configuration or signaling).

 

My 2c,

     Sasha

From: Gregory Mirsky [gregory.mirsky@ericsson.com]
Se= nt:=20 Wednesday, July 11, 2012 5:37 PM
To: Alexander Vainshtein; David = Allan=20 I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org; Misha= el=20 Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org); Rotem=20 Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH typ= e=20 for

 
Dear Sasha, et al.,
= I think that one of differences b= etween CC=20 defined in RFC 5885 and RFC 6428 in introduction of independent mode to mon= itor=20 associated bi-directional p2p connections. Then there's FSMs fo coordinated= and=20 independent modes, Fig.7 and Fig.8 in RFC 6428, that are different from FSM= of=20 RFC 5880. Then, IMHO, using G-ACh from RFC 6428 indicates possible use of R= FC=20 6428-based CV while there's no CV for neither Control Channel=20 0x07.
 
   =20 Regards,
       =20 Greg

From: mpls-bounces@ietf.org=20 [mailto:mpls-bounces@ietf.org] On Behalf Of Alexander=20 Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: D= avid=20 Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org;= =20 Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org); Rotem=20 Cohen
Subject: [mpls] Doubts in allocation of a new G-ACH type=20 for

Hi all,

I have doubts regarding allocation of the G-ACH type f= or the=20 MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, i= t seems=20 that the format of the MPLS-TP CC packet and the format of the raw BFD pack= et in=20 VCCV is exactly the same. However, two different G-ACH types have been allo= cated=20 by IANA for these two cases.

 

IMHO and FWIW such duplication can only create=20 interoperability problems, especially with progress of the new VCCV Type (u= sing=20 GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capab= ility=20 to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the=20 confusion IMO, since it uses un-capitalized “may” and not one o= f the IETF=20 reserved requirement level words.

 

Clarification of intentions by the editors of RFC 6428= =20 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_FE60A4E52763E84B935532D7D9294FF137D7192B15EUSAACMS0715e_-- From ma.yuxia@zte.com.cn Wed Jul 11 18:30:55 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CE521F859E for ; Wed, 11 Jul 2012 18:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQIguZi5em-9 for ; Wed, 11 Jul 2012 18:30:53 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 40A0F21F8592 for ; Wed, 11 Jul 2012 18:30:52 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286201397396305; Thu, 12 Jul 2012 09:24:05 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 9361.1397396305; Thu, 12 Jul 2012 09:31:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6C1VDPr092960 for ; Thu, 12 Jul 2012 09:31:13 +0800 (GMT-8) (envelope-from ma.yuxia@zte.com.cn) To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: ma.yuxia@zte.com.cn Date: Thu, 12 Jul 2012 09:30:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-07-12 09:31:14, Serialize complete at 2012-07-12 09:31:14 Content-Type: multipart/alternative; boundary="=_alternative 00085AD748257A39_=" X-MAIL: mse02.zte.com.cn q6C1VDPr092960 Subject: [PWE3] New Version Notification for draft-hao-pwe3-iccp-extension-for-msp-03.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 01:30:55 -0000 This is a multipart message in MIME format. --=_alternative 00085AD748257A39_= Content-Type: text/plain; charset="US-ASCII" Hi all, "draft-hao-pwe3-iccp-extension-for-msp" has been updated to version 3. Any comments are welcome! Thanks, Yuxia > > A new version of I-D, draft-hao-pwe3-iccp-extension-for-msp-03.txt > has been successfully submitted by Yuxia Ma and posted to the > IETF repository. > > Filename: draft-hao-pwe3-iccp-extension-for-msp > Revision: 03 > Title: ICCP extension for the MSP application > Creation date: 2012-07-11 > WG ID: Individual Submission > Number of pages: 17 > URL: http://www.ietf.org/internet-drafts/draft-hao-pwe3- > iccp-extension-for-msp-03.txt > Status: http://datatracker.ietf.org/doc/draft-hao-pwe3- > iccp-extension-for-msp > Htmlized: http://tools.ietf.org/html/draft-hao-pwe3-iccp- > extension-for-msp-03 > Diff: http://tools.ietf.org/rfcdiff?url2=draft-hao-pwe3- > iccp-extension-for-msp-03 > > Abstract: > This document specifies extensions to the Inter-Chassis Communication > Protocol (ICCP) to support inter-chassis linear multiplex section > protection (MSP) as described in G.841 and automatic protection > switching as defined in ANSI T1.105.01. This document considers an > application where a CE device or access network is attached to two > PEs through Synchronous Digital Hierarchy (SDH) circuits, and MSP or > APS is used to protect the attachment circuits. ICCP is used to > support configuration and state synchronization between two chassis. > CE device or access network attached to more than two PEs is out of > the scope of this document. > > > > > The IETF Secretariat > --=_alternative 00085AD748257A39_= Content-Type: text/html; charset="US-ASCII"
Hi all,

"draft-hao-pwe3-iccp-extension-for-msp" has been updated to version 3.

Any comments are welcome!

Thanks,
Yuxia


>
> A new version of I-D, draft-hao-pwe3-iccp-extension-for-msp-03.txt
> has been successfully submitted by Yuxia Ma and posted to the
> IETF repository.
>
> Filename:    draft-hao-pwe3-iccp-extension-for-msp
> Revision:    03
> Title:       ICCP extension for the MSP application
> Creation date:    2012-07-11
> WG ID:       Individual Submission
> Number of pages: 17
> URL:             http://www.ietf.org/internet-drafts/draft-hao-pwe3-
> iccp-extension-for-msp-03.txt
> Status:          http://datatracker.ietf.org/doc/draft-hao-pwe3-
> iccp-extension-for-msp
> Htmlized:        http://tools.ietf.org/html/draft-hao-pwe3-iccp-
> extension-for-msp-03
> Diff:            http://tools.ietf.org/rfcdiff?url2=draft-hao-pwe3-
> iccp-extension-for-msp-03
>
> Abstract:
>    This document specifies extensions to the Inter-Chassis Communication
>    Protocol (ICCP) to support inter-chassis linear multiplex section
>    protection (MSP) as described in G.841 and automatic protection
>    switching as defined in ANSI T1.105.01.  This document considers an
>    application where a CE device or access network is attached to two
>    PEs through Synchronous Digital Hierarchy (SDH) circuits, and MSP or
>    APS is used to protect the attachment circuits.  ICCP is used to
>    support configuration and state synchronization between two chassis.
>    CE device or access network attached to more than two PEs is out of
>    the scope of this document.
>
>                                                                              
>
>
> The IETF Secretariat
>
--=_alternative 00085AD748257A39_=-- From Alexander.Vainshtein@ecitele.com Wed Jul 11 21:28:35 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEFEF21F853D; Wed, 11 Jul 2012 21:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8+caJ3aTNEL; Wed, 11 Jul 2012 21:28:34 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id BF1A621F8534; Wed, 11 Jul 2012 21:28:33 -0700 (PDT) Received: from [85.158.143.35:61968] by server-3.bemta-4.messagelabs.com id AB/0F-05808-1925EFF4; Thu, 12 Jul 2012 04:29:05 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1342067344!16515552!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 21391 invoked from network); 12 Jul 2012 04:29:04 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-14.tower-21.messagelabs.com with SMTP; 12 Jul 2012 04:29:04 -0000 X-AuditID: a8571402-b7f116d0000051b6-71-4ffe4e2df43a Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 97.95.20918.D2E4EFF4; Thu, 12 Jul 2012 06:10:21 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 12 Jul 2012 06:29:03 +0200 From: Alexander Vainshtein To: Gregory Mirsky Thread-Topic: [mpls] Doubts in allocation of a new G-ACH type for Thread-Index: AQHNX3sSiCn3X34i4EqIXHysnGrWUpckVUkBgABrAmCAAE5VBQ== Date: Thu, 12 Jul 2012 04:29:03 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wMURh159GdVoexrfZ2IzG58YjHsuuVRbdRVWyidrVNiFDG7rU77M6u nfWohNQrqGoIf2yISouutyLqFbFBaFL8KKmlDVpplBJFqEeZ6VBNxPw69zvn+865M98wpH6P zsCIUggHJcGL4hKoBNDLYDTO7rSbNt9JsrQ0FwNL7HCEtpS2n6emkDO/fnoYN7OiooNwEPOL QLogSf6QEMK8C8tOK3IExVWCsxDxosuKzIgPeAUn9mEpZEVCIIAlF8pI4P950hWZKPFYcvpd ouS2Ilue3WixjJ9oNKOMfI8o89joE0Qv78OyLLgxr1TUyJJr8SnSUx55qwts3wLWRJrf0UVg 64piEM9AbhwsaW2L03AKfNB4WsEJjJ6rAfDy2xZaO1QAeL+jjlJVcZwVVh1v6OpI5kzwyZGj pCoiuXIA68qekCqRxE2B0Z0HaE2UCffeeENpeCq8XFJLqJjiBsOfpZ+69CyXA082fNNpbhEC nqg/3yWK5+bBtovtOhUDJd/nmhNddZJLhbHmg4SWm4MVV++TGu4PXzV10hoeCM9daKI1vR/e rY7qNLN+8O6+ZkrTpMEblfXULpAS7jE23KMl3KNFq5vgu3sHSQ2PgEcOvf6NR8OzH2tBz3oZ 0B0DcHqubdoshyNvqsk0ZlR2li0/e1b2qCx7ThVQ9qhybjJRDTY9NkcBxwCUyDLHftj1tLBK LvRFQRpDoP5snaPTru+zxO8q9AiyZ1FwpRfLUQAZEiWzY7IUjnUJhWtx0P+Hylbe7m7S0Nvp Vz9/aNFYk+n/B5TKFuRm2PWcW1nQ5RgHcPDPnAEMgyB7Z45i0S+I3XjNUtEb+ksTTLwaI1GJ EVU1rBwQfLLo1vgaMILZ3xKLAab8WmMM6CnJL2FDKntLlXKq1LNS6p7WClKV6yex5SqbqKxt 95xWxYJQLMoOf1ctlN+omzIUAfbmcl2ZvOv95pNfPhQbA01oWMq2XIc3sz3lUmmxtcpmyxoS rly9Ycdk2Tj00fXQS7DgddSSeW9dzN/59Hbfh7tfTJw0v/7zMhypzRtbcMX+HIWc+YOKIuGN 8c/MuWltNFiS3/jI8nxIQwcfW/DAvL6gOmdkwULrjAnpaSX0ijMtiJI9gnk4GZSFX486HTgm BAAA Cc: Mishael Wexler , "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] [mpls] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 04:28:36 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Greg, Lots of thanks for a prompt and highly informative response! Regards, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Thursday, July 12, 2012 2:04 AM To: Alexander Vainshtein Cc: mpls@ietf.org; Mishael Wexler; pwe3 (pwe3@ietf.org); Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Hi Sasha, if one is interested only in CC monitoring on bi-directional p2p LSP in coor= dinated mode, then, IMHO, use PW-ACH ecapsulation is as good as MPLS-TP CC c= ode point. In Section 3.3 of RFC 6428 I read (apologies for a lengthy quote): "CC and CV operations are simultaneously employed on a maintenance entity (ME) within a single BFD session. The expected usage is that normal operation is to send CC BFD protocol data units (PDUs) interleaved with a CV BFD PDU (augmented with a Source MEP-ID and identified as requiring additional processing by the different ACh channel types)." Yes, though there is no MUST or even CAN but I'd interpret it as SHOULD. At= the same time MPLS-TP CC ACh MAY be used, by mutual agreement between the e= nd points, as CC only, without expectation of CV messages. AFAIK, http://too= ls.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08 supports explic= it CC and CC/CV configuration. Regards, Greg ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:30 AM To: Gregory Mirsky; David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Greg, Lots of thanks for a prompt response. Regarding your first point - ability to maintain independent BFD sessions fo= r associated unidirectional LSPs: Do you imply that, as far as co-routed bid= irectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-ACh Type =3D= 22? As for ability to deduce from receiving something with G-ACh Type =3D 22 tha= t you should be also reqdy to receive something with G-ACh Type =3D 23 (CV),= I do not think that this is explicitly specified anywhere. From my point of= view, ability to support CV MUST be explicitly synchronized between the LSP= endpoints (by configuration or signaling). My 2c, Sasha ________________________________ From: Gregory Mirsky [gregory.mirsky@ericsson.com] Sent: Wednesday, July 11, 2012 5:37 PM To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@juniper.n= et Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for Dear Sasha, et al., I think that one of differences between CC defined in RFC 5885 and RFC 6428= in introduction of independent mode to monitor associated bi-directional p2= p connections. Then there's FSMs fo coordinated and independent modes, Fig.7= and Fig.8 in RFC 6428, that are different from FSM of RFC 5880. Then, IMHO,= using G-ACh from RFC 6428 indicates possible use of RFC 6428-based CV while= there's no CV for neither Control Channel 0x07. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alex= ander Vainshtein Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ietf.org)= ; Rotem Cohen Subject: [mpls] Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized =93may=94 and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Greg,

Lots of thanks for a prompt and highly informative response!

 

Regards,

     Sasha

From: Gregory Mirsky [gregory.mirsky@ericsso= n.com]
Sent: Thursday, July 12, 2012 2:04 AM
To: Alexander Vainshtein
Cc: mpls@ietf.org; Mishael Wexler; pwe3 (pwe3@ietf.org); Rotem Cohen<= br> Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Hi Sasha,
if one is interested only in CC mon= itoring on bi-directional p2p LSP in coordinated mode, then, IMHO, use PW-AC= H ecapsulation is as good as MPLS-TP CC code point.
In Section 3.3 of RFC 6428 I read (= apologies for a lengthy quote):
  "CC and CV operations a= re simultaneously employed on a maintenance
   entity (ME) within a single BFD session.  The expected usa= ge is that
   normal operation is to send CC BFD protocol data units (PDUs)    interleaved with a CV BFD PDU (augmented with a Source MEP-ID a= nd
   identified as requiring additional processing by the different= ACh
   channel types)."
Yes, though there is no MUST or eve= n CAN but I'd interpret it as SHOULD. At the same time MPLS-TP CC ACh MAY be= used, by mutual agreement between the end points, as CC only, without expectation of CV messages. AFAIK, http://tools.ietf.org/html/draft-ietf-ccamp-rsvp-te-mpls-tp-oam-ext-08&n= bsp;supports explicit CC and CC/CV configuration.
 
 &nb= sp;  Regards,
 &nb= sp;      Greg
 
From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 10:30 AM
To: Gregory Mirsky; David Allan I; swallow@cisco.com; jdrake@juniper.= net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

Greg,

Lots of thanks for a prompt response.

 

Regarding your first point - ability to maintain independent BFD sessions= for associated unidirectional LSPs: Do you imply that, as far as co-routed= bidirectional LSPs are concerned, G-ACh Type =3D 7 is as good as G-A= Ch Type =3D 22?

 

As for ability to deduce from receiving something with G-ACh Type= =3D 22 that you should be also reqdy to receive something with= G-ACh Type =3D 23 (CV), I do not think that this is explicitly speci= fied anywhere. From my point of view, ability to support CV MUST be explicitly synchronized between the LSP endpoints (by= configuration or signaling).

 

My 2c,

     Sasha

From: Gregory Mirsky [gregory.mirsky@ericsso= n.com]
Sent: Wednesday, July 11, 2012 5:37 PM
To: Alexander Vainshtein; David Allan I; swallow@cisco.com; jdrake@ju= niper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: RE: [mpls] Doubts in allocation of a new G-ACH type for

 
Dear Sasha, et al.,
I think that one of differences between CC defined in RFC 5885 and RFC 6428 in introduct= ion of independent mode to monitor associated bi-directional p2p connections= . Then there's FSMs fo coordinated and independent modes, Fig.7 and Fig.8 in= RFC 6428, that are different from FSM of RFC 5880. Then, IMHO, using G-ACh from RFC 6428 indicates possi= ble use of RFC 6428-based CV while there's no CV for neither Control Channel= 0x07.
 
    Regards,
        Greg

From: mpls-bounces@ietf.org [mailto:= mpls-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: mpls@ietf.org; Mishael Wexler; tnadeau@juniper.net; pwe3 (pwe3@ie= tf.org); Rotem Cohen
Subject: [mpls] Doubts in allocation of a new G-ACH type for

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized =93may=94 and not one of the IETF reserved requirement level wo= rds.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A4F2FRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Wed Jul 11 21:58:14 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76B021F8628; Wed, 11 Jul 2012 21:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+6WJK9GA4ni; Wed, 11 Jul 2012 21:58:13 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 10DA821F8630; Wed, 11 Jul 2012 21:58:11 -0700 (PDT) Received: from [85.158.143.99:38123] by server-1.bemta-4.messagelabs.com id 6C/02-24392-3895EFF4; Thu, 12 Jul 2012 04:58:43 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1342069123!20852986!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 7571 invoked from network); 12 Jul 2012 04:58:43 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-11.tower-216.messagelabs.com with SMTP; 12 Jul 2012 04:58:43 -0000 X-AuditID: a8571403-b7eff6d000003899-4b-4ffe5974d60b Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 97.78.14489.4795EFF4; Thu, 12 Jul 2012 06:58:28 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 12 Jul 2012 06:58:42 +0200 From: Alexander Vainshtein To: David Allan I Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAK655QAAJsTPwAADHVYAAXivAU Date: Thu, 12 Jul 2012 04:58:40 +0000 Message-ID: References: , <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> , <60C093A41B5E45409A19D42CF7786DFD53BC065985@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: <60C093A41B5E45409A19D42CF7786DFD53BC065985@EUSAACMS0703.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.2] Content-Type: multipart/alternative; boundary="_000_F9336571731ADE42A5397FC831CEAA0209A529FRIDWPPMB001ecite_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTa2wMURjtndndTqvD2FZ7LdLJReKRXVslWWpL0pDSsIJQfmDsXrvD7sxm ZzQqxEaIRrwjaZRQtLQ0bdpqtKhHJWjFaiUeWTSkRVSapqIexTJjVjUR99e53zn3O+fOfJci jQdjTRQvyDggcF5kiNfFgxiTWV4ZcVjvdKTaXj24RNrCpeV62/4PF3VzyOz+vkeG7JKSr8Ri YlUQzOIEQZQ5GbMuLDntaHGAz+Oc+YjlXXaUhli/l3NiHxZkO+L8fiy4UGY8+8+apch4gcWC U3TxgtuO5i91mG226TPMaShzmYeXWGz2cbyX9WFJ4tyYVSpqZMG1tpL0HKv8TPiP7QSbP9SF yCD4JO4BcRRkpsG+W291Gk6Gre1Vhj0gnjIyLQDefv4TaJsSACM3umJVlYGxw5oLLwwqTmIs sKLtm17FJJMDI9dbSRUnMjNh4a7uqCYDnu7rJTU8D75pLvqt1zHjYbDnnFKnKJpZCBs6o8bl BDwdKiTUehyTCwt/DlHlQAn3uaWC0KxSYLjzJKGFZmDJ1QekhkfAdx0RvYZTYW1dRzSaCJ9+ K/itp5nhsPloZ/TCI+HNsqe6gyC5aFDbokFHigYd0epW2BM6SWp4Mjx76n0UT4HVH++DwfVi EHsewPUB3uX150nrrNZ0C3byMvZii1P01QBliMpWJJH14OMBSxNgKIAS6PrKHw6jnsuT8n1N YCRFoBH0ytyIwzh0nejK93CSZ01gkxdLTQBSJEqip2YpHO3i8rfggPiHmqt820OkaYhTVP+9 vCbdav3/BqXQVUsyHUbGrUznRoz9OPCnz2iKQpB+rNoPD2A33rye98p/aYKKU2MkKDGaVQ0t +TmfxLs1vgVMpo6/DYcBdaaxPQyMOkEUsCmFLlaljCr1bBIGunWBFOX6iXSNyiYoMzvQp0ux IBSL4tLvqoXyhgYoUxAIV448/9rdeN6yNTS6oOFZ946z+ruXHn7fltgy0TilKiY0e1F3Y38O Weirztn+clv16kcVCwoOjU1+PYF9siH7BWssTZ02fVzPqKuHbzWgMZ/Sr3lnJF1+2dOWtby9 t2xvq73cfDHj3rB9GVn1uTEou6627qiUW9r3ZeH73ftPTDLIwe1IJ3m4tElkQOJ+AY8e+Rwj BAAA Cc: "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 04:58:15 -0000 --_000_F9336571731ADE42A5397FC831CEAA0209A529FRIDWPPMB001ecite_ Content-Type: text/plain; charset="Windows-1252" content-transfer-encoding: quoted-printable Dave, Lots of thanks for a prompt response. My reading of this response is like fo= llowing: 1. If you are only interested in CC but do not use CV functionality, use= G-ACH type =3D 7 (from RFC 5885). 2. If you are interested in CC and CV interleaved, use G-ACH type =3D 22= for CC and G-ACH type =3D 23 for CV. 3. If the session has been brought up using G-ACH type =3D 7, any receive= d CV messages MUST be ignored. 4. If the session has been set up with G-ACH Type =3D 22 but no CV messag= es have ever been received, no defect is detected and hence no consequent ac= tion is taken. Did I miss something? If this reading is correct, how could it become common? As I see it, the cur= rent situation creates ample opportunities for interoperability problems. Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, July 11, 2012 7:21 PM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3 (pwe3@ietf.org) Subject: RE: Doubts in allocation of a new G-ACH type for Hi Sasha: cc list trimmed.... I'm sorry, I'm not quite grasping your point. We need to know when CC will not have CV interleaved. We need to know when CC will have CV interleaved. We need to know when a CV TLV will be present. Ergo 3 code points. Could you clarify your concern? Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:18 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf.= org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Dave, Lots of thanks for a prompt response. Unfortunately I have to say that it is confusing: interleave of CC and CV pa= ckets on the same stream is achieved by using a different G-ACh type for CV= messages. This type discriminates between CC and CV messages equally well f= or any of the two G-ACh types that potentially could be used for carrying CC= messages. Do I miss something fundamental? Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, July 11, 2012 6:07 PM To: Alexander Vainshtein; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf.= org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Hi Sasha: The reason for this is the overall system behavior implied. A 5885 code poin= t is purely CC operation. A 6428 code point indicates that CV will be interl= eaved with the stream. We wanted to explicitly disambiguate this. It further permits misbranching of a 5885 stream into a 6428 path to be dete= cted so the overall network is more robust. If the CC messages in both 5885= and 6428 had a common code point, this would not be possible, and CV operat= ion would not be authoritative. I hope this helps Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf.= org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mess= age in RFC 6428. Looking at both this RFC and RFC 5885, i= t seems that the format of the MPLS-TP CC packet and the format of the raw B= FD packet in VCCV is exactly the same. However, two different G-ACH types ha= ve been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, es= pecially with progress of the new VCCV Type (using GAL) for PWs. The text in= Section 3.1 of 6428 that refers to existing capability to run BFD over LSP= with the G-ACh using Channel Type 7 only adds to the confusion IMO, since i= t uses un-capitalized =93may=94 and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. --_000_F9336571731ADE42A5397FC831CEAA0209A529FRIDWPPMB001ecite_ Content-Type: text/html; charset="Windows-1252" content-transfer-encoding: quoted-printable

Dave,

Lots of thanks for a prompt response. My reading of this response is like= following:

  1. If you are only interested in CC but do not use CV functionality, use G-= ACH type =3D 7 (from RFC 5885).
  2. If you are interested in CC and CV interleaved, use G-ACH type =3D= 22 for CC and G-ACH type =3D 23 for CV.
  3. If the session has been brought up using G-ACH type =3D 7, any rece= ived CV messages MUST be ignored.
  4. If the session has been set up with G-ACH Type =3D 22 but no CV mes= sages have ever been received, no defect is detected and hence no consequent= action is taken.

Did I miss something?

 

If this reading is correct, how could it become common? As I see it, the= current situation creates ample opportunities for interoperability problems= .

 

Regards,

     Sasha

 

 

 

 

From: David Allan= I [david.i.allan@ericsson.com]
Sent: Wednesday, July 11, 2012 7:21 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; pwe3 (pwe3@ietf.org)
Subject: RE: Doubts in allocation of a new G-ACH type for

Hi Sasha:
 
cc list trimmed....
 
I'm sorry, I'm not quite grasping your point.
 
We need to know when CC will not have CV interleaved.
We need to know when CC will have CV interleaved.
We need to know when a CV TLV will be present.
 
Ergo 3 code points. Could you clarify your concern?
Dave

From: Alexander Vainshtein [mailto:A= lexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 10:18 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe= 3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

Dave,

Lots of thanks for a prompt response.

 

Unfortunately I have to say that it is confusing: interleave of CC and CV= packets on the same stream is achieved by using a different G-ACh= type for CV messages. This type discriminates between CC and CV message= s equally well for any of the two G-ACh types that potentially could be used fo= r carrying CC messages.

 

Do I miss something fundamental?

 

Regards,

     Sasha 

From: David Allan I [david.i.allan@ericsson.= com]
Sent: Wednesday, July 11, 2012 6:07 PM
To: Alexander Vainshtein; swallow@cisco.com; jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe= 3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for

Hi Sasha:
 
The reason for this is the overall system behavior implied. A= 5885 code point is purely CC operation. A 6428 code point indicates that CV= will be interleaved with the stream. We wanted to explicitly disambiguate this.
 
It further permits misbranching of a 5885 stream into a 6428 p= ath to be detected so the overall network is more robust. If the CC messages= in both 5885 and 6428 had a common code point, this would not be possible, and CV operation would not be authoritat= ive.
 
I hope this helps
Dave

From: Alexander Vainshtein [mailto:A= lexander.Vainshtein@ecitele.com]
Sent: Wednesday, July 11, 2012 3:51 AM
To: David Allan I; swallow@cisco.com; jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe= 3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael Wexler
Subject: Doubts in allocation of a new G-ACH type for

Hi all,

I have doubts regarding allocation of the G-ACH type= for the MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, it seems that the format of the MPLS-TP CC packet and the form= at of the raw BFD packet in VCCV is exactly the same. However, two different= G-ACH types have been allocated by IANA for these two cases.

 

IMHO and FWIW such duplication can only create intero= perability problems, especially with progress of the new VCCV Type (using GA= L) for PWs. The text in Section 3.1 of 6428 that refers to existing capabili= ty to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the confusion IMO, since it uses un= -capitalized =93may=94 and not one of the IETF reserved requirement level wo= rds.

 

Clarification of intentions by the editors of RFC 642= 8 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If= you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof.

--_000_F9336571731ADE42A5397FC831CEAA0209A529FRIDWPPMB001ecite_-- From Alexander.Vainshtein@ecitele.com Thu Jul 12 08:12:17 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3197821F87BA for ; Thu, 12 Jul 2012 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.28 X-Spam-Level: X-Spam-Status: No, score=-5.28 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3eKY8mR3o-XG for ; Thu, 12 Jul 2012 08:12:14 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id 7448521F87BC for ; Thu, 12 Jul 2012 08:12:13 -0700 (PDT) X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-27.messagelabs.com!1342105962!8967672!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 12973 invoked from network); 12 Jul 2012 15:12:43 -0000 Received: from unknown (HELO fridlpvsb003.ecitele.com) (168.87.1.157) by server-3.tower-27.messagelabs.com with SMTP; 12 Jul 2012 15:12:43 -0000 X-AuditID: a8571403-b7eff6d000003899-1c-4ffee95c0ede Received: from FRIDWPPCH001.ecitele.com (Unknown_Domain [10.1.16.52]) by fridlpvsb003.ecitele.com (Symantec Messaging Gateway) with SMTP id 0A.B8.14489.C59EEFF4; Thu, 12 Jul 2012 17:12:28 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH001.ecitele.com ([10.1.16.52]) with mapi id 14.01.0339.001; Thu, 12 Jul 2012 17:12:41 +0200 From: Alexander Vainshtein To: "jmedved@cisco.com" , "dmm@cisco.com" , "amclachl@cisco.com" Thread-Topic: I-D Action: draft-medved-pwe3-of-config-01.txt Thread-Index: AQHNXyPoTOcM0MAQFEm4M8vD4MnHUZclvAsQ Date: Thu, 12 Jul 2012 15:12:41 +0000 Message-ID: References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com> In-Reply-To: <20120711051239.19562.70082.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.224.134] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA2VTWUwTQRh2dtuyYNesBe1QMW42GoMKKaKxKsXjRYyY4hWjYnBph3Zju212 C1ITI4mgkSjiGeVBOQriASjhgXgF8UaNRg2iESQC8XppKgYv0FlWEeM8ffN///d9M7P/UqSh T2eiBNGPJJF3c7ooTRQYY0rIfD9kMx87GW3p7C4mLN1dTTrLvu/PSEtJuEljCRV/0S7Wph35 flGbFgx+JdIO1eVkkBsLQAovil4/70esA8l2K5chCXm8PcCxgsPKJXGsz83bkQeJfivH+3xI dHCpUex/KwW3CSKLRLvXIYhOK7d8jS3BYpk7PyGJS13rEmQWJXh4wc16kCzzTsTiinIB0bGl nnQ17f0R4Sudnj/4OUgUgHuTi0EkBZk58Hj4tk7FE+HjrgaMoygD0wbgt4e1hEIYmCCAb/vz FaxjrLDxXOewIIYJwDvf3kQomGSyYfXTAaDgaGYhLNnVQ6g9KXAoFNKqeDY8fOjWcF3DTIP3 +8LDPjSzEhZdasI+FM5aAj82pCvlSGYpLH93dNgS4LMNtJ0n1CgjfNl7ilDPzMDglUekiifA 9z1DWhWzsLKwWaf2z4Lll8O/8UxYU/GRVGPHw3snejVqfyy8XtuhKQXGslERZaPkZaPkZaPk 5UBzFsAcSXC4fXlyttmcnIjsgh+5UaLd62kEeHBq18eQzaD/QGIrYCjA6enm+kGbQcvnyQFP K4ilCG4CPb1vyGYYl+11BFy87MqSct1IbgWQIrkYelk75mgHH9iOJO8fyoLf8CBpGmv3Kl/Y n5VsNv+z4Yx0w+pUm4Fx4rHbipAPSX+kcRTFQfrCO+w6XkJOlJ8juP1/aYKKVJL1OLlC6aFl H++RBafKt4FYk5HOVAhGIVy54oj2AzDi+0XT1Qqrx6M3ovqADQlsWF79QzHEv8IIZSoAhvTd fZ1fSicj/Y0xcVN2rH21WQoGrC0bTfGvZ0T0t92Mb3ky71W8J7RuoLdu1d4T9IpNcTHX91eZ Fw7S7SUdVYsCC35uqwllJS4uKlm3ZWf19ujntVflmqIXuj1P6QddZ7aG1xy4kMucfnm34Frh nandk+ZU7ltQtMxVGJHzSd9o2LGB08guPmkGKcn8L+527xL4AwAA Cc: "Yaakov Stein \(yaakov_s@rad.com\)" , "pwe3 \(pwe3@ietf.org\)" Subject: [PWE3] FW: I-D Action: draft-medved-pwe3-of-config-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:12:17 -0000 Hi all, I've looked up a new version of the draft and I have several issues with the= proposed mode of operation as described in Figure 4 in Section 2.1: A packet initially arrives at the AC with the following headers and payload. This packet becomes the PW payload. \ - PW payload / Next, the iPProc adds the Transport header. \ - PW payload - Transport header The Virtual OF switch then pushes on PW label with S=3D1. \ - PW payload / - PW label - Transport header Finally, the oPProc pushes the Transport label and switches the packet onto the Transport LSP. \ - PW payload / - PW label - Transport label - Transport header Figure 4: Input Encapsulation Sequence It is further explained in the beginning of Section 2.1 that : The iPProc encapsulates arriving packets on the Attachment Circuit in the o= uter transport (Ethernet) header. This is required because OpenFlow can only push MPLS labels onto the top of= a label stack encapsulated in an existing Ethernet header. The problem (as I see it) is that "the outer transport (Ethernet) header" MU= ST match the egress port (SA) and Next Hop LSR (DA) in order for the MPLS da= ta plane to operate properly. I.e., the OF switch-based model of the PW endpoint proposed in the draft imp= lies that it must be reconfigured every time the egress port and/or the Next= Hop LSR change (e.g., in a protection switch). As I have already mentioned= in my comments on the -00 version of the draft such behavior does not scale= up. The scalability problem of the proposed model do not end here. The draft sti= ll seems to consider per-PW OAM engines as generators of triggers for protec= tion switching. Just mentioning that The OAM function for Transport LSPs is out of scope for this revision of this document. However, PW-OAM mechanisms described in this document could also applicable to Transport LSP-OAM. and Note that in addition to the OAM Engine, the Virtual OF Switch MAY use other liveness monitoring mechanisms for the virtual port Fast Failover groups, which are out of scope of this document. is not really helpful. I am pretty near ignorant with regard to OpenFlow, but I wonder whether a di= fferent model of the PW endpoint that better agrees with the PWE3 architectu= re (which, as per RFC 3985, clearly distinguishes between PW endpoints and PSN= tunnels) could be created? IMHO and FWIW, without such a model using OpenFlow for control of PW endpoin= ts would be highly problematic. My 2c, Sasha -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] O= n Behalf Of internet-drafts@ietf.org Sent: Wednesday, July 11, 2012 8:13 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-medved-pwe3-of-config-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. Title : MPLS-TP Pseudowire Configuration using OpenFlow 1.3 Author(s) : Jan Medved Andrew McLachlan David Meyer Filename : draft-medved-pwe3-of-config-01.txt Pages : 20 Date : 2012-07-10 Abstract: This document describes a method by which MPLS-TP Pseudowires (PW) can be configured in an LER using OpenFlow 1.3. In addition to the configuration of PWs this document also specifies how to enact OAM for these PWs using standard IETF conventions defined by the GAL label method. The primary goal of this document is to provide a simple and yet flexible method for configuring PWs using standardized tools from the emerging SDN toolkit. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-medved-pwe3-of-config There's also a htmlized version available at: http://tools.ietf.org/html/draft-medved-pwe3-of-config-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-medved-pwe3-of-config-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From amalis@gmail.com Thu Jul 12 08:13:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12E821F8666 for ; Thu, 12 Jul 2012 08:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.343 X-Spam-Level: X-Spam-Status: No, score=-103.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDQBXlNnTXqD for ; Thu, 12 Jul 2012 08:13:23 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 87AB421F864B for ; Thu, 12 Jul 2012 08:13:21 -0700 (PDT) Received: by yenq13 with SMTP id q13so2739957yen.31 for ; Thu, 12 Jul 2012 08:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=z/CBP5vst/X9ks6JKt9Nq5ELd6/yOZPORTsrKS3Lrco=; b=dtybT1OlZ6JOlhEO1dF89V54MFwp51gI98w3nMFmwqI0NuGkTqmQMLs4BLF5pKb23g BNsa2u6hUaAmmg4SyjbnuVraSxN+sEPK3arNzbyk/eVHwCZU9VAst1yLKb7G3u32J6H3 /Zh5XSXpHf/8YIbZKxubh48Xr2cUCEYBkCPk1nTxFixKBpRsSR9CZ1QN/kSZ2/ewVWB6 WeFtOxBBLEjNLUKhLbZ6iW/b8cx3NNxwYm5A2Y4UcWL/vKvChQGCjylIFAelh9bImPOP UmF7lMpUyKbVurKNtzN9ekw+3cSyAPue7mHkAaHjK1ohJFPEd1JzDp6kEW2qknaZDAtp lSMw== Received: by 10.66.88.68 with SMTP id be4mr90756355pab.23.1342106034475; Thu, 12 Jul 2012 08:13:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.45.9 with HTTP; Thu, 12 Jul 2012 08:13:34 -0700 (PDT) From: "Andrew G. Malis" Date: Thu, 12 Jul 2012 11:13:34 -0400 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: Martin Stiemerling Subject: [PWE3] ITU-T liaison of interest to pwe3 on QoS mappings between Ethernet, IP, and MPLS X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 15:13:25 -0000 pwe3 wg, I would like to call your attention to a liaison from ITU-T SG12 on a new draft ITU-T Recommendation, Y.1566, on =93QoS mapping and interworking between Ethernet, IP and MPLS=94. This Recommendation intends to simplify Ethernet, MPLS and IP QoS interconnection negotiations. The liaison can be found at https://datatracker.ietf.org/liaison/1165/ . The tsvwg will be taking the lead on generating a response to the liaison. Discussion and comments on this liaison will take place on the tsvwg list. Thanks, Andy From tnadeau@juniper.net Wed Jul 11 11:42:56 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A35E11E80EF; Wed, 11 Jul 2012 11:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPICM64o35EA; Wed, 11 Jul 2012 11:42:55 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6F011E80DB; Wed, 11 Jul 2012 11:42:52 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT/3JR9NUXHa0q1wI4Wxx16WwTSZ6DcWN@postini.com; Wed, 11 Jul 2012 11:43:26 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 11 Jul 2012 11:41:03 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Wed, 11 Jul 2012 14:41:02 -0400 From: Thomas Nadeau To: John E Drake Date: Wed, 11 Jul 2012 14:40:58 -0400 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1flLhm14+iYO1cQMyTU5OPosWnow== Message-ID: <13CD53A9-978D-413C-8D53-A0517D6B62DE@juniper.net> References: <5E893DB832F57341992548CDBB333163A5A82A4B7A@EMBX01-HQ.jnpr.net> <5E893DB832F57341992548CDBB333163A5A82A4D88@EMBX01-HQ.jnpr.net> In-Reply-To: <5E893DB832F57341992548CDBB333163A5A82A4D88@EMBX01-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 12 Jul 2012 08:14:31 -0700 Cc: "swallow@cisco.com" , "cpignata@cisco.com" , "mpls@ietf.org" , Andrew Sergeev , Mishael Wexler , "pwe3 \(pwe3@ietf.org\)" , Rotem Cohen Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 18:42:56 -0000 DQoNCg0KDQpPbiBKdWwgMTEsIDIwMTIsIGF0IDExOjMwIEFNLCAiSm9obiBFIERyYWtlIiA8amRy YWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+PiB3cm90ZToNCg0KU2Fz aGEsDQoNCk9vcHNpZS4NCg0KRG9lc27igJl0IFJGQyA1ODg1ICBkZXNjcmliZSB0aGUgdXNlIG9m IEJGRCBmb3IgcHNldWRvd2lyZSBWQ0NWPw0KDQp5ZXMNCg0KVG9tDQoNCk90aGVyIHRoYW4gdGhl IGluZGVwZW5kZW50IG1vZGUgdGhhdCBHcmVnIG1lbnRpb25lZCwgIFJGQyA2NDI4IGlzIGp1c3Qg c3RhbmRhcmQgQkZEIGJ1dCBpdCBpcyBmb3IgYW4gTFNQIHJhdGhlciB0aGFuIGEgcHNldWRvd2ly ZS4gIE9yIGRpZCBJIG1pc3Mgc29tZXRoaW5nIDgtPj8NCg0KVGhhbmtzLA0KDQpKb2huDQoNClNl bnQgZnJvbSBteSBpUGhvbmUNCg0KRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gW21haWx0bzpB bGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAx MSwgMjAxMiAxMDoxMyBBTQ0KVG86IEpvaG4gRSBEcmFrZTsgZGF2aWQuaS5hbGxhbkBlcmljc3Nv bi5jb208bWFpbHRvOmRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tPjsgc3dhbGxvd0BjaXNjby5j b208bWFpbHRvOnN3YWxsb3dAY2lzY28uY29tPg0KQ2M6IGNwaWduYXRhQGNpc2NvLmNvbTxtYWls dG86Y3BpZ25hdGFAY2lzY28uY29tPjsgVGhvbWFzIE5hZGVhdTsgbXBsc0BpZXRmLm9yZzxtYWls dG86bXBsc0BpZXRmLm9yZz47IHB3ZTMgKHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5v cmc+KTsgUm90ZW0gQ29oZW47IEFuZHJldyBTZXJnZWV2OyBNaXNoYWVsIFdleGxlcg0KU3ViamVj dDogUkU6IERvdWJ0cyBpbiBhbGxvY2F0aW9uIG9mIGEgbmV3IEctQUNIIHR5cGUgZm9yDQoNCg0K Sm9obiwNCg0KTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IHJlc3BvbnNlLg0KDQoNCg0KVW5m b3J0dW5hdGVseSBpdCBkb2VzIG5vdCBhZGRyZXNzIG15IHF1ZXN0aW9uIHdoaWNoIHJlZmVycmVk IHRvIENDIG9wZXJhdGlvbiBvbmx5LiBJdCBkb2VzIG5vdCBpbnZvbHZlIENWIG9wZXJhdGlvbiB3 aGljaCBpbmRlZWQgcmVxdWlyZXMgaXRzIG93biBkZWRpY2F0ZWQgRy1BQ2ggdHlwZS4NCg0KDQoN CkJ1dCBDQyAoYW5kIFJESSkgb3BlcmF0aW9uIHNlZW1zIHRvIGJlIGV4YWN0bHkgdGhlIHNhbWUg aW4gUkZDIDY0MjggYW5kIFJGQyA1ODg1Lg0KDQoNCg0KT3IgZG8gSSBtaXNzIHNvbWV0aGluZz8N Cg0KDQoNClJlZ2FyZHMsDQoNCiAgICAgU2FzaGENCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkZyb206IEpvaG4gRSBEcmFrZSBbamRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpq ZHJha2VAanVuaXBlci5uZXQ+XQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDExLCAyMDEyIDY6MjQg UE0NClRvOiBBbGV4YW5kZXIgVmFpbnNodGVpbjsgZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb208 bWFpbHRvOmRhdmlkLmkuYWxsYW5AZXJpY3Nzb24uY29tPjsgc3dhbGxvd0BjaXNjby5jb208bWFp bHRvOnN3YWxsb3dAY2lzY28uY29tPg0KQ2M6IGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3Bp Z25hdGFAY2lzY28uY29tPjsgVGhvbWFzIE5hZGVhdTsgbXBsc0BpZXRmLm9yZzxtYWlsdG86bXBs c0BpZXRmLm9yZz47IHB3ZTMgKHB3ZTNAaWV0Zi5vcmc8bWFpbHRvOnB3ZTNAaWV0Zi5vcmc+KTsg Um90ZW0gQ29oZW47IEFuZHJldyBTZXJnZWV2OyBNaXNoYWVsIFdleGxlcg0KU3ViamVjdDogUkU6 IERvdWJ0cyBpbiBhbGxvY2F0aW9uIG9mIGEgbmV3IEctQUNIIHR5cGUgZm9yDQpTYXNoYSwNCg0K VGhlIEJGRCBwYWNrZXQgZm9ybWF0IGlzIHRoZSBzYW1lIGZvciBib3RoIENDIGFuZCBDVi4gIFRo ZSAgcmVhc29uIGZvciBoYXZpbmcgdHdvIGNvZGUgcG9pbnRzIGlzIHRvIGluZGljYXRlIHRvIHRo ZSByZWNlaXZlciB3aGV0aGVyIHRoZXJlIGlzIGEgdHJhaWxpbmcgc291cmNlIElEIFRMViwgaW4g d2hpY2ggY2FzZSB0aGUgcGFja2V0IGlzIHRvIGJlIHVzZWQgZm9yIENWIHJhdGhlciB0aGFuIEND Lg0KDQpUaGFua3MsDQoNCkpvaG4NCg0KU2VudCBmcm9tIG15IGlQaG9uZQ0KDQpGcm9tOiBBbGV4 YW5kZXIgVmFpbnNodGVpbiBbbWFpbHRvOkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29t XQ0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDExLCAyMDEyIDM6NTEgQU0NClRvOiBkYXZpZC5pLmFs bGFuQGVyaWNzc29uLmNvbTxtYWlsdG86ZGF2aWQuaS5hbGxhbkBlcmljc3Nvbi5jb20+OyBzd2Fs bG93QGNpc2NvLmNvbTxtYWlsdG86c3dhbGxvd0BjaXNjby5jb20+OyBKb2huIEUgRHJha2UNCkNj OiBjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT47IFRob21hcyBO YWRlYXU7IG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBwd2UzIChwd2UzQGll dGYub3JnPG1haWx0bzpwd2UzQGlldGYub3JnPik7IFJvdGVtIENvaGVuOyBBbmRyZXcgU2VyZ2Vl djsgTWlzaGFlbCBXZXhsZXINClN1YmplY3Q6IERvdWJ0cyBpbiBhbGxvY2F0aW9uIG9mIGEgbmV3 IEctQUNIIHR5cGUgZm9yDQoNCkhpIGFsbCwNCkkgaGF2ZSBkb3VidHMgcmVnYXJkaW5nIGFsbG9j YXRpb24gb2YgdGhlIEctQUNIIHR5cGUgZm9yIHRoZSBNUExTLVRQIENDIG1lc3NhZ2UgaW4gUkZD IDY0Mjg8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjQyOD4uDQoNCkxvb2tpbmcgYXQg Ym90aCB0aGlzIFJGQyBhbmQgUkZDIDU4ODU8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTg4NT4sIGl0IHNlZW1zIHRoYXQgdGhlIGZvcm1hdCBvZiB0aGUgTVBMUy1UUCBDQyBwYWNrZXQg YW5kIHRoZSBmb3JtYXQgb2YgdGhlIHJhdyBCRkQgcGFja2V0IGluIFZDQ1YgaXMgZXhhY3RseSB0 aGUgc2FtZS4gSG93ZXZlciwgdHdvIGRpZmZlcmVudCBHLUFDSCB0eXBlcyBoYXZlIGJlZW4gYWxs b2NhdGVkIGJ5IElBTkEgZm9yIHRoZXNlIHR3byBjYXNlcy4NCg0KSU1ITyBhbmQgRldJVyBzdWNo IGR1cGxpY2F0aW9uIGNhbiBvbmx5IGNyZWF0ZSBpbnRlcm9wZXJhYmlsaXR5IHByb2JsZW1zLCBl c3BlY2lhbGx5IHdpdGggcHJvZ3Jlc3Mgb2YgdGhlIG5ldyBWQ0NWIFR5cGUgKHVzaW5nIEdBTCkg Zm9yIFBXcy4gVGhlIHRleHQgaW4gU2VjdGlvbiAzLjEgb2YgNjQyOCB0aGF0IHJlZmVycyB0byBl eGlzdGluZyBjYXBhYmlsaXR5IHRvIHJ1biBCRkQgb3ZlciBMU1Agd2l0aCB0aGUgRy1BQ2ggdXNp bmcgQ2hhbm5lbCBUeXBlIDcgb25seSBhZGRzIHRvIHRoZSBjb25mdXNpb24gSU1PLCBzaW5jZSBp dCB1c2VzIHVuLWNhcGl0YWxpemVkIOKAnG1heeKAnSBhbmQgbm90IG9uZSBvZiB0aGUgSUVURiBy ZXNlcnZlZCByZXF1aXJlbWVudCBsZXZlbCB3b3Jkcy4NCg0KQ2xhcmlmaWNhdGlvbiBvZiBpbnRl bnRpb25zIGJ5IHRoZSBlZGl0b3JzIG9mIFJGQyA2NDI4IChhbmQvb3Igb2YgUkZDIDU4ODUpIHdv dWxkIGJlIGhpZ2hseSBhcHByZWNpYXRlZC4NCg0KUmVnYXJkcywNCiAgICAgU2FzaGENCg0KDQpU aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5k IGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5 IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25l IG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNvcGllcyB0aGVy ZW9mLg0KDQpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50 IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIENPTkZJREVOVElBTCBhbmQg d2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1h aWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYWxsIGNv cGllcyB0aGVyZW9mLg0K From david.i.allan@ericsson.com Thu Jul 12 10:29:05 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1D011E80C7; Thu, 12 Jul 2012 10:29:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvKO-M4HV1DX; Thu, 12 Jul 2012 10:29:01 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 2D41C21F8453; Thu, 12 Jul 2012 10:29:01 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6CHTJ8x025534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Jul 2012 12:29:24 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.11]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 12 Jul 2012 13:29:19 -0400 From: David Allan I To: Alexander Vainshtein Date: Thu, 12 Jul 2012 13:29:18 -0400 Thread-Topic: Doubts in allocation of a new G-ACH type for Thread-Index: Ac1fUxknWPfc/Fv5TJmTM15xHce7WgAK655QAAJsTPwAADHVYAAXivAUABrdTJA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD53BC0662D0@EUSAACMS0703.eamcs.ericsson.se> References: , <60C093A41B5E45409A19D42CF7786DFD53BC0658B4@EUSAACMS0703.eamcs.ericsson.se> , <60C093A41B5E45409A19D42CF7786DFD53BC065985@EUSAACMS0703.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD53BC0662D0EUSAACMS0703e_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "pwe3 \(pwe3@ietf.org\)" Subject: Re: [PWE3] Doubts in allocation of a new G-ACH type for X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2012 17:29:05 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD53BC0662D0EUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI Sasha: You are correct in noting that there is no representation in the RFC for re= quiring any sort timer associated with CV PDU reception (it only discusses = send interval), which means a non-compliant implementation sending CVs coul= d operate undetected by an implementation that made no measurement at all o= f reception of CVs and if it misbranched into a different LSP, would not be= detected. Another LSP running CV leaking into the LSP served by the non-compliant imp= lementation would still be detected. Well spotted! Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 9:59 PM To: David Allan I Cc: mpls@ietf.org; pwe3 (pwe3@ietf.org) Subject: RE: Doubts in allocation of a new G-ACH type for Dave, Lots of thanks for a prompt response. My reading of this response is like f= ollowing: 1. If you are only interested in CC but do not use CV functionality, use = G-ACH type =3D 7 (from RFC 5885). 2. If you are interested in CC and CV interleaved, use G-ACH type =3D 22 = for CC and G-ACH type =3D 23 for CV. 3. If the session has been brought up using G-ACH type =3D 7, any receive= d CV messages MUST be ignored. 4. If the session has been set up with G-ACH Type =3D 22 but no CV messag= es have ever been received, no defect is detected and hence no consequent a= ction is taken. Did I miss something? If this reading is correct, how could it become common? As I see it, the cu= rrent situation creates ample opportunities for interoperability problems. Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, July 11, 2012 7:21 PM To: Alexander Vainshtein Cc: mpls@ietf.org; pwe3 (pwe3@ietf.org) Subject: RE: Doubts in allocation of a new G-ACH type for Hi Sasha: cc list trimmed.... I'm sorry, I'm not quite grasping your point. We need to know when CC will not have CV interleaved. We need to know when CC will have CV interleaved. We need to know when a CV TLV will be present. Ergo 3 code points. Could you clarify your concern? Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 10:18 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Dave, Lots of thanks for a prompt response. Unfortunately I have to say that it is confusing: interleave of CC and CV p= ackets on the same stream is achieved by using a different G-ACh type for C= V messages. This type discriminates between CC and CV messages equally well= for any of the two G-ACh types that potentially could be used for carrying= CC messages. Do I miss something fundamental? Regards, Sasha ________________________________ From: David Allan I [david.i.allan@ericsson.com] Sent: Wednesday, July 11, 2012 6:07 PM To: Alexander Vainshtein; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: RE: Doubts in allocation of a new G-ACH type for Hi Sasha: The reason for this is the overall system behavior implied. A 5885 code poi= nt is purely CC operation. A 6428 code point indicates that CV will be inte= rleaved with the stream. We wanted to explicitly disambiguate this. It further permits misbranching of a 5885 stream into a 6428 path to be det= ected so the overall network is more robust. If the CC messages in both 588= 5 and 6428 had a common code point, this would not be possible, and CV oper= ation would not be authoritative. I hope this helps Dave ________________________________ From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] Sent: Wednesday, July 11, 2012 3:51 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net Cc: cpignata@cisco.com; tnadeau@juniper.net; mpls@ietf.org; pwe3 (pwe3@ietf= .org); Rotem Cohen; Andrew Sergeev; Mishael Wexler Subject: Doubts in allocation of a new G-ACH type for Hi all, I have doubts regarding allocation of the G-ACH type for the MPLS-TP CC mes= sage in RFC 6428. Looking at both this RFC and RFC 5885, = it seems that the format of the MPLS-TP CC packet and the format of the raw= BFD packet in VCCV is exactly the same. However, two different G-ACH types= have been allocated by IANA for these two cases. IMHO and FWIW such duplication can only create interoperability problems, e= specially with progress of the new VCCV Type (using GAL) for PWs. The text = in Section 3.1 of 6428 that refers to existing capability to run BFD over L= SP with the G-ACh using Channel Type 7 only adds to the confusion IMO, sinc= e it uses un-capitalized "may" and not one of the IETF reserved requirement= level words. Clarification of intentions by the editors of RFC 6428 (and/or of RFC 5885)= would be highly appreciated. Regards, Sasha This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. --_000_60C093A41B5E45409A19D42CF7786DFD53BC0662D0EUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
HI=20 Sasha:
 
You=20 are correct in noting that there is no representation in the RFC for requir= ing=20 any sort timer associated with CV PDU reception (it only discusses sen= d=20 interval), which means a non-compliant implementation sending CVs=20 could operate undetected by an implementation that made no measurement= at=20 all of reception of CVs and if it misbranched into a different LSP, would n= ot be=20 detected.
 
Another LSP running CV leaking into the LSP served by the=20 non-compliant implementation would still be detected.
 
Well=20 spotted!
Dave
 
 

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July = 11,=20 2012 9:59 PM
To: David Allan I
Cc: mpls@ietf.org; pwe3= =20 (pwe3@ietf.org)
Subject: RE: Doubts in allocation of a new G-ACH = type=20 for

Dave,

Lots of thanks for a prompt response. My reading of this response is lik= e=20 following:

  1. If you are only interested in CC but do not use CV functionality, use= =20 G-ACH type =3D 7 (from RFC 5885).=20
  2. If you are interested in CC and CV interleaved, use G-ACH type =3D 22= for CC=20 and G-ACH type =3D 23 for CV.=20
  3. If the session has been brought up using G-ACH type =3D 7, any receiv= ed CV=20 messages MUST be ignored.=20
  4. If the session has been set up with G-ACH Type =3D 22 but no CV messa= ges=20 have ever been received, no defect is detected and hence no consequent ac= tion=20 is taken.

Did I miss something?

 

If this reading is correct, how could it become common? As I see it, the= =20 current situation creates ample opportunities for interoperability problems= .

 

Regards,

     Sasha

 

 

 

 

From:= David Allan=20 I [david.i.allan@ericsson.com]
Sent: Wednesday, July 11, 2012 7:2= 1=20 PM
To: Alexander Vainshtein
Cc: mpls@ietf.org; pwe3=20 (pwe3@ietf.org)
Subject: RE: Doubts in allocation of a new G-ACH = type=20 for

Dave,

Lots of thanks for a prompt response.

 

Unfortunately I have to say that it is confusing: interleave of CC and C= V=20 packets on the same stream is achieved by using a different G-ACh= =20 type for CV messages. This type discriminates between CC and CV messages eq= ually=20 well for any of the two G-ACh types that potentia= lly=20 could be used for carrying CC messages.

 

Do I miss something fundamental?

 

Regards,

     Sasha 

From: David Allan I=20 [david.i.allan@ericsson.com]
Sent: Wednesday, July 11, 2012 6:07= =20 PM
To: Alexander Vainshtein; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: RE: Doubts in allocation of a new G-ACH type for= =20

Hi=20 Sasha:
 
The=20 reason for this is the overall system behavior implied. A 5885 code point i= s=20 purely CC operation. A 6428 code point indicates that CV will be interleave= d=20 with the stream. We wanted to explicitly disambiguate=20 this.
 
It=20 further permits misbranching of a 5885 stream into a 6428 path to be detect= ed so=20 the overall network is more robust. If the CC messages in both 5885 and 642= 8 had=20 a common code point, this would not be possible, and CV operation would not= be=20 authoritative.
 
I hope=20 this helps
Dave

From: Alexander Vainshtein=20 [mailto:Alexander.Vainshtein@ecitele.com]
Sent: Wednesday, July = 11,=20 2012 3:51 AM
To: David Allan I; swallow@cisco.com;=20 jdrake@juniper.net
Cc: cpignata@cisco.com; tnadeau@juniper.net;=20 mpls@ietf.org; pwe3 (pwe3@ietf.org); Rotem Cohen; Andrew Sergeev; Mishael=20 Wexler
Subject: Doubts in allocation of a new G-ACH type for=20

Hi all,

I have doubts regarding allocation of the G-ACH type f= or the=20 MPLS-TP CC message in RFC 6428.

 

Looking at both this RFC and RFC 5885, i= t seems=20 that the format of the MPLS-TP CC packet and the format of the raw BFD pack= et in=20 VCCV is exactly the same. However, two different G-ACH types have been allo= cated=20 by IANA for these two cases.

 

IMHO and FWIW such duplication can only create=20 interoperability problems, especially with progress of the new VCCV Type (u= sing=20 GAL) for PWs. The text in Section 3.1 of 6428 that refers to existing capab= ility=20 to run BFD over LSP with the G-ACh using Channel Type 7 only adds to the=20 confusion IMO, since it uses un-capitalized “may” and not one o= f the IETF=20 reserved requirement level words.

 

Clarification of intentions by the editors of RFC 6428= =20 (and/or of RFC 5885) would be highly appreciated.

 

Regards,

     Sasha

 

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

This e-mail message is intended for the recipient only and contains=20 information which is CONFIDENTIAL and which may be proprietary to ECI Telec= om.=20 If you have received this transmission in error, please inform us by e-mail= ,=20 phone or fax, and then delete the original and all copies thereof.=20

--_000_60C093A41B5E45409A19D42CF7786DFD53BC0662D0EUSAACMS0703e_-- From amclachl@cisco.com Fri Jul 13 01:47:26 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9DB21F8797 for ; Fri, 13 Jul 2012 01:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.044 X-Spam-Level: X-Spam-Status: No, score=-10.044 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNV0woG4AJmY for ; Fri, 13 Jul 2012 01:47:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE8C21F86B8 for ; Fri, 13 Jul 2012 01:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=amclachl@cisco.com; l=6551; q=dns/txt; s=iport; t=1342169281; x=1343378881; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jle38PsGGb0H3eAxN53OD1d+/2hFBxjF8833YBz3Z4o=; b=fWAs8viRzK924p5vhabwtZGtvJo+bfGmQJxYBqr9y5GsPQdrNKdacNgd l0sJtgCwR1QJzvD6nPzJ5F1Zzqchj4GqkXHcvjcKvgQijrrWvj+ueCcr9 ssrPau5sX9nA+qhfoOnFOIzCxPxTnAfsg2wumYowdW+CH9TMzONQnE55K o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIjf/0+tJV2Y/2dsb2JhbABFuB2BB4IZBwEBAQQBAQEPASc0CwwEAgEIEQEDAQEfCQcnCxQDBggCBA4FCRmFJweCPQubFaAYizwahHxgA5U6gRKJdYMZgWaCX4Ff X-IronPort-AV: E=Sophos;i="4.77,579,1336348800"; d="scan'208";a="101520230" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 13 Jul 2012 08:48:01 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q6D8m0uT024506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jul 2012 08:48:00 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.205]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 03:48:00 -0500 From: "Andrew McLachlan (amclachl)" To: Alexander Vainshtein Thread-Topic: I-D Action: draft-medved-pwe3-of-config-01.txt Thread-Index: AQHNXyPoTOcM0MAQFEm4M8vD4MnHUZclvAsQgAGB54A= Date: Fri, 13 Jul 2012 08:48:00 +0000 Message-ID: <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com> References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.38] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19036.006 x-tm-as-result: No--36.287100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <923A5ACE098D7D44B4478A122F4D220E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "pwe3 \(pwe3@ietf.org\)" , "David Meyer \(dmm\)" , "Jan Medved \(jmedved\)" , "Yaakov Stein \(yaakov_s@rad.com\)" Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 08:47:26 -0000 Hi Sasha Thank you for your comments, apologies for my late reply, I was traveling y= esterday. "per-PW OAM engines as generators of triggers for protection switching" - i= t's not the intention to 'spin up' a new Engine per PW, we will edit and ma= ke this clearer in the next version of the draft. The OAM Engine could be e= ither linecard based or more central on a switch, RP for example, but this = will be down to the switch vendors implementation. "the OF switch-based model of the PW endpoint proposed in the draft implies= that it must be reconfigured every time the egress port and/or the Next Ho= p LSR change " - The intention is for the output/group port (ff) to be pre-= provisioned to know the primary/second path information, should a failure o= ccur the label and SA/DA headers would be added by the output packet proces= sor.=20 Whilst this this draft is only currently only aimed at the PW, and we are s= till relying on existing mechanisms for the LSP and subsequent encaps for t= hem, totally understand your concerns we will review the draft again before= the next version to see if we can make better distinction between PW endpo= ints and the PSN piece. andrew On 12 Jul 2012, at 16:12, Alexander Vainshtein wrote: Hi all, I've looked up a new version of the draft and I have several issues with th= e proposed mode of operation as described in Figure 4 in Section 2.1: A packet initially arrives at the AC with the following headers and payload. This packet becomes the PW payload. \ - PW payload / Next, the iPProc adds the Transport header. \ - PW payload - Transport header The Virtual OF switch then pushes on PW label with S=3D1. \ - PW payload / - PW label - Transport header Finally, the oPProc pushes the Transport label and switches the packet onto the Transport LSP. \ - PW payload / - PW label - Transport label - Transport header Figure 4: Input Encapsulation Sequence It is further explained in the beginning of Section 2.1 that : The iPProc encapsulates arriving packets on the Attachment Circuit in the = outer transport (Ethernet) header. =20 This is required because OpenFlow can only push MPLS labels onto the top o= f a label stack encapsulated in an existing Ethernet header. The problem (as I see it) is that "the outer transport (Ethernet) header" M= UST match the egress port (SA) and Next Hop LSR (DA) in order for the MPLS = data plane to operate properly. I.e., the OF switch-based model of the PW endpoint proposed in the draft im= plies that it must be reconfigured every time the egress port and/or the Ne= xt Hop LSR change (e.g., in a protection switch). As I have already mention= ed in my comments on the -00 version of the draft such behavior does not sc= ale up. The scalability problem of the proposed model do not end here. The draft st= ill seems to consider per-PW OAM engines as generators of triggers for prot= ection switching. Just mentioning that The OAM function for Transport LSPs is out of scope for this revision of this document. However, PW-OAM mechanisms described in this document could also applicable to Transport LSP-OAM. and Note that in addition to the OAM Engine, the Virtual OF Switch MAY use other liveness monitoring mechanisms for the virtual port Fast Failover groups, which are out of scope of this document. is not really helpful. I am pretty near ignorant with regard to OpenFlow, but I wonder whether a d= ifferent model of the PW endpoint that better agrees with the PWE3 architec= ture=20 (which, as per RFC 3985, clearly distinguishes between PW endpoints and PSN= tunnels) could be created?=20 IMHO and FWIW, without such a model using OpenFlow for control of PW endpoi= nts would be highly problematic. My 2c, Sasha -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: Wednesday, July 11, 2012 8:13 AM To: i-d-announce@ietf.org Subject: I-D Action: draft-medved-pwe3-of-config-01.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : MPLS-TP Pseudowire Configuration using OpenFlow 1.3 Author(s) : Jan Medved Andrew McLachlan David Meyer Filename : draft-medved-pwe3-of-config-01.txt Pages : 20 Date : 2012-07-10 Abstract: This document describes a method by which MPLS-TP Pseudowires (PW) can be configured in an LER using OpenFlow 1.3. In addition to the configuration of PWs this document also specifies how to enact OAM for these PWs using standard IETF conventions defined by the GAL label method. The primary goal of this document is to provide a simple and yet flexible method for configuring PWs using standardized tools from the emerging SDN toolkit. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-medved-pwe3-of-config There's also a htmlized version available at: http://tools.ietf.org/html/draft-medved-pwe3-of-config-01 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-medved-pwe3-of-config-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. From amalis@gmail.com Fri Jul 13 05:28:28 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B47F21F85EF for ; Fri, 13 Jul 2012 05:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.369 X-Spam-Level: X-Spam-Status: No, score=-103.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVTLD8FlLKTB for ; Fri, 13 Jul 2012 05:28:27 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5721F85E3 for ; Fri, 13 Jul 2012 05:28:27 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so5740179pbc.31 for ; Fri, 13 Jul 2012 05:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=YML+KMsFVcB0Wk32sPqbvf4CLQI3ZHF1BBDasgXJ+8E=; b=l659I+XuiUjg42FnW42fjqxfVFJYiQZb09zO7G8Yrybl2gO8e7LByinWJtRpBaUqPw Hr/Jcqd1lQMbWurwnc8uMexBfc3pwTrYVdoehsopn21/pCxBcF9WErlcPEuHWMJhsNvJ qSOVqD4HJ5rFCxgs0dXfjrYJZFd1J0xXQGDla9uTcdWEUjkKSg15C3+XQXBbhpskxuMM vFZ9/je9FPEBlASulNMBNlthr6ol4fYx5vHuQKt98PEaTM2pgD0iPYjUzPZgnyrYDltA pmxHKGM+kz3j19VFCWR9o9c6VFxpkAYTJ3SjwwTz6ZJmAJPi28UEsD6msJNirSQFVk7v IFsQ== Received: by 10.68.192.97 with SMTP id hf1mr2961974pbc.132.1342182543516; Fri, 13 Jul 2012 05:29:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.45.9 with HTTP; Fri, 13 Jul 2012 05:28:43 -0700 (PDT) In-Reply-To: <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com> References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com> <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com> From: "Andrew G. Malis" Date: Fri, 13 Jul 2012 08:28:43 -0400 Message-ID: To: "Andrew McLachlan (amclachl)" , "David Meyer (dmm)" , "Jan Medved (jmedved)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "pwe3 \(pwe3@ietf.org\)" , "Yaakov Stein \(yaakov_s@rad.com\)" Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 12:28:28 -0000 Andrew et al, I still don't like the following sentence in the first paragraph of section= 1.3: At present no open standards exist to provision these PWs, and therefore there is a reliance on vendor specific provisioning platforms. It should be noted that there exists alternative methods for the static provisioning of PWs, including via SNMP ([RFC5601]). Are you claiming that RFC 5601 isn't an open standard? I would much prefer something like: The static PW provisioning method in this document is presented as an alternative to the existing method of provisioning static PWs via SNMP ([RFC5601]) or via vendor-specific provisioning platforms. PWs may of course also be dynamically signaled via a control plane if desired ([RFC4447]). Thanks, Andy On Fri, Jul 13, 2012 at 4:48 AM, Andrew McLachlan (amclachl) wrote: > > Hi Sasha > > Thank you for your comments, apologies for my late reply, I was traveling= yesterday. > > "per-PW OAM engines as generators of triggers for protection switching" -= it's not the intention to 'spin up' a new Engine per PW, we will edit and = make this clearer in the next version of the draft. The OAM Engine could be= either linecard based or more central on a switch, RP for example, but thi= s will be down to the switch vendors implementation. > > "the OF switch-based model of the PW endpoint proposed in the draft impli= es that it must be reconfigured every time the egress port and/or the Next = Hop LSR change " - The intention is for the output/group port (ff) to be pr= e-provisioned to know the primary/second path information, should a failure= occur the label and SA/DA headers would be added by the output packet proc= essor. > > Whilst this this draft is only currently only aimed at the PW, and we are= still relying on existing mechanisms for the LSP and subsequent encaps for= them, totally understand your concerns we will review the draft again befo= re the next version to see if we can make better distinction between PW end= points and the PSN piece. > > andrew > > > On 12 Jul 2012, at 16:12, Alexander Vainshtein wrote: > > Hi all, > I've looked up a new version of the draft and I have several issues with = the proposed mode of operation as described in Figure 4 in Section 2.1: > > > A packet initially arrives at the AC with the following headers > and payload. This packet becomes the PW payload. > > \ > - PW payload > / > > Next, the iPProc adds the Transport header. > > \ > - PW payload > - Transport header > > The Virtual OF switch then pushes on PW label with S=3D1. > > \ > - PW payload > / > - PW label > - Transport header > > Finally, the oPProc pushes the Transport label and switches the > packet onto the Transport LSP. > > \ > - PW payload > / > - PW label > - Transport label > - Transport header > > Figure 4: Input Encapsulation Sequence > > > It is further explained in the beginning of Section 2.1 that : > > > The iPProc encapsulates arriving packets on the Attachment Circuit in th= e outer transport (Ethernet) header. > This is required because OpenFlow can only push MPLS labels onto the top= of a label stack encapsulated in an existing Ethernet header. > > > The problem (as I see it) is that "the outer transport (Ethernet) header"= MUST match the egress port (SA) and Next Hop LSR (DA) in order for the MPL= S data plane to operate properly. > I.e., the OF switch-based model of the PW endpoint proposed in the draft = implies that it must be reconfigured every time the egress port and/or the = Next Hop LSR change (e.g., in a protection switch). As I have already menti= oned in my comments on the -00 version of the draft such behavior does not = scale up. > > The scalability problem of the proposed model do not end here. The draft = still seems to consider per-PW OAM engines as generators of triggers for pr= otection switching. > Just mentioning that > > > The OAM function for Transport LSPs is out of scope for this revision > of this document. However, PW-OAM mechanisms described in this > document could also applicable to Transport LSP-OAM. > > > and > > > Note that in addition to the OAM Engine, the Virtual OF Switch MAY > use other liveness monitoring mechanisms for the virtual port Fast > Failover groups, which are out of scope of this document. > > > is not really helpful. > > I am pretty near ignorant with regard to OpenFlow, but I wonder whether a= different model of the PW endpoint that better agrees with the PWE3 archit= ecture > (which, as per RFC 3985, clearly distinguishes between PW endpoints and P= SN tunnels) could be created? > IMHO and FWIW, without such a model using OpenFlow for control of PW endp= oints would be highly problematic. > > My 2c, > Sasha > > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, July 11, 2012 8:13 AM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-medved-pwe3-of-config-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > > Title : MPLS-TP Pseudowire Configuration using OpenFlow= 1.3 > Author(s) : Jan Medved > Andrew McLachlan > David Meyer > Filename : draft-medved-pwe3-of-config-01.txt > Pages : 20 > Date : 2012-07-10 > > Abstract: > This document describes a method by which MPLS-TP Pseudowires (PW) > can be configured in an LER using OpenFlow 1.3. In addition to the > configuration of PWs this document also specifies how to enact OAM > for these PWs using standard IETF conventions defined by the GAL > label method. The primary goal of this document is to provide a > simple and yet flexible method for configuring PWs using standardized > tools from the emerging SDN toolkit. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-medved-pwe3-of-config > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-medved-pwe3-of-config-01 > > A diff from previous version is available at: > http://tools.ietf.org/rfcdiff?url2=3Ddraft-medved-pwe3-of-config-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > > > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From dmm@cisco.com Fri Jul 13 06:15:44 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D298221F8844 for ; Fri, 13 Jul 2012 06:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHDINZFaOSt7 for ; Fri, 13 Jul 2012 06:15:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF5621F8851 for ; Fri, 13 Jul 2012 06:15:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8955; q=dns/txt; s=iport; t=1342185379; x=1343394979; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=enHjrkWpwwbVr1mQ/d92D/XineCzIcIUTnuEL/8pVVQ=; b=K5TmkqhpGYKWriAw/F6bu2+SztYz/q40f1e48aXeguaSofy5sSSd1hpo 0hYfFIItp5hemhDEVzah4TkM0jLLkdFDH9KD3Q2/I1DLCNp1nmWJEtumi cdvoOCODp25QyWzXYyGaieDvAPO1kL0ZVcH4vLxYNyHgkGhfUZAIERk67 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALUeAFCtJV2Z/2dsb2JhbABFuCOBB4IZBwEBAQQBAQEPASc0CwwEAgEIEQEDAQEBChQJByEGCxQDBggCBAENBQgBGYUnB4IuAwsBC5sjllENiU6KVmYahHxgA5ZMiXIDgxmBZoJfgV8 X-IronPort-AV: E=Sophos;i="4.77,579,1336348800"; d="scan'208";a="98605518" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 13 Jul 2012 13:16:19 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6DDGJx6026306 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 13 Jul 2012 13:16:19 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.118]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Fri, 13 Jul 2012 08:16:18 -0500 From: "David Meyer (dmm)" To: "Andrew G. Malis" , "Andrew McLachlan (amclachl)" , "Jan Medved (jmedved)" Thread-Topic: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt Thread-Index: AQHNXyPoTOcM0MAQFEm4M8vD4MnHUZclvAsQgAGB54CAAD2sgP//uW96 Date: Fri, 13 Jul 2012 13:15:42 +0000 Message-ID: <5EA033561A7C374F82DF1FC7F9079BAF0D205B@xmb-rcd-x09.cisco.com> References: <20120711051239.19562.70082.idtracker@ietfa.amsl.com> <6C4D4E30-0040-4F0A-A703-0E0A7F84639D@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.46.188] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19036.006 x-tm-as-result: No--43.251700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 13 Jul 2012 08:02:21 -0700 Cc: "pwe3 \(pwe3@ietf.org\)" , "Yaakov Stein \(yaakov_s@rad.com\)" Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 13:15:45 -0000 Sure, thanks for the text. --dmm=0A= =0A= ________________________________________=0A= From: Andrew G. Malis [amalis@gmail.com]=0A= Sent: Friday, July 13, 2012 05:28=0A= To: Andrew McLachlan (amclachl); David Meyer (dmm); Jan Medved (jmedved)=0A= Cc: Alexander Vainshtein; pwe3 (pwe3@ietf.org); Yaakov Stein (yaakov_s@rad.= com)=0A= Subject: Re: [PWE3] I-D Action: draft-medved-pwe3-of-config-01.txt=0A= =0A= Andrew et al,=0A= =0A= I still don't like the following sentence in the first paragraph of section= 1.3:=0A= =0A= At present no open standards=0A= exist to provision these PWs, and therefore there is a reliance on=0A= vendor specific provisioning platforms. It should be noted that=0A= there exists alternative methods for the static provisioning of PWs,=0A= including via SNMP ([RFC5601]).=0A= =0A= Are you claiming that RFC 5601 isn't an open standard?=0A= =0A= I would much prefer something like:=0A= =0A= The static PW provisioning method in this document is presented as an=0A= alternative to the existing method of provisioning static PWs via SNMP=0A= ([RFC5601]) or via vendor-specific provisioning platforms. PWs may of=0A= course also be dynamically signaled via a control plane if desired=0A= ([RFC4447]).=0A= =0A= Thanks,=0A= Andy=0A= =0A= On Fri, Jul 13, 2012 at 4:48 AM, Andrew McLachlan (amclachl)=0A= wrote:=0A= >=0A= > Hi Sasha=0A= >=0A= > Thank you for your comments, apologies for my late reply, I was traveling= yesterday.=0A= >=0A= > "per-PW OAM engines as generators of triggers for protection switching" -= it's not the intention to 'spin up' a new Engine per PW, we will edit and = make this clearer in the next version of the draft. The OAM Engine could be= either linecard based or more central on a switch, RP for example, but thi= s will be down to the switch vendors implementation.=0A= >=0A= > "the OF switch-based model of the PW endpoint proposed in the draft impli= es that it must be reconfigured every time the egress port and/or the Next = Hop LSR change " - The intention is for the output/group port (ff) to be pr= e-provisioned to know the primary/second path information, should a failure= occur the label and SA/DA headers would be added by the output packet proc= essor.=0A= >=0A= > Whilst this this draft is only currently only aimed at the PW, and we are= still relying on existing mechanisms for the LSP and subsequent encaps for= them, totally understand your concerns we will review the draft again befo= re the next version to see if we can make better distinction between PW end= points and the PSN piece.=0A= >=0A= > andrew=0A= >=0A= >=0A= > On 12 Jul 2012, at 16:12, Alexander Vainshtein wrote:=0A= >=0A= > Hi all,=0A= > I've looked up a new version of the draft and I have several issues with = the proposed mode of operation as described in Figure 4 in Section 2.1:=0A= >=0A= > =0A= > A packet initially arrives at the AC with the following headers=0A= > and payload. This packet becomes the PW payload.=0A= >=0A= > \=0A= > - PW payload=0A= > /=0A= >=0A= > Next, the iPProc adds the Transport header.=0A= >=0A= > \=0A= > - PW payload=0A= > - Transport header=0A= >=0A= > The Virtual OF switch then pushes on PW label with S=3D1.=0A= >=0A= > \=0A= > - PW payload=0A= > /=0A= > - PW label=0A= > - Transport header=0A= >=0A= > Finally, the oPProc pushes the Transport label and switches the=0A= > packet onto the Transport LSP.=0A= >=0A= > \=0A= > - PW payload=0A= > /=0A= > - PW label=0A= > - Transport label=0A= > - Transport header=0A= >=0A= > Figure 4: Input Encapsulation Sequence=0A= > =0A= >=0A= > It is further explained in the beginning of Section 2.1 that :=0A= >=0A= > =0A= > The iPProc encapsulates arriving packets on the Attachment Circuit in th= e outer transport (Ethernet) header.=0A= > This is required because OpenFlow can only push MPLS labels onto the top= of a label stack encapsulated in an existing Ethernet header.=0A= > =0A= >=0A= > The problem (as I see it) is that "the outer transport (Ethernet) header"= MUST match the egress port (SA) and Next Hop LSR (DA) in order for the MPL= S data plane to operate properly.=0A= > I.e., the OF switch-based model of the PW endpoint proposed in the draft = implies that it must be reconfigured every time the egress port and/or the = Next Hop LSR change (e.g., in a protection switch). As I have already menti= oned in my comments on the -00 version of the draft such behavior does not = scale up.=0A= >=0A= > The scalability problem of the proposed model do not end here. The draft = still seems to consider per-PW OAM engines as generators of triggers for pr= otection switching.=0A= > Just mentioning that=0A= >=0A= > =0A= > The OAM function for Transport LSPs is out of scope for this revision= =0A= > of this document. However, PW-OAM mechanisms described in this=0A= > document could also applicable to Transport LSP-OAM.=0A= > =0A= >=0A= > and=0A= >=0A= > =0A= > Note that in addition to the OAM Engine, the Virtual OF Switch MAY=0A= > use other liveness monitoring mechanisms for the virtual port Fast=0A= > Failover groups, which are out of scope of this document.=0A= > =0A= >=0A= > is not really helpful.=0A= >=0A= > I am pretty near ignorant with regard to OpenFlow, but I wonder whether a= different model of the PW endpoint that better agrees with the PWE3 archit= ecture=0A= > (which, as per RFC 3985, clearly distinguishes between PW endpoints and P= SN tunnels) could be created?=0A= > IMHO and FWIW, without such a model using OpenFlow for control of PW endp= oints would be highly problematic.=0A= >=0A= > My 2c,=0A= > Sasha=0A= >=0A= > -----Original Message-----=0A= > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] On Behalf Of internet-drafts@ietf.org=0A= > Sent: Wednesday, July 11, 2012 8:13 AM=0A= > To: i-d-announce@ietf.org=0A= > Subject: I-D Action: draft-medved-pwe3-of-config-01.txt=0A= >=0A= >=0A= > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.=0A= >=0A= >=0A= > Title : MPLS-TP Pseudowire Configuration using OpenFlow= 1.3=0A= > Author(s) : Jan Medved=0A= > Andrew McLachlan=0A= > David Meyer=0A= > Filename : draft-medved-pwe3-of-config-01.txt=0A= > Pages : 20=0A= > Date : 2012-07-10=0A= >=0A= > Abstract:=0A= > This document describes a method by which MPLS-TP Pseudowires (PW)=0A= > can be configured in an LER using OpenFlow 1.3. In addition to the=0A= > configuration of PWs this document also specifies how to enact OAM=0A= > for these PWs using standard IETF conventions defined by the GAL=0A= > label method. The primary goal of this document is to provide a=0A= > simple and yet flexible method for configuring PWs using standardized= =0A= > tools from the emerging SDN toolkit.=0A= >=0A= >=0A= > The IETF datatracker status page for this draft is:=0A= > https://datatracker.ietf.org/doc/draft-medved-pwe3-of-config=0A= >=0A= > There's also a htmlized version available at:=0A= > http://tools.ietf.org/html/draft-medved-pwe3-of-config-01=0A= >=0A= > A diff from previous version is available at:=0A= > http://tools.ietf.org/rfcdiff?url2=3Ddraft-medved-pwe3-of-config-01=0A= >=0A= >=0A= > Internet-Drafts are also available by anonymous FTP at:=0A= > ftp://ftp.ietf.org/internet-drafts/=0A= >=0A= > _______________________________________________=0A= > I-D-Announce mailing list=0A= > I-D-Announce@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/i-d-announce=0A= > Internet-Draft directories: http://www.ietf.org/shadow.html=0A= > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt=0A= >=0A= > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof.=0A= >=0A= >=0A= > _______________________________________________=0A= > pwe3 mailing list=0A= > pwe3@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/pwe3=0A= From iesg-secretary@ietf.org Fri Jul 13 09:26:35 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681121F878B; Fri, 13 Jul 2012 09:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aktQYlbJlBAd; Fri, 13 Jul 2012 09:26:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0863521F8798; Fri, 13 Jul 2012 09:26:34 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120713162634.27289.56612.idtracker@ietfa.amsl.com> Date: Fri, 13 Jul 2012 09:26:34 -0700 Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Document Action: 'Pseudowire Redundancy' to Informational RFC (draft-ietf-pwe3-redundancy-09.txt) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 16:26:35 -0000 The IESG has approved the following document: - 'Pseudowire Redundancy' (draft-ietf-pwe3-redundancy-09.txt) as Informational RFC This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-redundancy/ Technical Summary This document describes a framework comprised of a number of scenarios and associated requirements for pseudowire (PW) redundancy. A set of redundant PWs is configured between provider edge (PE) nodes in single segment PW applications, or between Terminating PE nodes in Multi-Segment PW applications. In order for the PE/T-PE nodes to indicate the preferred PW to use for forwarding PW packets to one another, a new PW status is required to indicate the preferential forwarding status of active or standby for each PW in the redundancy set. Working Group Summary This document represents the consensus of the working group. Document Quality There are no concerns regarding the document's quality. Personnel Andy Malis is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. RFC Editor Note In the Security Section (5) Old This document requires extensions to the Label Distribution Protocol (LDP) that are needed for protecting pseudowires. These will inherit at least the same security properties as LDP [RFC5036] and the PW control protocol [RFC4447]. NEW The PW redundancy method described in this RFC will require an extension to the PW control protocol [RFC4447], which in turn is carried over the Label Distribution Protocol (LDP) [RFC5036]. This PW redundancy method will therefore inherit the security mechanisms of the version of LDP implemented in the PEs. END From yaakov_s@rad.com Sun Jul 15 05:14:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B889B21F859B for ; Sun, 15 Jul 2012 05:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leZ1U5r3QSBs for ; Sun, 15 Jul 2012 05:14:45 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0262721F859E for ; Sun, 15 Jul 2012 05:14:36 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 15 Jul 2012 14:39:41 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Sun, 15 Jul 2012 15:15:12 +0300 From: Yaakov Stein To: pwe3 Thread-Topic: New Version Notification for draft-stein-pwe3-congcons-01.txt Thread-Index: Ac1ig3nTQp82kwJuTPulyQwLUFpGYA== Date: Sun, 15 Jul 2012 12:15:11 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044E59C4@EXRAD5.ad.rad.co.il> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {F0D5288D-67C1-41F8-B20D-EADA1DAEF3A5} x-cr-hashedpuzzle: ATQq Azy8 BICX Bck9 D0PI FubT HTZm HT8p IUg5 IX6d JEZG JeW1 J7Cq KBiF Keaf LL00; 1; cAB3AGUAMwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {F0D5288D-67C1-41F8-B20D-EADA1DAEF3A5}; eQBhAGEAawBvAHYAXwBzAEAAcgBhAGQALgBjAG8AbQA=; Sun, 15 Jul 2012 12:15:08 GMT; TgBlAHcAIABWAGUAcgBzAGkAbwBuACAATgBvAHQAaQBmAGkAYwBhAHQAaQBvAG4AIABmAG8AcgAgAGQAcgBhAGYAdAAtAHMAdABlAGkAbgAtAHAAdwBlADMALQBjAG8AbgBnAGMAbwBuAHMALQAwADEALgB0AHgAdAA= x-originating-ip: [172.17.141.36] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9044E59C4EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090205.5002B450.0054,ss=1,fgs=0 Subject: [PWE3] New Version Notification for draft-stein-pwe3-congcons-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jul 2012 12:14:46 -0000 --_000_07F7D7DED63154409F13298786A2ADC9044E59C4EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have submitted a new version of the PW congestion considerations draft (co-authored by David Black and Bob Briscoe), and have asked for a slot to discuss it in Vancouver. Please read the PDF version, since it has the figures. Y(J)S ---------------------------------------------------------------------------= ---------------- A new version of I-D, draft-stein-pwe3-congcons-01.txt has been successfull= y submitted by Yaakov (Jonathan) Stein and posted to the IETF repository. Filename: draft-stein-pwe3-congcons Revision: 01 Title: PW Congestion Considerations Creation date: 2012-07-15 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-stein-pwe3-congc= ons-01.txt Status: http://datatracker.ietf.org/doc/draft-stein-pwe3-congcons Htmlized: http://tools.ietf.org/html/draft-stein-pwe3-congcons-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-stein-pwe3-cong= cons-01 Abstract: Pseudowires (PWs) have become a common mechanism for tunneling traffic, and may be found competing for network resources both with other PWs and with non-PW traffic, such as TCP/IP flows. It is thus worthwhile specifying under what conditions such competition is safe, i.e., the PW traffic does not significantly harm other traffic or contribute more than it should to congestion. We conclude that PWs transporting responsive traffic behave as desired without the need for additional mechanisms. For inelastic PWs (such as TDM PWs) we derive a bound under which such PWs consume no more network capacity than a TCP flow. The IETF Secretariat --_000_07F7D7DED63154409F13298786A2ADC9044E59C4EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have submitted a new version of the PW congesti= on considerations draft

(co-authored by David Black and Bob Briscoe),

and have asked for a slot to discuss it in Vancou= ver.

 

Please read the PDF version, since it has the fig= ures.

 

Y(J)S

 

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

A new version of I-D, draft-stein-pwe3-congcons-0= 1.txt has been successfully submitted by Yaakov (Jonathan) Stein and posted= to the IETF repository.

 

Filename:   draft-stein-pwe3-congcons

Revision:   01

Title:       &= nbsp;    PW Congestion Considerations

Creation date:    2012-07-15<= /o:p>

WG ID:       &= nbsp;    Individual Submission

Number of pages: 13

URL:       &nb= sp;     http://www.ietf.org/internet-drafts/draft-stein-pwe3-congcons-01.txt

Status:       =    http://datatracker.ietf.org/doc/draft-stein-pwe3-congcons

Htmlized:      &nbs= p; http://tools.ietf.org/html/draft-stein-pwe3-congcons-01

Diff:       &n= bsp;    http://tools.ietf.org/rfcdiff?url2=3Ddraft-stein-pwe3-congcons-01<= /o:p>

 

Abstract:

   Pseudowires (PWs) have become a comm= on mechanism for tunneling

   traffic, and may be found competing = for network resources both with

   other PWs and with non-PW traffic, s= uch as TCP/IP flows.  It is thus

   worthwhile specifying under what con= ditions such competition is safe,

   i.e., the PW traffic does not signif= icantly harm other traffic or

   contribute more than it should to co= ngestion.  We conclude that PWs

   transporting responsive traffic beha= ve as desired without the need

   for additional mechanisms.  For= inelastic PWs (such as TDM PWs) we

   derive a bound under which such PWs = consume no more network capacity

   than a TCP flow.

 

        &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          

 

 

The IETF Secretariat

 

--_000_07F7D7DED63154409F13298786A2ADC9044E59C4EXRAD5adradcoil_-- From agmalis@gmail.com Mon Jul 16 09:52:07 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E503E21F86E8 for ; Mon, 16 Jul 2012 09:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.39 X-Spam-Level: X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwrRtTXxO1Wu for ; Mon, 16 Jul 2012 09:52:06 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E94EA11E813F for ; Mon, 16 Jul 2012 09:52:05 -0700 (PDT) Received: by yenq13 with SMTP id q13so5728463yen.31 for ; Mon, 16 Jul 2012 09:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=NGSf2/7l+fDQLh4nmFyLyvEUPlWwHmxlTFCL6a1UE9o=; b=QaA+35uRp2WuJI4PUtgfnAfP/N14rmpaGDoE+uPRyw/jzszKX27SM8Dln1OvBUwiig WmmBQyvojtCr9PSwMcFR9Im+xfJD5sf4WiEgmXnQMp0XBeaz20tX0XxkC1cYRw/zECrE ig4m685WoVXcySQHd13bDcVpXNAUxXaKvayTZGhYIpTEze8FVH0nhFlbNetaAFc+XycI mD4IRCb6cWBLXB0CiGxifUxZ875YRl58vP6mgwm7I+RagmrURxh0wQfchqz8YUVSvQLS l+Lju9KbUTp9RTof+63dyvZJQO1TJeGlqsCMYfzvH3CySIpM3M9CYP3NvaErEBO3rhYL lAew== Received: by 10.42.129.75 with SMTP id p11mr3885390ics.41.1342457570691; Mon, 16 Jul 2012 09:52:50 -0700 (PDT) MIME-Version: 1.0 Sender: agmalis@gmail.com Received: by 10.64.90.229 with HTTP; Mon, 16 Jul 2012 09:52:30 -0700 (PDT) In-Reply-To: <20120716160144.12686.37622.idtracker@ietfa.amsl.com> References: <20120716160144.12686.37622.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Mon, 16 Jul 2012 12:52:30 -0400 X-Google-Sender-Auth: WlySdT1Xl_I1VgT94PhkWt5GsyU Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PWE3] Fwd: Internet Draft Final Submission Cut-off Date Today X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 16:52:07 -0000 ---------- Forwarded message ---------- From: IETF Secretariat Date: Mon, Jul 16, 2012 at 12:01 PM Subject: Internet Draft Final Submission Cut-off Date Today To: IETF Announcement List This is a reminder that the Internet Draft Final Submission (version -01 and up) Cut-off is today. All Final Version (-01 and up) submissions are due by UTC 24:00 Monday, July 16. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ Thank you! From Internet-Drafts@ietf.org Mon Jul 16 15:27:00 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF2A11E830B; Mon, 16 Jul 2012 15:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lFsMyZ9f0-Z; Mon, 16 Jul 2012 15:26:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92E0511E830A; Mon, 16 Jul 2012 15:26:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120716222659.21215.20622.idtracker@ietfa.amsl.com> Date: Mon, 16 Jul 2012 15:26:59 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D ACTION:draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 22:27:00 -0000 --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 : MPLS and Ethernet OAM Interworking Author(s) : D. Mohan, et al Filename : draft-ietf-pwe3-mpls-eth-oam-iwk Pages : 25 Date : July 16, 2012 This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-pwe3-mpls-eth-oam-iwk"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-07-16152659.I-D@ietf.org> --NextPart-- From gmanhoudt@aimvalley.nl Wed Jul 18 01:33:00 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2EA921F8737 for ; Wed, 18 Jul 2012 01:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBhkH4ejXHsj for ; Wed, 18 Jul 2012 01:32:57 -0700 (PDT) Received: from mika.eatserver.nl (mika.eatserver.nl [195.20.9.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF4C21F8738 for ; Wed, 18 Jul 2012 01:32:55 -0700 (PDT) Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by mika.eatserver.nl (8.13.8/8.13.8) with ESMTP id q6I8XU8N032467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2012 10:33:30 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id 0B5A5818303; Wed, 18 Jul 2012 10:33:30 +0200 (CEST) X-Virus-Scanned: by Endian Firewall X-Spam-CTCH-RefID: Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id ED0B0818302; Wed, 18 Jul 2012 10:33:28 +0200 (CEST) Received: from [10.10.7.15] (pc315.aimsys.nl [10.10.7.15]) (authenticated bits=0) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id q6I8XSjI024707; Wed, 18 Jul 2012 10:33:28 +0200 Message-ID: <500674D8.1040601@aimvalley.nl> Date: Wed, 18 Jul 2012 10:33:28 +0200 From: Gert Manhoudt Organization: AimValley B.V. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Alexander Vainshtein , "stbryant@cisco.com" , "Yaakov Stein (yaakov_s@rad.com)" References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070402070706000808060903" Cc: "peter.roberts@alcatel-lucent.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gmanhoudt@aimvalley.nl List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:33:00 -0000 This is a cryptographically signed message in MIME format. --------------ms070402070706000808060903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Stewart, Yaacov and Alexander, Thanks for your comments on draft-manhoudt-pwe3-tsop-00. It is our=20 intent to request the PWE3 WG to accept this document as a working group = draft. At this stage I want to address those points that could be=20 interpreted to imply that the TSoP approach as such is not acceptable.=20 The other comments are of a less principal nature and can be addressed=20 later (and can probably be fixed by adapting the text). 1. TSoP does not require the termination of any STM-N overhead: Yaakov's e-mail contains the statement: "this function is at least a=20 section (in SDH terminology a regenerator section) termination". I=20 believe that this statement is not true: There is no reason why STM-N=20 signals can not be carried transparently over some server layer with=20 minimal interaction between client and server (as should always be the=20 goal). The correct architectural analogue would be to compare a TSoP PW section = to an OTN network that transports an STM-N client signal. The mapping of = an STM-16/OC-48 in an ODU1 does not require any processing of STM-N=20 overhead or even framing for alignment purposes: All STM-16 bits are=20 directly written into the OPU1 payload area. This is described in G.709=20 section 17.2.1. In terms of functional blocks this is described in G.798 = section 14.3.1. Note that Appendix I.1 of this same Recommendation=20 describes the mapping of STM-N in OPU-k using OPTIONAL RS-monitoring,=20 just like TSoP. Because a TSoP PW section (STM-N over PSN) is modeled to behave itself=20 in the same way as an STM-N over OTN section, the TSoP decapsulation=20 function inserts Generic AIS as defined in G.709, rather than SDH=20 multiplex section AIS as defined in G.707, in case the client signal is=20 interrupted. As a side remark: Yaakov's mail also contains the statement: "(since it=20 does not divide up STM-Ns, it is not a line termination)". Note that=20 this directly contradicts the remark that the S1-byte must be processed. = If that were really necessary, it would not be sufficient to limit the=20 required SDH functionality to a regenerator section termination, but=20 rather a full multiplex section termination (SONET: line termination)=20 would be necessary, since the S1-byte is located in the MS part of the=20 STM-N overhead and not in the RS part: SDH regenerators pass the S1-byte = transparently. 2. TSoP passes the S1-byte transparently: The S1-byte in the STM-N multiplex section overhead carries the=20 "traceability information" of the STM-N signal, i.e. the quality level=20 of the master clock at the beginning of a chain of slaved STM-N systems. = Normally this quality level is PRC/PRS, but during fault situations, it=20 may lower to SSU/ST2 or even SEC/ST3. Downstream STM-N systems can use=20 this information to select another reference signal or to go in=20 hold-over mode. The question is now whether the passage of an STM-N signal over a=20 TSoP/PSN section should affect the value of the S1-byte. We believe that = this is not the case: The nature of a passage of an STM-N signal through = a TSoP Pseudowire is such that the traceability does not change, since=20 the (long term average of the) frequency of the STM-N signals before=20 entering the TSoP PW and after leaving the TSoP PW is the same: No bits=20 are created or deleted from the STM-N client signal. This means that if=20 the long term frequency accuracy of an STM-N signal is 1E-11 (i.e. it is = traceable to PRC/PRS), that this will not change by passing the TSoP PW, = i.e. the traceability is invariant. Of course, during a failure, the TSoP decapsulation function substitutes = the G-AIS signal which is no longer frequency synchronous with the input = STM-N. In this case the downstream STM-N node will immediately detect=20 Loss of Frame and will no longer be able to read the S1-byte. According=20 to standard SDH reference selection procedures (see G.781), this node=20 will no longer consider such a signal to be an acceptable=20 synchronization reference. 3. A TSoP PWE3 can be carried over UDP/IP: This option has been included in the TSoP draft purely because it is=20 present in the SAToP standard and to keep the encapsulation options=20 aligned. If experience has shown that transport over an UDP/IP PSN of=20 higher bitrate circuit emulation PW's is not recommendable, the authors=20 have no problem to remove this option. Regards, Gert Manhoudt. On 10 jul 2012 11:01, Alexander Vainshtein wrote: > Hi all, > Several comments on the draft in question: > > 1. The draft seems to follow closely RFC 4553, including support of IPv= 4/IPv6 as the PSN, congestion handling etc. I echo Stewart's question reg= arding usage of IPv4/IPv6 PSN (with limited TE capabilities) for carrying= such high-rate CBR flows as STM-1/OC-3 and higher. > > 2. The draft correctly mentions RFC 4842 as an alternative (and approve= d by the IETF) method for emulating SONET/SDH over PSN. However, it is wo= rth noting that one of the reasons this method has been preferred to tran= sparent passing of the entire SONET/SDDH bit stream (e.g., as proposed in= one of the early precursors of RFC 4553 - see http://www.watersprings.o= rg/pub/id/draft-vainshtein-cesopsn-01.txt, Annex B) to was elimination of= the need to manipulate the S1 byte in the SONET/SDH overhead. The lower = nibble of this byte contains encoded quality of the system clock of the S= ONET/SDH mux that has been used to drive the outgoing SONET/SDH bit strea= m. Simply passing tits value transparently thru the PSN does not make any= sense (and, indeed, potentially violates integrity of clock distribution= ). The IWF proposed in the draft cannot access this byte because it is un= aware of the SONET/SDH boundaries, and neither can this be done by the O= Sn_TT_So & OSn/RSn_A_So/ OSn_TT_Sk & OSn/RSn_A_Sk functional blocks to = which the IWF is connected. IMHO the draft should explain in some detail = how this issue is resolved. Alternatively, it should state that the SONET= /SDH bit stream that has passed thru the TSoP PW MUST NOT be used as the = clock source by the CE device. > > 3. The draft defines only LOS as the mandatory SONET/SDH AC fault to af= fect setting of the L bit in the PW control word. However, if Loss of Fra= me defect is encountered (dLOF), de-scrambling of the incoming SONET/SDH= stream cannot be completed, and the payload of the TSoP would become jun= k; hence IMO LOF must be added as a mandatory trigger for asserting the S= F condition in Section 3.1. (And, while the reference to the ITU-T G.783= functional blocks implies that, it would be nice to explain that the inc= oming SONET/SDH bit stream is segmented and encapsulated after de-scrambl= ing - for the sake of the readers that do not parse the ITU-T-ish easily:= -) > > 4. The draft seems to imply that TSoP requires, as a pre-requisite, ava= ilability of common high-quality clock for the pair of PEs terminating a = TSoP PW by both mandating the use of the minimal RTP header in the encaps= ulation and not recommending usage of adaptive clock recovery for these P= Ws. However, this important restriction is not reflected in the Applicabi= lity Statement section of the draft. > > 5. The draft mentions the need not to exceed the path MTU between the p= air of PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS P= SN (where it obviously applies). > > Hopefully these notes will be useful. > > Regards, > Sasha > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf >> Of Stewart Bryant >> Sent: Tuesday, July 10, 2012 10:57 AM >> To: pwe3 >> Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP >> >> Do the authors think that running transparent >> SONET emulation over IP is likely in practice, or is >> this included because SAToP included it? >> >> Stewart >> (Speaking as an individual) >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > This e-mail message is intended for the recipient only and contains inf= ormation which is CONFIDENTIAL and which may be proprietary to ECI Teleco= m. If you have received this transmission in error, please inform us by e= -mail, phone or fax, and then delete the original and all copies thereof.= > --------------ms070402070706000808060903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaTCC BWUwggRNoAMCAQICAhFsMA0GCSqGSIb3DQEBBAUAMIHMMQswCQYDVQQGEwJOTDEWMBQGA1UE CBMNTm9vcmQgSG9sbGFuZDESMBAGA1UEBxMJSGlsdmVyc3VtMRcwFQYDVQQKEw5BaW1WYWxs ZXkgQi5WLjEcMBoGA1UECxMTU2VjdXJpdHkgRGVwYXJ0bWVudDE0MDIGA1UEAxMrQWltVmFs bGV5IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjAwNzEkMCIGCSqGSIb3DQEJARYV c2VjdXJpdHlAYWltdmFsbGV5Lm5sMB4XDTExMDMxMDA4NDQzMFoXDTE0MDMxNDA4NDQzMFow gbgxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZCBIb2xsYW5kMRIwEAYDVQQHEwlIaWx2 ZXJzdW0xFzAVBgNVBAoTDkFpbVZhbGxleSBCLlYuMRwwGgYDVQQLExNTZWN1cml0eSBEZXBh cnRtZW50MR8wHQYDVQQDFBZnbWFuaG91ZHRAYWltdmFsbGV5Lm5sMSUwIwYJKoZIhvcNAQkB FhZnbWFuaG91ZHRAYWltdmFsbGV5Lm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAuw56tsNq+B1arLVy8Wl7yrM3CJ8bFO8vxcfMUnKIzT6nai5yJOzcJlqYmqQd8AexuvzC psiyZUaTz0WERQ3fcnWn4xpt8l8ae9N+vH2ym3o/ikNF7BxyXjlx+8ccSyVIpvI9Tc/bUYtV GckjKUD2webMys8IqHq6Jvjfotw6+wmTZN2tiYc88GV9F+wLdA3ZHr7EumwIxZcvzLLtGdH2 7h+DCMgDeSl1vXKtBkytcIM3Lbb5r9qtKDv0bCszDk0XYnhTRIXlNtrKHoe1OhQ3y2TuLDWX ccIs2oR9NbEEYwk1Jtn1d3Csz65TTrLXaSx4klV3to+0KPFtCsYOByKwiwIDAQABo4IBYTCC AV0wCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlm aWNhdGUwHQYDVR0OBBYEFK/31dJRNdnlx5vxZsZf2knHSQ0HMIIBAQYDVR0jBIH5MIH2gBTb 3nb+Ge+TFaFjNRKfTCRzMuUmCaGB0qSBzzCBzDELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5v b3JkIEhvbGxhbmQxEjAQBgNVBAcTCUhpbHZlcnN1bTEXMBUGA1UEChMOQWltVmFsbGV5IEIu Vi4xHDAaBgNVBAsTE1NlY3VyaXR5IERlcGFydG1lbnQxNDAyBgNVBAMTK0FpbVZhbGxleSBS b290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwMDcxJDAiBgkqhkiG9w0BCQEWFXNlY3Vy aXR5QGFpbXZhbGxleS5ubIIJAL5BwL888j5TMA0GCSqGSIb3DQEBBAUAA4IBAQB0f0bL8Ikx iELD3/7+/zuU5o0lLquoHFnu6sfut/P6jTQkF/yCl6vMKEosvcjbUtxqjM0SgugSF63hDMbf 1ruKhJvCADEkU2nJgJPQrPncVQVp64DZNAh/h951WsbYZK2vDMkRbz0312MiJzgwchtjqlbJ RZOAEBe4FYyHeliudFWSUXYAgCHFOPArBkxGbyvDFY3wYBBwX37HRJjCIK3ro1JTGRSCn1qr HHDLn/srUon/07Fmr6chFtptK9GLZJHwoMB3WduAAFVvjhbUMDP+w2GYkW9EzZNe8WhiUOQu 89WOdYj1I7IPlJ9xrFpnKkfyVGIpwaFFnfFYX8BjaJq3MYIEmjCCBJYCAQEwgdMwgcwxCzAJ BgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZCBIb2xsYW5kMRIwEAYDVQQHEwlIaWx2ZXJzdW0x FzAVBgNVBAoTDkFpbVZhbGxleSBCLlYuMRwwGgYDVQQLExNTZWN1cml0eSBEZXBhcnRtZW50 MTQwMgYDVQQDEytBaW1WYWxsZXkgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAyMDA3 MSQwIgYJKoZIhvcNAQkBFhVzZWN1cml0eUBhaW12YWxsZXkubmwCAhFsMAkGBSsOAwIaBQCg ggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxODA4 MzMyOFowIwYJKoZIhvcNAQkEMRYEFHEc4jhKoXw3nTplbHchIArVlxF6MGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgeQGCSsGAQQB gjcQBDGB1jCB0zCBzDELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkIEhvbGxhbmQxEjAQ BgNVBAcTCUhpbHZlcnN1bTEXMBUGA1UEChMOQWltVmFsbGV5IEIuVi4xHDAaBgNVBAsTE1Nl Y3VyaXR5IERlcGFydG1lbnQxNDAyBgNVBAMTK0FpbVZhbGxleSBSb290IENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDIwMDcxJDAiBgkqhkiG9w0BCQEWFXNlY3VyaXR5QGFpbXZhbGxleS5u bAICEWwwgeYGCyqGSIb3DQEJEAILMYHWoIHTMIHMMQswCQYDVQQGEwJOTDEWMBQGA1UECBMN Tm9vcmQgSG9sbGFuZDESMBAGA1UEBxMJSGlsdmVyc3VtMRcwFQYDVQQKEw5BaW1WYWxsZXkg Qi5WLjEcMBoGA1UECxMTU2VjdXJpdHkgRGVwYXJ0bWVudDE0MDIGA1UEAxMrQWltVmFsbGV5 IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjAwNzEkMCIGCSqGSIb3DQEJARYVc2Vj dXJpdHlAYWltdmFsbGV5Lm5sAgIRbDANBgkqhkiG9w0BAQEFAASCAQBSfG9Yyf9OFByX+prC L4Gd94KAF2I/gkN0MW50vW8QkG5Q4faAwplUpZ09hCfmU0nZxd8LjJV0azvB7LH52vWbTUFQ ppV+4SB+jzAIrN+rttMjsLuGw4hDx1QnqLVkKa2wk8h3XlPKLHmRKi+H54Rkvnb8j8cYZyG5 GTyW4efT7FPdIfiJQBJBN26wk96tUZYyIZhgze42ZtSKGsR7s/H/wFIjWDwPii4TkTQmje87 wPkTyNDU02ui/obMAowUGoS/H638nVr+r1LdS3t4vnYItfDuqpRZQmfsx2UNOEcz+40k25f8 xRBdUTV+AmVXjhUHEirnbld0jm4VIThWjogQAAAAAAAA --------------ms070402070706000808060903-- From yaakov_s@rad.com Wed Jul 18 01:58:44 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE0321F8690 for ; Wed, 18 Jul 2012 01:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYHOm3LvMxLZ for ; Wed, 18 Jul 2012 01:58:43 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5721F8686 for ; Wed, 18 Jul 2012 01:58:40 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 18 Jul 2012 11:23:13 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 11:59:26 +0300 From: Yaakov Stein To: "gmanhoudt@aimvalley.nl" , Alexander Vainshtein , "stbryant@cisco.com" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGiS690goHnm0iu3kV86wpwkZciBfkAgAyK2wCAADQsEA== Date: Wed, 18 Jul 2012 08:59:26 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044E9429@EXRAD5.ad.rad.co.il> References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <500674D8.1040601@aimvalley.nl> In-Reply-To: <500674D8.1040601@aimvalley.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.141.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0B0207.50067AEF.00FA,ss=1,fgs=0 Cc: "peter.roberts@alcatel-lucent.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 08:58:44 -0000 see comments below. -----Original Message----- From: Gert Manhoudt [mailto:gmanhoudt@aimvalley.nl]=20 Sent: Wednesday, July 18, 2012 11:33 To: Alexander Vainshtein; stbryant@cisco.com; Yaakov Stein Cc: stephan.roullot@alcatel-lucent.com; peter.roberts@alcatel-lucent.com; p= we3; Ron Cohen Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Stewart, Yaacov and Alexander, Thanks for your comments on draft-manhoudt-pwe3-tsop-00. It is our=20 intent to request the PWE3 WG to accept this document as a working group=20 draft.=20 [YJS] I think that since this draft redefines basic SDH functionality, at very least we need to liaise with ITU-T before accepting this document. At this stage I want to address those points that could be=20 interpreted to imply that the TSoP approach as such is not acceptable.=20 The other comments are of a less principal nature and can be addressed=20 later (and can probably be fixed by adapting the text). 1. TSoP does not require the termination of any STM-N overhead: Yaakov's e-mail contains the statement: "this function is at least a=20 section (in SDH terminology a regenerator section) termination". I=20 believe that this statement is not true: There is no reason why STM-N=20 signals can not be carried transparently over some server layer with=20 minimal interaction between client and server (as should always be the=20 goal). [YJS] Anything that breaks the physical layer continuity,=20 is at least a regenerator from the SDH layering point of view. A simple optical amplifier is less than a regenerator, since it indeed passes the SDH transparently. The proposal here is VERY non-transparent, as I pointed out. In particular, it breaks the timing chain, which is absolutely fundamental = to SDH operation.=20 The correct architectural analogue would be to compare a TSoP PW section=20 to an OTN network that transports an STM-N client signal.=20 [YJS] Do you realize that PSNs are not synchronous networks ? The mapping of an STM-16/OC-48 in an ODU1 does not require any processing o= f STM-N=20 overhead or even framing for alignment purposes: All STM-16 bits are=20 directly written into the OPU1 payload area. This is described in G.709=20 section 17.2.1. In terms of functional blocks this is described in G.798=20 section 14.3.1. Note that Appendix I.1 of this same Recommendation=20 describes the mapping of STM-N in OPU-k using OPTIONAL RS-monitoring,=20 just like TSoP. Because a TSoP PW section (STM-N over PSN) is modeled to behave itself=20 in the same way as an STM-N over OTN section, the TSoP decapsulation=20 function inserts Generic AIS as defined in G.709, rather than SDH=20 multiplex section AIS as defined in G.707, in case the client signal is=20 interrupted. As a side remark: Yaakov's mail also contains the statement: "(since it=20 does not divide up STM-Ns, it is not a line termination)". Note that=20 this directly contradicts the remark that the S1-byte must be processed.=20 If that were really necessary, it would not be sufficient to limit the=20 required SDH functionality to a regenerator section termination, but=20 rather a full multiplex section termination (SONET: line termination)=20 would be necessary, since the S1-byte is located in the MS part of the=20 STM-N overhead and not in the RS part: SDH regenerators pass the S1-byte=20 transparently. [YJS] The whole purpose of my remark was to point out that this draft proposes a network element that does not exist in SDH as presently de= fined, and thus, as I proposed, needs to be liaised to the SDO holding the pen on = SDH. 2. TSoP passes the S1-byte transparently: The S1-byte in the STM-N multiplex section overhead carries the=20 "traceability information" of the STM-N signal, i.e. the quality level=20 of the master clock at the beginning of a chain of slaved STM-N systems.=20 Normally this quality level is PRC/PRS, but during fault situations, it=20 may lower to SSU/ST2 or even SEC/ST3. Downstream STM-N systems can use=20 this information to select another reference signal or to go in=20 hold-over mode. The question is now whether the passage of an STM-N signal over a=20 TSoP/PSN section should affect the value of the S1-byte. We believe that=20 this is not the case: The nature of a passage of an STM-N signal through=20 a TSoP Pseudowire is such that the traceability does not change, since=20 the (long term average of the) frequency of the STM-N signals before=20 entering the TSoP PW and after leaving the TSoP PW is the same: No bits=20 are created or deleted from the STM-N client signal. This means that if=20 the long term frequency accuracy of an STM-N signal is 1E-11 (i.e. it is=20 traceable to PRC/PRS), that this will not change by passing the TSoP PW,=20 i.e. the traceability is invariant. [YJS] This statement is blatantly incorrectly. The S1 byte specifically indicates that the bit stream obeys the appropriat= e ITU-T timing Recommendation, such as G.811, G.812, or G.813. This is not limited to very long term FFO constraints, but also jitter and wander limits. Were this statement to be true, the entire SDH timing chain would fail (which is precisely what worries me about the draft). In particular, were this statement to be true, we would not have needed to work so hard over the past 10 years on algorith= ms and standards for TDM PW synchronization. We could just send everything using a local 100 ppm crystal and claim that long term the FFO is will be c= orrect. Of course, during a failure, the TSoP decapsulation function substitutes=20 the G-AIS signal which is no longer frequency synchronous with the input=20 STM-N. In this case the downstream STM-N node will immediately detect=20 Loss of Frame and will no longer be able to read the S1-byte. According=20 to standard SDH reference selection procedures (see G.781), this node=20 will no longer consider such a signal to be an acceptable=20 synchronization reference. [YJS] I am not talking about failures. I am talking about normal operation. You will be carrying an SSM that states that you are SEC or SSU, and the downstream network elements will believe this. Their G.781 will cause this clock to be selected, rejecting better clocks, and leading to system failures. 3. A TSoP PWE3 can be carried over UDP/IP: This option has been included in the TSoP draft purely because it is=20 present in the SAToP standard and to keep the encapsulation options=20 aligned. If experience has shown that transport over an UDP/IP PSN of=20 higher bitrate circuit emulation PW's is not recommendable, the authors=20 have no problem to remove this option. [YJS] While this was not my remark, I think that there is a big difference between an individual E1 and an STM signal. Regards, Gert Manhoudt. On 10 jul 2012 11:01, Alexander Vainshtein wrote: > Hi all, > Several comments on the draft in question: > > 1. The draft seems to follow closely RFC 4553, including support of IPv4/= IPv6 as the PSN, congestion handling etc. I echo Stewart's question regardi= ng usage of IPv4/IPv6 PSN (with limited TE capabilities) for carrying such = high-rate CBR flows as STM-1/OC-3 and higher. > > 2. The draft correctly mentions RFC 4842 as an alternative (and approved = by the IETF) method for emulating SONET/SDH over PSN. However, it is worth = noting that one of the reasons this method has been preferred to transparen= t passing of the entire SONET/SDDH bit stream (e.g., as proposed in one of = the early precursors of RFC 4553 - see http://www.watersprings.org/pub/id/= draft-vainshtein-cesopsn-01.txt, Annex B) to was elimination of the need to= manipulate the S1 byte in the SONET/SDH overhead. The lower nibble of this= byte contains encoded quality of the system clock of the SONET/SDH mux tha= t has been used to drive the outgoing SONET/SDH bit stream. Simply passing = tits value transparently thru the PSN does not make any sense (and, indeed,= potentially violates integrity of clock distribution). The IWF proposed in= the draft cannot access this byte because it is unaware of the SONET/SDH b= oundaries, and neither can this be done by the OSn_TT_So & OSn/RSn_A_So/ = OSn_TT_Sk & OSn/RSn_A_Sk functional blocks to which the IWF is connected. = IMHO the draft should explain in some detail how this issue is resolved. Al= ternatively, it should state that the SONET/SDH bit stream that has passed = thru the TSoP PW MUST NOT be used as the clock source by the CE device. > > 3. The draft defines only LOS as the mandatory SONET/SDH AC fault to affe= ct setting of the L bit in the PW control word. However, if Loss of Frame d= efect is encountered (dLOF), de-scrambling of the incoming SONET/SDH strea= m cannot be completed, and the payload of the TSoP would become junk; hence= IMO LOF must be added as a mandatory trigger for asserting the SF conditio= n in Section 3.1. (And, while the reference to the ITU-T G.783 functional = blocks implies that, it would be nice to explain that the incoming SONET/SD= H bit stream is segmented and encapsulated after de-scrambling - for the sa= ke of the readers that do not parse the ITU-T-ish easily:-) > > 4. The draft seems to imply that TSoP requires, as a pre-requisite, avail= ability of common high-quality clock for the pair of PEs terminating a TSoP= PW by both mandating the use of the minimal RTP header in the encapsulatio= n and not recommending usage of adaptive clock recovery for these PWs. Howe= ver, this important restriction is not reflected in the Applicability State= ment section of the draft. > > 5. The draft mentions the need not to exceed the path MTU between the pai= r of PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS PSN (= where it obviously applies). > > Hopefully these notes will be useful. > > Regards, > Sasha > >> -----Original Message----- >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On Behalf >> Of Stewart Bryant >> Sent: Tuesday, July 10, 2012 10:57 AM >> To: pwe3 >> Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP >> >> Do the authors think that running transparent >> SONET emulation over IP is likely in practice, or is >> this included because SAToP included it? >> >> Stewart >> (Speaking as an individual) >> >> >> _______________________________________________ >> pwe3 mailing list >> pwe3@ietf.org >> https://www.ietf.org/mailman/listinfo/pwe3 > This e-mail message is intended for the recipient only and contains infor= mation which is CONFIDENTIAL and which may be proprietary to ECI Telecom. I= f you have received this transmission in error, please inform us by e-mail,= phone or fax, and then delete the original and all copies thereof. > From Alexander.Vainshtein@ecitele.com Wed Jul 18 02:02:11 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CAD21F86A0 for ; Wed, 18 Jul 2012 02:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.271 X-Spam-Level: X-Spam-Status: No, score=-5.271 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6X3loGWLobz for ; Wed, 18 Jul 2012 02:02:09 -0700 (PDT) Received: from mail1.bemta4.messagelabs.com (mail1.bemta4.messagelabs.com [85.158.143.242]) by ietfa.amsl.com (Postfix) with ESMTP id 21EEF21F869C for ; Wed, 18 Jul 2012 02:02:08 -0700 (PDT) Received: from [85.158.143.99:3280] by server-1.bemta-4.messagelabs.com id 67/3D-24392-2CB76005; Wed, 18 Jul 2012 09:02:58 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-3.tower-216.messagelabs.com!1342602177!26925640!1 X-Originating-IP: [168.87.1.157] X-StarScan-Version: 6.6.1.2; banners=-,-,- Received: (qmail 12185 invoked from network); 18 Jul 2012 09:02:57 -0000 Received: from unknown (HELO FRIDLPPSB002.ECITELE.COM) (168.87.1.157) by server-3.tower-216.messagelabs.com with SMTP; 18 Jul 2012 09:02:57 -0000 X-AuditID: a8571402-b7fab6d000004c34-71-50067731d1ff Received: from FRIDWPPCH002.ecitele.com (Unknown_Domain [10.1.16.53]) by FRIDLPPSB002.ECITELE.COM (Symantec Messaging Gateway) with SMTP id 82.90.19508.13776005; Wed, 18 Jul 2012 10:43:29 +0200 (CEST) Received: from FRIDWPPMB001.ecitele.com ([169.254.3.23]) by FRIDWPPCH002.ecitele.com ([10.1.16.53]) with mapi id 14.01.0339.001; Wed, 18 Jul 2012 11:02:56 +0200 From: Alexander Vainshtein To: "gmanhoudt@aimvalley.nl" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGcQcIs6TA3k0aw083lr8KXcpciKb2QgAx32wCAACNNIA== Date: Wed, 18 Jul 2012 09:02:56 +0000 Message-ID: References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <500674D8.1040601@aimvalley.nl> In-Reply-To: <500674D8.1040601@aimvalley.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.42.92] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLsWRmVeSWpSXmKPExsXCxcggpWtYzhZgcOGwlMWTlc/ZLW5vespq 0fdpC4vFvketjBbnns5htNgy/R+LxYeuH6wO7B7b709j9Wh9tpfVY8rvjaweO2fdZfdYsuQn k8ektWkBbFENjDaJeXn5JYklqQopqcXJtkoBRZllicmVSgqZKbZKhkoKBTmJyam5qXkltkqJ BQWpeSlKdlwKGMAGqCwzTyE1Lzk/JTMv3VbJM9hf18LC1FLXUMkuJCOzWCFVNzcxM0chN7W4 ODE9VQEoAvJZXkrCOuaMdf3drAUrIyt2bW1ib2B86N7FyMkhIWAisXFGFzOELSZx4d56ti5G Lg4hgVOMEicPHWeBcJYwSvRNX8gOUsUmYCuxafVdNhBbRMBU4uymTYwgRcwCm5kk7l1aBVYk LGAlcf/NcnaIImuJ5R0rGCFsJ4mli/YCrePgYBFQlVj4PQ0kzCvgK9Hf8QpsppDAMUaJP2us QGxOAR2JozPbwFoZga77fmoNE4jNLCAucevJfCaIqwUkluw5D/WBqMTLx/9YIWw5iaaVV9gh 6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YIOolJQ6uuMEygVF8FpIVs5C0z0LSPgtJ+wJGllWM Em5Bni4+AQHBTgYGRnquzp4hrj6ues7+vpsYgWlqRbgI0w7G5puGhxgFOBiVeHgbNrIGCLEm lhVX5h5ilORgUhLlFahiCxDiS8pPqcxILM6ILyrNSS0+xCjBwawkwnstDijHm5JYWZValA+T sgCG4URmKe7kfFAcl8QbGxigcJTEeeOC7PyFBNKBCS87NbUgtQimVYaDQ0mC17UaaKpgUWp6 akVaZk4JQpqJgxNkMw/Q5jCQGt7igsTc4sx0iPwpRkOOaw9v3WLkuP0XRC7ee+8WoxBLXn5e qpQ47yeQNwRAGjJK8+BmvmIUB/pbmFcBZBwPMFHCTXsFtIgJaBF3MdgiYCaBS0kBM87Up/O3 LQjXZJiwqUOy+72GTGLEf7YJU149239hn7ww78OluzdJbJ8S/IjL8tTmp6sZjG1S5FjERdg/ 371TZ7mNyff9tQiWBEXd3W387clvZrfvfD89RctwJkvOU3e+mIhrfzlvbL+XczQiK+Xzzzmn 7062alrPFDKj5YkNX+y52ZXlWf4GYUosxRmJhlrMRcWJAH/Z6IArBAAA Cc: "Yaakov Stein \(yaakov_s@rad.com\)" , "peter.roberts@alcatel-lucent.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" , "stbryant@cisco.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:02:11 -0000 Gert, and all, Please see some comments inline below. Regards, Sasha > -----Original Message----- > From: Gert Manhoudt [mailto:gmanhoudt@aimvalley.nl] > Sent: Wednesday, July 18, 2012 11:33 AM > To: Alexander Vainshtein; stbryant@cisco.com; Yaakov Stein > (yaakov_s@rad.com) > Cc: stephan.roullot@alcatel-lucent.com; peter.roberts@alcatel-lucent.com; > pwe3; Ron Cohen > Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP > > Stewart, Yaacov and Alexander, > > Thanks for your comments on draft-manhoudt-pwe3-tsop-00. It is our > intent to request the PWE3 WG to accept this document as a working group > draft. [[[Sasha]]] I may be running ahead of things, but I would not support adopt= ion of the draft - at least in its present form. > At this stage I want to address those points that could be > interpreted to imply that the TSoP approach as such is not acceptable. > The other comments are of a less principal nature and can be addressed > later (and can probably be fixed by adapting the text). > > 1. TSoP does not require the termination of any STM-N overhead: > Yaakov's e-mail contains the statement: "this function is at least a > section (in SDH terminology a regenerator section) termination". I > believe that this statement is not true: There is no reason why STM-N > signals can not be carried transparently over some server layer with > minimal interaction between client and server (as should always be the > goal). > > The correct architectural analogue would be to compare a TSoP PW section > to an OTN network that transports an STM-N client signal. The mapping of > an STM-16/OC-48 in an ODU1 does not require any processing of STM-N > overhead or even framing for alignment purposes: All STM-16 bits are > directly written into the OPU1 payload area. This is described in G.709 > section 17.2.1. In terms of functional blocks this is described in G.798 > section 14.3.1. Note that Appendix I.1 of this same Recommendation > describes the mapping of STM-N in OPU-k using OPTIONAL RS-monitoring, > just like TSoP. > [[[Sasha]]] Do you imply that you TSoP carries STM-N unscrambled? > > Because a TSoP PW section (STM-N over PSN) is modeled to behave itself > in the same way as an STM-N over OTN section, the TSoP decapsulation > function inserts Generic AIS as defined in G.709, rather than SDH > multiplex section AIS as defined in G.707, in case the client signal is > interrupted. [[[Sasha]]] To the best of my understanding: (a) You cannot insert MS-AIS (because you do not know where the MS is) (b) Any standard SDH framer would recognize the Generic AIS as RS-LOF (b) inserting "all ones" would actually have the same effect. > > As a side remark: Yaakov's mail also contains the statement: "(since it > does not divide up STM-Ns, it is not a line termination)". Note that > this directly contradicts the remark that the S1-byte must be processed. > If that were really necessary, it would not be sufficient to limit the > required SDH functionality to a regenerator section termination, but > rather a full multiplex section termination (SONET: line termination) > would be necessary, since the S1-byte is located in the MS part of the > STM-N overhead and not in the RS part: SDH regenerators pass the S1-byte > transparently. > > 2. TSoP passes the S1-byte transparently: > The S1-byte in the STM-N multiplex section overhead carries the > "traceability information" of the STM-N signal, i.e. the quality level > of the master clock at the beginning of a chain of slaved STM-N systems. > Normally this quality level is PRC/PRS, but during fault situations, it > may lower to SSU/ST2 or even SEC/ST3. Downstream STM-N systems can use > this information to select another reference signal or to go in > hold-over mode. > > The question is now whether the passage of an STM-N signal over a > TSoP/PSN section should affect the value of the S1-byte. We believe that > this is not the case: The nature of a passage of an STM-N signal through > a TSoP Pseudowire is such that the traceability does not change, since > the (long term average of the) frequency of the STM-N signals before > entering the TSoP PW and after leaving the TSoP PW is the same: No bits > are created or deleted from the STM-N client signal. This means that if > the long term frequency accuracy of an STM-N signal is 1E-11 (i.e. it is > traceable to PRC/PRS), that this will not change by passing the TSoP PW, > i.e. the traceability is invariant. > [[[Sasha]]] I think that your interpretation of S1 is inaccurate. In SDH (and SONET) it carries the information about the traceability level o= f the clock that has been used to generate the current SDH bit-stream. The= TSoP endpoint should do exactly the same IMO. So what is the quality of the clock that the TSoP endpoint uses? There are a= t least three factors that affect this clock: (a) Characteristics of the local oscillator used for clock recovery (b) Quality of the original clock (c) Specifics of the clock recovery algorithm. (c) above may be not all that relevant with Differential clock recovery that= you propose to use for TSoP. For Adaptive clock recovery its impact on wand= er of the recovered SAToP and CESoPSN clock is known to be critical - and t= his in spite of the fact that these protocols do not add or remove any bits! (a) and (b) are not really under your control, but I would guess that the ac= tual quality of the recovered clock cannot be higher than the worst of these= two. So if your incoming SDH stream has been clocked by the PRC, but your c= ommon clock used for Differential clock recovery is Stratum 3E, then the qua= lity of the recovered clock would not be better that Stratum 3E - and sendin= g out the S1 value that reports PRC quality would be wrong. The draft could, of course, indicate (e.g., in its applicability section) th= at S1 values sent out by the TSoP endpoint should not be believed. It could= also recommend synchronizing the two PEs containing a pair of TSoP endpoint= s to a PRC-class common clock - not a very far-reaching assumption taking in= to account availability of GPS clock sources. But without these caveats the= draft simply looks as containing technically wrong statements. > Of course, during a failure, the TSoP decapsulation function substitutes > the G-AIS signal which is no longer frequency synchronous with the input > STM-N. In this case the downstream STM-N node will immediately detect > Loss of Frame and will no longer be able to read the S1-byte. According > to standard SDH reference selection procedures (see G.781), this node > will no longer consider such a signal to be an acceptable > synchronization reference. > > 3. A TSoP PWE3 can be carried over UDP/IP: > This option has been included in the TSoP draft purely because it is > present in the SAToP standard and to keep the encapsulation options > aligned. If experience has shown that transport over an UDP/IP PSN of > higher bitrate circuit emulation PW's is not recommendable, the authors > have no problem to remove this option. > > > Regards, > Gert Manhoudt. > > > > On 10 jul 2012 11:01, Alexander Vainshtein wrote: > > Hi all, > > Several comments on the draft in question: > > > > 1. The draft seems to follow closely RFC 4553, including support of > IPv4/IPv6 as the PSN, congestion handling etc. I echo Stewart's question > regarding usage of IPv4/IPv6 PSN (with limited TE capabilities) for carryi= ng > such high-rate CBR flows as STM-1/OC-3 and higher. > > > > 2. The draft correctly mentions RFC 4842 as an alternative (and approved > by the IETF) method for emulating SONET/SDH over PSN. However, it is > worth noting that one of the reasons this method has been preferred to > transparent passing of the entire SONET/SDDH bit stream (e.g., as proposed > in one of the early precursors of RFC 4553 - see > http://www.watersprings.org/pub/id/draft-vainshtein-cesopsn-01.txt, Annex > B) to was elimination of the need to manipulate the S1 byte in the > SONET/SDH overhead. The lower nibble of this byte contains encoded quality > of the system clock of the SONET/SDH mux that has been used to drive the > outgoing SONET/SDH bit stream. Simply passing tits value transparently thr= u > the PSN does not make any sense (and, indeed, potentially violates integri= ty > of clock distribution). The IWF proposed in the draft cannot access this b= yte > because it is unaware of the SONET/SDH boundaries, and neither can this be > done by the OSn_TT_So & OSn/RSn_A_So/ OSn_TT_Sk & OSn/RSn_A_Sk > functional blocks to which the IWF is connected. IMHO the draft should > explain in some detail how this issue is resolved. Alternatively, it shoul= d state > that the SONET/SDH bit stream that has passed thru the TSoP PW MUST NOT > be used as the clock source by the CE device. > > > > 3. The draft defines only LOS as the mandatory SONET/SDH AC fault to > affect setting of the L bit in the PW control word. However, if Loss of Fr= ame > defect is encountered (dLOF), de-scrambling of the incoming SONET/SDH > stream cannot be completed, and the payload of the TSoP would become > junk; hence IMO LOF must be added as a mandatory trigger for asserting the > SF condition in Section 3.1. (And, while the reference to the ITU-T G.783 > functional blocks implies that, it would be nice to explain that the incom= ing > SONET/SDH bit stream is segmented and encapsulated after de-scrambling - > for the sake of the readers that do not parse the ITU-T-ish easily:-) > > > > 4. The draft seems to imply that TSoP requires, as a pre-requisite, > availability of common high-quality clock for the pair of PEs terminating= a > TSoP PW by both mandating the use of the minimal RTP header in the > encapsulation and not recommending usage of adaptive clock recovery for > these PWs. However, this important restriction is not reflected in the > Applicability Statement section of the draft. > > > > 5. The draft mentions the need not to exceed the path MTU between the > pair of PEs in the case of IPv4/IPv6 PSN but not in the case of the MPLS P= SN > (where it obviously applies). > > > > Hopefully these notes will be useful. > > > > Regards, > > Sasha > > > >> -----Original Message----- > >> From: pwe3-bounces@ietf.org [mailto:pwe3-bounces@ietf.org] On > Behalf > >> Of Stewart Bryant > >> Sent: Tuesday, July 10, 2012 10:57 AM > >> To: pwe3 > >> Subject: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP > >> > >> Do the authors think that running transparent > >> SONET emulation over IP is likely in practice, or is > >> this included because SAToP included it? > >> > >> Stewart > >> (Speaking as an individual) > >> > >> > >> _______________________________________________ > >> pwe3 mailing list > >> pwe3@ietf.org > >> https://www.ietf.org/mailman/listinfo/pwe3 > > This e-mail message is intended for the recipient only and contains > information which is CONFIDENTIAL and which may be proprietary to ECI > Telecom. If you have received this transmission in error, please inform us= by > e-mail, phone or fax, and then delete the original and all copies thereof. > > > > This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From yaakov_s@rad.com Wed Jul 18 02:25:06 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC65F21F861E for ; Wed, 18 Jul 2012 02:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMIk05KoteCK for ; Wed, 18 Jul 2012 02:25:06 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3021F8620 for ; Wed, 18 Jul 2012 02:25:03 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 18 Jul 2012 11:49:38 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 12:25:51 +0300 From: Yaakov Stein To: "gmanhoudt@aimvalley.nl" , Alexander Vainshtein , "stbryant@cisco.com" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGiS690goHnm0iu3kV86wpwkZciBfkAgAyK2wCAADQsEIAACYAA Date: Wed, 18 Jul 2012 09:25:50 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il> References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <500674D8.1040601@aimvalley.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.141.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090203.50068120.0056,ss=1,fgs=0 Cc: "peter.roberts@alcatel-lucent.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:25:07 -0000 Gert and all,=20 I would like to partially retract what I previously said about the S1 byte = and traceability. I hit the send too quickly, and should have thought over the issue first. It is true that the SSM message relates information about traceability, i.e., that after N SDH network elements a certain amount of phase noise has= accumulated, so that the bit stream does not obey the G.81x masks. However, this is not applicable here. Here the physical layer traceability is truly broken, and you are relying on unexplained magic to restore it. All that your statement about not dropping or adding bits guarantees is lim_tau->infinity MTIE(tau) / tau =3D 0, which is not enough. The MTIE slope has to obey the constraint at some finite time. Put in another way, stating that you don't drop or add bits is equivalent to stating that you are somehow traceable to the original clock, but since you broke the physical layer, and do not describe any mechanism for recovery of that physical layer clock, in fact you WILL be forced to have bit slips at the egress IWF. So, simply saying that the SSM is correct by definition, and relying on magic to restore the proper clock, is not meaningful. Sorry for my previous incorrect statements. Y(J)S From yaakov_s@rad.com Wed Jul 18 03:50:10 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6B21F86B3 for ; Wed, 18 Jul 2012 03:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LC+yGevJdcHi for ; Wed, 18 Jul 2012 03:50:09 -0700 (PDT) Received: from rad.co.il (mailrelay02-q.rad.co.il [94.188.133.159]) by ietfa.amsl.com (Postfix) with ESMTP id D8E4B21F8698 for ; Wed, 18 Jul 2012 03:50:08 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 18 Jul 2012 13:14:39 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 13:50:52 +0300 From: Yaakov Stein To: Alexander Vainshtein , "gmanhoudt@aimvalley.nl" Thread-Topic: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP Thread-Index: AQHNXnGiS690goHnm0iu3kV86wpwkZciBfkAgAyK2wCAAAg8AIAAT9YA Date: Wed, 18 Jul 2012 10:50:51 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9044E95F7@EXRAD5.ad.rad.co.il> References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <500674D8.1040601@aimvalley.nl> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.141.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090202.50069510.007C,ss=1,fgs=0 Cc: "peter.roberts@alcatel-lucent.com" , "stbryant@cisco.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 10:50:10 -0000 [[[Sasha]]] I think that your interpretation of S1 is inaccurate. In SDH (and SONET) it carries the information about the traceability level = of the clock that has been used to generate the current SDH bit-stream. Th= e TSoP endpoint should do exactly the same IMO. Sasha - thank you for wording my concerns in a much better fashion than I w= as able to! >From what we understand in the present draft, the clock to which the egress= SDH is locked is a free-running local oscillator (perhaps disciplined to GPS). This is not reflected in the SSM message. Y(J)S From david.sinicrope@ericsson.com Wed Jul 18 12:28:14 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1995B11E8166 for ; Wed, 18 Jul 2012 12:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+L57T5azghj for ; Wed, 18 Jul 2012 12:28:13 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0E36411E8199 for ; Wed, 18 Jul 2012 12:28:13 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6IJT1vv001412 for ; Wed, 18 Jul 2012 14:29:03 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.11]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 18 Jul 2012 15:29:01 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Wed, 18 Jul 2012 15:28:58 -0400 Thread-Topic: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Thread-Index: Ac1lG5VG7/dYkLFQTUq0KZrz81fA+g== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:28:14 -0000 Thanks to all who sent me their requests. The initial agenda for PWE3 is p= osted at: http://www.ietf.org/proceedings/84/agenda/agenda-84-pwe3 If you requested a slot, please make sure your draft is listed on the agend= a. Note that the time allocation may have been reduced to fit into the 90 = PWE3 session. If you requested a slot and your draft is not present on the agenda, please= resend your request by replying to me. Those that are listed on the agenda: 1. Please send an email to me and the Chairs noting what objectives and iss= ues need to be discussed and resolved via the presentation. 2. Your slides are due into me for upload no later than Monday, July 30, 20= 12 ** 2pm ** Vancouver time. Please send me the slides by attaching to a r= eply to this email. Presenters submitting late/no slides and objectives risk losing their prese= ntation slot. Thanks! Dave -----Original Message----- From: David A Sinicrope > Date: Wednesday, June 27, 2012 3:51 PM To: "IETF.PWE3" > Subject: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Hi All, If you need a presentation slot for the IETF 84 PWE3 session, please reply = to this email (subject intact) with: -topic -draft name -requested duration -speaker name Thanks, Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From amalis@gmail.com Wed Jul 18 12:45:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCE811E8196 for ; Wed, 18 Jul 2012 12:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.407 X-Spam-Level: X-Spam-Status: No, score=-103.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvy0oVWrmSLJ for ; Wed, 18 Jul 2012 12:45:21 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 865AF11E8166 for ; Wed, 18 Jul 2012 12:45:21 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so3011860obb.31 for ; Wed, 18 Jul 2012 12:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=KidwSNVsr2K8JgT2GtBgGcidKu99IlvuFXB1eRAmYPg=; b=ujhDde+ZzeTKSjcKBDM3hikrrpZ3hlcsBIsVFd/Nw1y9qoLQiO2K/BZUOc5KxHbpCh d+IPXLu6oXH/JHwz3mzflR8E21QBEyCcCLEZ1fwlQaNw0hytsq3qtayUxz69AzI20SAy ao3KpsAj1vkTUunZcCl2miZFlZiYI9VWCR4e5Q2DIdmZG6haLRsDQqoThHlyJsvyKGRR 85NeOylfbrJPpkhIyARZI/pEo8z+Vn2Tg3x5jsOdP/kcv9NafGAosWyujQ7faNAFq80j 7nFDwhVha18WzRRDLmNGnDfL7PWSCXwHdMCGkbCI+4bidRQirgDszg2JJSGA+12NkfJe HBVQ== Received: by 10.182.231.6 with SMTP id tc6mr3051760obc.63.1342640772365; Wed, 18 Jul 2012 12:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.76.168 with HTTP; Wed, 18 Jul 2012 12:45:51 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Wed, 18 Jul 2012 15:45:51 -0400 Message-ID: To: David Sinicrope Content-Type: text/plain; charset=ISO-8859-1 Cc: "IETF.PWE3" Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 19:45:22 -0000 All, PLEASE note what Dave said regarding the email regarding objectives to the chairs and the deadline for slides submission. As the agenda is completely full, any further requests will be put into an overflow section which we may get to if we have drop off any of the current slots due to slides and objectives not being received by the deadline. So even if you make a late request and end up in the overflow, follow the same instructions regarding the email and slide submission. If you plan to run without slides, let us know!!!!!!!! Don't just assume that if you don't have slides you don't have to let us know in advance. Due to the social, we really can't run past 18:30, but if there's overflow and time available, we'll keep going until we hit 18:30. Thanks, Andy On Wed, Jul 18, 2012 at 3:28 PM, David Sinicrope wrote: > Thanks to all who sent me their requests. The initial agenda for PWE3 is posted at: > > http://www.ietf.org/proceedings/84/agenda/agenda-84-pwe3 > > If you requested a slot, please make sure your draft is listed on the agenda. Note that the time allocation may have been reduced to fit into the 90 PWE3 session. > If you requested a slot and your draft is not present on the agenda, please resend your request by replying to me. > > > Those that are listed on the agenda: > > 1. Please send an email to me and the Chairs noting what objectives and issues need to be discussed and resolved via the presentation. > > 2. Your slides are due into me for upload no later than Monday, July 30, 2012 ** 2pm ** Vancouver time. Please send me the slides by attaching to a reply to this email. > > > Presenters submitting late/no slides and objectives risk losing their presentation slot. > > Thanks! > Dave > > > -----Original Message----- > From: David A Sinicrope > > Date: Wednesday, June 27, 2012 3:51 PM > To: "IETF.PWE3" > > Subject: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver > > Hi All, > If you need a presentation slot for the IETF 84 PWE3 session, please reply to this email (subject intact) with: > -topic > -draft name > -requested duration > -speaker name > > Thanks, > Dave From wwwrun@rfc-editor.org Wed Jul 18 17:12:56 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D587811E81C7; Wed, 18 Jul 2012 17:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.93 X-Spam-Level: X-Spam-Status: No, score=-101.93 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZwA2J372REo; Wed, 18 Jul 2012 17:12:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1DBC611E80E8; Wed, 18 Jul 2012 17:12:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 477A472E002; Wed, 18 Jul 2012 17:13:09 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120719001309.477A472E002@rfc-editor.org> Date: Wed, 18 Jul 2012 17:13:09 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 6658 on Packet Pseudowire Encapsulation over an MPLS PSN X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 00:12:56 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6658 Title: Packet Pseudowire Encapsulation over an MPLS PSN Author: S. Bryant, Ed., L. Martini, G. Swallow, A. Malis Status: Standards Track Stream: IETF Date: July 2012 Mailbox: stbryant@cisco.com, lmartini@cisco.com, swallow@cisco.com, andrew.g.malis@verizon.com Pages: 15 Characters: 32164 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-packet-pw-04.txt URL: http://www.rfc-editor.org/rfc/rfc6658.txt This document describes a pseudowire mechanism that is used to transport a packet service over an MPLS PSN in the case where the client Label Switching Router (LSR) and the server Provider Edge equipments are co-resident in the same equipment. This pseudowire mechanism may be used to carry all of the required layer 2 and layer 3 protocols between the pair of client LSRs. [STANDARDS-TRACK] This document is a product of the Pseudo Wire Emulation Edge to Edge INT Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From wwwrun@rfc-editor.org Wed Jul 18 17:14:02 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E619111E81EB; Wed, 18 Jul 2012 17:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.943 X-Spam-Level: X-Spam-Status: No, score=-101.943 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZpwpLmO01cN; Wed, 18 Jul 2012 17:14:02 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABF111E81F5; Wed, 18 Jul 2012 17:14:02 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CC66872E0D9; Wed, 18 Jul 2012 17:14:17 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120719001417.CC66872E0D9@rfc-editor.org> Date: Wed, 18 Jul 2012 17:14:17 -0700 (PDT) Cc: pwe3@ietf.org, rfc-editor@rfc-editor.org Subject: [PWE3] RFC 6667 on LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 00:14:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6667 Title: LDP 'Typed Wildcard' Forwarding Equivalence Class (FEC) for PWid and Generalized PWid FEC Elements Author: K. Raza, S. Boutros, C. Pignataro Status: Standards Track Stream: IETF Date: July 2012 Mailbox: skraza@cisco.com, sboutros@cisco.com, cpignata@cisco.com Pages: 8 Characters: 17068 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pwe3-pw-typed-wc-fec-03.txt URL: http://www.rfc-editor.org/rfc/rfc6667.txt The "Typed Wildcard Forwarding Equivalence Class (FEC) Element" defines an extension to the Label Distribution Protocol (LDP) that can be used when requesting, withdrawing, or releasing all label bindings for a given FEC Element type is desired. However, a Typed Wildcard FEC Element must be individually defined for each FEC Element type. This specification defines the Typed Wildcard FEC Elements for the Pseudowire Identifier (PWid) (0x80) and Generalized PWid (0x81) FEC Element types. [STANDARDS-TRACK] This document is a product of the Pseudowire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From gmanhoudt@aimvalley.nl Thu Jul 19 02:56:57 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D1721F87A4 for ; Thu, 19 Jul 2012 02:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABzShtGLL7Sl for ; Thu, 19 Jul 2012 02:56:57 -0700 (PDT) Received: from mika.eatserver.nl (mika.eatserver.nl [195.20.9.75]) by ietfa.amsl.com (Postfix) with ESMTP id BBFE021F8783 for ; Thu, 19 Jul 2012 02:56:56 -0700 (PDT) Received: from [195.242.97.150] (qore.networks.above.net [195.242.97.150] (may be forged)) (authenticated bits=0) by mika.eatserver.nl (8.13.8/8.13.8) with ESMTP id q6J9vVfO023387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 19 Jul 2012 11:57:31 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by router38.aimvalley.nl (Postfix) with ESMTP id 9BA79818303; Thu, 19 Jul 2012 11:57:31 +0200 (CEST) X-Virus-Scanned: by Endian Firewall X-Spam-CTCH-RefID: Received: from mail3.aimsys.nl (mail.aimsys.nl [10.10.0.114]) by router38.aimvalley.nl (Postfix) with ESMTP id BE493818302; Thu, 19 Jul 2012 11:57:30 +0200 (CEST) Received: from [10.10.7.15] (pc315.aimsys.nl [10.10.7.15]) (authenticated bits=0) by mail3.aimsys.nl (8.14.2/8.14.2) with ESMTP id q6J9vSo6012111; Thu, 19 Jul 2012 11:57:28 +0200 Message-ID: <5007DA08.1020108@aimvalley.nl> Date: Thu, 19 Jul 2012 11:57:28 +0200 From: Gert Manhoudt Organization: AimValley B.V. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Yaakov Stein , Alexander Vainshtein References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <500674D8.1040601@aimvalley.nl> <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9044E9468@EXRAD5.ad.rad.co.il> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010604030202060701010703" Cc: "peter.roberts@alcatel-lucent.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" , "stbryant@cisco.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gmanhoudt@aimvalley.nl List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 09:56:58 -0000 This is a cryptographically signed message in MIME format. --------------ms010604030202060701010703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Yaakov, Alexander, I understand that the key issue that you raise is whether the continuity = of the "physical layer" when an STM-N signal traverses a TSoP Pseudowire = is sufficiently guaranteed. First of all, I assume that "continuity of the physical layer"(during=20 normal operation)means that all bits that ingress the Pseudowire also=20 egress the Pseudowire in the same order and that there is a certain=20 timing relation between these ingress en egress signals. The example of=20 an optical amplifier was mentioned as a system that does not break the=20 physical layer. That is indeed a clear example. But also more complex=20 systems that do process the binary content of the client signals, like=20 OTN networks, can be said to leave the physical layer intact. Actually,=20 the whole point of Pseudowires is to deliver services that emulate a=20 wire as well as possible, but that does not mean that the client signals = are not "adapted" during transport. Anyway, I agree that to transport STM-N signals over a Pseudowire in the = way as proposed in the TSoP draft, requires that not only the STM-N bits = should remain unaffected, but also a certain timing relation between=20 input and output must be satisfied in order not to "lie about the S1=20 content". The way that this is currently specified in the TSoP draft is written in = section 6.2.2, where it stated for the TSoP decapsulation function, that:= - A reconstructed SDH-type STM-N signal delivered to an Attachment=20 Circuit MUST meet [G.825] jitter and wander requirements, or, - A reconstructed SONET-type OC-M signal delivered to an Attachment=20 Circuit MUST meet [GR-253] jitter and wander requirements. I believe this covers Yaakov's comment that "The MTIE slope has to obey=20 the constraint at some finite time", since G.825 and GR-253 exactly=20 define all phase noise tolerances in different observation intervals. The current draft indeed does not specify how this should be achieved.=20 This is done on purpose to avoid prescribing a certain implementation:=20 The draft allows in principle both adaptive and differential approaches, = and who knows what other schemes that clever people may dream up in the=20 future. As long as the recovered SDH/SONET signal meets all applicable=20 G.825/GR-253 jitter and wander specifications, it should be fine from a=20 network perspective. Clearly, meeting the G.825/GR-253 requirements is a lot easier=20 whensynchronized clocks are available in the PE ingress and egress=20 nodesand differential timing can be used. I agree that it may be useful=20 (necessary?) to add some text to the draft in the Applicability=20 Statements section that explains these things, referring to the=20 different network timing situations described in RFC-4197. Answering some of the other questions: - TSoP carries STM-N in scrambled format - TSoP can not insert MS-AIS, since it does not know where the STM-N=20 frame starts. Instead it substitutes G-AIS, just as an OTN network will=20 do when it carries an STM-N client and something goes wrong. - The quality level of the clock at the PE that reconstructs the STM-N=20 signal at the PW egress is not prescribed. It depends on the design of=20 this circuit and the network synchronization. Again, as long as you meet = G.825/GR-253 jitter and wander requirements at the egress it should be=20 fine. The only other requirement is a +/-20 ppm accuracy when the STM-N=20 signal is replaced by G-AIS. Note that in this condition no S1 is=20 present any longer, so the downstream SDH/SONET NE can not draw any=20 wrong conclusions. In fact it will immediately detect LOF and select=20 another reference or fall back into hold-over mode. Regards, Gert. On 18 jul 2012 11:25, Yaakov Stein wrote: > Gert and all, > > I would like to partially retract what I previously said about the S1 b= yte and traceability. > I hit the send too quickly, and should have thought over the issue firs= t. > > It is true that the SSM message relates information about traceability,= > i.e., that after N SDH network elements a certain amount of phase noise= has accumulated, > so that the bit stream does not obey the G.81x masks. > However, this is not applicable here. > Here the physical layer traceability is truly broken, > and you are relying on unexplained magic to restore it. > > All that your statement about not dropping or adding bits guarantees is= > lim_tau->infinity MTIE(tau) / tau =3D 0, which is not enough. > The MTIE slope has to obey the constraint at some finite time. > > Put in another way, stating that you don't drop or add bits is equivale= nt > to stating that you are somehow traceable to the original clock, > but since you broke the physical layer, and do not describe any mechani= sm > for recovery of that physical layer clock, in fact you WILL be forced > to have bit slips at the egress IWF. > > So, simply saying that the SSM is correct by definition, > and relying on magic to restore the proper clock, > is not meaningful. > > Sorry for my previous incorrect statements. > > Y(J)S > --------------ms010604030202060701010703 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFaTCC BWUwggRNoAMCAQICAhFsMA0GCSqGSIb3DQEBBAUAMIHMMQswCQYDVQQGEwJOTDEWMBQGA1UE CBMNTm9vcmQgSG9sbGFuZDESMBAGA1UEBxMJSGlsdmVyc3VtMRcwFQYDVQQKEw5BaW1WYWxs ZXkgQi5WLjEcMBoGA1UECxMTU2VjdXJpdHkgRGVwYXJ0bWVudDE0MDIGA1UEAxMrQWltVmFs bGV5IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjAwNzEkMCIGCSqGSIb3DQEJARYV c2VjdXJpdHlAYWltdmFsbGV5Lm5sMB4XDTExMDMxMDA4NDQzMFoXDTE0MDMxNDA4NDQzMFow gbgxCzAJBgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZCBIb2xsYW5kMRIwEAYDVQQHEwlIaWx2 ZXJzdW0xFzAVBgNVBAoTDkFpbVZhbGxleSBCLlYuMRwwGgYDVQQLExNTZWN1cml0eSBEZXBh cnRtZW50MR8wHQYDVQQDFBZnbWFuaG91ZHRAYWltdmFsbGV5Lm5sMSUwIwYJKoZIhvcNAQkB FhZnbWFuaG91ZHRAYWltdmFsbGV5Lm5sMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAuw56tsNq+B1arLVy8Wl7yrM3CJ8bFO8vxcfMUnKIzT6nai5yJOzcJlqYmqQd8AexuvzC psiyZUaTz0WERQ3fcnWn4xpt8l8ae9N+vH2ym3o/ikNF7BxyXjlx+8ccSyVIpvI9Tc/bUYtV GckjKUD2webMys8IqHq6Jvjfotw6+wmTZN2tiYc88GV9F+wLdA3ZHr7EumwIxZcvzLLtGdH2 7h+DCMgDeSl1vXKtBkytcIM3Lbb5r9qtKDv0bCszDk0XYnhTRIXlNtrKHoe1OhQ3y2TuLDWX ccIs2oR9NbEEYwk1Jtn1d3Csz65TTrLXaSx4klV3to+0KPFtCsYOByKwiwIDAQABo4IBYTCC AV0wCQYDVR0TBAIwADAsBglghkgBhvhCAQ0EHxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlm aWNhdGUwHQYDVR0OBBYEFK/31dJRNdnlx5vxZsZf2knHSQ0HMIIBAQYDVR0jBIH5MIH2gBTb 3nb+Ge+TFaFjNRKfTCRzMuUmCaGB0qSBzzCBzDELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5v b3JkIEhvbGxhbmQxEjAQBgNVBAcTCUhpbHZlcnN1bTEXMBUGA1UEChMOQWltVmFsbGV5IEIu Vi4xHDAaBgNVBAsTE1NlY3VyaXR5IERlcGFydG1lbnQxNDAyBgNVBAMTK0FpbVZhbGxleSBS b290IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDIwMDcxJDAiBgkqhkiG9w0BCQEWFXNlY3Vy aXR5QGFpbXZhbGxleS5ubIIJAL5BwL888j5TMA0GCSqGSIb3DQEBBAUAA4IBAQB0f0bL8Ikx iELD3/7+/zuU5o0lLquoHFnu6sfut/P6jTQkF/yCl6vMKEosvcjbUtxqjM0SgugSF63hDMbf 1ruKhJvCADEkU2nJgJPQrPncVQVp64DZNAh/h951WsbYZK2vDMkRbz0312MiJzgwchtjqlbJ RZOAEBe4FYyHeliudFWSUXYAgCHFOPArBkxGbyvDFY3wYBBwX37HRJjCIK3ro1JTGRSCn1qr HHDLn/srUon/07Fmr6chFtptK9GLZJHwoMB3WduAAFVvjhbUMDP+w2GYkW9EzZNe8WhiUOQu 89WOdYj1I7IPlJ9xrFpnKkfyVGIpwaFFnfFYX8BjaJq3MYIEmjCCBJYCAQEwgdMwgcwxCzAJ BgNVBAYTAk5MMRYwFAYDVQQIEw1Ob29yZCBIb2xsYW5kMRIwEAYDVQQHEwlIaWx2ZXJzdW0x FzAVBgNVBAoTDkFpbVZhbGxleSBCLlYuMRwwGgYDVQQLExNTZWN1cml0eSBEZXBhcnRtZW50 MTQwMgYDVQQDEytBaW1WYWxsZXkgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAyMDA3 MSQwIgYJKoZIhvcNAQkBFhVzZWN1cml0eUBhaW12YWxsZXkubmwCAhFsMAkGBSsOAwIaBQCg ggKbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDcxOTA5 NTcyOFowIwYJKoZIhvcNAQkEMRYEFEcGoK28lKKx39nZF6RnJyd4aCiUMGwGCSqGSIb3DQEJ DzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0D AgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgeQGCSsGAQQB gjcQBDGB1jCB0zCBzDELMAkGA1UEBhMCTkwxFjAUBgNVBAgTDU5vb3JkIEhvbGxhbmQxEjAQ BgNVBAcTCUhpbHZlcnN1bTEXMBUGA1UEChMOQWltVmFsbGV5IEIuVi4xHDAaBgNVBAsTE1Nl Y3VyaXR5IERlcGFydG1lbnQxNDAyBgNVBAMTK0FpbVZhbGxleSBSb290IENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDIwMDcxJDAiBgkqhkiG9w0BCQEWFXNlY3VyaXR5QGFpbXZhbGxleS5u bAICEWwwgeYGCyqGSIb3DQEJEAILMYHWoIHTMIHMMQswCQYDVQQGEwJOTDEWMBQGA1UECBMN Tm9vcmQgSG9sbGFuZDESMBAGA1UEBxMJSGlsdmVyc3VtMRcwFQYDVQQKEw5BaW1WYWxsZXkg Qi5WLjEcMBoGA1UECxMTU2VjdXJpdHkgRGVwYXJ0bWVudDE0MDIGA1UEAxMrQWltVmFsbGV5 IFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgMjAwNzEkMCIGCSqGSIb3DQEJARYVc2Vj dXJpdHlAYWltdmFsbGV5Lm5sAgIRbDANBgkqhkiG9w0BAQEFAASCAQCKrGeosN68/9PsLo1d xoUaNVwEZcZmankuo5AtYKaeZ9zCvCt0arFFHAdoBJIiEiGDVhlRKRn0joO7ms9C0RXbQ7P/ qIl0S/+cDFHQF6H/s/NxMe/4RmnHwMoKIDZ4IywaNnfWxithyRmVpmYKBviuOJRcToyaV6Jc 07WAcc31CHABsejzmlM2zzHpT78HSPJdHCLamLzpGP2qslwIwX+KfHXHGuhOs/DumqSfanuN QrTrS0BbXF1/ey/aAPI+LtgZpns0lG8g4Izm6sYn8NoYR0XYFvBNYYTWdOFCcSNuXs0yCP/A JD5CpulyaV3v++Cw9MSVn3jGl7JtCtXNFxC6AAAAAAAA --------------ms010604030202060701010703-- From stbryant@cisco.com Thu Jul 19 03:12:46 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BE821F8769 for ; Thu, 19 Jul 2012 03:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.571 X-Spam-Level: X-Spam-Status: No, score=-110.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOyWYY8-E4X3 for ; Thu, 19 Jul 2012 03:12:45 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4949421F86D9 for ; Thu, 19 Jul 2012 03:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=368; q=dns/txt; s=iport; t=1342692818; x=1343902418; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=lYJHOuyZrHGy0F6S945dod+B7zv6o6NwZQg5sPjKR2A=; b=K7goFxWo7g8nXMKCScTRlmVgiATBmWhhFtF8LHaZsR8aLUg1pGxnv7Dt 3n4hdgikSfakENtCe3j6zK89F4BTcTaMLLH1sYWORyQDC+uX5R+HZjih6 08KB/Rp0O85MHtCmDL2yK4uWCkraCvPA3DyzWbbzrfDURuVJ37NSZz4Yw 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFADXdB1CQ/khL/2dsb2JhbABFtWqDXYEHgiABAQEEEgECI0ABEAsYCRYPCQMCAQIBRQYNAQcBAR6Ha55Gg0gQnC6LQIcQA5VEjiOBBGKCYA X-IronPort-AV: E=Sophos;i="4.77,615,1336348800"; d="scan'208";a="141341184" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 19 Jul 2012 10:13:34 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q6JADYjq026542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Jul 2012 10:13:34 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id q6JADPdw003561; Thu, 19 Jul 2012 11:13:27 +0100 (BST) Message-ID: <5007DDC5.3070805@cisco.com> Date: Thu, 19 Jul 2012 11:13:25 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: Yaakov Stein References: <20120709230133.15922.55905.idtracker@ietfa.amsl.com> <4FFBE04A.5010203@cisco.com> <500674D8.1040601@aimvalley.nl> <07F7D7DED63154409F13298786A2ADC9044E9429@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC9044E9429@EXRAD5.ad.rad.co.il> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "peter.roberts@alcatel-lucent.com" , pwe3 , "stephan.roullot@alcatel-lucent.com" Subject: Re: [PWE3] draft-manhoudt-pwe3-tsop-00.txt and IP X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2012 10:12:46 -0000 On 18/07/2012 09:59, Yaakov Stein wrote: > > [YJS] I think that since this draft redefines basic SDH functionality, > at very least we need to liaise with ITU-T before accepting this document. > I cannot speak to whether this draft redefines SDH or not, but I agree that PWE3 WG needs to liaise with ITU SG15 if it is considers adopting the draft. Stewart From david.sinicrope@ericsson.com Mon Jul 23 06:39:22 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B84021F85DF for ; Mon, 23 Jul 2012 06:39:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.016 X-Spam-Level: X-Spam-Status: No, score=-106.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zJInK1DRtGh for ; Mon, 23 Jul 2012 06:39:21 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7537121F85AD for ; Mon, 23 Jul 2012 06:39:21 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6NDdJs9023848 for ; Mon, 23 Jul 2012 08:39:20 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 23 Jul 2012 09:39:14 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Mon, 23 Jul 2012 09:39:11 -0400 Thread-Topic: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Thread-Index: Ac1o2Iv8EuM48qQ/RC6GSmKWXuKtDA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 13:39:22 -0000 The updated agenda is posted at the link below. No slides received yet. Thanks to those who have started sending their obj= ectives to the Chairs. Thanks! Dave From: David A Sinicrope > Date: Wednesday, July 18, 2012 3:28 PM To: "IETF.PWE3" > Cc: David A Sinicrope > Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Thanks to all who sent me their requests. The initial agenda for PWE3 is p= osted at: http://www.ietf.org/proceedings/84/agenda/agenda-84-pwe3 If you requested a slot, please make sure your draft is listed on the agend= a. Note that the time allocation may have been reduced to fit into the 90 = PWE3 session. If you requested a slot and your draft is not present on the agenda, please= resend your request by replying to me. Those that are listed on the agenda: 1. Please send an email to me and the Chairs noting what objectives and iss= ues need to be discussed and resolved via the presentation. 2. Your slides are due into me for upload no later than Monday, July 30, 20= 12 ** 2pm ** Vancouver time. Please send me the slides by attaching to a r= eply to this email. Presenters submitting late/no slides and objectives risk losing their prese= ntation slot. Thanks! Dave -----Original Message----- From: David A Sinicrope > Date: Wednesday, June 27, 2012 3:51 PM To: "IETF.PWE3" > Subject: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Hi All, If you need a presentation slot for the IETF 84 PWE3 session, please reply = to this email (subject intact) with: -topic -draft name -requested duration -speaker name Thanks, Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From gregory.mirsky@ericsson.com Mon Jul 23 10:00:44 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8511E80BD for ; Mon, 23 Jul 2012 10:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZiW8pj55-Ps for ; Mon, 23 Jul 2012 10:00:43 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC0711E80B3 for ; Mon, 23 Jul 2012 10:00:41 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6NGxHFd008837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jul 2012 12:00:40 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.13]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 23 Jul 2012 13:00:17 -0400 From: Gregory Mirsky To: "pwe3 (pwe3@ietf.org)" Date: Mon, 23 Jul 2012 13:00:15 -0400 Thread-Topic: New Version Notification for draft-mirsky-mpls-tp-cv-adv-01.txt Thread-Index: Ac1hPJ1xjMBQslo/QOiPQZatU5fZqgCNu7HAAV/CoZA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [PWE3] FW: New Version Notification for draft-mirsky-mpls-tp-cv-adv-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 17:00:44 -0000 =20 Dear All, The new version was recently publish to address discussion at IETF-83 meeti= ng in Paris. I welcome your comments and will greatly appreciate consideration to adopt = the draft as PWE3 WG document. Regards, Greg -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Friday, July 13, 2012 2:15 PM To: Gregory Mirsky Subject: New Version Notification for draft-mirsky-mpls-tp-cv-adv-01.txt A new version of I-D, draft-mirsky-mpls-tp-cv-adv-01.txt has been successfully submitted by Greg Mirsky and posted to the IETF repos= itory. Filename: draft-mirsky-mpls-tp-cv-adv Revision: 01 Title: VCCV MPLS-TP Connectivity Verification (CV) Capability Advertiseme= nt Creation date: 2012-07-13 WG ID: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-mirsky-mpls-tp-c= v-adv-01.txt Status: http://datatracker.ietf.org/doc/draft-mirsky-mpls-tp-cv-ad= v Htmlized: http://tools.ietf.org/html/draft-mirsky-mpls-tp-cv-adv-01 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-mirsky-mpls-tp-= cv-adv-01 Abstract: This document specifies how use of proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile [RFC6428] affects operation and management function election for PW VCCV [RFC5085], [RFC5885]. = =20 The IETF Secretariat From amalis@gmail.com Mon Jul 23 10:25:40 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F8121F863C for ; Mon, 23 Jul 2012 10:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkgmHmoIuHNp for ; Mon, 23 Jul 2012 10:25:40 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC9821F861B for ; Mon, 23 Jul 2012 10:25:40 -0700 (PDT) Received: by ggnc4 with SMTP id c4so6267808ggn.31 for ; Mon, 23 Jul 2012 10:25:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9sZT2/ZPUoEMoqQC5tEBUICLWx6Mt3fOdr7CI9VfIXY=; b=TuAZ64W601FrAuxVCjKLwUjXYWKxp3BSlEU8ENaOiHH7ERb7jtkoSV0Le4XGM67z3q ShDz3rev+NS/ZELin7VfGzwu5ZpZzSXr2i73EsgI6o6Y5srzm2PhpztBp6RiQ1Yt8HV5 el4eYnfE1jeTVr4E3Atj+zWIeETnf0s6nuSI2k7G6Sa7IGdX5COEbTu+eqCSh0rHlyuN z211qwSLw7Ff8rclWz4kyThqcUG05KULp+FwxYhW3/KEoXJ8xiha7m26u52ha213ElBU LKQMgZL8kYNDkevpcrTniUVngW/F7O5VQV0S9EtzV5RcDc7w85qsWIBrio1+QLrkyPlX jr8Q== Received: by 10.50.182.232 with SMTP id eh8mr14909728igc.48.1343064339305; Mon, 23 Jul 2012 10:25:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.98.136 with HTTP; Mon, 23 Jul 2012 10:25:19 -0700 (PDT) In-Reply-To: References: From: "Andrew G. Malis" Date: Mon, 23 Jul 2012 13:25:19 -0400 Message-ID: To: Gregory Mirsky Content-Type: text/plain; charset=ISO-8859-1 Cc: "pwe3 \(pwe3@ietf.org\)" Subject: Re: [PWE3] FW: New Version Notification for draft-mirsky-mpls-tp-cv-adv-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 17:25:41 -0000 Greg, Thanks for updating and calling for discussion on the list. Matthew and I will discuss whether we should call for WG adoption. If we do, it won't be until after the IETF meeting. Cheers, Andy On Mon, Jul 23, 2012 at 1:00 PM, Gregory Mirsky wrote: > > Dear All, > The new version was recently publish to address discussion at IETF-83 meeting in Paris. > I welcome your comments and will greatly appreciate consideration to adopt the draft as PWE3 WG document. > > Regards, > Greg > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, July 13, 2012 2:15 PM > To: Gregory Mirsky > Subject: New Version Notification for draft-mirsky-mpls-tp-cv-adv-01.txt > > > A new version of I-D, draft-mirsky-mpls-tp-cv-adv-01.txt > has been successfully submitted by Greg Mirsky and posted to the IETF repository. > > Filename: draft-mirsky-mpls-tp-cv-adv > Revision: 01 > Title: VCCV MPLS-TP Connectivity Verification (CV) Capability Advertisement > Creation date: 2012-07-13 > WG ID: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-mirsky-mpls-tp-cv-adv-01.txt > Status: http://datatracker.ietf.org/doc/draft-mirsky-mpls-tp-cv-adv > Htmlized: http://tools.ietf.org/html/draft-mirsky-mpls-tp-cv-adv-01 > Diff: http://tools.ietf.org/rfcdiff?url2=draft-mirsky-mpls-tp-cv-adv-01 > > Abstract: > This document specifies how use of proactive Connectivity > Verification, Continuity Check, and Remote Defect Indication for the > MPLS Transport Profile [RFC6428] affects operation and management > function election for PW VCCV [RFC5085], [RFC5885]. > > > > > The IETF Secretariat > _______________________________________________ > pwe3 mailing list > pwe3@ietf.org > https://www.ietf.org/mailman/listinfo/pwe3 From lizhong.jin@zte.com.cn Mon Jul 23 20:25:34 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387B811E8112 for ; Mon, 23 Jul 2012 20:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.545 X-Spam-Level: X-Spam-Status: No, score=-101.545 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fNK7Wwaxf3uP for ; Mon, 23 Jul 2012 20:25:33 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id EAE2C11E8110 for ; Mon, 23 Jul 2012 20:25:32 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107231397396305; Tue, 24 Jul 2012 11:13:54 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 46806.3415362422; Tue, 24 Jul 2012 11:25:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6O3PIDW059434; Tue, 24 Jul 2012 11:25:19 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) To: pwe3@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: Lizhong Jin Date: Tue, 24 Jul 2012 11:25:11 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-24 11:25:17, Serialize complete at 2012-07-24 11:25:17 Content-Type: multipart/alternative; boundary="=_alternative 0012CAED48257A45_=" X-MAIL: mse01.zte.com.cn q6O3PIDW059434 Subject: [PWE3] FW: New Version Notification for draft-jc-pwe3-static-config-check-00.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 03:25:34 -0000 This is a multipart message in MIME format. --=_alternative 0012CAED48257A45_= Content-Type: text/plain; charset="US-ASCII" Hi all, Draft-jc-pwe3-static-config-check-00 is the updated version of draft-jc-pwe3-mpls-tp-static-checking-00 (http://tools.ietf.org/html/draft-jc-pwe3-mpls-tp-static-checking-00) which had been presented at IETF83 Paris meeting. After receiving the comments from the meeting and mailing list, we change the draft name, and the updates include: 1. Extending static PW checking for both MPLS-TP and Non-TP; 2. New Static PW FEC Element TLV is defined, instead of using Generalized ID FEC; 3. TX/RX Sequence number is used to ensure message delivery, instead of using local and remote PW element. 4. Control word configuration checking update; Any more comments are appreciated. Thank you. Regards Lizhong ----- Forwarded by Lizhong Jin on 2012/07/24 11:16 ----- internet-drafts@ietf.org wrote 2012/07/06 11:55:41: > > A new version of I-D, draft-jc-pwe3-static-config-check-00.txt > has been successfully submitted by Lizhong Jin and posted to the > IETF repository. > > Filename: draft-jc-pwe3-static-config-check > Revision: 00 > Title: Static pseudowire configuration checking using Generic > Associated Channel (G-ACh) Advertisement Protocol > Creation date: 2012-07-06 > WG ID: Individual Submission > Number of pages: 10 > URL: http://www.ietf.org/internet-drafts/draft-jc-pwe3- > static-config-check-00.txt > Status: http://datatracker.ietf.org/doc/draft-jc-pwe3- > static-config-check > Htmlized: http://tools.ietf.org/html/draft-jc-pwe3-static- > config-check-00 > > > Abstract: > This draft defines a method to verify the configuration parameters of > static pseudowires (PW). Since a static PW can be independently > provisioned at each end of the PW there is a potential for a > configuration parameter mismatch and this can result in the PW not > being operational. The procedures in this draft intend to solve this > problem and simplify the provisioning. > > > > > The IETF Secretariat > --=_alternative 0012CAED48257A45_= Content-Type: text/html; charset="US-ASCII"
Hi all,
Draft-jc-pwe3-static-config-check-00 is the updated version of draft-jc-pwe3-mpls-tp-static-checking-00 (http://tools.ietf.org/html/draft-jc-pwe3-mpls-tp-static-checking-00) which had been presented at IETF83 Paris meeting.
After receiving the comments from the meeting and mailing list, we change the draft name, and the updates include:
1. Extending static PW checking for both MPLS-TP and Non-TP;
2. New Static PW FEC Element TLV is defined, instead of using Generalized ID FEC;
3. TX/RX Sequence number is used to ensure message delivery, instead of using local and remote PW element.
4. Control word configuration checking update;

Any more comments are appreciated. Thank you.

Regards
Lizhong

 
----- Forwarded by Lizhong Jin on 2012/07/24 11:16 -----

internet-drafts@ietf.org wrote 2012/07/06 11:55:41:

>
> A new version of I-D, draft-jc-pwe3-static-config-check-00.txt
> has been successfully submitted by Lizhong Jin and posted to the
> IETF repository.
>
> Filename:    draft-jc-pwe3-static-config-check
> Revision:    00
> Title:       Static pseudowire configuration checking using Generic
> Associated Channel (G-ACh) Advertisement Protocol
> Creation date:    2012-07-06
> WG ID:       Individual Submission
> Number of pages: 10
> URL:             http://www.ietf.org/internet-drafts/draft-jc-pwe3-
> static-config-check-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-jc-pwe3-
> static-config-check
> Htmlized:        http://tools.ietf.org/html/draft-jc-pwe3-static-
> config-check-00
>
>
> Abstract:
>    This draft defines a method to verify the configuration parameters of
>    static pseudowires (PW).  Since a static PW can be independently
>    provisioned at each end of the PW there is a potential for a
>    configuration parameter mismatch and this can result in the PW not
>    being operational.  The procedures in this draft intend to solve this
>    problem and simplify the provisioning.
>
>                                                                              
>
>
> The IETF Secretariat
>
--=_alternative 0012CAED48257A45_=-- From iesg-secretary@ietf.org Wed Jul 25 08:48:48 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654B021F8679; Wed, 25 Jul 2012 08:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XQcsDMl5ZFm; Wed, 25 Jul 2012 08:48:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4057321F8682; Wed, 25 Jul 2012 08:48:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.30p3 Message-ID: <20120725154847.32276.89181.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2012 08:48:47 -0700 Cc: pwe3 mailing list , pwe3 chair , RFC Editor Subject: [PWE3] Protocol Action: 'Pseudowire Control Word Negotiation Mechanism Update' to Proposed Standard (draft-ietf-pwe3-cbit-negotiation-05.txt) X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 15:48:48 -0000 The IESG has approved the following document: - 'Pseudowire Control Word Negotiation Mechanism Update' (draft-ietf-pwe3-cbit-negotiation-05.txt) as Proposed Standard This document is the product of the Pseudowire Emulation Edge to Edge Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-pwe3-cbit-negotiation/ Technical Summary This document solves a particular problem with the control word negotiation mechanism specified in RFC 4447. Based on the problem analysis, a message exchanging mechanism is introduced to solve the control word negotiation issue. This document updates the RFC 4447 control word negotiation mechanism. This update is fully backwards compatible with existing implementations. Working Group Summary This draft had strong consensus in the WG, and received good comments at the various stages of its development. For more information please see the entry in document history log in the tracker posted on 21/June/2012. Document Quality To quote the Shepherd: There is at least one known vendor implementation of the draft (the reporter says "Our product manager asked me to thank IETF&PWE3 to help to solve this problem"), and other vendors have expressed implementation plans. Personnel Andrew Malis is the Document Shepherd for this document. Stewart Bryant is the Responsible Area Director. From gregory.mirsky@ericsson.com Wed Jul 25 16:09:08 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6CDF21F86A7; Wed, 25 Jul 2012 16:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LE0yVEnTFzJJ; Wed, 25 Jul 2012 16:09:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3C36D21F8629; Wed, 25 Jul 2012 16:09:08 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q6PN91uR009682; Wed, 25 Jul 2012 18:09:03 -0500 Received: from EUSAACMS0715.eamcs.ericsson.se ([169.254.1.13]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 25 Jul 2012 19:08:58 -0400 From: Gregory Mirsky To: Yaakov Stein , "odonoghue@isoc.org" , "Bocci, Matthew (Matthew)" , "Malis, Andrew G (Andy)" Date: Wed, 25 Jul 2012 19:08:56 -0400 Thread-Topic: Status of http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02.txt Thread-Index: Ac1qundHmlCeo+1IQFiYa+Birxd0aQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FE60A4E52763E84B935532D7D9294FF13924C82A19EUSAACMS0715e_" MIME-Version: 1.0 Cc: "pwe3 \(pwe3@ietf.org\)" , "tictoc@ietf.org" Subject: [PWE3] Status of http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 23:09:09 -0000 --_000_FE60A4E52763E84B935532D7D9294FF13924C82A19EUSAACMS0715e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Chairs, et al., I found that draft Transporting PTP messages (1588) over MPLS Networks been= scheduled for presentation at both TICTOC and PWE3 sessions at IETF-84. AF= AIK, the draft expired as of April 9, 2012 and that is confirmed by IETF Da= tatracker https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls/. Discussion of the version -02 already took place and, according to minutes = from TICTOC meeting at IETF-83 in Paris, concluded with "Some attendees wis= h to wait for version 03 before commenting further." Which version will be presented this time - -02 or else? Regards, Greg --_000_FE60A4E52763E84B935532D7D9294FF13924C82A19EUSAACMS0715e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Chairs, et al.,
I found that draft Transporting PTP messages (1588) over MPLS Networks= been scheduled for presentation at both TICTOC and PWE3 sessions at IETF-8= 4. AFAIK, the draft expired as of April 9, 2012 and that is confirmed by IE= TF Datatracker https://datatracker.ietf.org/do= c/draft-ietf-tictoc-1588overmpls/.
Discussion of the version -02 already took place and, according to min= utes from TICTOC meeting at IETF-83 in Paris, concluded with "Some att= endees wish to wait for version 03 before commenting further."
Which version will be presented this time - -02 or else?
 
        Regards,
           &nbs= p;    Greg
 
 --_000_FE60A4E52763E84B935532D7D9294FF13924C82A19EUSAACMS0715e_-- From yaakov_s@rad.com Wed Jul 25 21:47:35 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37DF21F84DE for ; Wed, 25 Jul 2012 21:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.411 X-Spam-Level: X-Spam-Status: No, score=-102.411 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykmZbxG72nNQ for ; Wed, 25 Jul 2012 21:47:34 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id 62CDB21F84CE for ; Wed, 25 Jul 2012 21:47:31 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 26 Jul 2012 07:09:17 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Thu, 26 Jul 2012 07:47:27 +0300 From: Yaakov Stein To: Gregory Mirsky , "odonoghue@isoc.org" , "Bocci, Matthew (Matthew)" , "Malis, Andrew G (Andy)" Thread-Topic: Status of http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02.txt Thread-Index: Ac1qundHmlCeo+1IQFiYa+Birxd0aQALq42A Date: Thu, 26 Jul 2012 04:47:26 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC9045263C7@EXRAD5.ad.rad.co.il> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: multipart/alternative; boundary="_000_07F7D7DED63154409F13298786A2ADC9045263C7EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A090204.5010CBE0.0058,ss=1,fgs=0 Cc: "pwe3 \(pwe3@ietf.org\)" , "tictoc@ietf.org" Subject: Re: [PWE3] Status of http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpls-02.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 04:47:35 -0000 --_000_07F7D7DED63154409F13298786A2ADC9045263C7EXRAD5adradcoil_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg The draft authors could not generate a new version before the cutoff. The discussion will be about the 03 version which hopefully resolves all ou= tstanding issues. (Note: I call it a 03 version, but actually the document is being split int= o several documents.) If I receive a new version I will post it on a non-IETF site before the pre= sentation at TICTOC. Y(J)S From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] Sent: Thursday, July 26, 2012 02:09 To: Yaakov Stein; odonoghue@isoc.org; Bocci, Matthew (Matthew); Malis, Andr= ew G (Andy) Cc: tictoc@ietf.org; pwe3 (pwe3@ietf.org) Subject: Status of http://tools.ietf.org/html/draft-ietf-tictoc-1588overmpl= s-02.txt Dear Chairs, et al., I found that draft Transporting PTP messages (1588) over MPLS Networks been= scheduled for presentation at both TICTOC and PWE3 sessions at IETF-84. AF= AIK, the draft expired as of April 9, 2012 and that is confirmed by IETF Da= tatracker https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls/. Discussion of the version -02 already took place and, according to minutes = from TICTOC meeting at IETF-83 in Paris, concluded with "Some attendees wis= h to wait for version 03 before commenting further." Which version will be presented this time - -02 or else? Regards, Greg --_000_07F7D7DED63154409F13298786A2ADC9045263C7EXRAD5adradcoil_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg

 

The draft authors could not generate a new version before th= e cutoff.

 

The discussion will be about the 03 version which hopefully = resolves all outstanding issues.

(Note: I call it a 03 version, but actually the document is = being split into several documents.)

 

If I receive a new version I will post it on a non-IETF site= before the presentation at TICTOC.

 

Y(J)S

 

From: Gregory = Mirsky [mailto:gregory.mirsky@ericsson.com]
Sent: Thursday, July 26, 2012 02:09
To: Yaakov Stein; odonoghue@isoc.org; Bocci, Matthew (Matthew); Mali= s, Andrew G (Andy)
Cc: tictoc@ietf.org; pwe3 (pwe3@ietf.org)
Subject: Status of http://tools.ietf.org/html/draft-ietf-tictoc-1588= overmpls-02.txt

 

Dear Chairs, et al.,

I found that draft Transporting PTP messa= ges (1588) over MPLS Networks been scheduled for presentation at both TICTO= C and PWE3 sessions at IETF-84. AFAIK, the draft expired as of April 9, 2012 and that is confirmed by IETF Datatracker https://datatracker.ietf.org/doc/draft-ietf-tictoc-1588overmpls/.<= /o:p>

Discussion of the version -02 already too= k place and, according to minutes from TICTOC meeting at IETF-83 in Paris, = concluded with "Some attendees wish to wait for version 03 before commenting further."

Which version will be presented this time= - -02 or else?

 

       = ; Regards,

       = ;         Greg

 

--_000_07F7D7DED63154409F13298786A2ADC9045263C7EXRAD5adradcoil_-- From matthew.bocci@alcatel-lucent.com Thu Jul 26 07:07:06 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACC421F8776; Thu, 26 Jul 2012 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.791 X-Spam-Level: X-Spam-Status: No, score=-107.791 tagged_above=-999 required=5 tests=[AWL=-1.543, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HsOXim9IgZv; Thu, 26 Jul 2012 07:07:04 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [62.23.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 31ABE21F876E; Thu, 26 Jul 2012 07:07:03 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6QE70oA012037 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Jul 2012 16:07:00 +0200 Received: from FRMRSSXCHMBSA3.dc-m.alcatel-lucent.com ([135.120.45.36]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 26 Jul 2012 16:07:00 +0200 From: "Bocci, Matthew (Matthew)" To: Stewart Bryant , The IESG Date: Thu, 26 Jul 2012 16:06:58 +0200 Thread-Topic: Publication request for draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Thread-Index: Ac1rN+wmpTaxik89TWCNclEXLjJ/uA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CC370D9230A75matthewboccialcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "pwe3@ietf.org" Subject: [PWE3] Publication request for draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 14:07:06 -0000 --_000_CC370D9230A75matthewboccialcatellucentcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PWE3 working group requests publication of draft-ietf-pwe3-mpls-eth-oam= -iwk-06.txt as a standards track RFC. Please find the document write-up below. Best regards, Matthew draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt Document Shepherd Write-Up (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? Standards track. This is appropriate as the draft describes a set of procedures for interworking defect notifications between Ethernet attachment circuits and PWs that will have interoperability implications. The intended status is properly indicated. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies the mapping of defect states between Ethernet Attachment Circuits (ACs) and associated Ethernet Pseudowires (PWs) connected in accordance to the PWE3 architecture to realize an end-to-end emulated Ethernet service. It standardizes the behavior of Provider Edges (PEs) with respect to Ethernet PW and AC defects. Working Group Summary Solutions for mapping OAM messages related to defect notifications fro= m attachement circuits to PWs for ATM, FR, and TDM services were specified in RFC6310. This RFC did not cover Ethernet attachment circuits because of a perception at the time that Ethernet OAM mechanisms were less widel= y deployed and their standardization was on-going. The WG decided to handl= e the Ethernet case in a separate draft. This was considered to be an impo= rtant work item by the PWE3 working group, and there were a number of requests= to roll this working into the draft that became RFC6310. However, ultimatel= y the consensus was to progress the Ethernet case separately to not further de= lay RFC6310. The document received two working group last calls, the second as a resu= lt of IPR declaration 1781. The second WG last call resulted in the security secti= on being improved, but no issues were raised about the IPR declaration. Document Quality Previous PW deployment surveys (see draft-ietf-pwe3-pw-vccv-impl-survey-results-00) have indicated that the majority of PWs are Ethernet, and therefore standardizing the interworki= ng of defect notifications for emulated Ethernet services is expected to be of significant interest to the IETF and the operator community in genera= l. There are believed to be numerous implementations and deployments of Eth= ernet OAM mechanisms referred to in this draft, including cases where the Ethe= rnet service is supported over PWs and where OAM interworking is used. The document does not specify any MIB changes or additions which would n= eed review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@alcatel-lucent.com= ). The responsible Area Director is Stewart Bryant (stbryant@cisco.com). (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd reviewed the document and provided detailed technic= al and editorial comments. This were addressed by the authors before progres= sing the draft. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has received significant review by the WG over a number of years and received a number of comments during WG last call. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No further review required. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No specific concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each author listed in the Authors Addresses section has indicated that they are not aware of any IPR that has not been declared in accordance with BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR declaration (1781) that was made after the original WG l= ast call. The document was given a second WG last call as a result of this. There w= ere no issues raised as a result of this. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It ha= s been discussed over a period of a number of years, both in face to face IE= TF meetings and on the list. It has also been through two working group last call= s with comments raised at each. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) None indicated. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Yes. There is one I-D nits warning related to some pages with too man= y lines. This results in I-D Nits generating an additional false comments. There are also a few spelling or gramatical errors. These should be fixed before publication. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. There is a downward normative reference to the published MetroEthernet Fo= rum specification MEF16. It is reasonable to require conformance to MEF16 for= any interworking between PW OAM and MEF16. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document does not change the status of any existing RFCs. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). There are no IANA actions. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. There are no IANA actions. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no sections containing formal language that needs reviewing. --_000_CC370D9230A75matthewboccialcatellucentcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The PWE3 working group r= equests publication of draft-ietf-pwe3-mpls-eth-oam-iwk-06.txt as a st= andards track RFC.

Please find the document write-= up below.

Best regards,

M= atthew

draft-ietf-pwe3-mpls-eth-oam-iwk-06.tx= t

Document Shepherd Write-Up

<= div>(1) What type of RFC is being requested (BCP, Proposed Standard,
<= div>Internet Standard, Informational, Experimental, or Historic)?  Why=
is this the proper type of RFC?  Is this type of RFC indica= ted in the
title page header?

  &nb= sp;Standards track.
   
   This is = appropriate as the draft describes a set of procedures for
 =  interworking defect notifications between Ethernet attachment circui= ts
   and PWs that will have interoperability implicati= ons.
   
   The intended status is = properly indicated.

(2) The IESG approval announce= ment includes a Document Announcement
Write-Up. Please provide su= ch a Document Announcement Write-Up. Recent
examples can be found= in the "Action" announcements for approved
documents. The approv= al announcement contains the following sections:

T= echnical Summary

  This document specifies th= e mapping of defect states between
  Ethernet Attachment Cir= cuits (ACs) and associated Ethernet
  Pseudowires (PWs) conn= ected in accordance to the PWE3
  architecture to realize an= end-to-end emulated Ethernet service.
  It standardizes the= behavior of Provider Edges (PEs) with
  respect to Ethernet= PW and AC defects.


Working Group S= ummary

     Solutions for mapping O= AM messages related to defect notifications from 
  &nb= sp;attachement circuits to PWs for ATM, FR, and TDM services were specified=
   in RFC6310. This RFC did not cover Ethernet attachm= ent circuits because
   of a perception at the time tha= t Ethernet OAM mechanisms were less widely 
   dep= loyed and their standardization was on-going. The WG decided to handle = ;
   the Ethernet case in a separate draft. This was co= nsidered to be an important 
   work item by the P= WE3 working group, and there were a number of requests to 
&= nbsp;  roll this working into the draft that became RFC6310. However, = ultimately the 
   consensus was to progress the E= thernet case separately to not further delay RFC6310.
  &nbs= p;
   The document received two working group last call= s, the second as a result of IPR
   declaration 1781. T= he second WG last call resulted in the security section being
&nb= sp;  improved, but no issues were raised about the IPR declaration.&nb= sp;

Document Quality

&nbs= p;  Previous PW deployment surveys (see 
   d= raft-ietf-pwe3-pw-vccv-impl-survey-results-00) have indicated that the = ;
   majority of PWs are Ethernet, and therefore standa= rdizing the interworking 
   of defect notificatio= ns for emulated Ethernet services is expected to be
   = of significant interest to the IETF and the operator community in general.&= nbsp;
   There are believed to be numerous implementati= ons and deployments of Ethernet 
   OAM mechanisms= referred to in this draft, including cases where the Ethernet
&n= bsp;  service is supported over PWs and where OAM interworking is used= .

   The document does not specify any M= IB changes or additions which would need review.

&= nbsp;  
  
Personnel

   The document shepherd is Matthew Bocci (matthew.bocci@al= catel-lucent.com).
   The responsible Area Director is = Stewart Bryant (stbryant@cisco.com).

(3) Briefly d= escribe the review of this document that was performed by
the Doc= ument Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The document shepherd rev= iewed the document and provided detailed technical
  and edi= torial comments. This were addressed by the authors before progressing
  the draft.

(4) Does the document Shep= herd have any concerns about the depth or
breadth of the reviews = that have been performed? 

  No concerns= . The document has received adequate review. The document has
&nb= sp;       received significant review by the WG over a numbe= r of years and 
        received a numbe= r 
        of comments during WG last ca= ll. 

(5) Do portions of the document need rev= iew from a particular or from
broader perspective, e.g., security= , operational complexity, AAA, DNS,
DHCP, XML, or internationaliz= ation? If so, describe the review that
took place.

=
   No further review required.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or t= he
IESG should be aware of? For example, perhaps he or she is unc= omfortable
with certain parts of the document, or has concerns wh= ether there really
is a need for it. In any event, if the WG has = discussed those issues and
has indicated that it still wishes to = advance the document, detail those
concerns here.

<= /div>
  No specific concerns.

(7) Has eac= h author confirmed that any and all appropriate IPR
disclosures r= equired for full conformance with the provisions of BCP 78
and BC= P 79 have already been filed. If not, explain why.

   Each author listed in the Authors Addresses section has indic= ated that
   they are not aware of any IPR that has not= been declared in accordance
   with BCP 78 and 79.

(8) Has an IPR disclosure been filed that references = this document?
If so, summarize any WG discussion and conclusion = regarding the IPR
disclosures.

  Th= ere is one IPR declaration (1781) that was made after the original WG last = call.
  The document was given a second WG last call as a re= sult of this. There were no issues
  raised as a result of t= his.
  
(9) How solid is the WG consensus beh= ind this document? Does it 
represent the strong concurrence= of a few individuals, with others
being silent, or does the WG a= s a whole understand and agree with it? 

&nbs= p;   I am comfortable that the document represents WG consensus and ha= s
      been reviewed by a reasonable number of ac= tive WG participants. It has been 
      disc= ussed over a period of a number of years, both in face to face IETF meeting= s
      and on the list. It has also been through = two working group last calls with comments
      r= aised at each. 

(10) Has anyone threatened an= appeal or otherwise indicated extreme 
discontent? If so, p= lease summarise the areas of conflict in separate
email messages = to the Responsible Area Director. (It should be in a
separate ema= il because this questionnaire is publicly available.) 

<= /div>
  None indicated.

(11) Identify any= ID nits the Document Shepherd has found in this
document. (See h= ttp://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklis= t). Boilerplate checks are not enough; this check needs to be
tho= rough.

      Yes. There is one I-D = nits warning related to some pages with too many lines.
  &n= bsp;   This results in I-D Nits generating an  additional false c= omments. 
      There are also a few spelling= or gramatical errors.  
       These sh= ould be fixed before publication.


(= 12) Describe how the document meets any required formal review
cr= iteria, such as the MIB Doctor, media type, and URI type reviews.

   There are no relevant formal review criteria.<= /div>

(13) Have all references within this document been= identified as
either normative or informative?

  Yes

(14) Are there normative refere= nces to documents that are not ready for
advancement or are other= wise in an unclear state? If such normative
references exist, wha= t is the plan for their completion?

  No

(15) Are there downward normative references reference= s (see RFC 3967)?
If so, list these downward references to suppor= t the Area Director in the
Last Call procedure.

  There is a downward normative reference to the published Met= roEthernet Forum 
  specification MEF16. It is reasonab= le to require conformance to MEF16 for any 
  interwork= ing between PW OAM and MEF16. 

(16) Will publ= ication of this document change the status of any
existing RFCs? = Are those RFCs listed on the title page header, listed
in the abs= tract, and discussed in the introduction? If the RFCs are not
lis= ted in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,<= /div>
explain why the WG considers it unnecessary.

=
  This document does not change the status of any existing RFCs.<= /div>

(17) Describe the Document Shepherd's review of th= e IANA considerations
section, especially with regard to its cons= istency with the body of the
document. Confirm that all protocol = extensions that the document makes
are associated with the approp= riate reservations in IANA registries.
Confirm that any reference= d IANA registries have been clearly
identified. Confirm that newl= y created IANA registries include a
detailed specification of the= initial contents for the registry, that
allocations procedures f= or future registrations are defined, and a
reasonable name for th= e new registry has been suggested (see RFC 5226).

=    There are no IANA actions.

(18) List = any new IANA registries that require Expert Review for future
all= ocations. Provide any public guidance that the IESG would find
us= eful in selecting the IANA Experts for these new registries.

=
   There are no IANA actions.

(19) Describe reviews and automated checks performed by the Document
=
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

   There are no sections containing formal langu= age that needs reviewing.

--_000_CC370D9230A75matthewboccialcatellucentcom_-- From internet-drafts@ietf.org Mon Jul 30 10:22:14 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB1211E814B; Mon, 30 Jul 2012 10:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeZN7cBXXQxV; Mon, 30 Jul 2012 10:22:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E0911E8143; Mon, 30 Jul 2012 10:22:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730172214.13660.89787.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2012 10:22:14 -0700 Cc: pwe3@ietf.org Subject: [PWE3] I-D Action: draft-ietf-pwe3-iccp-09.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:22:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Pseudowire Emulation Edge to Edge Working= Group of the IETF. Title : Inter-Chassis Communication Protocol for L2VPN PE Redund= ancy Author(s) : Luca Martini Samer Salam Ali Sajassi Satoru Matsushima Filename : draft-ietf-pwe3-iccp-09.txt Pages : 80 Date : 2012-07-30 Abstract: This document specifies an inter-chassis communication protocol (ICCP) that enables Provider Edge (PE) device redundancy for Virtual Private Wire Service (VPWS) and Virtual Private LAN Service (VPLS) applications. The protocol runs within a set of two or more PEs, forming a redundancy group, for the purpose of synchronizing data amongst the systems. It accommodates multi-chassis attachment circuit as well as pseudowire redundancy mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pwe3-iccp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-pwe3-iccp-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-pwe3-iccp-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From amalis@gmail.com Mon Jul 30 11:06:09 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142FE21F8685 for ; Mon, 30 Jul 2012 11:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.446 X-Spam-Level: X-Spam-Status: No, score=-103.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id azc53h+m7u4d for ; Mon, 30 Jul 2012 11:06:08 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F87421F8679 for ; Mon, 30 Jul 2012 11:06:08 -0700 (PDT) Received: by ghbg16 with SMTP id g16so5552129ghb.31 for ; Mon, 30 Jul 2012 11:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=uYNKzNUFQ7G4Rq+9AyojbWpHwapZAx7XkOPvsKN1oUI=; b=fOHoVIpgEfqDtAX3BEZ2aDPadSiJnwcDLIZF/t5s3CweNW2uhrKIfMZFnav97/HZJu 3W6q3ed57XjhL7Kec0pKW2DwHsdiQHfR9yzQDZluaL/5R7jG8wzGqX3LWXRMhFQGoQqg PkRYferJYW8CaeNau5/lHRKhmt7pdIzqrP/ZpM9mXgcZp2Hy4wzwRHLhGp7uptHRSHfa DURHJIYD3xDr4HKVI2E/c14GXvFJ5P+JXqhNBaGa33pOuY9yR1GqP3Nup6zMSrnpRAAL 0aR8kqFRYXjx2ynGJ29SU0eNyoJvnrY3OKjoshlP8i6OIjaOknHAVNaz0/pQLir/98SL ZZ4Q== Received: by 10.60.3.194 with SMTP id e2mr18870124oee.1.1343671567474; Mon, 30 Jul 2012 11:06:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.34.193 with HTTP; Mon, 30 Jul 2012 11:05:47 -0700 (PDT) In-Reply-To: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> References: <20120730032233.17770.35790.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Mon, 30 Jul 2012 11:05:47 -0700 Message-ID: To: pwe3@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [PWE3] Fwd: Need volunteers for the NomCom X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:06:09 -0000 PWE3ers, Please consider volunteering for NomCom (I have). Thanks, Andy ---------- Forwarded message ---------- From: NomCom Chair Date: Sun, Jul 29, 2012 at 8:22 PM Subject: Need volunteers for the NomCom To: Working Group Chairs We are currently looking for volunteers to serve on the 2012-2013 NomCom. As you know, the success of the NomCom process depends crucially on having a large pool of volunteers from throughout the IETF community. In particular, it is valuable for the pool of volunteers to have strong representation from all of the technical areas within the IETF. I understand that not all IETF participants read the IETF announce list frequently. Therefore, if you would be willing to inform active participants in your working groups about this year's call for NomCom volunteers, I would greatly appreciate it. The NomCom 2012-2013 Call for Volunteers is open until this Sunday, August 5. Details can be found at: https://datatracker.ietf.org/ann/nomcom/49851/ Thank you for your help, - Matt Lepinski mlepinski.ietf@gmail.com nomcom-chair@ietf.org From david.sinicrope@ericsson.com Mon Jul 30 11:23:24 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3A21F8617 for ; Mon, 30 Jul 2012 11:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1mRwjpBAsc6 for ; Mon, 30 Jul 2012 11:23:24 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 23F5E21F85DF for ; Mon, 30 Jul 2012 11:23:23 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q6UINHM1014683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 30 Jul 2012 13:23:22 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.135]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Mon, 30 Jul 2012 14:23:16 -0400 From: David Sinicrope To: "IETF.PWE3" Date: Mon, 30 Jul 2012 14:23:15 -0400 Thread-Topic: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Thread-Index: Ac1ugGO3DUyNV6cdR2iT/OCWQAeDSA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 18:23:25 -0000 I just updated the agenda with the slides sent to me. (See http://www.ietf.= org/proceedings/84/agenda/agenda-84-pwe3) Please remember the slides are due to me for upload no later than 2PM Vanco= uver time today. Please send slides by attaching to a reply of this email. Also be sure to include the objectives for the presentation if you haven't = sent them separately. Presenters submitting late/no slides and objectives risk losing their prese= ntation slot. Thanks, Dave From: David A Sinicrope > Date: Wednesday, July 18, 2012 3:28 PM To: "IETF.PWE3" > Cc: David A Sinicrope > Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Thanks to all who sent me their requests. The initial agenda for PWE3 is p= osted at: http://www.ietf.org/proceedings/84/agenda/agenda-84-pwe3 If you requested a slot, please make sure your draft is listed on the agend= a. Note that the time allocation may have been reduced to fit into the 90 = PWE3 session. If you requested a slot and your draft is not present on the agenda, please= resend your request by replying to me. Those that are listed on the agenda: 1. Please send an email to me and the Chairs noting what objectives and iss= ues need to be discussed and resolved via the presentation. 2. Your slides are due into me for upload no later than Monday, July 30, 20= 12 ** 2pm ** Vancouver time. Please send me the slides by attaching to a r= eply to this email. Presenters submitting late/no slides and objectives risk losing their prese= ntation slot. Thanks! Dave -----Original Message----- From: David A Sinicrope > Date: Wednesday, June 27, 2012 3:51 PM To: "IETF.PWE3" > Subject: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver Hi All, If you need a presentation slot for the IETF 84 PWE3 session, please reply = to this email (subject intact) with: -topic -draft name -requested duration -speaker name Thanks, Dave _______________________________________________ pwe3 mailing list pwe3@ietf.org https://www.ietf.org/mailman/listinfo/pwe3 From zhang.fei3@zte.com.cn Mon Jul 30 19:35:00 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03FB211E80EA; Mon, 30 Jul 2012 19:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.892 X-Spam-Level: X-Spam-Status: No, score=-96.892 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jztGH2+pcS0W; Mon, 30 Jul 2012 19:34:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1FA21F842A; Mon, 30 Jul 2012 19:34:58 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 107233491178658; Tue, 31 Jul 2012 10:24:04 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 21262.6111660030; Tue, 31 Jul 2012 10:34:56 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q6V2YhxY063146; Tue, 31 Jul 2012 10:34:43 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: "Bocci, Matthew (Matthew)" , "Malis, Andrew G (Andy)" , David Sinicrope MIME-Version: 1.0 X-KeepSent: 95FDEEA0:32B3FBF5-48257A4C:000D1583; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 31 Jul 2012 10:34:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-31 10:34:41, Serialize complete at 2012-07-31 10:34:41 Content-Type: multipart/alternative; boundary="=_alternative 000E259248257A4C_=" X-MAIL: mse02.zte.com.cn q6V2YhxY063146 Cc: pwe3-bounces@ietf.org, "IETF.PWE3" Subject: Re: [PWE3] PWE3 IETF 84 Slot Requests - Vancouver X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:35:00 -0000 This is a multipart message in MIME format. --=_alternative 000E259248257A4C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNClJlZ2FyZGluZyBQVyBPQU0gQ29uZmlndXJhdGlvbiBkcmFmdCANCmh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdlMy1tcGxzLXRwLW9hbS1jb25maWctMDAs IG5vIA0KdXBkYXRlcyBmb3IgdGhpcyBpZXRmLiBIZXJlIGEgcm91Z2ggcGxhbiBmb3IgdGhlIG5l eHQgdmVyc2lvbg0KLSBNb3ZpbmcgdGhlIE9BTSBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIG91dCBv ZiB0aGlzIGRvY3VtZW50Lg0KLSBEZWxldGluZyB0aGUgcGFyYWdyYXBoIDMgIkFuYWx5c2lzIG9m IEV4aXN0aW5nIFBXIE9BTSBDb25maWd1cmF0aW9uIg0KDQpBbnkgb3RoZXIgY29tbWVudHM/DQoN CkNoZWVycw0KRmVpDQoNCg0KDQpEYXZpZCBTaW5pY3JvcGUgPGRhdmlkLnNpbmljcm9wZUBlcmlj c3Nvbi5jb20+IA0Kt6K8/sjLOiAgcHdlMy1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTA3LTMxIDAy OjIzDQoNCsrVvP7Iyw0KIklFVEYuUFdFMyIgPHB3ZTNAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3zOIN ClJlOiBbUFdFM10gUFdFMyBJRVRGIDg0IFNsb3QgUmVxdWVzdHMgLSBWYW5jb3V2ZXINCg0KDQoN Cg0KDQoNCkkganVzdCB1cGRhdGVkIHRoZSBhZ2VuZGEgd2l0aCB0aGUgc2xpZGVzIHNlbnQgdG8g bWUuIChTZWUgDQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg0L2FnZW5kYS9hZ2Vu ZGEtODQtcHdlMykNCg0KUGxlYXNlIHJlbWVtYmVyIHRoZSBzbGlkZXMgYXJlIGR1ZSB0byBtZSBm b3IgdXBsb2FkIG5vIGxhdGVyIHRoYW4gMlBNIA0KVmFuY291dmVyIHRpbWUgdG9kYXkuICBQbGVh c2Ugc2VuZCBzbGlkZXMgYnkgYXR0YWNoaW5nIHRvIGEgcmVwbHkgb2YgdGhpcyANCmVtYWlsLg0K QWxzbyBiZSBzdXJlIHRvIGluY2x1ZGUgdGhlIG9iamVjdGl2ZXMgZm9yIHRoZSBwcmVzZW50YXRp b24gaWYgeW91IGhhdmVuJ3QgDQpzZW50IHRoZW0gc2VwYXJhdGVseS4NCg0KUHJlc2VudGVycyBz dWJtaXR0aW5nIGxhdGUvbm8gc2xpZGVzIGFuZCBvYmplY3RpdmVzIHJpc2sgbG9zaW5nIHRoZWly IA0KcHJlc2VudGF0aW9uIHNsb3QuDQoNClRoYW5rcywNCkRhdmUNCg0KRnJvbTogRGF2aWQgQSBT aW5pY3JvcGUgPGRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb208DQptYWlsdG86ZGF2aWQuc2lu aWNyb3BlQGVyaWNzc29uLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMTgsIDIwMTIgMzoy OCBQTQ0KVG86ICJJRVRGLlBXRTMiIDxwd2UzQGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYub3Jn Pj4NCkNjOiBEYXZpZCBBIFNpbmljcm9wZSA8ZGF2aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbTwN Cm1haWx0bzpkYXZpZC5zaW5pY3JvcGVAZXJpY3Nzb24uY29tPj4NClN1YmplY3Q6IFJlOiBbUFdF M10gUFdFMyBJRVRGIDg0IFNsb3QgUmVxdWVzdHMgLSBWYW5jb3V2ZXINCg0KVGhhbmtzIHRvIGFs bCB3aG8gc2VudCBtZSB0aGVpciByZXF1ZXN0cy4gIFRoZSBpbml0aWFsIGFnZW5kYSBmb3IgUFdF MyBpcyANCnBvc3RlZCBhdDoNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84NC9h Z2VuZGEvYWdlbmRhLTg0LXB3ZTMNCg0KSWYgeW91IHJlcXVlc3RlZCBhIHNsb3QsIHBsZWFzZSBt YWtlIHN1cmUgeW91ciBkcmFmdCBpcyBsaXN0ZWQgb24gdGhlIA0KYWdlbmRhLiAgTm90ZSB0aGF0 IHRoZSB0aW1lIGFsbG9jYXRpb24gbWF5IGhhdmUgYmVlbiByZWR1Y2VkIHRvIGZpdCBpbnRvIA0K dGhlIDkwIFBXRTMgc2Vzc2lvbi4NCklmIHlvdSByZXF1ZXN0ZWQgYSBzbG90IGFuZCB5b3VyIGRy YWZ0IGlzIG5vdCBwcmVzZW50IG9uIHRoZSBhZ2VuZGEsIA0KcGxlYXNlIHJlc2VuZCB5b3VyIHJl cXVlc3QgYnkgcmVwbHlpbmcgdG8gbWUuDQoNCg0KVGhvc2UgdGhhdCBhcmUgbGlzdGVkIG9uIHRo ZSBhZ2VuZGE6DQoNCjEuIFBsZWFzZSBzZW5kIGFuIGVtYWlsIHRvIG1lIGFuZCB0aGUgQ2hhaXJz IG5vdGluZyB3aGF0IG9iamVjdGl2ZXMgYW5kIA0KaXNzdWVzIG5lZWQgdG8gYmUgZGlzY3Vzc2Vk IGFuZCByZXNvbHZlZCB2aWEgdGhlIHByZXNlbnRhdGlvbi4NCg0KMi4gWW91ciBzbGlkZXMgYXJl IGR1ZSBpbnRvIG1lIGZvciB1cGxvYWQgbm8gbGF0ZXIgdGhhbiBNb25kYXksIEp1bHkgMzAsIA0K MjAxMiAqKiAycG0gKiogVmFuY291dmVyIHRpbWUuICBQbGVhc2Ugc2VuZCBtZSB0aGUgc2xpZGVz IGJ5IGF0dGFjaGluZyB0byANCmEgcmVwbHkgdG8gdGhpcyBlbWFpbC4NCg0KDQpQcmVzZW50ZXJz IHN1Ym1pdHRpbmcgbGF0ZS9ubyBzbGlkZXMgYW5kIG9iamVjdGl2ZXMgcmlzayBsb3NpbmcgdGhl aXIgDQpwcmVzZW50YXRpb24gc2xvdC4NCg0KVGhhbmtzIQ0KRGF2ZQ0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBEYXZpZCBBIFNpbmljcm9wZSAgIDxkYXZpZC5zaW5pY3Jv cGVAZXJpY3Nzb24uY29tPA0KbWFpbHRvOmRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20+Pg0K RGF0ZTogV2VkbmVzZGF5LCBKdW5lIDI3LCAyMDEyIDM6NTEgUE0NClRvOiAiSUVURi5QV0UzIiA8 cHdlM0BpZXRmLm9yZzxtYWlsdG86cHdlM0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbUFdFM10gUFdF MyBJRVRGIDg0IFNsb3QgUmVxdWVzdHMgLSBWYW5jb3V2ZXINCg0KSGkgQWxsLA0KSWYgeW91IG5l ZWQgYSBwcmVzZW50YXRpb24gc2xvdCBmb3IgdGhlIElFVEYgODQgUFdFMyBzZXNzaW9uLCBwbGVh c2UgcmVwbHkgDQp0byB0aGlzIGVtYWlsIChzdWJqZWN0IGludGFjdCkgd2l0aDoNCi10b3BpYw0K LWRyYWZ0IG5hbWUNCi1yZXF1ZXN0ZWQgZHVyYXRpb24NCi1zcGVha2VyIG5hbWUNCg0KVGhhbmtz LA0KRGF2ZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CnB3ZTMgbWFpbGluZyBsaXN0DQpwd2UzQGlldGYub3JnPG1haWx0bzpwd2UzQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2UzDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlzdA0K cHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9wd2Uz DQoNCg0KDQo= --=_alternative 000E259248257A4C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBhbGw8YnI+DQo8YnI+DQpSZWdhcmRpbmcgUFcgT0FN IENvbmZpZ3VyYXRpb24gZHJhZnQgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1wd2UzLW1wbHMtdHAtb2FtLWNvbmZpZy0wMCwNCm5vIHVwZGF0ZXMgZm9yIHRoaXMgaWV0Zi4g SGVyZSBhIHJvdWdoIHBsYW4gZm9yIHRoZSBuZXh0IHZlcnNpb248YnI+DQotIE1vdmluZyB0aGUg T0FNIGNhcGFiaWxpdHkgbmVnb3RpYXRpb24gb3V0IG9mIHRoaXMgZG9jdW1lbnQuPGJyPg0KLSBE ZWxldGluZyB0aGUgcGFyYWdyYXBoIDMgJnF1b3Q7QW5hbHlzaXMgb2YgRXhpc3RpbmcgUFcgT0FN IENvbmZpZ3VyYXRpb24mcXVvdDs8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPkFueSBvdGhlciBjb21tZW50cz88YnI+DQo8YnI+DQpDaGVlcnM8YnI+DQpGZWk8L2ZvbnQ+ PC90dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQgd2lkdGg9MzYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5EYXZp ZCBTaW5pY3JvcGUgJmx0O2RhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3B3 ZTMtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj4yMDEyLTA3LTMxIDAyOjIzPC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0 aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O0lFVEYuUFdFMyZxdW90OyAmbHQ7cHdlM0BpZXRm Lm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPlJlOiBbUFdFM10gUFdFMyBJRVRGIDg0IFNsb3QgUmVxdWVzdHMNCi0gVmFuY291 dmVyPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N Cjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5JIGp1c3QgdXBkYXRlZCB0aGUgYWdlbmRhIHdpdGggdGhlIHNsaWRlcyBzZW50IHRvDQpt ZS4gKFNlZSBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg0L2FnZW5kYS9hZ2VuZGEt ODQtcHdlMyk8YnI+DQo8YnI+DQpQbGVhc2UgcmVtZW1iZXIgdGhlIHNsaWRlcyBhcmUgZHVlIHRv IG1lIGZvciB1cGxvYWQgbm8gbGF0ZXIgdGhhbiAyUE0gVmFuY291dmVyDQp0aW1lIHRvZGF5LiAm bmJzcDtQbGVhc2Ugc2VuZCBzbGlkZXMgYnkgYXR0YWNoaW5nIHRvIGEgcmVwbHkgb2YgdGhpcyBl bWFpbC48YnI+DQpBbHNvIGJlIHN1cmUgdG8gaW5jbHVkZSB0aGUgb2JqZWN0aXZlcyBmb3IgdGhl IHByZXNlbnRhdGlvbiBpZiB5b3UgaGF2ZW4ndA0Kc2VudCB0aGVtIHNlcGFyYXRlbHkuPGJyPg0K PGJyPg0KUHJlc2VudGVycyBzdWJtaXR0aW5nIGxhdGUvbm8gc2xpZGVzIGFuZCBvYmplY3RpdmVz IHJpc2sgbG9zaW5nIHRoZWlyIHByZXNlbnRhdGlvbg0Kc2xvdC48YnI+DQo8YnI+DQpUaGFua3Ms PGJyPg0KRGF2ZTxicj4NCjxicj4NCkZyb206IERhdmlkIEEgU2luaWNyb3BlICZsdDtkYXZpZC5z aW5pY3JvcGVAZXJpY3Nzb24uY29tJmx0O21haWx0bzpkYXZpZC5zaW5pY3JvcGVAZXJpY3Nzb24u Y29tJmd0OyZndDs8YnI+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMTgsIDIwMTIgMzoyOCBQTTxi cj4NClRvOiAmcXVvdDtJRVRGLlBXRTMmcXVvdDsgJmx0O3B3ZTNAaWV0Zi5vcmcmbHQ7bWFpbHRv OnB3ZTNAaWV0Zi5vcmcmZ3Q7Jmd0Ozxicj4NCkNjOiBEYXZpZCBBIFNpbmljcm9wZSAmbHQ7ZGF2 aWQuc2luaWNyb3BlQGVyaWNzc29uLmNvbSZsdDttYWlsdG86ZGF2aWQuc2luaWNyb3BlQGVyaWNz c29uLmNvbSZndDsmZ3Q7PGJyPg0KU3ViamVjdDogUmU6IFtQV0UzXSBQV0UzIElFVEYgODQgU2xv dCBSZXF1ZXN0cyAtIFZhbmNvdXZlcjxicj4NCjxicj4NClRoYW5rcyB0byBhbGwgd2hvIHNlbnQg bWUgdGhlaXIgcmVxdWVzdHMuICZuYnNwO1RoZSBpbml0aWFsIGFnZW5kYSBmb3INClBXRTMgaXMg cG9zdGVkIGF0Ojxicj4NCjxicj4NCmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvODQv YWdlbmRhL2FnZW5kYS04NC1wd2UzPGJyPg0KPGJyPg0KSWYgeW91IHJlcXVlc3RlZCBhIHNsb3Qs IHBsZWFzZSBtYWtlIHN1cmUgeW91ciBkcmFmdCBpcyBsaXN0ZWQgb24gdGhlIGFnZW5kYS4NCiZu YnNwO05vdGUgdGhhdCB0aGUgdGltZSBhbGxvY2F0aW9uIG1heSBoYXZlIGJlZW4gcmVkdWNlZCB0 byBmaXQgaW50byB0aGUNCjkwIFBXRTMgc2Vzc2lvbi48YnI+DQpJZiB5b3UgcmVxdWVzdGVkIGEg c2xvdCBhbmQgeW91ciBkcmFmdCBpcyBub3QgcHJlc2VudCBvbiB0aGUgYWdlbmRhLCBwbGVhc2UN CnJlc2VuZCB5b3VyIHJlcXVlc3QgYnkgcmVwbHlpbmcgdG8gbWUuPGJyPg0KPGJyPg0KPGJyPg0K VGhvc2UgdGhhdCBhcmUgbGlzdGVkIG9uIHRoZSBhZ2VuZGE6PGJyPg0KPGJyPg0KMS4gUGxlYXNl IHNlbmQgYW4gZW1haWwgdG8gbWUgYW5kIHRoZSBDaGFpcnMgbm90aW5nIHdoYXQgb2JqZWN0aXZl cyBhbmQNCmlzc3VlcyBuZWVkIHRvIGJlIGRpc2N1c3NlZCBhbmQgcmVzb2x2ZWQgdmlhIHRoZSBw cmVzZW50YXRpb24uPGJyPg0KPGJyPg0KMi4gWW91ciBzbGlkZXMgYXJlIGR1ZSBpbnRvIG1lIGZv ciB1cGxvYWQgbm8gbGF0ZXIgdGhhbiBNb25kYXksIEp1bHkgMzAsDQoyMDEyICoqIDJwbSAqKiBW YW5jb3V2ZXIgdGltZS4gJm5ic3A7UGxlYXNlIHNlbmQgbWUgdGhlIHNsaWRlcyBieSBhdHRhY2hp bmcNCnRvIGEgcmVwbHkgdG8gdGhpcyBlbWFpbC48YnI+DQo8YnI+DQo8YnI+DQpQcmVzZW50ZXJz IHN1Ym1pdHRpbmcgbGF0ZS9ubyBzbGlkZXMgYW5kIG9iamVjdGl2ZXMgcmlzayBsb3NpbmcgdGhl aXIgcHJlc2VudGF0aW9uDQpzbG90Ljxicj4NCjxicj4NClRoYW5rcyE8YnI+DQpEYXZlPGJyPg0K PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBEYXZpZCBB IFNpbmljcm9wZSAmbmJzcDsgJmx0O2RhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20mbHQ7bWFp bHRvOmRhdmlkLnNpbmljcm9wZUBlcmljc3Nvbi5jb20mZ3Q7Jmd0Ozxicj4NCkRhdGU6IFdlZG5l c2RheSwgSnVuZSAyNywgMjAxMiAzOjUxIFBNPGJyPg0KVG86ICZxdW90O0lFVEYuUFdFMyZxdW90 OyAmbHQ7cHdlM0BpZXRmLm9yZyZsdDttYWlsdG86cHdlM0BpZXRmLm9yZyZndDsmZ3Q7PGJyPg0K U3ViamVjdDogW1BXRTNdIFBXRTMgSUVURiA4NCBTbG90IFJlcXVlc3RzIC0gVmFuY291dmVyPGJy Pg0KPGJyPg0KSGkgQWxsLDxicj4NCklmIHlvdSBuZWVkIGEgcHJlc2VudGF0aW9uIHNsb3QgZm9y IHRoZSBJRVRGIDg0IFBXRTMgc2Vzc2lvbiwgcGxlYXNlIHJlcGx5DQp0byB0aGlzIGVtYWlsIChz dWJqZWN0IGludGFjdCkgd2l0aDo8YnI+DQotdG9waWM8YnI+DQotZHJhZnQgbmFtZTxicj4NCi1y ZXF1ZXN0ZWQgZHVyYXRpb248YnI+DQotc3BlYWtlciBuYW1lPGJyPg0KPGJyPg0KVGhhbmtzLDxi cj4NCkRhdmU8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0BpZXRmLm9yZyZsdDttYWlsdG86 cHdlM0BpZXRmLm9yZyZndDs8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3B3ZTM8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0BpZXRmLm9yZzxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMzxicj4NCjxicj4NCjwv Zm9udD48L3R0Pg0KPGJyPg0K --=_alternative 000E259248257A4C_=-- From zhang.fei3@zte.com.cn Mon Jul 30 19:56:16 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D363111E80E0; Mon, 30 Jul 2012 19:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.078 X-Spam-Level: X-Spam-Status: No, score=-97.078 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZkHiYindx8S; Mon, 30 Jul 2012 19:56:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 571FA11E8087; Mon, 30 Jul 2012 19:56:15 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 107233491178658; Tue, 31 Jul 2012 10:45:29 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 228.5504356121; Tue, 31 Jul 2012 10:56:06 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q6V2tvDB047639; Tue, 31 Jul 2012 10:56:03 +0800 (GMT-8) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: To: Gregory Mirsky MIME-Version: 1.0 X-KeepSent: 2695D28A:7D4CF387-48257A4C:000F7D25; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 31 Jul 2012 10:56:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2012-07-31 10:56:00, Serialize complete at 2012-07-31 10:56:00 Content-Type: multipart/alternative; boundary="=_alternative 0010194748257A4C_=" X-MAIL: mse01.zte.com.cn q6V2tvDB047639 Cc: pwe3-bounces@ietf.org, "pwe3 \(pwe3@ietf.org\)" Subject: Re: [PWE3] FW: New Version Notification for draft-mirsky-mpls-tp-cv-adv-01.txt X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 02:56:16 -0000 This is a multipart message in MIME format. --=_alternative 0010194748257A4C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR3JlZw0KDQoNCkhpIEdyZWcNCg0KSG9wZSB5b3Ugd2VsbA0KDQpJIGhhdmUgdGFrZW4gYSBj bG9zZSBsb29rIGF0IHRoZSBkcmFmdC1taXJza3ktbXBscy10cC1jdi1hZHYtMDEsIGJlIGdsYWQg DQp0byBzZWUgdGhhdCB0aGUgbGVuZ3RoIG9mIHRoZSBkZWZpbmVkIFZDQ1YgRXh0ZW5kZWQgQ1Yg QWR2ZXJ0aXNlZW1udCANCnN1Yi1UTFYgaXMgdmFyaWFibGUgbm93LCB3aGljaCBpcyBtb3JlIGV4 dGVuc2libGUuDQogDQpCZWxvdyBhcmUgc29tZSBtaW5vciBjb21tZW50cyBvbiB0aGlzIGRyYWZ0 IHRoYXQgSSBsaWtlIHRvIHNoYXJlIHdpdGggeW91LCANCmJvdGggb2YgdGhlbSBoYXZlIGJlZW4g ZGlzY3Vzc2VkIHdpdGggeW91IG9mZmxpbmUgKFBsZWFzZSBjaGVjayB0aGUgZW1haWwgDQpzZW50 IG91dCBhdCAyMDEyLTAyLTI5IDExOjE5IHdpdGggdGhlIHRpdGxlIFJFOiBjb21tZW50cyBvbiB0 aGUgZHJhZnQgDQpkcmFmdC1taXJza3ktbXBscy10cC1jdi1hZHYpDQoNCjEuIEkgYW0gYWZyYWlk IHRoYXQgSVAvVURQIGVuY2Fwc3VsYXRpb24gb2YgQkZEIHBhY2tldHMgYXJlIG5vdCBleGNsdWRl ZCANCmJ5IHRoZSBNUExTLVRQIG1lY2hhbmlzbQ0KDQoyLiBTaW5jZSB0aGUgUFcgbmVlZHMgdG8g c3VwcG9ydCB0aGUgb3RoZXIgZGVmaW5lZCBNUExTLVRQIE9BTSwgc3VjaCBQTSANCmFuZCBGTVMs IG1heWJlIHRoZSBuYW1lIG9mIHRoaXMgc3ViLVRMViBjYW4gYmUgbW9yZSBNUExTLVRQIG9yaWVu dGllZCANCg0KQW5vdGhlciBxdWVzdGlvbiB0aGF0IHdhbnQgdG8gY2hlY2sgd2l0aCB5b3UgaXMg YWJvdXQgdGhlIHJlbGF0aW9uc2hpcCANCmJldHdlZW4geW91ciBkcmFmdCBhbmQgYW5vdGhlciBk cmFmdCANCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcHdlMy1tcGxzLXRw LW9hbS1jb25maWctMDAuIEFsdGhvdWdoIA0Kd2UgYWxzbyBhZGRyZXNzZWQgdGhlIE1QTFMtVFAg T0FNIG5lZ290aWF0aW9uIGluIHRoZSBJbml0aWFsaXphdGlvbiANCm1lc3NhZ2UgaW4gdGhlIGRy YWZ0IGRyYWZ0LWlldGYtcHdlMy1tcGxzLXRwLW9hbS1jb25maWctMDAsIGFzIHlvdSBwb2ludGVk IA0Kb3V0IGluIElFVEY4MyBtZWV0aW5nIHRoYXQgdGhlIENhcGFiaWxpdHkgbmVnb3RpYXRpb25z IGluIHRoZSBJbml0aWF0aW9uIA0KbWVzc2FnZSBhcmUgcmVsYXRlZCB0byB0aGUgTERQIG1lc3Nh Z2UgcHJvY2VkdXJlcyB0aGVtc2VsZi4gSSB0ZW5kIHRvIA0KYWdyZWUgd2l0aCB5b3Ugb24gdGhp cyBwb2ludCBhZnRlciBjaGVja2luZyBSRkM1NTYxIGFuZCByZWxhdGVkIA0KZXh0ZW5zaW9ucywg YW5kIHdvdWxkIGxpa2UgdG8gaGVhciBtb3JlIG9waW5pb25zIGZyb20gV0cuDQoNCkJlc3QgcmVn YXJkcw0KDQpGZWkNCg0KDQoNCkdyZWdvcnkgTWlyc2t5IDxncmVnb3J5Lm1pcnNreUBlcmljc3Nv bi5jb20+IA0Kt6K8/sjLOiAgcHdlMy1ib3VuY2VzQGlldGYub3JnDQoyMDEyLTA3LTI0IDAxOjAw DQoNCsrVvP7Iyw0KInB3ZTMgICAocHdlM0BpZXRmLm9yZykiIDxwd2UzQGlldGYub3JnPg0Ks63L zQ0KDQrW98ziDQpbUFdFM10gRlc6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQt bWlyc2t5LW1wbHMtdHAtY3YtYWR2LTAxLnR4dA0KDQoNCg0KDQoNCg0KIA0KRGVhciBBbGwsDQpU aGUgbmV3IHZlcnNpb24gd2FzIHJlY2VudGx5IHB1Ymxpc2ggdG8gYWRkcmVzcyBkaXNjdXNzaW9u IGF0IElFVEYtODMgDQptZWV0aW5nIGluIFBhcmlzLg0KSSB3ZWxjb21lIHlvdXIgY29tbWVudHMg YW5kIHdpbGwgZ3JlYXRseSBhcHByZWNpYXRlIGNvbnNpZGVyYXRpb24gdG8gYWRvcHQgDQp0aGUg ZHJhZnQgYXMgUFdFMyBXRyBkb2N1bWVudC4NCg0KICAgICAgICAgICAgICAgICBSZWdhcmRzLA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogRnJpZGF5LCBKdWx5IDEzLCAyMDEyIDI6MTUgUE0N ClRvOiBHcmVnb3J5IE1pcnNreQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1taXJza3ktbXBscy10cC1jdi1hZHYtMDEudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LW1pcnNreS1tcGxzLXRwLWN2LWFkdi0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgR3JlZyBNaXJza3kgYW5kIHBvc3RlZCB0byB0aGUgSUVURiAN CnJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOiAgICAgICAgICAgICAgICAgZHJhZnQtbWlyc2t5LW1w bHMtdHAtY3YtYWR2DQpSZXZpc2lvbjogICAgICAgICAgICAgICAgIDAxDQpUaXRsZTogICAgICAg ICAgICAgICAgICAgICAgICAgICAgVkNDViBNUExTLVRQIENvbm5lY3Rpdml0eSBWZXJpZmljYXRp b24gDQooQ1YpIENhcGFiaWxpdHkgQWR2ZXJ0aXNlbWVudA0KQ3JlYXRpb24gZGF0ZTogICAgICAg ICAgICAyMDEyLTA3LTEzDQpXRyBJRDogICAgICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDgNClVSTDogICAgICAgICAgICAgDQpo dHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1taXJza3ktbXBscy10cC1j di1hZHYtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIA0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1taXJza3ktbXBscy10cC1jdi1hZHYNCkh0bWxpemVkOiAgICAgICAgaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWlyc2t5LW1wbHMtdHAtY3YtYWR2LTAxDQpE aWZmOiAgICAgICAgICAgIA0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1taXJza3ktbXBscy10cC1jdi1hZHYtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50 IHNwZWNpZmllcyBob3cgdXNlIG9mIHByb2FjdGl2ZSBDb25uZWN0aXZpdHkNCiAgIFZlcmlmaWNh dGlvbiwgQ29udGludWl0eSBDaGVjaywgYW5kIFJlbW90ZSBEZWZlY3QgSW5kaWNhdGlvbiBmb3Ig dGhlDQogICBNUExTIFRyYW5zcG9ydCBQcm9maWxlIFtSRkM2NDI4XSBhZmZlY3RzIG9wZXJhdGlv biBhbmQgbWFuYWdlbWVudA0KICAgZnVuY3Rpb24gZWxlY3Rpb24gZm9yIFBXIFZDQ1YgW1JGQzUw ODVdLCBbUkZDNTg4NV0uDQoNCiAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpwd2UzIG1haWxpbmcgbGlz dA0KcHdlM0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w d2UzDQoNCg0KDQo= --=_alternative 0010194748257A4C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdyZWc8L2ZvbnQ+DQo8YnI+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdyZWc8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhvcGUgeW91IHdlbGw8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgaGF2ZSB0 YWtlbiBhIGNsb3NlIGxvb2sgYXQgdGhlIGRyYWZ0LW1pcnNreS1tcGxzLXRwLWN2LWFkdi0wMSwN CmJlIGdsYWQgdG8gc2VlIHRoYXQgdGhlIGxlbmd0aCBvZiB0aGUgZGVmaW5lZCBWQ0NWIEV4dGVu ZGVkIENWIEFkdmVydGlzZWVtbnQNCnN1Yi1UTFYgaXMgdmFyaWFibGUgbm93LCB3aGljaCBpcyBt b3JlIGV4dGVuc2libGUuPGJyPg0KICZuYnNwOzxicj4NCkJlbG93IGFyZSBzb21lIG1pbm9yIGNv bW1lbnRzIG9uIHRoaXMgZHJhZnQgdGhhdCBJIGxpa2UgdG8gc2hhcmUgd2l0aCB5b3UsDQpib3Ro IG9mIHRoZW0gaGF2ZSBiZWVuIGRpc2N1c3NlZCB3aXRoIHlvdSBvZmZsaW5lIChQbGVhc2UgY2hl Y2sgdGhlIGVtYWlsDQpzZW50IG91dCBhdCAyMDEyLTAyLTI5IDExOjE5IHdpdGggdGhlIHRpdGxl IFJFOiBjb21tZW50cyBvbiB0aGUgZHJhZnQgZHJhZnQtbWlyc2t5LW1wbHMtdHAtY3YtYWR2KTwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gSSBhbSBh ZnJhaWQgdGhhdCBJUC9VRFAgZW5jYXBzdWxhdGlvbg0Kb2YgQkZEIHBhY2tldHMgYXJlIG5vdCBl eGNsdWRlZCBieSB0aGUgTVBMUy1UUCBtZWNoYW5pc208L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIFNpbmNlIHRoZSBQVyBuZWVkcyB0byBzdXBwb3J0 IHRoZQ0Kb3RoZXIgZGVmaW5lZCBNUExTLVRQIE9BTSwgc3VjaCBQTSBhbmQgRk1TLCBtYXliZSB0 aGUgbmFtZSBvZiB0aGlzIHN1Yi1UTFYNCmNhbiBiZSBtb3JlIE1QTFMtVFAgb3JpZW50aWVkIDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5vdGhlciBx dWVzdGlvbiB0aGF0IHdhbnQgdG8gY2hlY2sNCndpdGggeW91IGlzIGFib3V0IHRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiB5b3VyIGRyYWZ0IGFuZCBhbm90aGVyIGRyYWZ0DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXB3ZTMtbXBscy10cC1vYW0tY29uZmlnLTAwLiBBbHRo b3VnaA0Kd2UgYWxzbyBhZGRyZXNzZWQgdGhlIE1QTFMtVFAgT0FNIG5lZ290aWF0aW9uIGluIHRo ZSBJbml0aWFsaXphdGlvbiBtZXNzYWdlDQppbiB0aGUgZHJhZnQgZHJhZnQtaWV0Zi1wd2UzLW1w bHMtdHAtb2FtLWNvbmZpZy0wMCwgYXMgeW91IHBvaW50ZWQgb3V0DQppbiBJRVRGODMgbWVldGlu ZyB0aGF0IHRoZSBDYXBhYmlsaXR5IG5lZ290aWF0aW9ucyBpbiB0aGUgSW5pdGlhdGlvbiBtZXNz YWdlDQphcmUgcmVsYXRlZCB0byB0aGUgTERQIG1lc3NhZ2UgcHJvY2VkdXJlcyB0aGVtc2VsZi4g SSB0ZW5kIHRvIGFncmVlIHdpdGgNCnlvdSBvbiB0aGlzIHBvaW50IGFmdGVyIGNoZWNraW5nIFJG QzU1NjEgYW5kIHJlbGF0ZWQgZXh0ZW5zaW9ucywgYW5kIHdvdWxkDQpsaWtlIHRvIGhlYXIgbW9y ZSBvcGluaW9ucyBmcm9tIFdHLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5GZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lk dGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+PGI+R3JlZ29yeSBNaXJza3kgJmx0O2dyZWdvcnkubWlyc2t5QGVyaWNz c29uLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPreivP7IyzogJm5ic3A7cHdlMy1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTItMDctMjQgMDE6MDA8L2ZvbnQ+DQo8dGQgd2lk dGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYg YWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7cHdlMyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsocHdlM0BpZXRmLm9yZykmcXVvdDsNCiZsdDtwd2UzQGll dGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+W1BXRTNdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24NCmZvciAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1taXJza3ktbXBscy10cC1jdi1hZHYtMDEudHh0 PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mbmJzcDs8YnI+DQpEZWFyIEFsbCw8YnI+DQpUaGUgbmV3IHZlcnNpb24gd2FzIHJlY2VudGx5 IHB1Ymxpc2ggdG8gYWRkcmVzcyBkaXNjdXNzaW9uIGF0IElFVEYtODMgbWVldGluZw0KaW4gUGFy aXMuPGJyPg0KSSB3ZWxjb21lIHlvdXIgY29tbWVudHMgYW5kIHdpbGwgZ3JlYXRseSBhcHByZWNp YXRlIGNvbnNpZGVyYXRpb24gdG8gYWRvcHQNCnRoZSBkcmFmdCBhcyBQV0UzIFdHIGRvY3VtZW50 Ljxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQpSZWdhcmRzLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0dyZWc8YnI+DQo8YnI+DQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBb bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ108YnI+DQpTZW50OiBGcmlkYXksIEp1bHkg MTMsIDIwMTIgMjoxNSBQTTxicj4NClRvOiBHcmVnb3J5IE1pcnNreTxicj4NClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWlyc2t5LW1wbHMtdHAtY3YtYWR2LTAx LnR4dDxicj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1taXJza3kt bXBscy10cC1jdi1hZHYtMDEudHh0PGJyPg0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBHcmVnIE1pcnNreSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuPGJyPg0K PGJyPg0KRmlsZW5hbWU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwO2RyYWZ0LW1pcnNreS1tcGxzLXRwLWN2LWFkdjxicj4NClJl dmlzaW9uOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDswMTxicj4NClRpdGxlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KVkNDViBNUExTLVRQIENvbm5lY3Rp dml0eSBWZXJpZmljYXRpb24gKENWKSBDYXBhYmlsaXR5IEFkdmVydGlzZW1lbnQ8YnI+DQpDcmVh dGlvbiBkYXRlOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsyMDEyLTA3LTEzPGJyPg0KV0cgSUQ6ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpJbmRpdmlkdWFs IFN1Ym1pc3Npb248YnI+DQpOdW1iZXIgb2YgcGFnZXM6IDg8YnI+DQpVUkw6ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LW1pcnNreS1tcGxzLXRwLWN2LWFkdi0wMS50eHQ8YnI+DQpTdGF0dXM6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1pcnNreS1tcGxzLXRwLWN2LWFkdjxicj4NCkh0bWxpemVkOiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1t aXJza3ktbXBscy10cC1jdi1hZHYtMDE8YnI+DQpEaWZmOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtbWlyc2t5LW1wbHMtdHAtY3YtYWR2LTAxPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZu YnNwOyBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdXNlIG9mIHByb2FjdGl2ZSBDb25uZWN0 aXZpdHk8YnI+DQogJm5ic3A7IFZlcmlmaWNhdGlvbiwgQ29udGludWl0eSBDaGVjaywgYW5kIFJl bW90ZSBEZWZlY3QgSW5kaWNhdGlvbiBmb3INCnRoZTxicj4NCiAmbmJzcDsgTVBMUyBUcmFuc3Bv cnQgUHJvZmlsZSBbUkZDNjQyOF0gYWZmZWN0cyBvcGVyYXRpb24gYW5kIG1hbmFnZW1lbnQ8YnI+ DQogJm5ic3A7IGZ1bmN0aW9uIGVsZWN0aW9uIGZvciBQVyBWQ0NWIFtSRkM1MDg1XSwgW1JGQzU4 ODVdLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJp YXQ8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCnB3ZTMgbWFpbGluZyBsaXN0PGJyPg0KcHdlM0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcHdlMzxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0K PGJyPg0K --=_alternative 0010194748257A4C_=-- From jie.dong@huawei.com Tue Jul 31 18:22:09 2012 Return-Path: X-Original-To: pwe3@ietfa.amsl.com Delivered-To: pwe3@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5648C11E80E7 for ; Tue, 31 Jul 2012 18:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJ8Oz2Dngqjw for ; Tue, 31 Jul 2012 18:22:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B40E011E816E for ; Tue, 31 Jul 2012 18:22:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIN09832; Tue, 31 Jul 2012 21:22:05 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 18:20:42 -0700 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 31 Jul 2012 18:20:45 -0700 Received: from SZXEML504-MBS.china.huawei.com ([169.254.8.92]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 1 Aug 2012 09:20:34 +0800 From: Jie Dong To: "pwe3@ietf.org" Thread-Topic: Appreciate comments on draft-dong-pwe3-redundancy-spe-02 Thread-Index: Ac1vg5qEqVAVYax6Q3CZWY8Ykggs3Q== Date: Wed, 1 Aug 2012 01:20:33 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C9273253CBAF@szxeml504-mbs.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [PWE3] Appreciate comments on draft-dong-pwe3-redundancy-spe-02 X-BeenThere: pwe3@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Pseudo Wires Edge to Edge List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 01:22:09 -0000 Dear all, The authors would like to solicit your review and comments on draft-dong-pw= e3-redundancy-spe-02. As said in the PWE3 meeting, this draft is complementary to draft-ietf-pwe3= -redundancy-bit and can be helpful in scenarios described in the draft. The url is: http://tools.ietf.org/html/draft-dong-pwe3-redundancy-spe-02 Many thanks, Jie=