From nobody Wed Mar 2 08:44:01 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7E1B2C35 for ; Wed, 2 Mar 2016 08:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MBHjMUxIIBJ for ; Wed, 2 Mar 2016 08:43:58 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705741B2C37 for ; Wed, 2 Mar 2016 08:43:58 -0800 (PST) X-AuditID: c618062d-f79dd6d000003091-0b-56d713ca540b Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id E7.05.12433.AC317D65; Wed, 2 Mar 2016 17:24:42 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0248.002; Wed, 2 Mar 2016 11:43:57 -0500 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: PALS IETF 95 Slot Requests - Buenos Aires Thread-Index: AQHRdKK2jUc0VY2AIE2RSXVw67SOCg== Date: Wed, 2 Mar 2016 16:43:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_D2FC80BC1BEC99davidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPgu4p4ethBj9OSVms+beOyYHRY8mS n0wBjFFcNimpOZllqUX6dglcGbMbnrMXPLepOPjgOksD43fTLkZODgkBE4k5M2YxQdhiEhfu rWfrYuTiEBI4wiix4nAXlLOMUeLd7tXMIFVsQB3rNu5hAbFFBJQldp2fwghiCwsYSzx9eIUJ Im4hsb31B1SNnsSbQ02sXYwcHCwCKhIdR1RBwrwCVhKHJraxgtiMQIu/n1oD1sosIC5x68l8 qIMEJJbsOc8MYYtKvHz8D6xeFGjk7Y617BBxJYlJS8+BjWcWiJeYvx1qvKDEyZlPWCYwCs9C MnUWQtUsJFUQJToSC3Z/YoOwtSWWLXzNDGOfOfCYCcK2lth3dCIzspoFjByrGDlKiwtyctON DDYxAqPkmASb7g7G+9M9DzEKcDAq8fB+kLsWJsSaWFZcmXuIUYKDWUmEV0rkepgQb0piZVVq UX58UWlOavEhRmkOFiVx3vVvL4cJCaQnlqRmp6YWpBbBZJk4OKUaGFVeyz1eYf53Wl3Kae7u wFP7K89fU5U9tt3FUXb3tKxHq00Ymr+ZlodKaF9S636frv3ofyPbYhsju9O6vTqmt4/Evlqg UviM78Aho/IWznTFybqmpWwJLZcuRRuUlZVJXjfd8/JBoV90Uez3OXmta+2WNu6yP/5QUvHD tWObwhPnvFW4PsX3nBJLcUaioRZzUXEiAExdWxOOAgAA Archived-At: Subject: [Pals] PALS IETF 95 Slot Requests - Buenos Aires X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 16:44:00 -0000 --_000_D2FC80BC1BEC99davidsinicropeericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, It's that time again. If you need a presentation slot for the upcoming IETF PALS session, please = reply to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests.) Form: 1. Topic: (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker: you only need to provide the file name= to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-= mpls-eth-oam-iwk/): 3. Brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting: (e.g., need to address security iss= ues and get direction from the WG): 4. Requested duration: (norm/default is 10 min): 5. Speaker name: (e.g., Dave SINICROPE= ): Thanks! Dave --_000_D2FC80BC1BEC99davidsinicropeericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi All,

It's that time again. 

If you need a presentation slot for the upcoming IET= F PALS session, please reply to this email (subject intact= ) completing the form below.   

Please use this form and&n= bsp;please reply to this email with the subject i= ntact.  (Not doing so probably means your request will not trigger the= filter I use to identify PALS slot requests.)

Form:
1. Topic:= (e.g., MPLS and Ethernet OAM Interworking):

2. URL to your draft on D= atatracker:&n= bsp;you only need to provide the file name to the example URL (e.g., http://datatracker.ietf.org/doc/draft-i= etf-pwe3-mpls-eth-oam-iwk/):   

3. Brief statement of objectives and issues to be= discussed and resolved via the presentation during the meeting:  = (e.g., need to address security issues and get direction from the WG): &nbs= p;

4. Requested duration: (norm/default is 10 min):=

5. Speaker name: <Given-name FAMILY-N= AME-IN-ALL-CAPS> (e.g., Dave SINICROPE):  

 

Thanks!
Dave<= /div>
--_000_D2FC80BC1BEC99davidsinicropeericssoncom_-- From nobody Thu Mar 3 03:37:21 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2BD1A907C for ; Thu, 3 Mar 2016 03:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.893 X-Spam-Level: X-Spam-Status: No, score=-0.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, LOCALPART_IN_SUBJECT=1.107, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwTgmnJA0iUx for ; Thu, 3 Mar 2016 03:37:18 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB74D1A907B for ; Thu, 3 Mar 2016 03:37:17 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id l68so127018047wml.0 for ; Thu, 03 Mar 2016 03:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:cc:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=TJ09v7cjOlLjxX4NP1r+jjJMPsk2calcbXpeRNXZP6I=; b=lhEz4RBLYSWNReo0zkoR1LJILtxaTz4woHiX9Vil2+vIeE+QkgP0nDG0notXUnz9Hw G2klvvqlNhbQiiFVMI0xWoTIqPVQ6JZFxeKe4nuoNwWSZsvIwt4XxIupQo8/SZwDXKcS WHfNh0AxCOfrCE0ruN8Fgo00w19+z9ZxyfmllFXghYShaO3qMdDgDAtnN5DBWhR9Tq2+ Lfz/zFP6kJsfYFMjMMmt/Fy2/YkCkaTInWuYvRjqqJeblnkuALcwcbnglqoSI9YqD1E+ oY3snePP87YHby9ukyK0C2Z+irEGYktXCTla/I/krnShXhJU/mMjsuSU3FawhKIiLms3 XzJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:cc:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=TJ09v7cjOlLjxX4NP1r+jjJMPsk2calcbXpeRNXZP6I=; b=OcfY0XpUjxk1qbn7EceGfdGoNdXaPY1Z24IrXfdgqKoShsKGBQr2G0YIqojNkgBQDp OloZL4dl6byA2wUtwXS/tkXW4srp3Y7/adWC3xcZ2YgRFS+kQc9FWiFXVe6fb/rA/dt2 JXL3lU/Luuyb/3CVl3rMjqj+NtyN8/1Nquiojpg/2fjb9KGKuD1OMaBRMeeLB+0/WMAr 9c9cpajPwS2rN9rmFfrZge6b58JsfgrvUV11F40ZT7Ibrs5bBWpHEAqCOicEsfIDbxs8 +ysxvuPZ0CMa9w38jprZEB4hEbL5HUWUwk5on4xZO+XAyljG3crzMTFv8XEvEE0lwqxL 45Kw== X-Gm-Message-State: AD7BkJL+o88tkn8YacNqWtM0IBc7qDboilFI2WHNTPaZ6V7uNWbSCD55Tc7mNllDA5mzcQ== X-Received: by 10.28.146.209 with SMTP id u200mr2776040wmd.59.1457005036391; Thu, 03 Mar 2016 03:37:16 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id di1sm40114552wjc.3.2016.03.03.03.37.14 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 03:37:15 -0800 (PST) To: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org From: Stewart Bryant Message-ID: <56D821EA.5080007@gmail.com> Date: Thu, 3 Mar 2016 11:37:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: [Pals] draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:37:20 -0000 Authors In doing the write up for this draft I cannot find a reply from each of you to the effect that you have declared all of the IPR that you know about. This may be that I lost the emails when I changed system, or that I am looking under the wrong subject in the PALS/PWE3 archives, in which case I apologise. It is probably simplest if I ask you to reply to this email confirming that you have declared all the relevant IPR that you know about. As soon as I hear back I will make the final edit to the shepherd's report and change the status to publication requested. Stewart From nobody Thu Mar 3 03:51:52 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83201A90DB for ; Thu, 3 Mar 2016 03:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.5 X-Spam-Level: X-Spam-Status: No, score=0.5 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXWvz6ypJN8X for ; Thu, 3 Mar 2016 03:51:45 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3E8B1A90BE for ; Thu, 3 Mar 2016 03:51:44 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n186so127972364wmn.1 for ; Thu, 03 Mar 2016 03:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=7KJzB/+Ulx2qBfIcCwjJ2mLBT5rAM5Zob+fPm0UtXFE=; b=rGrQ88sg+wmr+UsFGIwv8ez0FmB5CLmVNhV/c7FoajvbdYzLs7zW388O3ZF9w52ILC 6bGcwoW6W0kImFyLX3zygVc+iRcOQOLBX1MS5ovGWhIm6MQ7gqwcrC+YMUKAtTztboxv lGQNtaCMeI0cCrcvPB82Imso8dDE4B5rd1J6ykrP+s2HWb9vsL/mug/L1YpeTSavLNhy /weD1BuEHy5X4EcaMNHV5HVtC8ZuOOERIlDsr0gkZkKrTjb1EYqOqLk5KEuNDmykbsak 4Q5Xv32u+u5C6RjYMvmOJevMiciIDBLttV1FbFhGk694MiwznihAkjCetbzPlBDwzuyM 14rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=7KJzB/+Ulx2qBfIcCwjJ2mLBT5rAM5Zob+fPm0UtXFE=; b=X4e8OX/R5P7QcTZRpGVb4y1YiDmd1yEodqn9v5qMgG9VblRaY3p20TjphchdqmgIW2 K8fPJ+hhEbDlXHjxPkUGJm6yIG+KIk1RabiPRKMXOsEVO7z1NZcp/4iyd1QzN59iMpqn 3J28BTcOOGJlTWUaQI7iVbVfwJEdXTtBMnAP5hAwenCGeeacAcaFRsG2V7ihayrHuYC5 bOG6zVFlfxgrSvjMiLX6LoErp/KJvtVL8HYbgSvSkOay9pR0DAnoWKAyUtvEU+W+9fFJ z3s21nj5/TRYOdMlOUHEJ5hvuTkhAfpyBBDjP123+srmZVP8tXKqLqutWhJzAcpu44op dO8A== X-Gm-Message-State: AD7BkJIOYjf/0KC9rzQfxz2iJSugnMvx6lthjkEZmwny5HoTTlXpZYTx/lAwN7XBpvuPog== X-Received: by 10.194.174.134 with SMTP id bs6mr2480716wjc.111.1457005903193; Thu, 03 Mar 2016 03:51:43 -0800 (PST) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id 77sm8606547wmp.18.2016.03.03.03.51.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Mar 2016 03:51:41 -0800 (PST) To: Mach Chen , Alexander Vainshtein References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> From: Stewart Bryant Message-ID: <56D8254C.4030702@gmail.com> Date: Thu, 3 Mar 2016 11:51:40 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050007020600050505070206" Archived-At: Cc: "draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org" , "Elisa.bellagamba@gmail.com" , "pals-chairs@tools.ietf.org" , "wu.bo@zte.com.cn" , "pals@ietf.org" Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 11:51:51 -0000 This is a multi-part message in MIME format. --------------050007020600050505070206 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Mach The document has expired. Please can you refresh with your current version and let the WG know if you still have outstanding comments to address. I have received some comments direct to me. I have asked if the reviewer will post direct to the list. If not, I will include them in my review of the next version. - Stewart On 25/01/2016 02:02, Mach Chen wrote: > > Hi Sasha, > > Many thanks for your detailed review and comment! > > We’ll address them in the next revision. > > Best regards, > > Mach > > *From:*Pals [mailto:pals-bounces@ietf.org] *On Behalf Of *Alexander > Vainshtein > *Sent:* Friday, January 22, 2016 11:08 PM > *To:* Stewart Bryant > *Cc:* draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; > Elisa.bellagamba@gmail.com; pals-chairs@tools.ietf.org; > wu.bo@zte.com.cn; pals@ietf.org > *Subject:* Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config > > Stewart (and all), > > Following your call for volunteers I have read the draft (or, at least > most of it – I did not go into detail regarding the part that > discusses PM functions), and I have multiple concerns regarding it. I > have sent most of these concerns to the authors off-list, and received > some feedback from Mach. My concerns are listed below: > > 1._References to some basic documents are missing and/or incomplete_: > > a.RFC 4447: > > i.From my POV, the draft is about some extensions to RFC 4447, but > this document is only mentions this document in Section 6 “Security > Considerations” > > ii.The draft silently ignores the differences between FEC-128 and > FEC-129. If (as the authors have claimed during our off-list > discussions) it is equally applicable to both, this should be > explicitly stated in the document IMO. > > b.RFC 5085: > > i.To the best of my understanding, all PW OAM messages run in VCCV, > but neither RFC 5085 nor RFC 7708 are referenced in the document. > Actually, even the term “VCCV” is not mentioned in the document. > > ii.In particular, the draft silently ignores the situation when /the > PW endpoints could not agree on any VCCV Type/ so that any attempts to > run OAM on the PW would fail – even if the PW endpoints agree about > all specific OAM functions and their parameters. From my POV if the PW > endpoints could not agree on the VCCV type, all OAM-related parameters > should be simply silently ignored > > c.RFC 5885 and RFC 6428 and: > > i.The draft discusses setup of BFD as pro-active OAM mechanism for PWs > > ii.Neither RFC 5885 (that defines BFD in VCCV) nor RFC 6428 (that > defines Pro-Active CC, CV and RDI for MPLS-TP based on BFD) are > mentioned in the draft. > > 2._Excessively strict behavior_: > > a.The draft defines that any difference in the OAM capabilities of the > PW endpoints would result in failure to set it up. One example of this > behavior can be found in the following fragment copied from Section > 3.1.1 “*Establishment of OAM Entities and Functions*”: > > To achieve this, a Label Mapping message with the "OAM Alarms Enabled" > flag cleared is sent. In the message, the "OAM MEP Entities Desired" > flag is set... In addition, to configure and enable particular OAM > functions, the PW OAM Functions TLV and relevant sub-TLVs MUST be > included. > > When the Label Mapping message is received by PE2, PE2 needs to check > whether it supports the requested OAM configuration. If it does not > support the requested OAM configuration, a Label Release message MUST > be returned to PE1, with a Status Code set to "PW OAM Parameters > Rejected". The PW signaling is complete and the PW will not be > established. > > b.From my POV the behavior defined in the txt above is too harsh for > PWs. I have suggested to the authors to consider a more liberal > behavior model when the PW endpoints succeed setting up a PW > regardless of whether there is a 100% match between their supported > OAM functionality, and just agree on a commonly supported set of OAM > functions which could be empty. Such a model, if accepted, would be > also consistent with the model for adjustment of OAM parameters as > defined in Section 3.1.2 “Adjustment of OAM Parameters”. > > 3._Internal inconsistencies_: > > a.BFD Identifiers sub-TLV: > > i.Mentioned twice as “MUST be included” in Section 4.2.1 > > ii.Is not defined anywhere in the draft > > iii.This looks like a “copy and paste” notion from RFC 7487 – but the > definition of the namesake TLV in this document is not applicable as > it deals with MPLS-TP LSP identifiers only. > > b.Usage of the “OAM Alarms Enabled” flag: > > i.The text in at the end of Section 4.1 states that “The"OAM Alarms > Enabled" flag is used to request the received PEs to enable (when set) > or disable (when cleared) OAM alarms function”. > > ii.In almost all the cases considered in the draft, the “OAM Alarms > Enabled” flag is used in accordance with the definition quoted above. > > iii.However, the text in Section 3.1.2 says that “Consequently, the > ingress PE needs to keep its OAM sink and source functions running > without any changes until the OAM parameters are updated. However, in > order to suppress spurious alarms, it also need to disable the alarm > functions before the Label Mapping message, with the "OAM Alarms > Enabled" flag cleared and the updated PW OAM Function TLV, is sent. > The OAM alarm function needs to be disabled until the corresponding > response message is received”. To me this reads as the Label Mapping > message to be sent to the “egress PE” in order to adjust the OAM > parameters must have the “OAM Alarms Enabled” flag cleared in order to > disable spurious OAM alarms there > > iv.Some of the use case of the “OAM Alarms Enabled” flag look > unnecessary to me. E.g., when the PW is being set up, I would expect > it to suppress all alarms (OAM alarms included) until the PW setup is > complete – and that without the need of any additional synchronization. > > 4._Poor alignment with the standard PW setup process_: > > a.RFC 4447 defines the SS-PW setup process as symmetric: > > i.Each PW endpoint sends its own Label Mapping message for one of the > PW FECs to the peer and waits for receiving a matching (with the match > condition defined by the FEC-specific rules) from the peer > > ii.The PW setup is successfully completed when /both these events are > encountered/. Their order does not matter, and consequently there is > no such thing as a “response Label Mapping message” > > b.However, the draft refers (in 3 different places) to a “response > Label Mapping message”: > > i.In Section 3.1.2 when it says that “The OAM alarm function needs to > be disabled until the corresponding response message is received” > > ii.In Section 3.2.2 (the same text is used) > > iii.In Section 4.2.1 when it says that “The BFD Configuration Sub-TLV > MUST include the following sub-TLVs in the "response" Label Mapping > message”. > > c.This looks to me like a probable “copy and paste” error from RFC > 7487. But this document uses RSVP-TE with its Path and Resv messages. > PW setup is different, of course. > > 5._Problematic use of sink/source terminology_: > > a.The draft assumes some kind of separation between Sink and Source > OAM functions, e.g., when it says in Section 3.1.1 that: > > i.The OAM sink functions must be enabled before the Label Mapping > message (exposing the required OAM functionality to the remote PW > endpoint) are enabled > > ii.The OAM source functions must be enabled only after a “response” > Label Mapping message has been received > > b.In addition, to referring (explicitly or implicitly) to the > non-existing “response” OAM Label Mapping message, this logic cannot, > from my POV, be applied to such an OAM function as BFD. > > 6._Problematic reference to MIP function_: To the best of my > understanding: > > a.From my POV S-PEs always support MIP because: > > i.In order to reach a MIP the transmitter must set the TTL in the PW > label to a corresponding value > > ii.Once the TTL in the PW label expires in some S-PE, the relevant > packet is always trapped > > b.It is not clear how MIP functionality can be used for pro-active OAM > operations > > 7._Multiple inconsistencies pertaining to use of BFD_: > > a.Timer Negotiation: > > i.The draft defines (in section 4.2.1) an N flag that indicates > whether negotiation of timer parameters using BFD control packets is > or is not supported. If it is not supported, a Timer negotiation > parameters sub-TLV must be used > > ii.According to Section 3.7.1 of RFC 6428 (which, AFAIK, equally > applies to BFD in MPLS-TP Sections, LSPs and PWs), BFD sessions always > start with 1 second transmission intervals until they reach their UP > state, and then modify the timers to mutually agreed values using > Poll/Final. Further, RFC 6428 specifies that the timer parameters may > be used at any time, and that non-supporting implementations MUST set > the BFD session on which such a change is required to Admin Down in > response to an attempt of the remote endpoint of the session to change > these parameters. > > iii.The bottom line, as I see it, that the draft is not compatible > with RFC 6428 > > b.Authentication: > > i.The draft defines an I flag that indicates that BFD authentication > is required, and a BFD Authentication sub-TLV for synchronizing the > authentication parameters. > > ii.I am not a security expert, and do not pretend to be one. But I > think that the default authentication mechanism defined in the draft > (SHA1 cryptographic authentication using a hard-coded – all zeroes – > “pre-shared” secret”) would not pass any serious review by the > security experts > > iii.I also do not understand why the BFD Authentication sub-TLV as > defined in Section 4.2.1.3 carries the Authentication Key ID. As per > RFC 5880, this key ID is carried as part of the Authentication Data in > the Authentication Section of the all authenticated BFD Control > Packets (and can be changed randomly and independently by each > endpoint of the session). > > c.Local Discriminator sub-TLV: > > i.To the best of my understanding, the draft suggests (in Section > 4.2.1.1) to exchange the values of the local discriminators between > the endpoints of the BFD session > > ii.I do not really understand why this is needed, because RFC 5880 > defines the mechanism for announcing My Discriminator value in the > first packet of the session, and RFC 6428 only adds that this value > MUST NOT be changed for an already established session. > > *Note*: It is possible that these inconsistencies are copy-pasted from > RFC 7487, but I did not review this document in detail. > > 8._Packet Delay Measurement Issues_: I did not review this part of the > draft in detail, but several points look problematic to me: > > a.Inferred vs. Direct measurement > > i.According to RFC 6374 “inferred packet loss measurement” is the > method that measures loss of synthetic probe packets while “direct > packet loss measurement” counts actually transmitted and received packets. > > ii.As per the same RFC, packet delay measurements are always done > based on synthetic probe packets (carrying timestamps) > > iii.The draft, however, mentions “inferred/direct packet delay > measurement” while, AFAIK, direct delay measurement simply does not exist > > b.Delay Variation Measurement: > > i.The draft supports signaling of delay variation management function > between the PW endpoints(Active/Inactive) > > ii.AFAIK, delay variation measurement is a purely local function, and > there is no need to synchronize its activation between the two PW > endpoints > > *Note*: It is possible that these inconsistencies are also copy-pasted > from RFC 7487. > > ** > > Hopefully these comments will be useful for the authors and for the WG. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > *From:*Alexander Vainshtein > *Sent:* Wednesday, January 06, 2016 3:35 PM > *To:* 'Stewart Bryant' > *Cc:* draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org > ; > pals@ietf.org ; pals-chairs@tools.ietf.org > ; wu.bo@zte.com.cn > ; Elisa.bellagamba@gmail.com > > *Subject:* RE: [Pals] WG Last call draft-ietf-pals-tp-oam-config > > Stewart, > > I will try to read the draft and provide some feedback by January 22nd. > > Meanwhile, while looking for the total number of pages in order to > understand whether I can handle this, I have found a reference to a > "/Dyadic mode of an egress LSR/". I have to admit that I do not know > what this means, and a short look-up in the Internet did not return > anything useful (unless somebody is going to use 2nd order tensors > in MPLSJ). > > If the authors could explain in advance what they mean, it would > simplify the review. > > Regards, > > Sasha > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant > Sent: Wednesday, January 06, 2016 12:34 PM > To: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org > ; > pals@ietf.org ; pals-chairs@tools.ietf.org > ; wu.bo@zte.com.cn > ; Elisa.bellagamba@gmail.com > > Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config > > Hi Folks > > I guess that everyone has been busy over the holiday period. > > I really need some indication on the list that the WG wants to publish > this draft, otherwise I cannot take it forward to the IESG. > > I also need some volunteers to read the draft and check it over for > errors. > > So please can have reviews and confirmation that we should go forward > with publication by 22nd January 2016. > > Thanks > > Stewart > > On 23/12/2015 13:00, Stewart Bryant wrote: > > > > > > > > > On 09/12/2015 14:13, Stewart Bryant wrote: > > >> This message starts the WG Last Call on draft-ietf-pals-tp-oam-config. > > >> > > >> This draft can be found at > > >> > > >> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/ > > >> > > >> Please respond to this thread with substantive comments and an > > >> indication of whether you have read the text and whether or not you > > >> think it is ready for publication. > > >> > > >> I will close WGLC on 23rd December. > > >> > > >> Regards > > >> > > >> - Stewart > > > > > > PALS WG > > > > > > I should close this LC today, but I have no evidence in terms of list > > > traffic in response to this LC that I can present to the IESG that > > > anyone has read it or cares whether we publish it of not. > > > > > > Has anyone besides the chairs and authors read it? > > > > > > Should we publish it, and why? > > > > > > - Stewart > > > > > _______________________________________________ > > Pals mailing list > > Pals@ietf.org > > https://www.ietf.org/mailman/listinfo/pals > --------------050007020600050505070206 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Mach

The document has expired.

Please can you refresh with your current version and let the WG know if you still have outstanding comments to address.

I have received some comments direct to me. I have asked if the reviewer will post direct to the list. If not, I will include them in my review of the next version.

- Stewart



On 25/01/2016 02:02, Mach Chen wrote:

Hi Sasha,

 

Many thanks for your detailed review and comment!

 

We’ll address them in the next revision.

 

Best regards,

Mach

 

From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Friday, January 22, 2016 11:08 PM
To: Stewart Bryant
Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; Elisa.bellagamba@gmail.com; pals-chairs@tools.ietf.org; wu.bo@zte.com.cn; pals@ietf.org
Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config

 

Stewart (and all),

Following your call for volunteers I have read the draft (or, at least most of it – I did not go into detail regarding the part that discusses PM functions), and I have multiple concerns regarding it. I have sent most of these concerns to the authors off-list, and received some feedback from Mach. My concerns are listed below:

 

1.       References to some basic documents are missing and/or incomplete:

a.       RFC 4447:

                                                               i.      From my POV, the draft is about some extensions to RFC 4447, but this document is only mentions this document in Section 6 “Security Considerations”

                                                             ii.      The draft silently ignores the differences between FEC-128 and FEC-129. If (as the authors have claimed during our off-list discussions) it is equally applicable to both, this should be explicitly stated in the document IMO.

b.      RFC 5085:

                                                               i.      To the best of my understanding, all PW OAM messages run in VCCV, but neither RFC 5085 nor RFC 7708 are referenced in the document. Actually, even the term “VCCV” is not mentioned in the document.

                                                             ii.      In particular, the draft silently ignores the situation when the PW endpoints could not agree on any VCCV Type so that any attempts to run OAM on the PW would fail – even if the PW endpoints agree about all specific OAM functions and their parameters. From my POV if the PW endpoints could not agree on the VCCV type, all OAM-related parameters should be simply silently ignored

c.       RFC 5885 and RFC 6428 and:

                                                               i.      The draft discusses setup of BFD  as pro-active OAM mechanism for PWs

                                                             ii.      Neither RFC 5885 (that defines BFD in VCCV) nor RFC 6428 (that defines Pro-Active CC, CV and RDI for MPLS-TP based on BFD)  are mentioned in the draft.

2.       Excessively strict behavior:

a.       The draft defines that any difference in the OAM capabilities of the PW endpoints would result in failure to set it up. One example of this behavior can be found in the following fragment copied from Section 3.1.1 “Establishment of OAM Entities and Functions”:

To achieve this, a Label Mapping message with the "OAM Alarms Enabled" flag cleared is sent.  In the message, the "OAM MEP Entities Desired" flag is set...  In addition, to configure and enable particular OAM functions, the PW OAM Functions TLV and relevant sub-TLVs MUST be included.

 

When the Label Mapping message is received by PE2, PE2 needs to check whether it supports the requested OAM configuration.  If it does not support the requested OAM configuration, a Label Release message MUST be returned to PE1, with a Status Code set to "PW OAM Parameters Rejected".  The PW signaling is complete and the PW will not be established.

b.      From my POV the behavior defined in the txt above is too harsh for PWs. I have suggested to the authors to consider a more liberal behavior model when the PW endpoints succeed setting up a PW regardless of whether there is a 100% match between their supported OAM functionality, and just agree on a commonly supported set of OAM functions which could be empty. Such a model, if accepted, would be also consistent with the model for adjustment of OAM parameters as defined in Section 3.1.2 “Adjustment of OAM Parameters”.

3.       Internal inconsistencies:

a.       BFD Identifiers sub-TLV:

                                                               i.      Mentioned twice as “MUST be included” in Section 4.2.1

                                                             ii.      Is not defined anywhere in the draft

                                                            iii.      This looks like a “copy and paste” notion from RFC 7487 – but the definition of the namesake TLV in this document is not applicable as it deals with MPLS-TP LSP identifiers only.

b.      Usage of the “OAM Alarms Enabled” flag:

                                                               i.      The text in at the end of Section 4.1 states that “The "OAM Alarms Enabled" flag is used to request the received PEs to enable (when set) or disable (when cleared) OAM alarms function”.

                                                             ii.      In almost all the cases considered in the draft, the “OAM Alarms Enabled” flag is used in accordance with the definition quoted above.

                                                            iii.      However, the text in Section 3.1.2 says that “Consequently, the ingress PE needs to keep its OAM sink and source functions running without any changes until the OAM parameters are updated.  However, in order to suppress spurious alarms, it also need to disable the alarm functions before the Label Mapping message, with the "OAM Alarms Enabled" flag cleared and the updated PW OAM Function TLV, is sent.  The OAM alarm function needs to be disabled until the corresponding response message is received”. To me this reads as the Label Mapping message to be sent to the “egress PE” in order to adjust the OAM parameters must have the “OAM Alarms Enabled” flag cleared in order to disable spurious OAM alarms there

                                                           iv.      Some of the use case of the “OAM Alarms Enabled” flag look unnecessary to me. E.g., when the PW is  being set up, I would expect it to suppress all alarms (OAM alarms included) until the PW setup is complete – and that without the need of any additional synchronization.

4.       Poor alignment with the standard PW setup process:

a.       RFC 4447 defines the SS-PW setup process as symmetric:

                                                               i.      Each PW endpoint sends its own Label Mapping message for one of the PW FECs to the peer and waits for receiving a matching (with the match condition defined by the FEC-specific rules) from the peer

                                                             ii.      The PW setup is successfully completed when both these events are encountered. Their order does not matter, and consequently there is no such thing as a “response Label Mapping message”

b.      However, the draft refers (in 3 different places) to a “response Label Mapping message”:

                                                               i.      In Section 3.1.2 when it says that “The OAM alarm function needs to be disabled until the corresponding response message is received”

                                                             ii.      In Section 3.2.2 (the same  text is used)

                                                            iii.      In Section 4.2.1 when it says that “The BFD Configuration Sub-TLV MUST include the following sub-TLVs in the "response" Label Mapping message”.

c.       This looks to me like a probable “copy and paste” error from RFC 7487. But this document uses RSVP-TE with its Path and Resv messages. PW setup is different, of course.

5.       Problematic use of sink/source terminology:

a.       The draft assumes some kind of separation between Sink and Source OAM functions, e.g., when it says in Section 3.1.1 that:

                                                               i.      The OAM sink functions must be enabled before the Label Mapping message (exposing the required OAM functionality to the remote PW endpoint) are enabled

                                                             ii.      The OAM source functions must be enabled only after a “response” Label Mapping message has been received

b.      In addition, to referring (explicitly or implicitly) to the non-existing “response” OAM Label Mapping message, this logic cannot, from my POV,  be applied to such an OAM function as BFD.

6.       Problematic reference to MIP function: To the best of my understanding:

a.       From my POV S-PEs always support MIP because:

                                                               i.      In order to reach a MIP the transmitter must set  the TTL in the PW label to a corresponding value

                                                             ii.      Once the TTL in the PW label expires in some S-PE, the relevant packet is always trapped

b.      It is not clear how MIP functionality can be used for pro-active OAM operations

7.       Multiple inconsistencies pertaining to use of BFD:

a.       Timer Negotiation:

                                                               i.      The draft defines (in section 4.2.1) an N flag that indicates whether negotiation of timer parameters using BFD control packets is or is not supported. If it is not supported, a Timer negotiation parameters sub-TLV must be used

                                                             ii.      According to Section 3.7.1 of RFC 6428 (which, AFAIK, equally applies to BFD in MPLS-TP Sections, LSPs and PWs), BFD sessions always start with 1 second transmission intervals until they reach their UP state, and then modify the timers to mutually agreed values using Poll/Final. Further, RFC 6428 specifies that the timer parameters may be used at any time, and that non-supporting implementations MUST set the BFD session on which such a change is required to Admin Down in response to an attempt of the remote endpoint of the session to change these parameters.

                                                            iii.      The bottom line, as I see it, that the draft is not compatible with RFC 6428

b.      Authentication:

                                                               i.      The draft defines an I flag that indicates that BFD authentication is required, and a BFD Authentication sub-TLV for synchronizing the authentication parameters.

                                                             ii.      I am not a security expert, and do not pretend to be one. But I think that the default authentication mechanism defined in the draft (SHA1 cryptographic authentication using a hard-coded – all zeroes – “pre-shared” secret”) would not pass any serious review by the security experts

                                                            iii.      I also do not understand why the BFD Authentication sub-TLV as defined in Section 4.2.1.3 carries the Authentication Key ID. As per RFC 5880, this key ID is carried as part of the Authentication Data in the Authentication Section of the all authenticated BFD Control Packets (and can be changed randomly and independently by each endpoint of the session).

c.       Local Discriminator sub-TLV:

                                                               i.      To the best of my understanding, the draft suggests (in Section 4.2.1.1) to exchange the values of the local discriminators between the endpoints of the BFD session

                                                             ii.      I do not really understand why this is needed, because RFC 5880 defines the mechanism for announcing My Discriminator value in the first packet of the session, and RFC 6428 only adds that this value MUST NOT be changed for an already established session.

Note: It is possible that these inconsistencies are copy-pasted from RFC 7487, but I did not review this document in detail.

8.       Packet Delay Measurement Issues: I did not review this part of the draft in detail, but several points look problematic to me:

a.       Inferred vs. Direct measurement

                                                               i.      According to RFC 6374 “inferred packet loss measurement” is the method that measures loss of synthetic probe packets while “direct packet loss measurement” counts actually transmitted and received packets.

                                                             ii.      As per the same RFC, packet delay measurements are always done based on synthetic probe packets (carrying timestamps)

                                                            iii.      The draft, however, mentions “inferred/direct packet delay measurement” while, AFAIK, direct delay measurement simply does not exist

b.      Delay Variation Measurement:

                                                               i.      The draft supports signaling of delay variation management function between the PW endpoints(Active/Inactive)

                                                             ii.      AFAIK, delay variation measurement is a purely local function, and there is no need to synchronize its activation between the two PW endpoints

Note: It is possible that these inconsistencies are also copy-pasted from RFC 7487.

 

Hopefully these comments will be useful for the authors and for the WG.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

From: Alexander Vainshtein
Sent: Wednesday, January 06, 2016 3:35 PM
To: 'Stewart Bryant'
Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; pals@ietf.org; pals-chairs@tools.ietf.org; wu.bo@zte.com.cn; Elisa.bellagamba@gmail.com
Subject: RE: [Pals] WG Last call draft-ietf-pals-tp-oam-config

 

Stewart,

I will try to read the draft and provide some feedback by January 22nd.

 

Meanwhile, while looking for the total number of pages in order to understand whether I can handle this, I have found a reference to a "Dyadic mode of an egress LSR". I have to admit that I do not know what this means, and a short look-up in the Internet did not return anything useful (unless somebody is going to use 2nd order tensors in MPLSJ).

 

If the authors could explain in advance what they mean, it would simplify the review.

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com

 

 

-----Original Message-----
From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 06, 2016 12:34 PM
To: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; pals@ietf.org; pals-chairs@tools.ietf.org; wu.bo@zte.com.cn; Elisa.bellagamba@gmail.com
Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config

 

Hi Folks

 

I guess that everyone has been busy over the holiday period.

 

I really need some indication on the list that the WG wants to publish this draft, otherwise I cannot take it forward to the IESG.

 

I also need some volunteers to read the draft and check it over for errors.

 

So please can  have reviews and confirmation that we should go forward with publication by 22nd January 2016.

 

Thanks

 

Stewart

 

On 23/12/2015 13:00, Stewart Bryant wrote:

> 

> 

> On 09/12/2015 14:13, Stewart Bryant wrote:

>> This message starts the WG Last Call on draft-ietf-pals-tp-oam-config.

>> 

>> This draft can be found at

>> 

>> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/

>> 

>> Please respond to this thread with substantive comments and an

>> indication of whether you have read the text and whether or not you

>> think it is ready for publication.

>> 

>> I will close WGLC on 23rd December.

>> 

>> Regards

>> 

>> - Stewart

> 

> PALS WG

> 

> I should close this LC today, but I have no evidence in terms of list

> traffic in response to this LC that I can present to the IESG  that

> anyone has read it or cares whether we  publish it of not.

> 

> Has anyone besides the chairs and authors read it?

> 

> Should we publish it, and why?

> 

> - Stewart

> 

 

_______________________________________________

Pals mailing list

Pals@ietf.org

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


--------------050007020600050505070206-- From nobody Thu Mar 3 04:28:09 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F75B1A92B2 for ; Thu, 3 Mar 2016 04:28:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQzEbb87kABT for ; Thu, 3 Mar 2016 04:28:05 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7444D1A92B1 for ; Thu, 3 Mar 2016 04:28:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CJM29321; Thu, 03 Mar 2016 12:28:00 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 12:27:59 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.177]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 20:27:54 +0800 From: Mach Chen To: Stewart Bryant , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org" Thread-Topic: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL Thread-Index: AQHRdUEVZpQs9LqZvk2cfLkjHket+p9HpKz7 Date: Thu, 3 Mar 2016 12:27:54 +0000 Message-ID: References: <56D821EA.5080007@gmail.com> In-Reply-To: <56D821EA.5080007@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.61.26] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.56D82DD1.000D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.177, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3ee1ce21b7fa688623f266aa61214262 Archived-At: Cc: "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 12:28:07 -0000 Hi Stewart, I am not ware of any other IPRs other than the one that has been disclosed. Best regards, Mach ________________________________________ From: Stewart Bryant [stewart.bryant@gmail.com] Sent: Thursday, March 03, 2016 19:37 To: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org Cc: pals-chairs@tools.ietf.org; pals@ietf.org Subject: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL Authors In doing the write up for this draft I cannot find a reply from each of you to the effect that you have declared all of the IPR that you know about= . This may be that I lost the emails when I changed system, or that I am looking under the wrong subject in the PALS/PWE3 archives, in which case I apologise. It is probably simplest if I ask you to reply to this email confirming that you have declared all the relevant IPR that you know about. As soon as I hear back I will make the final edit to the shepherd's report and change the status to publication requested. Stewart= From nobody Thu Mar 3 04:29:57 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2371A92B8 for ; Thu, 3 Mar 2016 04:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0V-78bCeHrn for ; Thu, 3 Mar 2016 04:29:54 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BC81A92B6 for ; Thu, 3 Mar 2016 04:29:53 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFH25434; Thu, 03 Mar 2016 12:29:51 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 3 Mar 2016 12:29:51 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0235.001; Thu, 3 Mar 2016 20:29:39 +0800 From: "Zhangfei (Philip)" To: Mach Chen , Stewart Bryant , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org" Thread-Topic: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL Thread-Index: AQHRdUEVZpQs9LqZvk2cfLkjHket+p9HpKz7gAABb7A= Date: Thu, 3 Mar 2016 12:29:38 +0000 Message-ID: References: <56D821EA.5080007@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.64.45] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.56D82E40.0054, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 1a4d8c34db6355dd095a2d816cccf214 Archived-At: Cc: "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 12:29:55 -0000 Hi Stewart, I am not ware of any other IPRs other than the one that has been disclosed. Best regards, Philip -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Mach Chen Sent: Thursday, March 03, 2016 1:28 PM To: Stewart Bryant; draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.or= g Cc: pals-chairs@tools.ietf.org; pals@ietf.org Subject: Re: [Pals] draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL Hi Stewart, I am not ware of any other IPRs other than the one that has been disclosed. Best regards, Mach ________________________________________ From: Stewart Bryant [stewart.bryant@gmail.com] Sent: Thursday, March 03, 2016 19:37 To: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org Cc: pals-chairs@tools.ietf.org; pals@ietf.org Subject: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL Authors In doing the write up for this draft I cannot find a reply from each of you= to the effect that you have declared all of the IPR that you know about. This may be that I lost the emails when I changed system, or that I am look= ing under the wrong subject in the PALS/PWE3 archives, in which case I apol= ogise. It is probably simplest if I ask you to reply to this email confirming that= you have declared all the relevant IPR that you know about. As soon as I hear back I will make the final edit to the shepherd's report = and change the status to publication requested. Stewart _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals From nobody Thu Mar 3 11:01:26 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8616F1B40E0 for ; Thu, 3 Mar 2016 11:01:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160303190125.1926.41740.idtracker@ietfa.amsl.com> Date: Thu, 03 Mar 2016 11:01:25 -0800 From: IETF Secretariat Archived-At: Subject: [Pals] Milestones changed for pals WG X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 19:01:25 -0000 Changed milestone "Submit PW Congestion Considerations to the IESG", resolved as "Done". Changed milestone "Submit STP Application of ICCP to the IESG", resolved as "Done". Changed milestone "Submit Pseudowire Redundancy on S-PE to the IESG", resolved as "Done". Changed milestone "Submit Unified Control Channel for PWs to the IESG", resolved as "Done". Changed milestone "Submit MAC Address Withdrawal over Static Pseudowire to the IESG", resolved as "Done". Changed milestone "Submit S-PE resilience for statically provisioned MS-PWs to the IESG", set due date to January 2016 from June 2016, resolved as "Done". Changed milestone "Submit MPLS-TP PW OAM Configuration to the IESG", set due date to March 2016 from June 2015. Changed milestone "Submit LDP extensions for PW Binding to LSP Tunnels to the IESG", set due date to March 2016 from June 2015. Changed milestone "Submit E-Tree Support in VPLS to the IESG jointly with the BESS WG", set due date to June 2016 from December 2015. Changed milestone "Submit PW Endpoint Fast Failure Protection to the IESG", set due date to June 2016 from June 2015. Changed milestone "Submit LDP-VPLS for Ethernet Broadcast and Multicast to the IESG", set due date to June 2016 from June 2015, added draft-ietf-pals-ldp-vpls-broadcast-exten to milestone, removed draft-ietf-l2vpn-ldp-vpls-broadcast-exten from milestone. Changed milestone "Submit MPLS LSP PW status refresh reduction for Static PWs to the IESG", set due date to June 2016 from December 2015. Changed milestone "Submit PIM Snooping over VPLS to the IESG", set due date to June 2016 from December 2015, added draft-ietf-pals-vpls-pim-snooping to milestone. Deleted milestone "Submit YANG data model for LDP VPLS to the IESG". Changed milestone "Submit L2VPN applicability statement for data center applications to the IESG", set due date to June 2017 from June 2016. Changed milestone "Submit YANG data model for SS-PWs and MS-PWs to the IESG", set due date to June 2017 from December 2016. URL: https://datatracker.ietf.org/wg/pals/charter/ From nobody Thu Mar 3 11:02:31 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E242C1B410E for ; Thu, 3 Mar 2016 11:02:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.15.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160303190229.9139.43441.idtracker@ietfa.amsl.com> Date: Thu, 03 Mar 2016 11:02:29 -0800 From: IETF Secretariat Archived-At: Subject: [Pals] Milestones changed for pals WG X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 19:02:30 -0000 Changed milestone "Submit P2MP PW Signaling (root initiated) to the IESG", set due date to June 2016 from December 2015. URL: https://datatracker.ietf.org/wg/pals/charter/ From nobody Thu Mar 3 16:51:44 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 096C01B30ED; Thu, 3 Mar 2016 16:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.357 X-Spam-Level: X-Spam-Status: No, score=-96.357 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlDaiIKMMNxF; Thu, 3 Mar 2016 16:51:40 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 78B9C1B30C2; Thu, 3 Mar 2016 16:51:39 -0800 (PST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 5B938F6575960; Fri, 4 Mar 2016 08:51:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id u240p7iQ078722; Fri, 4 Mar 2016 08:51:07 +0800 (GMT-8) (envelope-from wu.bo@zte.com.cn) In-Reply-To: <56D821EA.5080007@gmail.com> References: <56D821EA.5080007@gmail.com> To: Stewart Bryant MIME-Version: 1.0 X-KeepSent: 3861002A:5744D0F3-48257F6C:00038EA5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: wu.bo@zte.com.cn Date: Fri, 4 Mar 2016 08:51:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2016-03-04 08:51:07, Serialize complete at 2016-03-04 08:51:07 Content-Type: multipart/alternative; boundary="=_alternative 0004AE7748257F6C_=" X-MAIL: mse01.zte.com.cn u240p7iQ078722 Archived-At: Cc: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org, Pals , "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: [Pals] =?gb2312?b?tPC4tDogIGRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3?= =?gb2312?b?LW92ZXItYmlkaXItbHNwIC0gSVBSIFBPTEw=?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 00:51:43 -0000 This is a multipart message in MIME format. --=_alternative 0004AE7748257F6C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksU3Rld2FydA0KDQpJIGFtIG5vdCBhd2FyZSBhbnkgSVBSIHdpdGggdGhpcyBkcmFmdC4NCg0K Qm8gV3UNCg0KDQoNClN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+IA0K t6K8/sjLOiAgIlBhbHMiIDxwYWxzLWJvdW5jZXNAaWV0Zi5vcmc+DQoyMDE2LTAzLTAzIDE5OjM3 DQoNCsrVvP7Iyw0KZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRpci1sc3BAdG9v bHMuaWV0Zi5vcmcsIA0Ks63LzQ0KInBhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnIiA8cGFscy1j aGFpcnNAdG9vbHMuaWV0Zi5vcmc+LCAicGFsc0BpZXRmLm9yZyIgDQo8cGFsc0BpZXRmLm9yZz4N Ctb3zOINCltQYWxzXSBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcCAt IElQUiBQT0xMDQoNCg0KDQoNCg0KDQoNCkF1dGhvcnMNCg0KSW4gZG9pbmcgdGhlIHdyaXRlIHVw IGZvciB0aGlzIGRyYWZ0IEkgY2Fubm90IGZpbmQgYSByZXBseSBmcm9tIGVhY2ggb2YgDQp5b3Ug dG8gdGhlIGVmZmVjdCB0aGF0IHlvdSBoYXZlIGRlY2xhcmVkIGFsbCBvZiB0aGUgSVBSIHRoYXQg eW91IGtub3cgDQphYm91dC4NCg0KVGhpcyBtYXkgYmUgdGhhdCBJIGxvc3QgdGhlIGVtYWlscyB3 aGVuIEkgY2hhbmdlZCBzeXN0ZW0sIG9yIHRoYXQgSSBhbSANCmxvb2tpbmcgdW5kZXIgdGhlIHdy b25nIHN1YmplY3QgaW4gdGhlIFBBTFMvUFdFMyBhcmNoaXZlcywgaW4gd2hpY2ggY2FzZSANCkkg YXBvbG9naXNlLg0KDQpJdCBpcyBwcm9iYWJseSBzaW1wbGVzdCBpZiBJIGFzayB5b3UgdG8gcmVw bHkgdG8gdGhpcyBlbWFpbCBjb25maXJtaW5nIA0KdGhhdCB5b3UgaGF2ZSBkZWNsYXJlZCBhbGwg dGhlIHJlbGV2YW50ICBJUFIgdGhhdCB5b3Uga25vdyBhYm91dC4NCg0KQXMgc29vbiBhcyBJIGhl YXIgYmFjayBJIHdpbGwgbWFrZSB0aGUgZmluYWwgZWRpdCB0byB0aGUgc2hlcGhlcmQncyANCnJl cG9ydCBhbmQgY2hhbmdlIHRoZSBzdGF0dXMgdG8gcHVibGljYXRpb24gcmVxdWVzdGVkLg0KDQpT dGV3YXJ0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpQYWxzIG1haWxpbmcgbGlzdA0KUGFsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9wYWxzDQoNCg0K --=_alternative 0004AE7748257F6C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLFN0ZXdhcnQ8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gbm90IGF3YXJlIGFueSBJUFIg d2l0aCB0aGlzIGRyYWZ0LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Qm8gV3U8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+PGI+U3Rld2FydCBCcnlhbnQgJmx0O3N0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbSZn dDs8L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7I yzogJm5ic3A7JnF1b3Q7UGFscyZxdW90OyAmbHQ7cGFscy1ib3VuY2VzQGlldGYub3JnJmd0Ozwv Zm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDE2LTAzLTAzIDE5OjM3 PC9mb250Pg0KPHRkIHdpZHRoPTYzJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYi PmRyYWZ0LWlldGYtcGFscy1tcGxzLXRwLXB3LW92ZXItYmlkaXItbHNwQHRvb2xzLmlldGYub3Jn LA0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtwYWxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyZx dW90Ow0KJmx0O3BhbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnJmd0OywgJnF1b3Q7cGFsc0BpZXRm Lm9yZyZxdW90OyAmbHQ7cGFsc0BpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3 zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltQYWxz XSBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1vdmVyLWJpZGlyLWxzcA0KLSBJUFIgUE9MTDwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ PGJyPg0KQXV0aG9yczxicj4NCjxicj4NCkluIGRvaW5nIHRoZSB3cml0ZSB1cCBmb3IgdGhpcyBk cmFmdCBJIGNhbm5vdCBmaW5kIGEgcmVwbHkgZnJvbSBlYWNoIG9mDQo8YnI+DQp5b3UgdG8gdGhl IGVmZmVjdCB0aGF0IHlvdSBoYXZlIGRlY2xhcmVkIGFsbCBvZiB0aGUgSVBSIHRoYXQgeW91IGtu b3cgYWJvdXQuPGJyPg0KPGJyPg0KVGhpcyBtYXkgYmUgdGhhdCBJIGxvc3QgdGhlIGVtYWlscyB3 aGVuIEkgY2hhbmdlZCBzeXN0ZW0sIG9yIHRoYXQgSSBhbQ0KPGJyPg0KbG9va2luZyB1bmRlciB0 aGUgd3Jvbmcgc3ViamVjdCBpbiB0aGUgUEFMUy9QV0UzIGFyY2hpdmVzLCBpbiB3aGljaCBjYXNl DQo8YnI+DQpJIGFwb2xvZ2lzZS48YnI+DQo8YnI+DQpJdCBpcyBwcm9iYWJseSBzaW1wbGVzdCBp ZiBJIGFzayB5b3UgdG8gcmVwbHkgdG8gdGhpcyBlbWFpbCBjb25maXJtaW5nDQo8YnI+DQp0aGF0 IHlvdSBoYXZlIGRlY2xhcmVkIGFsbCB0aGUgcmVsZXZhbnQgJm5ic3A7SVBSIHRoYXQgeW91IGtu b3cgYWJvdXQuPGJyPg0KPGJyPg0KQXMgc29vbiBhcyBJIGhlYXIgYmFjayBJIHdpbGwgbWFrZSB0 aGUgZmluYWwgZWRpdCB0byB0aGUgc2hlcGhlcmQncyA8YnI+DQpyZXBvcnQgYW5kIGNoYW5nZSB0 aGUgc3RhdHVzIHRvIHB1YmxpY2F0aW9uIHJlcXVlc3RlZC48YnI+DQo8YnI+DQpTdGV3YXJ0PGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpQYWxzIG1haWxpbmcgbGlzdDxicj4NClBhbHNAaWV0Zi5vcmc8YnI+DQo8L2ZvbnQ+PC90 dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFscz48dHQ+ PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGFsczwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K --=_alternative 0004AE7748257F6C_=-- From nobody Thu Mar 3 21:00:17 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132E01B334C for ; Thu, 3 Mar 2016 21:00:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FedYkwlCuDUM for ; Thu, 3 Mar 2016 21:00:14 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5401B3349 for ; Thu, 3 Mar 2016 21:00:14 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-b5-56d9165cb38c Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 9B.2F.20792.C5619D65; Fri, 4 Mar 2016 06:00:12 +0100 (CET) Received: from ESESSMB201.ericsson.se ([169.254.1.71]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Fri, 4 Mar 2016 05:59:55 +0100 From: Attila Takacs To: Stewart Bryant , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org" Thread-Topic: draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL Thread-Index: AQHRdUEVrQN/LnWPsUmg9gfKqJq0iJ9II/6A Date: Fri, 4 Mar 2016 04:59:55 +0000 Message-ID: References: <56D821EA.5080007@gmail.com> In-Reply-To: <56D821EA.5080007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BFC92606560B3458A120B0632B3EA0F@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7lm6M2M0wg5ufRSw2HnzBZvH8ygJG izX/1jFZnHqQ6MDisXPWXXaPJUt+Mnl8ufyZLYA5issmJTUnsyy1SN8ugStjz/otLAUfWCuO PXvL2sB4hqWLkZNDQsBEovfDflYIW0ziwr31bCC2kMBhRok5M526GLmA7EWMEk0rH4EVsQkY SFxonswMkhARWMEosWjRYkaQBLNAgsS1j1eZQGxhAUeJrw8vgG0QEXCSaDl1jh3CNpI49fce 0AYODhYBFYkva9RAwrwC5hIPmr+wgISFBDQk5i8KBwlzCmhKfJyxEKyTEei276fWMEFsEpe4 9WQ+E8TNAhJL9pxnhrBFJV4+/scKMkZUQE+i60gFRFhJYtHtz1CtOhILdn9ig7CtJf48fgt1 vLbEsoWvmSGuEZQ4OfMJywRGiVlIts1C0j4LSfssJO2zkLQvYGRdxShanFpcnJtuZKSXWpSZ XFycn6eXl1qyiREYnwe3/LbawXjwueMhRgEORiUe3g0rrocJsSaWFVfmHmKU4GBWEuEV4r4Z JsSbklhZlVqUH19UmpNafIhRmoNFSZyX7dPlMCGB9MSS1OzU1ILUIpgsEwenVANj1wruJV/X Z3fOYldJz62LXex73uvV0j6Hug0GrlvYBZL99K8LKWV+VnZblcIiud6sp9eDuS/NesbuLjfJ CoEbqXVZvDY2mn1HbY7WPd+vK6l6wd2HheWUb/T3Q/vZt52572K7aM6unbYbdjN2Rolz3LPz eSWZ7XWmaL7QEqnP02b8vfE1OVGJpTgj0VCLuag4EQCNMEevywIAAA== Archived-At: Cc: "pals-chairs@tools.ietf.org" , "pals@ietf.org" Subject: Re: [Pals] draft-ietf-pals-mpls-tp-pw-over-bidir-lsp - IPR POLL X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 05:00:16 -0000 I do not know about relevant IPR. Thanks, Attila On 3/3/16, 03:37, "Stewart Bryant" wrote: > >Authors > >In doing the write up for this draft I cannot find a reply from each of >you to the effect that you have declared all of the IPR that you know >about. > >This may be that I lost the emails when I changed system, or that I am >looking under the wrong subject in the PALS/PWE3 archives, in which case >I apologise. > >It is probably simplest if I ask you to reply to this email confirming >that you have declared all the relevant IPR that you know about. > >As soon as I hear back I will make the final edit to the shepherd's >report and change the status to publication requested. > >Stewart From nobody Mon Mar 7 06:55:02 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3201B4200 for ; Mon, 7 Mar 2016 06:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNSj0NUapCev for ; Mon, 7 Mar 2016 06:54:58 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360451B41F4 for ; Mon, 7 Mar 2016 06:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13318; q=dns/txt; s=iport; t=1457362497; x=1458572097; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=A34RqQqZ0C2kX1jMx6Jdflo/xYpV3AP4Pn+uwO5r16E=; b=ENtGWzcJu7Z5BFhFk38+fGuLyn9TdnfahZbbZaTAEMpMTWFRIQKGQz9O qg5IFgYkFMUPn5pJp+PDiInAY3gMetzwlEZzOvjcqN5yNhQSrlyIdBaDd 54gFTzLQtXxzJy8bcpMowukrebjR/mq6QFsxTPovy7vmBwAlPk/ekQ+Ei Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQATld1W/5BdJa1TBwOCbkxSbQa4J?= =?us-ascii?q?4ITAQ2BaSOFbAKBKTgUAQEBAQEBAWQnhEEBAQEEZgMBHQICAQgRAwECKAcbFxQ?= =?us-ascii?q?JCAIEARKIIg6xX4NCiW8BAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIEKhQmEPYQKB?= =?us-ascii?q?gsBGQoBBRUBFQIPgkyBJwWNMIVKhDABhWKICoFjS4N5hzmBGo5UAR4BAUKDZGo?= =?us-ascii?q?BiAMHFx0BfQEBAQ?= X-IronPort-AV: E=Sophos; i="5.22,551,1449532800"; d="scan'208,217"; a="80424186" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 14:54:56 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u27EsuUf026599 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 14:54:56 GMT Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 08:54:55 -0600 Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 08:54:55 -0600 From: "Patrice Brissette (pbrisset)" To: David Sinicrope , "pals@ietf.org" Thread-Topic: [Pals] PALS IETF 95 Slot Requests - Buenos Aires Thread-Index: AQHReIFPEM5f6IdlBUOvZSsjDJuzow== Date: Mon, 7 Mar 2016 14:54:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [161.44.213.55] Content-Type: multipart/alternative; boundary="_000_D303006C86CCFpbrissetciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Pals] PALS IETF 95 Slot Requests - Buenos Aires X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2016 14:55:00 -0000 --_000_D303006C86CCFpbrissetciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable David, I need a slot for L2VPN Yang model Regards, Patrice [http://www.cisco.com/web/europe/images/email/signature/est2014/logo_06.= png?ct=3D1406640631632] Patrice Brissette TECHNICAL LEADER.ENGINEERING pbrisset@cisco.com Phone: +1 613 254 3336 Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada Cisco.com [http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif] Think before = you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. From: Pals > on behalf = of David Sinicrope > Date: Wednesday, March 2, 2016 at 11:43 AM To: "pals@ietf.org" > Subject: [Pals] PALS IETF 95 Slot Requests - Buenos Aires Hi All, It's that time again. If you need a presentation slot for the upcoming IETF PALS session, please = reply to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests.) Form: 1. Topic: (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker: you only need to provide the file name= to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-= mpls-eth-oam-iwk/): 3. Brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting: (e.g., need to address security iss= ues and get direction from the WG): 4. Requested duration: (norm/default is 10 min): 5. Speaker name: (e.g., Dave SINICROPE= ): Thanks! Dave --_000_D303006C86CCFpbrissetciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <7F1EE13F4866C74285EA4E13312714F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
David,

I need a slot for L2VPN Yang model


Regards,

Patrice

   

Patrice Brissette
TECHNICAL LEADER.ENGINEERING

pbrisset@cisco.com
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE Canada
Cisco.com
Think before you print.

This email may contain confidential and privileged material for the sole= use of the intended recipient. Any review, use, distribution or disclosure= by others is strictly prohibited. If you are not the intended recipient (o= r authorized to receive for the recipient), please contact the sender by reply email and delete all copies= of this message.

Please click here for Company Registration Information.


From: Pals <pals-bounces@ietf.org> on behalf of David Sinic= rope <david.sinicrope@er= icsson.com>
Date: Wednesday, March 2, 2016 at 1= 1:43 AM
To: "pals@ietf.org" <pals@i= etf.org>
Subject: [Pals] PALS IETF 95 Slot R= equests - Buenos Aires


Hi All,

It's that time again. 

If you need a presentation slot for the upcoming IET= F PALS session, please reply to this email (subject intact= ) completing the form below.   

Please use this form and&n= bsp;please reply to this email with the subject i= ntact.  (Not doing so probably means your request will not trigger the= filter I use to identify PALS slot requests.)

Form:
1. Topic:= (e.g., MPLS and Ethernet OAM Interworking):

2. URL to your draft on D= atatracker:&n= bsp;you only need to provide the file name to the example URL (e.g., http://datatracker.ietf.org/doc/draft-i= etf-pwe3-mpls-eth-oam-iwk/):   

3. Brief statement of objectives and issues to be= discussed and resolved via the presentation during the meeting:  = (e.g., need to address security issues and get direction from the WG): &nbs= p;

4. Requested duration: (norm/default is 10 min):=

5. Speaker name: <Given-name FAMILY-N= AME-IN-ALL-CAPS> (e.g., Dave SINICROPE):  

 

Thanks!
Dave<= /div>
--_000_D303006C86CCFpbrissetciscocom_-- From nobody Mon Mar 7 17:43:10 2016 Return-Path: X-Original-To: pals@ietfc.amsl.com Delivered-To: pals@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D72211CD817 for ; Mon, 7 Mar 2016 17:43:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iA1WWS5Ef4aw for ; Mon, 7 Mar 2016 17:43:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 6CE2B1CD81B for ; Mon, 7 Mar 2016 17:43:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CFL47588; Tue, 08 Mar 2016 01:42:58 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 8 Mar 2016 01:42:56 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.177]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 8 Mar 2016 09:42:50 +0800 From: Mach Chen To: Stewart Bryant , Alexander Vainshtein Thread-Topic: [Pals] WG Last call draft-ietf-pals-tp-oam-config Thread-Index: AQHRMovQJO31cjsjYE+2QmNLAFoJYp7ufB6QgBdUjFCABfKJ4IA717EAgAe2jkA= Date: Tue, 8 Mar 2016 01:42:49 +0000 Message-ID: References: <56683703.9040101@gmail.com> <567A9B08.5030001@gmail.com> <568CED9B.5000701@gmail.com> <56D8254C.4030702@gmail.com> In-Reply-To: <56D8254C.4030702@gmail.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.102.135] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6FB424SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.56DE2E23.0051, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.177, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: e9316894dfe0ce65117d1f151d2b578d Archived-At: Cc: "draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org" , "Elisa.bellagamba@gmail.com" , "pals-chairs@tools.ietf.org" , "wu.bo@zte.com.cn" , "pals@ietf.org" Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2016 01:43:09 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6FB424SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Stewart, Thanks for the reminding, we received quite a few valuable comments from Sa= sha, we are trying to address them. If there are additional comments, pleas= e send them to us. Thanks, Mach From: Stewart Bryant [mailto:stewart.bryant@gmail.com] Sent: Thursday, March 03, 2016 7:52 PM To: Mach Chen; Alexander Vainshtein Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; Elisa.bellagamba@gma= il.com; pals-chairs@tools.ietf.org; wu.bo@zte.com.cn; pals@ietf.org Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config Mach The document has expired. Please can you refresh with your current version and let the WG know if you= still have outstanding comments to address. I have received some comments direct to me. I have asked if the reviewer wi= ll post direct to the list. If not, I will include them in my review of the= next version. - Stewart On 25/01/2016 02:02, Mach Chen wrote: Hi Sasha, Many thanks for your detailed review and comment! We'll address them in the next revision. Best regards, Mach From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Alexander Vainshtein Sent: Friday, January 22, 2016 11:08 PM To: Stewart Bryant Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; Elisa.bellagamba@gmail.com; pals-chairs@tools.ietf.org; wu.bo@zte.com.cn; pals@ietf.org Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config Stewart (and all), Following your call for volunteers I have read the draft (or, at least most= of it - I did not go into detail regarding the part that discusses PM func= tions), and I have multiple concerns regarding it. I have sent most of thes= e concerns to the authors off-list, and received some feedback from Mach. M= y concerns are listed below: 1. References to some basic documents are missing and/or incomplete: a. RFC 4447: i. From= my POV, the draft is about some extensions to RFC 4447, but this document = is only mentions this document in Section 6 "Security Considerations" ii. The d= raft silently ignores the differences between FEC-128 and FEC-129. If (as t= he authors have claimed during our off-list discussions) it is equally appl= icable to both, this should be explicitly stated in the document IMO. b. RFC 5085: i. To t= he best of my understanding, all PW OAM messages run in VCCV, but neither R= FC 5085 nor RFC 7708 are referenced in the document. Actually, even the ter= m "VCCV" is not mentioned in the document. ii. In pa= rticular, the draft silently ignores the situation when the PW endpoints co= uld not agree on any VCCV Type so that any attempts to run OAM on the PW wo= uld fail - even if the PW endpoints agree about all specific OAM functions = and their parameters. From my POV if the PW endpoints could not agree on th= e VCCV type, all OAM-related parameters should be simply silently ignored c. RFC 5885 and RFC 6428 and: i. The = draft discusses setup of BFD as pro-active OAM mechanism for PWs ii. Neith= er RFC 5885 (that defines BFD in VCCV) nor RFC 6428 (that defines Pro-Activ= e CC, CV and RDI for MPLS-TP based on BFD) are mentioned in the draft. 2. Excessively strict behavior: a. The draft defines that any difference in the OAM capabilities of t= he PW endpoints would result in failure to set it up. One example of this b= ehavior can be found in the following fragment copied from Section 3.1.1 "E= stablishment of OAM Entities and Functions": To achieve this, a Label Mapping message with the "OAM Alarms Enabled" flag= cleared is sent. In the message, the "OAM MEP Entities Desired" flag is s= et... In addition, to configure and enable particular OAM functions, the P= W OAM Functions TLV and relevant sub-TLVs MUST be included. When the Label Mapping message is received by PE2, PE2 needs to check wheth= er it supports the requested OAM configuration. If it does not support the= requested OAM configuration, a Label Release message MUST be returned to P= E1, with a Status Code set to "PW OAM Parameters Rejected". The PW signali= ng is complete and the PW will not be established. b. From my POV the behavior defined in the txt above is too harsh for = PWs. I have suggested to the authors to consider a more liberal behavior mo= del when the PW endpoints succeed setting up a PW regardless of whether the= re is a 100% match between their supported OAM functionality, and just agre= e on a commonly supported set of OAM functions which could be empty. Such a= model, if accepted, would be also consistent with the model for adjustment= of OAM parameters as defined in Section 3.1.2 "Adjustment of OAM Parameter= s". 3. Internal inconsistencies: a. BFD Identifiers sub-TLV: i. Ment= ioned twice as "MUST be included" in Section 4.2.1 ii. Is no= t defined anywhere in the draft iii. This = looks like a "copy and paste" notion from RFC 7487 - but the definition of = the namesake TLV in this document is not applicable as it deals with MPLS-T= P LSP identifiers only. b. Usage of the "OAM Alarms Enabled" flag: i. The = text in at the end of Section 4.1 states that "The "OAM Alarms Enabled" fla= g is used to request the received PEs to enable (when set) or disable (when= cleared) OAM alarms function". ii. In al= most all the cases considered in the draft, the "OAM Alarms Enabled" flag i= s used in accordance with the definition quoted above. iii. Howev= er, the text in Section 3.1.2 says that "Consequently, the ingress PE needs= to keep its OAM sink and source functions running without any changes unti= l the OAM parameters are updated. However, in order to suppress spurious a= larms, it also need to disable the alarm functions before the Label Mapping= message, with the "OAM Alarms Enabled" flag cleared and the updated PW OAM= Function TLV, is sent. The OAM alarm function needs to be disabled until = the corresponding response message is received". To me this reads as the La= bel Mapping message to be sent to the "egress PE" in order to adjust the OA= M parameters must have the "OAM Alarms Enabled" flag cleared in order to di= sable spurious OAM alarms there iv. Some of= the use case of the "OAM Alarms Enabled" flag look unnecessary to me. E.g.= , when the PW is being set up, I would expect it to suppress all alarms (O= AM alarms included) until the PW setup is complete - and that without the n= eed of any additional synchronization. 4. Poor alignment with the standard PW setup process: a. RFC 4447 defines the SS-PW setup process as symmetric: i. Each= PW endpoint sends its own Label Mapping message for one of the PW FECs to = the peer and waits for receiving a matching (with the match condition defin= ed by the FEC-specific rules) from the peer ii. The P= W setup is successfully completed when both these events are encountered. T= heir order does not matter, and consequently there is no such thing as a "r= esponse Label Mapping message" b. However, the draft refers (in 3 different places) to a "response La= bel Mapping message": i. In S= ection 3.1.2 when it says that "The OAM alarm function needs to be disabled= until the corresponding response message is received" ii. In Se= ction 3.2.2 (the same text is used) iii. In Se= ction 4.2.1 when it says that "The BFD Configuration Sub-TLV MUST include t= he following sub-TLVs in the "response" Label Mapping message". c. This looks to me like a probable "copy and paste" error from RFC 7= 487. But this document uses RSVP-TE with its Path and Resv messages. PW set= up is different, of course. 5. Problematic use of sink/source terminology: a. The draft assumes some kind of separation between Sink and Source = OAM functions, e.g., when it says in Section 3.1.1 that: i. The = OAM sink functions must be enabled before the Label Mapping message (exposi= ng the required OAM functionality to the remote PW endpoint) are enabled ii. The O= AM source functions must be enabled only after a "response" Label Mapping m= essage has been received b. In addition, to referring (explicitly or implicitly) to the non-exi= sting "response" OAM Label Mapping message, this logic cannot, from my POV,= be applied to such an OAM function as BFD. 6. Problematic reference to MIP function: To the best of my understan= ding: a. From my POV S-PEs always support MIP because: i. In o= rder to reach a MIP the transmitter must set the TTL in the PW label to a = corresponding value ii. Once = the TTL in the PW label expires in some S-PE, the relevant packet is always= trapped b. It is not clear how MIP functionality can be used for pro-active OA= M operations 7. Multiple inconsistencies pertaining to use of BFD: a. Timer Negotiation: i. The = draft defines (in section 4.2.1) an N flag that indicates whether negotiati= on of timer parameters using BFD control packets is or is not supported. If= it is not supported, a Timer negotiation parameters sub-TLV must be used ii. Accor= ding to Section 3.7.1 of RFC 6428 (which, AFAIK, equally applies to BFD in = MPLS-TP Sections, LSPs and PWs), BFD sessions always start with 1 second tr= ansmission intervals until they reach their UP state, and then modify the t= imers to mutually agreed values using Poll/Final. Further, RFC 6428 specifi= es that the timer parameters may be used at any time, and that non-supporti= ng implementations MUST set the BFD session on which such a change is requi= red to Admin Down in response to an attempt of the remote endpoint of the s= ession to change these parameters. iii. The b= ottom line, as I see it, that the draft is not compatible with RFC 6428 b. Authentication: i. The = draft defines an I flag that indicates that BFD authentication is required,= and a BFD Authentication sub-TLV for synchronizing the authentication para= meters. ii. I am = not a security expert, and do not pretend to be one. But I think that the d= efault authentication mechanism defined in the draft (SHA1 cryptographic au= thentication using a hard-coded - all zeroes - "pre-shared" secret") would = not pass any serious review by the security experts iii. I als= o do not understand why the BFD Authentication sub-TLV as defined in Sectio= n 4.2.1.3 carries the Authentication Key ID. As per RFC 5880, this key ID i= s carried as part of the Authentication Data in the Authentication Section = of the all authenticated BFD Control Packets (and can be changed randomly a= nd independently by each endpoint of the session). c. Local Discriminator sub-TLV: i. To t= he best of my understanding, the draft suggests (in Section 4.2.1.1) to exc= hange the values of the local discriminators between the endpoints of the B= FD session ii. I do = not really understand why this is needed, because RFC 5880 defines the mech= anism for announcing My Discriminator value in the first packet of the sess= ion, and RFC 6428 only adds that this value MUST NOT be changed for an alre= ady established session. Note: It is possible that these inconsistencies are copy-pasted from RFC 74= 87, but I did not review this document in detail. 8. Packet Delay Measurement Issues: I did not review this part of the= draft in detail, but several points look problematic to me: a. Inferred vs. Direct measurement i. Acco= rding to RFC 6374 "inferred packet loss measurement" is the method that mea= sures loss of synthetic probe packets while "direct packet loss measurement= " counts actually transmitted and received packets. ii. As pe= r the same RFC, packet delay measurements are always done based on syntheti= c probe packets (carrying timestamps) iii. The d= raft, however, mentions "inferred/direct packet delay measurement" while, A= FAIK, direct delay measurement simply does not exist b. Delay Variation Measurement: i. The = draft supports signaling of delay variation management function between the= PW endpoints(Active/Inactive) ii. AFAIK= , delay variation measurement is a purely local function, and there is no n= eed to synchronize its activation between the two PW endpoints Note: It is possible that these inconsistencies are also copy-pasted from R= FC 7487. Hopefully these comments will be useful for the authors and for the WG. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Wednesday, January 06, 2016 3:35 PM To: 'Stewart Bryant' Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; pals@ietf.org; = pals-chairs@tools.ietf.org; wu.bo@zte.co= m.cn; Elisa.bellagamba@gmail.com Subject: RE: [Pals] WG Last call draft-ietf-pals-tp-oam-config Stewart, I will try to read the draft and provide some feedback by January 22nd. Meanwhile, while looking for the total number of pages in order to understa= nd whether I can handle this, I have found a reference to a "Dyadic mode of= an egress LSR". I have to admit that I do not know what this means, and a = short look-up in the Internet did not return anything useful (unless somebo= dy is going to use 2nd order tensors= in MPLS:)). If the authors could explain in advance what they mean, it would simplify t= he review. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Pals [mailto:pals-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: Wednesday, January 06, 2016 12:34 PM To: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; pals@ietf.org; = pals-chairs@tools.ietf.org; wu.bo@zte.co= m.cn; Elisa.bellagamba@gmail.com Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config Hi Folks I guess that everyone has been busy over the holiday period. I really need some indication on the list that the WG wants to publish this= draft, otherwise I cannot take it forward to the IESG. I also need some volunteers to read the draft and check it over for errors. So please can have reviews and confirmation that we should go forward with= publication by 22nd January 2016. Thanks Stewart On 23/12/2015 13:00, Stewart Bryant wrote: > > > On 09/12/2015 14:13, Stewart Bryant wrote: >> This message starts the WG Last Call on draft-ietf-pals-tp-oam-config. >> >> This draft can be found at >> >> https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/ >> >> Please respond to this thread with substantive comments and an >> indication of whether you have read the text and whether or not you >> think it is ready for publication. >> >> I will close WGLC on 23rd December. >> >> Regards >> >> - Stewart > > PALS WG > > I should close this LC today, but I have no evidence in terms of list > traffic in response to this LC that I can present to the IESG that > anyone has read it or cares whether we publish it of not. > > Has anyone besides the chairs and authors read it? > > Should we publish it, and why? > > - Stewart > _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6FB424SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stewart= ,

 = ;

Thanks for= the reminding, we received quite a few valuable comments from Sasha, we ar= e trying to address them. If there are additional comments, please send them to us.

 = ;

Thanks,

Mach<= /o:p>

 = ;

From:= Stewart Bryant [mai= lto:stewart.bryant@gmail.com]
Sent: Thursday, March 03, 2016 7:52 PM
To: Mach Chen; Alexander Vainshtein
Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; Elisa.bellaga= mba@gmail.com; pals-chairs@tools.ietf.org; wu.bo@zte.com.cn; pals@ietf.org<= br> Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config<= /o:p>

 

= Mach

The document has expired.

Please can you refresh with your current version and let the WG know if you= still have outstanding comments to address.

I have received some comments direct to me. I have asked if the reviewer wi= ll post direct to the list. If not, I will include them in my review of the= next version.

- Stewart


On 25/01/2016 02:02, Mach Chen = wrote:

Hi Sasha,<= /span>

 

Many thank= s for your detailed review and comment!

 

We’l= l address them in the next revision.=

 

Best regar= ds,

Mach

 

From: Pals [mailto= :pals-bounces@ietf.org] On Behalf Of Alexander Vainshtein
Sent: Friday, January 22, 2016 11:08 PM
To: Stewart Bryant
Cc: draft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; Elisa.bellagamba@gmail.com; pals-chairs@tools.ietf.org; wu.bo@z= te.com.cn; pals@ietf.org
Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config

 

Ste= wart (and all),

Fol= lowing your call for volunteers I have read the draft (or, at least most of= it – I did not go into detail regarding the part that discusses PM functions), and I have multiple concerns regarding it. I have sent most= of these concerns to the authors off-list, and received some feedback from= Mach. My concerns are listed below:=

&nb= sp;

1.       References to some basi= c documents are missing and/or incomplete:

a.       RFC 4447:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      From my POV, the draft is = about some extensions to RFC 4447, but this document is only mentions this = document in Section 6 “Security Considerations”

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      The draft silently ignores= the differences between FEC-128 and FEC-129. If (as the authors have claim= ed during our off-list discussions) it is equally applicable to both, this should be explicitly stated in the document IMO.

b.      RFC 5085:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      To the best of my understa= nding, all PW OAM messages run in VCCV, but neither RFC 5085 nor RFC 7708 a= re referenced in the document. Actually, even the term “VCCV” is not mentioned in the document. <= /span>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      In particular, the draft s= ilently ignores the situation when the PW endpoints could not agree on any VCCV Type so that any attemp= ts to run OAM on the PW would fail – even if the PW endpoints agree a= bout all specific OAM functions and their parameters. From my POV if the PW= endpoints could not agree on the VCCV type, all OAM-related parameters should be simply silently ignored<= span lang=3D"EN-US">

c.       RFC 5885 and RFC 6428 and:=

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      The draft discusses setup = of BFD  as pro-active OAM mechanism for PWs

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      Neither RFC 5885 (that def= ines BFD in VCCV) nor RFC 6428 (that defines Pro-Active CC, CV and RDI for = MPLS-TP based on BFD)  are mentioned in the draft.

2.       Excessively strict beha= vior:

a.       The draft defines that any= difference in the OAM capabilities of the PW endpoints would result in fai= lure to set it up. One example of this behavior can be found in the following fragment copied from Section 3.1.1 “Establishmen= t of OAM Entities and Functions”:

To achieve this, a Label Mapping message with the "= ;OAM Alarms Enabled" flag cleared is sent.  In the message, the "OAM MEP Entities Desired" flag is set...  In addition, to = configure and enable particular OAM functions, the PW OAM Functions TLV and= relevant sub-TLVs MUST be included.=

 

When the Label Mapping message is received by PE2, PE2 needs to check whether it supports th= e requested OAM configuration.  If it does not support the requested O= AM configuration, a Label Release message MUST be returned to PE1, with a S= tatus Code set to "PW OAM Parameters Rejected".  The PW signaling is complete and the PW will not be established.

b.      From my POV the behavior d= efined in the txt above is too harsh for PWs. I have suggested to the autho= rs to consider a more liberal behavior model when the PW endpoints succeed setting up a PW regardless of whether there is a 100% ma= tch between their supported OAM functionality, and just agree on a commonly= supported set of OAM functions which could be empty. Such a model, if acce= pted, would be also consistent with the model for adjustment of OAM parameters as defined in Section 3.1.2 = 220;Adjustment of OAM Parameters”.

3.       Internal inconsistencie= s:

a.       BFD Identifiers sub-TLV:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      Mentioned twice as “= MUST be included” in Section 4.2.1

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      Is not defined anywhere in= the draft

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      iii.     = ; This looks like a “c= opy and paste” notion from RFC 7487 – but the definition of the= namesake TLV in this document is not applicable as it deals with MPLS-TP LSP identifiers only.

b.      Usage of the “OAM Al= arms Enabled” flag:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      The text in at the end of = Section 4.1 states that “The "OAM Alarms Enabled&qu= ot; flag is used to request the received PEs to enable (when set) or disabl= e (when cleared) OAM alarms function”.

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      In almost all the cases co= nsidered in the draft, the “OAM Alarms Enabled” flag is used in= accordance with the definition quoted above.

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      iii.     = ; However, the text in Secti= on 3.1.2 says that “Co= nsequently, the ingress PE needs to keep its OAM sink and source functions running wit= hout any changes until the OAM parameters are updated.  However, in or= der to suppress spurious alarms, it also need to disable the alarm function= s before the Label Mapping message, with the "OAM Alarms Enabled" flag = cleared and the updated PW OAM Function TLV, is sent.  The OAM = alarm function needs to be disabled until the corresponding response messag= e is received”. To me this reads as the Label Mapping message to be sent to the “egr= ess PE” in order to adjust the OAM parameters must have the “OA= M Alarms Enabled” flag cleared in order to disable spurious OAM alarm= s there

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     iv.      Some of the use case of th= e “OAM Alarms Enabled” flag look unnecessary to me. E.g., when = the PW is  being set up, I would expect it to suppress all alarms (OAM alarms included) until the PW setup is complete – and that without t= he need of any additional synchronization.=

4.       Poor alignment with the= standard PW setup process:

a.       RFC 4447 defines the SS-PW= setup process as symmetric:<= /p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      Each PW endpoint sends its= own Label Mapping message for one of the PW FECs to the peer and waits for= receiving a matching (with the match condition defined by the FEC-specific rules) from the peer<= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      The PW setup is successful= ly completed when both these events are encountered. Their order does not matter, and = consequently there is no such thing as a “response Label Mapping mess= age”

b.      However, the draft refers = (in 3 different places) to a “response Label Mapping message”:<= /span>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      In Section 3.1.2 when it s= ays that “The OAM alar= m function needs to be disabled until the correspon= ding response message is received”

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      In Section 3.2.2 (the same=  text is used)

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      iii.     = ; In Section 4.2.1 when it s= ays that “The BFD Conf= iguration Sub-TLV MUST include the following sub-TLVs in the "response" Label Mapp= ing message”.=

c.       This looks to me like a pr= obable “copy and paste” error from RFC 7487. But this document = uses RSVP-TE with its Path and Resv messages. PW setup is different, of course.

5.       Problematic use of sink= /source terminology:

a.       The draft assumes some kin= d of separation between Sink and Source OAM functions, e.g., when it says i= n Section 3.1.1 that:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      The OAM sink functions must be enabled= before the Label Mapping message (exposing the required OAM functionality = to the remote PW endpoint) are enabled

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      The OAM source functions must be enabl= ed only after a “response” Label Mapping message has been recei= ved

b.      In addition, to referring = (explicitly or implicitly) to the non-existing “response” OAM L= abel Mapping message, this logic cannot, from my POV,  be applied to such an OAM function as BFD.=

6.       Problematic reference t= o MIP function: To the= best of my understanding:

a.       From my POV S-PEs always s= upport MIP because:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      In order to reach a MIP th= e transmitter must set  the TTL in the PW label to a corresponding val= ue

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      Once the TTL in the PW lab= el expires in some S-PE, the relevant packet is always trapped

b.      It is not clear how MIP fu= nctionality can be used for pro-active OAM operations

7.       Multiple inconsistencie= s pertaining to use of BFD:

a.       Timer Negotiation:<= span lang=3D"EN-US">

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      The draft defines (in sect= ion 4.2.1) an N flag that indicates whether negotiation of timer parameters= using BFD control packets is or is not supported. If it is not supported, a Timer negotiation parameters sub-TLV must be used

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      According to Section 3.7.1= of RFC 6428 (which, AFAIK, equally applies to BFD in MPLS-TP Sections, LSP= s and PWs), BFD sessions always start with 1 second transmission intervals until they reach their UP state, and then modify the timers to m= utually agreed values using Poll/Final. Further, RFC 6428 specifies that th= e timer parameters may be used at any time, and that non-supporting impleme= ntations MUST set the BFD session on which such a change is required to Admin Down in response to an attempt= of the remote endpoint of the session to change these parameters.

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      iii.     = ; The bottom line, as I see = it, that the draft is not compatible with RFC 6428

b.      Authentication:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      The draft defines an I fla= g that indicates that BFD authentication is required, and a BFD Authenticat= ion sub-TLV for synchronizing the authentication parameters.

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      I am not a security expert= , and do not pretend to be one. But I think that the default authentication= mechanism defined in the draft (SHA1 cryptographic authentication using a hard-coded – all zeroes – “pre-shared” sec= ret”) would not pass any serious review by the security experts

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      iii.     = ; I also do not understand w= hy the BFD Authentication sub-TLV as defined in Section 4.2.1.3 carries the= Authentication Key ID. As per RFC 5880, this key ID is carried as part of the Authentication Data in the Authentication Section o= f the all authenticated BFD Control Packets (and can be changed randomly an= d independently by each endpoint of the session).

c.       Local Discriminator sub-TL= V:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      To the best of my understa= nding, the draft suggests (in Section 4.2.1.1) to exchange the values of th= e local discriminators between the endpoints of the BFD session

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      I do not really understand= why this is needed, because RFC 5880 defines the mechanism for announcing = My Discriminator value in the first packet of the session, and RFC 6428 only adds that this value MUST NOT be changed for an already = established session.

= Note: It is possible t= hat these inconsistencies are copy-pasted from RFC 7487, but I did not review this d= ocument in detail.

8.       Packet Delay Measuremen= t Issues: I did not re= view this part of the draft in detail, but several points look problematic to m= e:

a.       Inferred vs. Direct measur= ement

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      According to RFC 6374 R= 20;inferred packet loss measurement” is the method that measures loss= of synthetic probe packets while “direct packet loss measurementR= 21; counts actually transmitted and received packets.

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      As per the same RFC, packe= t delay measurements are always done based on synthetic probe packets (carr= ying timestamps)

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;      iii.     = ; The draft, however, mentio= ns “inferred/direct packet delay measurement” while, AFAIK, dir= ect delay measurement simply does not exist

b.      Delay Variation Measuremen= t:

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         i.      The draft supports signali= ng of delay variation management function between the PW endpoints(Active/I= nactive)

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       ii.      AFAIK, delay variation mea= surement is a purely local function, and there is no need to synchronize it= s activation between the two PW endpoints<= /o:p>

= Note: It is possible t= hat these inconsistencies are also copy-pasted from RFC 7487.

=  

Hop= efully these comments will be useful for the authors and for the WG.=

&nb= sp;

Reg= ards,

Sas= ha

&nb= sp;

Off= ice: +972-39266302

Cel= l:      +972-549266302

Ema= il:   Alexander.Vainshtein@ec= itele.com

&nb= sp;

 

Stewart,

I will try to rea= d the draft and provide some feedback by January 22nd.

 

Meanwhile, while = looking for the total number of pages in order to understand whether I can = handle this, I have found a reference to a "Dyadic mode of an egress LSR". I have to admit that I do not know what this m= eans, and a short look-up in the Internet did not return anything useful (u= nless somebody is going to use 2nd order tensors in = MPLSJ).

 

If the authors co= uld explain in advance what they mean, it would simplify the review.=

 

Regards,

Sasha

 

Office: +972-= 39266302

Cell:  =     +972-549266302

Email:  = ; Alexander.Vainshtein@ec= itele.com

 

 

-----Original Mes= sage-----
From: Pals [mailto:pals-bounces@ie= tf.org] On Behalf Of Stewart Bryant
Sent: Wednesday, January 06, 2016 12:34 PM
To: dr= aft-ietf-pals-mpls-tp-oam-config@tools.ietf.org; pals@ietf.org; pals-chairs@tools.ietf.org; wu.bo@z= te.com.cn; Elisa.bellagamba@gmail.com
Subject: Re: [Pals] WG Last call draft-ietf-pals-tp-oam-config

 

Hi Folks

 

I guess that ever= yone has been busy over the holiday period.

 

I really need som= e indication on the list that the WG wants to publish this draft, otherwise= I cannot take it forward to the IESG.

 

I also need some = volunteers to read the draft and check it over for errors.

 

So please can&nbs= p; have reviews and confirmation that we should go forward with publication= by 22nd January 2016.

 

Thanks

 

Stewart

 

On 23/12/2015 13:= 00, Stewart Bryant wrote:

> =

> =

> On 09/12/201= 5 14:13, Stewart Bryant wrote:

>> This mes= sage starts the WG Last Call on draft-ietf-pals-tp-oam-config.

>> 

>> This dra= ft can be found at

>> 

>> https://datatra= cker.ietf.org/doc/draft-ietf-pals-mpls-tp-oam-config/

>> 

>> Please r= espond to this thread with substantive comments and an

>> indicati= on of whether you have read the text and whether or not you

>> think it= is ready for publication.

>> 

>> I will c= lose WGLC on 23rd December.

>> 

>> Regards<= /span>

>> 

>> - Stewar= t

> =

> PALS WG

> =

> I should clo= se this LC today, but I have no evidence in terms of list

> traffic in r= esponse to this LC that I can present to the IESG  that

> anyone has r= ead it or cares whether we  publish it of not.

> =

> Has anyone b= esides the chairs and authors read it?

> =

> Should we pu= blish it, and why?

> =

> - Stewart

> =

 

_________________= ______________________________

Pals mailing list=

Pals@= ietf.org

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

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE28B6FB424SZXEMA510MBXchi_-- From nobody Fri Mar 11 15:07:48 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFA912DE99; Fri, 11 Mar 2016 15:05:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230541.15028.66112.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:41 -0800 Archived-At: Cc: db3546@att.com, pals@ietf.org Subject: [Pals] pals - Requested session has been scheduled for IETF 95 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2016 23:05:44 -0000 Dear Andrew Malis, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. pals Session 1 (1:00:00) Tuesday, Afternoon Session II 1620-1720 Room Name: Buen Ayre A size: 125 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Pseudowire And LDP-enabled Services Area Name: Routing Area Session Requester: Andrew Malis Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 50 Conflicts to Avoid: First Priority: bess ccamp detnet mpls nvo3 l2tpext rtgarea rtgwg sfc spring teas sdnrg nfvrg Second Priority: bfd i2rs pce Special Requests: No conflicts with any BOFs in the RTG area. Tuesday or later - sm1 --------------------------------------------------------- From nobody Fri Mar 11 21:02:13 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66912DEB7 for ; Fri, 11 Mar 2016 21:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQ06gjMO87d3 for ; Fri, 11 Mar 2016 21:02:10 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93FB212DEC0 for ; Fri, 11 Mar 2016 21:02:10 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id m82so100476883oif.1 for ; Fri, 11 Mar 2016 21:02:10 -0800 (PST) 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; bh=R5ioZP9KG9ZwIeKW17fcbfYFq5tqiGYjbRbUbMItQ9Q=; b=b4M4dmnjy1/eISI4t3Ada3p0jzpzpzOlj8cvBGfobcOUew2KVFoR0Mfbi1AULVT2VJ +1otEk5j6b7kaSVjQPjRGfeIuXbWK2XQypujUSlJeYkTbWhBCkJODDq6xzo5df1/K7We iXEbP5Gb9f0HAn0tNcVkGcLvPsfyitECepByIeRLnGnDYqu8UfuxVYqiK/2KNueE4GvS 1JQe3bTRvtTccUV0FpS6fUW5R+vlwJ6jEq3CVt+Qo01mGDKBzifFgAmDNohMh2sZXmSM ZUPkYJyp3q3MnVC7Nuxyclw4FY/WxntXaUeWBAZbu467fBa5Nci+s2w8S4ukMfTr9UGf KeIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=R5ioZP9KG9ZwIeKW17fcbfYFq5tqiGYjbRbUbMItQ9Q=; b=FITTO2Hg3Gm0uDApMn64Ku09DIt/fRn6aoX8ikXl/V/igII8PARoM20gIIsPk7HTLJ kINGS2nT0gchlWHwVn2zzEZfOEZ3Fj9Lqp3mMw1JRMSOXIVSIbPblnzwJ3ey3SQtjsUr ZrtWApQpNoYxlmXaU00cFIyKRIyzqH3XClmHSkbnzsARLnYZ8iGCK29pTemWuKacIn0d H2yFSWrJ9D6vWDvO8BY4lrk1pzNXiVWS0F93ANSi94hm66Fqifh2QW3EF9hQrNqnv1Xz cgRUs9mmozLVVlB9MX1E7rq0fnF30mf4pyvWRKhuckiFd3ybS9UL6hjZxvNKtqft720q wsQw== X-Gm-Message-State: AD7BkJLusMMyh968MkY0SjPsNR/nHGXrWunpYJ+EELh46pJhBBKWsGIx2Ehb/zUCpHQ7eX+eo3L8aUKSLMPHeg== X-Received: by 10.202.90.3 with SMTP id o3mr7719016oib.96.1457758930027; Fri, 11 Mar 2016 21:02:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.236.167 with HTTP; Fri, 11 Mar 2016 21:01:50 -0800 (PST) In-Reply-To: <20160311230541.15028.66112.idtracker@ietfa.amsl.com> References: <20160311230541.15028.66112.idtracker@ietfa.amsl.com> From: "Andrew G. Malis" Date: Sat, 12 Mar 2016 06:01:50 +0100 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=001a113d5edc3148e3052dd2f3b4 Archived-At: Subject: Re: [Pals] pals - Requested session has been scheduled for IETF 95 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2016 05:02:12 -0000 --001a113d5edc3148e3052dd2f3b4 Content-Type: text/plain; charset=UTF-8 As a reminder, please send agenda requests to Dave Sinicrope (see his earlier email on the list). Thanks, Andy On Sat, Mar 12, 2016 at 12:05 AM, "IETF Secretariat" wrote: > Dear Andrew Malis, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > pals Session 1 (1:00:00) > Tuesday, Afternoon Session II 1620-1720 > Room Name: Buen Ayre A size: 125 > --------------------------------------------- > > > > Request Information: > > > --------------------------------------------------------- > Working Group Name: Pseudowire And LDP-enabled Services > Area Name: Routing Area > Session Requester: Andrew Malis > > Number of Sessions: 1 > Length of Session(s): 1 Hour > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: bess ccamp detnet mpls nvo3 l2tpext rtgarea rtgwg sfc > spring teas sdnrg nfvrg > Second Priority: bfd i2rs pce > > > > Special Requests: > No conflicts with any BOFs in the RTG area. > Tuesday or later - sm1 > > --------------------------------------------------------- > > --001a113d5edc3148e3052dd2f3b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As a reminder, please send agenda requests to Dave Sinicro= pe (see his earlier email on the list).

Thanks,
Andy

On Sat, Mar 12, 2016 at 12:05 AM, "IETF Secretariat" <agenda@ie= tf.org> wrote:
Dear Andrew = Malis,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

pals Session 1 (1:00:00)
=C2=A0 =C2=A0 Tuesday, Afternoon Session II 1620-1720
=C2=A0 =C2=A0 Room Name: Buen Ayre A size: 125
=C2=A0 =C2=A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name: Pseudowire And LDP-enabled Services
Area Name: Routing Area
Session Requester: Andrew Malis

Number of Sessions: 1
Length of Session(s):=C2=A0 1 Hour
Number of Attendees: 50
Conflicts to Avoid:
=C2=A0First Priority: bess ccamp detnet mpls nvo3 l2tpext rtgarea rtgwg sfc= spring teas sdnrg nfvrg
=C2=A0Second Priority: bfd i2rs pce



Special Requests:
=C2=A0 No conflicts with any BOFs in the RTG area.
Tuesday or later - sm1

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


--001a113d5edc3148e3052dd2f3b4-- From nobody Wed Mar 16 15:58:49 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE1312D79E; Wed, 16 Mar 2016 15:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqymh_-8inzE; Wed, 16 Mar 2016 15:58:38 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE1F12D797; Wed, 16 Mar 2016 15:58:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 77B97180452; Wed, 16 Mar 2016 15:57:54 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160316225754.77B97180452@rfc-editor.org> Date: Wed, 16 Mar 2016 15:57:54 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org Subject: [Pals] RFC 7796 on Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2016 22:58:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7796 Title: Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) Author: Y. Jiang, Ed., L. Yong, M. Paul Status: Standards Track Stream: IETF Date: March 2016 Mailbox: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de Pages: 26 Characters: 52579 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-vpls-pe-etree-11.txt URL: https://www.rfc-editor.org/info/rfc7796 DOI: http://dx.doi.org/10.17487/RFC7796 This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation. This document is a product of the Pseudowire And LDP-enabled Services Working Group of the IETF. This is now a Proposed Standard. 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 nobody Wed Mar 16 17:22:25 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582AA12D790 for ; Wed, 16 Mar 2016 17:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbmomEAcJCq5 for ; Wed, 16 Mar 2016 17:22:19 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5450A12D74A for ; Wed, 16 Mar 2016 17:22:19 -0700 (PDT) Received: by mail-ob0-x22c.google.com with SMTP id ts10so68215428obc.1 for ; Wed, 16 Mar 2016 17:22: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; bh=3SUn6Wwn6bw4R8ixWHjja/O/ZAXU+r6fHejIs6tZjIc=; b=uxVSdtVoWQtA1scfn7Y4DFu9YXUVyb9/NbEW8TczQWUa0XTPp4vpJEQvgQLByEYwYi GTSYsWDYF8s5BAMbCaBQBD30wf2twwz82tBFrVZfhvPVRZidYwTqHHuH0sqhyexBhPUo MYr7yUKXQlicLS4jwzBLVC3fnlmgdYT9y0s+nVwkYQSha5SF0MqlM83u/FOIZSUF4MtL rmdqpJVZYCe9S3rqdU1kZcXruRRLeoXnI0mnfWFz7PS9/tMaGXL0aeax7/kSJUxw7p7S 3ZNjU5MKMOKn/tynU1aba3TGHsejMwMBD+62qGExSxaI+uWEd4zrrRBXAU5QLuyphJ36 WuUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3SUn6Wwn6bw4R8ixWHjja/O/ZAXU+r6fHejIs6tZjIc=; b=iAlWVrWAStZcqFS+Iky6Kp1vqUp7eNn4p8Udc5aEB+XhNiFYzooftvHTV/hvq1QXBf h8M6HA4sRIzoHa335f9oRjdBJQ8LlqbHvpF9VBkJ6w32QBeqz/bc2QLPvsKCi1LcmvjD XJ7q4cArLBpccgboIUehV8KvLz2FMKmflCxgj7FQjBHOOcvjpi4ixB2LZrVKyxQRVw4U M6g6eJ2BwV+XDMpBFzUbFP6TnYlE8QWahgv03wwhCDrT8ZlhCc8n01b1TlWq8hr8eF75 yZ1YniYEtUiUr7bRVVM8pAmh8ufLClATzveJeVwDPw2NsOM1tEDOyasiipyx4pa5wmjX Hpig== X-Gm-Message-State: AD7BkJJ935B9ktiutAzdJLUn0XSk2idaDetP523b+EW+gd3crOvB4pv3dXBES4VLXqrDqxZdLuc8/nkf7YIQhw== X-Received: by 10.60.128.229 with SMTP id nr5mr4550435oeb.56.1458174138663; Wed, 16 Mar 2016 17:22:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.104.162 with HTTP; Wed, 16 Mar 2016 17:21:59 -0700 (PDT) In-Reply-To: <20160316225754.77B97180452@rfc-editor.org> References: <20160316225754.77B97180452@rfc-editor.org> From: "Andrew G. Malis" Date: Wed, 16 Mar 2016 17:21:59 -0700 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e3f748e54bb052e339ff6 Archived-At: Subject: [Pals] Fwd: RFC 7796 on Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 00:22:23 -0000 --047d7b2e3f748e54bb052e339ff6 Content-Type: text/plain; charset=UTF-8 Congratulations to the authors for another PALS RFC! Cheers, Andy ---------- Forwarded message ---------- From: Date: Wed, Mar 16, 2016 at 3:57 PM Subject: [Pals] RFC 7796 on Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Cc: drafts-update-ref@iana.org, pals@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7796 Title: Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) Author: Y. Jiang, Ed., L. Yong, M. Paul Status: Standards Track Stream: IETF Date: March 2016 Mailbox: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de Pages: 26 Characters: 52579 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-vpls-pe-etree-11.txt URL: https://www.rfc-editor.org/info/rfc7796 DOI: http://dx.doi.org/10.17487/RFC7796 This document specifies a generic Virtual Private LAN Service (VPLS) solution, which uses VLANs to indicate root or leaf traffic to support Ethernet-Tree (E-Tree) services. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs), which carry the VLAN indicating the E-Tree attribute. The MAC address-based Ethernet forwarding engine and the PW work in the same way as specified in RFC 4762 and RFC 4448, respectively. A signaling mechanism is described to support E-Tree capability and VLAN mapping negotiation. This document is a product of the Pseudowire And LDP-enabled Services Working Group of the IETF. This is now a Proposed Standard. 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 Official Internet Protocol Standards (https://www.rfc-editor.org/standards) 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 https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk 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 _______________________________________________ Pals mailing list Pals@ietf.org https://www.ietf.org/mailman/listinfo/pals --047d7b2e3f748e54bb052e339ff6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Congratulations to the authors for another PALS RFC!
<= br>
Cheers,
Andy

---------- Forwarded message ----------
From: <rfc-editor@rfc-editor.org>
Date: Wed, Mar 16, 2016 at = 3:57 PM
Subject: [Pals] RFC 7796 on Ethernet-Tree (E-Tree) Support in Vi= rtual Private LAN Service (VPLS)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Cc: drafts-update-ref@iana.org, p= als@ietf.org, rfc-editor@r= fc-editor.org


A new Request for Comments is now available in= online RFC libraries.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 7796

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title:=C2=A0 =C2=A0 =C2=A0 Ethernet-Tree (E-Tre= e) Support in Virtual
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Priva= te LAN Service (VPLS)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author:=C2=A0 =C2=A0 =C2=A0Y. Jiang, Ed.,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L. Yo= ng, M. Paul
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Status:=C2=A0 =C2=A0 =C2=A0Standards Track
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stream:=C2=A0 =C2=A0 =C2=A0IETF
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date:=C2=A0 =C2=A0 =C2=A0 =C2=A0March 2016
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mailbox:=C2=A0 =C2=A0 jiangyuanlong@huawei.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lucyyong@huawei.com,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Manuel.Paul@telekom.de
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages:=C2=A0 =C2=A0 =C2=A0 26
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Characters: 52579
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Updates/Obsoletes/SeeAlso:=C2=A0 =C2=A0None

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I-D Tag:=C2=A0 =C2=A0 draft-ietf-l2vpn-vpls-pe-= etree-11.txt

=C2=A0 =C2=A0 =C2=A0 =C2=A0 URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.rfc-editor.org/info/rfc7796

=C2=A0 =C2=A0 =C2=A0 =C2=A0 DOI:=C2=A0 =C2=A0 =C2=A0 =C2=A0 http:/= /dx.doi.org/10.17487/RFC7796

This document specifies a generic Virtual Private LAN Service (VPLS)
solution, which uses VLANs to indicate root or leaf traffic to
support Ethernet-Tree (E-Tree) services.=C2=A0 A VPLS Provider Edge (PE) model is illustrated as an example for the solution.=C2=A0 In the
solution, E-Tree VPLS PEs are interconnected by Pseudowires (PWs),
which carry the VLAN indicating the E-Tree attribute.=C2=A0 The MAC
address-based Ethernet forwarding engine and the PW work in the same
way as specified in RFC 4762 and RFC 4448, respectively.=C2=A0 A signaling<= br> mechanism is described to support E-Tree capability and VLAN mapping
negotiation.

This document is a product of the Pseudowire And LDP-enabled Services Worki= ng Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestion= s
for improvements.=C2=A0 Please refer to the current edition of the Official=
Internet Protocol Standards (https://www.rfc-editor.org/standard= s) for the
standardization state and status of this protocol.=C2=A0 Distribution of th= is
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
=C2=A0 https://www.ietf.org/mailman/listinfo/iet= f-announce
=C2=A0 https://mailman.rfc-editor.org/mailma= n/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search=
For downloading RFCs, see https://www.rfc-editor.org/retriev= e/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.=C2=A0 Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
Pals mailing list
Pals@ietf.org
https://www.ietf.org/mailman/listinfo/pals

--047d7b2e3f748e54bb052e339ff6-- From nobody Thu Mar 17 00:00:53 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD1DB12D587 for ; Thu, 17 Mar 2016 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoP1tL4SSc0i for ; Thu, 17 Mar 2016 00:00:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FD2B12D554 for ; Thu, 17 Mar 2016 00:00:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CKX26625; Thu, 17 Mar 2016 07:00:46 +0000 (GMT) Received: from SZXEMI401-HUB.china.huawei.com (10.82.75.33) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Thu, 17 Mar 2016 07:00:45 +0000 Received: from SZXEMI506-MBX.china.huawei.com ([169.254.5.147]) by SZXEMI401-HUB.china.huawei.com ([10.82.75.33]) with mapi id 14.03.0235.001; Thu, 17 Mar 2016 15:00:09 +0800 From: "Caowei (Wayne)" To: Stewart Bryant , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org" Thread-Topic: PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp Thread-Index: AQHRHUHBiaV6bnLJp0GrP73wPIUMOZ9d+j7g Date: Thu, 17 Mar 2016 07:00:09 +0000 Message-ID: <007F62FE9FDC864DBFD2289E5B9FCB90818FB468@SZXEMI506-MBX.china.huawei.com> References: <56447F53.7010106@gmail.com> In-Reply-To: <56447F53.7010106@gmail.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.153.98] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.56EA561E.011F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.147, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ac1e69dd16cc7dfcf443057a30042fe9 Archived-At: Cc: "pals-chairs@ietf.org" Subject: [Pals] =?utf-8?b?562U5aSNOiBQQUxTIFdHTEMgb24gZHJhZnQtaWV0Zi1wYWxz?= =?utf-8?q?-mpls-tp-pw-over-bidir-lsp?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 07:00:51 -0000 SGkgU3Rld2FydCwNCg0KU29ycnkgZm9yIGxhdGUgcmVzcG9uc2UsIEkgbWlzc2VkIHRoaXMgZW1h aWwgYmVmb3JlLiANCkkgYW0gbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFJzIG90aGVyIHRoYW4g dGhlIG9uZSB0aGF0IGhhcyBiZWVuIGRpc2Nsb3NlZC4NCg0KVGhhbmtzIQ0KDQpXZWkNCg0KLS0t LS3pgq7ku7bljp/ku7YtLS0tLQ0K5Y+R5Lu25Lq6OiBTdGV3YXJ0IEJyeWFudCBbbWFpbHRvOnN0 ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbV0gDQrlj5HpgIHml7bpl7Q6IDIwMTXlubQxMeaciDEy5pel IDIwOjAwDQrmlLbku7bkuro6IHBhbHNAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtcGFscy1tcGxzLXRw LXB3LW92ZXItYmlkaXItbHNwQHRvb2xzLmlldGYub3JnDQrmioTpgIE6IHBhbHMtY2hhaXJzQGll dGYub3JnDQrkuLvpopg6IFBBTFMgV0dMQyBvbiBkcmFmdC1pZXRmLXBhbHMtbXBscy10cC1wdy1v dmVyLWJpZGlyLWxzcA0KDQpUaGlzIGVtYWlsIGlzIHRvIGRvIHR3byB0aGluZ3M6DQoNCjEpIFRv IHN0YXJ0IHRoZSBQQUxTIFdHIGNhbGwgb24gZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zl ci1iaWRpci1sc3ANClRoZSBkb2N1bWVudCBjYW4gYmUgZm91bmQgYXQNCg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1wYWxzLW1wbHMtdHAtcHctb3Zlci1iaWRp ci1sc3AvDQoNClRoaXMgbGFzdCBjYWxsIHdpbGwgcnVuIHVudGlsIDI1dGggTm92ZW1iZXIgMjAx NS4NCg0KUGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCB3aXRoIHN1YnN0YW50aXZlIGNvbW1l bnRzIG9uIHRoZSBkb2N1bWVudC4gSXQgaXMgYWxzbyB1c2VmdWwgaWYgdGhvc2UgdGhhdCBoYXZl IHJlYWQgdGhlIHRleHQgYW5kIGJlbGlldmUgdGhhdCBpdCBpcyByZWFkeSB0byBzZW5kIHRvIHRo ZSBJRVNHIGNvbmZpcm0gdGhhdC4NCg0KMikgVG8gdmVyaWZ5IHRoYXQgYWxsIElQUiBrbm93biB0 byB0aGUgV0cgaGFzIGJlZW4gZGVjbGFyZWQuIFBsZWFzZSBkZWNsYXJlIHRoaXMgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIHlvdSBhcmUgYW4gYXV0aG9yIG9yIG5vdC4NCg0KSG93ZXZlciBJIHNwZWNp ZmljYWxseSBuZWVkIHRvIGhhdmUgYSByZXNwb25zZSBmcm9tIHRoZSBmaXJzdCB0aHJlZSBhdXRo b3JzIGluIHRoZSBhdXRob3IgbGlzdCBvbiB0aGlzLg0KDQpUaGFua3MNCg0KU3Rld2FydA0KDQoN Cg== From nobody Thu Mar 17 08:23:01 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B4E12D953 for ; Thu, 17 Mar 2016 08:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m6fqHQeF66H for ; Thu, 17 Mar 2016 08:22:58 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D0312D950 for ; Thu, 17 Mar 2016 08:22:57 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id l68so230482401wml.0 for ; Thu, 17 Mar 2016 08:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=1P+ed4BTDTCRSqfWwXPua7xUE+/ZnDwEWYMEBaGcQdc=; b=aaLiKfmCEd4cpokay9aHF7RtxAhWe5y4fofL3gSIZ1g1NRqcADbDX0uzEBexN0bkOj +sVdyYdjd87NQNJibi0mpfRGiPnxQKQ3WDd0cA51/AI4SL5PlrPiMNEZ1a6EixW3vTxa PimmLKlanAgPJkxuvTrtJ+xZPs9u4p7QOGF1bwYifxBMI8Ughtb9tSpAniwKweHN8tb/ JeybH5fM/XTUwkmX36GKgXEODzgJTnRGeTi3i9ocxL332NvgbWVKxggg4On3nsEq7/tC 0yGKZIcDo/aBrgV1lGZQ1pkY5CnfSPxp/RVCATCA3Ovf3busdme1aiXh37WM7QDmVdk4 wjdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=1P+ed4BTDTCRSqfWwXPua7xUE+/ZnDwEWYMEBaGcQdc=; b=N8dtzARz93iiIMRnGFpM8IcgkBcxi6XXIhnjhudGAcyfRRf5DX8OgWap1DKqgTL/bv RJLl4PxgNV7H+yvy20y6FrclHhR35szaVOBY+ilP4i1z7ATahyEJzKfABVVhlMlah5e3 n4vDe0d33EywqBFQGJdpsqJ7HZtPjK1bH452eB63uDMhgUI9FRq3rWJBiqF1mKnXGm3R FzHZtpm2QADrdrVG6/wdRGMMgzBrAtmPdlGFRjE/mCFvxQvlCHtL8mBU6tEaKSywD19Y KB7Hg2yeEOgGEXuuZwkqhp3nO90qdZyn6N7FB4PGX0Wo2l+QMDGTO4rq1LiU9+1Mcio0 Sd0Q== X-Gm-Message-State: AD7BkJK1xhkgIBK0jMNO6PZbcxEcF7jb/cJ5OPmSnA/DTRUHr4bB9VJl70e9lzZDhXbwpQ== X-Received: by 10.28.158.15 with SMTP id h15mr38274113wme.89.1458228176279; Thu, 17 Mar 2016 08:22:56 -0700 (PDT) Received: from [192.168.2.126] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id w125sm8610294wmw.18.2016.03.17.08.22.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2016 08:22:55 -0700 (PDT) To: "Caowei (Wayne)" , "pals@ietf.org" , "draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org" References: <56447F53.7010106@gmail.com> <007F62FE9FDC864DBFD2289E5B9FCB90818FB468@SZXEMI506-MBX.china.huawei.com> From: Stewart Bryant Message-ID: <56EACBCC.1000707@gmail.com> Date: Thu, 17 Mar 2016 15:22:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <007F62FE9FDC864DBFD2289E5B9FCB90818FB468@SZXEMI506-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Pals] =?utf-8?b?562U5aSNOiBQQUxTIFdHTEMgb24gZHJhZnQtaWV0Zi1wYWxz?= =?utf-8?q?-mpls-tp-pw-over-bidir-lsp?= X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2016 15:23:00 -0000 Thanks Publication request just sent to our AD Stewart On 17/03/2016 07:00, Caowei (Wayne) wrote: > Hi Stewart, > > Sorry for late response, I missed this email before. > I am not aware of any other IPRs other than the one that has been disclosed. > > Thanks! > > Wei > > -----邮件原件----- > å‘件人: Stewart Bryant [mailto:stewart.bryant@gmail.com] > å‘é€æ—¶é—´: 2015å¹´11月12æ—¥ 20:00 > 收件人: pals@ietf.org; draft-ietf-pals-mpls-tp-pw-over-bidir-lsp@tools.ietf.org > 抄é€: pals-chairs@ietf.org > 主题: PALS WGLC on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp > > This email is to do two things: > > 1) To start the PALS WG call on draft-ietf-pals-mpls-tp-pw-over-bidir-lsp > The document can be found at > > https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-pw-over-bidir-lsp/ > > This last call will run until 25th November 2015. > > Please respond to this email with substantive comments on the document. It is also useful if those that have read the text and believe that it is ready to send to the IESG confirm that. > > 2) To verify that all IPR known to the WG has been declared. Please declare this regardless of whether you are an author or not. > > However I specifically need to have a response from the first three authors in the author list on this. > > Thanks > > Stewart > > From nobody Fri Mar 18 00:19:07 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4E412D5C2; Fri, 18 Mar 2016 00:19:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160318071904.20232.94531.idtracker@ietfa.amsl.com> Date: Fri, 18 Mar 2016 00:19:04 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mc-pon-03.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2016 07:19:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : Multi-chassis Passive Optical Network (PON) Protection in MPLS Authors : Yuanlong Jiang Yong Luo Edwin Mallette Yimin Shen Guangtao Zhou Filename : draft-ietf-pals-mc-pon-03.txt Pages : 15 Date : 2016-03-18 Abstract: MPLS is being deployed deeper into operator networks, often to or past the access network node. Separately network access nodes such as Passive Optical Network (PON) Optical Line Terminations (OLTs) have evolved to support first-mile access protection, where one or more physical OLTs provide first-mile diversity to the customer edge. Multi-homing support is needed on the MPLS-enabled PON OLT to provide resiliency for provided services. This document describes the multi-chassis PON protection architecture in MPLS and also specifies the Inter-Chassis Communication Protocol (ICCP) extension to support it. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mc-pon/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mc-pon-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mc-pon-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 20 20:24:29 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF912D526; Sun, 20 Mar 2016 20:24:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321032424.8974.16156.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 20:24:24 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-dual-homing-protection-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 03:24:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : Dual-Homing Protection for MPLS and MPLS-TP Pseudowires Authors : Weiqiang Cheng Lei Wang Han Li Kai Liu Shahram Davari Jie Dong Alessandro D'Alessandro Filename : draft-ietf-pals-mpls-tp-dual-homing-protection-02.txt Pages : 11 Date : 2016-03-20 Abstract: This document describes a framework and several scenarios for pseudowire (PW) dual-homing local protection. A Dual-Node Interconnection (DNI) PW is provisioned between the dual-homing Provider Edge (PE) nodes for carrying traffic when failure occurs in the Attachment Circuit (AC) or PW side. In order for the dual-homing PE nodes to determine the forwarding state of AC, PW and the DNI PW, necessary state exchange and coordination between the dual-homing PEs are needed. The PW dual-homing local protection mechanism is complementary to the existing PW protection mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-protection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-dual-homing-protection-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-dual-homing-protection-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 20 20:26:18 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F4F12D526; Sun, 20 Mar 2016 20:26:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321032618.8920.33858.idtracker@ietfa.amsl.com> Date: Sun, 20 Mar 2016 20:26:18 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-mpls-tp-dual-homing-coordination-02.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 03:26:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP) Pseudowires Protection Authors : Weiqiang Cheng Lei Wang Han Li Kai Liu Shahram Davari Jie Dong Alessandro D'Alessandro Filename : draft-ietf-pals-mpls-tp-dual-homing-coordination-02.txt Pages : 13 Date : 2016-03-20 Abstract: In some scenarios, the MPLS Transport Profile (MPLS-TP) Pseudowires (PWs) are provisioned through either static configuration or management plane, where a dynamic control plane is not available. A fast protection mechanism for MPLS-TP PWs is needed to protect against the failure of Attachment Circuit (AC), the failure of Provider Edge (PE) and also the failure in the Packet Switched Network (PSN). The framework and typical scenarios of dual-homing PW local protection are described in [draft-ietf-pals-mpls-tp-dual- homing-protection]. This document proposes a dual-homing coordination mechanism for MPLS-TP PWs, which is used for state exchange and switchover coordination between the dual-homing PEs for dual-homing PW local protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-mpls-tp-dual-homing-coordination/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-mpls-tp-dual-homing-coordination-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-pals-mpls-tp-dual-homing-coordination-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 09:59:01 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E768A12D7CF for ; Mon, 21 Mar 2016 09:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjlbsnf6I9-o for ; Mon, 21 Mar 2016 09:58:57 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59BA12D8E5 for ; Mon, 21 Mar 2016 09:58:56 -0700 (PDT) X-AuditID: c6180641-f79fa6d0000057a9-84-56f0282eab4e Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 2F.28.22441.E2820F65; Mon, 21 Mar 2016 17:58:22 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Mon, 21 Mar 2016 12:58:55 -0400 From: David Sinicrope To: "pals@ietf.org" Thread-Topic: PALS IETF 95 Slot Requests - Buenos Aires Thread-Index: AQHRdKK2jUc0VY2AIE2RSXVw67SOCp9kPJ+A Date: Mon, 21 Mar 2016 16:58:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_D3159F931C2AEFdavidsinicropeericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPrK6exocwgzefpS3W/FvH5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujFN9v9kKliRVHDyX1cB4OKyLkZNDQsBEYsndf4wQtpjEhXvr 2boYuTiEBI4wSsxramWHcJYzSjzb3sIOUsUG1LFu4x4WEFtEQFli1/kpYN3CAuYSN34/Y4WI W0hsb/0BVWMkcWTaP7A4i4CqxPk1K4A2cHDwClhJbLvIBxIWAjJX/XgEVs4pYC1x5dd8sFWM QAd9P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePoYYLyqgJ3G7Yy07RFxRYl//dHaI3niJ +w1/wOp5BQQlTs58wjKBUXQWkrGzkJTNQlIGETeQeH9uPjOErS2xbOFrKFtfYuOXs4wQtrXE snU3mZDVLGDkWMXIUVpckJObbmS4iREYV8ck2Bx3MO7t9TzEKMDBqMTDa3DlfZgQa2JZcWXu IUYJDmYlEV4N9Q9hQrwpiZVVqUX58UWlOanFhxilOViUxHm/fbwcJiSQnliSmp2aWpBaBJNl 4uCUamAsZ+lr3FZw6FcS7wc7WXbpynnL1677dtD5SPKsDp/+IzV9cvtDVbVNbGtcRcrZj2hP +La+yJUv0eve+q2fXy9peVzU5vilP1dR56jstNvGs//tPj3JqKvXM+aJ8porwRufP95gOVPl 26zL+462pU70epHOv7L5ArN7cpLEIueDL+r39C5efdxRiaU4I9FQi7moOBEAk7Xfp6cCAAA= Archived-At: Subject: Re: [Pals] PALS IETF 95 Slot Requests - Buenos Aires X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 16:58:59 -0000 --_000_D3159F931C2AEFdavidsinicropeericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi All, The PALS agenda is posted at the link below. https://www.ietf.org/proceedings/95/agenda/agenda-95-pals If you requested a slot and I haven=92t allocated one, my apologies, please= complete the form below and send it in reply to this email. Those that have slots allocated, please send me your slides as soon as you = complete them. I will need your slides no later than Monday 4 April 2016 23:59:59 Buenos A= ires time. If I don=92t have your slides by that time, you risk losing your slot. Thanks! Dave From: David A Sinicrope > Date: Wednesday, March 2, 2016 at 12:43 PM To: "pals@ietf.org" > Subject: PALS IETF 95 Slot Requests - Buenos Aires Hi All, It's that time again. If you need a presentation slot for the upcoming IETF PALS session, please = reply to this email (subject intact) completing the form below. Please use this form and please reply to this email with the subject intact= . (Not doing so probably means your request will not trigger the filter I = use to identify PALS slot requests.) Form: 1. Topic: (e.g., MPLS and Ethernet OAM Interworking): 2. URL to your draft on Datatracker: you only need to provide the file name= to the example URL (e.g., http://datatracker.ietf.org/doc/draft-ietf-pwe3-= mpls-eth-oam-iwk/): 3. Brief statement of objectives and issues to be discussed and resolved vi= a the presentation during the meeting: (e.g., need to address security iss= ues and get direction from the WG): 4. Requested duration: (norm/default is 10 min): 5. Speaker name: (e.g., Dave SINICROPE= ): Thanks! Dave --_000_D3159F931C2AEFdavidsinicropeericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: David A Sinicrope <david.sinicrope@ericsson.com&g= t;
Date: Wednesday, March 2, 2016 at 1= 2:43 PM
To: "pals@ietf.org" <pals@i= etf.org>
Subject: PALS IETF 95 Slot Requests= - Buenos Aires


Hi All,

It's that time again. 

If you need a presentation slot for the upcoming IET= F PALS session, please reply to this email (subject intact= ) completing the form below.   

Please use this form and&n= bsp;please reply to this email with the subject i= ntact.  (Not doing so probably means your request will not trigger the= filter I use to identify PALS slot requests.)

Form:
1. Topic:= (e.g., MPLS and Ethernet OAM Interworking):

2. URL to your draft on D= atatracker:&n= bsp;you only need to provide the file name to the example URL (e.g., http://datatracker.ietf.org/doc/draft-i= etf-pwe3-mpls-eth-oam-iwk/):   

3. Brief statement of objectives and issues to be= discussed and resolved via the presentation during the meeting:  = (e.g., need to address security issues and get direction from the WG): &nbs= p;

4. Requested duration: (norm/default is 10 min):=

5. Speaker name: <Given-name FAMILY-N= AME-IN-ALL-CAPS> (e.g., Dave SINICROPE):  

 

Thanks!
Dave<= /div>
--_000_D3159F931C2AEFdavidsinicropeericssoncom_-- From nobody Mon Mar 21 13:31:25 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2B12D652; Mon, 21 Mar 2016 13:31:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321203123.12199.45999.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 13:31:23 -0700 Archived-At: Cc: pals@ietf.org Subject: [Pals] I-D Action: draft-ietf-pals-p2mp-pw-00.txt X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:31:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Pseudowire And LDP-enabled Services of the IETF. Title : Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP Authors : Siva Sivabalan Sami Boutros Luca Martini Maciek Konstantynowicz Gianni Del Vecchio Yuji Kamite Lizhong Jin Filename : draft-ietf-pals-p2mp-pw-00.txt Pages : 18 Date : 2016-03-21 Abstract: This document specifies a mechanism to signal Point-to-Multipoint (P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable for any Layer 2 VPN service requiring P2MP connectivity over an IP or MPLS enabled PSN. A P2MP PW established via the proposed mechanism is root initiated. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-pals-p2mp-pw/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-pals-p2mp-pw-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 21 13:55:53 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC9C12DB5E for ; Mon, 21 Mar 2016 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHVS8VjDakEP for ; Mon, 21 Mar 2016 13:55:51 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4F112DB61 for ; Mon, 21 Mar 2016 13:55:51 -0700 (PDT) Received: by mail-ob0-x234.google.com with SMTP id fp4so185188127obb.2 for ; Mon, 21 Mar 2016 13:55:51 -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; bh=EVJWlBDUIVqE8T6H+wDvaxUxKQS9AyAwMcxSqKp6LTw=; b=IIyy/FZ4FrubKCBoltPQCH/luP5SghogLu5uTG9XbRCV1hjm6Ve/EavxmKyuu2dQAr /5ujBBz/cPBhocdGNq/Qikz3OQzOjnRoe3jUclVCU3r0QmS/C0ZYWNU25TBOe3SuQ+EZ MvZxtZvyFEHJQD1kYZBnWIHVdEMTme/L8UlLFcewDnVCi8SLYUfUQPuSkJ2NSXE95aAC VoPBIcZ2YT08Q7S67n1JbEfXnYxnuOaBB1yEtiq6Bk6cM5zw1R2jSs4nnsE5sRLAChes XMGAeJUar19Pfx0CXRs5zLAHKFg6sbTVHkhN3sDb9HswvdRPCn+fIWEEFs2YyZMxfevL H53g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EVJWlBDUIVqE8T6H+wDvaxUxKQS9AyAwMcxSqKp6LTw=; b=YHdLCCw0JTgmcAuqvNkCWaeLfpCIRoBwaIAF05lyqeHKDHMEP9mu+bYb8Bbilg0Jhb 7u+7xtnNEc9W6hLKoGQRq3PqzKtEA/VEzkT0mtYIns7xJH09dXS9I/TUsr26tjfmLu96 FJzi9N+vF2+9dHntiPX3vJisRHyxNM7zqicBc06Fb5Fon4qiFCFHnU/BlipljUQiIuo3 yAQ+IBxj9hXmrW/zl6E+R7HVulEHv5CHwf5pubqNHyVMzoA/0XaG3ytlpM3hBT7SU3H/ TkQauZnOShgO2l09V+GSDzMZjvA+tqNeL5XwyuOZ8E857i7WFBySSrFEchU9Z3Jb700M IGvA== X-Gm-Message-State: AD7BkJL6qdQiWOOOMzxsl+jsqzoFgqcQRXWZAAt+FicUQymlKXTmGgyEJOhTKWxs9eKwobNBDIniVRyjUJB6Fw== X-Received: by 10.60.51.135 with SMTP id k7mr19721471oeo.42.1458593750756; Mon, 21 Mar 2016 13:55:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.104.162 with HTTP; Mon, 21 Mar 2016 13:55:31 -0700 (PDT) From: "Andrew G. Malis" Date: Mon, 21 Mar 2016 16:55:31 -0400 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=001a11c301a662b32f052e955228 Archived-At: Subject: [Pals] Draft PALS agenda uploaded X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:55:53 -0000 --001a11c301a662b32f052e955228 Content-Type: text/plain; charset=UTF-8 The PALS draft agenda is now online at https://datatracker.ietf.org/meeting/95/agenda/pals/ . Cheers, Andy --001a11c301a662b32f052e955228 Content-Type: text/html; charset=UTF-8
The PALS draft agenda is now online at https://datatracker.ietf.org/meeting/95/agenda/pals/ .

Cheers,
Andy

--001a11c301a662b32f052e955228-- From nobody Tue Mar 22 14:46:55 2016 Return-Path: X-Original-To: pals@ietf.org Delivered-To: pals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5468E12DA64; Tue, 22 Mar 2016 14:46:51 -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: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160322214651.4076.9148.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 14:46:51 -0700 Archived-At: Cc: draft-ietf-pals-seamless-vccv@ietf.org, pals-chairs@ietf.org, "Andrew G. Malis" , db3546@att.com, pals@ietf.org Subject: [Pals] Last Call: (Seamless BFD for VCCV) to Proposed Standard X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 21:46:51 -0000 The IESG has received a request from the Pseudowire And LDP-enabled Services WG (pals) to consider the following document: - 'Seamless BFD for VCCV' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document extends the procedures and Connectivity Verification (CV) types already defined for Bidirectional Forwarding Detection (BFD) for Virtual Circuit Connectivity Verification (VCCV) to define Seamless BFD (S-BFD) for VCCV. This document updates RFC 5885, extending the CV Values and the Capability Selection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-pals-seamless-vccv/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-pals-seamless-vccv/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Thu Mar 24 08:54:45 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED03D12DBEF; Thu, 24 Mar 2016 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.38 X-Spam-Level: X-Spam-Status: No, score=0.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEXHASH_WORD=3, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W-CiIvq_TeL; Thu, 24 Mar 2016 08:54:39 -0700 (PDT) Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C06B12DC2A; Thu, 24 Mar 2016 08:42:28 -0700 (PDT) Received: from pps.filterd (m0002317.ppops.net [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2OFfIrW028652; Thu, 24 Mar 2016 11:42:23 -0400 Received: from vawvcgsie2k1301.ciena.com (lin1-118-36-35.ciena.com [63.118.36.35]) by mx0b-00103a01.pphosted.com with ESMTP id 21s30eyh3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 24 Mar 2016 11:42:23 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by VAWVCGSIE2K1301.ciena.com (10.4.62.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 24 Mar 2016 11:42:22 -0400 Received: from ONWVEXCHHT03.ciena.com (10.128.6.43) by MDWEXCHCGSIHT01.ciena.com (10.4.140.106) with Microsoft SMTP Server (TLS) id 8.3.389.2; Thu, 24 Mar 2016 11:42:22 -0400 Received: from ONWVEXCHMB04.ciena.com ([::1]) by ONWVEXCHHT03.ciena.com ([::1]) with mapi; Thu, 24 Mar 2016 11:42:21 -0400 From: "Shah, Himanshu" To: "bess@ietf.org" , "pals@ietf.org" Date: Thu, 24 Mar 2016 11:42:22 -0400 Thread-Topic: Request for WG adoption of draft-shah-bess-l2vpn-yang-01 Thread-Index: AdGF4iKx8iQBmnrMSwqmmiJCotxTmQ== Message-ID: <40746B2300A8FC4AB04EE722A593182BA85E5AB1@ONWVEXCHMB04.ciena.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-CA X-TM-AS-Product-Ver: SMEX-11.0.0.4179-8.000.1202-22214.003 X-TM-AS-Result: No--21.896200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: multipart/alternative; boundary="_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-24_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: Thomas Morin , Martin Vigoureux Subject: [Pals] Request for WG adoption of draft-shah-bess-l2vpn-yang-01 X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 15:54:41 -0000 --_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear BESS WG chairs - The authors of the draft-shah-bess-l2vpn-yang-01.txt request the adoption o= f this draft as working group document. We have been holding design team meeting every week since months and have h= ad very active participation and contribution from a lot of members (evident from the auth= or list..) We believe the individual draft is mature enough to have the entire WG to c= ontribute as a WG work item. I know this is close to the face-2-face meeting coming up shortly in a coup= le of weeks. We do not mind an extended WG adoption polling and would prefer that adopti= on email be sent out before the meeting. Thanks, Himanshu Shah on behalf of all the co-authors --_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear BESS WG chairs –=

 

The authors of the draft-shah-bess= -l2vpn-yang-01.txt request the adoption of this draft=

as working group document.

<= i> <= /i>

We have been holding design team meeting every week since months and ha= ve had very active

participation and contribution fro= m a lot of members (evident from the author list..)

<= o:p> 

We believe the individual draft is mature enoug= h to have the entire WG to contribute

as a WG work it= em.

 

I know this is close= to the face-2-face meeting coming up shortly in a couple of weeks.

We do not mind an extended WG adoption polling and would pre= fer that adoption email

be sent out before the meetin= g.

 

Thanks,

Himanshu Shah on behalf of all the co-authors

 

= --_000_40746B2300A8FC4AB04EE722A593182BA85E5AB1ONWVEXCHMB04cie_-- From nobody Thu Mar 31 04:20:29 2016 Return-Path: X-Original-To: pals@ietfa.amsl.com Delivered-To: pals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9282612D5BE for ; Thu, 31 Mar 2016 04:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kb_AlgAJMXQg for ; Thu, 31 Mar 2016 04:20:25 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA1F12D5A9 for ; Thu, 31 Mar 2016 04:20:25 -0700 (PDT) Received: by mail-ob0-x236.google.com with SMTP id fp4so20573162obb.2 for ; Thu, 31 Mar 2016 04:20:25 -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; bh=HNSG0Mgh7DCyMQ011G8BekzQ3gy+F5aeozt101Fr1jE=; b=oc1n1U9NJcgNvMC4rS6kSbOR2VBnt4IuiUXFDwwSG9ig7y0Yl5Oxpm9sEYXXXvPwj6 PTFBnUZfvd/iNcLX4kI0BoGGANKdqP4BOgqy8yP5BO3/5BISJtH7QEYZUsqHjnrHUm5r UMmRIV23i52CYUqDT+VA6eS7Sut+EHNZFxANRpabvueiS4z58OrfPv9x29JaYsiZgoIu 8dEjV3UmA++dCrTYVHh9SJw9TCDPlXL+hZQ0nfoHEjLH1gBYot0uifVXxXddZHqKT4pP 5xxzvPGSQtefiQmQNNrUuZNfsRILv2CpLf1djCWd14FGK72gDlTBw9C+PD6Y1sdov7t3 0LnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=HNSG0Mgh7DCyMQ011G8BekzQ3gy+F5aeozt101Fr1jE=; b=mgqrSxgh519afTwI/nQOIVBzs7SdRmS8EDqfUclFDbQcJ14Bos8R2HHjFHiAEzBsln uIYbVMz9o9QR7vkhLYI2p+76hZSlfBAaMR2O85oYa8BRZE1i/CIKc+zbCCten0QCF4tT Bk0+CZJpW+7+VDz0+qfdLcPWy3igQVDY4AgYEAotuz67TESwI0RCBZYHvOpziwaR3Bwx rODy7BKbb84uG33hr7rzLtvDER/P73KfqO15HAWwKpRq1UpF+4TSiA8tZEQwZNdU1xLX 7qCjNBvXu5YBw4yyos1Ssb8CqTZUO2xuxjEPCEqAmJVB8CuEOBgKYpIyE4kMBsdNGUEv hi1g== X-Gm-Message-State: AD7BkJIlVFWNvC2JL/y2uCrwV+yLnvL2sybuP2F29Q1hBLoRtaNdEBm6TwH7LqYu57A4x/jnatyuM09dvVjeOA== X-Received: by 10.60.128.229 with SMTP id nr5mr917828oeb.56.1459423224539; Thu, 31 Mar 2016 04:20:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.104.162 with HTTP; Thu, 31 Mar 2016 04:20:04 -0700 (PDT) From: "Andrew G. Malis" Date: Thu, 31 Mar 2016 07:20:04 -0400 Message-ID: To: "pals@ietf.org" Content-Type: multipart/alternative; boundary=047d7b2e3f74e032ad052f567264 Archived-At: Subject: [Pals] Please send in your PALS slides X-BeenThere: pals@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Pseudowire And LDP-enabled Services dicussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2016 11:20:26 -0000 --047d7b2e3f74e032ad052f567264 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If you=E2=80=99re on the PALS agenda, please send in your slides to Dave so= that we can run the meeting from a single laptop, it=E2=80=99s also for the benefit= of any remote participants. We need everything uploaded by Sunday, so please get in those slides, or let us know if you don=E2=80=99t plan to use any. Thanks, Andy --047d7b2e3f74e032ad052f567264 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you=E2=80=99re on the PALS agenda, please send in your = slides to Dave so that we can run the meeting from a single laptop, it=E2= =80=99s also for the benefit of any remote participants. We need everything= uploaded by Sunday, so please get in those slides, or let us know if you d= on=E2=80=99t plan to use any.

Thanks,
Andy

--047d7b2e3f74e032ad052f567264--